Processos de Software

           Neste artigo serão apresentados modelos de processos de software, necessário para o entendimento do ciclo de desenvolvimento do software.

           Para Jacobson, Booch e Rumbaugh (1999) um conjunto de atividades define que pessoa está desenvolvendo o quê, em que ocasião e como, para cumprir um objetivo estabelecido. Já Pádua (2009, p. 11) define processo como “um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta”. Os processos de desenvolvimento de software tiveram evoluções com o proposito em explorar a experiência das pessoas dentro das empresas juntamente com as características dos programas (RIBEIRO, 2012).

           Processos de software são etapas, que determinam, a maneira com que um projeto irá seguir durante todo o seu ciclo de desenvolvimento. Existem, diferentes tipos de software para suprir diversas necessidades, para isso, são necessários diferentes processos de desenvolvimento que se adeque a cada projeto. Diante disso, o conhecimento e experiência de uma equipe de desenvolvimento de software, influencia na qualidade do progresso do sistema, pois, se a mesma não compreender cada uma das etapas, o projeto pode ser interrompido.

           Segundo Sommerville (2011) um processo de desenvolvimento de software é um conjunto de etapas que dá seguimento a criação de um software. Um processo de software pode determinar o sucesso ou não de um projeto, pois tudo depende de qual melhor forma se adapta ao mesmo. No trecho abaixo explica bem o que autor quer passar:

Um modelo de processo de software é uma representação simplificada de um processo de software. Cada modelo representa uma perspectiva particular de um processo e, portanto, fornece informações parciais sobre ele. (SOMMERVILLE, 2011, p. 19)

           Não há um modelo de processo padrão a ser implementado a cada projeto de software que surge, é necessário avaliar, que tipo de software irá ser desenvolvido e definir um processo com melhores resultados. Conforme Pressman (2011) um processo engloba "flexibilidade" em adaptação, que dão alternativas a uma equipe de projetistas de software a responsabilidade em adotar um conjunto adequado de ações e tarefas para o projeto. Ainda Pressman (2011) descreve que o intuito é entregar o produto (software) de acordo com o prazo estipulado e que seja de alta qualidade, para satisfazer as expectativas dos patrocinadores e de quem irá utiliza-lo.

           Os modelos de processos de software surgiram a partir da necessidade de buscar possíveis soluções a projetos a serem explorados, pois só no momento que uma equipe de desenvolvedores se depara com um projeto difícil é que surge a “carência” de um modelo. Nos tópicos seguintes serão explicados alguns dos modelos de processo de software.

Nas próximas seções serão apresentados alguns dos modelos mais relatados na literatura (SOMMERVILLE, 2011; PRESSMAN, 2010; PADUA, 2009).  

2.1.1  Modelo Cascata 

O Modelo Cascata é o mais antigo dentre os outros modelos, mais usual, sendo uma abordagem gradual, possuindo uma sequência de passos que devem ser seguidas, metodologicamente. São estabelecidas fases, e essas fases possuem técnicas (atividades) que devem ser cumpridas.  

·                   Definição de requisitos: onde vai ser estabelecido todo o padrão, o que estará “dentro” do software, esse processo requer a comunicação do desenvolvedor e o cliente.

·                   Projeto de sistemas e de software: Onde vai ser definido todo o modelo de software da aplicação.

·                   Implementação e teste de unidades: a implementação é feita por partes, então é realizada um teste somente nessas partes, ou seja, cada integrante de uma equipe de desenvolvimento tem uma responsabilidade.

·                   Integração e teste de sistemas: Baseia-se na Integração dessas pequenas partes de programa do processo anterior, são testados como um sistema completo, para garantir que os requisitos do mesmo foram atendidos, após os testes, o sistema é liberado como produto final.

·                   Operação e Manutenção: Normalmente é a fase mais extensa do ciclo de vida, o sistema é instalado e posto em operação. A manutenção procura erros que não foram encontrados em estágios anteriores do ciclo de vida. 

As fases do modelo em cascata seguem conforme mostra a Figura 1.

Figura 1: Modelo Cascata

  Fonte: Sommerville (2011, p.20).

2.2 Desenvolvimento Evolucionário 

Desenvolvimento Evolucionário referem-se aos modelos que a cada interação são acrescentados uma série de versões. Com a inclusão de novas versões o software fica mais completo, evoluindo com o decorrer do processo de interação entre o cliente e o desenvolvedor, o usuário é que vai definir quais os papéis e os requisitos que estarão presentes no software. Abaixo encontram-se dois tipos essenciais de desenvolvimento evolucionário:

Desenvolvimento exploratório: procura explorar a comunicação entre cliente e desenvolvedor, buscando analisar os requisitos e entregar o software final. O desenvolvimento inicia com as fases do mesmo entendidas. O software evolui de acordo com as novas perspectivas proposta pelo cliente.

