Referência: Sommerville, Engenharia de Software, 10 ed., Capítulo 2

O quadro geral

Um processo de software é um conjunto estruturado de atividades necessárias para desenvolver um sistema de software. Note que estamos falando de um “processo de software” — e não de um “processo de desenvolvimento de software”.”

Existem muitos tipos diferentes de processos de software, mas cada um deles envolve estes quatro tipos de actividades fundamentais:

• Especificação de software – definindo o que o sistema deve fazer;
• Desenho e implementação de software – definindo a organização do sistema e implementando o sistema;
• Validação de software – verificando se faz o que o cliente quer;
• Evolução de software – alterando o sistema em resposta às necessidades do cliente.

Um modelo de processo de software é uma representação abstrata de um processo. Ele apresenta uma descrição de um processo a partir de alguma perspectiva particular. Quando descrevemos e discutimos processos de software, normalmente falamos sobre as atividades desses processos, como a especificação de um modelo de dados, o desenho de uma interface de usuário, etc. e a ordenação dessas atividades.As descrições de processos também podem incluir:

• Produtos, que são os resultados de uma atividade de processo;
• Papéis, que refletem as responsabilidades das pessoas envolvidas no processo;
• Pré e pós-condições, que são afirmações que são verdadeiras antes e depois de uma atividade de processo ter sido decretada ou de um produto ter sido produzido.

Processos orientados pelo plano são processos onde todas as atividades do processo são planejadas com antecedência e o progresso é medido em relação a este plano. Em processos ágeis, o planejamento é incremental e é mais fácil mudar o processo para refletir as mudanças nas necessidades do cliente. Na prática, a maioria dos processos práticos inclui elementos de ambas as abordagens, orientada por planos e ágil.

Modelos de processo de software

O modelo de cascata Modelo orientado por planos. Fases separadas e distintas de especificação, projeto de software, implementação, teste e manutenção. Especificação de desenvolvimento incremental, desenvolvimento e validação são intercalados. O sistema é desenvolvido como uma série de versões (incrementos), com cada versão adicionando funcionalidade à versão anterior. Pode ser orientado por planos ou ágil. Integração e configuração Baseada na existência de um número significativo de componentes/sistemas reutilizáveis. O processo de desenvolvimento do sistema centra-se na integração destes componentes num sistema em vez de os desenvolver a partir do zero. Pode ser orientado por um plano ou ágil.

Na prática, a maioria dos grandes sistemas são desenvolvidos utilizando um processo que incorpora elementos de todos estes modelos.

O modelo de cascata

Existem fases identificadas separadamente no modelo de cascata:

Análise e definição de requisitos Os serviços, restrições e objetivos do sistema são estabelecidos através de consulta aos usuários do sistema. Eles são então definidos em detalhes e servem como uma especificação do sistema. Projeto do sistema e do software O processo de projeto do sistema aloca os requisitos aos sistemas de hardware ou software, estabelecendo uma arquitetura geral do sistema. O design de software envolve a identificação e descrição das abstrações fundamentais do sistema de software e suas relações. Implementação e teste de unidades Durante esta etapa, o projeto de software é realizado como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atende a sua especificação. Integração e teste de sistema As unidades ou programas de programa individuais são integrados e testados como um sistema completo para garantir que os requisitos de software foram cumpridos. Após o teste, o sistema de software é entregue ao cliente. Operação e manutenção Normalmente (embora não necessariamente), esta é a fase do ciclo de vida mais longo. O sistema é instalado e colocado em uso na prática. A manutenção envolve a correção de erros que não foram descobertos em fases iniciais do ciclo de vida, melhorando a implementação das unidades do sistema e melhorando os serviços do sistema à medida que novos requisitos são descobertos.

O principal inconveniente do modelo de cascata é a dificuldade de acomodar a mudança após o processo estar em andamento. Em princípio, uma fase tem que estar completa antes de passar para a fase seguinte. Os problemas do modelo de cascata incluem:

Dificuldade de lidar com a mudança A divisão inflexível do projecto em fases distintas dificulta a resposta às mudanças de requisitos do cliente, pelo que este modelo só é apropriado quando os requisitos são bem compreendidos e as mudanças serão bastante limitadas durante o processo de concepção. Poucos sistemas empresariais têm requisitos estáveis. Muito poucas aplicações no mundo real O modelo de cascata é usado principalmente para grandes projetos de engenharia de sistemas, onde um sistema é desenvolvido em vários locais, nestas circunstâncias, a natureza planejada do modelo de cascata ajuda a coordenar o trabalho.

>

Benefícios do desenvolvimento incremental:

Menor custo das mudanças O custo de acomodar as mudanças de requisitos do cliente é reduzido. A quantidade de análise e documentação que tem de ser refeita é muito menor do que o necessário com o modelo de cascata. Feedback frequente É mais fácil obter o feedback do cliente sobre o trabalho de desenvolvimento que foi feito. Os clientes podem comentar sobre as demonstrações do software e ver quanto foi implementado. Entrega mais rápida É possível uma entrega e implementação mais rápida de software útil para o cliente. Os clientes podem usar e ganhar valor com o software mais cedo do que é possível com um processo de queda de água.

