47

UNIVERSIDADE VEIGA DE ALMEIDA UVA

BACHARELADO EM CINCIA DA COMPUTAO

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE: O MTODO CASCATA COMPARADO AO MTODO SCRUM

LEONARDO DINIZ SEVERO VIEIRA

RIO DE JANEIRO

2014UNIVERSIDADE VEIGA DE ALMEIDA - UVA

LEONARDO DINIZ SEVERO VIEIRA

Monografia apresentada ao curso de Cincia da Computao da Universidade Veiga de Almeida, como requisito parcial para obteno do ttulo de bacharel em Cincia da Computao.

Orientador: Edgar Gurgel

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE: O MTODO CASCATA COMPARADO AO MTODO SCRUM

RIO DE JANEIRO

2014

UNIVERSIDADE VEIGA DE ALMEIDA - UVABACHARELADO EM CINCIA DA COMPUTAO

LEONARDO DINIZ SEVERO VIEIRA

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE: O MTODO CASCATA COMPARADO AO MTODO SCRUM

Monografia apresentada como requisito final concluso do curso em Bacharel em Cincia da Computao.

APROVADA EM:

CONCEITO: _________________________________

BANCA EXAMINADORA

_____________________________________________ PROF. EDGAR GURGELORIENTADOR

___________________________________________________ PROF. NOME DO PROFESSOR DA BANCA

___________________________________________________ PROF. NOME DO PROFESSOR DA BANCA

Coordenao de Cincia da ComputaoRio de JaneiroAGRADECIMENTOS

Agradeo a minha esposa Tnia Vieira pela compreenso e apoio durante todo o curso de graduao, por ter permanecido ao meu lado me apoiando e ajudando a superar todas as minhas dificuldades e meus limites em busca do objetivo de concluir esse trabalho e o curso de graduao. Aos meus pais pela confiana depositada e por estarem ao meu lado durante toda minha vida. Aos amigos que fiz dentro da universidade e que estiveram comigo nessa grande jornada de aprendizados e desafios. Aos professores que sempre de forma atenciosa, empenhados e exigentes contriburam para a minha formao como profissional.

RESUMO

Os processos de desenvolvimento de software so essenciais para o gerenciamento e desenvolvimento dos projetos baseados em software, assim como para a manuteno do ciclo e vida dos softwares mesmo aps a entrega do produto. Os processos de desenvolvimento de software gerenciam o trabalho de construo de sistemas de forma progressiva e organizada provendo uma estrutura conceitual para o gerenciamento, desenvolvimento e para a implantao de projetos de software. Estudando os conceitos bsicos dos processos de desenvolvimento de software esse trabalho tem como objetivo comparar o tradicional mtodo cascata com o mtodo de desenvolvimento gil SCRUM.

Palavras-Chave: Engenharia de Software, Processos de Desenvolvimento, gil.

ABSTRACT

The software development processes are essential for the management and development of softwares projects as well as for the maintenance of the life cycle of the software even after product delivery. The concepts and techniques of development process and help direct the work of building a progressive and organized systems, providing a conceptual framework for the management, development and deployment of software projects. Studying the basics of software development processes that work has as main objective to develop a method to traditional waterfall development model and as SCRUM agile methodology. Also compared the development processes in cascade with the SCRUM agile development process among themselves, emphasizing the main differences, advantages and disadvantages of each process.

Keywords: Software Engineering, Development Processes, Agile.

LISTA DE ILUSTRAES

Figura 1- Modelo Cascata Programa Curto17Figura 2- Modelo em Cascata.18Figura 3- Modelo em Cascata Incremental23Figura 4 - Modelo Incremental25Figura 5 - Modelo RAD27Figura 6 - Modelo em espiral30Figura 7 - Extreme Programming33Figura 8 SCRUM35Figura 9 KANBAN39

LISTA DE ABREVIATURAS E SIGLAS

RAD - Rapid Application Development

SCRUM- Processo de desenvolvimento interativo e incremental para gerenciamento gil.

RUP - Rational Unified Process

XP - Extreme Programming

SUMRIOcaptulo 1 - introduo121.1CONSIDERAES INICIAIS121.2QUESTES NORTEADORAS DA PESQUISA131.3JUSTIFICATIVA DA INVESTIGAO131.4OBJETIVO DA PESQUISA141.5ORGANIZAO DA MONOGRAFIA14captulo 2 OS Processos de desenvolvimento152.1O MODELO EM CASCATA162.1.1.O ESTADO DE BLOQUEIO162.1.2.OS DOIS PASSOS ESSENCIAIS172.1.3.A ESTRUTURA DO MODELO EM CASCATA182.1.4.AS LIMITAES DO MODELO EM CASCATA192.1.5.AS ETAPAS DO MODELO EM CASCATA192.2.MODELO EM CASCATA ITERATIVO222.3O MODELO INCREMENTAL242.4MODELO RAD272.5MODELO EM ESPIRAL29captulo 3 - DESENVOLVIMENTO GIL313.1PROPOSTA313.2PROGRAMAO EXTREMA323.3SCRUM343.3.1.OS PAPEIS DO SCRUM353.3.2.ELEMENTOS DO SCRUM373.4KANBAN38caPITULO 4 - ESTUDOs DE CASO404.1.A ESCOLHA DO PROCESSO404.2.O PROCESSO EM CASCATA VS O SCRUM404.3.ADOTANDO UM MODELO NA PRTICA I424.4.ADOTANDO UM MODELO NA PRTICA II444.5.TRABALHOS FUTUROS45Concluso46captulo 1 - introduo

Os processos de desenvolvimento de software so os conjuntos das metodologias utilizadas para que o gerenciamento e o desenvolvimento de sistemas sejam bem sucedidos de forma que atendam aos requisitos dos usurios. Um processo de desenvolvimento de software consiste na execuo das atividades referentes a um projeto de forma planejada, separado por etapas, sendo utilizados para definir, desenvolver, testar e manter um software. Os processos de desenvolvimento definem as regras que os envolvidos na concepo e implantao de um projeto de software devem seguir para garantir que o resultado final do produto gerado tanto no ponto de vista comercial como no funcional seja satisfatrio, alm de cumprir corretamente com os contratos de projetos de desenvolvimento, cumprindo os prazos e custos estabelecidos em um acordo entre o cliente e o fornecedor. Utilizar processos de desenvolvimento de software fundamental para qualquer empresa que queira obter xito no desenvolvimento e entrega de projetos de software, mas possuir um processo forte e eficaz depende tambm da maturidade da empresa e como os processos em um modo geral so vistos, seguidos e executados na rotina da empresa. H um elevado nmero empresas que oferecem o desenvolvimento de software como servio e no utilizam de forma clara, correta e precisa as metodologias de desenvolvimento de software, fazendo com que os nmeros de projetos entregues com falhas ou no entregues sejam altos gerando assim prejuzos aos clientes e usurios. Existe um alarmante indicador estatstico sobre a falha na entrega de projetos de softwares, alm disso, muitas empresas que no possuem a rea de tecnologia da informao como rea fim e sim como rea meio no utilizam processos para gerarem seus prprios produtos e servios, causando grande impacto na operao das reas que a tecnologia deve estar presente, aumentando ainda mais os indicadores de sistemas que no so finalizados e no funcionam corretamente atendendo a real necessidade do usurio que solicitou o produto.

CONSIDERAES INICIAIS

Esse trabalho faz a comparao entre o mtodo cascata e o mtodo SCRUM, demostrando as etapas e as definies de cada processo, busca ainda refletir sobre como os processos de desenvolvimento de software podem ajudar aos profissionais a produzirem sistemas com qualidade, atendendo aos requisitos, cumprindo o custo e o prazo do projeto.QUESTES NORTEADORAS DA PESQUISA

A engenharia de software surgiu no final da dcada de 1960 para organizar as atividades de desenvolvimento de software e assim melhorar os indicadores que apontavam que mais de 40% dos projetos falhavam e no eram entregues e apenas um ndice muito baixo de projetos era concludo satisfatoriamente enquanto a maioria ultrapassava o prazo e custo estabelecidos entre empresa e o cliente. Mesmo sendo um assunto muito debatido entre os profissionais de desenvolvimento nas empresas e exaustivamente ensinado no meio acadmico, as empresas que realizam projetos de software ou no utilizam nenhum processo de desenvolvimento ou utilizam de forma incompleta e equivocada fazendo com que os ndices de projetos entregues de forma satisfatria permaneam baixos mesmo nos dias atuais.A medio desse ndice comeou a partir de 1994 pelo The Standish Group e apesar de demostrar uma melhora nos indicadores desde a primeira medio at a ltima medio que foi realizada no ano de 2013, os indicadores demostram que mesmo atualmente com todos os recursos e tecnologias que facilitam o gerenciamento dos projetos muitos desses projetos no so entregues gerando prejuzos s empresas que compram o produto e no o recebem, mantendo os indicadores de projetos sem sucesso demasiadamente altos.

JUSTIFICATIVA DA INVESTIGAO

