SUMRIO Introduo .................................................................................................................. 3 1 1.1 1.2 1.3 2 2.1 3 Modelos de ciclo de vida no processo de desenvolvimento de software . 4 Cascata ............................................................................................................

4 Espiral.............................................................................................................. 5 Modelo Iterativo e Incremental ...................................................................... 7 Processos geis .............................................................................................8 Extreme programming ...................................................................................8 RUP .................................................................................................................. 9

Concluso ................................................................................................................ 12 REFERNCIAS ......................................................................................................... 13

INTRODUO

Neste breve trabalho trataremos sobre alguns modelos de ciclo de vida, o que nos ajudar a entender melhor como funcionam e sua repercusso no projeto. O objetivo mostrar qualidades e defeitos de alguns, vantagens e desvantagens quanto ao seu uso e aplicao sobre o projeto, bem como a repercusso na escolha de cada um.

1 MODELOS DE CICLO DE VIDA NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

1.1 CASCATA

O modelo clssico ou cascata, que tambm conhecido por abordagem top-down, foi proposto por Royce em 1970. At meados da dcada de 1980 foi o nico modelo com aceitao geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software. Comparado com outros modelos de desenvolvimento de software, este mais rgido e menos administrativo. O modelo cascata um dos mais importantes modelos, e referncia para muitos outros modelos, servindo de base para muitos projetos modernos. A verso original deste modelo foi melhorada e retocada ao longo do tempo e continua sendo muito utilizado hoje em dia. Grande parte do sucesso do modelo cascata est no fato dele ser orientado para documentao. No entanto deve salientar-se que a documentao abrange mais do que arquivo de texto, abrange representaes grficas ou mesmo simulao. Uma abordagem incorporando processos, mtodos e ferramentas devem ser utilizadas pelos criadores de software. Esta abordagem muitas vezes designada de Abordagem do Processo de Desenvolvimento. Existem trs abordagens de modelos de processo de desenvolvimento de software. Elas tentem colocar ordem numa atividade inerentemente catica. Uma vez definido o modelo de ciclo de desenvolvimento, existem trs abordagens para implement-lo: Cascata pura; Incremental; Evolucionria.

Um dos grandes problemas desse ciclo de vida a constante alterao dos requisitos, no decorrer do projeto os requisitos amadurecem, junto

com eles a equipe envolvida no desenvolvimento e a equipe de negcios, pois os negcios e o ambiente nos quais esto inseridos mudam constantemente. E devido a isso, a possibilidade de reviso e avaliao com os usurios do sistema no realizada neste modelo. Outro grave problema encontrado no modelo Cascata o fato de que os projetos que o utilizam raramente seguem o fluxo seqencial que este modelo prope. Um das maiores dificuldade que geralmente no inicio do projeto muito difcil estabelecer explicitamente todos os requisitos, ou ainda que se consiga estabelec-los, pode ser que venham a mudar ou no serem concretos devido a falta de conhecimento do negcio.

Ilustrao do Ciclo de Vida em Cascata

1.2 ESPIRAL

Durante muitos anos, o modelo cascata foi a base da maior parte do desenvolvimento de projetos de software, mas em 1988 Barry Boehm sugeriu o modelo em espiral. Do modelo em espiral para desenvolvimento de software saltam a vista dois aspectos: a anlise de risco e prototipagem. O modelo espiral incorpora-os de uma forma interativa permitindo que as ideias e o progresso sejam verificados e avaliados constantemente. Cada interao volta da espiral pode ser baseada num modelo diferente e pode ter

diferentes atividades. No caso da espiral, no foi a necessidade do envolvimento dos utilizadores que inspirou a introduo de interao mas sim a necessidade de identificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividades so repetidas at uma deciso ser tomada e o documento de especificao de requisitos ser aceito. Se forem encontrados problemas numa verso inicial do documento, reentra-se nas fases de levantamento, anlise, documentao e validao. Isto repete-se at que seja produzido um documento aceitvel ou at que fatores externos, tais como prazos e falta de recursos ditem o final do processo de engenharia de requisitos. Dentre as vantagens do modelo Espiral podemos citar que alm de utilizar a prototipao para a reduo de riscos do projeto, esse modelo possibilita que durante cada iterao do projeto sejam produzidas verses do sistema cada vez mais completas. Porm, existem algumas desvantagens, dentre elas podemos citar a dificuldade em convencer grandes clientes de que possivel controlar a abordagem evolutiva. Como a abordagem deste tipo de modelo exige consideravel experincia para especificao e avaliao dos riscos, se um grande risco no for descoberto, podero ocorrer problemas.

