Proposta de unificação das metodologias RUP e Scrum através de sua releitura

Tamanho: px
Começar a partir da página:

Download "Proposta de unificação das metodologias RUP e Scrum através de sua releitura"

Transcrição

1 UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia de Computação Bradley Felipe Zanoni Fonseca Proposta de unificação das metodologias RUP e Scrum através de sua releitura Itatiba 2012

2 Bradley Felipe Zanoni Fonseca RA: Proposta de unificação das metodologias RUP e Scrum através de sua releitura Monografia apresentada ao Curso de Engenharia de Computação da Universidade São Francisco como requisito parcial para a obtenção do título de Bacharel em Engenharia de Computação. Orientador: Prof. Rodrigo Luiz Nolli Brossi Itatiba 2012

3 Dedico este trabalho aos meus pais Ary e Angela, a minha irmã Yasmin e ao meu irmão Kelvyn que me apoiaram nesta etapa da vida. Dedico também a Débora, que sempre esteve do meu lado me dando forças, dedicação extensiva também aos meus amigos.

4 AGRADECIMENTOS Agradeço primeiramente a Deus, por estar sempre ao meu lado, e pelas oportunidades e desafios propostos. Agradeço aos meus pais, Ary e Angela, por tudo. Pelo apoio durante toda a vida, assim como durante o Curso Universitário, pelas oportunidades que possibilitaram eu ser o que sou hoje. Aos meus irmãos, Yasmin e Kelvyn, por sempre me apoiarem e pelo companheirismo, agradecendo também aos meus avós, tios e primos. Também quero agradecer a Débora, minha amada e companheira, pelo seu apoio, dedicação, força e por estar sempre ao meu lado. Ao meu professor, orientador e amigo, Rodrigo, agradeço pelo apoio durante o curso e a realização deste trabalho. Também são dignos de agradecimento todos os professores, pelo empenho e dedicação ao instruir os alunos, possibilitando um aperfeiçoamento profissional, pessoal e intelectual, aproveito reiterar meu respeito pela profissão, sendo de muito prestigio. Agradeço a todos os meus amigos, por estarem presentes em minha vida, me auxiliando e apoiando. A aqueles amigos da universidade e do ônibus, agradeço por todos os momentos, e pela troca de conhecimento e cultura.

5 "Você pode encarar um erro como uma besteira a ser esquecida, ou como um resultado que aponta uma nova direção". Steve Jobs

6 RESUMO Será realizada uma revisão bibliográfica e avaliação das metodologias RUP e Scrum, além do guia de gerenciamento de projetos PMBOK, sendo assim, com estes conceitos, será elaborado uma proposta de unificação das metodologias RUP e Scrum, buscando ainda atender o desenvolvimento de sistemas para Web e utilizando o mínimo de recursos, possibilitando a produção de software com baixo custo para atender pequenas organizações ou profissionais liberais. Palavras-chave: Gerenciamento. Projetos. Software.

7 ABSTRACT There will be a bibliographic review and evaluation of RUP and Scrum methodologies, as well as guide PMBOK project management, so with these concepts will be elaborated a proposal for unification of the RUP and Scrum methodologies, seeking to serve the still developing systems for Web and using minimal resources, enabling the production of software with low cost to meet small organizations or professionals. KEY WORDS: Management. Projects. Software.

8 LISTA DE ILUSTRAÇÕES FIGURA 1 Mapeamento dos grupos de processos e as áreas de conhecimento do PMBOK FIGURA 2 Grupo de processos de inicialização do PMBOK FIGURA 3 Grupo de processos de planejamento do PMBOK FIGURA 4 Grupo de processos de execução do PMBOK FIGURA 5 Grupo de processos de monitoramento e controle do PMBOK FIGURA 6 Grupo de processos de encerramento do PMBOK FIGURA 7 Grupos de processos de gerenciamento de projetos FIGURA 8 Atividade dos grupos de processos durante o projeto FIGURA 9 Resumo dos processos de gerenciamento de integração de processos e atividades do PMBOK FIGURA 10 Exemplo de fluxo de trabalho principal FIGURA 11 Artefatos da disciplina de modelagem de negócios FIGURA 12 Artefatos da disciplina de requisitos FIGURA 13 Artefatos da disciplina de analise FIGURA 14 Artefatos da disciplina de implementação FIGURA 15 Artefatos da disciplina de testes FIGURA 16 Artefatos da disciplina de distribuição FIGURA 17 Artefatos da disciplina de configuração e gerenciamento de mudanças FIGURA 18 Artefatos da disciplina de gerenciamento de projeto FIGURA 19 Artefatos da disciplina de ambiente... 37

9 FIGURA 20 Ciclo de vida do RUP FIGURA 21 Arquitetura geral do RUP FIGURA 22 Produtos de trabalho do RUP FIGURA 23 Ciclo de vida do Scrum FIGURA 24 Ciclo de vida da metodologia Processo Unificado Ágil FIGURA 25 Grupo de processos de inicialização FIGURA 26 Grupo de processos de planejamento FIGURA 27 Planejamento da construção do projeto Backlog FIGURA 28 Grupo de processos de construção FIGURA 29 Grupo de processos de transição FIGURA 30 Grupo de processos de gerenciamento de projeto FIGURA 31 Benchmark dos principais processos e grupos... 59

10 LISTA DE ABREVIATURAS E SIGLAS RUP Rational Unified Process UML Unified Modeling Language ERP Enterprise Resource Planning PMBOK Project Management Body of Knowledge PMI Project Management Institute

11 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS METODOLOGIA REVISÃO BIBLIOGRÁFICA GERENCIAMENTO DE PROJETOS O guia de gerenciamento de projetos PMBOK Os grupos de processos de gerenciamento de projetos do PMBOK Processos de Iniciação Processos de Planejamento Processos de Execução Processos de Monitoramento e Controle Processos de Encerramento Integração entre os grupos e processos ENGENHARIA DE SOFTWARE Evolução da Engenharia de Software Processo Unificado RUP (Rational Unified Process) Princípios do RUP Elementos do RUP Disciplinas do RUP Ciclo de vida do RUP Arquitetura geral do RUP... 40

12 Produtos de trabalho do RUP Desenvolvimento Ágil Scrum Princípios do Scrum Ciclo de vida do Scrum AVALIAÇÃO QUALITATIVA E QUANTITATIVA ENTRE OS METODOS PROPOSTA DA UNIFICAÇÃO DAS METODOLOGIAS PAPÉIS OS GRUPOS DE PROCESSOS DA METODOLOGIA PROCESSO UNIFICADO ÁGIL Grupo de processos de inicialização Grupo de processos de planejamento Grupo de processos de construção Grupo de processos de transição Grupo de processos de gerenciamento do projeto BENCHMARK DOS PROCESSOS DA METODOLOGIA PROCESSO UNIFICADO ÁGIL CONCLUSÃO REFERENCIAS BIBLIOGRÁFICAS ANEXOS ANEXO A Documento de Especificação de Requisitos ANEXO B Documento de Especificações Técnicas ANEXO C Documentação de Gerenciamento de Mudanças... 70

13 13 1 INTRODUÇÃO Hodiernamente a tecnologia da informação esta cada vez mais presente no dia a dia das pessoas e empresas de todo o mundo, tecnologias estas que auxiliam na organização e otimização de processos. Neste aspecto, companhias de grande e algumas de médio porte investem muito na área, possibilitando melhoramentos no desempenho, o que converge em um aumento dos lucros. Desta forma, a maioria das fábricas de software focam em atender e fornecer soluções à estas empresas que muito investem na tecnologia da informação. Para uso destes grandes clientes existem os Sistemas Integrados de Gestão Empresarial, ou E.R.P. (Enterprise Resource Planning), que basicamente integra todos os setores e dados do negócio, tornando fácil a administração do todo. Em contrapartida, os pequenos negócios e profissionais liberais, que estão presentes em grande número no mercado, são desfavorecidos quanto a soluções de tecnologia da informação, seja por falta de opção ou por valores elevados. No caso dos sistemas integrados é raro encontrar para esses empreendimentos, restando a opção de utilizar pequenos softwares, os quais devem ser adquiridos especificamente para cada setor. Já construir e manter um software de qualidade é muito difícil, ainda mais tratando de uma equipe de desenvolvedores, onde pode ocorrer comunicação ambígua e imprecisa, e complexidade do software subestimada comprometendo a qualidade final do produto, além destes fatores, podemos citar ainda a falha no entendimento das necessidades do usuário, inabilidade de tratar mudança de requisitos, arquitetura fracamente definida e testes insuficientes. Para tratar os problemas citados, além de aplicar padrões aos times de desenvolvedores e prover qualidade aos produtos, temos as metodologias de gerenciamento de projetos, que sugere uma forma padronizada de se trabalhar e gerenciar os projetos.

