Professor Prado

Capítulo 9 Índice Geral Índice de Figuras
e Tabelas
Índice de Exercícios Parte IV

Capítulo 10
A Fase de Operação e Manutenção - OM

Tratando-se a manutenção como um processo de desenvolvimento orientado a reutilização, leva-se o desenvolvedor a uma escolha da abordagem para manutenção e a uma melhora da evolução global do processo.
Basili, V. R. [BAS90] (Adaptação)

10.1 Introdução

A fase Operação e Manutenção - OM é considerada neste trabalho como formada pelas macro atividades de Operação e de Manutenção do Sistema de Software.
A atividade Operação refere-se a utilização do Sistema de Software desenvolvido no ambiente real para o qual ele foi projetado. A atividade de Manutenção refere-se às modificações necessárias a serem realizadas após a sua aceitação final.
Qualquer correção, aperfeiçoamento ou adaptação executada antes da aceitação final é considerada como parte do processo de desenvolvimento do software. A atividade de Operação inicia-se com uma aceitação provisória, como resultado da fase de TRansferência do Software. A Atividade de Manutenção inicia-se com a aceitação final.
Tanto a atividade de Operação quanto a de Manutenção só terminam com a desativação do Sistema de Software. Um usuário do Sistema desenvolvido pode ser classificado em dois tipos [FAI96]: Usuário Final e Usuário Operador.
Enquanto o Usuário Final utiliza os produtos e serviços do sistema, o Usuário Operador gerencia, controla e monitora o hardware e o seu software, apoiados por um serviço de Suporte ao Usuário [FAI96].
A atividade de Manutenção do Sistema de Software desenvolvida deve ser entendida como “um processo de modificação do sistema de software ou de seus componentes após a aceitação final do mesmo, a fim de corrigir defeitos, melhorar desempenhos ou outros atributos, ou ainda, adaptá-lo a um ambiente em constante evolução e mutação”.
As restrições impostas na execução da Manutenção são muito mais fortes do que aquelas utilizadas durante o Projeto, pois a liberdade criativa do pessoal de manutenção é muito menor. As atividades de Manutenção do Protótipo de Sistema de software do RDS são classificadas como:
- corretivas quando tratar-se de remoção de defeitos;
- de aperfeiçoamento quando tratar-se de melhora do sistema; e
- adaptativas quando tratar-se de mudança do ambiente operacional.
Nas Atividades de Operação e Manutenção, duas subatividades podem ser identificadas: de Suporte ao Usuário e de Relatório de Problemas.
A Figura 10.1 ilustra uma visão em alto nível da fase de Operação e Manutenção do Sistema de Software RDS. Nela são ilustradas as duas atividades de Operação e Manutenção antes da aceitação final - aaf e pós a aceitação final - paf bem como ilustra a existência de uma revisão formal separando-as. A importante atividade de Revisão Técnica Formal pode recomendar a aceitação final do software ao iniciador.
Após a aceitação final, a atividade de Manutenção pode ser controlada ou monitorada utilizando-se os planos de desenvolvimento, se apropriados, ou planos próprios desenvolvidos pela equipe de manutenção do operador ou mesmo do desenvolvedor.


Acrogramas
PGPS Plano Gerencial do Projeto de Software DTR Documento de Transferência de Software
PGCS Plano Gerencial da Configuração de Software dap declaração de aceitação final
PVVS Plano de Verificação e Validação de Software CRS Comissão de Revisão de Software
PGQS Plano de Garantia da Qualidade de Software RTA Relatório de Testes de Aceitação
RPS Relatório de Problemas de Software RPM Relatório de Pedido de Modificação
DHP Documento de História de Projeto PMOS Plano de Operação e Manutenção de Software
RMS Relatório de Modificação de Software OM/aaf Operação e Manutenção antes da aceitação final
OM/paf Operação e Manutenção pós a aceitação final
Figura 10.1 As Macro Atividades da fase de OM

10.2 Detalhamento da Fase de OM/aaf

A Figura 10.1 pode ser detalhada em subatividades componentes como representadas nas Figuras de 10.2 até 10.5 .


Acrogramas
PGPS Plano Gerencial do Projeto de Software PMS Pedido de Modificação de Software
PGCS Plano Gerencial da Configuração de Software RPM Relatório de Pedido de Modificação
PVVS Plano de Verificação e Validação de Software DHP Documento de História de Projeto
PGQS Plano de Garantia da Qualidade de Software RMS Relatório de Modificação de Software
PMOS Plano de Operação e Manutenção de Software ICS Item de Configuração de Software
Figura 10.2 Pré-aceitação Final como Subatividades da Fase de OM

10.2.1 A Operação Antes sa Aceitação Final