A ausncia de um processo de desenvolvimento de software, assim como a sua utilizao indevida ou incompleta pode custar o sucesso de um projeto de software que atualmente orado na casa de milhares de reais para uma empresa de mdio e grande porte, causando alm de um enorme prejuzo financeiro a sobrecarga das operaes para o qual o projeto foi orado e gerando transtornos e prejuzos na rotina da empresa. Apesar de ser um assunto extremamente popular entre os profissionais de desenvolvimento de sistemas os processos de desenvolvimento no so praticados e permanecem extremamente obscuros para os profissionais de todos os nveis de atuao que muitas vezes no conseguem por em prtica esse conhecimento em um cenrio real de desenvolvimento de sistemas.OBJETIVO DA PESQUISA

O objetivo dessa pesquisa apresentar e comparar o tradicional processo de desenvolvimento em Cascata com o processo de desenvolvimento gil SCRUM. Descrevendo e detalhando as etapas obrigatrias dos processos que uma equipe de desenvolvimento de software deve seguir em um projeto, assim como apresentar uma aplicao prtica do desenvolvimento de um software em cada metodologia com um cenrio real de dois projetos de software que foram implantados em uma empresa do ramo da educao.

ORGANIZAO DA MONOGRAFIA

Essa monografia um trabalho de concluso do curso de cincia da computao e encontra-se organizada da seguinte forma: o capitulo dois apresenta um estudo detalhando os tradicionais processos de desenvolvimento em cascata, o processo em espiral, o processo RAD e o processo de modelo incremental e ser utilizado como base de conhecimento para o estudo de caso. O capitulo trs apresenta as definies dos processos de metodologias geis de desenvolvimento focando no estudo do SCRUM, XP e KANBAN, prticas essenciais para a concluso do estudo de caso. O capitulo quatro apresenta o estudo de caso que compara o processo de desenvolvimento em cascata com o processo de desenvolvimento gil SCRUM ressaltando as vantagens e desvantagens de cada metodologia. O capitulo cinco apresenta uma aplicao prtica de dois projetos que foram desenvolvidos utilizando o processo em cascata e o SCRUM respectivamente. No capitulo seis apresentado concluso da monografia assim como uma sugesto para trabalhos futuros.

captulo 2 OS Processos de desenvolvimento

Um processo de desenvolvimento de software um conjunto de atividades organizado em etapas interligadas que determinam o modo como o trabalho das pessoas envolvidas com um projeto de software deve ser feito para que se atinja um resultado satisfatrio. Os processos devem ser adaptados conforme a necessidade da empresa ou da equipe que produz o software no existindo assim um processo ideal e engessado. Um processo define quem est fazendo o qu, quando e como para alcanar certo objetivo (PRESMANN, p.19, 2006). Durante a execuo do processo, profissionais de determinado perfil tornam-se responsveis por demonstrar e exigir que as regras do processo sejam cumpridas, tornando mais eficiente execuo das atividades. Para muitos sistemas de grande porte, naturalmente, no existe apenas um processo de software que possa ser utilizado. Processos diferentes so utilizados para desenvolver diferentes partes do sistema (SOMMERVILLE, p.37, 2007).Os processos de desenvolvimento surgiram nos anos de 1970 como uma resposta tcnica para resolver a crise do software que ocorreu no final da dcada de 1960 com a expanso do desenvolvimento de sistemas. Essa crise caracterizada por projetos estourando prazos e oramentos, softwares sendo produzidos com baixa ou nenhuma qualidade tcnica e sistemas que no atendem aos requisitos dos usurios, sendo esses problemas recorrentes at os dias atuais e apesar de atacar os principais pontos levantados que geraram uma crise no desenvolvimento de software a engenharia de software no conseguiu sanar os problemas.O Standish Group, uma comunidade de profissionais de T.I que possuem o interesse no gerenciamento de projetos disponibiliza um relatrio de forma peridica com informaes estatsticas sobre o status final de projetos. O ultimo relatrio aponta que apenas 39% dos projetos so finalizados com sucesso[footnoteRef:1]. Apesar de ser um nmero baixo em termos gerais esses nmeros so bem maiores do que em anos anteriores, em 1994, ano no qual a medio comeou a ser feita, apenas 16% dos projetos eram finalizados com sucesso, em 2001 esse nmero alcanou 27% e em 2006 j representavam 34% conforme nmeros da prpria comunidade. Os processos de desenvolvimento de software so essenciais para o sucesso dos projetos das empresas que produzem software, definindo o papel de cada envolvido no projeto e dando responsabilidades e metas a equipe de desenvolvimento. [1: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf]

1 1.1 O MODELO EM CASCATA

O modelo em cascata foi sugerido por Winston W. Royce em 1970 em um artigo com o titulo Waterfall Managing the development of large software systems [footnoteRef:2], onde descrito quais so os passos essenciais para a utilizao de um processo de desenvolvimento de sistemas para projetos definidos com extensos e complexos. O modelo de desenvolvimento em cascata um modelo sequencial onde o desenvolvimento do software sempre visto de forma linear, ou seja, em uma sequencia de etapas realizadas de forma sistemtica onde uma etapa posterior depende da etapa anterior para prosseguir, as etapas no podem ser transpostas e devem ser finalizadas antes que sejam prosseguidas etapas posteriores. [2: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf]

Mesmo no utilizando o termo cascata para descrever o processo o termo foi associado ao processo atravs do artigo, tornando-se conhecido como modelo em cascata devido ao desenho e abordagem inicial empregada ao processo. Como Royce argumentava que um processo sequencial com as etapas dependentes entre si propenso a falhas, seu artigo demostra ento como esse modelo inicial poderia ser desenvolvido em um modelo iterativo tentando assim eliminar as falhas de um processo estritamente sequencial para um formato de trabalho mais flexvel. Porm suas criticas foram ignoradas e o modelo em cascata no se tornou um processo iterativo tendo destaque apenas em seu modelo inicial e essa sugesto posteriormente sendo utilizada para a concepo de modelos iterativos baseados no mtodo em cascata.1. 2. 2.1. 1. 2. 2.1. O ESTADO DE BLOQUEIO

No modelo em cascata no h como transpor as etapas o que torna obrigatrio que cada sequencia seja definida, executada e finalizada corretamente. As dependncias entre as etapas do modelo em cascata geram paralisaes temporrias durante o processo de desenvolvimento e j haviam sido percebidas por Royce no momento da concepo e desenho do processo, sendo essas paralisaes descritas como estado de bloqueio.O estado de bloqueio faz com que as demais atividades do projeto fiquem paradas aguardando o trmino das atividades da etapa corrente no permitindo o desenvolvimento de forma intercalada. Um exemplo prtico dessa limitao que mesmo com algumas funcionalidades prontas s poder haver testes ao trmino do desenvolvimento de todas as funcionalidades do sistema, dessa forma o tempo gasto na espera da concluso das tarefas pode ser maior do que o tempo gasto nas atividades produtivas, consequentemente atrasando e elevando o custo e o prazo do projeto. O estado de bloqueio ocorre com mais frequncia no inicio e fim do processo e para evitar esse tipo de falha de extrema importncia que os requisitos e o escopo do projeto estejam bem definidos, uma vez que os usurios s podero avaliar o sistema na verso final aps todo o trabalho houver sido concludo. O estado de bloqueio a principal falha do processo em cascata gerando um impacto direto no cronograma do projeto e ficando acentuado como falha de conceito ao permitir que o usurio analise o produto somente na entrega. Isso faz com que um erro no levantamento de requisitos ou em outra etapa durante o projeto s seja notada na implantao, no permitindo a correo em tempo de entrega do projeto.

OS DOIS PASSOS ESSENCIAIS

No inicio do artigo Royce demonstra um conceito simples para realizar a codificao de qualquer sistema computacional explicando que existem dois passos essenciais e comuns a todo desenvolvimento de programas de computador, onde o primeiro passo uma etapa de analise seguido de uma etapa de codificao. Esse mtodo simples e eficaz para programas simples onde o usurio o prprio desenvolvedor, porm para aplicaes complexas como os sistemas para atender a uma ampla regra de negcios e a muitos usurios essa metodologia se torna ineficiente devido s falhas que possam ocorrer desde a concepo at a implantao do produto ao usurio. A Figura 1 ilustra as etapas que Royce acreditava ser essenciais ao desenvolvimento de sistemas curtos.

Figura 1- Modelo Cascata Programa CurtoA ESTRUTURA DO MODELO EM CASCATA

Percebendo que apenas duas etapas no seriam suficientes ao processo Royce define novas etapas para complementar o modelo e estender sua utilizao para sistemas complexos e maiores. Organizando o processo de desenvolvimento de forma sequencial a metodologia em cascata trabalha atendendo a um contexto maior pensando desde as necessidades bsicas para o funcionamento do sistema como os requisitos no funcionais at os requisitos funcionais que passa pelas necessidades dos usurios. Mesmo com essa organizao o processo continuou apresentando problemas j que o modelo inflexvel no ponto de vista da execuo de suas etapas no permitindo que ocorram duas etapas diferentes paralelamente, dessa forma os erros so encobertos e corrigidos aps a implantao do sistema. A Figura 2 ilustra o desenho original concebido por Royce em seu artigo com a incluso das demais etapas que formam o modelo em cascata.

Figura 2- Modelo em Cascata.

