Engenharia de Software - Modelos de Processos de Software!

É fato a necessidade de organização que uma equipe de desenvolvimento necessita para confeccionar um produto de software! Mas qual padrão seguir? Que modelo utilizar?

Mais do que essencial hoje em dia, é super-necessário utilizar-se de um modelo de desenvolvimento na produção de um software, pois mesmo falando-se de programadores "solos", ou autônomos, crê-se que o objetivo do felizardo é crescer, expandindo os seus horizontes no comércio, e consequentemente, aprimorando o seu produto. Mas como pode-se ter uma manutenção ou alteração confiável em um projeto sem a devida documentação da engenharia que deveria ter sido empregada? E se aquele desenvolvedor solo precisar contratar uma equipe, como "os camaradas" desenvolverão suas devidas partes sem conhecerem em que estão mexendo?

Por estes e outros assuntos descritos acima é que a história do desenvolvimento na informática criou os chamados Modelos de Processos de Software, onde o engenheiro de software pode organizar o projeto da forma mais adequada para a situação. Veremos agora alguns conceitos:

Processo de Software: "...é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software." - segundo WikiPedia;

Atividades: etapa preestabelecida, com um início e um fim, em um processo de software;

Modelos de Processos de Software: é o padrão de organização e representação dos objetos e atividades envolvidas no processo de software. Ainda não existe um modelo universal que supra as necessidades de todos os projetos, o engenheiro seleciona o que lhe for melhor para a gerência do processo;

Abaixo abordaremos alguns dos modelos mais realçados:

1 - Modelo Cascata:

Seguindo uma abordagem sequencial no desenvolvimento, a partir do momento em que uma fase do desenvolvimento chega ao fim, prossegue-se para a próxima fase, e não há retorno.

São algumas das desvantagens do seu uso:

"

• Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe.
• Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente logo no início.
• Exige paciência do cliente. Uma versão do software não estará disponível até um ponto tardio do cronograma do projeto. Um erro grosseiro, se não detectado, pode ser desastroso." - segundo Central da Engenharia.

Apesar de muitos outros modelos tê-lo como base ou de alguma forma implementá-lo, este não é o caminho ideal para a gerência de grandes projetos, pois além de não ser iterativo e modularizado, o projeto acaba seguindo até o final sem poder voltar a uma fase anterior para correções.

2 - Modelo Iterativo e Incremental:

Este modelo combina elementos do anterior, sendo aplicado de maneira iterativa(repetitiva), tem como objetivo apresentar um produto operacional a cada incremento realizado.

Como podemos ver na figura acima, para cada "pedaço do software" a ser produzido segue-se um modelo cascata.

É um modelo muito útil quando a empresa não possui mão de obra disponível no momento para uma implementação completa, dentro do prazo estipulado, e identificando os riscos numa fase inicial, o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final de projeto.

3 - Modelos Evolutivos de Processo:

Neste modelo, o software deve ser desenvolvido de forma a evoluir a partir de protótipos iniciais. As atividades são executadas de forma cíclica ou iterativa(sempre voltando ao início ao final de cada módulo desenvolvido). Começa-se com o design e desenvolvimento de um protótipo inicial, que deve ser mostrado aos usuários e avaliado. Durante a avaliação novos requisitos são definidos e alterações e incrementos ao protótipo inicial devem ser feitas. Repete-se este ciclo até atingir-se o produto final.

Como vantagem, ele permite a verificação antecipada do produto final por engenheiros, clientes e usuários, permitindo a correção dos problemas detectados, porém o fato de basear o software no incremento de protótipos acaba levando o projeto a arquiteturas mal definidas e mal documentadas, o que gera deficiência no desempenho, portabilidade, manutenção e outras qualidades internas.

É um bom modelo para ser utilizado quando não é possível ter uma minuciosa coleta de requisitos.

4 - Modelos Especializados de Processo:

Abrange muitas das características dos demais modelos, porém, eles tendem a ser aplicados quando há uma abordagem de engenharia de software bem escolhida.

Podemos dividi-lo em:

4.1 - Desenvolvimento Baseado em Componentes(DBC)

Aproveitando muitas das características dos modelos evolucionários, segue-se uma abordagem iterativa para a produção de software, compondo aplicações a partir de componentes predefinidos.

Componente: Na Engenharia de Software, segundo Krutchen, o componente é um elemento independente, que pode ser substituído, contudo, ele é significativo, pois tem uma função clara no contexto em que foi definido;

Logo percebe-se que o DBC baseia-se em partes de software independentes e substituíveis, com funcionalidades específicas e de característica reutilizável. Mesmo com tudo isso, não torna de um componente um objeto, mas talvez um pacote de classes, que juntas formam um todo independente, que recebe entradas e retorna saídas necessárias ao fim preterido.

Para chegar ao seu fim, o DBC dispõe dos seguintes passos:

• Produtos baseados em componentes disponíveis são pesquisados e avaliados para o domínio da aplicação;
• Tópicos de integração de componentes são considerados;
• Uma arquitetura de software é projetada para acomodar os componentes;
• Componentes são integrados à arquitetura;
• Testes abrangentes são realizados para garantir a funcionalidade adequada;

OBS.: Leva à reutilização de código, o que fornece à equipe de desenvolvimento ganhos significativos.

4.2 - Métodos Formais:

Abrange um conjunto de atividades que levam à especificação formal de um software de computador, e são feitos rigorosos cálculos matemáticos.

Estes cálculos são essenciais na produção de softwares críticos, em termos de segurança e de alta integridade, no qual há alta probabilidade das falhas conduzirem para a perda da vida ou sérios prejuízos.

Exemplo.: Um sistema de controle de tráfego aéreo;

4.3 - Desenvolvimento Orientado a Aspectos:

Utiliza-se constantemente um conjunto de características formados pela importância para a aplicação, funções, e conteúdos de informações de determinado software. Estas características são modeladas como componentes.

5 - Modelo de Processo Unificado:

Apoia-se no que há de melhor dos modelos convencionais, desde recursos a características, além de se preocupar com a ligação direta com o cliente, facilitando assim uma melhor analise dos requisitos.

É separado nas seguintes fases:

OBS.: para melhor compreensão das fases abaixo, olhar para a figura acima.

• Iniciação - Relaciona-se com as atividades de comunicação com o cliente e planejamento de um plano de natureza iterativa. Estabelece uma visão global do projeto, identificando os requisitos e definindo riscos;
• Elaboração - Relaciona-se com a comunicação com o cliente e atividades de modelagem. É responsável por produzir uma descrição arquitetural e um projeto preliminar;
• Construção - Relaciona-se com a atividade de construção na qual são desenvolvidos ou adquiridos os componentes que logo em seguida são aplicados no código fonte, sempre sendo realizados testes;
• Transição - Abrange-se os últimos estágios da atividade de construção e a primeira parte da atividade de implementação. É a fase em que são feitos testes finais pelos usuários que darão relatórios de feedbacks sobre defeitos e modificações necessárias;

Fica ai a dica para quem está passando por Engenharia de Software. Não deixem de comentar!

Abraços!

Ass.: David de Almeida Bezerra Jr