14 14 2 OBJETIVOS A elaboração deste trabalho tem como objetivo estudar alguns tipos de metodologias de gerenciamento de projetos. Com os estudos realizados, será efetuada uma avalição das metodologias, afim de elaborar uma proposta de unificação das metodologias estudadas, focando como caso de uso o desenvolvimento de Sistemas Integrados de Gestão Empresarial para pequenas empresas, levando em consideração percalços reais, como infraestrutura e recursos monetários disponíveis neste tipo de empresas.

15 15 3 METODOLOGIA Para a realização do trabalho, será realizado um estudo das metodologias de gerenciamento de projetos já existentes, como as metodologias RUP, SCRUM e Um Guia do Conhecimento em Gerenciamento de Projetos (PMBOK). Na primeira etapa do trabalho, será realizado uma revisão bibliográfica das metodologias citadas. Após esta revisão, em um segundo passo, será realizado uma avaliação dos itens estudados na primeira etapa, afim de elaborar uma proposta de unificação das metodologias através de sua releitura.

16 16 4 REVISÃO BIBLIOGRÁFICA 4.1 GERENCIAMENTO DE PROJETOS Segundo o PMI (2008), um projeto compreende em um esforço temporário para criar um produto, serviço, ou resultado exclusivo, sendo temporário pelo fato que tem início e fim definidos. Também é afirmado no Guia que cada projeto é exclusivo e com resultado incerto, mesmo que esteja usando os mesmos recursos, pelo fato de que cada projeto é caracterizado por um conjunto de entradas, ferramentas e técnicas que podem ser aplicadas e saídas resultantes. Diferenciamos projetos de processos por alguns aspectos, sendo o projeto temporário e com resultados únicos e incertos, os processos são permanentes, repetitivos, com resultados previsíveis e focados na disciplina, afirma o PMI (2008). Geralmente um processo é resultado de um projeto. Temos também aspectos comuns entre eles que são limitados por recursos; planejados, executados e controlados. Gerenciamento de projetos, o PMI (2008), considera como a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades de um projeto, a fim de cumprir seus requisitos com o maior desempenho possível. Segundo o PMI (2008), o desempenho desejável em um projeto define se pelo balanceamento de restrições conflitantes, como por exemplo, o escopo, a qualidade, o cronograma, o orçamento, os recursos e os riscos do projeto. Para que um projeto seja bem sucedido, o PMI (2008) recomenda que sejam adotados processos de gerenciamento de projetos, que são na realidade boas práticas, isto significa que existe um consenso geral de que a aplicação destes processos garante um fluxo eficaz e aumentam as chances de êxito em projetos. Isto não significa também que estes conhecimentos e habilidades devem ser empregados uniformemente em todos os projetos, mas sim conforme o escopo, resultado esperado e ferramentas de cada projeto. Neste âmbito, podemos encontrar diversos guias para gerenciamento de projetos, neste trabalho será utilizado o PMBOK (Project Management Body of Knowlegde), pelo fato de que atualmente é um dos mais utilizados no mundo.

17 O guia de Gerenciamento de Projetos PMBOK O guia de gerenciamento de projetos PMBOK, está atualmente em sua quarta edição e foi publicado pela Project Management Institute (PMI), uma das maiores organizações de profissionais de gerenciamento de projetos do mundo. O guia aborda todo o conteúdo relacionado a projetos e o seu gerenciamento, considerando que o gerenciamento pode ser realizado a partir da execução de processos de forma inter-relacionada, afirma a PMI (2008). Estes processos são divididos em cinco grupos e distribuídos em nove áreas de conhecimento. Sendo assim, no guia PMI (2008), os processos de gerenciamento de projetos são apresentados como elementos distintos, e cada um com sua configuração, porém na prática eles se sobrepõem e interagem de forma que não são detalhadas no guia, pelo fato de que existem várias formas de gerenciar um projeto Os Grupos de processos de gerenciamento de projetos do PMBOK O guia PMBOK apresenta os processos de gerenciamento de projetos agrupados em cinco categorias, conforme as interações e objetivos de cada processo. Os grupos são os de processos de inicialização, planejamento, execução, monitoramento e controle e encerramento (FIGURA 1). Também, cada processo definido no guia é caracterizado pela área de conhecimento, sendo, integração, escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos e aquisições as áreas dos processos, descreve o PMI (2008).

18 18 Fonte: PMBOK FIGURA 1: Mapeamento dos grupos de processos e as áreas de conhecimento do PMBOK

19 Processos de Iniciação Segundo o PMI (2008), os processos de inicialização são utilizados na definição de um novo projeto ou fase de um projeto já existente, obtendo autorização das partes para inicio. Nestes processos é definido o escopo inicial, os recursos financeiros iniciais e há uma interação entre as partes externas e internas interessadas no projeto, para identificação dos resultados esperados (FIGURA 2). Fonte: PMBOK FIGURA 2: Grupo de processos de inicialização. Quando há projetos grandes divididos em fases, o guia recomenda que este grupo não seja deixado de lado, pois ajuda a manter o foco nas necessidades para qual o projeto foi criado. A inicialização é importante em um projeto, pois geralmente o envolvimento dos clientes, ou outras partes interessadas, aumenta a probabilidade de aceitação e satisfação das partes interessadas. Neste grupo são descritos os objetivos do projeto, incluindo os motivos que levaram a iniciar um novo projeto, explica o PMI (2008). A partir destas informações é elaborado um documento, o Termo de Abertura de Projeto, que pode conter também a declaração inicial do escopo do projeto, prazos, duração do projeto e uma breve previsão dos recursos financeiros necessários. Este grupo de processos também é responsável pela identificação das partes interessadas, pessoas ou organizações afetadas pelo projeto.

20 20 Segundo o PMI (2008), este documento originado autoriza formalmente o início do trabalho, levando ao conhecimento das partes interessadas as necessidades e resultados esperados do determinado projeto, para que o mesmo satisfaça as expectativas Processos de Planejamento Conforme o guia, este grupo de processos tem a função de definir o escopo total do projeto, refinar os objetivos e desenvolver rumo de ação para obter os resultados para o qual o projeto foi criado. Estes processos de planejamento desenvolvem o plano de gerenciamento e os documentos necessários para execução do projeto (FIGURA 3). Fonte: PMBOK FIGURA 3: Grupo de processos de planejamento.

21 21 Ao longo do planejamento, informações e características sobre o projeto são coletadas e compreendidas, afirma o PMI (2008). O planejamento não é realizado somente uma vez, pois durante o ciclo de vida do projeto pode ser encontrado problemas ou mudanças necessárias fazendo com que parte do projeto seja replanejada. Ainda, segundo o guia, este grupo de processos gera um plano de gerenciamento e documentos, explorando características de escopo, custos, tempo, risco, qualidade, comunicação e aquisições. Atualizações ou mudanças autorizadas impacta no plano e em seus documentos, sendo necessário, para obter maior precisão no desenvolvimento do projeto, a atualização dos documentos de planejamento. A equipe envolvida no desenvolvimento do projeto deve estimular o envolvimento das partes interessadas no projeto ao planejá-lo, para que identifiquem o máximo de problemas ou melhoramentos nesta fase, afirma o PMI (2008). Contudo, alguns procedimentos definidos pela organização determinam quando encerrar o planejamento do projeto, procedimentos estes afetados pelos limites do projeto, natureza e pelas atividades de monitoramento e controle, explica o PMI (2008) Processos de Execução Segundo o guia PMBOK, este grupo de processos, consiste em concluir o trabalho definido no plano, ou seja, colocar em prática o desenvolvimento do projeto (FIGURA 4). Este grupo, envolve a coordenação de pessoal, recursos, integração e execução das atividades do projeto conforme o plano gerado.

22 22 Fonte: PMBOK FIGURA 4: Grupo de processos de execução. Conforme já exposto no item anterior, o guia do PMI (2008) afirma que nesta fase há a possibilidade de necessidade de atualizações no planejamento do projeto, podendo afetar nas durações previstas para cada atividade, produtividade, disponibilidade de recursos e riscos Processos de Monitoramento e Controle O guia PMBOK também apresenta o grupo de processos de monitoramento e controle, que basicamente consiste em acompanhar, revisar e regular o progresso e o desempenho do projeto (FIGURA 5). Quando há inconformidades ou necessidades de alteração no projeto, este grupo é responsável em identificar as áreas nas quais serão efetuadas as alterações, no plano do desenvolvimento do projeto, para que estas sejam executadas.

23 23 Fonte: PMBOK FIGURA 5: Grupo de processos de monitoramento e controle. Este grupo, segundo o guia PMBOK, está associado a todos os outros grupos de processos de gerenciamento de projeto, pois tem como função monitorar as atividades do projeto conforme o plano e à linha de base de desempenho do projeto, controlar as mudanças e recomendar ações preventivas e influenciar para que somente as mudanças autorizadas sejam implementadas. A grande importância deste grupo, segundo o PMI (2008), esta relacionada ao fato de que devido ao monitoramento de todo o projeto e sendo este contínuo, fornece à equipe do projeto uma melhor visão sobre a saúde e identifica as áreas que requerem maior atenção no projeto.

