O documento descreve os principais conceitos de engenharia de software, incluindo: (1) as camadas de engenharia de software focadas em qualidade, processos, métodos e ferramentas; (2) os modelos de processo de desenvolvimento de software como linear seqüencial, prototipação, incremental e espiral; (3) o Rational Unified Process (RUP) como um modelo de processo iterativo e incremental baseado em componentes e casos de uso.

1. Engenharia de Software

2. Tópicos – Engenharia de Software O que é? Camadas Perguntas que devem ser respondidas Fases genéricas da Engenharia de Software Modelos de Processos de Engenharia de Software Modelos de Processos de Desenvolvimento de Software RUP - ( Rational Unified Process )

3. O que é Engenharia de Software? É um conceito que está baseado em camadas: Qualidade: Toda engenharia deve se fundamentar no comprometimento com a qualidade; Processo: É a base da engenharia de software. É o processo que “cola” as ferramentas e os métodos; Métodos: Fornecem a definição do “como fazer” o desenvolvimento de software; Ferramentas: Realizam o suporte automatizado ou semi-automatizado para os processos e métodos (exemplo: ferramentas CASE);

4. Camadas de Engenharia de Software Foco em Qualidade Processos Métodos Ferramentas

5. Perguntas que devem ser respondidas Qual é o problema a ser resolvido? Quais características do software a ser gerado resolvem o problema? Como o software (a solução) serão concebidos? Como o software será construído? Qual a abordagem que será utilizada para cobrir erros feitos no projeto e construção do software? Como o software será mantido a longo prazo, quando correções, adaptações e melhorias forem requeridas por usuários do software?

6. Fases Genéricas da Engenharia de Software

7. Modelos de Processos de Engenharia de Software Para resolver problemas reais, o engenheiro de software deve aplicar uma estratégia de desenvolvimento que contemple as camadas de processos, métodos e ferramentas; Esta estratégia é o modelo de processo ou paradigma de engenharia de software; É escolhido baseado na natureza do projeto e aplicação, nos métodos e ferramentas a serem utilizados e nos controles e entregas requeridos; Os modelos definem ordem para uma atividade inerentemente caótica ;

8. Modelos de Processos de Desenvolvimento de Software Modelo Linear Seqüencial Modelo de Prototipação Modelos Evolucionários - Incremental - Espiral RUP – Rational Unified Process Atividades de suporte : independentes do modelo de processo - Garantia de Qualidade de Software - Gerenciamento da Configuração do Software - Mensuração de Software

9. Modelo Linear Seqüencial Também chamado de “ciclo de vida clássico” e “modelo cascata”; Sugere uma abordagem seqüencial para o desenvolvimento de software; Análise Projeto (Design) Codificação Testes Engenharia do Sistema / Informação

10. Engenharia do sistema/informação: O software é parte de um sistema maior. Por isso, o trabalho inicial com a definição dos elementos do sistema e do software, é realizada uma análise do projeto superficial; Análise: Intensificação do levantamento de requisitos, agora focado no software. Define domínio de informação, funcionalidade, comportamento, performance e interface; Projeto ( design ): Traduz os requerimentos para uma representação técnica; Codificação: É a tradução do projeto em uma linguagem de programação. Se o projeto for detalhado, a codificação é um processo mecânico; Teste: Teste do programa codificado. Pode ser da lógica interna do software ou focado nas funcionalidades externas; Suporte: Corrige e adapta o software gerado. Reaplica as fases precedentes no programa existente. Modelo Linear Seqüencial

11. Modelo Linear Seqüencial É o mais antigo paradigma de engenharia de software; Problemas do modelo linear seqüencial: Projetos reais raramente seguem a ordem seqüencial proposta e mudanças nesta seqüência podem causar confusão na equipe de projeto; É difícil para os usuários definir todos os requisitos explicitamente. O modelo seqüencial requer esta definição e é difícil acomodar incertezas nos requisitos; O cliente deve ter paciência. Uma versão “visível” do programa estará disponível somente no fim do projeto. Erros percebidos somente nesta fase podem ser tornar um desastre;

12. Modelo de Prototipação Permite que o cliente “perceba” o software que está sendo gerado antes da finalização; Atividades do modelo: Definição de requisitos; Projeto “Rápido”: foca em representar os aspectos do software que serão visíveis ao usuário. É a construção de um protótipo ; Avaliação do Protótipo: o usuário avalia o protótipo e refina os requisitos; Natureza iterativa: as atividades se repetem até que o software fique pronto;

13. Modelo de Prototipação

14. Problemas: O cliente vê o que parece ser uma versão que funciona do software. Apesar das grandes mudanças que devem ser feitas para que o protótipo se torne um software completo e com qualidade, o cliente pode querer fazer “remendos” no protótipo para iniciar o uso; Práticas não desejáveis de codificação podem ser utilizadas para construção do protótipo e depois “esquecidas”, tornando-se a solução definitiva; “ Software nunca está pronto”... Modelo de Prototipação

