Modelos de Processos de Software

Pedro Henrique D. Valle1, Ranieri de B. Moreira1, Ricardo F. Vilela1 Instituto de Cincias Matemticas e de Computao Universidade de So Paulo (USP) Caixa Postal 668 13560-970 - So Carlos SP Brasil
{pedrohenriquevalle,ranieribm,ricardovilela}@usp.br

Resumo. No incio do software no existia nenhum mtodo ou modelo para seu desenvolvimento. Com o passar do tempo essa falta de organizao comeou a gerar softwares com inmeros problemas, tais como: no se atendiam aos prazos e custos estabelecidos, possuam baixa qualidade e no atendiam aos requisitos iniciais. Os processos de software surgiram para suprir a necessidade de organizar o desenvolvimento do software e tentar sanar esses problemas. No incio seguiam a abordagem dos processos da engenharia de hardware, porm com o tempo, a crescente demanda por software, fez com que os processos evolussem, ganhando novas caractersticas, para atender ao alto nvel de exigncia do mercado. Foram criados diferentes modelos que atendiam a necessidades diferentes. Sendo assim, esse artigo tem como principal objetivo elencar alguns modelos de processo de software e suas caractersticas. Alm disso, procura-se analisar e comparar os modelos para auxiliar na escolha do processo mais adequado ao cenrio da equipe que desenvolver o software.

1. Introduo
Os problemas ocorridos na crise do software evidenciaram a necessidade da criao de mtodos sistematizados para o desenvolvimento de software. Dentre os mtodos propostos para auxiliar no desenvolvimento de sistemas, os modelos de processos de software tem se destacado, pois podem auxiliar a equipe de desenvolvimento na elaborao do projeto e na comunicao. Alm disso, fornecem benefcios que se aplicam ao produto final. De acordo com Pfleeger (2004), a qualidade do software produzido est grande parte ligada ao processo utilizado para o desenvolvimento. Um modelo de processo de software uma simplificao de um processo de software, o qual composto pelo conjunto de atividades e artefatos desenvolvidos durante o desenvolvimento do software. Independente do modelo adotado, existem quatro atividades fundamentais que devem ser seguidas. Essas atividades so: i) Especificao do Software, que est relacionado com a definio das funcionalidades e as restries do software; ii) Desenvolvimento do Software, envolve a construo do software atendendo suas especificaes; iii) Validao do Software, necessrio a avaliao do software para garantir que o mesmo atenda as necessidades do cliente; e iv) Evoluo do Software, o software deve atender as novas requisies do usurio e implementar as novas funcionalidades (SOMMERVILLE, 2003). Devido a heterogeneidade dos sistemas desenvolvidos, houve a necessidade de criar diferentes modelos de processos de software para cenrios distintos. Dentre os

mais conhecidos esto: o i) modelo tradicional: que tem como caracterstica planejar todas as atividades do projeto antes de comear a executa-las, dividido em etapas e/ou fase para a construo do produto; ii) modelo evolucionrio: onde o principal objetivo desenvolver um sistema inicial e em seguida submete-lo a uma avaliao com usurios. Desta forma, ser possvel realizar o aprimoramento em verses posteriores at que o sistema esteja de acordo com as necessidades dos clientes; e iii) modelos geis: os quais foram desenvolvidos para serem utilizados por pequenas equipes que normalmente permanecem no mesmo local de trabalho, podendo utilizar de conversas informais sobre o desenvolvimento do sistema (SOMMERVILLE, 2003; PRESSMAN,2011). Sendo assim, o principal objetivo deste trabalho demonstrar os diferentes modelos de processos de software, indicando diferentes cenrios que os mesmos podem ser utilizados no desenvolvimento de um software. Alm disso, apresentado uma discusso sobre as vantagens e desvantagens de cada um dos modelos proposto por este trabalho. Este trabalho est organizado da seguinte forma: a Seo 2 apresenta os modelos de processos de software. A Seo 3 apresenta um modelo de avaliao para auxiliar na escolha do modelo de processo de software. Por ltimo, na Seo 4 so apresentadas as consideraes finais deste trabalho.