24 Processos de Encerramento Por sua vez, o grupo de processos de encerramento consiste em finalizar todas as atividades, visando completar formalmente o projeto afirma o PMI (2008). Este grupo quando concluído verifica se os processos estão completos em todos os grupos, para se obter a aceitação do cliente (FIGURA 6). Fonte: PMBOK FIGURA 6: Grupo de processos de encerramento. Além da aceitação do cliente, segundo o guia, é feita uma revisão pósprojeto, registrado os impactos da adequação de algum processo, documentado as lições aprendidas, aplicada as atualizações apropriadas aos processos organizacionais ativos, arquivados os documentos relevantes ao projeto e encerrada às aquisições Integração entre os grupos e processos. Os grupos e seus processos apresentados, segundo o guia PMBOK, tem interações comuns, apesar de serem apresentados como distintos. Sendo assim, na prática os processos interagem e se sobrepõem de forma não detalhada pelo PMBOK, pelo fato de que estas integrações variam em cada projeto.

25 25 Sendo assim, os grupos e processos de gerenciamento de projetos interagem entre si, podendo ocorrer dependências entre esses processos, ou seja, a saída de um grupo ou processo ser à entrada de outro afirma o PMI (2008) (FIGURA 7). Fonte: PMBOK FIGURA 7: Grupos de processos de gerenciamento de projetos. Ainda segundo o guia, os grupos de processos raramente são executados exclusivamente e dificilmente ocorrem uma única vez; sendo atividades sobrepostas durante a vida do projeto (FIGURA 8). Fonte: PMBOK

26 26 FIGURA 8: Atividade dos grupos de processos durante o projeto. O PMBOK trata do gerenciamento da integração do projeto de forma separada do ciclo de vida principal do projeto, incluindo processos e atividades exclusivas para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dos grupos de processos do ciclo principal. Desta forma esses processos e atividades relacionados a integração, integra conhecimentos de unificação, consolidação, articulação e ações integradoras, que são necessárias para que o projeto chegue ao seu fim, com as expectativas atendidas. Ainda conforme o guia PMBOK, estes processos de gerenciamento da integração do projeto, requer por parte do gerente, que sejam realizadas escolhas e negociações, quanto a recursos, objetivos e alternativas. Conforme já explicito, o guia não detalha como é realizada a integração dos processos e atividades, cabendo ao gerente responsável, através de seus conhecimentos e experiências, com o auxilio dos processos de integração do PMBOK, ajustar o ciclo de vida e os processos de forma que haja interação entre eles. Um resumo exposto pelo PMBOK dos processos de integração apresenta os processos, os parâmetros de entrada e saída, e as ferramentas utilizadas (FIGURA 9). Ao todo são apresentados seis processos, sendo desenvolver o termo de abertura do projeto, desenvolver o plano de gerenciamento do projeto, orientar e gerenciar a execução do projeto, monitorar e controlar o trabalho do projeto, realizar o controle integrado de mudanças e encerrar o projeto ou fase.

27 27 Fonte: PMBOK FIGURA 9: Resumo dos processos de gerenciamento de integração de processos e atividades do PMBOK. 4.2 ENGENHARIA DE SOFTWARE Antigamente, por volta de 1950, os softwares começavam a ser projetados e desenvolvidos, sem seguir um roteiro específico, afirma PRESSMAN (2006). Com a evolução, softwares de computadores passaram a ser de grande relevância e utilizado em larga escala, seja para fins pessoais, corporativos, científicos, dentre outros.

28 28 Segundo PRESSMAN (2006), esta vasta utilização, tem gerado grande demanda de desenvolvimento de novas tecnologias e manutenção de softwares já existentes, tornando-se necessário a utilização de metodologias de projeto e desenvolvimento de software. Estas metodologias, por sua vez são praticamente um manual de boas práticas, tendo em vista que seu emprego não é uniforme em todos os casos, mas aqueles que utilizam, tem maior chance de obter sucesso, rapidez, qualidade, além de uma possível redução no orçamento e no cronograma, explica PRESSMAN (2006). Um sistema construído desta maneira possibilita atualizações, incrementos e manutenções de forma mais eficiente. Os conceitos do Guia de Gerenciamento de Projetos, o PMBOK, são relativos as metodologias de projeto e desenvolvimento de software, estas por sua vez sendo especificas para área, ao contrário do guia que é mais genérico Evolução da Engenharia de Software Segundo PRESSMAN (2006), as metodologias de projeto e desenvolvimento de software, são classificadas por ciclo de vida. Estes diversos tipos de ciclos de vida evolui com o passar do tempo e com as novas tecnologias de software e hardware, onde surgem novas metodologias e outras ficam para traz. Ainda conforme PRESSMAN (2006), o modelo cascata ou sequencial, uns dos primeiros a surgir, proposto em 1970 por Winston W. Royce prevê o gerenciamento do projeto e desenvolvimento de um software dividido em sete etapas, sendo estas executadas em uma sequencia, um modelo simples e de fácil planejamento, porém com problemas como, por exemplo, a impossibilidade de executar várias etapas simultaneamente. Este modelo serviu como base para os diversos outros modelos que surgiram com o passar do tempo, como por exemplo, modelos incrementais, evolucionários, baseado em componentes, processo unificado e o desenvolvimento ágil, este muito utilizado nos dias de hoje, afirma PRESSMAN (2006).

29 Processo Unificado - RUP (Rational Unified Process) KROLL e KRUCHTEN (2004) afirma que o modelo RUP (Rational Unified Process), foi criado pela Rational Software Corporation e posteriormente comprada pela IBM. Esta, assim como as demais metodologias, também fornece técnicas a serem seguidas por desenvolvedores de software a fim de melhorar sua produtividade. Esta metodologia de projeto e desenvolvimento de software é um processo unificado onde, explica KROLL e KRUCHTEN (2004), que suas bases são de natureza iterativa e incremental, guiada por casos de uso e centralizada na arquitetura. Além destas características fundamentais de um processo unificado, o modelo RUP, apresenta-se como bem definido e bem estruturado, definindo claramente quem é responsável pelo que no projeto, assim como o que deve ser feito e quando fazê-las. Segundo KROLL e KRUCHTEN (2004), o processo RUP provê ao projeto um ciclo de vida bem definido, definindo os pontos de decisão e os marcos essenciais. Além de tudo é um processo flexível, ou seja, suporta uma vasta variedade de processos, configurações ou criação de novos processos, sendo possível, desta maneira, ser utilizada por grandes ou pequenas equipes, ou mesmo empregada para pequenos, médios ou grandes projetos de software. A metodologia RUP utiliza a UML (Linguagem Unificada de Modelagem, em inglês Unified Modeling Language) para apoiar as práticas de engenharia de software orientada a objetos, especificando, modelando e documentando artefatos do projeto afirma PRESSMAN (2006). Cabe ainda ressaltar que a UML não fornece o arcabouço de processos para gerenciar as equipes de desenvolvimento de projetos, sendo esta uma linguagem muito utilizada atualmente Princípios do RUP Segundo MARTINS (2007), o modelo RUP se diferencia dos outros métodos iterativos por conter alguns princípios básicos característico que é atacar os riscos antecipadamente e continuamente, focar no software executável, certificar de entregar algo de

30 30 valor ao cliente, acomodar mudanças antecipadas, liberar um executável da arquitetura antecipadamente, construir o sistema com componentes, trabalhar junto como equipe e fazer da qualidade um estilo de vida, não deixando para depois. Um princípio muito importante da metodologia RUP é o foco na garantia da qualidade dos seus processos, buscando alcançar a qualidade de software desenvolvido, afirma KRUTCHEN Elementos do RUP A metodologia de desenvolvimento e projeto de software RUP, segundo KROLL e KRUCHTEN (2004) possuem cinco elementos principais. O primeiro são os papéis, que define o comportamento e as responsabilidades de uma pessoa ou grupo envolvido no projeto, desta forma destaca-se quatro papéis, sendo o desenvolvedor, analista, testador e gerente de projetos. Já as atividades, compreendem em unidades de trabalho realizado por um individuo envolvido no projeto, gerando resultados importantes para o projeto. O terceiro elemento é chamado de artefato, compreendido em um pedaço de informação que é produzido, modificado ou utilizado em um processo do desenvolvimento do projeto. Os artefatos são agrupados conforme as disciplinas, poderá ser visto com mais detalhes no item , disciplinas e artefatos do RUP. KROLL e KRUCHTEN (2004) definem que o quarto elemento é uma sequência de atividades, chamado de fluxo de trabalho, este gera resultados importantes para o projeto e podem ser representados por diagramas de sequência, diagramas de colaboração e diagramas de atividades da linguagem UML. O RUP apresenta três tipos de fluxo de trabalho: os fluxos principais que são associados as disciplinas, os fluxos de trabalho de detalhe que detalha cada fluxo de trabalho principal, e os planos de iteração que mostram como a iteração deverá ser executada (FIGURA 10).

