Modelos de Processo de Software

Um modelo de processo para engenharia de software é escolhido com base na natureza do projeto e da aplicação, nos métodos e ferramentas a serem usados, e nos controles e nos produtos intermediários e finais que são requeridos.

Modelos de Processo de Software

Ennharia de Software 1

Caracterizado por um ciclo de solução

de problemas

4 estágios distintos:

Situação atual

Definição do problema

Desenvolvimento técnico e integração da solução


Situação Atual

Representa o estado atual das coisas

Definição do problema

Identifica o problema específico a ser resolvido


Desenvolvimento técnico

Resolve o problema por intermédio da aplicação de alguma tecnologia.

Integração da solução

• Aqueles que solicitaram a solução inicialmente (p. ex. documentos, programas, dados, nova função de negócios, novo produto)


Ciclo solução de problemas

Aplica-se ao trabalho de engenharia de software em muitos diferentes níveis de resolução. Pode ser usado em nível macro, quando toda aplicação é considerada.


Em nível intermediário, quando os componentes de programa estão passando por engenharia e mesmo no nível de linha de código.


Cada estágio do ciclo de solução do problema contém, um ciclo idêntico de solução de problema, que contêm um outro ciclo de solução do problema (isso continua até algum limite racional; para software, uma linha de código)


Realisticamente, é difícil...

Porque interferências ocorrem dentro e entre os estágios. Essa visão simplificada leva ainda a uma idéia muito importante: independentemente do modelo de processo que é escolhido um projeto, todos os estágios.


Situação atual, definição do problema, desenvolvimento técnico e integração da solução – coexistem simultaneamente em algum nível de detalhe.

Uma completa aplicação para a geração de um pequeno trecho de código.


Ciclo de Vida

Ciclo de vida Clássico (cascata)

Abordagem sistemática e seqüencial;

O mais antigo ciclo e o mais amplamente utilizado pela engenharia de software;


Ciclo de vida

Engenharia

de Sistemas

Análise de

Requisitos

Projeto do

Software

Codificação

Teste

Manutenção


Modelagem – Eng. de Sistemas

Trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema e depois pela alocação de algum subconjunto desses requisitos para o software


Precisa interagir com outros elementos tais como hardware, pessoas e bases de dados.

Incluem um conjunto de necessidade a nível de sistema com um pouco de projeto de alto nível.


Inclui um conjunto de necessidades a nível estratégico e a nível da área de negócios.


Análise de requisitos de software

É intensificado e focalizado especificamente no software.

O ES (“analista”) deve conhecer o domínio da informação do software, tanto quanto a função necessária, o comportamento, o desempenho e a interface.


Os requisitos do sistema e do software são documentado e revistos com o cliente.


Projeto

Um processo de múltiplos passos que enfoca quatro atributos distintos do programa: estrutura de dados, arquitetura do software, representações da interface e detalhes procedimentais (algoritmicos)


O processo de projeto traduz os requisitos para uma representação do software, que pode ser avaliada quanto à qualidade, antes que a codificação tenha início. À semelhança dos requisitos, o projeto é documentado e torna-se parte da configuração do software.


Geração de código

O projeto deve ser traduzido para linguagem de máquina. O passo de geração de código executa essa tarefa. Se o projeto é realizado de maneira detalhada, a geração de código pode ser realizada mecanicamente.


Testes

O processo de teste focaliza os aspectos lógicos internos do software, garantindo que todos os comandos sejam testados, e os aspectos externos funcionais;


isto é, conduz testes para descobrir erros e garantir que entradas produzirão resultados reais, que concordam com os resultados exigidos.


Manutenção

Uma modificação acomodar mudanças no seu ambiente externo (modificação necessária por causa de um novo sistema Operacional ou dispositivo periférico), ou quando o cliente deseja melhoramentos funcionais ou de desempenho


O suporte/manutenção do software reaplica cada uma das fases precedentes a um programa existente ao invés de um novo programa


Ciclo de Vida

Atualmente críticas estão sendo feitas sobre sua aplicabilidade:

Os projetos raramente seguem o fluxo seqüencial;

Raramente o cliente declara totalmente suas exigências;

Uma versão do sistema é entregue

no fim do cronograma, o que deixa o cliente sem paciência


Prototipação

Adequado em casos de incertezas do cliente;

Recomendado quando há dúvidas da eficiência da versão final;

A prototipação pode assumir:

Modelo em papel ou baseado em PC com algumas interfaces que retratariam a versão final;

Implementação de um subconjunto da versão final

Uma versão que executa parte ou toda função desejada, mas que será melhorado em nova versão.


Prototipação


Começa com a definição de requisitos. O desenvolvedor e o cliente encontra-se e definem os objetivos gerais do software, identificam as necessidades conhecidas e delineiam áreas que necessitam de mais definições.


Um projeto rápido é então realizado. Esse projeto concentra-se na representação daqueles aspectos do software que vão ficar visíveis ao cliente/usuário (ex. abordagem de entrada e formato de saída).


O projeto rápido parte de um protótipo. O protótipo é avaliado pelo cliente/usuário e usado para refinar os requisitos do software que será desenvolvido.


