Desenvolvimento Global de Software Mestrado de Informática / UFPB Francilene Procópio Garcia, D.Sc. Manutenção de Software - Parte VII

Introdução  A manutenção de software também é um desafio em projetos virtuais: u em grandes sistemas, por exemplo, sempre se questiona “quem” será o responsável por manter “o que” u o desafio cresce em produtos direcionados para múltiplos mercados devido a existência de diferenças culturais u os grupos virtuais acabam se concentrando mais na obtenção das versões do cliente num dado cronograma, deixando o planajemento da manutenção num segundo plano  Começar a pensar na manutenção do produto antes de seu início efetivo é essencial em projetos virtuais

Diferenças Culturais  Particularmente, em se tratando de projetos virtuais, as diferenças culturais devem ser gerenciadas, evitando problemas em fases posteriores tais como: u definição do escopo das atividades de manutenção, tamanho da equipe de suporte e indicadores de qualidade no atendimento ao cliente u no mercado Americano, por exemplo, tende-se a alocar o staff do desenvolvimento em novos projetos o mais rápido possível, o que pode causar algum desgaste na condução das atividades de manutenção em produtos acabados - suporte técnico curto prazo u já na cultura Oriental, por outro lado, a tendência é se manter o staff do desenvolvimento por mais tempo para garantia da qualidade e integridade do produto junto ao mercado - suporte técnico longo prazo u Outra prática em países da Europa (UK) é a do “you get what you pay for”

Modelos de Manutenção  Uma das razões para se adotar um modelo de manutenção é a necessidade da definição de “quem” é o responsável por resolver “o que” u em geral, o modelo de manutenção é definido ainda na fase contratual, prevendo recursos, ferramentas e pessoal para sua execução  Dentre os modelos de manutenção aplicados em projetos virtuais, os mais comuns são: u distribuído - cada organização virtual é responsável por parte da manutenção u centralizado - uma organização virtual é contratada para assumir a manutenção u simples - uma das organizações virtuais envolvidas assume a manutenção

Modelos de Manutenção: Distribuído  Informações enviadas às organizações: problemas encontrados, condições para ocorrência do problema, dados sobre a versão do produto, outros problemas conhecidos e suas soluções Software é entregue ao mercado Upgrades Problemas Staff Revisões Organização Desenvolvimento 1 Organização Desenvolvimento 2 Organização Desenvolvimento 3

Modelos de Manutenção: Centralizado  As atividades realizadas são as mesmas do modelo distribuído, porém a organização contratada é focada na manutenção e suporte do produto junto aos clientes Software é entregue ao mercado Upgrades Problemas Organização contratada para manter o produto

Modelos de Manutenção: Simples  A organização responsável pela manutenção herda a biblioteca de configurações do software, as ferramentas, entre outras informações para manter uma base sólida acerca do produto Software é entregue ao mercado Upgrades Problemas Organização Desenvolvimento 1 Manutenção Organização Desenvolvimento 2 Organização Desenvolvimento 3

O Ambiente para Manutenção  O ambiente difere em função do modelo de manutenção adotado  Todo software alterado deve ser testado, inclusive as partes de documentação usadas pelo usuário  Testes de regressão são muito usados para verificar a integridade de código fonte alterado Biblioteca de Configurações do Desenvolvedor Ambiente de Manutenção do Software Cópia do Software    Original Upgrade

Estágios do Produto de Software  Desenvolvimento inicial: primeira versão do sistema é obtida  Evolução: as facilidades do sistema são estendidas em atendimento às novas demandas  Manutenção: conserto de pequenos defeitos e mudanças funcionais de baixa complexidade  Phaseout: finalização das atividades de manutenção, apesar de manter o produto no mercado  Closedown: retirada do produto do mercado Desenvolvimento Inicial Evolução Manutenção Phaseout Closedown Mudanças Reparos Perda na capacidade de evoluir Manutenção descontinuada Retirada

Desenvolvimento Inicial  Este estágio é sempre bem documentado e faz uso de várias ferramentas  Em geral, apresenta dois elementos chaves: u Grupo de software: pessoas que atuam sobre um dado domínio de problema para produzir um sistema u Arquitetura do sistema: os componentes do sistemas e suas iterações, que deixam claro para o onde o sistema deve evoluir Desenvolvimento Inicial Evolução Manutenção Phaseout Closedown Mudanças Reparos Perda na capacidade de evoluir Manutenção descontinuada Retirada

