Depois que um software é colocado em funcionamento, ou seja, depois que o mesmo é implantado, com certeza ocorrerá mudanças que levarão à alteração desse software. Essas mudanças podem ser, de acordo com Pressman (2011, p. 662), para correção de erros não detectados durante a etapa de validação do software, quando há adaptação a um novo ambiente, quando o cliente solicita novas características ou funções ou ainda quando a aplicação passa por um processo de reengenharia para proporcionar benefício em um contexto moderno. Sommerville (2011, p. 29) coloca que, historicamente, sempre houve uma fronteira entre o processo de desenvolvimento de software e o processo de evolução desse mesmo software (manutenção de software). O desenvolvimento de software é visto como uma atividade criativa, em que o software é desenvolvido a partir de um conceito inicial até chegar ao sistema em operação. Depois que esse sistema entrou em operação, inicia-se a manutenção de software, no qual o mesmo é modificado. Normalmente, os custos de manutenção são maiores do que os custos de desenvolvimento inicial, mas os processos de manutenção são considerados menos desafiadores do que o desenvolvimento de software original, ainda que tenha um custo mais elevado.
Porém, atualmente, os estágios de desenvolvimento e manutenção têm sido considerados como integrados e contínuos, em vez de dois processos separados. Tem sido mais realista pensar na engenharia de software como um processo evolucionário, em que o software é sempre mudado ao longo de seu período de vida, em resposta a requisitos em constante modificação e às necessidades do cliente.
CONSIDERAÇÕES FINAIS
Chegamos ao final de mais uma unidade. Nesta segunda unidade você conheceu o que é um processo de software e também alguns modelos de processo de software.
Um processo de software é um conjunto de atividades com resultados (artefatos) associados a cada uma delas que leva à produção de um software. Todo software deve ser especificado, projetado, implementado e validado. E, após o seu uso pelo usuário, passa por evoluções. Todas essas etapas são muito importantes, mas vimos que a especificação do software é uma etapa imprescindível nesse conjunto, pois, se os requisitos não forem esclarecidos, bem especificados, no início do desenvolvimento, há uma grande chance do software não atender às necessidades do cliente. No tempo que trabalhei com desenvolvimento de sistemas vi isso acontecer algumas vezes. E sabem o que acontece? O usuário acaba não utilizando o sistema e assim o sistema acaba não atingindo o seu objetivo. Na próxima unidade vamos tratar o assunto Requisitos de Software mais detalhadamente, justamente pela importância que mencionei acima.
Após os requisitos estarem declarados e validados, vimos que o projeto do sistema deve ser realizado. Nessa etapa, o sistema é modelado de forma bem detalhada, pois a próxima etapa é a implementação do software. Na unidade quatro trataremos com mais detalhes sobre a modelagem do sistema, em especial sobre a linguagem de modelagem unificada (UML –
Unified Modeling Language). A implementação é a escrita do sistema em uma linguagem de
programação. Nesta disciplina veremos somente a parte teórica relacionada à implementação, pois a parte prática faz parte de outras disciplinas do seu curso.
Mas, afinal, qual a diferença entre processo de software e modelo de processo de software? Um processo de software é o conjunto de atividades (mencionadas acima) e um modelo de processo de software é uma representação abstrata de um processo de software, ou seja, define a sequência em que as atividades do processo serão realizadas.
Existem vários modelos de processo de software descritos na literatura, porém nesta unidade vimos somente alguns desses modelos. O primeiro foi o Modelo em Cascata, que representa as atividades do processo (especificação, desenvolvimento, validação e evolução) como fases separadas, onde uma só pode acontecer depois que a anterior tenha sido concluída. O segundo modelo foi o Desenvolvimento Incremental, que tem como base a ideia de desenvolver uma
implementação inicial, expor ao comentário do usuário/cliente e fazer seu aprimoramento por meio de muitas versões, até que um sistema adequado tenha sido desenvolvido. Nesse modelo, em vez de ter as atividades de especificação, desenvolvimento e validação em separado, todo esse trabalho é realizado concorrentemente. O último modelo que estudamos foi a Engenharia de Software Baseada em Reuso, que baseia-se na existência de um número significativo de componentes reusáveis, sendo que o processo de desenvolvimento de sistemas se concentra na integração desses componentes em um sistema, em vez de partir do zero.
Mas, afinal, qual o melhor modelo de processo de software para uma empresa? Infelizmente a resposta para essa pergunta não é tão simples. Não existe um processo ideal de software e os modelos não são mutuamente exclusivos e na maioria das vezes, podem ser usados em conjuntos, em especial para o desenvolvimento de sistemas de grande porte.
O aumento na demanda por software de qualidade vem causando grande pressão sobre as empresas que trabalham com desenvolvimento de software. As entregas de software obedecendo ao cronograma e custos previstos vêm se tornando, a cada dia, um diferencial importante nesse ramo de atividade. Por isso, as empresas procuram por processos de software que propiciem o desenvolvimento de produtos com qualidade, e que respeitem o custo e cronograma previstos.
Na próxima unidade vamos conhecer um pouco mais sobre requisitos de software e entender por que os requisitos são tão importantes em um processo de software.
ATIVIDADE DE AUTOESTUDO
1. Faça um comparativo entre os Modelos de Processo de Software Modelo Cascata e Desenvolvimento Incremental.
2. Explique cada uma das atividades básicas que compõem um processo de software. Essas atividades devem ser realizadas sempre na ordem descrita nesta unidade? Justifique sua resposta.
3. Considerando os modelos de processo de software apresentados nesta unidade, de- fina um modelo de processo de software que poderia ser utilizado por uma pequena