Engenharia de Software I - fct.unesp.br · PRESSMAN, R. S. Engenharia de Software, 6 ... Análise...

�FCT-UNESP �25/04/2017

�Prof. Dr. Rogério Eduardo Garcia �1

Bacharelado emCiência da

Computação2017

Engenharia de Software I

Rogério Eduardo Garcia([email protected])

BCC2017Bibliografia Básica

� PRESSMAN, R. S. Engenharia de Software, 6ªEdição, McGraw-Hill, Boston, 2001.

� SOMMERVILLE, I. Engenharia de Software, 6ªEdição, Addison-Wesley, São Paulo, 2003.

� PETERS, J. F.; PEDRYCZ, W. Engenharia deSoftware: teoria e prática, Editora Campus, Riode Janeiro, 2001.

� PFLEEGER, S. L. Engenharia de Software,Teoria e Prática. Pearson Brasil, 2004.

25/04/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 2

�FCT-UNESP �25/04/2017


BCC2017Metodologia

� Aulas expositivas teórico-práticas;� Exercícios práticos;� Projetos individuais e/ou em grupo;� Seminários, individuais e em grupo, sobre

tópicos abordados e relacionados.


BCC2017Avaliação

� As notas de todas as atividades – entre 0 (zero) e 10,0 (dez) –serão atribuídas individualmente, mesmo em atividades em grupo;

� A média final será calculada da seguinte maneira:� MA = (NP1 + 2*NP2)/3� Mt = (NT1 + NT2 +...+ NTn) / n� MT = (7 * NPJ + 3 * Mt)� Média Final:

� MF = (MA + MT)/2 SE E SOMENTE SE (MA>=5 E MT>=5)� Caso contrário (MP<5 OU MT<5) MF = Menor Nota� Sendo:

� MF = Média Final.� MA = Média de Provas� MT = Média de Trabalhos e Projeto� Mt = Média de Trabalhos

Estude como se você fosse viver para sempre. Viva como se você fosse morrer amanhã


�FCT-UNESP �25/04/2017


BCC2017Tópicos da Disciplina

� Introdução: Histórico do desenvolvimento da área de Engenhariade Software. Conceitos básicos e terminologia.

� Objetivos da Engenharia de Software: Finalidade e aplicabilidadedos métodos e técnicas da Engenharia de Software, fornecendouma visão ampla e abrangente da área. Qualidade de Software(ISO 9126)

� Processo de software: Definição de processo de software.Comparação entre modelos de ciclo de vida. Descrição dasatividades no desenvolvimento de software.

� Análise de Requisitos de software: Técnicas de especificação derequisitos. Tipos de requisitos. Modelo de sistemas.

� Projeto de software: Arquitetura de software. Modelos paraarquitetura de sistemas. Sistema de tempo real. Interface com ousuário.

� Verificação e validação de software: Distinção entre verificação evalidação. Planejamento. Testes de software. Sistemas críticos.


BCC2017Cronograma


�FCT-UNESP �25/04/2017


BCC2017

Software e Engenharia de Software

� A importância do Software� Software� Aplicações de Software� Mitos de Software� Processo de Software� Modelos de Processo de

Desenvolvimento de Software


BCC2017


�FCT-UNESP �25/04/2017


BCC2017SOFTWARE

� “Software é um lugar onde sonhos sãoplantados e pesadelos são colhidos, umpântano abstrato e místico onde demôniosterríveis competem com mágicas panaceias,um mundo de lobisomem e balas de prata”

Brad J. Cox


BCC2017SOFTWARE

� INSTRUÇÕES que quando executadasproduzem a função e o desempenhodesejados

� ESTRUTURAS DE DADOS que possibilitamque os programas manipulemadequadamente a informação

� DOCUMENTOS que descrevem a operaçãoe o uso dos programas


�FCT-UNESP �25/04/2017


BCC2017Características do Software

� Desenvolvido ou projetado por engenharia,não manufaturado no sentido clássico

� Não se desgasta, mas se deteriora





Curva de Falhas do Hardwaretempo

“desgaste”“mortalidade infantil”

índ

ice

de

falh

as


�FCT-UNESP �25/04/2017





mu

dan

ça

curva idealizada

tempo

Curva de Falhas do Software

índ

ice

de

falh

as


curva real



� Não se desgasta, mas se deteriora� A maioria é feita sob medida em vez de ser

montada a partir de componentes existentes


�FCT-UNESP �25/04/2017


BCC2017Aplicações do Software

� Básico� De Tempo Real� Comercial� Científico e de Engenharia� Embutido� De Computador Pessoal� De Inteligência Artificial


BCC2017Evolução do Software

(1950 - 1965)� O hardware sofreu contínuas mudanças� O software era uma arte "secundária" para a

qual havia poucos métodos sistemáticos� O hardware era de propósito geral� O software era específico para cada

aplicação� Não havia documentação


�FCT-UNESP �25/04/2017



(1965 - 1975)� Multiprogramação e sistemas multiusuários� Técnicas interativas� Sistemas de tempo real� 1ª geração de SGBD’s� Produto de software - software houses� Bibliotecas de Software



