SISTEMA DE ENSINO PRESENCIAL CONECTADO ANLISE E DESENVOLVIMENTO DE SISTEMAS FBIO EDUARDO COSTA DA HORA

ANLISE DE SISTEMAS I

Barreiras 2009

FBIO EDUARDO COSTA DA HORA

ANLISE DE SISTEMAS I

Trabalho apresentado ao Curso Anlise e Desenvolvimento de Sistemas da UNOPAR Universidade Norte do Paran, para a disciplina Anlise de Sistemas I. Orientador: Profa. Simone Sawasaki Tanaka

Barreiras 2009

SUMRIO 1 MODELOS DE CICLO DE VIDA NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE..................................................................................................................6 REFERNCIAS..........................................................................................................11

1 MODELOS DE CICLO DE VIDA NO PROCESSO DE DESENVOLVIMENTO DE

SOFTWARE

1.1 MODELO CASCATA O conceito do modelo cascata foi proposto em 1970 por W. W. Royce, no qual atravs de uma srie de artigos, no qual o mesmo no citava o nome cascata, mas em seus artigos exprimia um conceito inicial daquilo que chamamos hoje de desenvolvimento em cascata onde se usa um padro seqencial que flui para a frente, como uma cascata, atravs das fases de Anlise de Requisitos, Projeto, Implementao, validao, integrao e manuteno de software. Quando comeou a ser utilizado, o modelo em cascata trouxe novas qualidades ao desenvolvimento, disciplinando o desenvolvimento, com suas atividades claramente definida, determinadas em planejamento anterior e com possibilidade de gerenciamento durante sua execuo. Todas as atividades so executadas tendo seus requisitos totalmente determinados e separa atividades de definio e design da atividade de programao. Suas principais crticas vem do fato de ser linear, rgido e monoltico. Seguindo sua metodologia, cada atividade s poder ser iniciada quando a atividade anterior estiver finalizada por completo e por ser rgido e monoltico, no inclui nem usurios e nem o cliente durante o seu processo de desenvolvimento, no possibilitando que o cliente possa ter acesso ao produto antes de sua entrega e que possa encontrar eventuais falhas no software. A falta de flexibilidade do fluxo seqencial deste modelo dificulta muito o desenvolvimento, no permitindo, por exemplo, que se possa voltar atrs para efetuar eventuais modificaes. A no abrangncia de caractersticas partculas de software, como ser conceitual, por exemplo, falta de modelos tericos, tcnicas e ferramentas adequadas mostram que a falta de flexibilidade neste modelo. Estimativas de prazos e recursos humanos no costumam ter preciso e normalmente necessrio revisar o planejamento de atividades, algo que no possvel neste modelo devido a sua estrutura rgida e seqencial.
O modelo cascata pode ser muito til para ajudar os desenvolvedores a descrever o que eles precisam fazer. Sua simplicidade o torna fcil de explicar aos clientes no famaliarizados com o desenvolvimento de software. Ele explicita os produtos intermedirios necessrios para comear

o prximo estgio de desenvolvimento. Muitos outros modelos mais complexos so apenas variaes do modelo cascata, incorporando loops de feedback e atividades extras. (ENGENHARIA DE SOFTWARE TEORIA E PRATICA, Shari Lawrence Pfleeger, 2003).

Podemos concluir observando este modelo que o mesmo extremamente eficaz nas situaes em que se possui todos os requisitos do software, no vai ser necessria a interveno do cliente, a equipe e os prazos esto plenamente definidos e no h a necessidade de revisar planejamento de atividades. Em situaes onde estas situaes no podem ser preenchidas, no se deve utilizar este modelo, pois sua rigidez e linearidade impedem mudanas repentinas e podem fazer com que se percam prazos.

1.2 CODIFICA-REMENDA O codifica-remenda um modelo considerado catico, pois parte-se de uma ou nenhuma especificao e inicia-se imediatamente o desenvolvimento, remendando o cdigo na medida em que os erros acontecem, onde nenhum processo de desenvolvimento especfico seguido. Mesmo sendo um modelo considerado catico, hoje um dos mais utilizados pelos desenvolvedores quando se trata de desenvolver ferramentas para uso interno ou prprio na empresa, pois h uma velocidade rpida na entrega e exige-se pouca qualidade de desenvolvimento, podendo ser corrigido a todo momento e ter uma espera na soluo dos problemas. Como no h nenhuma sofisticao tcnica ou gerencial, o modelo se torna muito atraente, o que implica num software de alto risco, que muito suscetvel a falhas e erros. Uma das principais desvantagens em sua metodologia a quase que impossibilidade de gerencia, pois no segue as fases bsicas do desenvolvimento e no se usa um processo de desenvolvimento, sem etapas, planejamento ou atividades definidas, partindo diretamente para a produo do software. Como no h nada de realmente no concreto em seu mtodo de desenvolvimento, o Codifica-Remenda no permite que se estabeleam prazos confiveis para entrega ou testes do software, mas em contrapartida permite em

seus ciclos de remendos que haja uma interao muito grande entre usurios e desenvolvedores, obtendo ao final de alguns destes ciclos um software que totalmente adequado a soluo desejada.