31 31 Fonte: FIGURA 10: Exemplo de fluxo de trabalho principal. As disciplinas, conforme MARTINS (2007), é uma coleção de atividades relacionadas, fazendo parte do contexto do projeto, sendo este o quinto elemento do RUP. A divisão, ou o agrupamento das atividades em disciplinas traz um melhor entendimento do projeto, porém dificulta no momento do planejamento Disciplinas e artefatos do RUP Como vimos as disciplinas, assim como os artefatos são elementos do RUP e as disciplinas estão divididas em um total de nove.

32 32 Os artefatos, como já explicitado, podem ser de diversos tipos, documentos, códigos fonte, modelos, dentro outros, sendo que este podem ser produzidos pela execução de um processo ou fase do projeto, e utilizado como entrada de um outro processo, tudo conforme a integração dos processos de gerenciamento afirma KROLL e KRUCHTEN (2004). Os artefatos dos RUP (FIGURAS 11, 12, 13, 14, 15, 16, 17, 18, 19) são dispostos conforme as disciplinas apresentadas a seguir: a) Modelagem de negócios Fonte: Figura 11: Artefatos da disciplina de modelagem de negócios.

33 33 b) Requisitos Fonte: FIGURA 12: Artefatos da disciplina de requisitos. c) Análise Fonte: FIGURA 13: Artefatos da disciplina de analise.

34 34 d) Implementação Fonte: FIGURA 14: Artefatos da disciplina de implementação. e) Teste Fonte: FIGURA 15: Artefatos da disciplina de teste.

35 35 f) Distribuição Fonte: FIGURA 16: Artefatos da disciplina de distribuição g) Configuração e gerenciamento de mudanças Fonte: FIGURA 17: Artefatos da disciplina de configuração e gerenciamento de mudanças.

36 36 h) Gerenciamento de projetos Fonte: FIGURA 18: Artefatos da disciplina de gerenciamento de projetos. i) Ambiente

37 37 Fonte: FIGURA 19: Artefatos da disciplina de ambiente Ciclo de Vida do RUP O modelo RUP, segundo KROLL e KRUCHTEN (2004) apresentam quatro fases em seu ciclo de desenvolvimento. A primeira fase, nomeada de iniciação ou concepção, foca no tratamento de riscos relacionados aos casos de negócio, comunicação com o cliente e planejamento. Nesta fase são gerados casos de uso preliminares. A quantificação dos riscos do projeto é uma prioridade, e é essencial, tendo em vista que enfatiza a qualidade do produto e auxilia nas tomadas de decisão quanto a viabilidade e a possibilidade financeira de implementação do projeto.

38 38 Já a segunda fase, a elaboração, além da comunicação do cliente, os riscos técnicos e arquiteturais do projeto são enfatizados, descreve KROLL e KURCHTEN. Durante esta segunda fase do projeto, o escopo, e os requisitos é revisado e aprimorado, gerando um modelo genérico de processo. Os casos de uso são expandidos, possibilitando garantir que o escopo, os riscos e os prazos permaneçam equilibrados. Segundo KROLL e KRUCHTEN (2004), a fase de construção consiste na implementação do projeto. Usando o modelo gerado nas fases anteriores, esta fase desenvolve o software, ou componentes deles, tornando os casos de uso utilizáveis pelo interessados no produto. Em sua última fase, a chamada transição, KROLL e KRUCHTEN (2004) afirmam que o RUP engloba as últimas atividades de construção e inicia a implantação. A versão do software é entregue aos usuários, o software começa ser utilizado e é acompanhado com rotinas de teste e através de relatórios dos interessados, para que em caso de necessidade de modificações ou defeitos seja iniciado um novo ciclo para correção. Segundo KROLL e KRUCHTEN (2004), por se tratar de uma metodologia iterativa e incremental, o término das quatro fases do ciclo de vida não significa que o software está em sua versão final, pois o ciclo pode iniciar novamente pelo fato de que foram encontrados defeitos, há novas necessidades ou mesmo pela alteração da tecnologia empregada. Quando um ciclo é concluído, uma versão do produto é lançada (FIGURA 20).

39 39 Fonte: FIGURA 20: Ciclo de vida do RUP. Por tratar de um sistema já desenvolvido em uma primeira versão, KRUCHTEN (2004) afirma que as fases de iniciação e elaboração são bem menores, pelo fato de que a arquitetura e as definições básicas do produto já foram determinadas anteriormente.

40 Arquitetura Geral do RUP MARTINS (2007) define a arquitetura geral da metodologia da Rational como possuindo duas dimensões conforme a figura 21. Fonte: FIGURA 21: Arquitetura geral do RUP. Conforme MARTINS (2007), no eixo vertical, ficam agrupadas as disciplinas, de maneira lógica, este representa as atividades do processo, em relação ao tempo, que por sua vez esta situada no eixo horizontal do gráfico. Observa-se também as fases e a incidência de trabalho sobre cada disciplina do projeto em relação ao tempo.

41 Produtos de trabalho do RUP Segundo PEARSON, as fases do desenvolvimento de projetos geram produtos (FIGURA 22), onde o produto de uma fase torna a entrada de outra. Sendo assim, a fase da iniciação prevê estabelecer uma visão global do projeto, sendo utilizado para isso documentos chamados casos de uso. Os casos de uso descrevem os atores do software, ou seja, as pessoas que irão interagir com o software, além das características das funcionalidades do produto. À medida que o projeto avança em seu desenvolvimento, os casos de uso são aprimorados afirma PEARSON. Na fase da elaboração, é produzido um conjunto de produtos que abordam os requisitos (funcionais e não funcionais), descrição arquitetural e um projeto preliminar. A etapa de construção do projeto produz um modelo de implementação, que traduz as classes dos objetos gerados na etapa anterior, em componentes de software que serão construídos afirma PRESSMAN (2006). Há também além do modelo da implementação o modelo de implantação que especifica os componentes físicos de informática do ambiente. Por fim, está etapa ainda utiliza um modelo de teste que é utilizado para garantir que os casos de uso sejam implementados adequadamente. PRESSMAN (2006) descreve que o encerramento de um ciclo de vida do projeto, a fase de transição, produz a medida que os usuários finais utilizam o software, relatórios de testes e de solicitações de modificações.

42 42 Fonte: PRESSMAN FIGURA 22: Produtos de Trabalho do RUP Desenvolvimento Ágil - Scrum A metodologia de desenvolvimento e projeto de software Scrum é uma metodologia de característica ágil. PRESSMAN (2006) afirma ainda que o Movimento Ágil iniciou em 2001 por Kent Beck e outros dezesseis profissionais da área. Devido a rápida evolução da informática e do mundo atual, houve a necessidade de agilizar o desenvolvimento de novos ou atualizações de softwares, a fim de acompanhar a evolução rápida e continua do mundo. As metodologias baseadas no desenvolvimento ágil, diferente das convencionais, foca na valorização das iterações, dos indivíduos, software funcionando e não na longa documentação, colaboração com o cliente e não negociações de contratos e atividades de acordo com as respostas de modificações sem utilização de um plano, explica PRESSMAN (2006). A engenharia de software ágil, conforme PRESSMAN (2006), combina algumas diretrizes de desenvolvimento e uma filosofia que encoraja, por parte do cliente, a sofisticação e a entrega incremental do software. As equipes de desenvolvimento também são altamente

43 43 motivadas, utilizando métodos informais e documentação de engenharia de software mínimos, resultando em um desenvolvimento simplificado. Há comunicação continua entre os desenvolvedores e os clientes. Segundo a perspectiva de PRESSMAN (2006) afirma que os engenheiros de softwares e os demais interessados no projeto trabalham juntos no desenvolvimento do projeto, formando uma equipe, sendo está auto organizada e controlando seu próprio destino. Este tipo de desenvolvimento não é aplicável à todos os projetos de software, apesar de fornecer benefícios importantes. Ainda, segundo PRESSMAN (2006), as atividades básicas da engenharia de software, a comunicação com o cliente, o planejamento, a modelagem, construção, entrega e avaliação continuam, porém foram reduzidas ao tamanho mínimo de tarefas. Neste modelo de desenvolvimento, o produto gerado é o incremento de software, ou seja, uma versão do software, tendo em vista que não há utilização de muitos documentos neste modelo expõem PRESSMAN (2006). A equipe de desenvolvimento ao final de uma interação, verifica se o software atende as necessidades e é entregue ao cliente. Um processo de desenvolvimento ágil, assim como o RUP pode ter várias interações, e a cada uma delas é gerada uma versão do produto. Scrum é um modelo de desenvolvimento ágil. O nome é derivado de uma atividade que ocorre durante um jogo rugby, onde os jogadores se aproximam da bola, e em equipe movimentam a bola explica PRESSMAN (2006). Este modelo foi desenvolvido por Jeff Sutherland e por sua equipe no inicio da década de 1990, antes do Movimento Ágil Princípios do Scrum Assim como descrito anteriormente, quanto ao Movimento Ágil, o Scrum é compatível, descreve PRESSMAN (2006), quanto aos princípios do Scrum, que consiste no trabalho organizado em pequenas equipes, priorizando a comunicação entre os membros, minimização da supervisão e maximização da troca de conhecimentos de formas informais.