(1965 - 1975)� Cresce o número de sistemas baseado em

computador� Manutenção quase impossível

..... CRISE DE SOFTWARE


�FCT-UNESP �25/04/2017



(1965 - 1975)� Cresce o número de sistemas baseado em


..... CRISE DE SOFTWARE

CRISE DE SOFTWARERefere-se a um conjunto de

problemas encontrados no desenvolvimento de software

AFLIÇÃO CRÔNICA



(1975 - hoje)� Sistemas distribuídos� Redes locais e globais� Uso generalizado de microprocessadores -

produtos inteligentes� Hardware de baixo custo� Impacto de consumo


�FCT-UNESP �25/04/2017


BCC2017Crise de Software - problemas

1) As estimativas de prazo e de custofrequentemente são imprecisas� “Não dedicamos tempo para coletar dados sobre

o processo de desenvolvimento de software”� “Sem nenhuma indicação sólida de produtividade,

não podemos avaliar com precisão a eficácia denovas ferramentas, métodos ou padrões”



2) Insatisfação do cliente com o sistemaconcluído� “Os projetos de desenvolvimento de software

normalmente são efetuados apenas com umvago indício das exigências do cliente”


�FCT-UNESP �25/04/2017



3) A qualidade de software às vezes é menosque adequada� Só recentemente começam a surgir conceitos

quantitativos sólidos de garantia de qualidade desoftware



4) O software existente é muito difícil demanter� A tarefa de manutenção devora o orçamento

destinado ao software� A facilidade de manutenção não foi enfatizada

como um critério importante


�FCT-UNESP �25/04/2017


BCC2017

Causas dos problemas associados à crise de software

1) PRÓPRIO CARÁTER DO SOFTWARE� O software é um elemento de sistema lógico e

não físico. Consequentemente o sucesso émedido pela qualidade de uma única entidade enão pela qualidade de muitas entidadesmanufaturadas

O software não se desgasta, mas se deteriora


BCC2017


2) FALHAS DAS PESSOAS RESPONSÁVEISPELO DESENVOLVIMENTO DESOFTWARE� Gerentes sem nenhum background em software� Profissionais da área de software têm pouco

treinamento formal em novas técnicas para odesenvolvimento de software

� Resistência a mudanças


�FCT-UNESP �25/04/2017


BCC2017


3) MITOS DO SOFTWARE� Propagaram desinformação e confusão

� Administrativos� Cliente� Profissional


BCC2017

Mito 1:� Já temos um manual repleto de padrões e

procedimentos para a construção desoftware.

� Isso não oferecerá ao meu pessoal tudo oque eles precisam saber?

Mitos do SoftwareADMINISTRATIVOS:


�FCT-UNESP �25/04/2017


BCC2017

Mito 1:� Já temos um manual repleto de padrões e

procedimentos para a construção desoftware.

� Isso não oferecerá ao meu pessoal tudo oque eles precisam saber?



BCC2017

Mito 2:� Meu pessoal tem ferramentas de

desenvolvimento de software de últimageração.



�FCT-UNESP �25/04/2017


BCC2017

Mito 2:� Meu pessoal tem ferramentas de

desenvolvimento de software de últimageração.



BCC2017

Mito 3:� Se nós estamos atrasados nos prazos,

podemos adicionar mais programadores etirar o atraso.



�FCT-UNESP �25/04/2017


BCC2017

Mito 3:� Se nós estamos atrasados nos prazos,

podemos adicionar mais programadores etirar o atraso



BCC2017

Mito 1:� Uma declaração geral dos objetivos é

suficiente para se começar a escreverprogramas - podemos preencher os detalhesmais tarde.

Mitos do SoftwareCLIENTE:


�FCT-UNESP �25/04/2017


BCC2017

Mito 1:� Uma declaração geral dos objetivos é

suficiente para se começar a escreverprogramas - podemos preencher os detalhesmais tarde.



BCC2017

Mito 2:� Os requisitos de projeto modificam-se

continuamente, mas as mudanças podem serfacilmente acomodadas, porque o software éflexível.



�FCT-UNESP �25/04/2017


BCC2017

Mito 2:� Os requisitos de projeto modificam-se

continuamente, mas as mudanças podem serfacilmente acomodadas, porque o software éflexível.



BCC2017

MAGNITUDE DAS MUDANÇAS

Mitos do Software

FASES CUSTO DE MANUTENÇÃO

DEFINIÇÃO 1x

DESENVOLVIMENTO 1.5 a 6x

MANUTENÇÃO 60 a 100x


�FCT-UNESP �25/04/2017


BCC2017

Mito 1:� Assim que escrevermos o programa e o

colocarmos em funcionamento nossotrabalho estará completo.

Mitos do SoftwarePROFISSIONAL:


BCC2017

Mito 1:� Assim que escrevermos o programa e o

colocarmos em funcionamento nossotrabalho estará completo.



�FCT-UNESP �25/04/2017


BCC2017

Mito 2:� Enquanto não tiver o programa

"funcionando", eu não terei realmentenenhuma maneira de avaliar sua qualidade.