Prototipação throw away: Compreender as exigências do cliente e, diante disso, implementar melhor definição de requisitos para o software.

O desenvolvimento evolucionário em confrontação na produção de programas que atendam às necessidades imediatas aos interessados no sistema, frequentemente, é mais eficaz do que uma abordagem em cascata. O trecho abaixo exemplifica melhor a vantagem:  

A vantagem de um processo de software baseado na abordagem evolucionária é que a especificação pode ser desenvolvida de forma incremental. À medida que os usuários compreendem melhor seu problema, isso pode ser refletido no sistema de software (SOMMERVILLE 2011, p. 45) 

A figura 2 demonstra os passos do modelo evolucionário, que tem início com a descrição do projeto. Logo depois, implementa-se a primeira versão do programa e em seguida começam as análises do cliente para com a versão. Após as verificações, durante a implementação são criadas versões intermediarias do programa que “sofre” evoluções até cumprir a funcionalidade apropriada.

Figura 2: Desenvolvimento Evolucionário

Fonte: Sommerville (2011, p.22). 

2.3 Modelo Espiral 

           Segundo Pressman (2011, p. 65), o modelo espiral “é um modelo de processo de software evolucionário que acopla a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo cascata”. Para Sommerville (2011, p. 33), o “processo de software é representado como uma espiral, e não como uma sequência de atividades com alguns retornos de uma para outra. Cada volta na espiral representa uma fase do processo de software”. Este modelo é denominado em espiral pois as atividades de interações vão avançando formando uma espiral à medida que vai crescendo o projeto, o mesmo pode ser utilizado junto a outros modelos, por exemplo: modelo cascata. Cada loop no modelo espiral está divido em quatro fases:

·                   Definição de Objetivos: Nesta etapa são definidos os objetivos específicos do projeto. O Controle sobre o processo e produto são constatadas e é elaborado uma estratégia detalhada de gerenciamento, aqui, detecta-se os perigos do projeto;

·                   Avaliação e redução de riscos: Com a identificação de cada risco do projeto, uma verificação precisa é feita. Para reduzir os riscos “medidas” são realizadas.

·                   Desenvolvimento e validação: Após o processo anterior, um modelo de desenvolvimento para o software é escolhido.

·                   Planejamento: O projeto é reanalisado e uma escolha é “tomada” para dar continuação ao seguinte loop da espiral. Se a escolha aprovada for continuada, é necessário criar ideias para próxima etapa do projeto.

Figura 3: Modelo Espiral

Fonte: Sommerville (2011, p.33). 

2.4 Modelo Baseado em Componentes 

O modelo baseado em Componentes consiste em componentes reutilizáveis, em vez de desenvolvê-los a partir do zero novamente, o mesmo consiste em seis fases.

·                   Especificação de requisitos: semelhante com outros processos, por exemplo, modelo cascata.

·                   Análise de componentes: consiste na análise de componentes que vão satisfazer as necessidades do software que está em desenvolvimento.

·                   Modificação de requisitos: para adequá-los a cada um dos requisitos que vai ser atendido, cada uma das funcionalidades deve compor o sistema.

·                   Projeto de sistema com reuso: durante esta etapa o sistema é elaborado aplicando os componentes a serem reusados.

·                   Desenvolvimento e integração: As partes do software que não podem ser reusados são implementados e os componentes ou softwares de prateleira são incluídos para criar um programa.

·                   Validação de sistema: O sistema deve ser aprovado para garantir que atenda a especificação do cliente.

Figura 4: Modelo Baseado em Componentes

Fonte: Sommerville (2011, p.23).

 2.5 O Rational Unified Process

O Rational Unified Process (RUP) é um processo unificado de desenvolvimento de software, que a partir de alguns passos, viabiliza o objetivo final de um produto com qualidade, o mesmo é um produto comercializado pela IBM (International Business Machines). O processo unificado baseia-se em 4 fases:

1.   Concepção: detectar entidades externas: pessoas e sistemas, que irão “comunicar-se” com o software, e definir essas interações.

2.   Elaboração: Desenvolver o entendimento do problema através da Linguagem de Modelagem Unificada (UML).

3.   Construção: Essencialmente ligada ao projeto, programação e teste de software, ao concluir a fase, o software já deve estar em funcionamento e a documentação pronta para ser liberada ao cliente.

4.   Transição: A etapa de transição baseia-se na distribuição do sistema em uso no ambiente final. São essenciais, testes de aprovação e operação, capacitação de usuários e transição de dados a partir de sistemas antigos, que podem ser capturados automaticamente ou digitados.

Figura 5: Modelo Unificado

Fonte: Sommerville (2011, p.33).

REFERÊNCIAS

JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The Unified Software Development Process. New York: Addison-wesley Professional, 1999.

PRESSMAN, Roger S.. Engenharia de Software: Uma abordagem Profissional. 7. ed. São Paulo: Bookman, 2011. 780 p.