2. Modelos de Processos de Software

Cascata O modelo cascata, tambm conhecido por ciclo de vida clssico, ganhou esse nome por sugerir uma abordagem sequncia para o desenvolvimento de software, onde cada etapa do desenvolvimento cede espao para a prxima quando est finalizada e validada (PRESSMAN, 2011). As fases do modelo cascata compreendem: Levantamento de requisitos, fase em que so listados os objetivos, as restries e os requisitos; Projeto do sistema e software, O projeto de software envolve a identificao e a descrio das abstraes fundamentais do sistema de software suas relaes; Implementao e teste de unidade, durante essa etapa o software se transforma em um programa, ou conjunto de programas, alm de ser submetido testes unitrios que verificam se cada parte atende as especificaes; Integrao e teste do sistema, nessa etapa as unidades desenvolvidas separadamente so integradas e testadas em conjunto e tambm realizada a entrega para o cliente; Suporte ou operao e manuteno, em geral essa a fase mais longa do ciclo de vida de um software, ela envolve a correo de erros e a implementao de novos requisitos encontrados aps a entrega do sistema para atender novo requisitos.

Essas so as fases tradicionais de desenvolvimento do modelo cascata, que embora tenha sido proposto por Winston Royce (ROYCE, 1970) com feedback loops, em geral utilizado como um modelo sequencial sistemtico e linear, como visto na Figura 1 (PRESSMAN, 2011).

Figura 1: Fases do modelo de processo Cascata

O modelo Cascata estruturou os projetos de software, pode-se dizer que as vantagens desse modelo so a separao em fases sequenciais, a documentao constante e pesada (TARHAN A., 2013) e a proximidade com outros modelos de processos de engenharia (SOMMERVILE, 2007). Em contrapartida, projetos de software raramente seguem um fluxo linear e sequencial, existe a dificuldade, por parte do cliente, em listar todas as necessidades logo no inicio do projeto e uma verso funcional do software pode ser entregue somente quando o projeto estiver em fases finais (PRESSMAN, 2011). Este modelo apresenta uma primeira tentativa de organizar o caos do desenvolvimento de software, porm fica claro que a abordagem sequencial e linear se transforma em um fator crtico quando no se tem requisitos bem definidos e pouca probabilidade de mudanas. Prototipao Um dos desafios no desenvolvimento de software saber o que construir, uma vez que, os clientes em sua maioria nem sempre possuem uma viso holstica do problema a ser resolvido por meio de um sistema computacional. Em situaes como esta, a prototipao pode ser a melhor a abordagem a ser adotada. (PRESSMAN,2011) A prototipao consiste na implementao de verses iniciais do software a ser desenvolvido que possuem apenas uma parte do sistema, tambm conhecidas como prottipos. O prottipo usado para demonstrar conceitos, experimentar opes de projeto e descobrir novos requisitos do software. Outra caracterstica relevante sobre os

Figura 2: O paradigma de prototipagem (adaptado)

prottipos a capacidade de atuar tanto no levantamento de requisitos, para validao dos requisitos de sistema, quanto no processo de desenvolvimento, visando o estudo de solues especificas do software e apoio no projeto de interface do usurio (SOMMERVILLE, 2011). A Figura 2, apresenta o paradigma de prototipao. O paradigma de prototipagem inicia com a fase de comunicao onde acontece a definio dos requisitos. Cliente e desenvolvedor encontram-se com o objetivo de definir os objetivos gerais do sistema, e identificar as necessidades do usurio. Com o levantamento de requisitos realizado, a equipe de desenvolvimento concentra-se na representao dos aspectos de softwares que devem estar visveis aos usurios, esta etapa compreende a atividade de projeto rpido que aps concluda permite a construo do prottipo. O prottipo implementado e avaliado pelos stakeholders, que fornecem feedback usado para refinar os requisitos. importante salientar que esse processo passa por diversas iteraes at que o software seja concludo (PRESSMAN, 2011). No obstante, o desenvolvimento de software com prototipao apresenta algumas desvantagens como: i) necessidade de vrias iteraes para o refinamento do prottipo; ii) possibilidade de que o prottipo seja utilizado como produto final, sem que a qualidade seja devidamente analisada; e iii) em alguns casos os prottipos so caros de se produzir, em termos de tempo e custo (SHAMS-UL-ARIF & GAHYYUR, 2010). RUP O Rational Unified Process, ou RUP, consiste na estrutura de um processo de engenharia de software produzido e comercializado pela Rational Software.1 O RUP composto por algumas das melhores prticas de desenvolvimento de software, alm de fornecer uma abordagem disciplinada para a atribuio e gesto de tarefas e responsabilidades em uma organizao de desenvolvimento de software. De acordo com
1