Problemas com desenvolvimento incremental (da perspectiva da gestão):

O processo não é visível Os gestores precisam de entregas regulares para medir o progresso. Se os sistemas são desenvolvidos rapidamente, não é rentável produzir documentos que reflictam todas as versões do sistema. A estrutura do sistema tende a degradar-se à medida que novos incrementos são adicionados A menos que tempo e dinheiro sejam gastos na refatoração para melhorar o software, mudanças regulares tendem a corromper sua estrutura. A incorporação de mais mudanças no software torna-se cada vez mais difícil e dispendiosa.

>>

Esta abordagem é baseada na reutilização sistemática onde os sistemas são integrados a partir de componentes existentes ou sistemas COTS (Commercial-off-the-shelf). As fases do processo incluem:

• Análise de componentes;
• Modificação de requisitos;
• Desenho do sistema com reutilização;
• Desenvolvimento e integração.

Reutilização é agora a abordagem padrão para a construção de muitos tipos de sistemas empresariais;

Tipos de componentes de software:

• Serviços Web que são desenvolvidos de acordo com padrões de serviço e que estão disponíveis para invocação remota.
• Colecções de objectos que são desenvolvidos como um pacote a ser integrado com uma estrutura de componentes como .NET ou J2EE.

>

• Sistemas autónomos comerciais de prateleira (COTS) que são configurados para utilização num determinado ambiente.

Processos reais de software são sequências intercaladas de atividades técnicas, colaborativas e gerenciais com o objetivo geral de especificar, projetar, implementar e testar um sistema de software.

As quatro atividades básicas do processo de especificação, desenvolvimento, validação e evolução são organizadas de forma diferente nos diferentes processos de desenvolvimento. No modelo cascata, elas são organizadas em sequência, enquanto que no desenvolvimento incremental elas são intercaladas.

Especificação de software O processo de estabelecer quais serviços são necessários e as restrições para o funcionamento e desenvolvimento do sistema. O processo de engenharia de requisitos:

• Estudo de viabilidade: é técnica e financeiramente viável construir o sistema?
• Elicitação e análise dos requisitos: o que as partes interessadas no sistema requerem ou esperam do sistema?
• Especificação dos requisitos: definindo os requisitos em detalhe
• Validação dos requisitos: verificando a validade dos requisitos

Concepção e implementação do software O processo de conversão da especificação do sistema num sistema executável.

• Concepção do software: conceber uma estrutura de software que realize a especificação;
• Implementação: traduzir esta estrutura num programa executável;

As actividades de concepção e implementação estão intimamente relacionadas e podem ser intercaladas. As atividades de projeto incluem:

• Projeto arquitetônico: identificar a estrutura geral do sistema, os principais componentes (às vezes chamados de sub-sistemas ou módulos), suas relações e como eles são distribuídos.
• Projeto de interface: definir as interfaces entre os componentes do sistema.
• Desenho de componentes: pegue cada componente do sistema e desenhe como ele irá operar.
• Desenho da base de dados: desenhe as estruturas de dados do sistema e como estas devem ser representadas numa base de dados.

Validação de software A verificação e validação (V & V) destina-se a mostrar que um sistema está em conformidade com as suas especificações e cumpre os requisitos do cliente do sistema.

• Validação: estamos a construir o produto certo (o que o cliente quer)?
• Verificação: estamos a construir o produto certo?

V & V envolve a verificação e revisão dos processos e testes do sistema. O teste do sistema envolve a execução do sistema com casos de teste que são derivados da especificação dos dados reais a serem processados pelo sistema. O teste é a atividade V & V mais comumente usada e inclui as seguintes etapas:

• Desenvolvimento ou teste de componentes: componentes individuais são testados independentemente; componentes podem ser funções ou objetos ou agrupamentos coerentes dessas entidades.
• Teste do sistema: teste do sistema como um todo, teste de propriedades emergentes é particularmente importante.
• Teste de aceitação: teste com dados do cliente para verificar se o sistema atende às necessidades do cliente.

Evolução do software O software é inerentemente flexível e pode mudar. Como os requisitos mudam através da mudança das circunstâncias do negócio, o software que suporta o negócio também deve evoluir e mudar. Embora tenha havido uma demarcação entre desenvolvimento e evolução (manutenção), isto é cada vez mais irrelevante uma vez que cada vez menos sistemas são completamente novos.

A mudança é inevitável em todos os grandes projetos de software. As mudanças no negócio levam a novos e alterados requisitos de sistemaNovas tecnologias abrem novas possibilidades para melhorar as implementações.O processo de software inclui atividades que podem antecipar possíveis mudanças antes que um retrabalho significativo seja necessário. Por exemplo, um sistema protótipo pode ser desenvolvido para mostrar algumas características chave do sistema aos clientes. Tolerância a mudanças O processo é projetado para que as mudanças possam ser acomodadas a um custo relativamente baixo, o que normalmente envolve alguma forma de desenvolvimento incremental. As alterações propostas podem ser implementadas em incrementos que ainda não tenham sido desenvolvidos. Se isso for impossível, então apenas um único incremento (uma pequena parte do sistema) pode ter sido alterado para incorporar a mudança.