1.3 MODELO ESPIRAL Definido em 1988 por Barry Boehm em seu artigo A Spiral Model of Software Development and Enhancement. O modelo no foi primeiro a tratar do Densenvolvimento iterativo e incremental, mas foi o primeiro modelo a explicar o porque do modo iterativo. O modelo espiral visa prover um metamodelo que pode acomodar diversos processos especficos. Isto quer dizer que podemos unir nele as principais caractersticas dos outros modelos, adaptando-as as particularidades do software e as vrias necessidades dos desenvolvedores, onde o modelo prev prototipao, desenvolvimento evolutivo e cclico e atividades do modelo em cascata. A grande inovao deste modelo em relao aos outros est em guiar o desenvolvimento do software a partir do metamodelo gerado com base nas atividades de anlise de riscos e planejamento, realizados durante toda a evoluo do desenvolvimento. Circunstancias adversas que podem surgir durante o processo impedindo etapas ou reduzindo a qualidade do software so denominadas riscos. Um exemplo disso seria um problema em equipamentos que seriam utilizados no desenvolvimento e/ou no software final, um membro da equipe de desenvolvimento se desligando ou uma ferramenta que no pode ser utilizada. Gerir estes riscos hoje uma atividade essencial no desenvolvimento do software. O fluxo de um modelo espiral um fluxo de atividades cclico e evolutivo, com quatro estgios distintos. No primeiro estgio, determinam-se objetivos e solues, bem como alternativas e restries. No segundo estgio os riscos de todas as decises do primeiro estgio so avaliados e neste estgio j pode ser construdo um prottipo ou uma simulao deste software. No terceiro estgio inicia-se o desenvolvimento do software, incluindo-se a design, especificao, codificao e verificao, tendo como principal caractersticas que a cada especificao que surge a cada ciclo, como especificao de requisitos, do software, da arquitetura, da interface de usurio e dos algoritmos e dados, faz-se

uma verificao apropriada. No quarto estgio faz-se a reviso de todas as etapas anteriores e inicia-se o planejamento da prxima fase. Nesta fase de planejamento, com base nos resultados que se obtm dos estgio anteriores, pode-se optar por utilizar um desenvolvimento num modelo Cascata, Evolutivo ou Transformao. Se, por exemplo, no primeiro ciclo se obtiver todas as especificaes do software, optase pelo modelo cascata. Caso no ocorra, pode iniciar um novo ciclo, construindo novos prottipos e etc. Podemos concluir ento que num projeto onde h muito a se obter em dados, e h muitas mudanas e ajustes a serem feitos durante o desenvolvimento do software, o modelo espiral o modelo mais adequado.

1.4 PROTOTIPAO O modelo de prototipao uma abordagem que se baseia num viso evolutiva do desenvolvimento de software, causando efeitos em todo o processo, consistindo basicamente na gerao de verses iniciais, prottipos de um sistema com o intuito de realizar verificaes, apresentar conceitos e idias ao clientes, obter requisitos, efetuar testes e avaliar a qualidade do software antes que o mesmo venha a ser realmente construdo. O seu principal uso se d quando cliente tem os objetivos do seu software mas no possui nenhum detalhe, quando o desenvolvedor precisa testar a eficincia de um determinado algoritmo ou quando no se sabe se a Interao do usurio do software ser a ideal para o cliente, envolvendo cliente e usurio no processo de desenvolvimento. Existem diversas tcnicas para gerar prottipos, porm as mais usadas atualmente so Storyboarding, que consiste em usar imagens para descrever as situaes; Prottipo em papel, que consiste em literalmente desenhar no papel as telas, caixas de dilogos, mensagens de erro e menus; Mago de Oz, onde uma pessoa (wizard) simula todas as respostas do sistema seguindo as entradas do utilizador com uma ordem definida; Maquina de cenrios, que consiste em algumas telas onde se sustentam uma srie de informaes sobre o se e o como indo de encontro aos objetivos e expectativas do utilizador; Prototipagem rpida, que usada para reduzir os riscos dos requisitos, onde um prottipo

desenvolvido a partir de uma especificao entregue ao cliente e depois deixado de lado; Prototipagem Evolutiva, que tem por objetivo mostrar uma parte do sistema j funcional ao cliente de modo a obter um bom feedback; Um dos maiores problema ao adotar este modelo est no cliente, que muitas vezes no quer esperar a verso totalmente funcional do sistema e simplesmente adota um prottipo, exigindo alguns ajustes do desenvolvimento para tornar o software funcional. Muitas vezes a codificao utilizada para construir o prottipo pode no ser a que se deseja como definitiva e por causa desta adoo por parte do cliente, que pode ainda considerar perda de tempo o descarte de um prottipo. Em suma, o modelo prottipo pode ser muito eficaz e tambm ter um alto custo de produo e consumir uma grande soma de tempo. Tais pontos devem ser cuidadosamente avaliados em conjunto pelos engenheiros de software e o cliente.

1.5

REFERNCIAS SOBRENOME, Nome do autor. Ttulo da obra. Edio. Cidade: Editora, Ano de Publicao. PFLEEGER, SHARI LAWRENCE. Engenharia de Software: Teoria e Pratica. Edio So Paulo: Prentice Hall, 2004. Modelo em cascata. Wikipdia, a enciclopdia livre. Disponvel http://pt.wikipedia.org/wiki/Modelo_em_cascata Acesso em: 20 set. 2009. Modelo em espiral. Wikipdia, a enciclopdia livre. Disponvel http://pt.wikipedia.org/wiki/Modelo_em_espiral Acesso em: 22 set. 2009. 2

em

em

Prototipagem de software. Wikipdia, a enciclopdia livre. Disponvel em http://pt.wikipedia.org/wiki/Prototipagem_de_software Acesso em: 22 set. 2009. O Modelo em espiral. Engenharia de Software. Disponvel em http://engenhariadesoftware.blogspot.com/2007/03/o-modelo-espiral.html Acesso em: 22 set. 2009.