Engenharia de Software

1. Engenharia de Software Revisão B1

2. Conceitos O que é Hardware ? Parte tangível de um computador, equipamentos, periféricos. Está limitado a espaços físicos com recursos finitos. No ser humano poderia ser comparado ao crânio. O que é Software ? Não é material, intangível, não limitado a espaços físicos ou recursos naturais. Seu potencial é infinito e conseqüente sua complexidade pode se tornar tão elevada, que pode passar a ser difícil de ser compreendido. No ser humano poderia ser comparado com os pensamentos.

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

4. Ciclo de Vida de Sistemas de Software. Ciclo de Vida

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

6. 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. O que é Engenharia de Software? Engenharia de Software

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

8. Com apenas essas duas variáveis o Engenheiro de Software precisa conseguir produzir produtos dentro dos padrões de custo e qualidade. Com menos tempo, como conseguir entregar o mesmo produto com a mesma qualidade e pelo mesmo preço? Procurar não errar. Utilizar processos e métodos já testados por outras pessoas. Reutilizar o que já estiver pronto - “ Os componentes reutilizáveis foram criados para que o Engenheiro possa se preocupar com os elementos realmente inovadores do projeto.” O que é Engenharia de Software?

9. Modelos Modelos usados na Engenharia de Software Cascata Incremental RAD Prototipação Espiral Modelos: conjunto de atividades, ações, tarefas, marcos, roteiros e produtos necessários para fazer com que a Engenharia de Software produza com qualidade. Cada projeto de software pode usar um modelo específico, segundo uma determinada necessidade.

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

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

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

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

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

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

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

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

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

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

20. O que é Engenharia de Software? Princípios Formalidade – O desenvolvimento de software é uma atividade criativa e como tal está muito relacionada à inspiração do momento e toda inspiração vem de uma maneira não estruturada. O princípio da formalidade deve estar presente todas as vezes que for necessário documentar, esquematizar, prototipar, registrar alguma idéia de maneira que ela saia do mundo abstrato e passe a vigorar no mundo concreto Abstração – Habilidade de obter uma visão da realidade diferente da visão do todo, e naturalmente uma visão que em geral é reduzida em relação à visão do todo. Na abstração podem ser ignorados alguns detalhes presentes na visão do todo, mas que não são importantes na visão reduzida que se criou. A visão reduzida é construída segundo um objetivo específico que se queira alcançar num determinado momento do desenvolvimento de um produto. Decomposição – Decomposição é um principio que nos auxilia a lidar com a complexidade. Todas as vezes que nos deparamos com algo muito complexo, a melhor maneira de começar a entender tal complexidade é subdividir o processo complexo em atividades específicas. Tais atividades podem ser atribuídas a profissionais com perfis diferenciados para que cada um possa resolver a complexidade daquele quinhão que lhe foi atribuído. Generalização – Capacidade de projetar um componente que possa ser reutilizado em mais de um ponto do sistema a ser desenvolvido, ao invés de ter várias soluções especializadas. Flexibilização – Capacidade de adaptar o produto ou o processo às várias mudanças que frequentemente acontecem em relação ao ambiente, ao escopo, à equipe envolvida, seja para eliminar erros ou para se adaptar a uma nova realidade.

21. O que é Engenharia de Software?

22. Sistemas sócio técnicos Sistemas baseados em computadores Sistema “Um conjunto de elementos concretos ou abstratos entre os quais se pode estabelecer uma relação” Sistemas de Software Produtos entregues ao usuário, contendo vários artefatos envolvidos na sua produção, tais como documentação, executáveis, estrutura de dados, manuais... Sistemas críticos Confiáveis Disponíveis Seguros

23. Ciclo de Vida de Sistemas de Software. Modelagem Comunicação Planejamento Construção Implantação Operação Desativação

24. Ciclo de Vida de Sistemas de Software. Custo F A L H A Ciclo V I D A Segundo Myers, o custo da correção de um defeito tende a ser cada vez maior tanto mais tarde ele for corrigido.