Ilustrao do Ciclo de Vida em Espiral

1.3 MODELO ITERATIVO E INCREMENTAL Entre as varias maneiras dos desenvolvedores decidirem como organizar o desenvolvimento em verses, as mais populares so: Desenvolvimento Incremental; Desenvolvimento Iterativo.

No desenvolvimento Incremental, o sistema, como descrito e especificado na documentao dos requisitos, dividido em subsistemas por funcionalidades. As verses so definidas, comeando com um pequeno subsistema funcional e, ento, adicionando mais funcionalidades a cada verso, ou seja, um processo lento que visa melhorias somente a cada verso nova. Em contrapartida, o desenvolvimento Iterativo entrega um sistema completo desde o inicio e muda a funcionalidade de cada subsistema a cada nova verso caso seja necessrio. Para ilustrar o caso, poderamos pensar um sistema de cadastro de clientes que tenha a funo de colher nome, data de nascimento e endereo. No desenvolvimento Incremental a primeira verso viria apenas colhendo o nome, a segunda a data de nascimento e a terceira o endereo, ao passo que no desenvolvimento Iterativo j na primeira verso teramos como cadastrar nome, data de nascimento e endereo, ficando para as prximas verses o aprimoramento dessas funcionalidades. Em muitos casos utilizado um misto de Incremental com Iterativo e tem se mostrado til dessa forma por propiciar algumas etapas importantes como o treinamento de usurios j nas primeiras verses, mercados podem ser criados antecipadamente, etc.

2 PROCESSOS GEIS

2.1 EXTREME PROGRAMMING O Extreme Programming ou Programao Extrema, ou ainda somente XP sem sombra de duvidas uma das mais geis metodologias de desenvolvimento de software. Normalmente utilizada por pequenas e mdias equipes, em situaes onde ainda no h maturidade suficiente nos requisitos para a criao do software demandado. Por ser uma metodologia extrema, o projeto passa constantemente por alteraes e ajustes durante o desenvolvimento, por conta da inconsistncia dos requisitos. Existem quatro valores fundamentais para a metodologia de Programao Extrema: Comunicao; Simplicidade; Feedback; Coragem.

Por esses valores gerenciado o ciclo de desenvolvimento, ao receber rpidos feedbacks, possvel analisar e gerar resultados de maneira simples e, ao implementar as mudanas, garante-se ainda um trabalho de qualidade. Mesmo sendo um processo gil de desenvolvimento, a qualidade uma varivel base do projeto nesse modelo, pois, ainda que haja prorrogao nos prazos por diminuio da qualidade, estes no so compensados pelas perdas ou limitaes que podero ocorrer em todo o projeto.

3 RUP O Processo Unificado da Rational (Rational Unified Process RUP) um processo maduro, resulta da unio de vrias metodologias que o compem. O RUP usa a abordagem da orientao a objetos em sua concepo e projetado e documentado utilizando a notao UML (Unified Modeling Language) para ilustrar os processos em ao. Utiliza tcnicas e prticas aprovadas comercialmente. um processo considerado pesado e preferencialmente aplicvel a grandes equipes de desenvolvimento e a grandes projetos, porm o fato de ser amplamente customizvel torna possvel que seja adaptado para projetos de qualquer escala. Para a gerncia do projeto, o RUP prov uma soluo disciplinada de como assinalar tarefas e responsabilidades dentro de uma organizao de desenvolvimento de software. O RUP possui quatro fases e nove disciplinas, onde cada fase possui um marco ou um resultado que deve ser alcanado, para que a mesma seja considerada finalizada. Fases: 1. Concepo ou iniciao: nfase no escopo do sistema A

fase de concepo contm os workflows necessrios para que as partes interessadas (stakeholders) concordem com os objetivos, arquitetura e o

planejamento do projeto. Se as partes interessadas tiverem bons conhecimentos, ento, pouca anlise ser requerida. Caso contrrio, uma anlise maior ser requerida; 2. Elaborao: nfase na arquitetura, preparao do projeto - A