Interações ocorrem à medida que o protótipo é ajustado para satisfazer às necessidades do cliente, enquanto, ao mesmo tempo, permitem ao desenvolvedor entender melhor o que precisa ser feito.


Idealmente, o protótipo serve como um mecanismo para a identificação dos requisitos do software. Se um protótipo executável é elaborado, o desenvolvedor tenta usar partes do programas existentes ou aplica ferramentas (ex. geradores de relatórios) que possibilitam que programas executáveis sejam gerados rapidamente.


Mas o que fazer com o protótipo quando

tiver cumprido a finalidade descrita

Na maioria dos projetos, o primeiro sistema construído consegue ser apenas utilizável. Pode ser muito lento, grande, complicado de usar ou tudo isso ao mesmo tempo.


Na há alternativa senão começar de novo e construir uma versão reprojetada, na qual esses problemas são resolvidos... Quando um novo conceito de sistema ou uma nova tecnologia é usada deve-se construir um sistema para ser descartado, porque nem mesmo o melhor planejamento é tão onisciente para fazer certo na primeira vez.


A questão de gerência, entretanto, não é se o sistema piloto elaborado deve ser descartado. Ele será. A única questão é planejar antecipadamente a construção de um descartável, ou prometer entregá-lo aos clientes...


O protótipo pode servir como o “primeiro sistema”. Aquele que Brooks recomenda que se descarte. Mas essa pode ser uma visão idealizada. É verdade que tanto clientes quanto desenvolvedores gostam de paradigma de prototipagem.


Os usuários tem o sabor de um sistema real e os desenvolvedores conseguem construir algo imediatamente.


Apesar dos problemas poderem ocorrer, a prototipagem pode ser utilizado. O importante é definir as regras do jogo no início, isto é, o cliente e desenvolvedor devem estar de acordo que o protótipo seja construído para servir como um mecanismo para definição dos requisitos. Depois é descartado (ou pelo menos em parte).


Prototipação

– possíveis problemas

O cliente vê aquilo que “parece” ser uma versão definitiva do trabalho do software.

O desenvolvedor muitas vezes faz concessões de implementação a fim de colocar um protótipo em funcionamento rapidamente.


Espiral

Atividades em espiral que é composta por ciclos (Planejamento, Análise de Riscos, Engenharia e Avaliação pelo Cliente);

A cada ciclo, novas versões são apresentadas ao cliente;

Caso a análise dos riscos indicar que há incertezas nos requisitos, a prototipação pode ser adotada no quadrante da engenharia para ajudar a desenvolvedor e cliente.


Espiral


É um modelo de processo de software evolucionário que combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos de modelo sequencial linear


Fornece potencial para o desenvolvimento rápido de versões incrementais do software. Usando o modelo Espiral, o software é desenvolvido numa séie de versões incrementais.


A versão incremental, durante as primeiras iterações, pode ser um modelo de papel ou protótipo. Durante as últimas iterações, são produzidas versões cada vez mais completas do sistema submetido à engenharia.


Regiões de tarefas

Comunicação com o cliente – tarefas necessárias para estabelecer efetiva comunicação entre o desenvolvedor e o cliente


Planejamento – tarefa necessárias para definir recursos, prazos e outras informações relacionadas ao projeto.

Análise de Risco – tarefas necessárias para avaliar os riscos, tanto técnico quanto gerenciais. Ennharia de Software 45

Engenharia – tarefa necessária para construir uma ou mais representações da aplicação.

Construção e liberação – para construir, testar, instalar e fornecer apoio ao usuário (Ex. documentação e treinamento)


Avaliação pelo cliente – tarefa necessária para obter realimentação do cliente, com base na avaliação das representações do software criadas durante o estágio de engenharia e implementadas durante o estágio de instalação.


Cada uma das regiões é preenchida por um conjunto de tarefas de trabalho, que são adaptadas às características do projeto a ser desenvolvidos.


Para projetos pequenos, a quantidade de tarefas de trabalho e suas formalidades é pequena. Para projetos maiores, mais críticos, cada região de tarefas contém mais tarefas de trabalho, que são definidas para alcançar um alto nível de formalidade.


A medida que esse processo evolucionário tem início, a equipe de engenharia de software move-se em volta da espiral, no sentido horário, a partir do centro. O primeiro circuito em torno da espiral pode resultar no desenvolvimento da especificação do produto;


Passagens subsequentes em torno da espiral podem ser usadas para desenvolver um protótipo e depois, progressivamente, versões mais sofisticadas do software. Cada passagem pela região de planejamento resulta em ajustes ao plano do projeto.


O custo e o cronograma sã ajustados com base na realimentação derivada da avaliação do cliente. Além disso, o gerente do projeto ajusta a quantidade de iterações necessárias planejadas para completar o software.


Um “projeto de desenvolvimento conceitual” começa no centro da espiral e continua (ocorrem múltiplas iterações ao longo do caminho em espiral que limita a região central escura) até que o desenvolvimento conceitual se complete.


