Revisões técnicas formais

I.4 SISTEMAS

Sistema: Um conjunto ou disposição de coisas relacionadas a ponto de formar uma unidade ou um todo orgânico.
Sistema baseado em computador: Um conjunto ou disposição de elementos organizados para executar certo método, procedimento ou controle ao processar informações.
Elementos de um sistema baseado em computador:

• 
  Software
  
• 
  Hardware
  
• 
  Pessoas
  
• 
  Banco de Dados
  
• 
  Documentação
  
• 
  Procedimentos
  

Sistemas de Informação baseados em computador: [Melo-97]

No início da computação dados eram armazenados no próprio programa já que não havia dispositivos de acesso direto. Desta forma os procedimentos relacionados a gerência de dados misturavam-se com os de interação com o usuário e com os relacionados ao próprio negócio.

Ao surgirem os discos magnéticos os dados passaram a ser armazenados em local distinto, organizando-se em arquivos. Com esta organização qualquer alteração na estrutura dos arquivos implica na alteração das funções de gerência de dados, presentes em cada programa.

A desejada independência de dados surgiu com os sistemas de gerência de banco de dados (SGBD), que reúnem todas as funções necessárias à localização e manipulação dos dados de interesse dos sistemas de informação.

I.5 QUALIDADE

Em [Pressman-95] é apresentada a seguinte lista de fatores que afetam a qualidade do software proposta por McCall e seus colegas:

Fatores relacionados à operação do software:

• 
  Correção: O quanto o software satisfaz as especificações e atende aos objetivos do cliente. (Ele faz o que quero ?)
  
• 
  Confiabilidade: O quanto espera-se que o software realize suas funções com precisão, sem erros. (Ele se comporta com precisão o tempo todo ?)
  
• 
  Eficiência: O total de recursos computacionais e código requerido por um software para realizar suas funções. (Ele rodará em meu hardware tão bem quanto possível ?)
  
• 
  Integridade: O quanto o acesso ao software ou dados, por pessoas não autorizadas, pode ser controlado. (Ele é seguro ?)
  
• 
  Facilidade de uso: O esforço requerido para aprender, operar, preparar entradas e interpretar as saídas do software. (Ele foi projetado para o usuário ?)
  

Fatores relacionados à revisão do software:

• 
  Facilidade de realizar manutenções: O esforço requerido para localizar e corrigir um erro num software. (Posso consertá-lo ?)
  
• 
  Flexibilidade: O esforço requerido para modificar um software. (Posso mudá-lo ?)
  
• 
  Facilidade de realizar testes: O esforço requerido para testar um software de forma a assegurar que ele realiza as funções desejadas. (Posso testá-lo ?)
  

Fatores relacionados à evolução do software:

• 
  Portabilidade: O esforço requerido para transferir um software de um hardware para outro ou de um ambiente para outro. (Serei capaz de usá-lo em outra máquina ?)
  
• 
  Facilidade de reuso: O quanto um software (ou partes dele) pode se reusado em outras aplicações. (Serei capaz de reutilizar parte do software ?)
  
• 
  Interoperabilidade: O quanto um software tem facilidade em cooperar com outros. Exemplo de cooperação: um processador de texto que incorpora uma figura gerada por um pacote gráfico. (Serei capaz de compor uma interface com outro sistema ?)
  

É difícil e em certos casos impossível medir com uma única métrica os fatores descritos. É definido então um conjunto de métricas relacionadas a cada fator. As métricas podem estar na forma de uma lista de verificação (checklist), que é usada para graduar atributos específicos do software. Por exemplo, no caso do fator facilidade de realizar manutenções, poderiam ser utilizadas as seguintes métricas:

• 
  Concisão: é a característica de um programa realizar as funções desejadas implementadas com o mínimo possível de código.
  
• 
  Consistência: uso de técnicas de projeto e documentação uniformes ao longo do projeto de desenvolvimento de software.
  
• 
  Instrumentação: o quanto o programa monitora sua própria operação e identifica erros que venham a ocorrer.
  
• 
  Modularidade: o quanto há independênica funcional dos componentes do programa. Independência funcional é conseguida desenvolvendo-se módulos com um só propósito e evitando-se interações excessivas com outros módulos. Pode ser medida usando-se como critérios a coesão e o acoplamento.
  
• 
  Autodocumentação: o quanto o código fonte apresenta documentação significante.
  
• 
  Simplicidade: o quanto o programa pode ser entendido sem dificuldades.
  

I.6 FASES DA ENGENHARIA DE SOFTWARE

A figura apresentada na página seguinte, de [Pressman-95], representa as fases genéricas da Engenharia de Software. Este processo divide-se em três etapas principais que são detalhadas ao longo dessa apostila:

1. 
   Definição (descrita na seção II)
   
2. 
   Desenvolvimento (descrita na seção III)
   
3. 
   Verificação, liberação e manutenção (descrita na seção IV)
   

II. FASE DE DEFINIÇÃO [Pressman-95]

Definição é a primeira etapa do processo de desenvolvimento e manutenção. Inclui o planejamento do projeto, a revisão do Plano de Projeto, a análise e especificação de requisitos e a revisão dos produtos gerados nesta última atividade. A seguir são abordados esses assuntos.

II.1 PLANEJAMENTO DO PROJETO

Grandes sistemas de software devem ser vistos como produtos complexos e a sua construção como um trabalho de engenharia. A abordagem de engenharia requer gerenciamento, organização, ferramentas, teorias, metodologias e técnicas.

O planejamento do projeto de desenvolvimento de software é uma das atividades de administração de projetos, envolvendo a especificação dos objetivos do projeto e como alcançá-los além da definição de que recursos serão necessários, como e quando obtê-los.
Ao iniciar o planejamento do projeto é importante que sejam definidos e documentados:

• 
  os objetivos e restrições do projeto: o projeto necessita de um definição clara de seus objetivos, capaz de guiar os participantes do processo em suas decisões. É comum que muito tempo seja desperdiçado discutindo-se alternativas que são conhecidas claramente pelo gerente do projeto, mas que não foram documentadas e nem disseminadas adequadamente.
  

• 
  os riscos do projeto: os riscos estão presentes em todos os projetos e por essa razão devem ser analisados e controlados.
  
• 
  os recursos necessários de pessoal, hardware e software para o desenvolvimento, além de outros recursos especiais que sejam necessários.
  

• 
  o cronograma do projeto: deve-se criar uma rede que represente cada etapa do desenvolvimento, sua dependência de outras tarefas e duração.
  
• 
  como os profissionais estarão organizados.
  
• 
  o custo do projeto.
  

Estas informações devem fazer parte do Plano do Projeto de Software, um documento, ou conjunto de documentos, que darão apoio ao gerente em sua atividade de planejamento.

O Plano do Projeto de Software deve ser um documento simples e seu nível de detalhamento dependerá do público ao qual é destinado e da necessidade de um grau maior ou menor de formalismo. Ao longo do projeto pode haver a necessidade de se modificar o Plano devido ao contínuo controle que deve ser exercido pelo gerente de projetos.
O plano deverá ser revisado. A seguir são apresentados alguns dos itens a serem considerados numa lista de verificação (ver Revisões Técnicas Formais):

• 
  O escopo do software é definido e delimitado com clareza ?
  

• 
  A terminologia utilizada é clara ?
  
• 
  Os recursos são adequados ?
  
• 
  Os recursos estão disponíveis ?
  
• 
  Os riscos mais importantes foram definidos ?
  
• 
  Um plano de gerenciamento de riscos está em andamento ?
  
• 
  As tarefas para realização do projeto são definidas e colocadas numa seqüência adequada?
  
• 
  O paralelismo entre tarefas é razoável, em função dos recursos disponíveis ?
  
• 
  A base para a estimativa de custos é razoável ? Foram utilizados métodos ?
  
• 
  Os orçamentos e prazos estimados são realistas ?
  
• 
  Foram utilizados dados históricos para a realização de estimativas ?
  
• 
  O cronograma é consistente ?
  

O controle é realizado pelo gerente de projetos de software para administrar os recursos do projeto, enfrentar problemas e dirigir o pessoal de projeto. Se tudo estiver caminhando bem (isto é, se o projeto estiver no prazo e dentro do orçamento, as revisões indicarem progresso real e os marcos estiverem sendo atingidos), é fácil realizar o controle. Mas quando ocorrerem problemas, o gerente de projetos deverá exercer o controle para saná-los o mais rapidamente possível. Depois que o problema tiver sido diagnosticado, recursos adicionais podem ser concentrados na área do problema, o pessoal pode ser reorganizado ou pode ser necessário redefinir as atividades do projeto. [Pressman-95]

O controle do projeto pode ser realizado de várias maneiras:

• 
  Realizando-se reuniões periódicas sobre a situação do projeto, nas quais cada membro da equipe deverá relatar o progresso e os problemas.
  
• 
  Avaliando-se os resultados de todas as revisões levadas a efeito ao longo do progresso de engenharia de software.
  
• 
  Verificando-se se os marcos do projeto foram atingidos até a data programada.
  
• 
  Comparando-se a data de início real com a data de início planejada para cada tarefa do projeto.
  
• 
  Reunindo-se informalmente com profissionais para obter suas avaliações subjetivas do progresso até o momento e dos problemas que podem já estar percebendo para o futuro.