44 44 Outro princípio exposto por PRESSMAN (2006) é a garantia de que seja produzido o melhor produto possível, para isso é necessária a flexibilidade de adaptação do processo, tanto as modificações técnicas como de negócios. Assim como o modelo RUP, é produzido por este processo várias versões do software, ou parte deles, que possibilita teste, modificação, expansão e documentação. No Scrum o trabalho é particionado, o trabalho e o pessoal são divididos, incumbindo cada pessoa com uma parte do trabalho explica PRESSMAN (2006). À medida que o produto é construído, são elaborados documentos e testes são realizados constantemente. O processo Scrum não impede a equipe, o cliente, ou o gerente de declarar que o produto está pronto a qualquer momento do desenvolvimento, fato este que pode ocorrer pela necessidade do cliente, necessidade financeira da empresa, prazo de entrega esgotado, por exemplo. Estes princípios do modelo servem para conduzir as atividades de desenvolvimento, afirma PRESSMAN (2006). Assim como as metodologias convencionais, o Scrum tem suas atividades principais, sendo chamadas de requisitos, análise, projeto, evolução e entrega Ciclo de Vida do Scrum O modelo Scrum, por ser de natureza iterativa e incremental tem um ciclo de vida semelhante ao da metodologia RUP já estudada. PRESSMAN (2006) afirma que em cada uma das atividades principais, o desempenho das tarefas é realizado conforme um padrão de processo, chamado de Sprint (FIGURA 23).

45 45 Fonte: FIGURA 23: Ciclo de vida do Scrum. Tendo em vista que o trabalho é conduzido dentro de uma Sprint, dependendo do tamanho e complexidade do projeto, o número de sprints, para cada atividade básica, varia, assim como as adaptações e modificações, que é realizada em tempo real pela equipe do Scum, afirma PRESSMAN (2006). Ainda, segundo PRESSMAN (2006), o modelo de desenvolvimento Scrum, prioriza a utilização de padrões de processo de software, pelo fato de que nos projetos que, o tempo de entrega é curto, ou sofrem muitas mudanças nos requisitos e nos planos de negócios, estes padrões se mostram eficazes. PRESSMAN (2006) afirma que cada um desses padrões define um conjunto de atividades de desenvolvimento chamadas de pendência, sprints, reuniões Scrum e demos. As pendências consistem em uma lista que contém as características e os requisitos do projeto. Esta lista de pendências é o que fornece o valor de negócio ao cliente. As pendências podem ser alteradas a qualquer momento do projeto, podendo ser inseridas novas necessidades ou modificações, e o gerente de produto examina e atualiza a lista conforme o desenvolvimento do projeto. As sprints, por sua vez, são unidades de trabalho necessárias para desenvolvimento de uma pendência, tendo um intervalo de tempo predefinido para ser finalizada. PRESSMAN (2006) ainda expõem que durante a execução de uma Sprint, as demais pendências são

46 46 travadas, para que não haja alteração nos requisitos durante o desenvolvimento de uma Sprint, tornando o ambiente mais estável. Diariamente, é realizada uma reunião com a equipe, tendo duração aproximada de quinze minutos afirma PRESSMAN (2006). Praticamente, as reuniões abordam três itens, sendo o que cada um realizou desde a última reunião, que obstáculos estão encontrando e o que pretende até a próxima reunião. As reuniões são dirigidas pelo líder da equipe, o chamado Scrum master, sendo ele que avalia as respostas de cada um para os três itens abordados. Ainda segundo PRESSMAN (2006) as reuniões ajudam a equipe a encontrar os problemas, o mais breve possível, promove um compartilhamento de conhecimento e promove uma auto organização na equipe. PRESSMAN (2006) descreve os demos como sendo a entrega de uma versão do software ao cliente, de modo que o cliente possa visualizar e trabalhar com esta versão. Cabe ressaltar que essas versões podem não contemplar totalmente os requisitos do projeto, porém algumas funções já podem ser utilizadas. PRESSMAN (2006) concluiu que a utilização do Scrum permite a equipe desenvolvimento trabalhar em projetos de forma a conquistar o sucesso no mundo atual, onde existe muitas incertezas, e a evolução da tecnologia da informação acontece rapidamente. A metodologia Scrum, segundo SCHWABER e SUTHERLAND (2012) utiliza uma única fonte de requisitos para o projeto, sendo este o documento chamado de Backlog do produto. Este documento consiste em uma lista ordenada contemplando tudo que pode ser útil para o produto final. O documento evoluí assim como o projeto e a cada iteração ele é atualizado.

47 47 5 COMPARAÇÃO QUALITATIVA E QUANTITAVIA ENTRE OS MÉTODOS. As metodologias abordadas na revisão bibliográfica, apresentam características específicas, sendo elas favoráveis ou desfavoráveis a sua aplicação na engenharia de software. As metodologias RUP e Scrum, conforme itens e 4.2.3, apresentam princípios semelhantes, ambas de natureza iterativa e incremental, podendo ser facilmente adaptadas ao projeto ao qual foi empregada, porém temos o Scrum como uma metodologia ágil. Sendo assim, ao tempo que o RUP é uma metodologia pesada, com a utilização de muitos documentos, o Scrum é simples, utilizando o mínimo de documentação para o desenvolvimento de projetos, conforme descrito nos itens e Segundo KROLL e KRUCHTEN (2004), além da documentação, a metodologia RUP define o papel de cada pessoa dentro do desenvolvimento do projeto, onde cada integrante da equipe tem uma função, equipes que geralmente são formadas por muitos membros, diferentemente do Scrum, que preza pelas pequenas equipes, havendo a necessidade dos profissionais membros da equipe serem altamente qualificados, podendo ser incumbido de várias tarefas, explica PRESSMAN (2006), isso faz com que todos os integrantes da equipe estejam sempre empenhados e em todas as fazes do projeto, o que não ocorre na metodologia RUP. PRESSMAN (2006), também cita que no Scrum o projeto é desenvolvido por meio de negociações, ou reuniões com o cliente, já no RUP, segundo KROLL e KRUCHTEN (2004), as etapas, ou modificações do projeto são realizadas tudo por meio de contratos o que acaba aumentando o tempo de vida do projeto. Os autores PRESSMAN (2006), KROLL e KRUCHTEN (2004), afirmam que no RUP as iterações são ajustáveis ao tamanho do escopo, recursos e prazos do projeto, diferente do Scrum que tem suas iterações com tempo determinado de duas a quatro semanas. Tratando de um método ágil, como vimos, o Scrum preza o produto funcionando, não enfatizando a documentação, o que faz com que a especificação detalhada inicial raramente seja produzida, diferente do método RUP, onde primeiramente constrói-se os documentos de especificação, fazendo com que seja possível fazer estimativas com certa precisão referente ao projeto, o que não ocorre na metodologia ágil, onde é possível fazer estimativas somente com o transcorrer do projeto, explica MARTINS (2007).

48 48 Ainda conforme MARTINS (2007), na metodologia RUP é possível obter informações dos estados internos de cada processo da metodologia que esta sendo executado, promovendo um melhor entendimento dos trabalhos internos. Esse entendimento, de certa forma requer um amplo e acurado conhecimento do processo, já no Scrum, não é possível obter informações detalhadas sobre um processo, mas sim de uma parte dela, pois este método trata o processo como se fosse uma caixa fechada. MARTINS (2007) ainda expõem que diferentemente ao RUP que exige um entendimento acurado sobre um processo, o Scrum não requer conhecimento detalhado, pois os resultados esperados podem ser obtidos através de algumas mudanças. Quando trabalha-se com a metodologia Scrum há uma grande incidência de mudanças não esperadas no projeto, fazendo com que tenha que ser empregada muitas adaptações, ao contrário do método RUP, que as mudanças são previstas, e raramente ocorrem mudanças que não foram planejadas no início do projeto, coloca MARTINS (2007). MARTINS (2007) ainda explica que a metodologia de desenvolvimento RUP é recomendada aos projetos de baixa complexidade e bem compreendido, pois estes podem ser estudados e bem planejados com esta metodologia. Já para os projetos de alta complexidade e também poucos compreendidos aconselha-se a utilização da metodologia Scrum, pois não foca muito no planejamento, mas sim a resposta a mudanças. Entretanto, cada metodologia há pontos bons e outros ruins, valendo ressaltar também, que para uma avaliação de desempenho de uma metodologia, deve ser levado em consideração não só os processos das metodologias, mas sim o projeto e a maneira que a metodologia esta sendo aplicada. No mundo da Engenharia de Software, há muitos que argumentam sobre qual seria a melhor metodologia, porém nenhum método individual dominou a área, explica PRESSMAN (2006).