Famlia de software da IBM para desenvolvimento, suporte, gerncia, construo e desenvolvimento de projetos de desenvolvimento de software.

Kroll e Kruchten (2003), ao adotar o RUP como modelo de processo, as equipes de desenvolvimento podem produzir softwares de qualidade que atendam s necessidades dos usurios, alm de cumprir o cronograma e o oramento planejado. Ao passo que os modelos de processos convencionais apresentam uma viso nica do processo, o RUP trata essa abordagem de forma diferente e oferece uma abordagem em trs perspectivas: i) perspectiva dinmica que apresenta as fases do modelo ao longo do tempo; ii) perspectiva esttica que composta pelas atividades realizadas no processo; e iii) perspectiva prtica, que sugere prticas a serem adotadas durante o processo (SOMMERVILLE, 2011). Os aspectos e caractersticas do modelo RUP, encontram se divididos graficamente em duas dimenses: Dinmica (horizontal), que expressa os ciclos, iteraes e marcos no processo, e Esttica (Vertical) onde so expressas as atividades, disciplinas e artefatos do projeto. Essas caractersticas podem ser observadas na Figura 3.

Figura 3: Modelo de Processo Rational Unified Process

O RUP um modelo constitudo por fases que identificam quatro fases distintas no processo de software (Iniciao, Elaborao, Construo e Transio), as mesmas so descritas a seguir. Iniciao: A meta desta fase atingir o consenso entre os investidores sobre os objetivos do ciclo de vida do projeto, esta fase possui grande nfase para os esforos de novos softwares, pois existem riscos de negcios e de requisitos que devem ser levantados para continuao do projeto. Elaborao: Esta fase concentra-se em compreender o objetivo principal do sistema, estabelecer a arquitetura, desenvolver o plano de projeto e identificar os riscos do projeto.

Construo: A fase de construo envolve o projeto, programao e testes do sistema, que aps concludas possvel obter um sistema em funcionamento, bem como a documentao associada pronta para ser entregues aos usurios. Transio: A meta desta fase de fato a transio do sistema do ambiente de desenvolvimento para o cenrio real do software. Ao final desta fase possvel obter um software documentado e funcionando corretamente em seu ambiente operacional.

A perspectiva esttica do RUP, sugere atividades (disciplinas) que devem ser executadas ao longo do ciclo de vida do processo. Essas atividades compreendem: i) modelagem de negcios, onde os processos de negcios so modelados por meio de representaes de casos de uso; ii) Requisitos, nesta disciplina os atores que interagem com o sistema so identificados e casos de usos so utilizados para modelar os requisitos do sistema; iii) Anlise e Design, a meta desta disciplina concentra-se em transformar os requisitos em um design do sistema a ser desenvolvido, desenvolver uma arquitetura do sistema e adaptar o projeto para que se adapte ao ambiente de implementao; iv) Implementao, os componentes do projetos so implementados e estruturados em subsistemas de implementao; v) Teste, A disciplina de teste opera como um fornecedor de servios para as demais disciplinas de diversas maneiras. No entanto, os testes tem como principal objetivo a avaliao da qualidade do produto; vi) Implantao, nesta etapa do processo o software lanado e distribudo aos usurios e implantado em seu ambiente de operao; vii) Gerenciamento de Configurao e mudanas, esta disciplina essencial para controlar os vrios produtos de trabalho produzidos por diversas pessoas que trabalham em um mesmo projeto. Este controle evita confuses dispendiosas, e assegura que os produtos desenvolvidos no entrem em conflito; viii) Gerenciamento de projeto, no gerenciamento de projeto a finalidade fornecer uma estrutura para gerenciar o projeto, prover orientao prtica para o planejamento e formao de equipe, alm de fornecer uma estrutura para gerenciar riscos; e por ltimo ix) Ambiente, que fornece ao cenrio do software o suporte para o projeto. A perspectiva prtica em torno do RUP apresenta prticas de engenharia de software que so recomendadas no desenvolvimento de softwares (SOMMERVILLE). As prticas recomendadas so: Desenvolver softwares iterativamente. Planejar novas funes durante o desenvolvimento, com base nas prioridades do cliente; Gerenciar os requisitos. Realizar a documentao dos requisitos de forma concisa, e acompanhar suas mudanas; Usar arquiteturas baseadas em componentes. Estruturar a arquitetura do sistema baseada em componentes, ou seja, desenvolvimento de arquiteturas complexas a partir de unidades bem especificadas e testadas; Modelar o software visualmente. Utilizar diagramas UML para representar vises estticas e dinmicas do software; Verificar a qualidade do software. necessrio uma ateno em assegurar que software atenda aos requisitos de qualidade;

