A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software Aula 2 Revisão aula anterior Modelos de Desenvolvimento de Software.

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software Aula 2 Revisão aula anterior Modelos de Desenvolvimento de Software."— Transcrição da apresentação:

1 Engenharia de Software Aula 2 Revisão aula anterior Modelos de Desenvolvimento de Software

2 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 Virtual IBM 360 Chip 8 bits Monitor TecladoCalculadora mão Microprocessador Impres. Laser Impres. Jato Tinta Apple Microsoftt Compu. < 11kh IBM PC CD ROM Super Compu. 1.2 milhões transistores Acesso ráp. www ac www cel dc bi oper/seg Tear controla produção Lógica x Símbolos Base Algoritmos Compilador Modem Transmissão dados 7 bits Data ddmmyy COBOLCria Bug Milênio Processador Windows Texto Desenv. Sist Desenv. Softw Anál. Estruturada Planilha Eletr. DOS 1 Ger. BD COCOMO AutoCad TCP/IP C++ OO CASE CMM Verme Modelo Espiral WWW UML http 1 browser ToyStory 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) Fonte: IEEE Computer Society Crise do Software Revisão

3 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 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 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 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 softwares dentro de determinados padrões de custo e qualidade Revisão

7 7 O que é Engenharia de Software? IncrementalCascataRADPrototipaçãoEspiral 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 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. IncrementalCascataRADPrototipaçãoEspiral

9 9 Cascata

10 10 Cascata Pontos 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 11 Prática Estraté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 12 Kick-off do Projeto: PJ_UCC_11_ 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 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. IncrementalCascataRADPrototipaçãoEspiral 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 14 Incremental

15 15 Incremental Pontos 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 16 Modelos IncrementalCascataRADPrototipaçãoEspiral 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 17 RAD - Rapid Application Development

18 18 RAD Pontos 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 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. Modelos IncrementalCascataRADPrototipaçãoEspiral

20 20 Prototipação

21 21 Prototipação Pontos 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 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: IncrementalCascataRADPrototipaçãoEspiral

23 23 Espiral

24 24 Espiral

25 25 Espiral Pontos 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 26 Modelos

27 Engenharia de Software Prof a. Maria Lina Buscariolli Obrigada!


Carregar ppt "Engenharia de Software Aula 2 Revisão aula anterior Modelos de Desenvolvimento de Software."

Apresentações semelhantes


Anúncios Google