Skip to content

Gestão de Processos

Gustavo Matozinho Lima edited this page Mar 28, 2017 · 7 revisions

Introdução

Processo de software é um conjunto de atividades relacionadas que guiam a produção de um software (Sommerville). Essas atividades envolvem a produção de um software do zero em linguagens conhecidas, mas não necessariamente ocorrem sempre dessa forma. Novos softwares podem ser criados à partir de outros softwares já existentes.

Segundo Sommerville, existem diversos tipos de processo de software, mas todos eles envolvem quatro atividades fundamentais:

  • Especificação: as funcionalidades e limites do software devem ser definidos
  • Design e implementação: O software que atende às especificações deve ser produzido
  • Validação: O software deve ser validado para garantir que este faz o que o cliente solicitou
  • Evolução: O software evolui para atender as necessidades do cliente.

Processos de software são complexos e, como qualquer atividade intelectual, dependem de decisões e julgamentos feitos por pessoas. Logo, não existe um processo ideal, e sim a necessidade de adaptar o processo para obter os melhores resultados de acordo com o contexto.

Modelos de processo de software

Os modelos de processo de software são nada mais que abstrações do processo que são utilizadas para explicar diferentes caminhos para o desenvolvimento de software. São diretivas que devem ser adaptadas para o contexto do projeto.

Modelo em cascata

O modelo em cascata foi o primeiro dos modelos de software, derivado de processos genéricos da engenharia. Neste modelo, a produção do software é dividida em várias etapas, que são executadas por completo e de forma consecutiva.
As principais etapas do modelo em cascata são:

  • Análise de requisitos
  • Design do software
  • Implementação e testes unitários
  • Integração e testes de sistema
  • Operação e manutenção

Em princípio, cada etapa deve ser iniciada apenas quando a etapa for concluída. O resultado de cada etapa são documentos que devem ser aprovados. Na prática, essas etapas acabam se sobrepondo, e cada fase fornece informações para a fase seguinte. Esse modelo é melhor utilizado quando se tem um bom conhecimento dos requisitos, e estes não mudam drasticamente ao longo processo, caso contrário os problemas de uma etapa podem causar problemas significativos para as etapas seguintes e gerar grande quantidade de retrabalho.

Modelo Incremental

O modelo incremental consiste em apresentar um projeto inicial, que será melhorado no decorrer do projeto, e estas melhorias são entregues ao cliente pouco a pouco em várias versões do software. As fases de especificação, desenvolvimento e validação são intercaladas nessas pequenas entregas, gerando feedbacks rápidos ao longo das atividades.

Esse modelo de software representa melhor a maneira como as pessoas resolvem problemas, e é uma parte fundamental do processo de desenvolvimento ágil. Cada fase do projeto inclui uma das funcionalidades solicitadas pelo cliente, e assim o cliente consegue avaliar o sistema desde o início de sua produção, dando feedback ao longo do processo. Assim, os custos para acomodar mudanças solicitadas pelo cliente são reduzidos, e ainda podem ser feitas pequenas entregas de funcionalidades que já servem de algo para o cliente mesmo com o software incompleto.

Os maiores problemas do modelo incremental são:

  • Geração de documentos: como são feitas várias pequenas entregas, perde-se mais tempo gerando documentos para cada uma delas, o que não é custo-efetivo
  • A estrutura do software se degrada conforme novos incrementos vão sendo adicionados, e se não forem gastos tempo e recursos para refatorar o software, fica cada vez mais difícil acrescentar novas mudanças.

Modelo Orientado a reuso

O modelo orientado a reuso consiste em reutilizar designs e códigos já existentes e são similares aos necessários para o projeto. Também pode ser dividido em algumas fases:

  • Análise de componentes: é feita uma pesquisa para encontrar os componentes necessários para atender à especificação
  • Modificação dos requisitos: os requisitos são reanalisados para refletir os componentes encontrados. Se isso não for possível, procuram-se novos componentes
  • Design do sistema com reuso: o design do sistema é construído ou um framework é utilizado. O framework é organizado para se enquadrar com os componentes encontrados
  • Desenvolvimento e integração: as partes do software que não foram encontradas são desenvolvidas e integradas com os componentes para criar o novo sistema.

Nossas escolhas

Como é possível ver, não há um modelo ideal. Cada um tem suas vantagens e desvantagens. Tendo isso em mente, nosso grupo não trabalhou com nenhum destes modelos em específico, mas sim com uma mistura entre os três modelos.

Incremental

  • Como temos entregas frequentes do trabalho, é necessário que nós tivéssemos alguma coisa nova pronta a cada entrega. Logo, o sistema é desenvolvido cada parte, e em cada "sprint" é entregue o que o professor solicitou.
  • A análise teve de ser refeita diversas vezes ao longo do projeto, e isso acaba impactando na implementação. Logo, tivemos diversos pontos de re-análise, sincronizados com as entregas dos professores, o que se torna muito similar ao modelo incremental.

Reuso

  • Utilizamos diversas partes de código prontas (frameworks) no nosso trabalho, desde designs de telas mobile à comunicação com banco de dados.

Em cascata

  • Inicialmente, tivemos um grande bloco de análise antes de começar a implementação. Apesar de terem sido feitos diversos ajustes ao longo do trabalho, nenhum desde foi longo como o bloco inicial.
  • O sistema Web foi construído quase que completamente antes de ser integrado ao sistema mobile, levando cerca de três sprints antes de finalmente ser integrado.

Além disso, é preciso considerar que ao iniciar o projeto o grupo não tinha conhecimento algum sobre modelos de projeto. A forma de trabalhar foi se alterando ao longo do projeto e se adaptando aos novos conhecimentos adquiridos e às necessidades da equipe e solicitações dos clientes (professores e NAC).