Atividades para especificar, projetar, implementar e ...maria/arqan/2013-2/cap2-proc.pdf · PRESSMAN, ROGER - Engenharia de Software - 6° Edição SOMMERVILLE - Engenharia de Software

Profa. Maria Auxiliadora

Fonte: PRESSMAN, ROGER - Engenharia de Software - 6° Edição SOMMERVILLE - Engenharia de Software - 8° Edição

1

PROCESSOS DE SOFTWARE

Atividades para especificar, projetar, implementar e testar

sistemas de software



Uma Visão Genérica: 3 Fases

Definição - “o que”

• Engenharia do Sistema

• Planejamento do Projeto

• Análise de Requisitos

Desenvolvimento - “como”

• Projeto

• Geração do Código

• Teste

Manutenção

Processos de software

2



• Um processo de software é um método para desenvolver ou produzir software.

• Define quem faz o que, quando e como.


3



O processo é o instrumento capaz de responder a qualquer momento:

• O que é feito? Produto • Como é feito? Passos • Por quem é feito? Agente • O que usa? Insumos • O que Produz? Resultados


4



Modelo de Processo de Software

definição do

problema

desenvolvimento técnico

integração da

solução

estado atual

Processo deve incorporar uma estratégia de desenvolvimento

5



Modelagem

• Modelagem é uma técnica de engenharia aprovada e bem aceita

– modelos de arquitetura de casas e de grandes prédios

– modelos matemáticos a fim de analisar os efeitos de ventos e tremores de terra --> causas

6



Modelagem na Engenharia Civil

Modelos

7



Modelo X Processo

• Um modelo é algo teórico, um conjunto de possíveis ações.

• O processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos e métricas para se avaliar como elas estão sendo realizadas

8



Modelo + Planejamento =

Processo

Modelo X Processo

9



Modelos de processo de software

• Um conjunto de atividades fundamentais exigida para desenvolver um sistema de software

–Especificação.

–Projeto e implementação.

–Validação.

–Evolução.

10




–Especificação - definição do quê o sistema deve

fazer;

–Projeto e implementação - definição da

organização do sistema e implementação do sistema;

–Validação - checagem de que o sistema faz o que

o cliente deseja;

–Evolução - evolução em resposta as mudanças

nas necessidades do cliente.

11



Estudo de viabilidade

Relatório de viabilidade

Levantamento e análise de

requisitos Especificação de requisitos

Validação de requisitos

Modelos de sistemas

Requisitos do usuário e do sistema

Documentação de requisitos

Processo de software

12



• Processo de Engenharia de Requisitos

– Estudo de viabilidade • Econômica – relação custo/benefício; • Técnica – tecnologia e capacitação; • Jurídica – aspectos legais.

– Levantamento e análise de requisitos

• Entrevista, observação, reuniões


13



– Especificação de requisitos • Documento contendo os requisitos

do usuário e do sistema – funcionais e não-funcionais

– Validação de requisitos

• Avaliação do documento de requisitos –consistência e integralidade.


14



• Exemplos de modelos de processo:

–Workflow - sucessão de atividades

–Fluxo de Dados - fluxo de informação

–Papel/ação – representa os papéis das pessoas e as atividades pelas quais elas são responsáveis.


15



Uma estratégia de desenvolvimento que englobe

processos, métodos e ferramentas, e as fases de

desenvolvimento...

Modelos de processo de software – (paradigmas)

16



• Modelo Sequencial Linear (ciclo de vida clássico)

• Modelos Evolucionários - Prototipação - Incremental - Espiral

- Métodos Ágeis

• Modelo de Métodos Formais • Técnicas de 4a Geração • Orientado a reúso

Modelos de processo de software – (paradigmas)

17



Engenharia de Sistemas

Análise / projeto de sistema e de software

Implementação e teste

Integração e teste

Operação e manutenção

Modelo Sequencial Linear (ciclo de vida clássico)

18