fase de elaborao ser apenas para o projeto do sistema, buscando complementar o levantamento / documentao dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negcio para os projetos e inicia a verso do manual do usurio. Deve-se aceitar: Viso geral do produto (incremento + integrao) est estvel?; O plano do projeto confivel?; Custos so admissveis?;

10

3.

Construo: nfase no desenvolvimento do projeto Na fase

de construo, comea o desenvolvimento fsico do software, produo de cdigos e testes.; 4. Transio: nfase na implantao, fase final do projeto - Nesta

fase ocorre a entrega do software, realizado o cronograma de implantao e entrega, acompanhamento e qualidade do software. Nesta fase tambm realizada a capacitao dos usurios. Disciplinas: 1. Modelagem de Negcios - Modelagem de negcios, explica

como descrever uma viso da organizao na qual o sistema ser implantado e como usar esta viso como uma base para descrever o processo, papis e responsabilidades. Nessa fase, boa parte dos requisitos deve ser capturada; 2. Requisitos - Esta disciplina explica como levantar pedidos das

partes interessadas e transform-los em um conjunto de requisitos que os produtos funcionam no mbito do sistema a ser construdo e fornecem requisitos detalhados para o que deve fazer o sistema; 3. Anlise e Design - O objetivo da anlise e projeto mostrar

como o sistema vai ser realizado. 4. Implementao - O processo descreve como a reutilizao de

componentes existentes ou implementar novos componentes com responsabilidades bem definidas, tornando o sistema mais fcil de manter e aumentar as possibilidades de reutilizao. 5. Teste - O RUP prope uma abordagem iterativa, o que significa

que deve-se testar todo o projeto. Isto permite encontrar defeitos to cedo quanto possvel, o que reduz radicalmente o custo de reparar o defeito. Os testes so realizados ao longo de quatro dimenses da qualidade: confiabilidade,

funcionalidade, desempenho da aplicao, e o desempenho do sistema. 6. Implantao Seu objetivo produzir com sucesso

lanamentos de produtos e entregar o software para seus usurios finais. Cobre uma vasta gama de atividades, incluindo a produo de releases externos do software, a embalagem do software e aplicativos de negcios, distribuio do software, instalao do software e prestao de ajuda e assistncia aos usurios. Embora as

11

atividades de implantao esto principalmente centradas em torno da fase de transio, muitas das atividades devem ser includas nas fases anteriores para se preparar para a implantao. Uma das principais atividades na Implantao garantir ao usuario que o software est pronto para uso; 7. Gerncia de Mudana a disciplina responsavel por manter

um controle de verses do cdigo do software de acordo com as alteraes que nele ocorreram e, tambm, reponsavel por gerenciar as necessidades do usurio em relao s alteraes solicitadas para atualizao do sistema; 8. Gerencia de Projetos Apresenta conceitos e tcnicas que

podem auxiliar no planejamento do projeto. Nela so analisados os riscos e progressos que o projeto poder conter; 9. Ambiente - enfoca as atividades necessrias para configurar o

processo para um projeto. Ele descreve as atividades necessrias para desenvolver as diretrizes de apoio a um projeto. A proposta das atividades de ambiente prover organizao de desenvolvimento de software com o ambiente de desenvolvimento de software - os processos e as ferramentas - que daro suporte equipe de desenvolvimento. Analisando sobre o RUP podemos concluir que existem

caracteristicas base para o processo de desenvolvimento de software, porm, preciso enxergar que nem todos os projetos necessitam de todas as disciplinas e fases para o seu desenvolvimento, por motivos de complexidade, tempo, recursos e, principalmente, mo de obra qualificada.

12

CONCLUSO

Para ser um Analista de Sistemas bem sucedido, necessrio ter conhecimento e domnio sobre o variados mtodos e modelos de ciclo de vida, pois muito do sucesso do projeto est envolvido na escolha do mtodo correto e da sensibilidade necessria para apontar o melhor caminho. Ao longo deste breve trabalho apresentado, pudemos ver

resumidamente sobre alguns desses modelos, dando conhecimento sobre vantagens e desvantagens, tempo de projeto, enfim, variveis que determinam o sucesso ou o fracasso de um projeto de software.

13

REFERNCIAS WIKIPEDIA. IBM Rational Unified Process. Disponvel em < http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process> Acesso em 05/09/2010. TANAKA, Simone Sawasaki. Anlise de Sistemas I. So Paulo: Pearson Prentice Hall, 2009.