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.