BCC2017

Mito 2:� Enquanto não tiver o programa

"funcionando", eu não terei realmentenenhuma maneira de avaliar sua qualidade.



�FCT-UNESP �25/04/2017



� (1965 - 1975)� Cresce o número de sistemas baseado em


CRISE DE SOFTWARE

Refere-se a um conjunto de problemas

encontrados no desenvolvimento de

software


BCC2017Resposta à Crise de Software

� A aplicação de uma abordagem sistemática,disciplinada e possível de ser medida para odesenvolvimento, operação e manutenção dosoftware (IEEE)


�FCT-UNESP �25/04/2017


BCC2017Resposta à Crise de Software

PROCESSO DE SOFTWARE

� A aplicação de uma abordagem sistemática,disciplinada e possível de ser medida para odesenvolvimento, operação e manutenção dosoftware (IEEE)


BCC2017Engenharia de Software

� Pode ser vista como uma abordagem dedesenvolvimento de software elaborada comdisciplina e métodos bem definidos.

.....“a construção por múltiplas pessoas de um

software de múltiplas versões”

[Parnas 1987]


�FCT-UNESP �25/04/2017


BCC2017Qualidade


BCC2017Qualidade de Software

O QUE

Funcionalidade

QUANDO e COMO

Confiabilidade

Usabilidade

Eficiência

Manutenibilidade

Portabilidade

Norma ISO/IEC 9126Características


�FCT-UNESP �25/04/2017


BCC2017Qualidade de Software

UsuárioDesenvolvedorOrganização requisitos de

software produto Processo

deDesenvolvimento

SOFTWARE PRODUTO

requisitosatendidos

SOFTWARE COM QUALIDADE

PROCESSO DE SOFTWAREDefinição

Avaliação


BCC2017O Processo de Software

� Abrange um conjunto de três elementosfundamentais: Métodos, Ferramentas eProcedimentos para projetar, construir emanter grandes sistemas de software deforma profissional


�FCT-UNESP �25/04/2017



� MÉTODOS: proporcionam os detalhes decomo fazer para construir o software

� Planejamento e estimativa de projeto

� Análise de requisitos de software e de sistemas

� Projeto da estrutura de dados

� Algoritmo de processamento

� Codificação

� Teste

� Manutenção



� FERRAMENTAS: dão suporte automatizadoaos métodos

� Existem atualmente ferramentas para sustentarcada um dos métodos

� Quando as ferramentas são integradas, éestabelecido um sistema de suporte aodesenvolvimento de software chamado CASE -

Computer Aided Software Engineering


�FCT-UNESP �25/04/2017



� PROCEDIMENTOS: constituem o elo deligação entre os métodos e ferramentas

� Sequência em que os métodos devem seraplicados

� Produtos que se exige que sejam entregues

� Controles que ajudam assegurar a qualidade ecoordenar as alterações

� Marcos de referência que possibilitamadministrar o progresso do software


BCC2017ISO 12207: Estrutura

Processos Fundamentais Processos de Apoio

Processos Organizacionais

Aquisição

Fornecimento

Desenvolvimento

Operação

Manutenção

Documentação

Garantia de Qualidade

Verificação

Validação

Revisão Conjunta

Auditoria

Resolução de Problemas

Gerência

Melhoria

Infra-estrutura

Treinamento

Ada

ptaç

ão


�FCT-UNESP �25/04/2017


BCC2017

Processo de Software com Qualidade

� A Qualidade do Processo de Software estárelacionada à extensão na qual um processo desoftware específico é eficiente e é explicitamentedefinido, gerenciado, medido e controlado.

� A Qualidade de Processo de Software tambémimplica em um potencial para crescimento nacapacidade do processo de software e aconsistência com a qual ele é aplicado em projetospor toda a organização.


BCC2017

Processo de Software com Qualidade (SOMMERVILLE)

� Inteligibilidade� O processo é definido e inteligível

� Visibilidade� O progresso do processo é visível

externamente

� Suportabilidade� O processo pode ser apoiado por ferramentas

CASE


�FCT-UNESP �25/04/2017


BCC2017


� Aceitabilidade� O processo é aceito por todos envolvidos nele

� Confiabilidade� Os erros do processo são descobertos antes

que resultem em erros no produto

� Robustez� O processo pode continuar a despeito de

problemas inesperados


BCC2017


� Manutenibilidade� O processo pode evoluir para atender

alterações de necessidades organizacionais

� Velocidade� Quão rápido o sistema pode ser produzido


�FCT-UNESP �25/04/2017


BCC2017

MODELOS DE PROCESSO DE SOFTWARE

Processo de Software com Qualidade

PROCESSO DE SOFTWARE

eficiente

controlado

definido

medido

gerenciado


BCC2017

Fases Genéricas dos Modelos de Processo de ENGENHARIA� Especificação - estabelecer os requisitos e restrições

do sistema

� Projeto - produzir um modelo documentado do sistema

� Implementação - construir o sistema

� Teste - verificar se o sistema atende às especificaçõesrequeridas

