Engenharia de Software

Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

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

2 Linha Tempo T.I. Revisão Evolução do Hardware Evolução do Software 2
Registros Argila Máquina Diferença Abaco Telégrafo Memória Virtual 1.2 milhões transistores Apple IBM PC Rádio Prim. Compu. PGM Prim. Compu. Com. IBM 360 www cel. Microprocessador Microsoftt CD ROM Telefone Calculadora IBM (1924) IBM-CartãoPerfurado RAM, CPU Modem Monitor Chip 8 bits Super Compu. Impres. Laser Impres. Jato Tinta Compu. < 11kh Acesso ráp. www 1bi oper/seg Televisão IBM-Máq. Escrever Ele Transistor Teclado Calculadora mão dc 1941 1951 1976 1981 1985 1989 1967 (~200 anos) 2000 1971 1995 1962 1977 ac (~5.600 anos) (~100 anos) (~84 anos) WWW UML http 1 browser ToyStory COCOMO AutoCad TCP/IP C++ OO Evolução do Software Anál. Estruturada Planilha Eletr. DOS Windows 95/NT Java Napster 57tri msg/ano Office2000 MP3 Bug milênio CASE CMM “Verme” Modelo Espiral Tear controla produção Transmissão dados Lógica x Símbolos 7 bits Processador Texto 1 Ger. Modem Data ddmmyy Desenv. Sist. Base Algoritmos Compilador BD Windows 1.0 COBOL Cria Bug Milênio Desenv. Softw 1959 1980 1985 1937 1968 1972 1975 1977 1963 (~84 anos) Fonte: IEEE Computer Society Serão estudados em Engenharia de Software Crise do Software 2

3 Hardware x Software Revisão Hardware Software
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. 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. ¹ Exemplo de difícil acesso = código macarrônico 3

4 Um projeto é uma função entre Escopo, Recurso e Tempo
Revisão O que é Engenharia de Software? 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 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. 4

5 Revisão 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. 5

6 O que é Engenharia de Software?
Revisão O que é Engenharia de Software? 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 Processo – 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. 6

7 O que é Engenharia de Software?
Revisão O que é Engenharia de Software? Incremental Cascata 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. 7

8 Modelos Cascata Incremental RAD Prototipação Espiral Para situações em que os requisitos do software são razoavelmente estáveis e lineares. Sugere uma abordagem sistemática e seqüencial. 8

9 Cascata 9

10 Pontos positivos e negativos
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. 10

11 Kick-off do Projeto: PJ_UCC_11_000001
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

12 Kick-off do Projeto: PJ_UCC_11_000001
Prática 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

13 Modelos Incremental Cascata RAD Prototipação Espiral 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. 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. 13

14 Incremental 14

15 Pontos positivos e negativos
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... 15

16 Modelos Incremental Cascata 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. 16

17 RAD - Rapid Application Development
17

18 Pontos positivos e negativos
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. 18

19 Modelos Incremental Cascata RAD Prototipação Espiral 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. 19

20 Prototipação 20

21 Pontos positivos e negativos
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 21

22 Modelos Incremental Cascata RAD Prototipação Espiral 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: 22

23 Espiral 23

24 Espiral 24

25 Pontos positivos e negativos
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. 25

26 Modelos 26

27 Engenharia de Software
Obrigada! Profa. Maria Lina Buscariolli