A familiarização do usuário com a operação do Sistema de Software inicia-se com o estudo do Manual do Usuário do Software - MUS, devendo ser completada com um treinamento realizado por especialistas, possivelmente da equipe de desenvolvimento e/ou de manutenção. A operação do Sistema desenvolvido deve exigir mais do que estas duas ações, por exemplo, a assistência direta de especialistas de desenvolvimento ou de manutenção ou ainda ajuda da operação.
Os problemas do Sistema de Software devem ser documentados no Relatório de Problemas de Software - RPS. Os RPS não devem conter problemas originados com a não familiaridade do usuário com o software.
Cada RPS deve relatar somente um problema e deve conter:
- O título ou nome do Item de Configuração de Software;
- O número de versão ou da liberação do Item de Configuração de Software;
- A prioridade do problema em relação a outros problemas;
- Uma descrição do problema;
- O ambiente operacional do software;
- A solução recomendada (se possível).
A função prioridade deve considerar sempre dois aspectos, a criticalidade, levando-se em conta dois ou mais estados, como por exemplo, crítico e não-crítico. Um problema é considerado crítico se uma função essencial do sistema de software tornar-se indisponível. É considerado não crítico se nenhuma função essencial é afetada.
Para que o problema seja reproduzível, tanto ele como o seu ambiente operacional devem ser descritos precisamente. Mesmo se o problema encontrado tiver como causa alguns requisitos do DRU, ele deve ser relatado no RPS e o DRU só será modificado após uma recomendação de aprovação da modificação pelo CRS ao gerente do Projeto. O processamento das dificuldades encontradas na fase operacional pode ser dividido em tarefas como mostrado na Figura 10.3.


Acrogramas
PGPS Plano Gerencial do Projeto de Software PMS Pedido de Modificação de Software
PGCS Plano Gerencial da Configuração de Software RPM Relatório de Pedido de Modificação
PVVS Plano de Verificação e Validação de Software DHP Documento de História de Projeto
PGQS Plano de Garantia da Qualidade de Software CRS Comissão de Revisão do Software
Figura 10.3 Tarefas do Processo de Tratamento dos Problemas no Software

10.2.2 A Manutenção do Software Antes da Aceitação Final

A manutenção deve ser um processo controlado, a fim de garantir que o software continue satisfazendo as necessidades do usuário final. As subatividades do processo de manutenção executadas antes da aceitação final encontram-se ilustradas na Figura 10.4.


Acrogramas
PGPS Plano Gerencial do Projeto de Software RPS Relatório de Problema de Software
PGCS Plano Gerencial da Configuração de Software CRS Comissão de Revisão do Software
PVVS Plano de Verificação e Validação de Software ICS Item de Configuração de Software
PGQS Plano de Garantia da Qualidade de Software DTR Documento de Transferência de Software
Figura 10.4 As Subatividades de Manutenção Antes da Aceitação Final do Software

A mudança no software, primeira subatividade, deve ser governada por um processo de controle de mudanças definido no PGCS, podendo ser executada em quatro passos:
- diagnosticar o problema relatado no RPS;
- rever o PMS;
- modificar o software;
- verificar efeitos das modificações do software.
O passo diagnosticar se inicia com o exame do RPS e com a tentativa de reproduzir o problema. O diagnóstico pode exigir rastreamento do código, MUS, DPD, DPA, DRS e DRU. Identificado o defeito e sua causa, uma mudança no software é pedida, utilizando o PMS. Todo PMS deve conter no mínimo as seguintes informações:
- nome ou título do ICS;
- número de versão ou liberação do ICS;
- mudanças requeridas;
- prioridade do pedido;
- responsável; e
- estimativa de início, fim e esforço.
Os três primeiros itens são de responsabilidade do engenheiro de software e os três últimos do gerente, do projeto de Software.
Embora os PMS sejam apresentados em formulários, as mudanças provocadas por eles devem ser registradas em seções especiais dos documentos DRU, DRS, DPA, DPD, PVVS e PGQS. O PGPS deve ser atualizado.
O passo revisão nos Pedidos de Mudança no Software, executado pelo CRS, autoriza as mudanças solicitadas pelos PMS.
O passo modificar o software consiste em implementar a mudança. A implementação modifica código e documentos, executa revisão destas modificações e testa o código modificado.
Os efeitos das modificações devem ser avaliados no desempenho, consumo de recursos, coesão, acoplamento, complexidade, consistência, portabilidade, confiabilidade, manutenabilidade, segurança física ou material e ameaças a confidencialidade, integridade e disponibilidade.
A documentação deve ser mantida atualizada.
O passo verificar as modificações do software é executado revendo-se o projeto detalhado, o seu código e ainda executando testes.
Na segunda subatividade, liberação do software, os gerentes devem definir o conteúdo e o tempo da liberação de acordo com as necessidades do usuário. Toda liberação deve ser acompanhada de documentos definindo o nome e/ou título do Item de Configuração de Software, número de versão e/ou liberação do Item de Configuração de Software, mudanças na liberação, lista de Itens de Configuração de Software incluídos na liberação e instruções de instalação. O software liberado deve sofrer auditoria funcional e física, verificando consistência e correção de Itens de Configuração de Software.
Na terceira subatividade, instalação de software, cuidado deve ser tomado para que a versão existente tenha cópia de segurança. Os itens de configuração obsoletos devem ser removidos dos diretórios e as novas versões instaladas.
Na quarta e última subatividade validação da solução, devem ser executados os testes de aceitação, inclusive aqueles de novos requisitos dos usuários que porventura venham a ser incluídos.