49 49 6. PROPOSTA DA UNIFICAÇÃO DAS METODOLOGIAS Inicialmente, vale ressaltar que há uma caracterização dos métodos estudados a fim de implementar novos princípios, desta forma, esta unificação das metodologias apoia-se nos melhores recursos e características dos modelos RUP e Scrum, assim como no Guia de Gerenciamento de Projetos (PMBOK), conforme o capítulo 4, de realizando uma releitura das metodologias e práticas de gerenciamento de projetos. A proposta será chamada de Processo Unificado Ágil. Levando em consideração o cenário atual da Engenharia de Software, este método tem seu ciclo de vida iterativo e incremental, assim como as demais metodologias estudadas (capítulo 4). Este ciclo de vida foi adotado pelo fato de que a natureza incremental gera uma nova versão do produto a cada iteração como podemos ver na Figura 24. Já tratando de um ciclo de vida iterativo, significa que o ciclo de vida completo do projeto é dada através de outros pequenos ciclos, onde cada um gera resultados diferentes. FIGURA 24: Ciclo de vida da metodologia Processo Unificado Ágil.

50 50 Desta forma, é possível entregar versões de software, funcionando, a fim de atender as necessidades mais urgentes do cliente em menor tempo, ou mesmo para teste da aplicação por parte do cliente, para que nas próximas iterações do projeto esses problemas sejam resolvidos, atendendo as necessidades do mesmo e do negócio, ou mesmo solucionando problemas de codificação. Uma característica muito importante e de certa forma, essencial para uma boa metodologia de gerencia de projeto, é a flexibilidade. Esta característica possibilita que a metodologia seja aplicada em diversos e nos mais diferentes projetos, sendo de grande ou pequeno porte, complexo ou simples. Como já foi dito, as metodologias são boas práticas de gerencia de projetos (capítulo 4), desta forma, não há a obrigatoriedade de ser aplicada uniformemente em todos os projetos, pois já é conhecido que não é aplicável no mundo real. Sendo assim, esta metodologia pode ser adaptada conforme necessidade e conhecimento do próprio gerente do projeto, adotando utilizar ou não, ou até mesmo modelar os processos e as disciplinas conforme a aplicação PAPÉIS Esta metodologia de desenvolvimento de software propõem quatro principais papéis dentro do projeto, semelhante a metodologia Scrum, sendo o cliente, gerente de projetos, assistente comercial e a equipe de desenvolvedores. O cliente, é a pessoa responsável em representar a companhia interessada no projeto perante ao assistente comercial, gerente de projetos e a equipe de desenvolvimento, de forma a descrever as necessidades, negociar prazos, recursos, escopo e qualidade do produto final. O assistente comercial também estará envolvido em todo o desenvolvimento do projeto, porém de forma não técnica e indireta. Este agente, tem como principal função a negociação com o cliente em relação aos recursos e custos do projeto. Um outro papel importante no desenvolvimento do projeto é o gerente de projetos, que participa diretamente e indiretamente em todo o ciclo de vida do projeto, com foco principal nas fases de iniciação, planejamento e gerenciamento do projeto. Esta pessoa deve ter um conhecimento técnico e ao mesmo tempo um conhecimento abstrato, gerencial.

51 51 A equipe de desenvolvedores, também participa de praticamente todas as fases do projeto, porém no gerenciamento do projeto não têm participação direta. A equipe é formada por profissionais de diversas especialidades técnicas, e esta equipe na fase de planejamento é dividida em equipes menores conforme a especialização profissional. 6.2 OS GRUPOS DE PROCESSOS DA METODOLOGIA PROCESSO UNIFICADO ÁGIL Assim como as demais metodologias e o guia de gerenciamento de projetos (capitulo 4), esta metodologia esta dividida em grupos de processos de gerenciamento, como podemos observar na figura 24. Os processos de cada grupo do ciclo de vida, devem interagir entre si, sendo que muitos deles é pré-requisito para outros. Desta forma, documentos ou dados gerados em um processo pode ser utilizado por outro processo do próprio grupo ou dos demais grupos. Essa característica da metodologia poderá ser observada nos próximos tópicos que evidenciará os processos internos as fases do ciclo de vida, ou grupos de processos Grupo de processos de inicialização A fase de iniciação do projeto compreende principalmente na comunicação com o cliente, formalizando o desenvolvimento do projeto através de contratos e documentos de marketing. Deve ser avaliado e estimado nesta fase a viabilidade, riscos, recursos necessários e tempo de desenvolvimento do projeto (FIGURA 25).

52 52 FIGURA 25: Grupo de processos de inicialização. Nesta fase do projeto, temos uma grande atuação do assistente comercial nas negociações e do gerente de projetos que tem a capacidade de avaliar e estimar o projeto Grupo de processos de planejamento Já a segunda fase do ciclo de vida, temos o planejamento, que é dividido em duas etapas (FIGURA 26). A primeira, é responsável em definir os aspectos genéricos, como definição dos atores do projeto, escopo, tempo, custo, qualidade e riscos, através do levantamento de requisitos e modelagem de negócios, a fim de elaborar o documento de especificações de requisitos (Anexo A). Esta primeira fase é muito importante, pois um planejamento e a coleta de requisitos bem realizada, poderá minimizar a incidência de mudanças que poderão ocorrer durante o desenvolvimento do projeto.

53 53 FIGURA 26: Grupo de processos de planejamento. As especificações de requisitos, é um documento formal que descreve as necessidades do cliente, devendo constar o máximo de informações possíveis a respeito do ambiente atual e futuro a implantação do software, como funciona o atual sistema, funcionalidades do software a ser desenvolvido, regras de negócios e políticas da empresa. Esse documento de requisitos deve ser aprovado pelo cliente, para que não haja incompatibilidades do produto final com as necessidades da empresa. Com as especificações de requisitos aprovadas, a equipe, orientada e supervisionada pelo gerente de projetos, irá adequar os requisitos especificados conforme as técnicas, lógicas, linguagens de programação e ferramentas que serão empenhadas na codificação, gerando assim o documento de especificação técnica. As especificações técnicas, descreve as funcionalidades do sistema individualmente, sendo que deve abordar quem são os atores que estarão relacionados a funcionalidade, descrição e modelagem dos dados, regras de negócio, fluxo principal, fluxos alternativos e fluxos de exceção (Anexo B).

54 54 A segunda etapa do planejamento, através do conceito de Backlog da metodologia Scrum (capítulo 4), as especificações técnicas serão seccionadas gerando os itens do Backlog, e esses itens serão distribuídos por áreas de conhecimento (FIGURA 27). As especialidades para seleção dos itens, poderão ser atribuídas pelo gerente de projetos, que adotará os grupos conforme o projeto e sua equipe de desenvolvedores. Para essa divisão em áreas de conhecimento, poderá ser levado em consideração características em comum dos itens e área técnica, como por exemplo existência de um grupo referente a banco de dados, outro referente a aplicação que pode ser subdividido conforme módulos do sistema ou conforme as especificações técnicas. FIGURA 27: Planejamento da construção do projeto - Backlog. Cada área de conhecimento, terá os itens de Backlog dispostos pelo gerente de projetos, na forma de fila (primeiro a entrar, primeiro a sair), para que o desenvolvimento dos itens aconteça de forma sequencial. Assim como no Scrum, cada um dos itens, terá sua graduação de complexidade (pontos), prioridade, adiciona-se a eles uma estimativa de tempo para a construção do item e uma identificação, contendo a identificação da área do conhecimento e um número, sequencial conforme a fila. Esta estimativa é realizada com toda a equipe, onde será exposto e discutido a opinião de todos em relação aos itens individualmente. Tendo os itens de Backlog dispostos em fila e com estimativa de tempo, teremos o desenvolvimento do projeto de forma sequencial e com referencias cronológicas, o que possibilita melhor controle de prazo pelo gerente de projetos.

