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. 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
Ennharia de Software
2
Situação Atual Representa o estado atual das coisas Definição do problema Identifica o problema específico a ser resolvido
Ennharia de Software
3
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)
Ennharia de Software
4
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.
Ennharia de Software
5
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.
Ennharia de Software
6
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) Ennharia de Software
7
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. Ennharia de Software
8
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. Ennharia de Software
9
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; Ennharia de Software
10
Ciclo de vida Engenharia de Sistemas Análise de Requisitos Projeto do Software
Codificação
Teste
Manutenção
Ennharia de Software
11
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 Ennharia de Software
12
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. Ennharia de Software
13
Inclui
um conjunto de necessidades a nível estratégico e a nível da área de negócios.
Ennharia de Software
14
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. Ennharia de Software
15
ď‚Ą Os
requisitos do sistema e do software sĂŁo documentado e revistos com o cliente.
Ennharia de Software
16
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) Ennharia de Software
17
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. Ennharia de Software
18
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. Ennharia de Software
19
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;
Ennharia de Software
20
isto
é, conduz testes para descobrir erros e garantir que entradas produzirão resultados reais, que concordam com os resultados exigidos.
Ennharia de Software
21
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 Ennharia de Software
22
O
suporte/manutenção do software reaplica cada uma das fases precedentes a um programa existente ao invés de um novo programa
Ennharia de Software
23
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 Ennharia de Software 24
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. Ennharia de Software 25
Prototipação
Ennharia de Software
26
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.
Ennharia de Software
27
Um
projeto rápido é então realizado. Esse projeto concentrase 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).
Ennharia de Software
28
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.
Ennharia de Software
29
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. Ennharia de Software
30
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. Ennharia de Software
31
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. Ennharia de Software
32
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. Ennharia de Software
33
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... Ennharia de Software
34
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. Ennharia de Software
35
ď‚Ą Os
usuĂĄrios tem o sabor de um sistema real e os desenvolvedores conseguem construir algo imediatamente.
Ennharia de Software
36
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). Ennharia de Software
37
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. Ennharia de Software
38
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. Ennharia de Software
39
Espiral
Ennharia de Software
40
É
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
Ennharia de Software
41
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.
Ennharia de Software
42
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. Ennharia de Software
43
Regiões de tarefas Comunicação
com o cliente – tarefas necessárias para estabelecer efetiva comunicação entre o desenvolvedor e o cliente
Ennharia de Software
44
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 Ennharia de Software 45 gerenciais.
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) Ennharia de Software
46
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. Ennharia de Software
47
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.
Ennharia de Software
48
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. Ennharia de Software
49
A
medida que esse processo evolucionário tem início, a equipe de engenharia de software movese 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; Ennharia de Software 50
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. Ennharia de Software 51
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. Ennharia de Software
52
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. Ennharia de Software
53
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. Ennharia de Software
54
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. Ennharia de Software
55
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) Ennharia de Software
56
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. Ennharia de Software
57
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. Ennharia de Software
58
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. Ennharia de Software
59
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. Ennharia de Software
60
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. Ennharia de Software
61
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. Ennharia de Software 62
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: Ennharia de Software 63
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. Ennharia de Software
64
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.
Ennharia de Software
65
Além
da ênfase na negociação inicial, o modelo espiral ganhaganha 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. Ennharia de Software
66
ď‚Ą Os
pontos de ancoragem representam trĂŞs diferentes visĂľes de progresso a medida que o projeto percorre a espiral. O primeiro ponto...
Ennharia de Software
67
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) Ennharia de Software
68
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) Ennharia de Software
69
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. Ennharia de Software
70
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. Ennharia de Software
71
Fase de Definição:
Análise ou Definição do Sistema;
Planejamento do Projeto de Software;
Permite determinar o papel de cada elemento (software, hardware, equipamentos, pessoas) 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.
Ennharia de Software
72
Fase de Desenvolvimento:
Projeto de Software
Codificação:
Definição de estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface.
É 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. Ennharia de Software
73
Fase de Manutenção:
Correção
Adaptação
Atividade de correção dos erros observados durante a operação do sistema
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