15. A natureza evolucionária do software não é considerada explicitamente nem no modelo linear seqüencial, nem no modelo de prototipação; Os modelos evolucionários são iterativos, ou seja, são caracterizados de maneira que permitem aos engenheiros de software, construções com versões cada vez mais completas do software; Veremos dois tipos de modelos evolucionários: - Incremental - Espiral Modelos Evolucionários

16. O modelo incremental combina elementos do modelo linear seqüencial (aplicado repetidamente) com a filosofia iterativa da prototipação; Cada seqüência linear produz um “incremento” entregável ( deliverable ) do software; Exemplo de um processador de texto: – Primeiro entregar funções básicas de manipulação de arquivo; – Depois, entregar funcionalidades de edição e produção de documentos mais avançadas; – No terceiro incremento, entregar verificação de grafia e gramática; – ... Modelo Incremental

17. A cada incremento, o usuário pode utilizar o produto gerado ou fazer uma revisão detalhada; O próximo incremento deve implementar as solicitações do usuário, mais as novas funcionalidades planejadas; O processo é repetido até que o produto completo é entregue; Modelo Incremental

18. Modelo Incremental O modelo incremental, como o de prototipação, é iterativo. Mas diferentemente do de prototipação, ele foca em entregar um produto operacional em cada incremento;

19. É um modelo que acopla a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo linear seqüencial; O software é desenvolvido em uma série de “ releases ” incrementais: nas primeiras iterações podem apenas ser um modelo em papel ou um protótipo; nas últimas, versões cada vez mais completas do software são produzidas; Modelo Espiral

20. Modelo Espiral O modelo espiral é dividido em um número de atividades, chamadas regiões de tarefas. Tipicamente, existem de 3 a 6 regiões;

21. Comunicação com cliente: tarefas requeridas para estabelecer comunicação efetiva entre desenvolvedor e cliente; Planejamento: tarefas requeridas para definir recursos, tempos de tarefas e outras atividades de planejamento; Análise de Risco: tarefas requeridas para avaliar riscos técnicos e de gerenciamento; Engenharia: tarefas requeridas para construir um ou mais representações da aplicação; Construção e Entrega: tarefas requeridas para construir, testar, instalar, e prover suporte ao usuário; Avaliação do cliente: tarefas requeridas para obter feedback do cliente baseado na avaliação das representações do software criadas durante o estágio de engenharia; Modelo Espiral

22. Cada região possui um conjunto de tarefas, que são adaptadas às características do projeto a ser iniciado. Para pequenos projetos, poucas tarefas. Para grandes projetos, mais tarefas para garantir nível maior de formalidade; Quando o processo inicia, a equipe de desenvolvimento se move na espiral em sentido horário, iniciando no centro: - O primeiro circuito resulta no desenvolvimento da especificação; - O subseqüente, pode ser usado para desenvolvimento do protótipo; - Cada passagem na região de Planejamento resulta em ajustes no plano de projeto (inclusive o número de iterações necessárias para finalizar o projeto); Modelo Espiral

23. Não termina quando o software é entregue: pode ser adaptado a todo o ciclo de vida do software; “ Eixos de Entrada de Projeto”: cada cubo localizado no eixo pode ser utilizado para representar o ponto de início de diferentes tipos de projetos; Modelo Espiral

24. Projeto de Desenvolvimento de Conceito: inicia no centro da espiral e continua na espiral até que esteja completo (área mais escura); Se o conceito será desenvolvido na forma de um produto, o processo continua através do próximo cubo (ponto de entrada de desenvolvimento de novo produto). O novo produto evolui na espiral na área em cinza médio; Em essência, se a espiral for vista dessa forma, ela continua até que o software é retirado de uso; Problemas: - Pode ser difícil convencer os clientes de que a abordagem evolucionária é controlável; - O modelo não é usado na mesma extensão que o linear e o de prototipação, e, por isso, não foi “testado” o suficiente; Modelo Espiral

25. As demandas atuais para softwares poderosos e complexos não têm sido atendidas pela forma como softwares são desenvolvidos. Hoje em dia, muitas pessoas desenvolvem software usando modelos de 25 anos atrás; A comunidade de software precisava de um processo que: - Provesse um guia para a ordem das atividades da equipe do projeto; - Direcionasse as tarefas dos desenvolvedores e da equipe como um todo; - Especificasse quais os artefatos que devem ser desenvolvidos; - Oferecesse critérios para monitoramento e medida dos produtos atividades de um projeto; RUP - ( Rational Unified Process )

26. O RUP é um modelo de processo de desenvolvimento de software (dessa forma, ele descreve um conjunto de atividades para transformar os requisitos do usuários em um software); É baseado em componentes: o sistema de software sendo desenvolvido é feito de componentes de software interconectados via interfaces bem definidas; Utiliza a UML ( Unified Modeling Language ) RUP - ( Rational Unified Process )

