Resumo do Artigo:

Software Engineering Phases

Heitor Augustus Xavier Costa


1. Introdução

É argumentado que existem 4 fases fundamentais na maioria, senão em todos, dos modelos de processo de desenvolvimento de software, a saber: Análise, Design, Implementação e Testes.

É enfatizado que na maioria dos produtos de software, grande parte do recurso financeiro é empregado nas últimas fases do ciclo de vida do software, enquanto menor quantidade é usada na fase inicial do processo de desenvolvimento.

 

2. Fase de Análise

Esta fase identifica os requisitos do sistema, definindo o problema que o cliente deseja resolver. Ao definir os requisitos, a Equipe de Análise não deve se preocupar com aspectos de implementação, mas apenas com as funcionalidades que devem existir no sistema. A Fase de Análise é chamada de Fase de "o que", pois é nela que se determina "o que" o sistema deve fazer para atender as necessidades do cliente.

A Fase de Análise tem como produto final a documentação de requisitos, explicitando de maneira clara e precisa o que deve ser feito. Para elaborar esta documentação é muito comum o uso de uma linguagem formal. Ao invés de usar uma linguagem natural, por ser ambígua e poder gerar, na leitura da documentação de requisitos, dúvidas de interpretação, utiliza-se uma linguagem formal que é mais apropriada, pois fornece fundamentação científica para expressar precisamente a informação, embora de difícil uso.

Em casos muito raros, a documentação de requisitos incorpora aspectos de engenharia devido a existência de sistemas legados e/ou a pedido do cliente, contudo isso deve ser evitado.

A documentação de requisitos descreve "coisas" (peças, partes, constantes, nomes e seus relacionamentos e são identificadas através de um nome) do sistema e as ações (métodos, funções e procedimentos e são identificadas através de um verbo) que podem ser feitas com elas. Essas "coisas" podem ser representadas como objetos ou como serviços de acesso a banco de dados.

A documentação de requisitos deve ser elaborada pela Equipe de Análise e incluir, além das "coisas" e das ações, estados (estados do sistema em um determinado espaço de tempo), cenários típicos (situações previstas que o software deve atender de modo satisfatório) e cenários atípicos (situações inesperadas de erro que o software deve atender de modo satisfatório) de uso.

A tentativa de identificar todos os requisitos é árdua e inglória, visto que é difícil prever todas as necessidades do mundo real (domínio da aplicação). Por isso a medida que o processo de desenvolvimento de software evolui tende-se a encontrar mais requisitos outrora não identificados. Esses novos requisitos podem acarretar inconsistências na solução obtida em sua ausência, fazendo com que exista um re-trabalho.

Como um produto de software tende a crescer tanto em tamanho quanto em complexidade, o processo de obtenção de requisitos se torna cada vez mais difícil, principalmente quando envolve várias pessoas de diversas áreas de conhecimento.

 

3. Fase de Design

Esta fase tem como objetivo estabelecer a arquitetura do software e tem como ponto de partida o produto final oriundo da Fase de Análise: a documentação de requisitos. A partir desta documentação é feito o mapeamento dos requisitos nos componentes da arquitetura. A Fase de Design é chamada de Fase de "como", pois é nela que se determina "como" fazer para obter todas as funcionalidades do software.

Nesta fase pode ser elaborado o plano de testes que define os testes necessários para estabelecer a qualidade do software. O plano de testes, também, pode ser feito na Fase de Testes pela Equipe de Testes. De modo geral, o plano de testes é baseado nos cenários típicos e atípicos.

A Equipe de Design, também, indica as prioridades críticas de implementação que consiste de implementar determinadas tarefas de modo que sejam corretamente executadas. Existem duas categorias de tarefas: associadas a construção do software e associadas ao próprio software.

A arquitetura define os componentes, as interfaces e o comportamento do software. Os componentes podem ser construídos do "zero" ou serem derivação de outros já existentes, a interface é o meio de comunicação entre componentes e define um comportamento de resposta a estímulos produzidos por uma ação de outro componente.

Todo o trabalho de Equipe de Design culmina na elaboração de um documento chamado plano de implementação que é o produto final desta fase e servirá de apoio para a Equipe de Implementação.

 

4. Fase de Implementação