� Instalação - liberar o sistema para o cliente e garantirque ele seja operacional

� Manutenção – eliminar defeitos e evoluir o sistemaconforme demanda


�FCT-UNESP �25/04/2017


BCC2017

Fases Genéricas dos Modelos de Processo de SOFTWARE

� Independentemente da natureza do projeto eaplicação os modelos de processo desoftware possuem:

� Fase de definição� Fase de desenvolvimento� Fase de manutenção� Atividades de apoio


BCC2017

Fase de Definição do Processo de Software

Focaliza "o que" será desenvolvido� Que informação vai ser processada� Que função e desempenho são desejados� Que comportamento pode ser esperado do sistema� Que interfaces vão ser estabelecidas� Que restrições de projeto existem� Que critérios de validação são exigidos para definir

um sistema bem sucedido� Que tarefas serão realizadas


�FCT-UNESP �25/04/2017


BCC2017

Fase de Definição do Processo de Software

Focaliza "o que" será desenvolvido� Que informação vai ser processada� Que função e desempenho são desejados� Que comportamento pode ser esperado do sistema� Que interfaces vão ser estabelecidas� Que restrições de projeto existem� Que critérios de validação são exigidos para definir

um sistema bem sucedido� Que tarefas serão realizadas

Três tarefas principais ocorrem de alguma forma:

engenharia de sistemas

planejamento do projeto de software

análise de requisitos


BCC2017

Fase de Desenvolvimento do Processo de Software

Focaliza "como" o software será desenvolvido� Como os dados vão ser estruturados� Como a função vai ser implementada como uma

arquitetura de software� Como os detalhes procedimentais vão ser

implementados� Como as interfaces vão ser caracterizadas� Como o projeto será traduzido em uma linguagem

de programação� Como os testes serão efetuados


�FCT-UNESP �25/04/2017


BCC2017

Fase de Desenvolvimento do Processo de Software

Focaliza "como" o software será desenvolvido� Como os dados vão ser estruturados� Como a função vai ser implementada como uma

arquitetura de software� Como os detalhes procedimentais vão ser

implementados� Como as interfaces vão ser caracterizadas� Como o projeto será traduzido em uma linguagem

de programação� Como os testes serão efetuados

Três tarefas técnicas específicas deverão ocorrer sempre:

projeto de software

geração de código

Inspeção e teste de software


BCC2017

Fase de Manutenção do Processo de Software

Focaliza as "mudanças" que ocorrerão depois que o software for liberado para uso operacional

� A fase de manutenção reaplica os passos das fasesde definição e desenvolvimento, mas faz isso nocontexto de um software existente.


�FCT-UNESP �25/04/2017


BCC2017

Fase de Manutenção do Processo de Software

Focaliza as "mudanças" que ocorrerão depois que o software for liberado para uso operacional

� A fase de manutenção reaplica os passos das fasesde definição e desenvolvimento, mas faz isso nocontexto de um software existente.

As mudanças estão associadas com:

• Correção de erros/defeitos• Adaptações exigidas conforme o ambiente

do software evolui• Mudanças devido a melhoramentos

ocorridos por alterações nos requisitos dos clientes


BCC2017

Atividades de Apoio ao Processo de Software

� As três fases genéricas do processo de softwaresão complementadas por uma série de atividades

de apoio

� As atividades de apoio são aplicadas durante toda aengenharia do software


�FCT-UNESP �25/04/2017


BCC2017

Atividades de Apoio ao Processo de Software

� As três fases genéricas do processo de softwaresão complementadas por uma série de atividades

de apoio

� As atividades de apoio são aplicadas durante toda aengenharia do software

Atividades típicas nessa categoria são:

� Controle e Acompanhamento do Projeto de Software

� Revisões Técnicas Formais

� Garantia de Qualidade de Software

� Gerenciamento de Configuração de Software

� Preparação e Produção de Documentos

� Gerenciamento de Reusabilidade

� Medidas


BCC2017

Modelos de Processo de Desenvolvimento de Software

� Existem vários modelos de processo de

desenvolvimento de software (ou paradigmas

de engenharia de software)� Cada um representa uma tentativa de

colocar ordem em uma atividadeinerentemente caótica

� Pode-se citar os seguintes modelos de

processo de desenvolvimento de software


�FCT-UNESP �25/04/2017


BCC2017

Modelos de Processo de Desenvolvimento de Software� O Modelo Sequencial Linear

� Também chamado Modelo Cascata

� O Modelo de Prototipação� O Modelo RAD (Rapid Application Development)� Modelos Evolutivos de Processo de Software

� O Modelo Incremental� O Modelo Espiral� O Modelo de Montagem de Componentes

� Técnicas de Quarta Geração


BCC2017


� Também chamado Modelo Cascata� O Modelo de Prototipação� O Modelo RAD (Rapid Application Development)� Modelos Evolutivos de Processo de Software




�FCT-UNESP �25/04/2017


BCC2017O Modelo Cascata

� Modelo mais antigo e o mais amplamenteusado da engenharia de software

� Modelado em função do ciclo da engenhariaconvencional

