Issuu on Google+

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


Modelos de Processo de Software