Engenharia de Software

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

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

Revisão Hardware x 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

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

O que é Engenharia? Engenharia – Processo => Implementa, Realiza Revisão 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.

Processo – 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 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.

Modelos usados na Engenharia de Software Cascata Incremental RAD Prototipação Espiral Revisão O que é 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.

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.

Cascata

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.

Typical Project Team • QA Lead • QA Testers • Developers • Speech Engineer (Tuning) • Build Manager • Account Manager • Project Manager • Vertical SME • UI Lead (Designer) • Technical Lead (Architect) Prática Kick-off do Projeto: PJ_UCC_11_000001 • Requirements • Weekly Status Reports (Project Duration) • Updated Project Plan (Each Phase) Estratégia de Implantação • Requirements Specifications Document • High Level Call Flows • Persona Requirements Document • Design • Data Interface Design • Systems Architecture • Test Plan Document • Sample Dialog Document • Persona Design Document • Skeletal UI and Full UI • Codeless Prototyping • Implementation • Code • Usability Study Report • Test Data Request Document • Test Cases • Testing • QA Builds • QA Testing Results • Installation Guide & Release Notes • Deployment • Production Build • Deployment Guide • Optimization • Call Detail Record • Tuning Reports • Post Tuning Analysis • Customer Approved Changes

Prática 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

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

Incremental

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...

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

RAD - Rapid Application Development http://www.youtube.com/watch?v=v9-ZA7V7O9I http://www.google.com.br/search?q=obras+do+niemeyer

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.

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

Prototipação http://www.google.com.br/search?hl=pt-BR&q=maquetes

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

Modelos Cascata Incremental 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: www.sei.cmu.edu/cbs/spiral2000

Espiral

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.

Modelos

Engenharia de Software Obrigada! Profa. Maria Lina Buscariollilina.buscariolli@hotmail.com

Engenharia de Software