A Equipe de Implementação desempenha a sua tarefa começando a codificação do "zero" ou a partir da composição de código já existente (bibliotecas). Os membros têm como base a documentação oriunda da Fase de Design junto com a documentação de requisitos.

 

5. Fase de Testes

Diversos modelos colocam a Fase de Testes separado do processo de desenvolvimento, pois é desempenhada por uma equipe diferente. Após o software pronto pode-se utilizar a técnica de Testes de Regressão, que consiste em:

 

Objetivo

Responsabilidade

Interno

Garantir que todos os componentes não visíveis pelo cliente estejam funcionando corretamente

Equipe de Implementação

Unidade

Garantir que todos os componentes visíveis pelo cliente estejam funcionando corretamente

Equipes de Implementação e Design

Aplicação

Garantir que o software completa todos os cenários

Equipe de Análise

Stress

Executar o software em um ambiente cuja situação seja mais carregada de onde será instalado

Todas as Equipes

 

6. Comentários

É comum encontrar na literatura a identificação das fases do processo de desenvolvimento de software como sendo: Análise de Requisitos, Design do Sistema, Design do Programa, Implementação e Testes. A Fase de Levantamento de Requisitos é a parte mais crítica do processo de desenvolvimento, pois tem como objetivo identificar os requisitos para satisfazer às necessidades do cliente. A Fase de Design do Sistema tem como objetivo dizer ao cliente exatamente o que o sistema fará. A Fase de Design do Programa permite que os construtores do sistema identifiquem hardware e software para solucionar o problema do cliente. A Fase de Implementação tem como objetivo codificar programas, implementando o design. A Fase de Testes tem como objetivo realizar vários tipos de testes sobre o produto final da Fase de Implementação (programa), a saber: Funcional (verifica se o software executa suas funções como especificado nos requisitos), Desempenho (compara os componentes integrados como os requisitos não funcionais), Aceitação (assegura ao cliente que o sistema construído realmente atende às suas necessidades) e Instalação (possibilita aos usuários executarem as funcionalidades do sistema e documentar algum problema que apareça).

Um aspecto importante é a identificação dos requisitos sem incorporar aspectos de tecnologia, isto é, identificar apenas os requisitos funcionais do software. Ao considerar questões tecnológicas, o software fica "amarrado" e quando a tecnologia é mudada, o desempenho do software pode degradar.

A argumentação de se utilizar uma linguagem formal para redigir a documentação de requisitos, ao invés da linguagem natural, é bastante razoável, uma vez que a linguagem natural é ambígua e pode ocasionar erros de interpretação, enquanto a linguagem formal consegue representar de forma precisa as informações, não gerando dúvidas.

A identificação de todos os requisitos junto ao cliente é difícil, visto que a interação do analista com o cliente envolve, entre outras coisas, conhecimento tácito. Conhecimento, que está intrinsecamente ligado ao cliente, que é o cliente pressupor que todos sabem uma determinada necessidade, pois ele lida com ela diversas vezes diariamente (o cliente acha que a Equipe de Análise sabe o que fazer).

A Equipe de Design ao optar por elaborar uma arquitetura do "zero", seus membros precisam ter um grande conhecimento do problema. Ela não deve estabelecer o plano de testes, esta tarefa deve ser desempenhada pela Equipe de Testes, que possui técnicas específicas. A Equipe de Design pode identificar requisitos que não estão na documentação de requisitos, seja por não entendimento pela Equipe de Levantamento de Requisitos, seja por não manifestação do cliente a respeito. Com isso deve-se agendar reuniões com as duas equipes e o cliente.

A Equipe de Implementação também tem a liberdade de encontrar aspectos obscuros nos documentos recebidos e agendar reuniões com a Equipe de Design a fim de esclarecer estes pontos.

A Equipe de Testes deve ser independente da Equipe de Implementação. Em geral a Equipe de Testes é formada por analistas, programadores e designers que estão dedicados a Fase de Testes. Eles devem estar familiarizados não só com a especificação do software como também com métodos e ferramentas de testes.

Dentre essas fases do processo de desenvolvimento de software pode-se identificar duas fases (Design do Programa e Design do Sistema) que pode-se aplicar a modelagem orientada a objetos.


 

[Voltar]           [e-mail]