Modelo de ciclo de vida

Perceber que atividades fazem parte do processo de engenharia de software é o primeiro passo para o concretizar, mas é também importante perceber como as atividades do processo se relacionam umas com as outras para que se torne visível 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 descrição de quando e como se deve mover de uma actividade para a próxima e os deliverables que devem ser produzidos em cada etapa. A razão pela qual estes modelos são tão conhecidos é o fato de ajudarem as equipes de desenvolvimento, e em particular os gestores, a obter uma visão geral do projecto de forma a ser possível 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" são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum modelo é capaz de dar uma visão completa de um determinado processo.

Modelos de Processos

Embora este artigo seja mais focado aos modelos de ciclo de vida na engenharia de software, é importante ter uma ideia dos vários 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 necessário um modelo para explicar como está organizada a informação 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 são:

Modelo de atividades.

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 não permite forçar um processo mas dá uma visão geral do mesmo e são tipicamente construídos como ponto de partida para a descrição de um processo com secções 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

Modelos de Atividade de Granularidade Fina

Estes são modelos mais detalhados para um processo específico. Podem ser utilizados para perceber e melhorar processos existentes.

Modelos Papel-Ação

Estes são modelos que mostram o papel de diferentes pessoas envolvidas num processo e as ações que podem tomar. Estes modelos, que não são tratados mais a fundo neste artigo, podem ajudar a perceber e automatizar processos.

Modelos Entidade-Relação

Estes modelos mostram as entradas, saídas e resultados intermédios dos processos e relações entre eles. Podem ser utilizados num sistema de gestão de qualidade e como modelos complementares das actividades de processo.

Atividades do Processo de Engenharia de Requisitos

Diferentes tipos de organizações abordam a engenharia de requisitos de formas radicalmente diferentes. Uma companhia aeroespacial que se encontre a especificar sistemas de software e hardware muito complexos não utiliza o mesmo processo de engenharia de requisitos que uma outra companhia que desenvolve produtos de consumo para computadores pessoais. No entanto, as diferenças entre estes processos encontram-se geralmente no nível de detalhe dos processos. Num nível 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 necessário compreender melhor as actividades nele envolvidas. As actividades do processo de engenharia de requisitos são as seguintes:

Levantamento de Requisitos

Os requisitos do sistema são obtidos através de consultas aos stakeholders, documentação do sistema, conhecimento do domínio e estudos de mercado. Este processo é também conhecido como aquisição de requisitos ou descoberta de requisitos.

Análise e Negociação de Requisitos

Os requisitos são analisados em detalhe e os diferentes stakeholders negociam para decidirem que requisitos serão aceitos. Este processo é necessário visto que é inevitável o aparecimento de conflitos entre requisitos de diferentes fontes, existência de informação incompleta ou então os requisitos podem ser incompatíveis com o orçamento disponível para o desenvolvimento do sistema. Existe, no entanto, alguma flexibilidade na negociação dos requisitos para que seja possível concordar acerca de conjunto de requisitos para o sistema.

Documentação de Requisitos

Os requisitos abordados durante o processo de negociação são documentados com um nível de detalhe apropriado. Em geral, é necessário existir um documento de especificação de requisitos que seja compreendido por todos os stakeholders. Isto significa que os requisitos devem ser detalhados utilizando linguagem natural e diagramas. Podem também ser produzidos documentos de sistema mais detalhados tais como modelos de sistema.

Validação de Requisitos

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

Modelos de Ciclo de Vida

Os modelos existentes possuem diferentes graus de sofisticação 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 não é suficiente para oferecer a estrutura de gestão e disciplina necessárias à engenharia de um bom produto de software. Desta forma, é necessário algo mais formal e disciplinado. É importante fazer notar que isto não significa que se perca em inovação ou que se põe entraves à criatividade. Significa apenas que é utilizado um processo bem estruturado para permitir a criação de uma base estável para a criatividade.

Por mais simples ou complexo que possa parecer, um modelo de ciclo de vida de um projeto é, de facto, uma versão simplificada da realidade. É suposto ser uma abstracção e, tal como todas as boas abstracções, apenas a quantidade de detalhe necessária ao trabalho em mãos deve ser incluída. Qualquer organização que deseje por um modelo de ciclo de vida em prática irá necessitar de adicionar detalhes específicos para dadas circunstâncias e diferentes culturas. Por exemplo, a Microsoft quis manter uma cultura de pequena equipa e ao mesmo tempo tornar possível o desenvolvimento de grandes e complexos produtos de software.

Na próxima secção, é introduzido uma interpretação 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 não ser completamente possível ou até apropriado seguir os modelos rigorosamente. É de notar também que para por em prática um destes modelos e aplica-lo a um projecto real seria necessário adicionar mais detalhe.

Modelos em Engenharia de Software e Requisitos