� Requer uma abordagem sistemática,sequencial ao desenvolvimento de software

� O resultado de uma fase se constitui naentrada da outra



Engenharia de Sistemas

Análise de Requisitos

Projeto

Codificação

Testes

Manutenção


�FCT-UNESP �25/04/2017





Projeto

Codificação

Testes

Manutenção

Engenharia de Sistemas / Informação e Modelagem

� Envolve a coleta de requisitos em nível dosistema, com uma pequena quantidade de projetoe análise de alto nível

� Esta visão é essencial quando o software devefazer interface com outros elementos (hardware,pessoas e banco de dados)





Projeto

Codificação

Testes

Manutenção

Análise de Requisitos de Software� O 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� Os requisitos (para o sistema e para o software) são

documentados e revistos com o cliente


�FCT-UNESP �25/04/2017





Projeto

Codificação

Testes

ManutençãoProjeto

� Tradução dos requisitos do software para um conjunto derepresentações que podem ser avaliadas quanto àqualidade, antes que a codificação se inicie





Projeto

Codificação

Testes

ManutençãoCodificação� Tradução das representações do projeto

para uma linguagem “artificial” resultandoem instruções executáveis pelo computador


�FCT-UNESP �25/04/2017





Projeto

Codificação

Testes

Manutenção

Testes� Concentra-se:

� Nos aspectos lógicos internos do software, garantindo quetodas as instruções tenham sido testadas

� Nos aspectos funcionais externos, para descobrir erros egarantir que a entrada definida produza resultados queconcordem com os esperados





Projeto

Codificação

Testes

Manutenção

Manutenção� Provavelmente o software

deverá sofrer mudanças depoisque for entregue ao cliente

� Causas das mudanças: erros,adaptação do software paraacomodar mudanças em seuambiente externo e exigênciado cliente para acréscimosfuncionais e de desempenho


�FCT-UNESP �25/04/2017


BCC2017

Problemas com o Modelo Cascata

� Projetos reais raramente seguem o fluxo“sequencial” que o modelo propõe

� Logo no início é difícil estabelecerexplicitamente todos os requisitos. Nocomeço dos projetos sempre existe umaincerteza natural

� O cliente deve ter paciência. Uma versãoexecutável do software só fica disponível emuma etapa avançada do desenvolvimento


BCC2017

Problemas com o Modelo Cascata

� Projetos reais raramente seguem o fluxo“sequencial” que o modelo propõe

� Logo no início é difícil estabelecerexplicitamente todos os requisitos. Nocomeço dos projetos sempre existe umaincerteza natural

� O cliente deve ter paciência. Uma versãoexecutável do software só fica disponível emuma etapa avançada do desenvolvimento

�Embora o Modelo Cascata tenha

fragilidades, ele é significativamente

melhor do que uma abordagem casual

ao desenvolvimento de software


�FCT-UNESP �25/04/2017



� O modelo Cascata trouxe contribuiçõesimportantes para o processo dedesenvolvimento de software:� Imposição de disciplina, planejamento e

gerenciamento� A implementação do produto deve ser

postergada até que os objetivos tenham sidocompletamente entendidos


BCC2017







�FCT-UNESP �25/04/2017


BCC2017O Modelo de Prototipação

� O objetivo é entender os requisitos dousuário e, assim, obter uma melhor definiçãodos requisitos do sistema

� Possibilita que o desenvolvedor crie ummodelo (protótipo) do software que deve serconstruído

� Apropriado para quando o cliente não definiudetalhadamente os requisitos


BCC2017

O Modelo de Prototipação para obtenção dos requisitos

Obter Requisitos

Elaborar Projeto Rápido

Construir Protótipo

Avaliar Protótipo

Refinamento do Protótipo


�FCT-UNESP �25/04/2017


BCC2017


Obter Requisitos



Avaliar Protótipo


1- OBTENÇÃO DOS REQUISITOS:desenvolvedor e cliente definem os objetivosgerais do software, identificam quaisrequisitos são conhecidos e as áreas quenecessitam de definições adicionais


BCC2017


Obter Requisitos



Avaliar Protótipo

Refinamento do Protótipo2- PROJETO RÁPIDO: representação dosaspectos do software que são visíveis aousuário (abordagens de entrada eformatos de saída)


�FCT-UNESP �25/04/2017


BCC2017


Obter Requisitos


Construir ProtótipoAvaliar Protótipo

Refinamento do Protótipo3- CONSTRUÇÃO PROTÓTIPO:

implementação rápida doprojeto


BCC2017


Obter Requisitos



Avaliar Protótipo

Refinamento do Protótipo4- AVALIAÇÃO DO PROTÓTIPO: cliente e

desenvolvedor avaliam o protótipo


�FCT-UNESP �25/04/2017


BCC2017


Obter Requisitos



Avaliar Protótipo


5- REFINAMENTO DO PROTÓTIPO: cliente edesenvolvedor refinam os requisitos dosoftware a ser desenvolvido


BCC2017


Obter Requisitos




CONSTRUÇÃO DO PRODUTO

Avaliar Protótipo


�FCT-UNESP �25/04/2017


