Revisões técnicas formais

V. PARADIGMAS DA ENGENHARIA DE SOFTWARE

Paradigmas da Engenharia de Software, ciclos de vida ou processo de desenvolvimento e manutenção são termos que têm sido utilizados significando um conjunto de etapas para elaboração de software. A seguir são descritos os modelos mais comentados na literatura: o modelo de codificação e ajuste, o modelo cascata, a abordagem incremental ou evolutiva, a prototipagem descartável, as técnicas de quarta geração e o modelo espiral.

a) Modelo de codificação e ajuste

• 
  Modelo utilizado no início da computação
  
• 
  Modelo consiste na iteração de dois passos:
  
• 
  Escrever o código numa linguagem de baixo nível
  
• 
  Ajustar o código de forma a eliminar erros ou acrescentar novas facilidades
  
• 
  Não é precisamente formulado e nem cuidadosamente controlado
  
• 
  Mostrou-se adequado porque:
  
• 
  Os problemas a serem resolvidos eram bem entendidos
  
• 
  O usuário era o próprio cientista ou engenheiro que desenvolvia sua aplicação (não existia distinção entre o programador e o usuário final)
  
• 
  Falhas do Modelo de codificação e ajuste levaram ao reconhecimento da chamada crise do software.
  

Causas:

• 
  Computação passou a ser utilizada em vários domínios de aplicação, nos quais os usuários não entendem de computação
  
• 
  O tamanho e a complexidade do software aumentaram
  
• 
  O software gerado não atendia às expectativas dos usuários
  
• 
  O software passou a ser desenvolvido também para ser vendido a um usuário específico ou ao mercado em geral
  
• 
  Passou a haver maiores exigências de qualidade
  

Como conseqüência:

• 
  Aspectos econômicos, organizacionais e psicológicos tornaram-se importantes
  
• 
  As fases de projeto e análise surgiram como uma alternativa para resolver alguns dos problemas: A fase de Projeto facilitava o gerenciamento da complexidade e a fase de Análise permitia um melhor entendimento dos requisitos do usuário.
  
• 
  Nascimento da Engenharia de Software como disciplina.
  
• 
  Surgimento do conceito de ciclo de vida de software e de modelos que descrevem o ciclo com mais precisão.
  

b) Modelo Cascata

Origem:

• 
  Na literatura surgiu na década de 50 como resultado da experiência obtida com o desenvolvimento de um sistema de software de defesa aérea
  
• 
  Tornou-se popular na década de 70.
  

Descrição:

• 
  O processo é estruturado como uma cascata de fases, onde a saída de uma constitui a entrada de outra.
  

• 
  Cada fase é composta por um conjunto de atividades que podem ser realizadas concorrentemente.
  

Características do modelo:

• 
  Linear: o desenvolvimento do software procede linearmente do início ao fim do processo.
  
• 
  Rígido: Os resultados de cada fase são congelados antes de se passar para a próxima fase.
  

Críticas:

• 
  Os projetos raramente seguem o fluxo seqüencial que o modelo propõe.
  
• 
  Tem dificuldade de acomodar a incerteza natural que existe no começo dos projetos.
  
• 
  O cliente deve ter paciência já que uma versão do trabalho só está disponível num ponto tardio do cronograma.
  

Estudo

de viabilidade

Análise e especificação

de requisitos
Projeto e

especificação

Codificação e testes

de módulos

Integração e teste

de sistemas

Instalação

Manutenção

c) Abordagem incremental ou evolutiva
Uma abordagem rígida ou monolítica detalha completamente todos os aspectos de uma etapa do desenvolvimento antes de partir para outra etapa. E nada é colocado em operação até o fim do desenvolvimento. Já numa abordagem incremental, parte de alguns estágios são adiadas de forma a se implementar logo um conjunto de funções.
A idéia dessa abordagem é que incrementos são liberados ao usuário logo que desenvolvidos. Se incrementos são liberados ao usuário, devem consistir não somente de código e documentação de projeto mas também de documentação dirigida ao usuário. Assim, podemos definir um incremento como uma unidade funcional de software contida em si mesma que atende a algum objetivo do cliente juntamente com todo o material de suporte: especificação de requisitos e projeto, planos de teste, manual do usuário e material de treinamento.
Estratégia de desenvolvimento:

• 
  Liberar algo ao usuário
  
• 
  Medir o valor para o usuário em todas as dimensões críticas
  
• 
  Ajustar tanto o projeto como os objetivos baseado na realidade observada.
  

Essa definição da abordagem é geral, podendo acomodar vários modelos como por exemplo:

• 
  Implementação incremental
  
• 
  Desenvolvimento incremental
  

Implementação incremental:

• 
  O modelo cascata é seguido até a fase de projeto. A implementação é incremental.
  

• 
  Durante a análise de requisitos e projeto há uma atenção especial com a identificação de subconjuntos do sistema e com a definição de interfaces que permitirão que novos subsistemas sejam acrescentados.
  