A engenharia de software tem produzido inúmeros modelos de ciclo de vida, incluindo os modelos de cascata, espiral e desenvolvimento rápido de aplicações (RAD). Antes do modelo de cascata ser proposto em 1970, não havia concordância em termos dos métodos a levar a cabo no desenvolvimento de software. Desde então ao longo dos anos muitos modelos têm sido propostos refletindo assim a grande variedade de interpretações e caminhos que podem ser tomados no desenvolvimento de software. Neste artigo, foi decidida a inclusão destes modelos por duas razões: primeiro porque são representativos dos modelos utilizados na indústria 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 visão mais interativa e centrada no utilizador.

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 nos dias de hoje. Este consiste basicamente num modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado. Por exemplo, a análise 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 definição exata de cada um deles, mas basicamente o ciclo de vida começa com a análise de requisitos movendo-se de seguida para a fase de desenho, codificação, implementação, teste e finalmente manutenção do sistema. Uma das grandes falhas deste modelo é o fato de os requisitos estarem constantemente a mudar já que os negócios e ambiente em que se inserem mudam rapidamente. Isto significa que não faz sentido parar os requisitos durante muito tempo, enquanto o desenho e implementação do sistema são completados. Foi então reconhecido que seria necessário dar feedback às atividades iniciais a partir do momento em que este modelo começou a ser usado em grande escala. A ideia de interacção não foi incorporada na filosofia do modelo de cascata. Neste momento, é incluído algum nível de interação na maior parte das versões deste modelo e são comuns sessões de revisão entre os elementos responsáveis pelo desenvolvimento do sistema. No entanto, a possibilidade de revisão e avaliação com os utilizadores do sistema não está contemplada neste modelo.

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 análise de risco e prototipagem. O modelo espiral incorpora-os de uma forma iterativa permitindo que as ideias e o progresso sejam verificados e avaliados constantemente. Cada iteração à volta da espiral pode ser baseada num modelo diferente e pode ter diferentes atividades. No caso da espiral, não foi a necessidade do envolvimento dos utilizadores que inspirou a introdução de iteração mas sim a necessidade de identificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividades são repetidas até uma decisão ser tomada e o documento de especificação de requisitos ser aceito. Se forem encontrados problemas numa versão inicial do documento, reentra-se nas fases de levantamento, análise, documentação e validação. Isto repete-se até que seja produzido um documento aceitável ou até que fatores externos, tais como prazos e falta de recursos ditem o final do processo de engenharia de requisitos.

Características dos Vários Modelos

Na tabela seguinte estão sumariadas algumas vantagens e desvantagens de vários modelos de ciclo de vida utilizados em engenharia de requisitos para projectos de software:

Modelo	Vantagens	Desvantagens
Modelo em cascata	Minimiza o tempo de planejamento. Funciona bem para equipes tecnicamente mais fracas.	Inflexível. Apenas a fase final produz um deliverable que não é um documento. Torna-se difícil voltar atrás para corrigir erros.
ESPIRAL	As iterações iniciais do projecto são as mais baratas, permitindo que as tarefas de maior risco sejam levadas com o mínimo de custos. Cada iteração da espiral pode ser customizada para as necessidades específicas de cada projecto.	É complexo e requer atenção e conhecimento especiais para o levar a cabo.
PROTOTIPAGEM EVOLUCIONÁRIA	Os usuários conseguem ver constantemente os progressos. É útil quando os requisitos mudam rapidamente e o cliente está relutante em aceitar um conjunto fixo de requisitos.	É impossível determinar com exactidão o tempo que o projecto vai demorar. Não há forma de saber o número de iterações que serão necessárias.
CODIFICAÇÃO e CORREÇÃO	Não há tempo gasto em planejamento, documentação, gestão de qualidade e cumprimento de standards. Requer pouca experiência.	Perigoso. Não há forma de assegurar qualidade e identificar riscos. Falhas fundamentais não percebidas imediatamente resultando em retrabalho.

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

Bibliografia

• Gerald Kotonya ; Ian Sommerville (1998). Requirements Engineering. Processes and Techniques (em Inglês). [S.l.]: John Wiley & Sons. 294 páginas. ISBN 0471972088  !CS1 manut: Língua não reconhecida (link)
  
• Ian Sommerville ; Pete Sawyer (1997). Requirements Engineering. A good practice guide (em Inglês) 1 ed. [S.l.]: John Wiley & Sons. 404 páginas. ISBN 0471974447  !CS1 manut: Língua não reconhecida (link)
  
• Helen Sharp ; Yvonne Rogers ; Jenny Preece (2002). Interaction Design. Beyond Human-computer Interaction (em Inglês) 2 ed. [S.l.]: John Wiley & Sons. 519 páginas. ISBN 0471492787  !CS1 manut: Nomes múltiplos: lista de autores (link) !CS1 manut: Língua não reconhecida (link)
  

Ver também

• en:Requirements engineering
• en:Process Modeling
• en:Data modeling

Ligações externas

• Project Lifecycle Models : How They Differ and When to Use Them.