Modelos ciclo de vida

Origem: Wikipdia, a enciclopdia livre. Perceber que atividades fazem parte do processo de engenharia de software o primeiro passo para o concretizar, mas tambm importante perceber como as actividades do processo se relacionam umas com as outras para que se torne visvel todo o processo de desenvolvimento. O termo modelo do ciclo de vida utilizado para descrever um modelo que visa descrever um grupo de actividades e a forma como elas se relacionam. Os modelos mais sofisticados incluem ainda uma descrio de quando e como se deve mover de uma actividade para a prxima e os deliverables que devem ser produzidos em cada etapa. A razo pela qual estes modelos so to conhecidos o fato de ajudarem as equipes de desenvolvimento, e em particular os gestores, a obter uma viso geral do projecto de forma a ser possvel segui-lo passo a passo, saber que deliverables foram especificados, o alocamento de recursos e os objectivos propostos. Estes "modelos de ciclo de vida" ou "modelos de processos" so tipicamente produzidos a partir de uma perspectiva de que podero existir vrios modelos para o mesmo processo. Nenhum modelo capaz de dar uma viso completa de um determinado processo.

ndice
[esconder]

1 Modelos de Processos 1.1 Modelos de Atividade 1.2 Modelos de Atividade de Granularidade Fina 1.3 Modelos Papel-Ao 1.4 Modelos Entidade-Relao 2 Atividades do Processo de Engenharia de Requisitos 2.1 Levantamento de Requisitos 2.2 Anlise e Negociao de Requisitos 2.3 Documentao de Requisitos 2.4 Validao de Requisitos 3 Modelos de Ciclo de Vida 4 Modelos em Engenharia de Software e Requisitos 4.1 Modelo em Cascata 4.2 Modelo em Espiral 4.3 Caractersticas de Vrios Modelos 5 Bibliografia 6 Ver tambm 7 Ligaes externas

[editar]Modelos

de Processos

Embora este artigo seja mais focado aos modelos de ciclo de vida na engenharia de software, importante ter uma ideia dos vrios tipos de modelos de processos existentes. Os tipos de modelos de processos que podem ser produzidos dependem do uso que lhes ser dado. Poder ser necessrio um modelo para explicar como est organizada a informao de processos, um modelo que ajude a compreender e permita melhorar processos, um modelo para satisfazer certos requisitos de qualidade, etc. Alguns exemplos de modelos que descrevem processos so:

Modelo de atividades.

[editar]Modelos

de Atividade

A figura seguinte um exemplo deste tipo de modelo. Estes modelos mostram os principais processos e atividades de engenharia de requisitos e o seu sequenciamento (aproximado). Este tipo de modelos no permite forar um processo mas d uma viso geral do mesmo e so tipicamente construdos como ponto de partida para a descrio de um processo com seces separadas dando cobertura a cada caixa no modelo. Os modelos descrevem o contexto das diferentes atividades de um processo, mostrando outros processos que consomem ou produzem input de um outro.

[editar]Modelos

de Atividade de Granularidade Fina

Estes so modelos mais detalhados para um processo especfico. Podem ser utilizados para perceber e melhorar processos existentes.

[editar]Modelos

Papel-Ao

Estes so modelos que mostram o papel de diferentes pessoas envolvidas num processo e as aes que podem tomar. Estes modelos, que no so tratados mais a fundo neste artigo, podem ajudar a perceber e automatizar processos.

[editar]Modelos

Entidade-Relao

Estes modelos mostram as entradas, sadas e resultados intermdios dos processos e relaes entre eles. Podem ser utilizados num sistema de gesto de qualidade e como modelos complementares das actividades de processo.

[editar]Atividades

do Processo de Engenharia de Requisitos

Diferentes tipos de organizaes abordam a engenharia de requisitos de formas radicalmente diferentes. Uma companhia aeroespacial que se encontre a especificar sistemas de software e hardware muito complexos no utiliza o mesmo processo de engenharia de requisitos que uma outra companhia que desenvolve produtos de consumo para computadores pessoais. No entanto, as diferenas entre estes processos encontram-se geralmente no nvel de detalhe dos processos. Num nvel abstracto, todos os processos de engenharia de requisitos podem ser descritos pelo modelo mostrado na figura anterior. Antes de apresentar os modelos de ciclo de vida para o processo de engenharia de requisitos, torna-se necessrio compreender melhor as actividades nele envolvidas. As actividades do processo de engenharia de requisitos so as seguintes:

[ editar]Levantamento

de Requisitos

Os requisitos do sistema so obtidos atravs de consultas aos stakeholders, documentao do sistema, conhecimento do domnio e estudos de mercado. Este processo tambm conhecido como aquisio de requisitos ou descoberta de requisitos.

[editar]Anlise

e Negociao de Requisitos

Os requisitos so analisados em detalhe e os diferentes stakeholders negociam para decidirem que requisitos sero aceitos. Este processo necessrio visto que inevitvel o aparecimento de conflitos entre requisitos de diferentes fontes, existncia de informao incompleta ou ento os requisitos podem ser incompatveis com o oramento disponvel para o desenvolvimento do sistema. Existe, no entanto, alguma flexibilidade na negociao dos requisitos para que seja possvel concordar acerca de conjunto de requisitos para o sistema.

[editar]Documentao

de Requisitos

Os requisitos acordados durante o processo de negociao so documentados com um nvel de detalhe apropriado. Em geral, necessrio existir um documento de especificao de requisitos que seja compreendido por todos os stakeholders. Isto significa que os requisitos devem ser detalhados utilizando linguagem natural e diagramas. Podem tambm ser produzidos documentos de sistema mais detalhados tais como modelos de sistema.

[editar]Validao

de Requisitos

