As Tecnologias 3R
Autor: Vanderlei Vilhanova Ortêncio
Parte 1
MANUTENÇÃO DE SOFTWARE OU REENGENHARIA
(MAIS PROBLEMAS QUE SOLUÇÃO)
Antes se falava apenas em DESENVOLVIMENTO e MANUTENÇÃO.
Hoje, com a proliferação de termos geralmente emprestados de áreas com maior tradição, como a indústria, vemos proposta de organização das atividades de gerenciamento e construção de software, sob o título: ENGENHARIA DE SOFTWARE.
No bojo desta analogia, temos também a ampliação do problema já existente que é privilegiar as atividades de desenvolvimento tornando a manutenção uma atividade nada atraente, amaldiçoada mesmo. Isto porque na indústria a Engenharia projeta produtos, enquanto que quem conserta estes produtos é um técnico bem menos qualificado.
Em que pese as atividades requeridas na manutenção de software não serem análogas, pois o termo de software não serem análogas, pois o termo é mal empregado como veremos mais adiante, a pessoa que trabalha com manutenção é a que menos recebe nas organizações a ponto de não se orgulharem do que fazem.
Mas e agora, a manutenção fica dentro ou fora do aparato de Engenharia de Software?
Se pertence à Engenharia de Software, e sendo a manutenção responsável por mais de 50% do orçamento com processamento de dados nas organizações, o que explica tanto descaso?
Quais as técnicas de manutenção consagradas e que são ensinadas nos cursos de formação e aperfeiçoamento de programadores e analistas?
O software em desenvolvimento hoje, estará em operação amanhã. Por mais bem projetado e construído, terá que funcionar ao longo do tempo, resistindo a todas intempéries que o mundo real lhe impõe.
Ao longo deste tempo, pretende-se desfrutá-lo e compensar todo investimento financeiro, esforço e angústia na espera pela implantação. Daí então vem um pacote econômico, e...
Não é novidade que todo software existente na organização representa um patrimônio que além de ter custado muito caro (oneroso)) lhe -e muito caro (necessário) pois faz parte da engrenagem que move os negócios da organização.
Mesmo com as técnicas mais avançadas de desenvolvimento estes velhos pioneiros continuarão existindo e não é prudente ignorar este fato.
PROBLEMAS COM A MANUTENÇÃO DE SOFTWARE.
Este é um tema mais se encontra matéria nos poucos artigos sobre o assunto.
Assim, procurei selecionar e resumir as classes de problemas mais representativos para uma reflexão e análise das causas e efeitos destes problemas.
1.ROTATIVIDADE DE PESSOAL
As pessoas se sentem motivadas na construção do software. Quando têm que trabalhar na manutenção – mesmo dos sistemas feitos por elas – procuram mudar de emprego ou de setor.
2.POUCA IMPORTÂNCIA À ATIVIDADE
(falta de reconhecimento)
Quando técnicos de desenvolvimento também lidam com manutenção, ao invés de usar processos os quais dominam usam no desenvolvimento, correm com o trabalho consertando programas e resolvendo o problema emergente o mais rápido para voltar às atividades de desenvolvimento. Com o tempo os programas ficam de difícil compreensão e a documentação se deteriora.
A pressão que o técnico se impõe tem a ver tanto com a falta de recompensa na satisfação pessoal, como na baixa valorização deste trabalho por parte de sua chefia que também geralmente subestima prazos e esforços.
3.ABRANGÊNCIA DO TERMO - mau emprego do termo.
A manutenção do hardware visa resolver algum problema causado por componentes que deixam de funcionar conforme as especificações.
No caso do software, nada garante que este atendia todas as especificações nem que tenha sido testado. Muitas atividades de manutenção são uma extensão dos testes e mesmo da construção.
O próprio termo é um erro, pois as aplicações e os programas fisicamente não se desgastam como peças. Ocorreu de “pegar” a palavra manutenção e agora é difícil mudar.
O próprio Dr. Dijkstrta, inventor do termo “Programação Estruturada”, lamenta este fato mas pelo jeito não encontrou nenhum outro nome que “colasse”.
4.NEGLIGÊNCIA TECNOLÓGICA
Apesar da Engenharia de Software pretende abranger o tema, o pouco que se tem publicado diz respeito mais à manutenção dentro do processo de desenvolvimento continuado que é o ciclo de vida em LOOP.
Pouca solução foi disponibilizada ao longo da década de 80 para atender a manutenção do acervo existente, construído fora dos conceitos da Engenharia de software.
Surgiram alguns produtos para reestruturação de programas, conversão de linguagens, mas não houve avanços significativos na esfera teórica e conceitual, como aconteceu na área de desenvolvimento.
5.DEPENDÊNCIA DO MÉTODO DE DESENVOLVIMENTO
Quando sistemas são construídos sem métodos, é impossível criar método para entendê-los.
Lei de Parikh:
“Nenhum método para desenvolvimento = Nenhum método para manutenção”
Quando o método utilizado no desenvolvimento é completo, este já aponta métodos de manutenção. Isto ocorre nos trabalhos do Dr. Warnnier:
LCP – Lógica de Construção de Programas e
LCS – Lógica de Construção e Sistemas.
Seria ótimo se os métodos mais modernos também adquirissem esta característica.
6.DOCUMENTAÇÃO DISPONÍVEL DEFICIENTE
Em muitos casos a documentação é solenemente ignorada. Principalmente nas atividades de manutenção, o que é um paradoxo.
A menos que haja grande rigor nesta tarefa com o tempo, o conceito e a documentação do projeto original não refletem o estado presente do sistema.
Na maioria das instalações as únicas informações confiáveis são o JCL e a listagem fonte dos programas (que nem são muito legíveis).
7.GRANDE FALHA OCULTA DO DESENVOLVIMENTO
Os sistemas não são projetados para manutenção como são os produtos da indústria.
“O principal problema na atividade de manutenção é que você não pode fazer manutenção em um sistema que não foi projetado para a manutenção.” (WEINBERG/78)
POSTURA GERENCIAL
Na reflexão sobre as 7 classes de problemas, vemos:
necessidade de se ter métodos mais rigorosos como o fator de minimização dos problemas:
1 – rotatividade
2 – falta de reconhecimento
3 – documentação deficiente
dificuldade de se criar métodos genéricos e que possam ser ensinados, capazes de atender à grande gama de sistemas construídos sob os mais variados critérios de desenvolvimento.
Esta dificuldade é compreendida na exposição dos problemas:
5 – dependência do método de desenvolvimento
6 - sistemas projetados sem preocupação com a manutenção
Isto nos impõem mais ou menos o seguinte:
- na impossibilidade de se dispor de métodos elegantes e genéricos, capazes de trazer a felicidade a todos os mantenedores de sistemas, dispomos de 2 caminhos:
1 – promover um esforço de estruturação e reorganização de seu patrimônio de software de maneira gradativa e planejada, convivendo com os dois ambientes durante algum tempo. (ver “tecnologias RE-3” mais adiante). Assim você estará migrando para a situação de manutenção em sistemas estruturados onde terá melhores opções. Desta forma poderá dispor de métodos mais gerenciáveis para as novas versões, e fatalmente acabará incorporando um ciclo de vida evolutivo para desenvolvimento e manutenção.
2 – organizar as atividades de manutenção tendo em vista os métodos de desenvolvimento adotados na organização. Muitas ferramentas e técnicas de desenvolvimento podem ser adaptadas. Os métodos possíveis nestes casos são mais elásticos, compondo-se de dicas, check-list e principalmente uma regulamentação severa na documentação das manutenções, bem como manutenção da integridade da documentação existente. A documentação é o ponto a ser atacado onde se pode auferir melhores ganhos na manutenção. É o investimento necessário e com retorno garantido.
Confesso serem estas as alternativas que minha limitada observação pode resumir. O que tenho encontrado são sempre soluções parciais, úteis mas não genéricas e convido o leitor amigo a mais este desafio que é a busca do Eldorado do informática. E quem encontrar a solução poderá até ficar rico e com todo mérito.
Se você não fizer alguma coisa para resolver o seu problema com manutenção, o mais provável é que é que daqui a dez anos você esteja fazendo a mesma coisa.
Existem 3 tecnologias se consolidando dentro do contexto, a partir do final da década de 80 e que prometem para os anos 90.
1 – Reestruturação
2 – Re-Engenharia
3 - Engenharia Reversa
Parte 1
MANUTENÇÃO DE SOFTWARE OU REENGENHARIA
(MAIS PROBLEMAS QUE SOLUÇÃO)
Antes se falava apenas em DESENVOLVIMENTO e MANUTENÇÃO.
Hoje, com a proliferação de termos geralmente emprestados de áreas com maior tradição, como a indústria, vemos proposta de organização das atividades de gerenciamento e construção de software, sob o título: ENGENHARIA DE SOFTWARE.
No bojo desta analogia, temos também a ampliação do problema já existente que é privilegiar as atividades de desenvolvimento tornando a manutenção uma atividade nada atraente, amaldiçoada mesmo. Isto porque na indústria a Engenharia projeta produtos, enquanto que quem conserta estes produtos é um técnico bem menos qualificado.
Em que pese as atividades requeridas na manutenção de software não serem análogas, pois o termo de software não serem análogas, pois o termo é mal empregado como veremos mais adiante, a pessoa que trabalha com manutenção é a que menos recebe nas organizações a ponto de não se orgulharem do que fazem.
Mas e agora, a manutenção fica dentro ou fora do aparato de Engenharia de Software?
Se pertence à Engenharia de Software, e sendo a manutenção responsável por mais de 50% do orçamento com processamento de dados nas organizações, o que explica tanto descaso?
Quais as técnicas de manutenção consagradas e que são ensinadas nos cursos de formação e aperfeiçoamento de programadores e analistas?
O software em desenvolvimento hoje, estará em operação amanhã. Por mais bem projetado e construído, terá que funcionar ao longo do tempo, resistindo a todas intempéries que o mundo real lhe impõe.
Ao longo deste tempo, pretende-se desfrutá-lo e compensar todo investimento financeiro, esforço e angústia na espera pela implantação. Daí então vem um pacote econômico, e...
Não é novidade que todo software existente na organização representa um patrimônio que além de ter custado muito caro (oneroso)) lhe -e muito caro (necessário) pois faz parte da engrenagem que move os negócios da organização.
Mesmo com as técnicas mais avançadas de desenvolvimento estes velhos pioneiros continuarão existindo e não é prudente ignorar este fato.
PROBLEMAS COM A MANUTENÇÃO DE SOFTWARE.
Este é um tema mais se encontra matéria nos poucos artigos sobre o assunto.
Assim, procurei selecionar e resumir as classes de problemas mais representativos para uma reflexão e análise das causas e efeitos destes problemas.
1.ROTATIVIDADE DE PESSOAL
As pessoas se sentem motivadas na construção do software. Quando têm que trabalhar na manutenção – mesmo dos sistemas feitos por elas – procuram mudar de emprego ou de setor.
2.POUCA IMPORTÂNCIA À ATIVIDADE
(falta de reconhecimento)
Quando técnicos de desenvolvimento também lidam com manutenção, ao invés de usar processos os quais dominam usam no desenvolvimento, correm com o trabalho consertando programas e resolvendo o problema emergente o mais rápido para voltar às atividades de desenvolvimento. Com o tempo os programas ficam de difícil compreensão e a documentação se deteriora.
A pressão que o técnico se impõe tem a ver tanto com a falta de recompensa na satisfação pessoal, como na baixa valorização deste trabalho por parte de sua chefia que também geralmente subestima prazos e esforços.
3.ABRANGÊNCIA DO TERMO - mau emprego do termo.
A manutenção do hardware visa resolver algum problema causado por componentes que deixam de funcionar conforme as especificações.
No caso do software, nada garante que este atendia todas as especificações nem que tenha sido testado. Muitas atividades de manutenção são uma extensão dos testes e mesmo da construção.
O próprio termo é um erro, pois as aplicações e os programas fisicamente não se desgastam como peças. Ocorreu de “pegar” a palavra manutenção e agora é difícil mudar.
O próprio Dr. Dijkstrta, inventor do termo “Programação Estruturada”, lamenta este fato mas pelo jeito não encontrou nenhum outro nome que “colasse”.
4.NEGLIGÊNCIA TECNOLÓGICA
Apesar da Engenharia de Software pretende abranger o tema, o pouco que se tem publicado diz respeito mais à manutenção dentro do processo de desenvolvimento continuado que é o ciclo de vida em LOOP.
Pouca solução foi disponibilizada ao longo da década de 80 para atender a manutenção do acervo existente, construído fora dos conceitos da Engenharia de software.
Surgiram alguns produtos para reestruturação de programas, conversão de linguagens, mas não houve avanços significativos na esfera teórica e conceitual, como aconteceu na área de desenvolvimento.
5.DEPENDÊNCIA DO MÉTODO DE DESENVOLVIMENTO
Quando sistemas são construídos sem métodos, é impossível criar método para entendê-los.
Lei de Parikh:
“Nenhum método para desenvolvimento = Nenhum método para manutenção”
Quando o método utilizado no desenvolvimento é completo, este já aponta métodos de manutenção. Isto ocorre nos trabalhos do Dr. Warnnier:
LCP – Lógica de Construção de Programas e
LCS – Lógica de Construção e Sistemas.
Seria ótimo se os métodos mais modernos também adquirissem esta característica.
6.DOCUMENTAÇÃO DISPONÍVEL DEFICIENTE
Em muitos casos a documentação é solenemente ignorada. Principalmente nas atividades de manutenção, o que é um paradoxo.
A menos que haja grande rigor nesta tarefa com o tempo, o conceito e a documentação do projeto original não refletem o estado presente do sistema.
Na maioria das instalações as únicas informações confiáveis são o JCL e a listagem fonte dos programas (que nem são muito legíveis).
7.GRANDE FALHA OCULTA DO DESENVOLVIMENTO
Os sistemas não são projetados para manutenção como são os produtos da indústria.
“O principal problema na atividade de manutenção é que você não pode fazer manutenção em um sistema que não foi projetado para a manutenção.” (WEINBERG/78)
POSTURA GERENCIAL
Na reflexão sobre as 7 classes de problemas, vemos:
necessidade de se ter métodos mais rigorosos como o fator de minimização dos problemas:
1 – rotatividade
2 – falta de reconhecimento
3 – documentação deficiente
dificuldade de se criar métodos genéricos e que possam ser ensinados, capazes de atender à grande gama de sistemas construídos sob os mais variados critérios de desenvolvimento.
Esta dificuldade é compreendida na exposição dos problemas:
5 – dependência do método de desenvolvimento
6 - sistemas projetados sem preocupação com a manutenção
Isto nos impõem mais ou menos o seguinte:
- na impossibilidade de se dispor de métodos elegantes e genéricos, capazes de trazer a felicidade a todos os mantenedores de sistemas, dispomos de 2 caminhos:
1 – promover um esforço de estruturação e reorganização de seu patrimônio de software de maneira gradativa e planejada, convivendo com os dois ambientes durante algum tempo. (ver “tecnologias RE-3” mais adiante). Assim você estará migrando para a situação de manutenção em sistemas estruturados onde terá melhores opções. Desta forma poderá dispor de métodos mais gerenciáveis para as novas versões, e fatalmente acabará incorporando um ciclo de vida evolutivo para desenvolvimento e manutenção.
2 – organizar as atividades de manutenção tendo em vista os métodos de desenvolvimento adotados na organização. Muitas ferramentas e técnicas de desenvolvimento podem ser adaptadas. Os métodos possíveis nestes casos são mais elásticos, compondo-se de dicas, check-list e principalmente uma regulamentação severa na documentação das manutenções, bem como manutenção da integridade da documentação existente. A documentação é o ponto a ser atacado onde se pode auferir melhores ganhos na manutenção. É o investimento necessário e com retorno garantido.
Confesso serem estas as alternativas que minha limitada observação pode resumir. O que tenho encontrado são sempre soluções parciais, úteis mas não genéricas e convido o leitor amigo a mais este desafio que é a busca do Eldorado do informática. E quem encontrar a solução poderá até ficar rico e com todo mérito.
Se você não fizer alguma coisa para resolver o seu problema com manutenção, o mais provável é que é que daqui a dez anos você esteja fazendo a mesma coisa.
Existem 3 tecnologias se consolidando dentro do contexto, a partir do final da década de 80 e que prometem para os anos 90.
1 – Reestruturação
2 – Re-Engenharia
3 - Engenharia Reversa