• ENGENHARIA DE SISTEMAS • envolve a coleta de requisitos em nível do sistema, pequena quantidade de projeto e análise de alto nível • definir quais os requisitos do produto de software, sem especificar como esses requisitos serão obtidos.


19



• ENGENHARIA DE SISTEMAS • deve-se analisar os requisitos, recursos e restrições para:

• apresentar soluções; • estudar a viabilidade; • planejar e gerenciar o desenvolvimento a partir de estimativas e análise de riscos que se utilizam de métricas.


20



• Estudo de viabilidade

• Analisar o problema em nível global

• Identificar soluções alternativas (custos / benefícios)

• Simulação do futuro processo de desenvolvimento.


21



• Estudo de viabilidade (cont)

Resultado documentação contendo:

• Definição do problema

• Soluções alternativas, com os benefícios esperados

• Fontes necessárias, custos e datas de entrega para cada solução proposta.


22



• ANÁLISE DE REQUISITOS DE SOFTWARE

• processo de coleta dos requisitos é intensificado e concentrado especificamente no software. • deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos.


23



• ANÁLISE DE REQUISITOS DE SOFTWARE

• os requisitos (para o sistema e para o software) são documentados e revistos com o cliente.

Resultado o contrato de desenvolvimento


24



• PROJETO

• Definição de “como” o produto deve ser implementado.

• Dividido em:

• Projeto de alto nível – decomposição lógica

• Projeto detalhado – decomposição física.


25



• PROJETO • Concentra-se em:

• Estrutura de Dados; • Arquitetura de Software; • Detalhes Procedimentais e • Caracterização de Interfaces.

Resultado documentação de especificação de projeto


26



• IMPLEMENTAÇÃO • Tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador.

Resultado coleção de programas implementados e testados.


27



• INTEGRAÇÃO

• Programas ou unidades de programas são integrados e testados como sistema. Programas ou unidades são integradas à medida em que forem sendo desenvolvidos.

Resultado produto pronto para ser entregue ao cliente.


28



• OPERAÇÃO

• Instalação e configuração • Utilização – inicialmente operado por um grupo de usuário


29



• MANUTENÇÃO

• Corretiva: correção de erros remanescentes • Adaptativa: adaptação dos produtos às mudanças novas versões e novas situações de operação – hardware, sistemas operacionais. • Evolutiva: alteração dos requisitos e manutenção da qualidade.

Resultado produto em funcionamento.


30



ETAPA PERGUNTAS-CHAVES CRITÉRIOS DE SAÍDA

Definição do

problema

Qual é o problema

Estudo de

viabilidade

Há uma solução viável

Análise O que terá de ser feito

para resolver o problema?

Declaração da delimitação e objetivos.

Análise geral de custo/benefício

Alcance e objetivos do sistema.

Modelo lógico do sistema:

Diagrama de Fluxo de Dados;

Diagrama de Entidade e Relacionamento Diagrama de Transição de Estado;

Dicionário de Dados;

Especificação de Processos.

UML.


31



ETAPA PERGUNTAS-CHAVES CRITÉRIOS DE SAÍDA Projeto Como o problema deve ser

resolvido? Como o sistema deve ser implementado?

Soluções Alternativas Especificação de hard/soft;

Plano de implementação; Plano de teste preliminares; Procedimento de segurança; Procedimento de auditoria.

Implementação Faça Programas; Plano de testes; Procedimento de segurança; Procedimento de auditoria.

Teste Verificar o sistema Testes do geral do sistema.

Manutenção Modificar o sistema conforme necessidade.

Apoio continuado.


32



CONTRIBUIÇÕES DO CICLO DE VIDA CLÁSSICO

• Processo de desenvolvimento de software deve ser sujeito à disciplina, planejamento e gerenciamento.

• A implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos.

• Deve ser utilizado quando os requisitos estão bem claros no inicio do desenvolvimento.

33



•Rigidez

•Qualquer desvio é desencorajado

• Todo o planejamento é orientado para a entrega do produto de software em uma data única.

PROBLEMAS DO CICLO DE VIDA CLÁSSICO