55 55 Finalizando o planejamento, a equipe deverá ser dividida em equipes menores, conforme a especialidade profissional dos integrantes, relacionando as especialidades ao qual os itens de backlog foram distribuídos Grupo de processos de construção A fase de construção do projeto, contempla genericamente a codificação do software, onde os itens gerados na segunda fase do planejamento serão codificados e testados (FIGURA 28). Assim como descrito no planejamento, os itens deverão ser implementados de acordo com a sequencia planejada em cada especialidade, focando finalizar a implementação do item conforme a estimativa de tempo. FIGURA 28: Grupo de processos de construção. As instruções de programa que representam os itens de backlog já codificados, deverão ser integrados aos outros conforme o transcorrer da construção do software, de modo a interagirem entre si, constituindo um só software ou versão dele. Ao término da codificação de cada item, é recomendável que estes sejam testados de forma individual, para que na possível existência de erros, facilite encontrá-los e repará-los.

56 Grupo de processos de transição A fase de transição, tem o nome adotado por ser o mais sugestivo para o grupo, sendo o mesmo nome utilizado pela metodologia RUP, porém havendo diferenças. Este contempla a realização dos testes finais, implantação e avaliação pelo cliente do produto final ou versão (FIGURA 29). FIGURA 29: Grupo de processos de transição. Os testes, inicialmente deverão ser realizados pela equipe do projeto, simulando o ambiente real e analisando os dados de saída do sistema. Uma segunda rotina de teste, homologação, deve ser realizada pelos atores do sistema, os usuários. Geralmente estes testes são realizados em um ambiente específico, instalado no cliente, para a homologação, ambiente este o mais próximo do real possível. Aprovado nos testes, o produto ou a versão será implantado no ambiente principal do cliente, tecnicamente chamado de ambiente de produção. A implantação, consiste na entrega oficial do software e sua documentação, configuração e instalação. Conforme o contrato com o cliente pode haver treinamento dos usuários para utilização do sistema durante a implantação.

57 Processos de gerenciamento do projeto Neste modelo proposto, assim como o PMBOK (capitulo ), este grupo tem a visão geral do andamento do projeto, além de controlar o ciclo de vida do projeto, integração entre os processos, mudanças, escopo, prazos, custos, qualidade, comunicação, riscos e demais recursos necessários ao desenvolvimento do projeto (FIGURA 30). FIGURA 30: Grupo de processos de gerenciamento do projeto. Para o bom desenvolvimento do projeto, é necessário comunicação entre os envolvidos no mesmo, tal que é essencial haver a comunicação entre o gerente de projetos com o cliente e com a equipe. Desta forma, há a necessidade de ser realizadas pequenas reuniões periódicas, de curta duração, com a equipe, para verificar o andamento do projeto e como a equipe está se comportando frente ao projeto. Estas pequenas reuniões podem ocorrer a qualquer momento no transcorrer do dia, podendo ser no próprio local de desenvolvimento do software, sem nenhuma formalidade. É recomendável que seja realizada ao menos uma vez a cada quarenta e oito horas.

58 58 Quando a iteração de desenvolvimento está transitando de uma fase a outra, há a necessidade de ser realizada uma reunião, formal, refinando e ajustando o que foi e o que será realizado, e de que forma irá transcorrer. Esta, como já esperado, poderá ter duração aproximada de uma hora e meia, e deve ser realizada em um ambiente propício onde possa reunir toda a equipe. Neste grupo de processos também ressaltamos o controle de mudanças, essas que podem ter grande incidência no transcorrer de toda iteração, principalmente durante a construção e a transição. O controle de mudanças deve ser realizado em todo o ciclo de vida do projeto. Essas mudanças, podem ser simples ou complexas. As mudanças simples, conforme orientação do gerente do projeto, poderá ser realizada durante a própria fase e nesta mesma iteração. Já as mudanças de maior complexidade, na maior parte das vezes, necessitará de comunicação e intervenção do cliente e possivelmente do assistente comercial, para que seja planejada e realizada, em uma nova iteração. Desta forma é feito um levantamento da necessidade de mudanças é elaborado o documento de gerenciamento de mudanças (Anexo C), para que estas sejam revistas em uma próxima iteração do projeto. Podemos destacar também neste grupo de processos o gerenciamento da integração entre os processos da metodologia. Inicialmente deve ser levado em consideração as entradas e saídas dos processos, ou seja, os dados ou conhecimentos utilizados na execução de um processo, e os resultados gerados por ele. Geralmente as entradas de um processo é o resultado da execução de outro processo. Desta maneira, os processos interagem entre si, mesmo estando em grupos distintos, porém cabe ao gerente de projetos adequar a execução dos processos conforme o projeto. De certa forma esta integração está evidenciada na descrição dos grupos de processos, porém, tratando de uma metodologia flexível, cabe ao gerente coordenar de que forma esses processos serão executados. Como descrito na introdução da proposta, esta metodologia tende a proporcionar flexibilidade ao gerenciamento de projetos de desenvolvimento de software, possibilitando que o gerente aplique seus conhecimentos e habilidades, de forma a modelar e adaptar a

59 59 metodologia, os processos e a integração dos processos da maneira que atinja o desempenho esperado. 6.3 BENCHMARK DOS PROCESSOS DA METODOLOGIA PROCESSO UNIFICADO ÁGIL Conforme a arquitetura da metodologia proposta, foi elaborado o gráfico (FIGURA 31), apresentando uma referência quanto a execução dos principais processos ou grupos durante uma iteração do projeto. FIGURA 31: Benchmark dos principais processos e grupos. Como pode-se observar, temos na vertical a representação dos processos da metodologia em relação ao tempo de duração da iteração do projeto, representado na horizontal. Desta forma podemos observar o tempo e as fases em que os processos apresentam atividades.

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

GERÊNCIA DE RISCOS E ESCOPO EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE

GERÊNCIA DE RISCOS E ESCOPO EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE GERÊNCIA DE RISCOS E ESCOPO EM PROJETOS DE DESENVOLVIMENTO DE SOFTWARE Viviana Regina Weber 1 Anderson Yanzer Cabral 2 RESUMO O presente artigo tem como objetivo apresentar uma pesquisa, em desenvolvimento,

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

PMBOK 4ª Edição I. Introdução