Protótipo é uma versão inicial de um sistema usado para demonstrar conceitos e experimentar opções de design. Um protótipo pode ser usado em:

• O processo de engenharia de requisitos para ajudar na elicitação de requisitos e validação;
• No processo de design para explorar opções e desenvolver um design de IU;
• No processo de teste para executar testes back-to-back.

Benefícios da prototipagem:

• Improvada usabilidade do sistema.
• Uma correspondência mais próxima com as necessidades reais dos utilizadores.
• Improvada qualidade do design.
• Improvada capacidade de manutenção.
• Reduzido esforço de desenvolvimento.

Protótipos podem ser baseados em linguagens ou ferramentas de prototipagem rápida. Eles podem envolver omitir funcionalidade:

• Protótipo deve focar em áreas do produto que não são bem compreendidas;
• A verificação e recuperação de erros pode não ser incluída no protótipo;
• Focalização em requisitos funcionais e não funcionais, como confiabilidade e segurança.

Protótipos devem ser descartados após o desenvolvimento pois não são uma boa base para um sistema de produção:

• Pode ser impossível afinar o sistema para satisfazer requisitos não funcionais;
• Protótipos são normalmente indocumentados;
• A estrutura do protótipo é normalmente degradada através de mudanças rápidas;
• O protótipo provavelmente não irá satisfazer os padrões normais de qualidade organizacional.

Realizar do que entregar o sistema como uma única entrega, o desenvolvimento e entrega é dividido em incrementos com cada incremento entregando parte da funcionalidade requerida.Uma vez iniciado o desenvolvimento de um incremento, os requisitos são congelados, embora os requisitos para os incrementos posteriores possam continuar a evoluir.

Vantagens da entrega incremental:

• Valor do cliente pode ser entregue com cada incremento para que a funcionalidade do sistema esteja disponível mais cedo.

>

• Os incrementos iniciais actuam como um protótipo para ajudar a obter requisitos para incrementos posteriores.

>

• Baixo risco de falha geral do projecto.

>

• Os serviços de sistema de maior prioridade tendem a receber o maior número de testes.

Problemas de entrega incremental:

• A maioria dos sistemas requer um conjunto de instalações básicas que são utilizadas por diferentes partes do sistema. Como os requisitos não são definidos em detalhes até que um incremento seja implementado, pode ser difícil identificar instalações comuns que são necessárias por todos os incrementos.
• A essência dos processos iterativos é que a especificação é desenvolvida em conjunto com o software. No entanto, isto entra em conflito com o modelo de compras de muitas organizações, onde a especificação completa do sistema é parte do contrato de desenvolvimento do sistema.

Muitas empresas de software se voltaram para a melhoria do processo de software como forma de melhorar a qualidade do seu software, reduzindo custos ou acelerando os seus processos de desenvolvimento. A melhoria de processos significa compreender os processos existentes e mudar esses processos para aumentar a qualidade do produto e/ou reduzir os custos e o tempo de desenvolvimento.

Abordagem de maturidade de processos Foca na melhoria da gestão de processos e projetos e na introdução de boas práticas de engenharia de software. O nível de maturidade dos processos reflete até que ponto as boas práticas técnicas e de gestão foram adotadas nos processos de desenvolvimento de software organizacional. Abordagem ágil Foca no desenvolvimento iterativo e na redução das despesas gerais no processo de desenvolvimento de software. As principais características dos métodos ágeis são a rápida entrega de funcionalidades e a capacidade de resposta às mudanças nos requisitos dos clientes.

Atividades de melhoria de processos formam um ciclo contínuo com um loop de feedback:

• Medir um ou mais atributos do processo ou produto de software. Estas medições formam uma linha de base que ajuda a decidir se as melhorias do processo foram eficazes.
• Analisar o processo atual e identificar quaisquer gargalos.
• Alterar o processo para resolver alguns dos pontos fracos do processo identificados. Estes são introduzidos e o ciclo retoma para recolher dados sobre a eficácia das mudanças.

Medição do processo

• Quando possível, devem ser recolhidos dados quantitativos do processo.
• Medições do processo devem ser usadas para avaliar as melhorias do processo.
• Métricas podem incluir:
  • Tempo de conclusão das actividades do processo, e.por exemplo, tempo ou esforço de calendário para completar uma atividade ou processo.
  • Recursos necessários para processos ou atividades, por exemplo, esforço total em dias-pessoa.
  • Número de ocorrências de um determinado evento, por exemplo, número de defeitos descobertos.

Modelo de maturidade da capacidade SEI

• Inicial: Essencialmente descontrolado
• Repetível: Procedimentos de gestão do produto definidos e utilizados
• Definidos: Procedimentos e estratégias de gestão de processos definidos e utilizados
• Gerenciados: Estratégias de gestão da qualidade definidas e utilizadas
• Optimização: Estratégias de melhoria de processos definidas e utilizadas

>