Evolução  Se o desenvolvimento inicial obtém sucesso, o produto entra na sua fase evolutiva  Em geral, as funcionalidades devem mudar em torno de 30% ou mais  As vezes as empresas preferem entregar o produto ao mercado apenas após algumas iterações, assegurando a retirada de falhas críticas  Testes alfa e beta são muito usados nesta fase Desenvolvimento Inicial Evolução Manutenção Phaseout Closedown Mudanças Reparos Perda na capacidade de evoluir Manutenção descontinuada Retirada

Manutenção  Para evoluir, o software necessita ter uma arquitetura bem definida e uma boa equipe de desenvolvimento  Quando esses elementos começam a perder sua importância, começa o estágio de manutenção  Durante esta fase, as mudanças são, em geral, onerosas e mais difíceis - cada pequena mudança pode degradar a arquitetura  Sistemas críticos jamais devem entrar em estágios de manutenção Desenvolvimento Inicial Evolução Manutenção Phaseout Closedown Mudanças Reparos Perda na capacidade de evoluir Manutenção descontinuada Retirada

Phaseout  Durante o estágio phaseout, a empresa não se preocupa mais em manter o sistema e tenta continuar tendo receita com o produto  Os usuários passam a lidar com os problemas encontrados, sem intervenção da empresa Desenvolvimento Inicial Evolução Manutenção Phaseout Closedown Mudanças Reparos Perda na capacidade de evoluir Manutenção descontinuada Retirada

Closedown  Durante a fase final, a empresa retira o produto do mercado e sugere a substituição por outro sistema, se existir  Algumas responsabilidades legais poderão ser conduzidas pela empresa - por exemplo no caso de sistemas desenvolvidos por terceiros, onde existem certas obrigações contratuais Desenvolvimento Inicial Evolução Manutenção Phaseout Closedown Mudanças Reparos Perda na capacidade de evoluir Manutenção descontinuada Retirada

Características dos Estágios  Experiência do Grupo u É mais crítica nos dois estágios iniciais - Desenvolvimento e Evolução, onde o grupo dever conhecer o domínio do produto, gerar sua arquitetura, gerenciar as diferentes locações de desenvolvimento e conduzir-se diante de padrões e legislações específicos u Nos demais estágios a experiência ajuda, porém não é tão crítica, uma vez que grandes mudanças são mais raras. O produto é visto como uma caixa preta

Características dos Estágios  Arquitetura do software u É estabelecida na fase do desenvolvimento inicial, onde os grupos se comprometem em seguí-la, estabelecendo um caminho para a evolução do produto u Na medida em que as mudanças se acumulam, a arquitetura tende a se degradar, perdendo a sua integridade. Nestes casos, recomenda-se uma reestruração no código, de forma a se retomar uma arquitetura que possa continuar a evoluir u Na fase de manutenção, em geral, os reparos são bastante limitados em escopo e devem gerar baixo impacto sobre os componentes do produto

Características dos Estágios  Deterioração do software u Relaciona-se diretamente com a saída dos desenvolvedores mais experientes e com a perda de integridade da arquitetura do produto. Sem os mais experientes fica mais difícil se retomar a arquitetura do sistema... u Em geral, a reengenharia do produto é uma tentativa de se impedir a completa deterioração do software, porém é cara, lenta e cheia de riscos para a empresa e, raramente consegue retornar da fase de manutenção para a evolução u Uma alternativa é “empacotar” os problemas em novos componentes de software e isolar os sub-sistemas com perdas no estágio phaseout

Características dos Estágios  Aspectos econômicos u Desenvolvimento inicial - altos investimentos e baixo retorno. Os desenvolvedores preferem sempre uma rápida entrada do produto no mercado, porém a capacidade do produto evoluir pode ser prejudicada u Evolução - alta demanda do mercado, bom retorno dos investimentos. Neste ponto, a empresa já deve estar se preparando para novos desenvolvimentos u Manutenção - deve iniciar quando as vendas do produto começarem a cair

Conclusões  Face aos cinco estágios de um produto: u Cada estágio aplica diferentes técnicas, processos, grupos e práticas de gestão u O gerente de produto que consegue enxergar mais claramente as transições entre os cinco estágios poderá planejá-los melhor u É sempre indicado buscar por manter o produto num dos estágios mais tempo o quanto for possível u Os projetistas devem prever uma arquitetura flexível que possa ser mantida na fase de evolução sem grandes problemas u Os estágios citados também dever ser aplicados ao desenvolvimento de componentes