Se o conceito deve ser desenvolvido até virar um produto real, o processo prossegue através do próximo cubo (ponto de entrada para um projeto de desenvolvimento de novo produto) e um “novo projeto de desenvolvimento” é iniciado.


O novo produto vai evoluir através de um certo número de iterações, em torno da espiral, seguindo o caminho que limita a região, que tem uma tonalidade um pouco mais clara do que o núcleo.


Em resumo, o espiral, quando caracterizada desse modo, permanece operacional até que o software seja retirado de serviço. Há momentos em que eu o processo fica adormecido, mas sempre que uma modificação é iniciada, o processo começa no ponto de entrada adequado (ex.: melhoria)


O modelo é utilizado para desenvolvimento de sistemas de grande porte. Como o software evolui a medida que o processo avança o desenvolvedor e o cliente entendem melhor e reagem aos riscos em cada nível evolucionário.


O modelo espiral usa prototipagem como mecanismo de redução de risco, porém, o mais importante, é que permite ao desenvolvedor aplicar a abordagem de prototipagem em qualquer estágio de evolução do produto.


Espiral

possíveis problemas

Pode ser difícil convencer os clientes de que a abordagem evolutiva é controlável;

Exige considerável experiência na avaliação dos riscos;

É um modelo relativamente novo, portanto a atenção e cuidados devem ser maiores.


Modelo Espiral Ganha-Ganha

O objetivo dessa atividade é formular os requisitos de projeto do cliente. Em contexto ideal, o desenvolvedor simplesmente pergunta ao cliente o que é necessário e o cliente fornece os detalhes suficiente para prosseguir.


Infelizmente, isso raramente acontece. Na realidade, o cliente e o desenvolvedor iniciam uma negociação, em que o cliente pode ser levado a ponderar a funcionalidade, o desempenho e outras características do produto, ou do sistema, em relação ao custo e ao prazo para chegar ao mercado.


As melhores negociações buscam um resultado “ganha-ganha”. Isto é, o cliente ganha obtendo um produto ou sistema que satisfaz à maior parte das necessidades do cliente, e o desenvolvedor ganha trabalhando com orçamento e prazos de entrega realísticos e possíveis de serem cumpridos.


O modelo espiral ganha-ganha de Boehm [BO98] define um conjunto de atividades de negociação no começo de cada passagem, em torno da espiral. Ao invés de uma única atividade de comunicação com o cliente, as seguintes atividades são definidas:


Identificação dos principais “interessados” do sistema ou do subsistema.

Determinação das condições de lucro do interessado.

Negociação das condições de ganho do interessado para reconciliá-las no âmbito das condições ganha-ganha para todos os envolvidos.


A conclusão bem-sucedida desses passos iniciais leva a um resultado ganha-ganha que vem a ser o principal critério para prosseguir em direção à definição do software e do sistema.


Além da ênfase na negociação inicial, o modelo espiral ganha-ganha introduz três marcos de processo, chamados pontos de ancoragem que ajudam a estabelecer quando um ciclo é completado em torno da espiral e fornecem marcos de decisão antes do projeto de software prosseguir.


Os pontos de ancoragem representam três diferentes visões de progresso a medida que o projeto percorre a espiral. O primeiro ponto...


Primeiro ponto de ancoragem

Objetivos de ciclo de vida – define um conjunto de objetivos para cada atividade principal de engenharia de software. (ex. alto nível dos requisitos do sistema/produto)


Segundo ponto de ancoragem

Arquitetura do ciclo de vida – estabelece objetivos que precisam ser satisfeitos, à medida que a arquitetura do sistema, e do software, é definida. (ex. avaliação de componentes reusável)


Terceiro ponto de ancoragem

Capacidade operacional – um conjunto de objetivos associado com a preparação do software para instalação/distribuição, preparação do local antes da instalação e assistência requerida por todas as partes que irão usar ao dar suporte.


Visão Geral da ES

Ao observarmos os modelos apresentados de ciclo de vida de um software, deparamos com fases em comum em todos eles;

Basicamente a Engenharia de Software dispões de 3 grandes fases:

Definição;

Desenvolvimento;

Manutenção.


Fase de Definição:

Análise ou Definição do Sistema;

Permite determinar o papel de cada elemento (software, hardware, equipamentos, pessoas)

Planejamento do Projeto de Software;

Análise de riscos, definição de recursos, custos e cronograma.

Análise de Requisitos

Determina o conjunto de funções a serem realizadas e principais estruturas de informação a serem processadas.


Fase de Desenvolvimento:

Projeto de Software

Definição de estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface.

Codificação:

É o mapa ou definição em forma de código em uma ou mais linguagens de programação baseado nas definições de Projeto de Software

Teste de Software:

Submissão a um conjunto de testes para validar sua funcionalidade e corrigir possíveis erros.


Fase de Manutenção:

Correção

Atividade de correção dos erros observados durante a operação do sistema

Adaptação

Alterações no software para que ele possa ser executado por exemplo em plataforma diferente

Melhoramento funcional ou Perfectivo

Alterações que permitam melhorar aspectos do software como desempenho, interface, robustez. Ennharia de Software 74

Documents

Modelos de Processo de Software