Controlar as mudanas do software. Com a constante mudana em softwares com desenvolvimento iterativo necessrio controlar as mudanas por meio de ferramentas de gerenciamento de configurao.

O modelo RUP oferece um processo robusto e definido com a gerao de artefatos importantes, no entanto para pequeno projetos o RUP se torna complexo e trabalhoso, exigindo assim um alto nvel de experincia da equipe de desenvolvimento. Espiral O modelo de processo de software espiral, foi desenvolvido por Boehm (1988) e hoje bastante conhecido pelos desenvolvedores de software. Esse modelo de processo abrange as melhores caractersticas dos modelos cascata e prototipao, adicionando a etapa de anlise de risco que nenhum dos modelo citados anteriormente contemplam. Cada loop na espiral demonstra uma fase do processo de desenvolvimento do software. (PRESSMAN, 2011). A Figura 4 apresenta quatro setores que representam quatro atividades importantes no desenvolvimento do software, que so:

Figura 4: Modelo de processo de software em espiral de Boehm (1988).

Definio dos objetivos: So definidos os objetivos especficos para essa etapa do projeto. Alm disso, apresentado as restries do projeto e um plano detalhado para o gerenciamento de riscos no projeto. Avaliao e reduo de riscos: Para os riscos identificados no projeto, realizado uma anlise detalhada, verificando quais so os passos necessrios para reduzir esses riscos.

Desenvolvimento e validao: De acordo com a avaliao dos riscos no projeto escolhido o modelo de desenvolvimento do software. Planejamento: O projeto revisado, verificando a necessidade de continuar com o prximo loop. Caso seja necessrio projetado novos planos para as prximas fases do desenvolvimento do software.

O modelo espiral parte do princpio de que a forma do desenvolvimento de software no pode ser completamente determinada na fase inicial do projeto. Esse modelo exige considervel experincias para determinao de riscos no projeto, desta forma poder se ter sucesso no desenvolvimento do sistema (PRESSMAN, 2003). Incremental O modelo de desenvolvimento incremental foi proposto por Mills (1980), com o objetivo de reduzir retrabalhos no processo de desenvolvimento do sistema. Alm disso, este modelo permite aos usurios a possibilidade de adiar decises relacionados aos requisitos antes que os mesmos tenham alguma experincia com o sistema. O modelo de desenvolvimento incremental pode ser observado na Figura 5.

Figura 5: Desenvolvimento Incremental

No desenvolvimento incremental, os clientes listam as funcionalidades que sero oferecidas pelo sistema. Em seguida os clientes listas quais funcionalidade so mais importantes e menos importantes para eles. Posteriormente definido incrementos de entregas, no qual estes apresentam algumas funcionalidades do sistema. Desta forma, o cliente poder utilizar partes do sistema que possui maior prioridade (MILLS, 1980 e PRESSMAN, 2011).