BCC2017


Obter Requisitos




CONSTRUÇÃO DO PRODUTO

Avaliar Protótipo

6- CONSTRUÇÃO PRODUTO: identificados osrequisitos, o protótipo deve ser descartadoe a versão de produção deve ser construídaconsiderando os critérios de qualidade


BCC2017Problemas com a Prototipação

� Cliente não sabe que o software que ele vênão considerou, durante o desenvolvimento,a qualidade global e a manutenibilidade alongo prazo

� Desenvolvedor frequentemente faz umaimplementação comprometida (utilizando oque está disponível) com o objetivo deproduzir rapidamente um protótipo


�FCT-UNESP �25/04/2017


BCC2017

Comentários sobre o Modelo de Prototipação

� Ainda que possam ocorrer problemas, aprototipação é um ciclo de vida eficiente

� A chave é definir-se as regras do jogo logono começo

� O cliente e o desenvolvedor devem ambosconcordar que o protótipo seja construídopara servir como um mecanismo a fim dedefinir os requisitos


BCC2017




� O Modelo Incremental� O Modelo Espiral� O Modelo de Montagem de Componentes� O Modelo de Desenvolvimento Concorrente

� Modelos de Métodos Formais� Técnicas de Quarta Geração


�FCT-UNESP �25/04/2017


BCC2017O Modelo RAD

� RAD (Rapid Application Development) é ummodelo sequencial linear que enfatiza umciclo de desenvolvimento extremamentecurto

� O desenvolvimento rápido é obtido usandouma abordagem de construção baseada emcomponentes


BCC2017O Modelo RAD

� Os requisitos devem ser bem entendidos e oalcance do projeto restrito

� O modelo RAD é usado principalmente paraaplicações de sistema de informação

� Cada função principal pode ser direcionadapara uma equipe RAD separada e entãointegrada para formar o todo


�FCT-UNESP �25/04/2017


BCC2017O Modelo RAD

Modelagem

do Negócio

Modelagem

dos Dados

Modelagem

do Processo

Geração da

Aplicação

Teste e

Modificação

Equipe #1

Modelagem

do Negócio

Modelagem

dos Dados

Modelagem

do Processo

Geração da

Aplicação

Teste e

Modificação

Equipe #2 Modelagem

do Negócio

Modelagem

dos Dados

Modelagem

do Processo

Geração da

Aplicação

Teste e

Modificação

Equipe #3

60 a 90 dias


BCC2017O Modelo RAD

Desvantagens:� Exige recursos humanos suficientes para todas

as equipes� Exige que desenvolvedores e clientes estejam

comprometidos com as atividades de “fogo-rápido” a fim de terminar o projeto num prazocurto


�FCT-UNESP �25/04/2017


BCC2017O Modelo RAD

� Nem todos os tipos de aplicação sãoapropriadas para o RAD:� Deve ser possível a modularização efetiva da

aplicação� Se alto desempenho é uma característica e o

desempenho é obtido sintonizando as interfacesdos componentes do sistema, a abordagem RADpode não funcionar


BCC2017







�FCT-UNESP �25/04/2017


BCC2017

Modelos Evolutivos de Processo

� Existem situações em que a engenharia desoftware necessita de um modelo deprocesso que possa acomodar um produtoque evolui com o tempo


BCC2017


� Quando os requisitos de produto e de negóciomudam conforme o desenvolvimento procede

� Quando uma data de entrega apertada (mercado) -impossível a conclusão de um produto completo

� Quando um conjunto de requisitos importantes ébem conhecido, porém os detalhes ainda devemser definidos


�FCT-UNESP �25/04/2017


BCC2017


� Modelos evolutivos são iterativos� Possibilitam o desenvolvimento de versões

cada vez mais completas do software


BCC2017







�FCT-UNESP �25/04/2017


BCC2017O Modelo Incremental

� O modelo incremental combina elementosdo modelo cascata (aplicado repetidamente)com a filosofia iterativa da prototipação

� O objetivo é trabalhar junto do usuário paradescobrir seus requisitos, de maneiraincremental, até que o produto final sejaobtido


BCC2017

O Modelo Incremental (SOMMERVILLE)

Versão Inicial

Descrição geral Descrição

geral

Descrição geral

Versões Intermediárias

Versão Final

Análise Projeto

Codificação

Teste

Engenharia de

sistemas/informação


�FCT-UNESP �25/04/2017



� A versão inicial é frequentemente o núcleodo produto (a parte mais importante)� A evolução acontece quando novas

características são adicionadas à medida quesão sugeridas pelo usuário

� Este modelo é importante quando é difícilestabelecer a priori uma especificaçãodetalhada dos requisitos



� O modelo incremental é mais apropriadopara sistemas pequenos

� As novas versões podem ser planejadas demodo que os riscos técnicos possam seradministrados (Ex. disponibilidade dedeterminado hardware)


�FCT-UNESP �25/04/2017


BCC2017







BCC2017O Modelo Espiral

� O modelo espiral acopla a natureza iterativada prototipação com os aspectos controladose sistemáticos do modelo cascata

