Processos de software

516 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
516
No SlideShare
0
A partir de incorporações
0
Número de incorporações
20
Ações
Compartilhamentos
0
Downloads
11
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Processos de software

  1. 1. DISCIPLINA DE ENGENHARIA DE SOFTWARE Processos Tradicionais de SoftwareUm processo de software é um conjunto de atividades que leva à produção de um produtode software. Os processos de software formam a base para o controle gerencial de projetos desoftware e estabelecem o contexto no qual os métodos técnicos são aplicados , os produtos detrabalho (modelos, documentos, dados, relatórios, etc.) são produzidos, os marcos sãoestabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas.Além dos processos de software, existem outros dois elementos fundamentais da engenhariade software, os quais são métodos e ferramentas.Os métodos fornecem a técnica de “como” fazer para construir software. As ferramentas deengenharia de software fornecem o apoio automatizado ou semi-automatizado para oprocesso e para os métodos. As ferramentas de engenharia de software auxiliada porcomputador (CASE – Computer-Aided Software Engineering) que existem atualmente nomercado ainda não automatizam todas as atividades dos processos, mas a maioria.Não existe um processo ideal, e várias organizações desenvolveram abordagens iteiramentediferentes para o desenvolvimento de software. A seguir são detalhados os processos dedesenvolvimento de software tradicionais mais conhecidos:MODELO EM CASCATATambém conhecido como modelo clássico.A metodologia de desenvolvimento em cascata foi desenvolvida pela marinha norte-americananos anos 60 para permitir o desenvolvimento de software militares. No modelo em cascata, oprojeto segue uma série passos ordenados. Ao final de cada fase, a equipe de projeto finalizauma revisão. O desenvolvimento não continua até que o cliente esteja satisfeito com osresultados da fase atual.A Figura 1 ilustra as fases deste modelo ou processo de desenvolvimento de software.
  2. 2. Figura 1. Fases do Modelo em Cascata.Se for necessário efetuar alguma modificação, voltar os passos de desenvolvimento do projetoé complicado. A metodologia em cascata é extremamente formal, como seria normal de seesperar de uma metodologia cuja concepção é militar. Pode-se afirmar que a metodologia emcascata é baseada em documentos e com certeza possui uma enorme quantidade de“entregáveis” e saídas que nada mais são do que documentos. Outra característica destemodelo é o alto valor dado ao planejamento. O forte planejamento inicial reduz a necessidadede planejamento contínuo conforme o andamento do projeto.A Metodologia em Cascata funciona bem quando os requisitos do usuário são rígidos e podemser conhecidos com antecedência. O sistema de navegação do ônibus espacial, por exemplo,pode ser um bom candidato para esta metodologia. Contudo, o foco em documentos paradescrever o que os clientes e usuários necessitam pode levar a problemas. Muitofrequentemente aparecem problemas de comunicação que resultam em um software de baixaqualidade. Os documentos produzidos pelo processo de desenvolvimento podem ser perfeitos,mas o produto real pode ser defeituoso ou inutilizável.De uma forma ou de outra, muitas das metodologias de desenvolvimento são variações dametodologia de Desenvolvimento em Cascata – apenas diferenciando-se uma das outras emrelação à velocidade, tipos de entregáveis e flexibilidade.A metodologia de Desenvolvimento em Cascata pode funcionar bem em ambientes rígidos efortemente controlados, como por exemplo, os militares, mas possui sérios inconvenientes nocenário comercial. No cenário comercial, somente recomenda-se usar este modelo parasistemas pequenos e simples, pois se for um sistema complexo vai demorar muito tempo atémostrar o funcionamento do sistema. Existem casos onde o contratante do desenvolvimentodo software se beneficia pela auditoria imposta pelos métodos do Desenvolvimento emCascata.
  3. 3. MODELO EM ESPIRALO objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processosespecíficos. Isto significa que podemos encaixar nele as principais características dos modelosvistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou àsparticularidades do software a ser desenvolvido. Este modelo prevê prototipação,desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata.Sua principal inovação é guiar o processo de desenvolvimento gerado a partir destemetamodelo com base em análise de riscos e planejamento que é realizado durante toda aevolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante odesenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto.São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentasque não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou queserão utilizados no produto final, etc. A identificação e o gerenciamento de riscos é hoje umaatividade importantíssima no desenvolvimento de software devido à imaturidade da área e àfalta de conhecimento, técnicas e ferramentas adequadas.O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de quatroestágios, como pode ser observado na Figura 2. Figura 2. Modelo Espiral No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições. No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. Duranteeste estágio podem ser construídos protótipos ou realizar-se simulações do software. O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design,especificação, codificação e verificação. A principal característica é que a cada especificação
  4. 4. que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, dainterface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente. O estágio 4 compreende a revisão das etapas anteriores e o planejamento da próximafase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores -decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento nummodelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, osrequisitos forem completamente especificados e validados pode-se optar por seguir o modeloCascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o,avaliando novos riscos e replanejando o processo.PROTOTIPAÇÃOA modelo de Prototipagem Evolutiva é uma abordagem que visualiza o desenvolvimento deconcepções do sistema conforme o andamento do projeto. Esta metodologia baseia-se nautilização de prototipagem visual ou modelos do sistema final. Estes modelos podem sersimples desenhos, imagens gráficas e até cópias completas em HTML do sistema esperado.Com esta abordagem visual, o cliente tem uma certeza maior do resultado final. A figuraabaixo ilustra esta metodologia. Figura 3. Prototipação EvolutivaO desenvolvimento real não inicia até que o protótipo final seja aceito. Esta metodologia é atécerto ponto bastante flexível a respeito de mudanças de requisitos; contudo, este processoprecisa de muito controle. Um ponto negativo deste modelo é que o planejamento efetivopode ser difícil e os projetos podem ser reduzidos a um ciclo Codifica-Corrige depois que odesenvolvimento é iniciado.
  5. 5. O aspecto de planejamento pode tornar-se um desafio, pois a equipe não tem certeza sobrequanto tempo levará o trabalho. Isto ocorre, em partes, porque o modelo é baseado eminterfaces, e não se preocupa tanto com as interdepêndencias de mais baixo nível. Os clientestem uma idéia de como eles querem utilizar o seu novo sistema e utilizam o protótipo comoreferência. O valor do protótipo porém, não deve ser super-estimado, pois, apesar de tudo, elenão é um software funcional. Existem riscos associados com o planejamento devido a naturezainterativa do desenvolvimento, mas eles são atenuados de certa forma através daprototipagem e ciclos de “releases” (ou versões) menores. Após o início do desenvolvimento, ogerente de projeto ou líder técnico deve concientizar aos desenvolvedores que existe umprazo a cumprir e que deve evitar um ciclo infinito de atualização do protótipo.MODELO INCREMENTALModelo iterativo e incremental é uma alternativa para solução de problemas enfrentado nomodelo cascata. Nesse modelo, considera-se o desenvolvimento do software em ciclositerativos onde uma pequena porção dos requisitos passa por todas as etapas dedesenvolvimento como em um modelo cascata. Ao final de cada ciclo de iteração têm-se umanova versão do software, a qual será incrementada a cada novo ciclo que ocorrer.Ao final de cada ciclo de iteração pode-se ter uma versão do software. Isso reduz a ansiedadee a expectativa do usuário em relação ao software. Além disso, o modelo possibilita que osoftware seja desenvolvido em módulos de acordo com a necessidade e características doprojeto.Embora pareça que o modelo imprima uma forma mais ágil de desenvolvimento, umplanejamento formal não é desprezado. A idéia das iterações desse modelo é permitir que osistema seja melhor compreendido e refinado a cada etapa. Dessa forma, a qualidade dosoftware pode ser provida gradualmente à medida que seu desenvolvimento evolui.RATIONAL UNIFIED PROCESS (RUP)A metodologia RUP (Rational Unified Process) é um processo que fornece uma metodologiadisciplinada de desenvolvimento utilizando um conjunto de ferramentas, modelos eentregáveis. A RUP se diferencia das demais metodologias por ser proprietária de umaempresa, no caso a IBM Rational.A metodologia padronizada pode ser atrativa para grandes organizações que necessitem deuma linguagem comum e ferramentas padronizadas para toda a organização. A metodologiaRUP utiliza UML (Unified Modeling Language) para comunicar os requisitos, arquiteturas emodelagens. A UML foi originalmente criada pela Rational Software (adquirida pela IBM) éatualmente é mantida pelo OMG (Object Management Group –http://www.omg.org/).Nesse modelo, considera-se o desenvolvimento do software em ciclos iterativos onde umapequena porção dos requisitos passa por todas as etapas de desenvolvimento como em ummodelo cascata. Ao final de cada ciclo de iteração têm-se uma nova versão do software, a qualserá incrementada a cada novo ciclo que ocorrer.
  6. 6. O RUP é estruturado ema duas dimensões, como pode ser observado na Figura 4:  Eixo X -Tempo: divisão do ciclo de vida em fases e iterações, mostra os aspectos do ciclo de vida do processo à medida que se desenvolve.  Eixo Y - Componentes de processo: produção de um conjunto específico de artefatos (produtos) com atividades bem definidas. Figura 4. Rational Unified Process (RUP)As fases são seqüenciais, cada uma concluída por um marco principal. Cada fase é basicamenteum intervalo de tempo entre dois marcos principais.

×