Aps os incrementos serem definidos, so utilizados diferentes modelos de desenvolvimento, de acordo com cada particularidade do incremento. Os requisitos elencados em incrementos futuros podero ser modificados, j os do atual incremento no podero ser modificados. A cada novo incremento desenvolvido, estes so integrados aos j existentes. Segundo Pressman (2003), o desenvolvimento incremental apresenta algumas vantagens, como por exemplo: 1. Os clientes no precisam esperar para utilizar o sistema, at que todas suas funcionalidade estejam implementadas; 2. Os clientes podem utilizar os incrementos j desenvolvidos como prottipos e permitindo utilizar a experincia adquirida em incrementos futuros; 3. Menor probabilidade de fracasso no desenvolvimento completo do sistema, pois alguns incrementos sero entregues com sucesso ao cliente; 4. As funes prioritrias do sistemas geralmente passam por maior parte dos testes, pois estas sero desenvolvidas primeiro. Sendo menos provvel que os clientes encontrem falhas nas partes mais importantes do software; Desta forma, possvel observar que modelo de desenvolvimento incremental aborda caractersticas do modelo clssico (cascata) e particularidades dos modelos evolucionrios. Desenvolvimento Baseado em Componentes O modelo de desenvolvimento baseado em componentes (componente-basead development, CBD) baseado em caractersticas do modelo espiral, juntamente com caractersticas interativas. Neste modelo o desenvolvimento do sistema realizado a partir de componentes de software j desenvolvidos (classes). Sendo assim, este modelo baseado na tecnologia de orientao a objetos. As classes j desenvolvidas em outros projetos so armazenadas em uma biblioteca ou repositrios de classes. Esse modelo apresenta um sequncia de passos para o desenvolvimento do software que so: 1. Realizar a comunicao com cliente, para permitir elencar os requisitos do sistema; 2. Definir um planejamento, no qual discutido os recursos, cronograma, entre outras atividades no projeto; 3. Avaliar os riscos tcnicos e de gerenciamento; 4. Definir os novos componentes e usados em outras aplicaes; 5. Realizar a implementao, os testes e elaborar a documentao; 6. Implantao do sistema; O modelo de desenvolvimento baseado em componentes apresenta algumas vantagens, como por exemplo, na reutilizao de cdigo, reduzindo cerca de 70% no

tempo do desenvolvimento do software. Alm disso, apresenta uma reduo dos custos no desenvolvimento do projeto. Metodologias geis: Os modelos de processos de software geis surgiram como uma alternativa s abordagens tradicionais tendo em vista, principalmente, melhorar a capacidade de adaptabilidade dos processos de software. A filosofia gil prega a simplicidade, acima de tudo, algo que no encontrado nos modelos tradicionais (PRESSMAN, 2011). Produzindo uma quantidade menor de artefatos, os processos geis so largamente utilizados em projetos onde a agilidade, flexibilidade e mudanas so necessrias para atender um mercado cada vez mais exigente e acelerado. Realizar mudanas, algo intrnseco ao software atualmente, com menor impacto, em custos e tempo, possvel uma caracterstica chave para esses processos. Esse tipo de metodologia foi criado para produzir software til rapidamente. Intercalando as fases de especificao, projeto, desenvolvimento e teste o software desenvolvido de forma incremental com o feedback constante do cliente, que pode, a cada entrega, propor novas alteraes ou requisitos (SOMMERVILE, 2007). Em resumo os princpios da Agilidade que norteiam os modelos geis so: Satisfazer o cliente; Alteraes so comuns; Entrega contnua de software; Comercial e desenvolvimento devem ser um conjunto; Confie e de ambiente e apoio para motivar as pessoas envolvidas; Conversas so feitas pessoalmente e frequentemente; Software em funcionamento; Mantenha o ritmo do desenvolvimento, sempre de modo sustentvel; Mantenha a ateno em excelncia tcnica e em bons projetos; Simplicidade; autoorganizaco valiosa; Auto-avaliao contnua com ajustes, quando necessrio (PRESSMAN, 2011). Cada modelo de processo gil aplica de maneiras e em quantidades diferentes cada um dos princpios acima. As metodologias geis tambm tm como caracterstica o foco nas pessoas envolvidas em detrimento do processo em si. Extreme Programming: O XP (Extreme Programming) a abordagem gil mais utilizada no desenvolvimento de software, essa abordagem baseada em cinco valores: a comunicao, a simplicidade, o feedback, a coragem e o respeito (PRESSMAN, 2011). O XP encoraja uma comunicao efetiva entre os envolvidos no projeto, preferencialmente presencial e verbal, evitando volumes exagerados de documentao. A simplicidade alcanada pensando somente no presente, problemas e requisitos futuros so deixados para o futuro, assim pode-se projetar e implementar com facilidade atendendo somente requisitos atuais. Mantendo a proximidade com o cliente e entregando frequentemente partes do software funcionais o feedback de uso e do cliente pode, e deve, ser uma constante durante o processo de desenvolvimento. Para a implantao total de todos os pontos acima preciso coragem, uma definio melhor seria disciplina segundo Pressman (2011), um exemplo da coragem necessria seria para suportar a presso frequente pela preparao do projeto levando em considerao