34



• Abordagem baseada na idéia de desenvolver uma implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões.

• Especificação e desenvolvimento são intercalados

Modelo Evolucionário

35



Atividades concorrentes

Validação

Desenvolvimento

Especificação Versão inicial

Descrição do esboço

Versão intermediárias

Versão final

Modelo evolucionário (Desenvolvimento exploratório )

36



• Trabalhar junto com o cliente, a fim de explorar seus requisitos e entregar um sistema final.

• O desenvolvimento se inicia com as partes do sistema que são mais bem compreendidas.


37



• O sistema evolui com o acréscimo de novas características à medida que elas são propostas pelo cliente.

• Importante quando é difícil, ou mesmo impossível, estabelecer uma especificação detalhada dos requisitos do sistema a priori.


38



PROTOTIPAÇÃO

Coleta e

refinamento dos

requisitos

Refinamento do

protótipo

Engenharia do

produto Projeto

rápido

Construção do

protótipo

Avaliação do

protótipo pelo

cliente

Fim

Início

39



Coleta e

refinamento dos

requisitos

Refinamento

do protótipo

Engenharia

do produto Projeto

rápido

Construção

do

protótipo Avaliação do

protótipo

pelo cliente

Fim

Início COLETA DOS REQUISITOS:

desenvolvedor e cliente definem os objetivos gerais do

software, identificam quais requisitos são

conhecidos e as áreas que necessitam de

definições adicionais

PROTOTIPAÇÃO

40



Coleta e

refinamento dos

requisitos

Refinamento

do protótipo

Engenharia

do produto Projeto

rápido

Construção

do


protótipo

pelo cliente

Fim

Início

PROJETO RÁPIDO: representação dos aspectos do software que são visíveis ao usuário (abordagens de entrada e formatos de saída)

PROTOTIPAÇÃO

41



Coleta e

refinamento dos

requisitos

Refinamento

do protótipo

Engenharia

do produto Projeto

rápido

Construção

do


protótipo

pelo cliente

Fim

Início

CONSTRUÇÃO PROTÓTIPO:

Implementação do projeto rápido serve como o “primeiro sistema” - recomendado que se jogue fora futuramente

PROTOTIPAÇÃO

42



Coleta e

refinamento dos

requisitos

Refinamento

do protótipo

Engenharia

do produto Projeto

rápido

Construção

do


protótipo

pelo cliente

Fim

Início

AVALIAÇÃO DO PROTÓTIPO:

Cliente e desenvolvedor avaliam o protótipo

PROTOTIPAÇÃO

43



Coleta e

refinamento dos

requisitos

Refinamento

do protótipo

Engenharia

do produto Projeto

rápido

Construção

do


protótipo

pelo cliente

Fim

Início

REFINAMENTO DOS REQUISITOS:

Cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido.

PROTOTIPAÇÃO

44



Coleta e

refinamento dos

requisitos

Refinamento

do protótipo

Engenharia

do produto Projeto

rápido

Construção

do


protótipo

pelo cliente

Fim

Início

CONSTRUÇÃO PRODUTO:

identificados os requisitos, o protótipo deve ser descartado e a versão de produção deve ser construída considerando os critérios de qualidade.

PROTOTIPAÇÃO

45



CONTRIBUIÇÕES DA PROTOTIPAÇÃO

• Sistemas pequenos

• Útil quando os requisitos estão obscuros

• Especificação é construída gradativamente

• Possibilitam um rápido desenvolvimento da aplicação

46



• O processo não é visível

• Os sistemas são frequentemente mal-estruturados e mal-documentados

• Processo não é claro, dificuldade de planejamento e gerenciamento

47

PROBLEMAS DA PROTOTIPAÇÃO



incremento 2

Engenharia de Sistemas /

Informação

Análise Projeto Codificação Testes




incremento 1

incremento 3

incremento 4

produto liberado

do incremento 1

produto liberado

do incremento 2

produto liberado

do incremento 3

produto

liberado

do

incremento 4