Eu acredito nesse conceito, mas a implementao descrita acima um risco e um convite a falhas (Royce, p.02, 1970). AS LIMITAES DO MODELO EM CASCATA

Na teoria o modelo em cascata sequencial com as etapas interligadas e dependentes entre si, porm na prtica extremamente difcil manter o estilo linear da metodologia o que faz com que as etapas se sobreponham.

A fase seguinte no deve se iniciar at que a fase precedente tenha sido concluda. Na prtica, esses estgios se sobrepem e trocam informaes entre si. Durante o projeto, so identificados problemas com os requisitos; durante a codificao, so verificados problemas no projeto, e assim por diante. O processo de software no um modelo linear simples, mas envolve uma sequencia de iteraes das atividades de desenvolvimento. Devido aos custos de produo e aprovao de documentos, as iteraes so onerosas e envolvem um retrabalho significativo (SOMMERVILLE, 2007, p.38).

Royce afirmava que o conceito do modelo em cascata um convite a falhas devido s paralisaes causadas pelo estado de bloqueio e devido o software ser testado e avaliado somente na verso final quando entregue o projeto e implantado para os usurios, mesmo assim, o processo bastante utilizado devido ao seu formato de fcil compreenso. Fazer uma etapa de cada vez torna simples a organizao para o desenvolvimento de um sistema, porm o caminho do desenvolvimento de um sistema nunca simples ocorrendo em muitos casos imprevistos e a falta do conhecimento necessrio sobre a rega de negcios tanto da equipe de desenvolvimento quanto do cliente faz com que os requisitos precisem ser revistos e funes adaptadas a todo o momento. O modelo em cascata engessa a construo do projeto que fica esttico e atualmente tornou-se obsoleto devido suas falhas e perdeu espao para as metodologias geis, e processos tradicionais de desenvolvimento iterativos e incrementais.

AS ETAPAS DO MODELO EM CASCATA

O modelo em cascata divido em etapas ou fases onde conforme a fase h um grupo de atividades necessrias e obrigatrias para o correto desenvolvimento de um projeto. A diviso em etapas tem como objetivo facilitar o entendimento, o gerenciamento e concluso das atividades necessrias para a construo de um produto de software complexo. Cada etapa possui uma caracterstica no cronograma do projeto e possui atividades especificas que devem ser vistas como parte fundamental para a construo do produto final. No possvel excluir nenhuma das etapas do modelo como tambm no possvel trabalha-las paralelamente.

1. 2. 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.5.1. REQUISITOS

A primeira ao que deve ser feita ao se planejar um projeto de software conhecer as necessidades que o sistema deve contemplar, ou seja, as regras de negcios do sistema assim como o prazo em que o sistema precisa ser implantado, a estrutura necessria para o sistema funcionar entre outros detalhes. Realizar o levantamento de requisitos no modelo em cascata requer habilidade e experincia para que o levantamento seja feito corretamente.

H ocasies em que os requisitos de um problema so razoavelmente bem compreendidos, quando o trabalho flui da comunicao at a implantao de um modo razoavelmente linear. Essa situao algumas vezes encontrada quando adaptaes bem definidas ou aperfeioamentos de um sistema existente precisam ser feitos (por exemplo, uma adaptao de um software de contabilidade que foi determinada devido a modificaes na regulamentao governamental). Pode ocorrer tambm em um nmero limitado de novos esforos de desenvolvimento, mas apenas quando os requisitos so bem definidos e razoavelmente estveis (PRESSMAN, 2006, p.38).

O levantamento de requisitos essencial para o sucesso do projeto e define todos os detalhes e especificaes do sistema e caso ocorram erros nessa fase toda analise e a codificao estar comprometida. O que ocorre em muitos projetos que o levantamento de requisitos feito de forma superficial e informal havendo apenas uma entrevista com o cliente para entender o contexto para o qual o sistema ser desenvolvido e as funcionalidades que o usurio espera que o sistema possua. Como no modelo em cascata o usurio ter que aguardar o desenvolvimento do sistema por completo e s poder realizar os testes aps ser disponibilizada a verso final os erros no entendimento dos requisitos so desastrosos.

1. 2. 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.4.1. 2.1.5.2. PROJETOSA fase de projeto envolve a identificao e a descrio do conceito que ser aplicado como regra de negocio e que o sistema dever atender, ou seja, trata-se das abstraes fundamentais do sistema de software e suas relaes. Nesse momento possvel perceber a dependncia do modelo em cascata onde caso os requisitos estejam errados o projeto comea a ser estruturado com erros que ir impactar todo o ciclo de vida do software e sero notados e reportados somente quando todo o sistema for codificado, testado, implantado e o projeto entregue. durante a fase de projetos que ocorre toda a modelagem do sistema e os desenvolvedores iro elaborar atravs de ferramentas e tcnicas como o Diagrama Entidade Relacionamento a modelagem e dependncias da estrutura de dados que sero persistidos em um banco de dados, alm da modelagem de classes atravs dos diagramas de classe, diagramas UML entre outras formas de documentar o processo de desenvolvimento e estruturar o projeto. Os arquitetos de software definem o desenho do sistema mostrando como iro trabalhar as tecnologias escolhidas, desenhando a integrao dos mdulos do sistema e gerando toda a documentao tcnica necessria.

1. 2. 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.4.1. 2.1.4.2. 2.1.5.3. IMPLEMENTAO

Na fase de implementao todo o projeto do software codificado pelos desenvolvedores utilizando alguma linguagem de programao. Durante esse estgio, o projeto de software compreendido como um conjunto de programas ou unidades de programa (SOMMERVILLE, 2007, p.39). Essa etapa extremamente critica j que envolvido um nmero maior de pessoas que precisam ser demandadas e gerenciadas, alm de ocorrer a maior parte do retrabalho das atividades de programao. Porm at essa etapa o custo de uma modificao no requisito menor e durante essa etapa podem ser utilizadas de forma isolada outras metodologias de gerenciamento para a concluso das atividades, mesmo assim o software que est sendo construdo s poder ser testado aps toda a etapa de codificao terminar se o processo em cascata for levado a rigor como a teoria ilustra.

1. 2. 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.4.1. 2.1.4.2. 2.1.4.3. 2.1.5.4. TESTES

Na fase de testes todas as unidades e funes criadas durante a fase de implementao so testadas e verificadas com o objetivo de confirmarem se atendem aos requisitos ou se possuem falhas de programao. So realizados tambm os primeiros testes de como a aplicao ir se comportar em um ambiente mais prximo ao ambiente de produo, sendo realizados testes na arquitetura do sistema. O ambiente de produo espelhado em um ambiente de homologao que atravs de ferramentas que estressam o funcionamento da aplicao e da infraestrutura podem testar a quantidade de acessos simultneos ao sistema e o desempenho do sistema com o objetivo de validar se a aplicao em produo ser vivel e atender a demanda. O tipo de teste pelo qual uma aplicao passar depende da equipe de desenvolvimento e do objetivo da aplicao no havendo assim uma lista de quais testes precisam ou devam ser feitos para que uma aplicao seja dada como funcional e correta ao trmino da etapa de desenvolvimento.1. 2. 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.4.1. 2.1.4.2. 2.1.4.3. 2.1.4.4. 2.1.5.5. IMPLANTAO

Na fase de implantao o sistema disponibilizado em um ambiente de produo, onde o usurio ir operar de fato o sistema.

1. 2. 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.4.1. 2.1.4.2. 2.1.4.3. 2.1.4.4. 2.1.4.5. 2.1.5.6. MANUTENO

A fase de manuteno a fase onde novos requisitos ou melhorias sero incorporados ao sistema j disponvel ao usurio em um ambiente de produo e as falhas corrigidas. Todos os sistemas passam por manuteno, melhorias e implementaes de novas funcionalidades aps irem para produo j que ocorrem mudanas na regra de negocio da empresa e a forma como os processos internos so feitos durante o ciclo de vida do sistema, alm da falta de algum requisito que no foi includo no desenvolvimento do sistema.

1. 2. 2.1. 2.2. MODELO EM CASCATA ITERATIVORoyce aps conceber o modelo em cascata e enxergando que o mtodo propenso a falhas sugere que haja iteratividade entre as fases do processo. Essa proposta procurava resolver os problemas existentes devido ao conceito do processo ser linear, melhorando assim a sua flexibilidade. Porm ao dar essa sugesto Royce estava mudando o conceito do processo fazendo com que o mesmo deixasse de ser linear e passasse a ser iterativo e incremental. Inicialmente alm de eliminar as principais falhas do processo como o estado de bloqueio essa mudana permitiria desenvolver as atividades de forma intercalada, onde aps a concluso de uma etapa o engenheiro de software poderia voltar e acrescentar detalhes e melhorias para gerar um produto mais completo no mesmo perodo de tempo utilizando o feedback da iterao, dando a flexibilidade que Royce esperava ao processo. Mesmo apresentando essa proposta em seu artigo Royce no detalha como essa iterao deveria ser feita tornando esse item em um estudo futuro para a metodologia. O processo de desenvolvimento em cascata uma metodologia simples de ser utilizada, porm considerada obsoleta em comparao a outros processos e caso no seja adaptado realidade dos projetos pode ser considerado apenas terico j que no mundo real dificilmente um projeto segue um fluxo estritamente sequencial e caso no ocorra essa adaptao no possvel cumprir com os primrdios dos projetos; prazo, custo e qualidade. A vantagem do processo em cascata que no ser entregue um projeto incompleto ou defeituoso proveniente da falta de unidades que no foram feitas devido ao no cumprimento das etapas de desenvolvimento, o sistema disponibilizado ao usurio somente ao fim de todo o projeto. A Figura a seguir ilustra um desenho do modelo em cascata de forma iterativa conforme a proposta de Royce.