27. Direcionado a Caso de Uso: o processo de desenvolvimento segue um fluxo (procede) através de uma série de workflows que derivam dos casos de uso; Centrado em Arquitetura: o processo do RUP ajuda o arquiteto a focar nos objetivos corretos, como entendimento, resiliência a mudanças futuras e reuso. Casos de uso e arquitetura se completam e devem evoluir em paralelo ; Iterativo e incremental: divide o trabalho de engenharia do software em “mini-projetos” ou iterações. Cada iteração resulta em um incremento no produto; Características Fundamentais

28. Em cada iteração, os desenvolvedores identificam e especificam casos de uso relevantes, criam um projeto usando a arquitetura escolhida como um guia, implementam o projeto em componentes e verificam se os componentes satisfazem o caso de uso; Se a iteração atinge seu objetivo, prossegue-se para a próxima iteração. Quando não, os desenvolvedores revisam suas decisões e tentam nova abordagem; Iterações

29. A iteração controlada reduz o custo do risco às despesas de um único incremento, e não do produto pronto; A iteração controlada reduz o risco de não colocar o produto no mercado no tempo esperado, ou seja, os riscos são descobertos antes; Acelera o tempo de desenvolvimento porque trabalha com tarefas mais curtas e focadas; Reconhece uma realidade geralmente ignorada: necessidades dos usuários e requerimentos não podem ser definidos logo no início. São tipicamente refinados em iterações sucessivas. Benefícios das Iterações

30. Segundo o RUP, um produto de software deve ter: Um modelo de casos de uso com todos os casos de uso e seus relacionamentos com usuários; Um modelo de análise que tem dois propósitos: refinar os casos de uso em mais detalhes e fazer uma alocação inicial do comportamento do sistema em uma série de objetos que provêem o comportamento; Um modelo de projeto ( design ) que define: a) a estrutura estática do sistema como subsistemas, classes e interfaces; e b) os casos de usos realizados como colaborações entre os subsistemas, classes e interfaces; Um modelo de implementação , que inclui componentes (representando código fonte), e mapeando as classes para os componentes; Um modelo de implantação ( deployment ), que define os nós físicos dos computadores e os mapeamentos dos componentes para estes nós; Um modelo de testes , que descreve os casos de teste e verifica os casos de uso; E uma representação da arquitetura ; O Produto de Software do RUP

31. O Produto de Software do RUP

32. O processo unificado repete uma série de ciclos que formam a vida de um sistema. Cada ciclo é concluído com uma release (entrega) aos clientes; Cada ciclo consiste de 4 fases: inception (iniciação), elaboration (elaboração), c onstruction (construção), transition (transição) e cada fase é dividida em iterações; O Ciclo de Vida do RUP

33. O Ciclo de Vida do RUP

34. Uma fase termina com um marco ( milestone ), que é definido pela disponibilidade de certos artefatos (modelos ou documentos) em um determinado estado; Dentro de cada fase, são realizadas iterações . Uma iteração é equivalente a um “mini-projeto”; Fases e Iterações do RUP

35. Iniciação : o foco é chegar a um acordo com os stakeholders quanto à visão do sistema e aos objetivos e estimativas das demais fases do ciclo/projeto; Elaboração : esta fase é um processo de engenharia, onde o foco está em especificar uma arquitetura robusta e confiável para o sistema e fazer o planejamento para o restante do ciclo/projeto; Construção : a fase de construção basicamente consiste num processo de manufatura, onde o foco está na construção do sistema e no gerenciamento dos recursos e otimização de tempo, custos e qualidade; Transição : o objetivo desta fase é transferir o produto para a comunidade de usuários. Pode ser apenas uma release do produto, e não o produto final. Fases

36. Fases

37. Os processos são procedimentos compostos de atividades logicamente seqüenciadas e têm objetivos específicos em relação ao projeto; O RUP possui 6 processos de engenharia e 3 processos de suporte, também chamados de disciplinas ; As Disciplinas do RUP

38. Engenharia: – Modelagem de Negócio : foca no entendimento do negócio ser automatizado pelo software; – Requisitos : foca no entendimento dos requisitos do software; – Análise e Design : análise dos requisitos e projeto ( design ) do software; – Implementação : codificação dos componentes; – Teste : avaliação do sistema em relação aos requisitos; – Implantação : entrega do software; Suporte: – Gerenciamento de Projeto ; – Gerenciamento de Configurações e Mudanças ; – Ambiente : preparação do ambiente para desenvolvimento do projeto; As Disciplinas do RUP

39. Quando o projeto amadurece, a ênfase em certas atividades das disciplinas aumenta ou diminui; As atividades podem ser executadas qualquer tempo durante o ciclo de vida do projeto; As Disciplinas do RUP

40. As Disciplinas do RUP

41. As Disciplinas do RUP