MODELO INCREMENTAL

48



• Combina elementos do Modelo Linear com a filosofia da Prototipação.

• Aplica sequências lineares numa abordagem de “saltos” à medida que o tempo progride.

• Cada sequência linear produz um incremento do software (proc. de texto)

49

MODELO INCREMENTAL



• O processo se repete até que um produto completo seja produzido.

• Difere da Prototipação, pois a cada incremento produz uma versão operacional do software.

50

MODELO INCREMENTAL



CONTRIBUIÇÕES DO MODELO INCREMENTAL

• Entrega acelerada dos serviços de cliente. Cada incremento fornece a funcionalidade de mais alta prioridade para o cliente.

• Engajamento do usuário com o sistema.

Os usuários têm de estar envolvidos no processo de desenvolvimento, o que significa que o sistema muito provavelmente atenderá aos seus requisitos, e que os usuários estarão mais comprometidos com ele.

51



• Problemas de gerenciamento O progresso pode ser difícil de julgar e os problemas, difíceis de serem encontrados, porque não há documentação que mostre o que foi feito.

• Problemas contratuais O contrato normal pode incluir uma especificação; sem uma especificação, formulários diferentes de contrato têm de ser usados.

52

PROBLEMAS DO MODELO INCREMENTAL



• Problemas de validação Sem uma especificação, contra o que o sistema está sendo testado.

• Problemas de manutenção Mudanças contínuas tendem a corromper a estrutura do software, o que torna mais dispendioso mudar e evoluir para atender aos novos requisitos.

53

PROBLEMAS DO MODELO INCREMENTAL



• Desenvolvido para englobar as melhores características do ciclo de vida clássico e do paradigma evolutivo.

• São avaliados riscos explicitamente e são solucionados ao longo do processo.

• Processo é representado como uma espiral em lugar de ser representado como uma sequência de atividades

54

MODELO ESPIRAL (Boehm)



Planejamento

Engenharia

Análise de

Risco

Avaliação do cliente

1 2

4 3

MODELO ESPIRAL (Boehm)

55



Planejamento

Engenharia

Análise de

risco


Coleta inicial dos requisitos e

planejamento do projeto

Planejamento baseado nos

comentários do cliente

Modelo Espiral

56



• São identificados objetivos específicos, tais como desempenho e funcionalidade.

• São determinadas alternativas para atingir estes objetivos.

• São identificadas restrições do processo e do produto e é elaborado um relatório de gestão detalhado.

Modelo Espiral

57



Modelo Espiral

Planejamento

Engenharia

Análise de

risco


Decisão de prosseguir/não prosseguir

Para cada risco do projeto identificado em planejamento é levada a cabo uma análise detalhada.

58



Planejamento

Engenharia

Análise de

risco


Na direção de um sistema concluído

Protótipo de software inicial

Sistema construído pela

engenharia

Modelo Espiral

59



Planejamento

Engenharia

Análise de

risco

Avaliação do

cliente

• tarefas requeridas para obter um feedback do cliente baseado na avaliação da representação do software criado durante a fase de engenharia e implementado durante a fase de instalação

Modelo Espiral

60



DESENVOLVIMENTO RÁPIDO DE SOFTWARE

• Métodos ágeis • Extreme programming • Desenvolvimento rápido de aplicações • Prototipação de software

61



• Devido à rápida mudança dos ambientes de negócio, os negócios devem responder às novas oportunidades e à competição. • Isso requer software e desenvolvimento rápido, e a entrega é, frequentemente, o requisito mais crítico para sistemas de software. • Os negócios podem estar dispostos a aceitar um software de baixa qualidade se a entrega rápida e a funcionalidade essencial for possível.

62

DESENVOLVIMENTO RÁPIDO DE SOFTWARE



• Movimento iniciado por programadores experientes e consultores em desenvolvimento de software.

• Objetivo: satisfazer o cliente entregando, rapidamente e com frequência, sistemas com algum valor.