Figura 3- Modelo em Cascata Incremental

A proposta de incluir iterao entre as etapas do modelo em cascata foi utilizada posteriormente em metodologias semelhantes com o acrscimo ou a compactao das etapas, onde o modelo em cascata foi o percursor das demais metodologias que se tornaram tradicionais na engenharia de software para o desenvolvimento de sistemas. Todas as metodologias que seguiram aps o modelo em cascata possui o objetivo de reverter crise do software, porm mesmo com o extenso estudo das prticas para o desenvolvimento de sistemas os mesmos indicadores que foram revelados no incio da dcada de 1970 ainda so presentes nos dias de hoje e h inclusive quem fale no fracasso da engenharia de software devido a continuidade dos problemas aps mais de 4 dcadas de existncia.

1.1 1.1 1.1 1.2 O MODELO INCREMENTAL

O modelo incremental uma aplicao adaptada do modelo em cascata e possui iteraes entre as suas fases evitando assim as principais falhas do processo em cascata e foi concebido como uma resposta s fraquezas do modelo em cascata. A principal diferena entre o modelo em cascata e o modelo incremental notada logo no resultado que a aplicao do mtodo prope, enquanto a aplicao do modelo em cascata prev um produto somente ao termino de todo o processo de desenvolvimento o modelo incremental estabelece que esse produto possa ser entregue em pacotes que contenham pequenas amostras das funcionalidades do sistema e as demais funcionalidades assim que ficarem disponveis so acrescentadas.

Quando um modelo incremental usado, o primeiro incremento frequentemente chamado de ncleo do produto. Isto , os requisitos bsicos so satisfeitos, mas muitas caractersticas suplementares (algumas conhecidas, outras desconhecidas) deixam de ser elaboradas. O ncleo do produto usado pelo cliente (ou passa por reviso detalhada). Um plano desenvolvido para o prximo incremento como resultado de uso e avaliao. O plano visa a modificao do ncleo do produto para melhor satisfazer as necessidades do cliente e a elaborao de caractersticas e funcionalidades adicionais. Esse processo repetido aps a realizao de cada incremento, at que o produto completo seja produzido (PRESSMAN, 2006, p.40).

O modelo incremental foi proposto por Harlan Mills em 1980 como uma maneira de reduzir o retrabalho nos processos de desenvolvimento adaptando os conceitos existentes e diminuindo o tempo de desenvolvimento de projetos. O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa (PRESSMAN, 2006, p.40). O formato iterativo facilita a identificao e a correo de erros evitando um atraso na entrega do produto j que so definidos estgios de entrega que fornecem subconjuntos que contemplam as funcionalidades dos sistemas.

2.3. ESTAGIOS DE ENTREGA

Os estgios de entrega so realizados em prazos estabelecidos entre a equipe de desenvolvimento do projeto e o cliente e determina quando a equipe de desenvolvimento ir entregar algum pacote de funcionalidades do sistema. Alm de sempre entregar uma verso funcional do sistema para o usurio testar e validar esse formato de trabalho no requer uma quantidade elevada de pessoas para realizar um projeto j que um profissional pode desempenhar funes diferentes em estgios diferentes. Os estgios ocorrerem paralelamente e sem dependncia proporcionando flexibilidade e agilidade ao processo e reduzindo o ndice de falhas de um projeto, esse modelo de trabalho oferece tambm a facilidade da implementao de novos requisitos ou no foram observados no momento de definio do sistema.

INCREMENTO

O primeiro incremento do sistema possui as funcionalidades que tratam dos requisitos bsicos da aplicao. Os prximos incrementos sempre iro entregar novas funcionalidades, do sistema. Em um processo de desenvolvimento incremental, os clientes identificam, em um esboo, as funes a serem fornecidas pelo sistema (SOMMERVILLE, 2007, p.43). Aps essa definio pode ocorrer paralelamente outras analises de requisitos para os incrementos seguintes, porm proibido alteraes nos requisitos que esto sendo trabalhados no incremento atual. Os clientes estaro aptos a testarem os requisitos aps a concluso e entrega do incremento, podendo assim elaborar os requisitos para os prximos incrementos. A Figura a seguir demostra o processo do modelo incremental.

Figura 4 - Modelo Incremental No existe a necessidade de utilizar o mesmo processo para o desenvolvimento de cada incremento (SOMMERVILLE, 2007, p.44). Ao desenvolver um incremento um engenheiro de software pode optar por gerenciar esse incremento utilizando o modelo em cascata ou qualquer outra metodologia de desenvolvimento. Esse comportamento demostra a flexibilidade do modelo incremental facilitando o gerenciamento e ciclo de vida da aplicao durante a codificao do sistema.

DIFERENCIAIS

A principal vantagem desse modelo que os clientes no precisam aguardar o trmino do sistema para utilizar o software e as primeiras verses podem ser utilizadas como prottipos a fim de obter uma melhor experincia sobre o sistema e verificar se os requisitos realmente atendem as necessidades dos usurios. Existe assim um risco menor de fracasso do projeto j que durante toda a codificao o sistema testado, revisto e homologado pelos usurios. O modelo incremental possui mais flexibilidade otimizando o tempo conforme os recursos disponveis para a implantao do projeto. Mesmo sendo um modelo mais eficiente o modelo permite que ocorram falhas durante o desenvolvimento caso no seja bem gerenciado.

Contudo, existem alguns problemas com o desenvolvimento incremental. Os incrementos devem ser relativamente pequenos, (compostos de no mais do que 20 mil linhas de cdigo), e cada incremento deve produzir alguma funcionalidade para o sistema. Pode, portanto, ser difcil mapear os requisitos dos clientes dentro de um incremento de tamanho correto. Como os requisitos no so bem definidos em detalhes at que um incremento seja implementado, difcil identificar facilidades comuns que todos os incrementos exigem (SOMMERVILLE, 2007, p.44).

Como ressaltou Pressman (2006, p.40) o modelo incremental particularmente til quando no h uma mo de obra disponvel para uma implementao completa dentro do prazo comercial de entrega estabelecido para o projeto. A metodologia incremental emprica sendo mais bem empregada a cada projeto bem sucedido que entregue. uma metodologia de fcil gerenciamento onde a pr-atividade extremamente importante, alm de ser uma metodologia dominante entre as empresas que fabricam software. A maior inovao do modelo iterativo e incremental ocorre no ponto de permitir que as suas etapas no sejam fixamente dependentes e inspirou novos mtodos para o desenvolvimento de sistemas em uma forma mais dinmica que os existentes at ento.

MODELO RAD

O Modelo RAD criado por James Martin na dcada de 90 um modelo de processo iterativo e incremental que prope um ciclo de desenvolvimento extremamente curto onde o perodo de desenvolvimento de no mximo trs meses. O modelo RAD uma adaptao de alta velocidade do modelo em cascata, no qual o desenvolvimento rpido obtido com o uso de uma abordagem de construo baseada em componentes (PRESSMAN, 2006, p.41). Uma das principais regras do processo que os requisitos estejam bem definidos e compreendidos por todos os envolvidos no projeto e aps o inicio das atividades o modelo no suporta qualquer mudana nos requisitos devido aos riscos tcnicos que ficam extremamente altos. A necessidade de todos os envolvidos compreenderem de forma clara e objetiva os requisitos essencial para o sucesso do projeto, onde tanto a equipe de desenvolvimento quanto o cliente precisam estar alinhados sobre as necessidades que o sistema precisa atender assim como compromissados com as atividades continuas e rpidas o qual o processo exige. A figura a seguir um diagrama do modelo do processo RAD.

Figura 5 - Modelo RAD2.4.

ABORDAGEM

A abordagem do processo consiste em quebrar o software em mdulos para que diversas equipes de desenvolvimento trabalhem simultaneamente no projeto separado em trs fases essenciais, a modelagem do negcio, modelagem dos dados e modelagem dos processos. O modelo RAD utiliza a gerao automtica de cdigo e componentes de software como forma de tornar gil o desenvolvimento e entregar em um tempo extremamente curto um projeto de software.

COMPONENTES DE SOFTWARE