PMBOK 4ª Edição I. Introdução PMBOK 4ª Edição I Introdução 1 PMBOK 4ª Edição Um Guia do Conhecimento em Gerenciamento de Projetos Seção I A estrutura do gerenciamento de projetos 2 O que é o PMBOK? ( Project Management Body of Knowledge

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com.

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com. ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS (CASE STUDY: SCRUM AND PMBOK - STATES IN PROJECT MANAGEMENT) Aline Maria Sabião Brake 1, Fabrício Moreira 2, Marcelo Divaldo Brake 3, João

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

www.plathanus.com.br

www.plathanus.com.br www.plathanus.com.br A Plathanus Somos uma empresa com sede na Pedra Branca Palhoça/SC, especializada em consultoria e assessoria na criação e desenvolvimento de estruturas e ambientes especializados com

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK

Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK 180 - Encontro Anual de Tecnologia da Informação Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK Thiago Roberto Sarturi1, Evandro Preuss2 1 Pós-Graduação em Gestão de TI Universidade

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro:

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro: Gerenciamento de Projetos Teoria e Prática Totalmente de acordo com a 4 a Edição/2009 do PMBOK do PMI Acompanha o livro: l CD com mais de 70 formulários exemplos indicados pelo PMI e outros desenvolvidos

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS Atualizado em 31/12/2015 GESTÃO DE PROJETOS PROJETO Para o PMBOK, projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Leia mais

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3.

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3. 02m Conteúdo Apresentação do PMBOK Brasília, 25 de Junho de 2015 Fase 01 1.PMBOK e PMI 2. Conceitos 3.Processos Fase 02 4. Áreas de Conhecimento 10m Gerenciamento de Projetos Projeto A manifestação da

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Grupo de Consultores em Governança de TI do SISP 20/02/2013 1 Agenda 1. PMI e MGP/SISP 2. Conceitos Básicos - Operações e Projetos - Gerenciamento de Projetos - Escritório de

Leia mais

Gerenciamento de Projetos Web. Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu.

Gerenciamento de Projetos Web. Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu. Gerenciamento de Projetos Web Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu.br/frufrek Possui Especialização em Engenharia de Software e Banco de Dados pela

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos. Prof.: Franklin M. Correia

Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos. Prof.: Franklin M. Correia 1 Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos Prof.: Franklin M. Correia Na aula anterior... Metodologias ágeis Princípios do Manifesto ágil 12 itens do manifesto

Leia mais

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Ferramenta web para gerenciamento de projetos de software baseado no Scrum Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Introdução Roteiro da apresentação Objetivos do trabalho Fundamentação

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

Como concluir um projeto com sucesso?

Como concluir um projeto com sucesso? Como concluir um projeto com sucesso? Luiz Eduardo Cunha, Eng. Professor da FAAP e do IMT 1 Luiz Eduardo Cunha Graduado em Engenharia de Produção EPUSP Pós-Graduado em Gestão do Conhecimento e Inteligência

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais

2 Jogos Educacionais. 2.1.Visão Geral de Jogos Educacionais 2 Jogos Educacionais Jogos estão presentes como uma prática habitual, eles tem sido concebidos como uma atividade lúdica que é bastante motivadora no processo de ensinoaprendizado. É assim que jogos educacionais

Leia mais

Metodologia de Gerenciamento de Projetos da Justiça Federal

Metodologia de Gerenciamento de Projetos da Justiça Federal Metodologia de Gerenciamento de Projetos da Justiça Federal Histórico de Revisões Data Versão Descrição 30/04/2010 1.0 Versão Inicial 2 Sumário 1. Introdução... 5 2. Público-alvo... 5 3. Conceitos básicos...

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Cartilha. Gestão de Projetos. Superintendência de Planejamento e Gestão SUPLAN Ministério Público do Estado de Goiás

Cartilha. Gestão de Projetos. Superintendência de Planejamento e Gestão SUPLAN Ministério Público do Estado de Goiás Cartilha Gestão de Projetos SUPLAN Ministério Público do Estado de Goiás Esta cartilha tem como objetivo transmitir os conceitos básicos relacionados ao Gerenciamento de Projetos e compartilhar da metodologia

Leia mais

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SIG Aula N : 11 Tema: Como desenvolver e

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

Aula 3 Fase de Iniciação de projetos

Aula 3 Fase de Iniciação de projetos Aula 3 Fase de Iniciação de projetos Objetivos da Aula: Os objetivos desta aula são, basicamente, apresentar as atividades que constituem a fase inicial dos projetos. Alem disso, vamos discorrer sobre

Leia mais

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos.

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos. A GESTÃO DE PROJETOS EXISTENTE NA NORMA DO-178B Matheus da Silva Souza, matheusdasilvasouza@gmail.com Prof. Dr. Luiz Alberto Vieira Dias, vdias@ita.br Instituto Tecnológico de Aeronáutica Praça Marechal

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

04/02/2009. Curso Superior de Tecnologia: Redes de Computadores. Disciplina: Gestão de Projetos de TI. Prof.: Fernando Hadad Zaidan. Unidade 1.

04/02/2009. Curso Superior de Tecnologia: Redes de Computadores. Disciplina: Gestão de Projetos de TI. Prof.: Fernando Hadad Zaidan. Unidade 1. Faculdade INED Curso Superior de Tecnologia: Redes de Computadores Disciplina: Gestão de Projetos de TI Prof.: Fernando Hadad Zaidan 1 Unidade 1.1 2 Introdução ao Gerenciamento de Projetos 3 1 Leitura

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas

Leia mais

PROJETO DE FÁBRICA DE SOFTWARE

PROJETO DE FÁBRICA DE SOFTWARE FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação PROJETO DE FÁBRICA DE SOFTWARE Denise Xavier Fortes Paulo Afonso BA Agosto/2015 Sumário 1. INTRODUÇÃO... 3 2. PERFIS FUNCIONAIS...

Leia mais

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE BOAS PRÁTICAS DO PMI COM OS MÉTODOS ÁGEIS Por: Sheyla Christina Bueno Ortiz Orientador Prof. Nelsom Magalhães Rio de Janeiro

Leia mais

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

Leia mais

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

F.1 Gerenciamento da integração do projeto

F.1 Gerenciamento da integração do projeto Transcrição do Anexo F do PMBOK 4ª Edição Resumo das Áreas de Conhecimento em Gerenciamento de Projetos F.1 Gerenciamento da integração do projeto O gerenciamento da integração do projeto inclui os processos

Leia mais

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS GESTÃO DE PROJETOS Prof. Me. Luís Felipe Schilling "Escolha batalhas suficientemente grandes para importar, suficientemente pequenas para VENCER." Jonathan Kozol GERÊNCIA DA INTEGRAÇÃO PMBOK 1 GERÊNCIA

Leia mais

PMBOK - Project Management Body of Knowledge - PORTUGUÊS

PMBOK - Project Management Body of Knowledge - PORTUGUÊS PMBOK - Project Management Body of Knowledge - PORTUGUÊS Sr(as) Gerentes de Projeto, O PMBOK, compilado pela expertise do PMI Project Management Institute, é a linha mestra que nos conduz ao conhecimento

Leia mais

RUP como Metodologia de Desenvolvimento de Software para Obtenção da Qualidade de Software

RUP como Metodologia de Desenvolvimento de Software para Obtenção da Qualidade de Software SEGeT Simpósio de Excelência em Gestão e Tecnologia 1 RUP como Metodologia de Desenvolvimento de Software para Obtenção da Qualidade de Software Alfredo Nazareno P. Boente Fabiano S. G. de Oliveira João

Leia mais

Tecnologia da Informação para EPPGG 2013. Victor Dalton

Tecnologia da Informação para EPPGG 2013. Victor Dalton Tecnologia da Informação para EPPGG 2013 Victor Dalton Edital TECNOLOGIA DA INFORMAÇÃO: 1. Noções sobre processo de desenvolvimento de software: modelos organizacionais, stakeholders, modelagem de negócio,

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

Leia mais

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos

Leia mais

MBA ARQUITETURA DE INTERIORES

MBA ARQUITETURA DE INTERIORES MBA ARQUITETURA DE INTERIORES Coordenador: Carlos Russo Professor: Fábio Cavicchioli Netto, PMP 1 APRESENTAÇÃO DO PROFESSOR CONHECENDO OS PARTICIPANTES EXPECTATIVAS DO GRUPO 2 SUMÁRIO PMI / PMBoK / Certificados

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

Leia mais

UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição

UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição Project Management Institute UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição NOTA As

Leia mais

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP RUP Rational Unified Process ( Unificado de Desenvolvimento da Rational) Conjunto de passos que tem como objetivo atingir uma meta de software na ES, processo que visa a produzir o software - de modo eficiente

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE 1 PMI- Project Management Institute Fundado nos Estudos Unidos em 1969; Instituto sem fins lucrativos, dedicado ao

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS VANESSA WATZKO

UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS VANESSA WATZKO UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS VANESSA WATZKO PROPOSTA DE MÉTODO DE GESTÃO DE PROJETOS INCORPORANDO CONCEITOS

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK V EPCC Encontro Internacional de Produção Científica Cesumar 23 a 26 de outubro de 2007 METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK Cleber Lecheta Franchini 1 Resumo:

Leia mais

3. Metodologias de Gerenciamento de Riscos

3. Metodologias de Gerenciamento de Riscos 3. Metodologias de Gerenciamento de Riscos A complexidade que caracteriza a implantação de um sistema ERP é uma das maiores preocupações das organizações que pretendem desenvolver projetos desta natureza.

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

O que é um projeto? Características de um projeto. O Que é o PMBoK Guide 3º Edition? Desmembrando o PMBoK através de mapas mentais (Mindmaps)

O que é um projeto? Características de um projeto. O Que é o PMBoK Guide 3º Edition? Desmembrando o PMBoK através de mapas mentais (Mindmaps) O que é um projeto? Projeto é um empreendimento não repetitivo, caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido,

Leia mais

Gerenciamento de Projetos Modulo III Grupo de Processos

Gerenciamento de Projetos Modulo III Grupo de Processos Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Processos de Gerenciamento de Projetos Para que um projeto seja bem-sucedido,

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

SINAL Sindicato Nacional dos Funcionários do Banco Central Conceitos básicos em gerenciamento de projetos

SINAL Sindicato Nacional dos Funcionários do Banco Central Conceitos básicos em gerenciamento de projetos Conceitos básicos em gerenciamento de projetos Projeto de regulamentação do Art. 192 da Constituição Federal Brasília (DF) Maio de 2009 i Conteúdo 1. Nivelamento de informações em Gerenciamento de Projetos...

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis MBA em Gestão de Projetos Gerenciamento de Projetos Prática essencial para gerar negócios sustentáveis Prof: Ângelo Braga, PMP, MBA angelo.braga@fgv.br eu@angelobraga.com.br 2/154 Contatos Prof. Ângelo

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

ATO Nº 91/2015/GP/TRT 19ª, DE 1º DE JUNHO DE 2015

ATO Nº 91/2015/GP/TRT 19ª, DE 1º DE JUNHO DE 2015 PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA DÉCIMA NONA REGIÃO ATO Nº 91/2015/GP/TRT 19ª, DE 1º DE JUNHO DE 2015 O DESEMBARGADOR PRESIDENTE DO TRIBUNAL REGIONAL DO TRABALHO DA

Leia mais

O Ciclo de Vida do Desenvolvimento de Sistemas i

O Ciclo de Vida do Desenvolvimento de Sistemas i O Ciclo de Vida do de Sistemas i O Ciclo de Vida do de Sistemas ( SDLC Systems Development Life Cycle), conhecido também com o ciclo de vida do software refere-se aos estágios de concepção, projeto, criação

Leia mais