10.2.3 Atualização do Documento da História do Projeto

O propósito da atividade de atualização do Documento História do Projeto, executada pelo gerente do projeto, é o de registrar pontos importantes do trabalho, dentre os quais destacam-se, a descrição de seus objetivos, o sumário de suas atividades gerenciais, registro de seu custo bem como comparação com o que foi previsto, discussão da aplicação de padrões, avaliação de seu desempenho operacional e descrição das lições aprendidas.
Os benefícios deste documento refletem na utilização das informações obtidas pelo grupo de desenvolvimento, pelo grupo de manutenção, evitando assim repetir erros ou eliminando tentativas de soluções não apropriadas. Ele registra também as experiências obtidas e o que pode ser útil para futuros projetos, nas áreas de custo, na solução de problemas e para evitar armadilhas.
A referência [MAZ94] contém excelentes recomendações de conteúdo e formato para este documento.

10.2.4 Aceitação Final

A Aceitação Final é recomendada pela CRS ao iniciador, após as Revisões Técnicas Formais, considerando-se o número e a natureza dos Casos de Testes de Aceitação que falharam, que não foram executados ou completados, o número e natureza dos problemas críticos relatados, incluindo os não resolvidos. Alguns parâmetros para medida de confiabilidade podem ser levantados, dentre os quais pode-se citar o MTTF (Mean Time To Failures), o MTTR (Mean Time To Repair) e o MTBF (Mean Time Between Failures),calculado como MTTF + MTTR, permitindo portanto calcular a disponibilidade do software como sendo:

D = MTTR/MTBF

Frequentemente a Disponibilidade é apresentada como um Requisito, o qual juntamente com uma estimativa do MTTR pode-se calcular o MTTF.

10.3 Detalhamento da Subfase OM Pós-Aceitação Final

Após a aceitação final, o grupo de manutenção pode utilizar sistemas gerenciais diferentes do adotado no desenvolvimento ou reutilizar os planos de desenvolvimento readaptados. A Figura 10.5 ilustra o detalhamento das atividades de manutenção pós-aceitação final.
A estrutura dessas atividades é similar àquela apresentada na Figura 10.2, exceto que os planos gerenciais poderão ser diferentes. Podem, por exemplo, ser as adaptações dos planos de desenvolvimento para gerenciar a manutenção, a configuração, as verificações e validações e ainda a garantia de qualidade. A Figura 10.5, ilustra os planos gerenciais no documento Plano de Operação e Manutenção de Software - POMS. Outra diferença é que uma mudança no software é realizada pelo grupo de manutenção e a atualização do DHP é feita pelo Gerente de Software.


Acrogramas
PGPS Plano Gerencial do Projeto de Software PMS Pedido de Modificação de Software
PGCS Plano Gerencial da Configuração de Software RPS Relatório de Problema de Software
PVVS Plano de Verificação e Validação de Software DHP Documento de História de Projeto
PGQS Plano de Garantia da Qualidade de Software RMS Relatório de Modificação de Software
Figura 10.5 As Subatividades da Fase de OM após a Aceitação Final

10.4 Ferramentas para a Manutenção de Software

Muitas ferramentas já se encontram disponíveis para facilitar a operação e manutenção de software. O grupo de manutenção deve preferir ferramentas que suportem definição dos requisitos do usuário, dos requsitos de software, do projeto arquitetural, do projeto detalhado, incluindo a produção do código e a transferência do software para usuário. Preferência também deve ser dada para ferramentas gerenciais de projeto, configuração, verificação e validação e garantia da qualidade.
Três tipos de ferramentas são comuns:
- Ferramentas de navegação utilizadas para acessar partes específicas do software, por exemplo, identificando o local onde variáveis são utilizadas, identificando módulos que chamam outros módulos, mostrando árvores de chamada e estrutura de dados. Quando se utiliza orientação a objetos é necessário localizar atributos e funções herdadas;
- Ferramentas para atualizar o código utilizadas para restruturação de código, para refazer os fluxos de controle, simplificando as conexões, reduzindo-as para os tipos de conexões: seqüenciais, seletivas e repetitivas. Outra função destas ferramentas é reformatar o código fonte, aproveitando características gráficas dos comandos fundamentais, melhorando assim a legibilidade; e
- Ferramentas de Engenharia Reversa utilizadas para recuperar projetos detalhados do código fonte e mesmo gerar código fonte a partir do código objeto.

10.5 Atividades Gerenciais na Fase de OM

Este trabalho endereça apenas a atividade Manutenção que necessita gerência efetiva. As funções gerenciais são similares as do processo de desenvolvimento. O grupo de manutenção precisa desenvolver seus próprios planos para projeto e para qualidade, os quais devem ser reunidos no documento chamado Plano de Manutenção e Operação de Software (PMOS). É necessário que o operador reutilize e melhore os Planos de Gerência de Configuração e de Verificação e Validação de Software (PGCS e PVVS) do desenvolvedor ou crie seus próprios planos.
A referência [FAI96] contém excelentes recomendações para produção destes documentos gerenciais.