Engenharia de Software
Aula 2Revisão aula anteriorModelos de Desenvolvimento de Software
2
Linha Tempo T.I.Evolução do Hardware
Evolução do Software
Registros Argila
Abaco
Calculadora IBM (1924)
Televisão
Máquina Diferença
Telégrafo
Rádio
Telefone
IBM-CartãoPerfurado
IBM-Máq. Escrever Ele
Prim. Compu. PGM
RAM, CPU
Transistor
Prim. Compu. Com.
Modem
Memória VirtualIBM 360
Chip 8 bitsMonitor
Teclado Calculadora mão
Microprocessador
Impres. LaserImpres. Jato Tinta
Apple
Microsoftt
Compu. < 11kh
IBM PC
CD ROM
Super Compu.
1.2 milhões
transistores
Acesso ráp. www
4.000-1200 ac
www cel.
1935-371941
1947-49
1600-1800 dc
1800-1900
1951
1958-59
1960-61
1962
19671971
1976
1977
1981
1982-84
1985
1bi oper/seg
1989
19952000
Tear controla produção
Lógica x Símbolos
Base Algoritmos CompiladorModem
Transmissão dados7 bits
Data ddmmyy
COBOL Cria Bug Milênio
Processador
Windows 1.0
1937
1949-19511800-1937
1958-59
1959
1963
1968 19721977
1980
1981-83
1985 1986-89
1990-95
Texto
Desenv. Sist.
1975
Desenv. Softw
Anál. Estruturada
Planilha Eletr.
DOS
1 Ger.
BD
COCOMO
AutoCad
TCP/IP
C++
OOCASE
CMM
“Verme”
Modelo Espiral
WWW
UML
http
1 browser
ToyStory
1995-2000
Windows 95/NT
Java
Napster
57tri msg/ano
Office2000
MP3
Bug milênio
Serão estudados em Engenharia de Software
(~5.600 anos)
(~200 anos)
(~100 anos)(~84 anos)
(~84 anos)
Fonte: IEEE Computer Society
Crise do Software
Revisão
3
Hardware
Software
Falhas de hardware no início são inerentes à sua fabricação e no final relativas ao desgaste ambiental das peças (poeira, aquecimento, vibração). Na fase mediana a estabilidade se dá pela facilidade de substituição de uma peça ou outra que apresente falha. Conclusão: é fácil ter estabilidade quando é fácil atuar exatamente no ponto gerador do problema.
Durante a vida do software modificações introduzem novas falhas, se a manutenção desta falha for de difícil acesso¹, o índice de correção é baixo, trazendo novas falhas. . Conclusão: é difícil ter estabilidade quando é difícil atuar exatamente no ponto gerador do problema.
¹ Exemplo de difícil acesso = código macarrônico
Hardware x Software
Revisão
4
Um produto de software novo, ou uma grande manutenção são produzidos
por meio de um projeto. Este, por um determinado período de tempo, se
compromete a construir um produto.
Um projeto é uma função entre Escopo, Recurso e Tempo
P = F (E, R, T)
O que é Engenharia de Software?
O tempo, que deveria ser variável, geralmente se mostra fixo
segundo a necessidade do cliente. Com isto o projeto de
construção ou manutenção se reduz a uma função de Escopo
e Recurso.
Revisão
5
O que é Engenharia?
Engenharia – Processo => Implementa, Realiza
Quando você elabora um produto ou sistema é importante percorrer uma série de passos previsíveis , um roteiro que ajuda a criar a tempo um resultado de qualidade. O roteiro que você segue é chamado de processo de software.
Este processo fornece estabilidade, controle e organização para uma atividade que se for deixada sem controle pode se tornar caótica.
Revisão
6
Processo – Engenharia de Software
O que é Engenharia de Software?
Os engenheiros de software adaptam o processo a suas necessidades e depois seguem.
Um processo de software define a abordagem que é adotada quando o software é elaborado. A engenharia de software inclui tecnologias que constituem um processo, métodos técnicos e ferramentas automatizadas.
A Engenharia de Software é um ramo da Engenharia, que tem
Como foco o desenvolvimento de softwaresdentro de determinados padrões
de custo e qualidade
Revisão
7
O que é Engenharia de Software?
IncrementalCascata RAD Prototipação Espiral
Modelos usados na Engenharia de Software
Modelos
Conjunto de atividades, ações, tarefas, marcos, roteiros e produtos necessários para fazer com
que a Engenharia de Software produza com qualidade.
Revisão
8
Modelos
Para situações em que os requisitos do software são razoavelmente estáveis e lineares. Sugere uma abordagem sistemática e seqüencial.
IncrementalCascata RAD Prototipação Espiral
9
Cascata
10
CascataPontos positivos e negativos
(+)- equipe com foco numa única fase traz qualidade;- fácil colocar preço; - fácil gerenciar projeto;- implementação mais barata.
(-)- modificações podem causar confusão à medida que o
desenvolvimento prossegue;- todos os requisitos têm que ser definidos de uma única vez;- só se tem um executável no final do processo;- ociosidade de profissionais entre as fases.
11
PráticaEstratégia de Implantação
Design• Data Interface Design• Systems Architecture• Test Plan Document
Requirements• Weekly Status Reports (Project
Duration)• Updated Project Plan (Each Phase)
Optimization• Call Detail Record• Tuning Reports• Post Tuning Analysis• Customer Approved
Changes
Deployment• Production Build• Deployment Guide
Testing• QA Builds• QA Testing Results• Installation Guide & Release Notes
Implementation• Code• Usability Study Report
• Test Data Request Document
• Test Cases
• Sample Dialog Document• Persona Design Document• Skeletal UI and Full UI• Codeless Prototyping
• Requirements Specifications Document• High Level Call Flows• Persona Requirements Document
• Account Manager• Project Manager • Vertical SME• UI Lead (Designer) • Technical Lead (Architect)
• QA Lead• QA Testers• Developers• Speech Engineer (Tuning)• Build Manager
Typical Project Team
Kick-off do Projeto: PJ_UCC_11_000001
12
Kick-off do Projeto: PJ_UCC_11_000001
Restrições do Projeto
Escopo limitado aos detalhamentos encontrados na proposta técnica e no documento de visão.
Método de implementação deve ser estritamente seguido, impedindo certas aplicações de paralelismo ou compressão de atividades
Sistema deve ser colocado em produção com alguns meses de antecedência do final do ano de 2012 para que os resultados sejam aferidos ainda neste ano
Prática
13
Modelos
Não é um processo puramente linear. Quando há alguns requisitos definidos, mas ainda há necessidades a serem refinadas, porém há uma necessidade de entregar algum produto ao usuário, ou quando não há equipe suficiente para desenvolver o produto no tempo solicitado.
IncrementalCascata RAD Prototipação Espiral
Combina a sequência linear do modelo em cascata de forma iterativa. Cada sequência linear produz uma entrega ao cliente chamada de iteração.
14
Incremental
15
IncrementalPontos positivos e negativos
(+)- cliente recebe funcionalidades ao longo do projeto;- não é obrigatório (embora seja desejável) que todos os
requisitos estejam definidos no início do projeto;- modificações podem ser bem vindas e melhorar o software;- não há ociosidade de profissionais entre as fases.
(-)- é complexo para colocar preço; - gerenciamento projeto trabalhoso;- implementação pode ficar cara;- novos requisitos podem ser incorporados e mudar planos...
16
ModelosIncrementalCascata RAD Prototipação Espiral
RAD (Rapid Application Development), Desenvolvimento Rápido de Aplicação.
Também é um modelo de software incremental, porém enfatiza um ciclo de desenvolvimento curto. É uma aceleração do modelo em cascata, conseguida à base de utilização de componentes. Comunicação e Planejamento
para entender o que se deseja e coordenar equipes.
Modelagem de Negocio, Dados e Processos. O desenvolvimento reaproveita componentes.
17
RAD - Rapid Application Development
http://www.youtube.com/watch?v=v9-ZA7V7O9I
http://www.google.com.br/search?q=obras+do+niemeyer
18
RADPontos positivos e negativos
(+)- rápida implementação;- baixa probabilidade de erros;- mão de obra barata, preço software mais barato;- pode ser trabalhado em equipes totalmente separadas
(-)- é pouco customizável, ou seja, atende no padrão; - gerenciamento projeto trabalhoso, sem marcos tradicionais;- só vale ser tecnologia for conhecida;- requer profissionais comprometidos, pois equipe tem que
trabalhar num ritmo profundo de sintonia.
19
Utilizado quando os requisitos estão confusos. Auxilia cliente e desenvolvedor a entender o que se deseja do software. Pode ser aplicado a qualquer um dos modelos da Engenharia de Software.
Um protótipo executável é criado rapidamente, utilizando ferramentas de
lay-out e componentes reutilizáveis, mas geralmente não tem a qualidade
que o produto final reprojetado terá e quando cumpre sua função de clarear
os requisitos, é descartado totalmente ou em partes.
ModelosIncrementalCascata RAD Prototipação Espiral
20
Prototipação
http://www.google.com.br/search?hl=pt-BR&q=maquetes
21
PrototipaçãoPontos positivos e negativos
(+)- um dos melhores aliados no entendimento do escopo;- materializa o escopo;- antecipa visualização de problemas;- auxilia nas fases de comunicação de todos os demais
modelos;
(-)- o cliente exige que o protótipo evolua em software definitivo;- desenvolvedor pode se acostumar com baixa qualidade de
desenvolvimento;- requer investimento que não fará parte do software definitivo
22
Modelos
Combina os aspectos controlados e sistemáticos do modelo em cascata com a natureza
iterativa da prototipagem. Possui uma abordagem cíclica para incrementar o nível de
entendimento e implementação ao mesmo tempo que diminui o grau de risco. Além disso
possui marcos para entregas. As primeiras versões entregues podem ser papel, mas as
últimas são completas. São realizados vários circuitos em espiral ao longo da vida do software.
Veja na Web: www.sei.cmu.edu/cbs/spiral2000
IncrementalCascata RAD Prototipação Espiral
23
Espiral
24
Espiral
25
EspiralPontos positivos e negativos
(+)- busca infinitamente a qualidade, busca erro tendendo a zero;- participação de profissionais altamente qualificados;- pode apoiar na produção de softwares altamente complexos;- pode entregar produtos relativos ao ciclo de desenvolvimento
(requisitos, protótipos, codificação...);
- as versões entregues são sempre evoluções das anteriores.
(-)- processo de desenvolvimento pode ser lento;- requer analistas de risco na equipe;- requer investimento de tempo e dinheiro;- requer marcos claros nas entregas;- se não for controlado, pode nunca ter fim.
26
Modelos
Top Related