Todos os requisitos obtidos nas actividades anteriores devem ser cuidadosamente verificados para apurar se esto completos e so consistentes. Este processo tem como finalidade detectar potenciais problemas no documento de especificao de requisitos antes que este seja utilizado como base para o desenvolvimento do sistema.

[editar]Modelos

de Ciclo de Vida

Os modelos existentes possuem diferentes graus de sofisticao e complexidade. Para projetos que envolvem uma equipe de desenvolvimento pouco numerosa e experiente, o mais adequado ser provavelmente um processo simples. No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas de elementos e milhares de utilizadores, um processo simples no suficiente para oferecer a estrutura de gesto e disciplina necessrias engenharia de um bom produto de software. Desta forma, necessrio algo mais formal e disciplinado. importante fazer notar que isto no significa que se perca em inovao ou que se pe entraves criatividade. Significa apenas que utilizado um processo bem estruturado para permitir a criao de uma base estvel para a criatividade. Por mais simples ou complexo que possa parecer, um modelo de ciclo de vida de um projeto , de facto, uma verso simplificada da realidade. suposto ser uma abstraco e, tal como todas as boas abstraces, apenas a quantidade de detalhe necessria ao trabalho em mos deve ser includa. Qualquer organizao que deseje por um modelo de ciclo de vida em prtica ir necessitar de adicionar detalhes especficos para dadas circunstncias e diferentes culturas. Por exemplo, a Microsoft quis manter uma cultura de pequena equipa e ao mesmo tempo tornar possvel o desenvolvimento de grandes e complexos produtos de software. Na prxima seco, introduzido uma interpretao do aspecto que um modelo de ciclo de vida deve ter em termos de engenharia de requisitos para projectos de software. Dependendo do tipo de sistema em desenvolvimento pode no ser completamente possvel ou at apropriado seguir os modelos rigorosamente. de notar tambm que para por em prtica um destes modelos e aplica-lo a um projecto real seria necessrio adicionar mais detalhe.

[editar]Modelos

em Engenharia de Software e Requisitos

A engenharia de software tem produzido inmeros modelos de ciclo de vida, incluindo os modelos de cascata, espiral e desenvolvimento rpido de aplicaes (RAD). Antes do modelo de cascata ser proposto em 1970, no havia concordncia em termos dos mtodos a levar a cabo no desenvolvimento de software. Desde ento ao longo dos anos muitos modelos tm sido propostos refletindo assim a grande variedade de interpretaes e caminhos que podem ser tomados no desenvolvimento de software. Neste artigo, foi decidida a incluso destes modelos por duas razes: primeiro porque so representativos dos modelos utilizados na indstria e foi j provado o seu sucesso, e segundo porque mostram como a nfase no desenvolvimento de software mudou gradualmente de forma a incluir uma viso mais interativa e centrada no utilizador.

[editar]Modelo

em Cascata

Modelo em Cascata.

O modelo de ciclo de vida em cascata foi o primeiro modelo a ser conhecido em engenharia de software e est na base de muitos ciclos de vida utilizados hoje em dia. Este consiste basicamente num modelo linear em que cada passo deve ser completado antes que o prximo passo possa ser iniciado. Por exemplo, a anlise de requisitos deve ser completada antes que o desenho do sistema possa ser iniciado. Os nomes dados a cada passo variam, assim como varia a definio exata de cada um deles, mas basicamente o ciclo de vida comea com a anlise de requisitos movendo-se de seguida para a fase de desenho, codificao, implementao, teste e finalmente manuteno do sistema. Uma das grandes falhas deste modelo o fato de os requisitos estarem constantemente a mudar j que os negcios e ambiente em que se inserem mudam rapidamente. Isto significa que no faz sentido parar os requisitos durante muito tempo, enquanto o desenho e implementao do sistema so completados. Foi ento reconhecido que seria necessrio dar feedback s atividades iniciais a partir do momento em que este modelo comeou a ser usado em grande escala. A ideia de interaco no foi incorporada na filosofia do modelo de cascata. Neste momento, includo algum nvel de interao na maior parte das verses deste modelo e so comuns sesses de reviso entre os elementos responsveis pelo desenvolvimento do sistema. No entanto, a possibilidade de reviso e avaliao com os utilizadores do sistema no est contemplada neste modelo.

[editar]Modelo

em 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.

[editar]Caractersticas

de Vrios Modelos
Desvantagens Inflexvel. Apenas a fase final produz um deliverable que no um documento. Torna-se difcil voltar atrs para corrigir erros. complexo e requer ateno e

Na tabela seguinte esto sumariadas algumas vantagens e desvantagens de vrios modelos de ciclo de vida utilizados em engenharia de requisitos para projectos de software:

Modelo Cascata

Vantagens Minimiza o tempo de planejamento. Funciona bem para equipes tecnicamente mais fracas.

Espiral

As interaes inicias do projecto so as mais baratas,

permitindo que as tarefas de maior risco sejam levadas com o mnimo de custos. Cada iterao da espiral pode ser customizada para as necessidades especficas de cada projecto. Prototipag em Evolucion ria Os clientes conseguem ver os progressos. til quando os requisitos mudam rapidamente e o cliente est relutante em aceitar um conjunto de requisitos.

conhecimento especiais para o levar a cabo.

impossvel determinar com exactido o tempo que o projecto vai demorar. No h forma de saber o nmero de iteraes que sero necessrias. Perigoso. No h forma de assegurar qualidade e identificar riscos. Falhas fundamentais no percebidas imediatamente resultando em trabalho deitado fora.

Codifica oe Correco

No h tempo gasto em planejamento, documentao, gesto de qualidade e cumprimento de standards. Requer pouca experincia.

Entre outros modelos utilizados esto: Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools e Off-the-Shelf.