• 
  Isto leva a um plano onde diferentes partes são implementadas, testadas e liberadas em diferentes momentos de acordo com a prioridade.
  

Desenvolvimento incremental:

• 
  O desenvolvimento começa analisando-se um incremento no nível de requisitos. Cada incremento é então separadamente projetado, codificado e testado, integrado e liberado.
  

• 
  Desta forma o cascata é seguido mas para cada incremento separadamente. O modelo é uma seqüência de mini-ciclos cascata.
  
• 
  Incrementos são desenvolvidos um após o outro depois de ter sido recebido um feedback do usuário.
  
• 
  É necessária muita disciplina e um planejamento cuidadoso para evitar uma iteração não proveitosa e um desenvolvimento que nunca termina.
  

d) Prototipagem descartável
Exemplos de uso de prototipagem:

• 
  Um stub, protótipo de um componente real que ele simula para facilitar a realização de testes.
  
• 
  O protótipo de uma interface apresentado para que o cliente de forma a se poder analisar melhor o tipo de interface desejado ou outros requisitos do sistema.
  

Nos casos em que o protótipo não evolui para o sistema final não há necessidade do rigor no desenvolvimento exigido na abordagem incremental ou evolutiva descrita acima.
e) Técnicas de quarta geração

Possibilitam que o desenvolvedor de software especifique alguma característica do software num nível elevado. A ferramenta gera, então, automaticamente, o código fonte.

Exemplos de ferramentas: linguagens não procedimentais para consulta a banco de dados, geração de relatórios, manipulação de dados, interação e definição de telas, planilhas eletrônicas etc..

Ferramentas se aplicam a domínios muito específicos. Não há nenhum ambiente de quarta geração que possa ser aplicado com igual facilidade a cada uma das categorias de aplicação.

Passos:

• 
  Coleta de requisitos (se for uma pequena aplicação pode-se partir para a implementação)
  
• 
  Estratégia de projeto
  
• 
  Implementação
  
• 
  Teste
  

f) Modelo Espiral
Tentativa, na década de 80, de reunir as melhores características do ciclo cascata e da prototipação acrescentando um novo elemento: a análise de risco.
Define quatro atividades principais que se repetem seguindo uma espiral:

• 
  Planejamento
  
• 
  Análise dos riscos
  
• 
  Engenharia
  
• 
  Avaliação feita pelo cliente
  

7. 
   Objectory
   

Desenvolvido por Booch, Jacobson e Rumbaugh, também é conhecido por Rational Unified Process.

CONSTRUÇÃO
1 2 3 . . . 4

TRANSIÇÃO

INÍCIO

ELABORAÇÃO




Este processo, apresentado em [Fowler-97] é iterativo e incremental, propondo o desenvolvimento em partes, através da realização das seguintes atividades:

• 
  INÍCIO (inception)
  

O início tem como objetivo o entendimento da área de negócio e a decisão sobre o escopo do projeto. É necessário realizar alguma análise de forma a se avaliar custos e benefícios. É quando se obtém a aceitação do projeto. Pode ser realizada de diferentes formas: uma conversa informal ou pode ser realizada através de um estudo de viabilidade que levará semanas para ser concluído.

• ELABORAÇÃO

Na elaboração obtém-se mais detalhes sobre os requisitos, elabora-se uma análise e projeto em alto nível de forma a se obter um arquitetura base e cria-se o plano de projeto. Devem ser avaliados os riscos do projeto:

• 
  Riscos relacionados aos requisitos: Qual o perigo de construir um sistema que não satisfaça ao usuário?
  
• 
  Riscos relacionados à tecnologia: Serão utilizados objetos ? Qual a experiência da equipe no desenvolvimento orientado a objetos ?
  
• 
  Riscos relacionados à capacidade da equipe: A equipe tem a experiência necessária ?
  
• 
  Riscos políticos: Há forças políticas que podem vir a afetar o projeto ?
  

A primeira e uma das mais importantes tarefas na fase de elaboração é descobrir os requisitos do sistema que está sendo construído. Na prática, não serão obtidos todos. No entanto, deve-se procurar descrever os mais importantes, através de contatos com os usuários do sistema.

• CONSTRUÇÃO

A etapa de construção consiste de várias iterações, cada uma produzindo um software com qualidade, testado e integrado e satisfazendo aos requisitos do projeto. Cada iteração contém as etapas de análise, projeto, implementação e testes.

• 
  TRANSIÇÃO
  

É na etapa de transição em que são realizados os testes beta, melhoria de desempenho e treinamento dos usuários.
Os projetos podem exigir um nível de formalidade maior ou menor dependendo de suas características. O projeto de um sistema bancário exigirá mais do que um sistema para controle de empréstimos de uma vídeo locadora. Desta forma os fundamentos destas fases ocorrerão sempre, mas de diferentes formas.

VI. CASE

Case - Engenharia de Software auxiliada por computador

A oficina de Eng. de Software é também denominada “Ambiente Integrado de Suporte a Projetos”.

Características das melhores oficinas:

• 
  contêm uma coleção de ferramentas úteis que ajudam em cada passo da construção de um produto. Esta coleção é o CASE.
  
• 
  contêm um layout organizado que possibilita que as ferramentas sejam encontradas rapidamente e usadas eficientemente.
  
• 
  dispõem de um artesão habilitado que entende como usar as ferramentas efetivamente.
  

Obs: Para dizermos que temos um CASE não é necessário que tenhamos todas as ferramentas.

Dificuldades da área
Se compararmos o CASE com o CAD/CAE/CIM que está muito mais evoluído, podemos observar que o CAD/CAE/CIM implementou práticas de engenharia que foram experimentadas e provadas ao longo dos últimos 100 anos. Isto não ocorreu com o CASE que apresenta um conjunto de ferramentas semi-automatizadas que estão implementando uma cultura de engenharia que é novidade para muitas empresas.

CASE hoje

• 
  Ferramentas individuais estão sendo usadas por algumas empresas.
  
• 
  Há um sério esforço para integrar ferramentas individuais a fim de se formar um ambiente consistente. Há diversos tipos de integração.
  
• 
  Hoje a tendência no desenvolvimento de software está distante do computador mainframe e caminha na direção da estação de trabalho como plataforma de engenharia de software. Estações de trabalho individuais são dispostas em redes, de forma que os engenheiros de software possam comunicar-se efetivamente.
  

Taxonomia por função
Ferramentas podem ser classificadas de várias formas: por função, pelo uso que elas têm nas várias etapas do processo de engenharia de software, pela arquitetura do ambiente que as suporta, pelo custo, etc...
A seguir é apresentada uma classificação por função:

1. 
   Planejamento de sistemas comerciais
   

Ajudam a melhorar a compreensão de como a informação flui entre as várias unidades organizacionais numa Empresa.

2. 
   Gerenciamento de projetos
   

Oferecem apoio ao planejamento de projetos, rastreamento dos requisitos e captação de métricas.

3. 
   Suporte
   

São ferramentas dos seguintes tipos:

• 
  Documentação
  
• 
  Software básico
  
• 
  Garantia da qualidade
  
• 
  Bancos de dados
  

• Gerenciamento de configuração

4. 
   Análise e projeto
   

Oferecem apoio para as atividades de análise e projeto estruturado, possibilitam a prototipação e simulação de sistemas e permitem o desenvolvimento de interfaces.

5. 
   Programação
   

Há ferramentas para codificação convencional, codificação de quarta geração e para programação orientada a objeto

6. 
   Integração e testes
   

Há ferramentas que ajudam a derivar casos de teste, outras que interagem com o programa enquanto ele está em execução podendo até mesmo mudar o software analisado e visam gerar informações sobre o que está ocorrendo no programa.

7. 
   Prototipação
   

8. 
   Manutenção
   

Podem dar apoio à Engenharia reversa ou à Reengenharia
Integração de ferramentas: I-CASE (CASE integrado)

Benefícios:

• 
  A transferência harmoniosa de informações (modelos, programas, documentos, etc)
  
• 
  A redução do esforço para realizar atividade de controle de qualidade, controle de configuração, documentação
  
• 
  Maior controle do projeto
  
• 
  Maior facilidade de coordenar os membros de uma equipe
  

Algumas das características de um I-CASE:

• 
  Oferecer um mecanismo para compartilha as informações entre todas as ferramentas do ambiente
  
• 
  Permitir que uma mudança efetuada num item de informação seja propagada para outros itens relacionados
  
• 
  Oferecer controle de versão e gerenciamento de configuração
  
• 
  Permitir acesso direto, não seqüencial a qualquer ferramenta contida no ambiente
  
• 
  Apoiar a comunicação entre os engenheiros de software
  

BIBLIOGRAFIA:

[Blaha-98] Blaha, Michael; Premerlani, William, Object-Oriented Modeling and Design for Database Applications, Prentice Hall, 1998.

[Fowler-97] Fowler, Martin; Scott, Kendall; UML Distilled: applying the standard object modeling language, Ed. Addison-Wesley, 1997.

[Ghezzi-91] Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli, Fundamentals of Software Engineering, Prentice-Hall International,Inc, 1991

[Jacobson] Jacobson, Ivar e outros, Object-Oriented Software Engineering: a use case driven approach, Ed. Addison-Wesley, 1996.

[Melo-97] Rubens Melo, Sidney Silva, A. Tanaka, Banco de Dados em Aplicações Cliente-servidor, Livraria e Editora Infobook, 1997.

[Page-Jones-88] Meilir Page-Jones, Projeto Estruturado de Sistemas, Ed. McGraw-Hill, 1988.

[Pressman-95] Roger S. Pressman, Engenharia de Software, Makron Books do Brasil Editora, 1995.

[Rumbaugh-94] J.Rumbaugh, M.Blaha e outros, Modelagem e Projetos Baseados em Objetos, Editora Campus, 1994.

[Yourdon-90] E. Yourdon, Análise Estruturada Moderna, Ed. Campus, 1990.