� O modelo espiral é dividido em uma série deatividades de trabalho ou regiões de tarefa

� Existem tipicamente de 3 a 6 regiões detarefa


�FCT-UNESP �25/04/2017


BCC2017

O Modelo Espiral (com 4 regiões)

DETERMINAR OBJETIVOS, ALTERNATIVAS E

RESTRIÇÕES

PLANEJAR PRÓXIMA FASE

AVALIAR ALTERNATIVAS,IDENTIFICAR, RESOLVER RISCOS

DESENVOLVER, VERIFICARPRODUTO NO PRÓXIMO NÍVEL

Análisede risco

Análisede risco

Análisede risco

Análisede risco

Protótipo 3Protótipo 2

Protó-tipo 1

Protótipo de

operação

Revisão

Simulação, modelos, benchmarksConceito deoperação

Plano de requisitosPlano de ciclo de vida

Plano dedesenvolvimento

Integração eplano de teste

Requisitosde S/W Projeto do

produtoProjetodetalhado

Código

Teste deunidadeTeste de

integraçãoTeste deaceitaçãoOperação

Validação de requisitos

V & V doprojeto


BCC2017

O Modelo EspiralDETERMINAR OBJETIVOS,

ALTERNATIVAS E RESTRIÇÕES




Análisede risco

Análisede risco

Análisede risco

Análisede risco


Protó-tipo 1

Protótipo de

operação

Revisão







Código




V & V doprojeto

cada “loop” no espiral representa

uma fase do processo de

software


�FCT-UNESP �25/04/2017


BCC2017

O Modelo Espiral

Análisede risco Protó-

tipo 1Revisão

Conceito deoperação


o “loop” mais interno está concentrado nas possibilidades do sistema


BCC2017

O Modelo Espiral

Análisede risco

Protótipo 2

Simulação, modelos, benchmarks


Requisitosde S/W


o próximo “loop”está concentrado na definição dos requisitos do sistema


�FCT-UNESP �25/04/2017


BCC2017

O Modelo Espiral

Análisede risco

Protótipo 3



Projeto doproduto

V & V doprojeto

o “loop” um pouco mais externo está concentrado no projeto do sistema


BCC2017

O Modelo Espiral

Análisede risco

Protótipo de

operação


Projetodetalhado

Código



um “loop” ainda mais externo está concentrado na construção do sistema


�FCT-UNESP �25/04/2017


BCC2017

O Modelo EspiralDETERMINAR OBJETIVOS,

ALTERNATIVAS E RESTRIÇÕES




Análisede risco

Análisede risco

Análisede risco

Análisede risco


Protó-tipo 1

Protótipo de

operação

Revisão







Código




V & V doprojeto

� Não existem fases fixas no modelo� As fases mostradas na figura são

meramente exemplos� A gerência decide como estruturar

o projeto em fases


BCC2017


DETERMINAR OBJETIVOS, ALTERNATIVAS E

RESTRIÇÕES




Análisede risco

Análisede risco

Análisede risco

Análisede risco


Protó-tipo 1

Protótipo de

operação

Revisão







Código




V & V doprojeto

AVALIAÇÃO E REDUÇÃO DE

RISCOS

Cada “loop” do espiral é dividido em 4 setores

DESENVOLVIMENTO E VALIDAÇÃO

PLANEJAMENTO

DEFINIÇÃO DE

OBJETIVOS


�FCT-UNESP �25/04/2017


BCC2017

• São definidos objetivos específicos para a fase do projeto

• São identificadas restrições sobre o processo e o produto

• É projetado um plano de gerenciamento detalhado

• São identificados riscos do projeto• Dependendo dos riscos, estratégias alternativas podem ser planejadas

DEFINIÇÃO DE

OBJETIVOS



BCC2017

• Para cada um dos riscos identificados, uma análise

detalhada é executada. Iniciativas são tomadas para

reduzir o risco

DEFINIÇÃO DE

OBJETIVOS


RISCOS



�FCT-UNESP �25/04/2017


BCC2017

• Depois da avaliação do risco, um modelo de

desenvolvimento é escolhido para o sistema

DEFINIÇÃO DE

OBJETIVOS


RISCOS




BCC2017

DEFINIÇÃO DE

OBJETIVOS


RISCOS


• O projeto é revisto e é tomada uma decisão de continuidade

se é decidido continuar• São projetados planos para a

próxima fase do projeto (próximo “loop” )

PLANEJAMENTO



�FCT-UNESP �25/04/2017


BCC2017

� Engloba as melhores características do ciclode vida Clássico e da Prototipação,adicionando um novo elemento: a Análisede Risco

� Segue a abordagem de passos sistemáticosdo Ciclo de Vida Clássico incorporando-osnuma estrutura iterativa que reflete maisrealisticamente o mundo real

� Usa a Prototipação, em qualquer etapa daevolução do produto, como mecanismo deredução de riscos

O Modelo Espiral


BCC2017

Comentários sobre o Modelo Espiral

� É, atualmente, a abordagem mais realísticapara o desenvolvimento de software emgrande escala