• Os métodos ágeis são, provavelmente, os mais adequados para sistemas de negócio de porte pequeno/médio ou produtos para PC.

MÉTODOS ÁGEIS

63



• A insatisfação com os overheads envolvidos nos métodos de projeto levou à criação dos métodos ágeis. Esses métodos:

• Enfocam o código ao invés do projeto; • São baseados na abordagem iterativa para desenvolvimento de software; • São destinados a entregar software de trabalho e evoluí-lo rapidamente para atender aos requisitos que se alteram.

64

MÉTODOS ÁGEIS



PRINCÍPIOS DOS MÉTODOS ÁGEIS

Envolvimento do cliente

Seu papel é fornecer e priorizar novos

requisitos do sistema e avaliar as

iterações do sistema.Clientes devem

ser profundamente envolvidos no

processo de desenvolvimento.

65



Entrega incremental

O software é desenvolvido em

incrementos e o cliente especifica os

requisitos a serem incluídos em cada

incremento.

66




Pessoas, não processo

As habilidades da equipe de

desenvolvimento devem ser

reconhecidas e exploradas. Os

membros da equipe devem

desenvolver suas próprias maneiras

de trabalhar sem processos

prescritivos.

67




Aceite as mudanças

Projete o sistema para acomodar

mudanças.

Mantenha a simplicidade

Elimine a complexidade do sistema.

68




PROBLEMAS COM MÉTODOS ÁGEIS

• Difícil manter o interesse dos clientes que estão envolvidos no processo. • Os membros da equipe podem ser inadequados para o intenso envolvimento que caracteriza os métodos ágeis.

69



• A priorização de mudanças pode ser difícil onde existem múltiplos stakeholders. • A manutenção da simplicidade requer trabalho extra. • Problemas nos contratos.

70

PROBLEMAS COM MÉTODOS ÁGEIS



EXTREME PROGRAMMING

• É talvez o mais conhecido e mais amplamente usado dos métodos ágeis. • A eXtreme Programming (XP) leva uma abordagem “extrema” para desenvolvimento iterativo.

71



• Novas versões podem ser compiladas várias vezes por dia. Os incrementos são entregues para os clientes a cada 2 semanas. • Todos os testes devem ser realizados para cada nova versão.

72

EXTREME PROGRAMMING



OS 4 VALORES DE XP

• Comunicação

• Simplicidade

• Retorno (feedback)

• Coragem

73



EXTREME PROGRAMMING a quem se destina

• Grupos de 2 a 10 programadores • Projetos de 1 a 36 meses (calendário) • De 1000 a 250 000 linhas de código • Papéis:

• Programadores foco central (sem hierarquia)

• “Treinador” ou “Técnico” (coach) • “Acompanhador” (tracker) • Cliente

74



EXTREME PROGRAMMING “Treinador” ou “Técnico” (coach)

• Em geral, o mais experiente do grupo. Identifica quem é bom no que. Comunica-se com outros gerentes e diretoria.

• Concentra-se na execução e evolução técnica do projeto.

75



• Eventualmente faz programação pareada.

• Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias.

• Seu papel diminui à medida em que o time fica mais maduro.

EXTREME PROGRAMMING “Treinador” ou “Técnico” (coach)

76



EXTREME PROGRAMMING Tracker (Acompanhador)

• Coleta estatísticas sobre o andamento do projeto. Alguns exemplos:

• Número de histórias definidas e implementadas. • Número de unit tests. • Número de testes funcionais definidos e

funcionando. • Número de classes, métodos, linhas de código

• Mantém histórico do progresso. Faz estimativas para

o futuro.

77



Um Dia na Vida de um Programador XP

• Escolhe uma história do cliente.

• Procura um par livre.

• Escolhe um computador para programação pareada (pair programming).

• Seleciona uma tarefa claramente relacionada a uma característica (feature)

desejada pelo cliente.

78



O ciclo de release em XP

79



Práticas do Extreme Programming

Planejamento Incremental

Registrados em cartões de histórias

Pequenos releases Conjunto

mínimo útil de funcionalidade é