25. UP - Unified Process Resolveu o dilema de ter que optar pelo melhor modelo para desenvolver. Ele reuniu o que há de bom em cada um dos modelos e criou um processo unificado!  História UP O Processo Unificado nasceu com um trabalho de Jacobson na Ericson, no final de 1960, quando modelaram um sistema muito grande de telecomunicações utilizando um modelo de camadas “em blocos”. Nesse modelo, as camadas inferiores serviam de subsídios para as camadas superiores. Esses blocos podem ser comparados ao que hoje chamamos de componentes. Os blocos de baixo foram construídos e chamados de “casos de tráfego”, hoje chamados de “casos de uso” na UML. Todo o trabalho subseqüente de análise, projeto, implementação, teste e implantação foi realizado com base nesses blocos chamados de “casos de tráfego”. Em 1987 Jacobson deixou a Ericsson e fundou uma empresa chamada Objectory AB, ele e seus colegas despenderam vários anos desenvolvendo um processo e um produto chamado Objectory.

26. UP - Unified Process Conceitos do Processo “O processo de software deve ser, guiado por casos de uso, centrado em arquitetura, iterativo e incremental” (Ivar Jacobson, GradyBooch e James Rumbaugh) Por quê Casos de Uso?Por que a partir desse diagrama serão derivados todos os demais diagramas que irão guiar o desenvolvimento de software Orientado a Objeto. Processo Unificado + UML (UnifiedModelingLanguage) Unified  Unifica em um único processo as melhores práticas de modelagem. Modeling  Modelos = simplificação da realidade para entender aspectos complexos do desenvolvimento de um software. Alguns dos modelos da UML são: Casos de Uso, Classes, Atividades, Estado, Seqüência. Language Linguagem = por definição é algo que deve ser usado para descrever coisas. A Língua Portuguesa é uma linguagem, mas saber falar português não significa ser poeta. Assim como saber construir um diagrama em UML não significa construir um software com uma arquitetura robusta. Por quê Arquitetura? Porque quando se decide construir softwares orientados ao objeto é necessário que o plano arquitetônico seja bem construído e sempre revisado, permitindo que os componentes se harmonizem para produzir um software de qualidade. Por quê Iterativo e Incremental? Porque são os melhores modelos que podem ser usados para entrega de um software em parte e garantir que a cada entrega o software está com mais qualidade.

27. Modelagem Comunicação Implantação Construção Operação Desativação Planejamento UP - Unified Process - Processo Unificado Conceito Processo: conjunto de atividades executadas para transformar um conjunto de requisitos do cliente em um sistema de software. Processo Unificado: Estrutura (framework) genérica de processo que pode ser customizado, adicionando-se ou removendo-se atividades com base nas necessidades e recursos de determinado projeto. Para se usar o Processo Unificado pode-se usar os elementos que agregam valor a um projeto específico e omitir os elementos que não agregam.

28. Fonte: Adaptado de Pressman UP - Unified Process Fases Nas aulas anteriores foi dito que os modelos de desenvolvimento de software contém atividades comuns e que se repetem em todos os modelos são elas Comunicação, Planejamento, Modelagem, Construção, Implantação. Processo Unificado não é exceção a regra das atividades contidas naqueles modelos. Ele também contém todas aquelas atividades, que podemos chamar de atividade genéricas, porém as agrupa em 5 fases do Processo Unificado: CONCEPÇÃO, ELABORAÇÃO, CONSTRUÇÃO, TRANSIÇÃO e PRODUÇÃO.

29. Fonte: Pressman Fonte: Adaptado de Pressman Fonte: RUP RUP – Rational Unified Process

30. Fonte: RUP RUP – Rational Unified Process

31. Dúvidas

32. Engenharia de Software Obrigada! Profa. Maria Lina Buscariolli lina.buscariolli@hotmail.com