O processo RAD utiliza o conceito de componentes de software onde desenvolvedores escrevem mdulos de forma genrica com o objetivo de atender a uma abstrao e no apenas a uma funcionalidade especifica de um sistema, reaproveitando esse componente em outros sistemas. O paradigma da programao orientada a objetos atravs do conceito de herana tende a reaproveitar cdigos existentes fazendo com que objetos herdem caractersticas de outros objetos j escritos por programadores evitando repetir o desenvolvimento de uma funcionalidade j existente e comumente utilizada, sendo esse conceito a principal vertente do desenvolvimento no modelo RAD.O conceito de componentes foi proposto por Malcolm Douglas McIlroy em 1968 na NATO Software Engineering Conference com um artigo titulado Mass Produced Software Components [footnoteRef:3] e deu nfase nas tcnicas utilizadas para o desenvolvimento de software. Minha tese que a indstria de software pouco fundamentada e que um aspecto dessa fraqueza a ausncia de uma subindstria de componentes de software (Mcilroy, 1968, p.79). A reutilizao de software para a construo de novos sistemas requer maturidade um processo complexo, porm de grande eficincia. A utilizao de componentes apresenta alguns problemas como a utilizao de funes desnecessrias no reuso dos componentes, o custo do conjunto de ferramentas e a dependncia de terceiros que pode causar j que em muitos casos a compra de componentes se faz necessria e o cdigo fonte dos componentes no so disponibilizados para os desenvolvedores que utilizam apenas uma interface de interao para o modulo de funes contidas nesse componente de software. [3: http://www.scrummanager.net/files/nato1968e.pdf]

MODELO EM ESPIRAL

Para o desenvolvimento de projetos de larga escala recomendvel que seja utilizado um processo de desenvolvimento iterativo e incremental devido as constantes mudanas dos requisitos no decorrer do projeto. Em 1988 em um artigo com o titulo de A Spiral Model of Software Development and Enhancement[footnoteRef:4], Barry Boehm definiu o processo de desenvolvimento do modelo em espiral. [4: http://csse.usc.edu/csse/TECHRPTS/1988/usccse88-500/usccse88-500.pdf]

Em vez de representar o processo de software como uma sequencia de atividades com algum retorno de uma atividade para outra, o processo representado como uma espiral. Cada loop na espiral representa uma fase do processo de software. Assim o loop interno pode estar relacionado viabilidade do sistema; o loop seguinte, a definio de requisitos; o prximo loop, ao projeto do sistema e assim por diante. (SOMMERVILLE, 2007, p.44-45)

O modelo em espiral um processo evolucionrio combinando uma natureza iterativa com alguns aspectos controlados do modelo em cascata, mas com uma diferena dos demais, esse processo possui uma etapa a mais que realiza a analise dos riscos do projeto. A incluso dessa etapa ocorreu com o intuito de melhorar o processo de desenvolvimento e de ajudar a resolver os problemas existentes em outros processos. A importante distino entre o modelo em espiral e outros modelos de processo de software a explicita considerao dos riscos no modelo em espiral (SOMMERVILLE, 2007, p.45).

2.5. ESPIRAL

O modelo em espiral prope que o software seja desenvolvido em uma srie de verses evolucionarias e medida que o desenvolvimento do produto avana as atividades so indicadas atravs de um circuito em volta de uma espiral em sentido horrio que comea no centro do circuito tendo a cada evoluo a considerao dos riscos do projeto. A abordagem do modelo em espiral prpria para o desenvolvimento de sistemas e softwares de grande porte podendo inclusive ser adaptado ao ciclo de vida do software aps a entrega do produto e assim manter o software com as manutenes e novos desenvolvimentos necessrios. Em resumo, a espiral, quando caracterizada desse modo, permanece operacional at que o software seja retirado de servio (PRESSMAN, 2006, p.45). A Figura a seguir demostra o processo do modelo em espiral, com a especificao de cada etapa utilizada, alm de ilustrar as atividades das etapas.

Figura 6 - Modelo em espiralO modelo em espiral um processo dinmico que permite a iterao entre os envolvidos, a adio de novas funcionalidades e requisitos durante o desenvolvimento controlando os riscos do projeto tornando a produo do software seguro. As vantagens do modelo em espiral esto no desenvolvimento continuo que ajuda na gesto de riscos, o modelo suporta tambm quantas alteraes de requisitos e funcionalidade forem necessrias em qualquer fase do processo.A principal abordagem do modelo em espiral a etapa de analise de riscos que exige a competncia necessria e influencia diretamente no sucesso do projeto. Se um risco importante no for descoberto e gerenciado, fatalmente ocorrero problemas (PRESSMAN, 2006, p.46). As demais etapas do processo diz respeito administrao do trabalho de desenvolvimento onde so acompanhados os testes, os prottipos e as validaes, gerenciando as atividades para que o projeto faa uma entrega contnua. Avaliar os riscos pode ser um trabalho extenso e difcil elevando o custo do projeto. O modelo em espiral serve como a melhor soluo para empresas que possuem negcios volteis em constante mudana porm com uma complexidade nas regras de negcios, sendo indicado principalmente para desenvolvimento de sistemas extensos e mais complexos.captulo 3 - DESENVOLVIMENTO GIL

O conceito de desenvolvimento gil recente e surgiu em 2001 onde um grupo de desenvolvedores, produtores e consultores de software assinaram um manifesto com doze princpios para atender ao proposito do desenvolvimento gil, esse grupo ficou conhecido como a Aliana gil[footnoteRef:5]. O desenvolvimento gil um conjunto de metodologias que providencia uma estrutura para o gerenciamento de projetos de softwares. Essa estrutura tambm conhecida como framework de processo gil e contm as regras e padres de gerenciamento para que um projeto seja feita de forma gil. Em essncia, os mtodos geis foram desenvolvidos em um esforo para vencer as fraquezas percebidas e reais da engenharia de software convencional (PRESSMAN, 2006, p.58). [5: http://www.agilealliance.org/]

3. 2 1.1 1.1 1.1 PROPOSTA

Os mtodos de desenvolvimento geis estimulam praticas diferentes aos processos tradicionais de desenvolvimento de software e as prticas da engenharia de software. A filosofia do desenvolvimento gil trabalha com a ideia de equipes pequenas porem altamente motivadas, mtodos informais e simplicidade global no desenvolvimento fazendo com que o software seja entregue de forma rpida e funcional. Um mtodo gil precisa ser de fcil adaptao para o caso de modificaes no esperadas no projeto ou nas condies tcnicas, precisando ser um processo flexvel e dinmico para atender a constante mudana de requisitos sem comprometer o resultado final do projeto, sendo necessrio possuir um determinado nvel de maturidade para a utilizao de um processo de desenvolvimento gil.

Mas a adaptao continua sem progresso realiza pouco. Assim, um processo gil de software deve ser adaptado incrementalmente. Para realizar a adaptao incremental, uma equipe gil requer o feedback do cliente (de modo que adaptaes apropriadas possam ser feitas). [...]. Essa abordagem iterativa habilita o cliente a avaliar o incremento de software regularmente, fornecer o feedback necessrio a equipe de software e influenciar as adaptaes do processo feitas para acomodar o feedback (PRESSMAN, 2006, p.61).

O processo de desenvolvimento gil foca na comunicao dos envolvidos no projeto propondo uma iterao continua entre o cliente e o fornecedor. A equipe de desenvolvimento deve pensar frequentemente se est atendendo as regras do desenvolvimento gil, como por exemplo, verificar se o software est sendo entregue de forma funcional sempre na menor escala de tempo assim como a continua ateno entre a excelncia tcnica e o bom design que aumentam a agilidade do desenvolvimento. Um processo gil melhorado continuamente pela equipe de desenvolvimento que deve deixar o processo mais refinado a ponto de torna-lo mais eficaz, esse experincia acumulada em cada iterao e incremento do processo.

1.1 1.1 2.1 PROGRAMAO EXTREMA

O conceito de Programao Extrema ou Extreme Programming recente na engenharia de software mesmo havendo registros de um trabalho inicial no final da dcada de 1980 apenas em 1999 foi publicado o primeiro trabalho sobre o assunto por Kent Beck considerado um pioneiro no assunto, uma evoluo da abordagem incremental e possui como base o desenvolvimento e a entrega de incrementos pequenos envolvendo o cliente no processo buscando melhorar constantemente o cdigo da aplicao. Utiliza o conceito de programao orientada a objetos como paradigma de desenvolvimento padro sendo divido em quatro fases, planejamento, projeto, codificao e testes.

3.1. 3.2. REGRAS

Os fundamentos da programao extrema incluem o desenvolvimento de todo o software em par, ou seja, dois programadores em uma tela, a escrita de testes unitrios antes do desenvolvimento e a manuteno desses testes rodando durante o desenvolvimento do sistema e colocar o sistema em produo rapidamente mesmo que seja apenas uma pequena parte. Esses fundamentos tem o objetivo de tornar gil e rpido o desenvolvimento de software por equipes de pequeno e mdio porte onde a maior dificuldade est na constante mudana dos requisitos.

ESTRUTURA DO PROCESSO

Por se um processo iterativo e incremental a programao extrema combina os conceitos de arcabouo do desenvolvimento de software como comunicao e planejamento com tcnicas especificas da reviso de cdigos e da utilizao de unidades de testes para a validao do cdigo sempre com o principio de simplicidade aplicada ao projeto. A Figura a seguir ilustra o processo da programao extrema.

Figura 7 - Extreme Programming

Diferente de outras metodologias que focam tempo e esforo em elaborar documentos como casos de uso e diagramas a programao extrema produz pouca documentao onde o cdigo com comentrios relevantes, feito de forma simples e bem estruturado torna-se uma documentao completa. O processo deve ser utilizado quando o cliente precisa ter alguma verso funcional do sistema em um prazo curto onde os incrementos e as iteraes podem ser dirias, semanais e mensais. Apesar de ser um processo gil a programao extrema se protege de falhas que essa agilidade pode ocasionar como o caso de funcionalidades que no atendam o requisito do cliente ou at mesmo erro de cdigo.

Um conceito chave durante a atividade de codificao (e um dos aspectos mais comentados do XP) a programao em pares. O XP recomenda que duas pessoas trabalhem juntas em uma estao de trabalho de computador para criar o cdigo correspondente a uma historia. Isso fornece um mecanismo de soluo de problemas em tempo real (duas cabeas so frequentemente melhores do que uma) e de garantia de qualidade em tempo real. Tambm mantem os desenvolvedores focados no problema em mos. Na prtica cada pessoa assume um papel ligeiramente diferente (PRESSMAN, 2006, p.65).

A programao extrema baseada nos conceitos de simplicidade, comunicao, feedback e coragem, conforme a definio de Ronald Jeffries esse processo funciona porque trs toda a equipe de desenvolvimento a presena de praticas simples com o feedback suficiente para permitir que vejam onde esto e ajustar as prticas para uma situao nica, alm de manter toda a equipe integrada e avanando para o objetivo do projeto durante o perodo necessrio de desenvolvimento e codificao do projeto de software.SCRUM

O SCRUM um processo iterativo e incremental para o gerenciamento de projetos e utilizado no desenvolvimento gil de software onde os projetos so divididos em ciclos tipicamente mensais chamados de SPRINTS e foi desenvolvido por Jeff Sutherland no inicio da dcada de 1990 possuindo os princpios consistentes com o manifesto gil[footnoteRef:6]. [6: http://manifestoagil.com.br/]

O SCRUM trabalha com o conceito de ser adaptvel e flexvel na modificao dos requisitos durante o desenvolvimento do projeto tentando sempre garantir que o melhor produto seja desenvolvido. O processo produz incrementos do produto que est em desenvolvimento frequentemente dando assim ao cliente sempre uma verso de avaliao. O processo SCRUM fornece a habilidade de declarar o produto pronto sempre que necessrio (porque a concorrncia acabou de entregar, porque a empresa precisa de dinheiro, porque o cliente precisa das funes, porque foi para essa data que foi prometido). (PRESSMAN, 2006, p.69).

3.3. ORGANIZAO

O SCRUM organiza as funcionalidades desejadas em uma lista que conhecida como PRODUCT BACKLOG ou Backlog do Produto que cresce e muda medida que o projeto avana. O Backlog do Produto definido durante as reunies onde participam os envolvidos no projeto que so compostos pelos papeis do PRODUCT OWNER, SCRUM MASTER e o SCRUM TEAM, assim como qualquer pessoa interessada que seja um representante direto da gerncia ou do cliente. O SCRUM possui nomes para cada atividade do processo como o exemplo de uma reunio fundamental onde ocorre o levantamento de requisitos denominado Sprint Planning Meeting, essa forma de descrever os envolvidos ou as atividades da metodologia faz com que o SCRUM seja um mtodo extensvel no somente ao gerenciamento de projetos de software mas a qualquer projeto que precisa ser gerenciado de forma gil.

CICLOS - SPRINTS

O SCRUM utiliza o conceito de ciclos onde em cada encerramento de um ciclo um pacote de funcionalidades entregue ao cliente que avalia e verifica se o mesmo est de acordo com os requisitos do sistema. Os ciclos so chamados de SPRINT e so as unidades de trabalho necessrias para satisfazer a um requisito podendo ter a durao ou serem revistas a cada 7, 15 ou 30 dias. Cada unidade de trabalho composta por outras unidades menores de trabalho que so contados em perodos menores como 24 horas para cada reavaliao. definido que as SPRINTS devem ter sempre a mesma durao e quem define o tempo de cada SPRINT so os envolvidos no projeto na figura do PRODUCT OWNER em uma reunio de alinhamento do projeto. A Figura abaixo ilustra o ciclo de iterao da metodologia SCRUM.

Figura 8 SCRUM

OS PAPEIS DO SCRUM

O SCRUM trabalha com o conceito de papeis que so as definies dos envolvidos no projeto, havendo apenas trs definies para todos os envolvidos em um projeto que utiliza o SCRUM onde todos trabalham em conjunto e de forma integrada e sem hierarquia.

PRODUCT OWNER

O PRODUCT OWNER ou Dono do Produto o papel associado ao cliente que deve possuir a viso do produto e dominar a regra de negcio fornecendo o conhecimento necessrio sobre o negcio equipe de desenvolvimento, fazendo a interface entre a empresa cliente e a empresa de desenvolvimento. O PRODUCT OWNER representado apenas por uma pessoa e no por um comit, porm pode representar a vontade de um comit caso seja do desejo de algum do comit que sejam feitas alteraes nas propriedades dos itens de Backlog do produto o PRODUCT OWNER deve ser convencido da vantagem dessa alterao j que o nico responsvel por gerenciar o backlog do produto.O gerenciamento do Backlog do produto pelo PRODUCT OWNER inclui expressar claramente os itens do Backlog do produto, ordenar os itens do Backlog do produto para alcanar melhor as metas, garantir o valor do trabalho realizado pelo time de desenvolvimento, garantir que a equipe de desenvolvimento entenda os itens do Backlog e garantir que o Backlog do produto seja visvel e transparente para todos mostrando em que o time SCRUM vai trabalhar.

SCRUM TEAM

A equipe de desenvolvimento, ou SCRUM TEAM, formada pelos profissionais que realizam o trabalho de analise e desenvolvimento do sistema entregando uma verso funcional que incrementa o produto em cada SPRINT. As equipes so estruturadas e autorizadas para gerenciar e organizar o prprio trabalho e possuem todas as habilidades necessrias para criar o incremento. No h divises da equipe em subequipes, ou seja, no h domnios especficos de conhecimento como teste ou anlise de negcios todos os integrantes so reconhecidos como desenvolvedores e no h exceo a essa regra. O tamanho ideal de uma equipe de desenvolvimento para o SCRUM que seja pequeno o suficiente para manter-se gil e grande o suficiente para completar uma parcela significativa do trabalho a cada iterao. Menos de trs integrantes na equipe diminuem a iterao resultando em um ganho menor de produtividade, alm de a equipe poder encontrar dificuldades em entregar um incremento devido limitao de habilidades, uma equipe com mais de nove integrantes exige muita coordenao. No existe hierarquia dentro da equipe sendo importante que cada membro saiba das prprias responsabilidades e da importncia do seu trabalho para o sucesso de todos. Os papeis do SCRUM MASTER e do PRODUCT OWNER no participam da contagem do total de integrantes de uma equipe a no ser que eles participem do trabalho do Backlog da Sprint, ou seja, que eles tambm desenvolvam o produto.

SCRUM MASTER

O SCRUM MASTER o responsvel pelo cumprimento das prticas e regras do processo fazendo todos seguirem a teoria, auxiliando no entendimento das interaes e maximizando o valor criado pelo SCRUM TEAM. O SCRUM MASTER trabalha para o PRODUCT OWNER encontrando tcnicas efetivas para o gerenciamento do Backlog do Produto, ensinando o SCRUM TEAM a criar itens de Backlog do Produto de forma clara e concisa, compreendendo e praticando a agilidade e auxiliando o PRODUCT OWNER a tomar decises. fundamental que o SCRUM MASTER conhea todo o processo para garantir que o mesmo seja seguido. O SCRUM MASTER quem gerencia o projeto com as ferramentas necessrias para acompanhar seu andamento, alm de ser uma blindagem para a equipe de desenvolvimento protegendo-a de instabilidades e fatores externos, assegurando que a equipe no se comprometa excessivamente alm de sua capacidade. O SCRUM MASTER a figura do gerente de projetos em outras metodologias, porm no SCRUM pode ser qualquer pessoa da equipe de desenvolvimento.

ELEMENTOS DO SCRUM

Os elementos do SCRUM so diferentes de outros processos, a equipe utiliza cartes com as funcionalidades que deve codificar e faz o acompanhamento do status das atividades atravs de grficos. Conforme as definies feitas pela comunidade de desenvolvimento gil do Brasil[footnoteRef:7] o SCRUM trabalha com os seguintes elementos: [7: http://desenvolvimentoagil.com.br/scrum/]

Product Backlog uma lista contendo todas as funcionalidades desejadas para um produto definido pelo Product Owner, no precisa estar completo no incio do projeto e cresce e muda medida que se aprende mais sobre o produto e seus usurios. Sprint Backlog uma lista de tarefas que o SCRUM Team se compromete a fazer em uma Sprint. So extrados do Product Backlog pela equipe com base nas prioridades definidas pelo Product Owner. Cabe a equipe determinar a quantidade de itens do Product Backlog que sero trazidos para a Sprint. Daily SCRUM uma reunio diria feita pela equipe com o objetivo de disseminar o conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia, so realizadas no mesmo lugar e hora e todos os membros da equipe devem participar. Outras pessoas podem estar presentes, mas s podero escutar. Sendo uma excelente forma para disseminar as informaes sobre o estado do projeto. Sprint Retrospective ocorre ao final de uma Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que aes sero tomadas para melhorar.

O SCRUM uma estrutura de processo feito para suportar o desenvolvimento e manuteno de produtos complexos, consiste em equipes associadas aos papeis e seguindo as regras e prticas onde cada componente dessa estrutura montada serve a um proposito especfico para o funcionamento da metodologia.

KANBAN

KANBAN um mtodo para o gerenciamento do fluxo de trabalho com nfase na entrega continua enquanto a equipe no fique sobrecarregada e comeou a ser utilizado na indstria japonesa. O nome de origem japonesa e quer dizer singboard ou billboard que traduzidos para o portugus significa quadro de avisos. uma abordagem para processos evolucionrios e incrementais, foi formulado por David J. Anderson e apesar do que muitos desenvolvedores acreditam no uma metodologia de desenvolvimento. David Anderson define o KANBAN da seguinte forma: KANBAN no um ciclo de vida de desenvolvimento de software ou uma metodologia de gerenciamento de projeto! No uma forma de fazer software ou executar projetos que fazem software!. KANBAN uma ferramenta poderosa de gerenciamento de atividades e pode ser utilizado juntamente com o SCRUM conforme seus fundamentos[footnoteRef:8]. Dessa forma o SCRUM torna-se a metodologia de desenvolvimento utilizado e o KANBAN o processo de gerenciamento das atividades. [8: http://www.ontimenow.com/scrum-training/kanban-fundamentals]

3.4. A PRTICA KANBAN

Na prtica o KANBAN o gerenciamento de tarefas que so expostas em um quadro, com quatro colunas que definem o status da atividade. A Figura a seguir ilustra o funcionamento do quadro organizando as atividades de uma equipe durante um projeto.

Figura 9 KANBAN

O KANBAN uma tcnica revolucionria para o gerenciamento do fluxo de atividades que trabalhada de forma integrada ao SCRUM torna o desenvolvimento de um projeto extremamente rpido. um conceito extremamente novo e ao mesmo tempo em que desenvolvedores dentro da comunidade gil defendam seu uso integrado com o SCRUM, David Anderson afirma que; Na verdade no possvel desenvolver com apenas KANBAN. O Mtodo KANBAN por si s, no contm prticas suficientes para fazer o desenvolvimento de produtos.

caPITULO 4 - ESTUDOs DE CASO

Esse estudo de caso aborda a comparao entre o processo de desenvolvimento em cascata, tradicional metodologia de desenvolvimento de software e o processo de desenvolvimento gil SCRUM. Demostrando suas principais diferenas, vantagens e desvantagens, o estudo de caso ilustra uma breve aplicao prtica de ambos os processos e o resultado alcanado pela equipe de desenvolvimento, descrevendo a experincia obtida na implantao de dois sistemas acadmicos no Grupo Ibmec.

4. 4.1. A ESCOLHA DO PROCESSO

A escolha de um processo para o gerenciamento e desenvolvimento de uma aplicao nem sempre uma escolha fcil e o principal erro que os gerentes de projetos comentem tentar utilizar o mesmo modelo de trabalho para projetos diferentes. Projetos nunca so iguais e por mais que possuam semelhanas no se conseguem aproveitar em 100% as prticas de projetos anteriores, mesmo o gerenciamento de projetos sendo um conhecimento emprico, onde em cada projeto h o acumulo de conhecimento conforme o sucesso ou o fracasso do desenvolvimento do projeto, no h como reutilizar todo o trabalho de um projeto anterior em um prximo. A escolha de um processo para gerenciar o desenvolvimento de um projeto passa por vrias premissas, como os recursos que estaro disponveis, o tempo em que o projeto precisa ser entregue, o seu escopo, como o cliente quer trabalhar com o feedback das atividades que compem o desenvolvimento e o custo que o projeto pode alcanar so apenas alguns dos parmetros que precisam ser levados em considerao por um gerente ao planejar o gerenciamento de um projeto.

4.2. O PROCESSO EM CASCATA VS O SCRUM

O processo em cascata um modelo tradicional de desenvolvimento de software concebido para trabalhar de forma sistemtica organizando o processo de criao de um sistema. um processo clssico da engenharia de software sendo uma das primeiras abordagens a ser ensinada no meio universitrio devido sua estrutura fixa e engessada de fcil entendimento. O processo em cascata extremamente rigoroso com o cumprimento das etapas, interferindo diretamente no resultado do produto final caso alguma das etapas no seja cumprida, alm de ser um processo que exige que seja gerado um grande volume de material tcnico, que a equipe seja subdividida, ou seja, que contenha reas especifica de conhecimento como analistas de negcios e desenvolvedores e que no ocorra alteraes de requisitos durante o desenvolvimento do sistema. O processo de desenvolvimento gil SCRUM tem como objetivo gerenciar um projeto que precisa ser entregue em um prazo curto, tendo como a principal diferena com o modelo em cascata a flexibilidade de trabalho e a forma de gerenciamento. A primeira grande diferena que notada em ambos os processos na entrega do produto ao cliente, no modelo em cascata a entrega feita somente quando o projeto concludo, no SCRUM essa entrega ocorre de forma peridica atravs de pacotes denominados de SPRINT. Os conceitos das metodologias so muito diferentes, o SCRUM consegue trabalhar de forma produtiva com uma equipe pequena onde no h hierarquia e subdiviso de conhecimento onde todos os integrantes da equipe so desenvolvedores, o modelo em cascata trabalha com reas de conhecimentos especificas, um processo mais burocrtico e demanda atividades para um nmero maior de pessoas em uma estrutura maior e mais complexa de ser gerenciada.Enquanto o modelo em cascata tradicional e com muitas etapas o SCRUM dinmico e gil tratando em poucos tpicos as mesmas necessidades para qualquer tipo de projeto, a diferena conceitual entre os processos os muda completamente. Escolher bem qual processo atende melhor um desafio para o gerente do projeto que precisa entender a capacidade e os recursos que tem disponveis para um projeto. Ambos os processos tem o mesmo objetivo, porm trabalham de maneiras diferentes para atingir a meta de entregar um sistema ao cliente com qualidade, dentro de um prazo e custo estabelecidos.De uma forma geral pode ser entendido que o SCRUM agiliza o desenvolvimento de software atravs da constante comunicao entre os envolvidos no projeto e aceitando as mudanas impostas a qualquer momento do projeto, ao contrario do modelo em cascata que no permite alterao de requisitos e mantm a equipe do projeto distante do usurio durante a o desenvolvimento do sistema. As duas metodologias possuem fraquezas e acertos como apontado nesse documento de estudo em tpicos anteriores e escolher qual metodologia utilizar depende desde a maturidade da empresa e seus profissionais at o negocio que o projeto deve atender. Ambos os processos oferecem estruturas e ferramentas como desafios para a construo de sistemas e dominar qualquer uma das metodologias coloca a empresa que as utiliza na frente de seus concorrentes em um mundo onde a organizao vital para o sucesso de um trabalho.

4.3. ADOTANDO UM MODELO NA PRTICA I

A adoo de uma metodologia extremamente fundamental para o sucesso de um projeto. O processo de desenvolvimento uma forma de gerenciar as atividades necessrias para que um projeto seja concludo de forma a atender aos usurios. Com o inicio da era digital as empresas se viram obrigadas a informatizar seus negcios e automatizar processos para ganhar competividade, produzindo mais com menos e assim garantir tanto a expanso do negocio da empresa quanto manter-se viva em um mercado cada vez mais dinmico.

O PROJETO

O primeiro estudo de caso prtico desse trabalho de monografia ocorreu sobre a implantao de um sistema de Rematrcula Online das Faculdades Ibmec com o escopo para atender a demanda de rematrcula dos alunos das unidades do Rio de Janeiro, Braslia e Belo Horizonte. Outra necessidade atendida pelo projeto seria a atualizao tecnolgica, necessria devido obsolescncia da tecnologia que vinha sendo utilizada. O projeto possua como escopo ainda diminuir a carga de trabalho da secretria e da rea financeira, automatizando os processos de renovao financeira de matricula e a liberao dos alunos para seleo de disciplinas. O escopo principal do projeto era de disponibilizar aos alunos aptos acadmica e financeiramente as disciplinas disponveis conforme currculo e curso, com a necessidade do aluno cursar as matrias obrigatrias, alm de matrias eletivas e equivalentes.

O PLANEJAMENTO

Foi decido pela empresa que o projeto seria desenvolvido internamente, no seria contratado terceiros para o desenvolvimento, alocando assim todos os recursos disponveis da rea de T.I para o desenvolvimento. A equipe composta por trs analistas de negcios de T.I e quatro desenvolvedores, alm de um gerente de projetos e um coordenador de sistemas seriam os responsveis por documentar, analisar, modelar, desenvolver, testar e implantar o sistema para as trs unidades da empresa em um prazo de trs meses. Foram escolhidas tecnologias modernas para o desenvolvimento do sistema e para o armazenamento e gerenciamento de dados, uma arquitetura cliente-servidor, a utilizao do paradigma de programao orientada a objetos e o processo de desenvolvimento em cascata. O DESENVOLVIMENTO

Seguindo a metodologia do processo em cascata, o escopo foi montado em reunies pelo gerente de projetos e pelos usurios das reas com o acompanhamento dos analistas funcionais que fizeram o levantamento de requisitos documento-os atravs de fluxogramas, diagramas UML e casos de uso, na primeira etapa foram levantadas as funcionalidades que o sistema deveria ter. Logo aps a fase de levantamento teve inicio a fase de projetos, onde foram feitos toda documentao necessria para serem passadas aos desenvolvedores e assim iniciar a fase de implementao, casos de uso, diagramas entidade relacionamento e as listas de atividades foram alguns dos recursos utilizados pelos analistas funcionais para detalhar e auxiliar os desenvolvedores do projeto. Durante a fase de implementao os desenvolvedores foram divididos em duas equipes onde a primeira realizou as atividades de programao do sistema referente a camada de aplicao e a outra equipe trabalhou na estrutura do banco de dados criando as tabelas e seus relacionamentos e as declaraes sql necessrias para o funcionamento do sistema. Essa diviso ocorreu em uma tentativa de se obter ganho de tempo e produtividade separando por rea de conhecimento os recursos disponveis. Aps o desenvolvimento o sistema foi testado por uma empresa especializada que foi contratada para avaliar o desempenho da aplicao utilizando ferramentas que analisaram a quantidade de acessos simultneos entre outros requisitos. Esse teste foi fundamental para dimensionar o que seria necessrio para implantar o sistema em produo de forma correta. Aps os testes validados e homologados o sistema foi implantado para os usurios da empresa atendendo da forma que esperavam aos requisitos e a demanda existente.

A ENTREGA DO PROJETO

O gerenciamento de um projeto no passa apenas pela escolha de um processo para o acompanhamento das atividades pertinentes ao desenvolvimento mais abrangente, preciso planejar cuidadosamente como administrar algo naturalmente dinmico. O sucesso de um projeto relativo e pode ser medido pela expectativa do usurio onde no necessariamente um projeto entregue no prazo, dentro do custo acordado ou funcionando significa que o mesmo foi bem sucedido. Muitas vezes os projetos de desenvolvimento de sistemas no so concludos de forma satisfatria tanto por requisitos mal levantados at a falta de planejamento. Apesar de o projeto ter sido entregue, a utilizao do processo em cascata trouxe contratempos principalmente durante a codificao do sistema. A forma linear de trabalhar no permitia que se avanasse para outras atividades e assim houve estagnao de recursos que ficaram ociosos em determinado momento. Foi de consenso de toda a equipe envolvida que o processo burocrtico e obsoleto para projetos atuais que demandam de uma agilidade maior para o desenvolvimento e entrega em um curto prazo e com poucas pessoas.

4.4. ADOTANDO UM MODELO NA PRTICA II Um processo de desenvolvimento deve sempre ser adaptado conforme a realidade da empresa que ir empregar e utilizar o mtodo, sendo essencial que todos que estejam envolvidos nas atividades que o processo gerencia entendam os conceitos do mtodo e acima de tudo as prprias responsabilidades. Os processos de desenvolvimento so experincias de conhecimento emprico, onde a cada projeto bem sucedido o gerente deve anotar as falhas ocorridas durante o processo para que no ocorra mais, aprendendo dessa forma em como chegar em um processo enxuto e preciso.

O PROJETO

O segundo estudo de caso prtico que esse trabalho de monografia apresenta de um sistema acadmico proposto a permitir que os candidatos a uma vaga dos cursos de ps-graduao das Faculdades Ibmec pudessem realizar seu cadastro e matricula atravs da internet, cadastrando seus dados pessoais e os dados necessrios para a matrcula, escolhendo o curso e optando por um plano e forma de pagamento.

O PLANEJAMENTO

Aps um projeto utilizando o processo em cascata e visto internamente como burocrtico e mal sucedido no ponto de vista gerencial, a implantao de um novo sistema teria que ser diferente e mais dinmico dessa forma o gerente de projetos responsvel decidiu prolongar o tempo de analise e planejamento do escopo do projeto. Ao fim foi decidido que seria utilizado um processo de desenvolvimento gil devido ao tamanho da equipe disponvel, quatro analistas para o desenvolvimento e pelo disponvel para a entrega do projeto. Dessa forma a equipe optou por utilizar a metodologia Scrum para o gerenciamento do projeto, acreditando se tratar do processo que melhor se encaixava a realidade da equipe no momento do projeto. Foram definidos ento os papeis de cada envolvido no projeto e acertados os prazos e o escopo do projeto que mais uma vez seria desenvolvido internamente pela equipe de T.I.

O DESENVOLVIMENTO

O projeto foi desenvolvido utilizando a metodologia Scrum devidamente seguida por todos os envolvidos onde na primeira instancia foi definido o Product Owner, o Scrum Master e o Scrum Team. As atividades foram acompanhadas atravs de Sprints dirias, semanais e mensais. A equipe se manteve motivada durante todo o ciclo de desenvolvimento da aplicao e conseguiu cumprir os prazos e requisitos, j que a cada nova iterao o usurio testava e validava as funcionalidades desenvolvidas, facilitando o trabalho dos desenvolvedores e tornando dinmico o processo de desenvolvimento.

A ENTREGA DO PRODUTO

Aps o desenvolvimento o sistema foi implantando em produo, onde para os usurios chaves que administram as matriculas dos cursos de ps-graduao todos os requisitos foram cumpridos e atenderam a demanda existente, sendo considerado um projeto bem sucedido e deixando uma boa impresso.

4.5. TRABALHOS FUTUROS

A proposta desse trabalho foi de analisar os processos de desenvolvimento em cascata e o Scrum, realizando uma comparao entre os processos de desenvolvimento em cascata e o processo de desenvolvimento gil Scrum. Para trabalhos futuros pode ser estudado mais profundamente as tcnicas do gerenciamento de projetos de software, com a aplicao das tcnicas necessrias e fundamentais para uma entrega bem sucedida, alm de como avaliar o nvel de maturidade da empresa que realiza o desenvolvimento, como levantar e avaliar os processos da empresa. Esses so apenas alguns itens de extrema importncia na gerencia de projetos e devem ser observados com ateno por qualquer gerente de projetos que queira ser bem sucedido.

Concluso

Para que um projeto seja bem sucedido essencial o correto gerenciamento das atividades utilizando tcnicas de engenharia de software. A engenharia de software emprega a utilizao de processos de desenvolvimento que estabelece regras e padres que devem ser seguidos por todos os profissionais atuantes nos projetos de desenvolvimento de software. Apenas a utilizao dos conceitos dos processos de desenvolvimento de software no garante a qualidade do produto final gerado, para isso se faz necessrio que seja seguido de forma metdica todos os passos inseridos no processo escolhido, outro fator importante para o sucesso de projetos nas empresas o nvel de maturidade que os processos da referida empresa possuem. Uma organizao que no possui os seus processos bem definidos ter enormes dificuldades para realizar qualquer tipo de projeto, desde a implantao de sistemas digitais para automatizar os processos internos at mesmo melhorias em infraestrutura ou servios.Os processos de desenvolvimento de software foram concebidos pela engenharia de software para organizar o catico ambiente de programao de sistemas. No existe um processo perfeito e sim processos que melhor se adaptam a realidade das equipes e empresas. Optar por um processo no uma tarefa trivial sendo necessrio ao responsvel conhecimento e experincia para optar corretamente por algo que ir atender as necessidades de todos os envolvidos em um projeto.Com esse trabalho foi possvel concluir que no existe processo melhor que outro e sim processo que atende de melhor forma uma determinada necessidade. Na comparao entre o processo em cascata e o Scrum ficou claro que ambos atendem ao mesmo objetivo, porm de formas diferentes. Suas diferenas conceituais demostram um pouco do esforo e conhecimento do momento em que foram concebidos e so extremamente eficientes nos dias atuais.

REFERNCIAS

FALBO, RICARDO DE ALMEIDA. Engenharia de Requisitos: Notas de Aula. Universidade Federal do Espirito Santo, 2012.

JACOBSON, I. MCMAHON, P. SPENCE, I. The Essence of Software Engineering. Addison-Wesley, 2012.

MAINART, Domingos de A. SANTOS, Ciro M. Desenvolvimento de Software: Processos geis ou Tradicionais? Uma viso crtica. Universidade Federal dos Vales do Jequitinhonha e Mucuri - UFVJM, 2010.

MILLS, HARLAN D. Software Productivity. Dorset House Publishing Softcover, 1988.

PDUA DE PAULA FILHO, W. Engenharia de Software: Fundamentos, Mtodos e Padres. 3 edio. LTC Livros Tcnicos e Cientficos Editora S.A. 2001.

PRESSMAN, R. Engenharia de Software. 6 edio.Mcgraw-hill Interamericana, 2006.

RANDELL, B. NAUR P. Software Engineering. Nato Science Committee, 1968.

SOMMERVILLE, I. Engenharia de Software. 8 edio. Pearson, 2007.

SUTHERLAND, J. SCHWABER, K. Guia do Scrum: As Regras do Jogo. Scrum.org, 2011.

YOURDON, E. Anlise Estruturada Moderna. 3 edio. Campus, 1990.

WILLIAMS, S. A Unified Theory of Software Evolution. Salon, 2002.