desenvolvido.

80



Projeto simples

Projeto suficiente para atender aos

requisitos atuais.

Desenvolvimento test-first

Uso um framework automatizado.


81



Refactoring

Espera-se que todos os

desenvolvedores recriem o código

continuamente.

Programação em pares

Os desenvolvedores trabalham em pares.


82



Propriedade coletiva

Os pares trabalham em todas as áreas

do sistema.

Integração contínua

Tarefa concluída é automaticamente

integrada ao sistema.


83



Ritmo sustentável

Não aceitar grande quantidade de

horas extras.

Cliente on-site

Um usuário do sistema deve estar

disponível em tempo integral..


84



Quando XP Não Deve Ser Experimentada?

• Quando o cliente não aceita as regras do jogo.

• Quando o cliente quer uma especificação detalhada do sistema antes de começar.

• Quando os programadores não estão dispostos a seguir (todas) as regras.

• Se (quase) todos os programadores do time não são experientes.

85



• Grupos grandes (>10 programadores).

• Quando feedback rápido não é possível:

• sistema demora 6h para compilar. • testes demoram 12h para rodar. • exigência de certificação que demora meses.

•Quando o custo de mudanças é essencialmente exponencial.

•Quando não é possível realizar testes (muito raro).

Quando XP Não Deve Ser Experimentada?

86



MODELO DE MÉTODOS FORMAIS

Um modelo de sistema matemático é transformado formalmente em uma implementação

87



• Compreende um conjunto de atividades

que determinam uma especificação

matemática para o software.

• A especificação de requisitos de software é redefinida em uma especificação formal detalhada, que é expressa em uma notação matemática.

88

MODELO DE MÉTODOS FORMAIS



TÉCNICAS DE 4A GERAÇÃO

Obtenção dos Requisitos

Estratégia de “Projeto”

Implementação usando

4GL Testes

89



• Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural.

• Engloba um conjunto de ferramentas de software que possibilitam que:

o sistema seja especificado em uma linguagem de alto nível e

o código fonte seja gerado automaticamente a partir dessas especificações

90




• O ambiente de desenvolvimento inclui as ferramentas:

• linguagens não procedimentais para consulta de banco de dados

• geração de relatórios

• manipulação de dados

• interação e definição de telas

• geração de códigos

• capacidade gráfica de alto nível

• capacidade de planilhas eletrônicas

91




ATIVIDADES DAS TÉCNICAS DE 4A GERAÇÃO

Obtenção dos

Requisitos Estratégia de “Projeto”

Implementação usando 4GL

Testes

92



• OBTENÇÃO DOS REQUISITOS: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional

• O cliente pode estar inseguro quanto aos requisitos

• O cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir

93





Estratégia de

“Projeto” Implementação usando 4GL

Testes

94




• ESTRATÉGIA DE "PROJETO":

• para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação

• Para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade, manutenibilidade ruim, má aceitação do cliente)

95






Implementação

usando 4GL Testes

96




• IMPLEMENTAÇÃO USANDO 4GL:

–os resultados desejados são representados de modo que haja geração automática de código.

97






Implementação usando 4GL

Testes

98




• TESTE:

• o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa.

• O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.

99




• Riscos na integração dos sub-sistemas Modelo Cascata

• Riscos significativos na interface com o utilizador Desenvolvimento evolutivo.

• Riscos de segurança Desenvolvimento Formal

Escolher um modelo de desenvolvimento para o sistema

100



Combinando Paradigmas obtenção preliminar dos

requisitos

modelo espiral

técnicas

4G

prototipação

análise dos

requisitos

projeto

codificação

testes

Manutenção

técnicas 4G

técnicas

4G

modelo espiral:

enésima interação

prototipação

enésima interação

Sistema Completo

101

Atividades para especificar, projetar, implementar e ...maria/arqan/2013-2/cap2-proc.pdf · PRESSMAN, ROGER - Engenharia de Software - 6° Edição SOMMERVILLE - Engenharia de Software

Documents