requisitos futuros. Alm disso, a coragem para enfrentar todas as consequncias de no incluir os requisitos futuros no projeto atual. Respeito pela equipe, todos os envolvidos no projeto e pelo software vem em conjunto com todos os valores citados acima. O XP possui quatro atividades metodolgicas segundo Pressman (2011), o planejamento, o projeto, a codificao e o teste. O fluxo de atividades processo XP apresentado na Figura 6.

Figura 6: Fluxo do processo XP. As atividades metodolgicas envolvem o conjunto de regras e prticas do processo (SOMMERVILE, 2007). Listadas a seguir: Planejamento incremental: o planejamento feito ao longo do projeto, os requisitos so registrados como historias (algo parecido com casos de uso) e so atribudos, pelo cliente, prioridade e, pelos desenvolvedores, custo de implementao. Com esses custos e prioridades definido o que ser entregue em cada release do software. Pequenas entregas: Primeiro desenvolvido o conjunto mnimo e til de funcionalidades, aps isso so incrementadas novas funcionalidades cada entrega. Projeto simples: O projeto realizado para atender somente aos requisitos atuais. Desenvolvimento test-first: O teste unitrio automtico desenvolvido para uma nova funcionalidade antes que ela seja desenvolvida. Refatorao: O cdigo melhorado frequentemente, se mantendo simples e de fcil de manuteno.

Programao em pares: Os desenvolvedores trabalham em pares. Enquanto um desenvolve o outro realiza validao e fornece apoio para execuo de um bom trabalho. Propriedade coletiva: Todos os desenvolvedores tem acesso ao cdigo por completo, o cdigo pode ser alterado por todos e pertence a todos. Integrao contnua: Cada tarefa realizada integrada, o mais rpido possvel, ao sistema como um todo. Aps essa integrao so realizados todos os testes unitrios novamente. Ritmo sustentvel: Horas extras no so aceitas, pois com o desgaste da equipe h uma reduo na qualidade do cdigo e na produtividade. Cliente on-site: O cliente faz parte da equipe, ele responsvel por listar os requisitos e manter o feedback constante.

O modelo XP apresenta uma capacidade de suportar as mudanas continuas do mercado e, mantendo o cliente por perto, oferece uma maior integrao entre o que esta sendo desenvolvido e entregue com a viso final que o cliente tem do sistema. Em contrapartida, o modelo pouco adaptvel, e pode perder o controle, em equipes de maior porte. Alm disso, a utilizao do XP depende de maturidade e comprometimento por parte da equipe. Scrum O modelo de processo Scrum consiste em um mtodo de desenvolvimento gil de software baseado em cinco atividades estruturais: requisitos, anlise, projeto, evoluo e entrega. De acordo com Pressman (2011), o Scrum faz uso de um conjunto de padres de processos que mostraram ser eficientes para projetos com requisitos mutveis e pequenos prazos de entrega. Para cada atividade metodolgica, ocorrem tarefas que devem ser realizadas dentro de um padro de processo denominado Sprint. O trabalho empenhado em um Sprint ajustado ao problema em anlise e posteriormente definido. importante ressaltar que em diversas circunstncias o Sprint modificado em tempo real pela equipe (PRESSMAN, 2011). O fluxo de atividades do modelo de processo Scrum apresentado na Figura 7.