� Usa uma abordagem que capacita odesenvolvedor e o cliente a entender ereagir aos riscos em cada etapa evolutiva

� Pode ser difícil convencer os clientes queuma abordagem "evolutiva" é controlável


�FCT-UNESP �25/04/2017


BCC2017

Comentários sobre o Modelo Espiral

� Exige considerável experiência nadeterminação de riscos e depende dessaexperiência para ter sucesso

� O modelo é relativamente novo e não temsido amplamente usado. Demorará muitosanos até que a eficácia desse modelo possaser determinada com certeza absoluta


BCC2017

Planejamento

Análise de Riscos

Engenharia

Construção e Liberação

Avaliação do Cliente

Comunicação com Cliente



�FCT-UNESP �25/04/2017


BCC2017







BCC2017

O Modelo de Montagem de Componentes

� Utiliza tecnologias orientadas a objeto� Quando projetadas e implementadas

apropriadamente as classes orientadas aobjeto são reutilizáveis em diferentesaplicações e arquiteturas de sistema

� O modelo de montagem de componentesincorpora muitas das características domodelo espiral


�FCT-UNESP �25/04/2017


BCC2017


Planejamento

Análise de Riscos



Engenharia Construção e Liberação


BCC2017

O Modelo de Montagem de ComponentesPlanejamento

Análise de Riscos



Engenharia Construção e Liberação

Identificar componentes

candidatos

Procurar componentes na biblioteca

Extrair componentes se disponíveis

Construir os componentes

não disponíveis

Colocar os novos

componentes na biblioteca

Construir a na

iteração do sistema


�FCT-UNESP �25/04/2017


BCC2017


� O modelo de montagem de componentesconduz ao reúso do software

� A reusabilidade fornece uma série debenefícios:� Redução de 70% no tempo de desenvolvimento� Redução de 84% no custo do projeto� Índice de produtividade de 26.2 (normal da

indústria é de 16.9)

� Esses resultados dependem da robustez dabiblioteca de componentes


BCC2017







�FCT-UNESP �25/04/2017


BCC2017Técnicas de 4ª Geração

� Concentra-se na capacidade de seespecificar o software a uma máquina em umnível que esteja próximo à linguagem natural

� Engloba um conjunto de ferramentas desoftware que possibilitam que:� O sistema seja especificado em uma linguagem

de alto nível� O código fonte seja gerado automaticamente a

partir dessas especificações


BCC2017

Ferramentas do Ambiente das Técnicas de 4ª Geração

� O ambiente de desenvolvimento de software quesustenta o ciclo de vida de 4ª geração inclui asferramentas:� 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


�FCT-UNESP �25/04/2017


BCC2017Técnicas de 4a Geração

Obtenção dos Requisitos

Estratégia do “Projeto”

Implementação usando 4GL

Testes






Testes

OBTENÇÃO DOS REQUISITOS:

• O cliente descreve os requisitos os quais sãotraduzidos para um protótipo operacional

• O cliente pode estar inseguro quanto aos requisitos

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

• As 4GLs atuais não são sofisticadas suficientemente paraacomodar a verdadeira "linguagem natural"


�FCT-UNESP �25/04/2017






Testes

ESTRATÉGIA DO "PROJETO":

• Para pequenas aplicações é possível mover-se do passode Obtenção dos Requisitos para o passo deImplementação usando uma linguagem de quartageração

• Para grandes projetos é necessário desenvolver umaestratégia de projeto. De outro modo ocorrerão osmesmos problemas encontrados quando se usaabordagem convencional (baixa qualidade)






Testes IMPLEMENTAÇÃO USANDO 4GL:

• Os resultados desejados são representados de modoque haja geração automática de código. Deve existiruma estrutura de dados com informações relevantes eque seja acessível pela 4GL


�FCT-UNESP �25/04/2017






TestesTESTES:

• O desenvolvedor deve efetuar testes e desenvolveruma documentação significativa. O softwaredesenvolvido deve ser construído de maneira que amanutenção possa ser efetuada prontamente


BCC2017

Comentários sobre as Técnicas de 4ª Geração

� PROPONENTES:� Redução dramática no tempo de

desenvolvimento do software (aumento deprodutividade)

� OPONENTES:� As 4GL atuais não são mais fáceis de usar do

que as linguagens de programação� O código fonte produzido é ineficiente� A manutenibilidade de sistemas usando técnicas

4GL ainda é questionável


�FCT-UNESP �25/04/2017


BCC2017

Para escolha de um Modelo de Processo de Software:

� Natureza do projeto e da aplicação

� Métodos e ferramentas a serem usados

� Controles e produtos que precisam serentregues


BCC2017

Software e Engenharia de Software

� A importância do Software

� Software

� Aplicações do Software

� Mitos do Software

� Processo de Software

� Modelos de Processo deDesenvolvimento de Software


Engenharia de Software I - fct.unesp.br · PRESSMAN, R. S. Engenharia de Software, 6 ... Análise...

Documents

Transcript of Engenharia de Software I - fct.unesp.br · PRESSMAN, R. S. Engenharia de Software, 6 ... Análise...