Figura 7: Fluxo do processo Scrum

Cada um dos padres de processos propostos pelo Scrum definem um conjunto de aes no desenvolvimento do software, sendo elas: Registo pendente de palavras (Backlog): consiste em um documento contendo as prioridades do conjunto de requisitos, ou funcionalidades do projeto que fornecem valor comercial ao cliente; Urgncias sprints: compe o conjunto de unidades de trabalho que so requisitadas para atingir um requisito estabelecido no registro de trabalho e que deve ser ajustado de acordo com o prazo estabelecido. Reunies Scrum: consiste em reunies realizadas diariamente pela equipe de desenvolvimento. Demos: envolve a entrega do incremento de software ao cliente para que o mesmo possa avaliar o produto.

O modelo Scrum oferece uma viso holstica do projeto a todos os envolvidos, diferentemente de outros modelos, alm de fornecer flexibilidade nas prioridades do produto. No entanto a ausncia de documentao e a desordem nos papis da equipe, podem prejudicar novas alteraes no software e causar dificuldade na comunicao entre as equipes.

3. Discusso
Devido as diversas caractersticas existentes entre os processos de software no uma tarefa trivial desenvolver um modelo de processo genrico que seja eficiente em todas as situaes. Sendo assim, o modelo de processo adotado para o desenvolvimento deve alinhar-se as necessidades do projeto. Para auxiliar a equipe na escolha do modelo adequado para o cenrio de desenvolvimento, foi criado o QUADRO 1. A primeira coluna do quadro composta pelas caractersticas que podem ocorrer durante o desenvolvimento, aqui denominadas por CAP (Critrios de Avaliao de Processos). Nas colunas subsequentes so expostos o modelos apresentados anteriormente neste trabalho, tendo como objetivo classifica-los de acordo com cada critrio. QUADRO 1: Critrios de Avaliao X Modelos de Processos Modelos de Processos CAP
Requisitos ocultos Equipe sem experincia Tempo delimitado Erros de implementao Alteraes durante o Cascata * * * * * Prototipao *** ** * *** ** RUP ** * * *** *** Espiral ** * * *** *** Incremental *** * ** *** *** CBD * ** *** * * XP *** * *** *** *** Scrum *** *** *** *** *

Modelos de Processos CAP

desenvolvimento Alteraes no produto final Sistemas Crticos Sistemas de grande porte ** *** *** ** ** * *** *** *** ** ** ** ** ** ** * * * *** ** * * ** * Cascata Prototipao RUP Espiral Incremental CBD XP Scrum

Para classificao do processos expostos no Quadro 1, foram estabelecidos os seguintes parmetros de avaliao: Significncia Alta (***) Significncia Mdia (**) Significncia Baixa (*)

Os critrios apresentados na primeira coluna do quadro correspondem as seguintes definies: 1. Requisitos ocultos: Tem como objetivo avaliar modelos que deparam-se com cenrios em que os requisitos ainda no possuem um bom nvel de maturidade para o desenvolvimento; 2. Equipe sem experincia: O critrio avalia a capacidade do modelo em oferecer suporte a equipes que no possuem alto nvel de conhecimento. 3. Tempo delimitado: A meta deste parmetro avaliar os processos que possuem um tempo curto para o desenvolvimento; 4. Erros de implementao: O critrio de erros observa qual a abordagem dos modelos para o tratamento de funcionalidades desenvolvidas incorretamente; 5. Alteraes durante o desenvolvimento: Tem como objetivo identificar os modelos que possuem mtodos que assegurem a insero de novas funcionalidades; 6. Alteraes no produto final: verifica-se a existncia de uma abordagem para o versionamento; 7. Sistemas crticos: Este critrio avalia os testes realizados no sistema antes que o mesmo seja inserido no ambiente operacional. 8. Sistemas de grande porte: Avalia o desempenho do modelo quando submetido ao desenvolvimento de sistemas de grande porte. Avaliao dos resultados Com os dados obtidos no QUADRO 1, possvel identificar as caractersticas dos modelos em determinadas situaes. Com os critrios utilizados nesta pesquisa, foi possvel observar: i) Os modelos que utilizam prototipao so mais adequados para projetos com requisitos ocultos; ii) Modelos que fornecem uma viso completa do

projeto e oferecem flexibilidade nas prioridades do produto, so mais indicados para equipes sem experincia, caractersticas apresentadas no modelo Scrum; iii) Para projetos que exigem um espao curto de tempo, os modelos XP, Scrum e CBD so mais indicados; iv) Erros de implementao so menos prejudiciais em projetos que possibilitam a iterao; v) Modelos geis de desenvolvimento no so indicados para projetos de grande porte que envolvam equipes geograficamente distribudas; e vi) Os modelos com maior planejamento de teste de software oferecem maior segurana para sistemas crticos, como exemplo RUP e Cascata. importante ressaltar que o resultado dessa avaliao, segue de acordo com os critrios propostos por este trabalho. No entanto existe diversos fatores que devem ser considerados na escolha de um modelo de processo.

4. Concluso
Em meados da dcada de 50, no havia processos para o desenvolvimento de software. Esses produtos eram criados a partir de conhecimentos empricos de desenvolvedores, no qual no havia etapas sistematizadas para auxiliar esse desenvolvimento. Isso gerou grandes problemas, pois os softwares produzidos apresentavam baixa manutenabilidade, muitas falhas, prazos e custos imprecisos, entre outros. Sendo assim, foi possvel perceber a necessidade da criao de modelos processos para auxiliar o desenvolvimento de software, elaborando etapas e/ou passos para o desenvolvimento desses produtos, permitindo desta forma, atender as necessidades do cliente e oferecer um bom desempenho (minimizao de falhas, boa manutenabilidade, entre outros). Dentre os modelos de processos de softwares existentes, alguns tm se destacado, como por exemplo: i) tradicional: nesse modelo, necessrio um planejamento antecipado antes do desenvolvimento do software, pois caso haja alguma alterao a ser realizada no produto, isso s poder ser realizado quando todas as fases desse processo forem executadas; ii) evolucionrio: neste modelo, so apresentadas verses aos usurios, para que estes analisem e verifiquem se realmente o produto atende suas necessidades; e iii) geis: geralmente so utilizados no desenvolvimento de softwares que possuem equipes de pequeno porte, utilizando conversas presenciais e informais entre os integrantes. Porm, importante lembrar que no h um modelo de processo genrico que pode ser utilizado no desenvolvimento de qualquer tipo de software, mas cada software deve utilizar um modelo de acordo com suas particularidades e circunstncias. Desta forma, a escolha do modelo de desenvolvimento deve ser feita com base nas caractersticas da equipe, no tempo de projeto, nas caractersticas do cliente, no ambiente operacional entre outros.

5. Referencias
Boehm, B.W. (1988). A spiral modelo of software development and enhancement. IEEE Computer. Kroll, P., & Kruchten, P. (2003). The rational unified process made easy: a practitioner's guide to the RUP. Addison-Wesley Professional.

Mills, H. D. (1980). Incremental software development. IBM Systems Journal, 19(4), 415-420. Pfleeger, S. L. (2004). Engenharia de software: teoria e prtica. 2 Edio, Prentice Hall. Pressman, R. S. (2011). Engenharia de software: uma abordagem profissional. 7 Edio. Ed: McGraw Hill. Shams-Ul-Arif, Q.; Khan, S.A.K.; Gahyyur (2010). Requirements Engineering Processes, Tools/Technologies & Methodologies, International Journal of Reviews in Computing. Sommerville, I. (2011). Engenharia de software. 9 Edio. So Paulo: Pearson Prentice Hall. SOMMERVILLE, Ian. (2003). Engenharia de software, 6 Ed. So Paulo: Addison Wesley. Tarhan, A. and Yilmaz S. G. (2013). Systematic analyses and comparison of development performance and product quality of Incremental Process and Agile Process." Information and Software Technology.