Introdução. Eng. de Software x Eng. De Sistemas

Transcrição

1 Introdução Software Programa de computador e documentação associada Produtos de software podem ser desenvolvidos para um cliente particular ou podem ser desenvolvidos para um mercado geral Novos softwares podem ser criados desenvolvendo-se novos programas ou reusando softwares existentes Processo Uma série conectada de ações, com a intenção de satisfazer um objetivo Define quem está fazendo o quê, quando e como para atingir certo objetivo. Processo de Software: Um conjunto estruturado de atividades para desenvolver um sistema de software, que deve envolver obrigatoriamente, pelo menos as seguintes atividades: Especificação Projeto e implementação Validação Evolução Disciplina de engenharia preocupada com todos os aspectos sobre a produção de software, incluindo: Processos: Racionalizam o desenvolvimento de Software Métodos: Conhecimentotécnico; Como fazer Ferramentas: Suporte automatizado para processos e métodos Objetivos: Obter software de qualidade Com produtividade no seu desenvolvimento, operação e manutenção Dentro de custos, prazos e níveis de qualidade controlados Com o melhor custo-benefício entre Qualidade e Produtividade Eng. de Software x Eng. De Sistemas Engenharia de Sistemas é algo maior: preocupa-se com todos os aspectos de sistemas baseados em computador Software Hardware Processos Pessoas e outros sistemas, etc. Engenharia de Software é apenas parte deste processo Questão (TRE/BA CESPE 2010) [61] A engenharia de software está relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que este entrar em operação. A engenharia de sistemas diz respeito aos aspectos do desenvolvimento e da evolução de sistemas complexos, nos quais o software desempenha um papel importante. Gab. C (IBGE CONSULPLAN 2009) [12] Segundo Pressman (1995), Engenharia de Software é o estabelecimento e uso de sólidos princípios

2 de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais, abrangendo um conjunto de três elementos fundamentais (métodos, ferramentas e procedimentos). Assinale a alternativa INCORRETA: A) Métodos de Engenharia de Software proporcionam os detalhes de como fazer para construir o software. B) As ferramentas proporcionam apoio automatizado ou semi-automatizado aos métodos. C) Procedimentos constituem o elo de ligação dos métodos e das ferramentas e possibilitam o desenvolvimento racional e oportuno de software. D) Métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos de software e sistemas, projeto de estrutura de dados, arquitetura de programa e algoritmo de processamento, codificação, teste e manutenção. E) Ferramentas são roteiros para o desenvolvimento de software Gab. E

3 Cascata (Clássico / sequencial linear): Modelos de Ciclo de Vida Recomendado para situações onde há requisitos estáveis e bem compreendidos. É inflexível, sistemático e sequencial É facilmente aplicável em equipes inexperientes Atrasa a resolução dos riscos (falha tardia do projeto) Pressman Sommerville

4 Prototipagem: Evolucionária: Evolui o sistema a partir de uma especificação inicial resumida. Começa com os requisitos mais fáceis e bem compreendidos. Novas funcionalidades são adicionadas à medida que o cliente às propõe. Falta visibilidade do progresso (sempre evoluindo, nunca está terminado). Aplicável em sistemas pequenos ou médios. Descartável: Pequenas versões são disponibilizadas ao clientes para avaliação. Objetivo: clarificar e entender os requisitos do sistema. Começa com os requisitos mais difíceis e menos compreendidos. Descarta-se o protótipo e a implementação continua. Útil para sistemas grandes e complexos, quando o cliente não sabe o que quer. Podem ser aplicados no contexto de qualquer modelo de processo. Métodos Formais: - Modelo baseado em técnicas matemáticas para especificar, desenvolver e verificar software. - O software é especificado usando técnicas formais(matemáticas), e após a prova da especificação é transformado em código. - Tem sido aplicados apenas a desenvolvimento de sistemas críticos (questões de segurança). Iterativos: - Motivação: requisitos de sistema sempre evoluem durante o projeto. - Duas abordagens: Incremental Desenvolver a entrega em incrementos, com cada um entregando parte da funcionalidade requerida. Requisitos são definidos antes do desenvolvimento do incremento, sendo os mais críticos priorizados. Os incrementos são avaliados e os desvios identificados, sendo possível replanejar as próximas iterações de acordo. Espiral Cada volta na espiral representa uma fase no processo Nãoháfasesfixas Inicia de dentro para fora Acrescenta aspectos gerenciais ao desenvolvimento de software Planejamento Análise de riscos OBS: O modelo espiral do ciclo de vida de software é iterativo e incremental, uma vez que a mesma sequência de atividades relacionadas à produção de software é realizada a cada ciclo da espiral. Falso, pois não há garantia de que a sequência de atividades será realizada em cada fase(ciclo), podendo ocorrer até supressões de atividades.

5 ^

6 PROCESSOS ÁGEIS Valores: Indivíduos e interações em vez de processos e ferramentas. Software funcional em vez de documentação extensiva. Colaboração com o cliente em vez de negociação de contrato. Resposta à mudança em vez de seguimento de um plano. Doze princípios do manifesto ágil: Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas ao negócio e os desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Contínua atenção à excelência técnica e bom design, aumenta a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. Vantagens: Entrega acelerada dos serviços ao cliente. Engajamento do usuário com o sistema (envolvimento). Problemas na implantação: Problemas de gerenciamento (mudanças rápidas, documentação, tecnologias não conhecidas). Problemas de contrato (preço fixo?). Problemas de validação (TDD). Problemas de manutenção Desvantagens: Envolvimento com o cliente (cadê ele?). Indisponibilidade do cliente para atuar continuamente no projeto em conjunto com a equipe de desenvolvimento. Membros da equipe podem não interagir bem com outros membros da equipe. Priorização de mudanças pode ser bem difícil, principalmente onde existem muitos Stakeholders. Manter a simplicidade requer trabalho extra.

7 Extreme Programming(XP): Características: Os programadores trabalham em pares. Testes são desenvolvidos antes da escrita do código Pequeno espaço de tempo entre as releases do sistema que apóia assim o desenvolvimento incremental. Envolvimento do cliente apoiado pelo engajamento em tempo integral deste na equipe de desenvolvimento sendo responsável pela definição de teste de aceitação do sistema. Dentro da tríplice restrição ele está focado no escopo. (?) Princípios: Feedback rápido Presumirsimplicidade Mudançasincrementais Abraçarmudanças Trabalho de altaqualidade. Valores: Comunicação. Simplicidade. Feedback. Coragem. Respeito. Práticas: Utilização de metáforas: as funcionalidades do software são descritas em histórias, da forma mais simples possível. Jogo de planejamento. Planejamento incremental: de acordo com a prioridade dos requisitos a serem implementados. Pequenas versões: entregas constantes de pequenos pedaços de software funcionando. Projeto Simples: o código na forma mais simples que atenda todos os testes. Testes de aceitação/cliente on-site: cliente com conhecimento sobre o negócio deve estar disponível em tempo integral, participando ativamente. Ritmo sustentável (trabalho motivado e hora extra quando trouxer vantagens). Posse coletiva (o código não tem dono): qualquer programador pode alterar o código. Programação em pares: validação mútua do trabalho realizado, 2 programadores em 1 computador. Desenvolvimento orientado a testes. (TDD, Test-first): testes unitários escritos antes da funcionalidade ser implementada. Refatoração: melhorar o código sem alterar o comportamento externo. Integração contínua: os módulos são integrados imediatamente após sua conclusão. Padrões de codificação: estilo e formato consistentes. Reuniões em pé: rápidas e diárias para discutir o essencial.

8 Ferramentas: Template de Cartão de História: ator, meta, motivo. Plainning poker: dividir (a história) em tarefas e estimar esforços e recursos necessários. Priorização de histórias para implementação pelos clientes. TDD (Desenvolvimento dirigido por testes) Define interfaces e comportamentos para a funcionalidade (entrada, testes, saídas). Desenvolvimento incremental de teste a partir de cenários. Envolvimento do usuário no desenvolvimento e validação de testes. O uso de ferramentas de teste automatizadas: teste escrito como um componente executável antes do código. Deve possibilitar a entrada e verificar se a saída atende. SCRUM: É um processo iterativo e incremental para o desenvolvimento de produtos e gerenciamento de projetos. Está mais para framework do que para uma metodologia. Ele não te dirá o que fazer, apenas te dará transparência para enfrentar os desafios do dia a dia, a decisão é sua. Método ágil para gerenciamento de projetos baseado em times pequenos (5 a 9 pes.) e auto-organizados. Apresenta forte-visibilidade e rápida adaptação a mudanças (Melhoria contínua). Pilares: Transparência: os aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Inspeção: detecção de variâncias inaceitáveis no processo devem ser inspecionadas e detectadas. Adaptação: aspectos do processo que saírem dos trilhos devem ser ajustados. PAPÉIS: Product Owner (PO): o Faz o Macro Management o Tem total decisão sobre o produto o Responsável por garantir o ROI. o Responsável por garantir as necessidades do cliente. o Proxy de comunicação em ambientes com mais de um cliente. o Precisa ter disponibilidade e não estar dentro do time. Scrum Master (SM): o Responsável por remover os impedimentos do time. o Garante o uso do Scrum. o Protege o time de interferências externas. o Não deve ser PO nem fazer parte do time. Time: o Multidisciplinar. o Auto-organizado. o Dedicação Integral. o Metascompartilhadas. o É quem faz o micro-management.

9 FLUXO: Product Backlog: O Product Owner define a visão do produto. Para tanto ele recolhe informações junto ao cliente, usuários finais, time, gerentes, stk, etc. A visão define o que o PO espera que seja entregue como produto final do projeto e sabe-se que ele foi finalizado quando a visão foi atendida. Definição de Pronto. Escopoaberto. O PO cria uma lista inicial de necessidades (ProductBacklog) com o auxílio do Scrum Master. O ProductBacklog contém os requisitos para o produto que a equipe está desenvolvendo. O PO é o responsável pelo ProductBacklog: conteúdo, disponibilidade e priorização. O ProductBacklog é um documento dinâmico. Nunca está completo. Não existe um padrão para documentação técnica, pode ser UC, Use Stories. Um item do backlog deverá sempre caber em uma sprint. Quanto mais no topo do ProductBacklog, mais prioritária será a necessidade e automaticamente mais detalhada ela estará. Quanto mais no fundo, menos prioritária será a necessidade e automaticamente menos detalhada ela estará. Cartão de Memória Plainning Poker Sprint Planning Meet: Planejamento da Iteração (tempo: 5% da Sprint)- A reunião ocorre dentro do Time Box da Sprint. Definição do Sprint Backlog Primeira metade: define-se o que vai ser realizado no Sprint. Segunda metade: como construir as funcionalidades do produto durante a Sprint (definição do Pronto e Implementado). CaiuemProva!!

10 Sprint Backlog: Lista de tarefas a serem executadas durante a sprint. Deverá estar definida no final da Sprint Plannning Meeting. Iniciará com 70% das atividades definidas. O restante virá diariamente durante a Sprint. Conterá os itens de backlog selecionados, suas respectivas tarefas e as metas da Sprint. Relacionadas a atividades micro (até 8 h). EX: Sprint Burndown: É um gráfico do time, não do PO nem do SM. Tem como objetivo ajudar o time no micro-management. O gráfico só evolui quando o item está efetivamente pronto. Auxilia na mediação da velocidade da equipe por sprint. Sprint: Ocorre em um período de 30 dias aproximadamente O tempo de duração inclui o planejamento e a revisão. O SM facilita o trabalho do time removendo os impedimentos encontrados e garantindo a boa aplicação do Scrum. O time pode consultar especialistas ou o PO. Daily Meeting/Scrums (Reunião Diária): Duração de 15 minutos (O que fiz? O que fazer? Qual impedimento?) Visibilidade da situação atual dentro do planejamento. SM comofacilitador. Micro- Management. Reunião para o time. Inclusão/exclusão de tarefas para cumprir a meta da Sprint. Inserção de impedimentos (relacionados às tarefas já previstas)

11 Sprint Review (Reunião de Revisão da Sprint) Realizada ao final do Sprint (4h p/ sprints de 1 mês) Identifica o que foi feito, problemas encontrados e soluções. O time demonstra o que foi feito e responde a questionamentos. O PO discute o ProductBacklog atual. Todos discutem melhorias que poderão ser implementadas (melhoria do produto). Retrospectiva: Foco na inspeção-adaptação (duração: 3h). O time é encorajado a revisar o processo de trabalho (melhoria do processo). Finalidade: inspecionar o último sprint (aspectos: pessoas, relacionamentos, processos e ferramentas). Identificação de melhorias para as próximas sprints. Stories, Temas e Epics: Epics são grandes user stories, que ainda estão em formato bruto. Temas são pacotes de user stories (decompostos ou não) relacionadas por algum grande objetivo de negócio. (= package de um caso de uso) Uma release pode ter 1 ou mais temas. No planning poker passou de 40 é um Epic. Sprints x Release: Sprint: entrega um incremento do produto. Release: entrega de um produto que entrará em produção. P.S: Uma release pode conter várias sprints. Mudanças Durante a Sprint: As mudanças ocorrem desde que não atrapalhem a meta das Sprint. Time-box é fixo. Mudanças não impactam o timer da sprint.

12 Feature Driven Development (FDD): Características: Focada na entrega regular de funcionalidades valiosas para o cliente. Que possam ser entregues em até 2 semanas. Equipes podem variar de 10 a 250 programadores. Nãonecessita de tantadocumentação Papéis: Existem papéis chave e papéis de apoio, abaixo seguem os papéis chave: Project Manager Líderadministrativo do projeto Planeja orçamento, elabora relatórios e protege a equipe de distrações externas. Chief Architect Responsável pelo projeto geral do sistema Tem a palavra técnica final sobre o software e sua arquitetura Development Manager Lidera as atividades diárias de desenvolvimento Lidera a equipe de desenvolvimento através de desafios técnicos Chief Programmers Desenvolvedoresexperientes Lideram pequenas equipes de desenvolvedores individuais Class Owners São os desenvolvedores individuais Projetam, codificam, testam e documentam as funcionalidades Domain Experts Usuários, clientes, patrocinadores... A base de conhecimento para os desenvolvedores Processos: Desenvolver um modelo abrangente (geral) Construirumalista de funcionalidades Planejarporfuncionalidade Projetar (detalhar) porfuncionalidade Implementarporfuncionalidade

13 Benefícios: Qualidade de software Maiorprodutividade Maiorprevisibilidade Maior controle sobre custos e prazos

14 Ferramentas CASE - São ferramentas que auxiliam o engenheiro de swnas atividades associadas ao desenvolvimento de sw. - Utilizada por Gerentes de projeto e engenheiros de sw. - Reduzem o esforço necessário para produzir artefatos e alcançar metas - Aumentam a qualidade do sw. -Ferramentas CASE são usadas em conjunto com o modelo de processo adotado. Se for escolhida uma ferramenta completa, pode passar por quase todos os passos do desenvolvimento de SW. - São usadas como complemento às boas práticas de Engenharia de Software. Ferramentas CASE não substituem uma metodologia de desenvolvimento de software sólida. Categorização: Terminologia I: Horizontais: são utilizados durante todo o processo de des. de soft. Verticais: são específicas para uma disciplina de soft. Por funções: processos de negócio, análise de risco... Terminologia II: Front-end ou Upper CASE: apoiam etapas iniciais da criação dos sistemas; planejamento, análise e projeto de aplicação. Back-end ou Lower CASE: dão apoio à parte física, código, testes e manutenção. I-CASE ou Integrated CASE: cobrem todo o ciclo de vida do início ao fim.

15 RUP Características: Iterativo e Incremental: O ciclo de vida do produto é dividido em iterações, cada uma entregando incrementos/releases (partes acabadas) do software. Guiado por casos de uso: Os casos de uso conectam todas as fases e visões, sendo utilizados por todos os stakeholders. Centrado na arquitetura: Evolui a partir das necessidades do produto. Orientado a objetos: Componentes são construídos através de Objetos e estes colaboram entre si para realizar os casos de uso. Planejado por riscos: Os riscos são analisados continuamente e os de maior criticidade são tratados prioritariamente. - O RUP tem duas dimensões: A primeira dimensão representa o aspecto dinâmico do processo (Eixo horizontal) Expresso em termos de fases, marcos e iterações A segunda dimensão representa o aspecto estático do processo (Eixo vertical) Expresso em termos de componentes, disciplinas, atividades, artefatos, papéis Perspectivas: Dinâmica: são as fases do modelo. o Concepção: estabelecer um business case para o sistema (escopo). o Elaboração: domínio do problema, identificar os riscos do projeto, elaborar um plano de projeto. o Construção: projeto, programação e teste de sistema. o Transição: implantação. Fase onerosa e problemática. Estática: são as disciplnas, fluxos ou workflows. PRINCIPAIS (realizadas no projeto)

16 Modelagem de negócios Requisitos Análise e projeto Implementação Teste Implantação AUXILIARES (acompanham o projeto) Gerenciamento de configuração e mudança Gerenciamento de Projeto Ambiente Disciplinas (MRAITIGGA) São um conjunto de atividades (fluxo de trabalho) relacionadas a uma área de interesse do projeto Ajudam a compreender o projeto a partir de uma perspectiva em cascata OBS: teste unitário está incluso na disciplina de implementação. Obs: Cada passagem pela sequência de disciplinas do projeto se chama iteração, não passando obrigatoriamente por todas.

17 Critérios de Avaliação dos Marcos: Objetivos do ciclo de vida: Casos de uso definem claramente o escopo? Foi possível fazer um protótipo da arquitetura? Todos os riscos críticos foram encontrados? Forammitigados? Há condições de realizar o projeto? Arquitetura do ciclo de vida: Baseline A arquitetura é estável e robusta, comportando requisitos atuais e futuros? Riscoscríticosforamresolvidos? Cronograma, orçamento e níveis de qualidade estão bem definidos? Devemosfechar o contrato? Capacidade operacionalinicial: O produto está estável para ser implantado? O resultado está coerente com o planejado? Os envolvidos estão prontos para a Transição? Release do produto: As despesas reais com recursos são aceitáveis se comparadas às planejadas? O usuárioestásatisfeito? - Papéis executam Atividades que geram Artefatos.

18 Práticas: boas práticas durante o processo. Desenvolver o software iterativamente. As táticas e os requisitos variáveis são acomodados Os riscos são reduzidos mais cedo, pois os elementos são integrados progressivamente. A melhoria e o refinamento do produto são facilitados, tornando-o mais robusto. As organizações podem aprender a partir dessa abordagem e melhorar seus processos. Identificar partes comuns quando estão parcialmente projetadas ou implementadas é mais fácil que identificar todas as semelhanças no começo. Gerenciar Requisitos (documentação e mudanças). Requisitossãoalterados. Entenda as necessidades das partes interessadas. Defina o sistema e seu escopo. Garanta que os requisitos sejam facilmente atualizáveis. Casos de uso guiam o desenvolvimento Arquiteturabaseadaemcomponentes. Grupos coesos de código fonte ou executável com interfaces e comportamentos bem definidos.(substituíveis) Permitereusoemgrandeescala Visões Arquiteturais(4+1): De casos de uso (externa) Queabrangemcomportamentossignificativos Visão obrigatória do documento de arq. de soft. Lógica (interna) Classes de projetos mais importantes e sua organização Visãoobrigatória De processos Descreve as tarefas envolvidas e suas interações Só precisa ser utilizada quando em alto grau de paralelismo Visãoopcional De implementação Detalhes(físicos) dos pacotes e módulos da visão lógica Visãoopcional De implantação Descrição dos vários nós físicos do sistema e suas tarefas. Visãoopcional Modelar Visualmente(UML). Notação gráfica e visual para capturar o projeto de software Capturarrequisitos com precisão Melhorcomunicação, diminuindo a ambiguidade Verificar a qualidade do software. Foco nos processos e como eles são executados (garantia) Foco no produto, em encontrar defeitos específicos (controle) Controlar as mudanças (SGM). Apenasmudançasaprovadassãoimplementadas Coordenação de atividades e artefatos Coordenação de iterações e releases Controle de mudanças no software OBS: No RUP a qualidade representa a característica de ter demonstrado a realização da criação de um produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critérios acordados, e que é criado em um processo acordado

19 FASES do RUP INICIAÇÃO(Concepção): Compensa/é possível realizar o projeto? Meta principal: atingir o consenso sobre os objetivos do ciclo de vida do projeto. Escopo Custos Tempo (cronograma) Riscos Identificarcasos de usocríticos Propor pelo menos uma opção de arquitetura para cenários básicos. Ênfases: Modelagem de Negócios: Entender a estrutura e a dinâmica da organização-alvo Analista de Processo de Negócios: Identificaosprocessosnaorganização Descreveosprocessos Definir o que pode e deve ser melhorado Artefatos: Modelo de Domínio: captura os tipos mais importantes de objetos de negócio. Modelos de negócio subsidiam os requisitos de sistema Entidades de negócio identificam classes de entidade Requisitos: Estabelecer o que o sistema deve fazer Definir o escopo do sistema Analista de Requisitos Levantarrequisitos do sistema Estruturar modelo de Casos de Uso Especificador de Requisitos Detalhar especificação de Casos de Uso Artefatos: Visão o Documento da visão em alto nível do produto a ser desenvolvido. o Contém as necessidades e características mais importantes. Glossário o Modelo de Casos de Uso: serve como contrato entre cliente e desenvolvedores.

20 ELABORAÇÃO: Fornecer uma base estável para o esforço de Construção Arquitetura é desenvolvida a partir dos requisitos que tem maior impacto na arquitetura. Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto. Selecionar componentes(reuso) e criar planos de iterações detalhados para a fase de construção. Artefatos: Protótipos: reduzir o risco e elicitar requisitos significativos Doc. de Arquit. de Soft.: visão geral, usando diversas visões para descrever diferentes aspectos do sistema. Modelo de projeto: descreve a realização dos casos de uso críticos. Modelo de dados: descreve a representação física e lógica dos dados persistentes no sistema. Ênfases: Análise e Design/projeto: Transformar os requisitos em projeto a ser criado Desenvolver uma arquitetura refinada (estabilizada) Adaptar o projeto às restrições de tecnologia Arquiteto de Software Projetararquitetura, visãoampla. Designer(projetista) Analisar e projetar casos de uso Projetarsubsistemas Projetista de Banco de Dados Projetar base de dados Implementa as funcionalidadescríticas OBS: Segundo o manual RUP, as atividades de Análise são opcionais. Apesar de na prática não ser muito interessante pular essas atividades. CONSTRUÇÃO: Esclarecerosrequisitosrestantes Concluir o desenvolvimento com base na arquitetura estável Gerenciamento de recursos e controle de operações para maior produtividade e qualidade. Otimizarrecursos e evitarretrabalho Definir se o software está pronto para ser implantado Artefatos: Sistema: pronto para iniciar os testes Beta. Plano de Implantação: versão inicial desenvolvida, analisada e com baseline. Conjunto de testes: testes implementados e executados para validar a estabilidade dos releases. Modelo de projetocompleto OBS: testes Alfa são executados na fase de construção, já os testes Beta são realizados na fase de transição. Ênfases: Implementação: Definir o código em subsistemas e camadas Implementar classes e objetos em termos de componentes Realizar testes unitários Integra os componentes individuais ao sistema executável. Implementador (II e III) Integrador (IV) Implementa o que foi definido na disciplina de Análise e Design

21 Teste: Localizar e documentar defeitos na qualidade do software Validar as funções do software conforme projetadas Verificar se os requisitos foram implementados de forma adequada Analista de teste: elaborar plano de testes. Projetista de teste: projetar testes (a partir dos casos de uso). Testador: implementar e executar testes. Plano de testes: Define metas e objetivos dos testes no escopo da iteração (ou projeto) Explicita a abordagem adotada, os recursos necessários e os produtos liberados. Caso de teste: Descrição do objetivo e do escopo do teste É desenvolvido caso de teste para cada cenário do caso de uso, prevendo caminhos para o fluxo básico, alternativo e de exceção. Define: o Entradas de teste o Condições de execução o Resultadosesperados OBS: testes unitários são executados na disciplina de implementação, e não na disciplina de teste. TRANSIÇÃO: Disponibilizar o software aos usuários finais Testar os releases e ajustar pequenos defeitos com base no feedback do usuário Feedback prioriza apenas ajustes finos, todos os problemas estruturais já devem ter sido trabalhados anteriormente. Teste Beta para validar o novo sistema Treinamento de usuários e equipe de manutenção Artefatos: Notas de Release Artefatos de instalação Material de treinamento Ênfase: Implantação: Coordenar e gerenciar os testes Beta e de aceitação Desenvolver artefatos de instalação e materiais de treinamento

22 Liberar para fabricação Tipos de Instalação: Personalizada/customizada Compacta (cd, dvd) Internet Gerente de implantação Desenvolverplano de implantação Escrevernotas de releases Desenvolvedor do curso Desenvolvermateriais de treinamento Implementador Desenvolverartefatos de instalação Gerenciamento de configuração e mudança: Disciplinas Auxiliares Controla as mudanças feitas nos artefatos de um projeto e mantém a integridade entre eles Identificar e controlar itens de configuração Restringir as mudanças nesses itens e auditá-las Trilha de auditoria indicando a razão, por quem e quando um artefato foi alterado Gerente de Configuração Configurar ambiente de CM Estabelecer políticas de CM Garantir a integridade dos artefatos Gerente de Mudanças Estabelecer processo de controle de mudanças Confirmar ou recusar solicitações de mudança Artefatos: Repositório do projeto Solicitações de mudanças Gerenciamento de Projeto: Gerenciar pessoas, equipes, fases e iterações. Planejar o cronograma do projeto Gerenciar a qualidade e realizar revisões Gerenciar os riscos Artefatos: Plano de desenvolvimento de software Planos de iteração Lista de riscos Ambiente: Oferecer o ambiente de que dará suporte à equipe de desenvolvimento. Configurar/ajustar o processo para o projeto Selecionar e adquirir as ferramentas que serão utilizadas Desenvolver/adaptar guias de atividades Engenheiro de processo Configurar o processo Iniciar caso de desenvolvimento Especialista em ferramentas Selecionar, adquirir e configurar ferramentas Artefato:Caso de desenvolvimento Descreve o processo escolhido para ser seguido no projeto É o documento que configura o próprio processo de desenvolvimento

23 Requisitos de Software Requisitos: definem o que o sistema deve fazer e sob quais limitações ele é requisitado a operar. - O sucesso das etapas posteriores depende da qualidade dos requisitos gerados. Tipos de Requisitos: No desenvolvimento Funcionais: definem as funcionalidades do sistema, é o que ele deve fazer. Depende dos usuários e do contexto de utilização. Não Funcionais: são qualidades, atributos, restrições, características do sistema.possuemrelação com as funcionalidades do sistema. Do produto: eficiência, confiabilidade, usabilidade, portabilidade. Organizacionais: obedecem a políticas, padrões, processos. Externos: legislação, interoperabilidade, privacidade De domínio: refletem características do domínio, são transformados posteriormente em funcionais ou não funcionais. São expressos na linguagem do domínio da aplicação. Conhecimentotácito Na evolução e manutenção Permanentes: relativamente estáveis, pois são derivados da atividade principal da organização. Voláteis: Mutáveis: são modificados por conta do ambiente do sistema. Emergentes: surgem durante o desenvolvimento à medida que o cliente compreende o sistema. Consequentes: resultam da introdução do sistema no ambiente do usuário. Compatibilidade: que dependem de outro processo, mudam conforme o outro muda. OBS: Requisitos não funcionais devem ser verificáveis(mensuráveis) de forma objetivamente testada. Elicitação e Análise de Requisitos: Entendimento do domínio da aplicação Descoberta/levantamento dos requisitos OBS: JAD- Técnica de elicitação de requisitos.(ibm) - ler sobre

24 Técnicas de Elicitação: Entrevistas Questionários Leituras de documentos Observações e análises sociais (etnografia): Fatores organizacionais importantes podem ser observados Analisar como as pessoastrabalham Requisitos são derivados da cooperação e compreensão das atividades. Workshops de requisitos Stakeholders são reunidos por um período intensivo Reunir informações para atributos de requisitos aplicáveis Resumir a sessão e elaborar conclusões Prototipagem Cenários (casos de uso) Utilizados para mostrar quais funcionalidades o sistema oferece e que usuários se comunicam com ele. Atores são sempre entidades externas ao ambiente do sistema. Tipos:. Concreto: iniciado por um ator, constitui um fluxo completo de eventos.. Abstrato: nunca são instanciados diretamente, são includes, extends ou generalizações de um caso de uso concreto. São escritosemitálico. Relacionamentos: Include: após um caso de uso base a inclusão de outro caso de uso é obrigatória. Extend: modela partes opcionais da execução de um caso de uso. Generalização: relaciona um caso de uso especializado a um mais geral.

25 Modelo de Caso de Uso: comunica o comportamento do sistema ao usuário final. Análise de Requisitos: Agrupar requisitos relacionados e organizá-los em conjuntos coerentes Checagem de consistência, ambigüidade, omissão e relacionamentos entre requisitos. Priorizar requisitos e negociar conflitos É papel do analista de requisitos balancear todas as demandas Requer grande capacidade de integração social Especificação de Requisitos: A abordagem utilizada depende da necessidade específica de cada projeto Podeabordar: Documento escrito Modelo gráfico Modelo matemático formal Coleção de cenários de uso Especificação do Sistema: É o produto final produzido pelo engenheiro de requisitos Descreve a função do sistema e suas restrições Descreve informações que entram e saem do sistema Validação de Requisitos: Objetivos: Assegurar que... Os requisitos definem o sistema que o usuário realmente deseja Requisitos são consistentes e de alta qualidade Documento de requisitos provê uma base adequada para Projeto e Implementação Aprovar o Documento de Requisitos Técnicas: Revisões(inspeções) Prototipagem Geração de Casos de teste Gerenciamento de Requisitos: A preocupação é manter os requisitos e controlar suas evoluções. Gerencia as mudanças nos requisitos. Requisitos sempre mudam! Rastreabilidade: relacionam os requisitos e avaliam seus impactos De fonte: liga o requisito a quem propôs, e sua necessidade original. De Requisitos: liga os requisitos que dependem entre si. De projeto: ligação entre o requisito e o projeto do software. É impossível rastrear requisitos sem uma ferramenta CASE adequada.

26 Análise e Projeto OO Análise OO: Gerar um primeiro modelo do sistema a partir dos casos de uso (Modelo de Análise/Domínio) Entender o problema a ser tratado antes de partir para a solução. Estruturando por classes e objetos. Escrita na linguagem dos desenvolvedores. Encontrar os objetos que vão compor o software, suas funções, dados e relacionamentos. Não depende de tecnologia Segundo o RUP, é atividade opcional. Modelo de Análise/Domínio: Modelo de objetos que descreve a realização dos casos de uso, é uma abstração do Modelo de Design. Contém as classes e qualquer artefato associado. O modelo evolui durante as iterações do projeto, incrementando detalhes às classes. Desenhar diagramas de classes conceituais Identificar persistência Classes de Fronteira: fazem a interação Ator x Sistema. Apresentam dados aosusuários. Classes de Controle: controlam a lógica de execução correspondente a cada caso de uso. Classes de Entidade: representam a informação que é manipulada pelo caso de uso. Armazenam informações persistentes. Contém as regras de negócio. Identificar responsabilidades: qual operação é fornecida por cada classe. Identificar atributos: sem identificar o tipo. Identificar relacionamentos: associações, dependências. Projeto OO: Criamos o Modelo de Projeto, no qual definimos como o software atenderá os requisitos analisados. Dependente da tecnologia a ser utilizada na implementação. Unificar os modelos de caso de uso em um modelo único, mais detalhado. Projetar detalhadamente a estrutura e o comportamento interno de cada subsistema (módulo). Projetar a arquitetura, em camadas. Tipos de Herança: Simples: novas classes são criadas a partir de uma classe existente. Múltipla: uma classe pode herdar de várias outras classes. Deve ser evitada. Pois pode causar vários problemas: Difícil de entender Codificaçãoconfusa Ambiguidade e duplicação de atributos Algumas linguagens(java e Smalltalk) não suportam herança múltipla Tipos de generalização: Incompleta: outros subtipos(objetos) podem ser adicionados no futuro Completa: todas as subclasses já foram especificadas. Disjunta(disjoint): não pode ocorrer herança múltipla Sobreposta(Overlapping): pode ocorrer herança múltipla

27 Classe Abstrata: Representa um conceito abstrato e é utilizada para organizar uma hierarquia de generalização Não é projetada para gerar instâncias. O nome estará sempre em Itálico A superclasse será herdada por outras, e estas é que gerarão instâncias concretas. Caso exista um método abstrato, a classe precisará ser abstrata, mas o contrário não pode se afirmado. Se a classe é abstrata, não obrigatoriamente eu preciso ter um método abstrato. Interface: Define um conjunto de comportamentos(operações) oferecidos para uma classe ou componente. Pode ser interpretada como um contrato de comportamento entre um objeto cliente e o fornecedor de serviços. É dito que classes realizam interfaces. Arquitetura do Sistema: é a estrutura dos componentes significativos do sistema que interagem por meio de interfaces. Composição: Componentes de software Propriedades visíveis externamente Relacionamento entre componentes OBS: Uma boa arquitetura deve ter componentes projetados com baixo acoplamento e alta coesão. Acoplamento: Grau de dependência de um módulo em relação aos demais. Acoplamento forte significa que uma classe precisa conhecer detalhes internos das outras. Quanto menos acoplamento melhor. Menor complexidade. Coesão: é o grau de entendimento das responsabilidades de um determinado módulo/classe. Queremos classes: Com menor complexidade possível Com responsabilidades claramente definidas Que não executam um grande volume de trabalho

28 Arquitetura em Camadas: Cada camada provê um conjunto de funcionalidades em determinado nível de abstração Camadas de mais alta abstração dependem das de mais baixa abstração Vantagens: Separação de responsabilidades Decomposição de complexidade Maiorreuso e extensibilidade Desvantagens: Pode penalizar o desempenho do sistema Aumento do esforço e complexidade de desenvolvimento Padrões: Arquitetura em 3 camadas(clássica): Camada de apresentação: entrada e saída de dados Camada da lógica do negócio: processa comandos, faz avaliações e implementa regras de negócio. Camada de acesso a dados: contém o código responsável por armazenar e recuperar dados de uma base de dados. Normalmente há uma interface(sub-camada) dentro dessa camada, o DAO (Data Acess Objetct), que abstrai o mecanismo de persistência, facilitando a integração de múltiplas fontes de dados. Model-View-Controller (MVC): View (Visão): É a camada de interface com o usuário. Entrada e saída de dados, apresenta os resultados. Pode requerer dados diretamente da camada Modelo Controle: Atualiza o modelo Seleciona a visão Controla e mapeia as ações do usuário Modelo: Modela os dados e o comportamento por trás das regras de negócio Armazena, manipula e gera os dados

29 Observações: Nem toda comunicação passa pelo controlador A visão despacha atualizações para o controlador O controlador atualiza o modelo A visão é atualizada diretamente pelo Modelo Arquitetura MVC na WEB(Model 2) Prova: A camada Controller geralmente possui um componente controlador padrão criado para atender a todas as requisições do cliente. Arquitetura WEB: Browser utilizadocomocliente universal Camadas de 3 a N Em projetos simples podemos ter as camadas WEB e Aplicação no mesmo local. Quanto mais camadas, maior a flexibilidade. A lógica de negócio fica no servidor de aplicação. N Camadas

30 Testes e Qualidade de Software Tipos de Manutenção: Corretiva: posterior ao encontro dos erros na verificação/validação. Adaptativa: para adaptar-se a mudanças externas. Melhoria (Perfectiva): para atender a requisições posteriores. Preventiva (reengenharia): abordagem pró-ativa, foco na melhoria contínua. Falta: Causa de uma falha, é o defeito / causa raiz. Erro: instabilidade causada ao tentar processar determinada informação, estado intermediário. Falha: incapacidade do software de realizar a função requisitada, fato observável. Prevenção de Faltas: Especificaçãorigorosa Proteção de hardware Ambientes e linguagensapropriados Tolerância a Falhas: Replicação/Redundância Isolamento do componentefaltoso Hot swapping Verificação: Garantir que o software implementa as funções especificadas. Corretaconstrução do produto. Verificações estáticas (inspeções) Verificações dinâmicas (testes). Foco mais interno. Inspeção de Software: Análise estática dos artefatos do sistema Checa a conformidade com as funções especificadas Não checa requisitos não funcionais (desempenho, usabilidade) Podem ser aplicadas a qualquer artefato do sistema Podem ser aplicadas antes da implementação, pois não precisam da execução do sistema. Erros são apenas detectados e nunca corrigidos durante a inspeção Podem ser manuais e com auxílio de ferramentas CASE Padrões organizacionais devem ser bem definidos As equipes devem ser bem informadas e ter acesso a especificações precisas

31 OBS: Walkthroughs são inspeções informais, rápidas que podem ocorrer a qualquer momento no desenvolvimento, exigindo uma menor formalidade. Validação: Garantir que o software atende às reais necessidades do cliente. Construção do produtocerto. Homologação Testes de aceitação (Beta). Foco mais externo, no cliente. Testes: O objetivo é encontrar erros. Ocorre sucesso quando encontra um erro não conhecido. Não garante que está livre de erros, apenas mostra os erros presentes. Devem ser planejados muito antes da execução, com base nos casos de uso. Aplica-se o princípio de Pareto, pois testes exaustivos são impossíveis. Preferencialmente conduzidos por terceiros. Abordagens: Caixa preta(funcional): foca nas entradas e saídas especificadas. Técnicas: Grafos: Toda aplicação é constituída por objetos Todos eles são identificados e representados em um grafo. Os relacionamentos definidos são utilizados para descobrir comportamentos inesperados. Particionamento de equivalências: As entradas utilizadas são organizadas em classes de dados, válidas e inválidas. Casos de teste são gerados através dessas classes. Análise de valoreslimítrofes: Os testes devem ser gerados com valores limítrofes, pois é sabido que a maioria dos erros ocorre nos limites do domínio. Utilizada em conjunto com o partic. de equiv. MatrizOrtogonal:??? Caixa Branca(estrutural): foca nas estruturas internas dos procedimentos do sistema. Testes são gerados a partir de uma análise dos caminhos lógicos possíveis de serem executados. Objetivos: Garantir que todos os caminhos sejam executados pelo menos uma vez. Realizar as decisões lógicas para valores falsos e verdadeiros Executar laços dentro dos valores limites Avaliar as estruturas de dados internas Técnicas: Testes de caminhos Testes de estruturas de controle (if, while...) Complexidade ciclomática: nos dá uma idéia do limite superior de caminhos necessários. Caixa cinza(mista): são testes que utilizam algum conhecimento sobre a estrutura interna.

32 Estágios(estratégias): Teste de Unidade(unitáro): Os componentes individuais são testados para assegurar sua operação individualmente. Componentes precisam possuir a estrutura interna bem conhecida Ferramenta mais utilizada: JUnit (Java) Pesquisar depois de ver Java Teste de Integração: Sistemas devem ser integrados gradualmente(boa prática) Top-down: desenvolve o esqueleto do sistema e o preenche com os componentes Bottom-up: integra os componentes de infraestrutura e depois adiciona componentes funcionais. Exemplos: Teste de Regressão: Execução de baterias de testes já executadas antes, toda vez que um módulo é adicionado ao sistema. Garantir que os módulos anteriores não quebraram com a inserção do novo. Teste de Fumaça(smoketest): Aplicado após cada montagem do produto(build) para verificar funcionalidades básicas. Normalmente é o primeiro teste realizado depois de integrar os componentes. Testes de Aceitação(validação): São realizados após os testes de integração Finalidade de demonstrar a conformidade com os requisitos de software Ambiente deve ser o mais próximo possível do ambiente real. Teste Alfa: Testes conduzidos pelo cliente, nas instalações do desenvolvedor(ambiente controlado) Desenvolvedor toma nota dos erros e problemas que ocorrem Teste Beta: Conduzido pelo usuário final, ocorre no ambiente real/de produção. O usuário anota os problemas e reporta ao desenvolvedor Teste de Sistema:. Conduzidos em um ambiente completo e integrado, por várias pessoas.. Considera hardware, pessoas, processos, informações e outros sistemas.

33 Exemplos: Teste de Recuperação: Força o software a falhar de várias formas e verifica a adequada recuperação. Recuperação pode ser automática ou manual. Teste de Segurança: Tentativas de penetrar no sistema, até penetrar. O papel do desenvolvedor é assegurar que isto custe mais caro que os ganhos com a invasão bem sucedida. Teste de Carga(estresse): Visam confrontar programas com situações anormais, de caráter destrutivo, para saber até onde ele aguenta. Pode estressar memória, disco, processamento etc. Teste de Desempenho: Visa garantir que o sistema atenda os níveis de desempenho e tempo acordados. Pode ocorrer durante todos os estágios de testes. Teste de Usabilidade: Avalia a facilidade de uso pelo usuário. Qual a diferença de teste beta x teste de sistema? OBS: Verificação e validação podem utilizar as mesmas técnicas, o que muda é apenas o foco, se para checar problemas com especificações ou se é para checar o atendimento ao propósito do cliente. Debugging - É o processo que resulta na remoção de um erro encontrado. - Envolve formular hipóteses sobre o comportamento do sistema e testar essa hipótese para achar os erros. Tipos: Força Bruta:espalha no sistema escritas de identificação, mapeando a execução do sistema Backtracking: rastreia-se manualmente a partir de onde o erro ocorreu até sua fonte. Eliminação de causa: elabora-se uma hipótese de causa, e os dados do erro são utilizados para provar a hipótese.

34 Questões - A metodologia de prototipagem evolutiva é uma abordagem que visualiza o desenvolvimento de concepções do sistema conforme o andamento do projeto, por meio de protótipos visuais. - No modelo de desenvolvimento prototipagem, um protótipo é desenvolvido para ajudar no entendimento dos requisitos do sistema. (descartável) - O modelo de desenvolvimento em espiral permite repensar o planejamento diversas vezes durante o desenrolar do projeto. - O modelo iterativo e o modelo em espiral possuem características semelhantes: ambos permitem que as atividades do processo sejam planejadas e avaliadas ao longo do ciclo de vida. - Uma vantagem do ciclo de desenvolvimento iterativo em relação ao ciclo clássico está na receptividade às mudanças inerentes ao desenvolvimento de software. - O Scrum é utilizado, como função primária, para o gerenciamento de projetos de desenvolvimento de software, mas também tem sido usado como extreme programming e outras metodologias de desenvolvimento. Teoricamente, o Scrum pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum. - Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando-se uma abordagem tradicional de controle. O Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes. - A metodologia Scrum é facilitada por um scrum master, que atua como um mediador entre a equipe e qualquer influência desestabilizadora, além de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando e mantendo o foco na meta da sprint. - Na engenharia de software, um processo iterativo denominado sprint, que segue o ciclo PDCA para entregar, num período de 30 dias aproximadamente, um incremento do software pronto, caracteriza a metodologia ágil Scrum. - O RUP foi projetado em conjunto com a UML e os processos de negócios são modelados usando casos de uso que, posteriormente, serão desenvolvidos para modelar os requisitos de sistema. - O processo unificado de software é centrado na arquitetura e orientado por casos de uso, o que sugere um fluxo de processo iterativo e incremental. - As atividades fundamentais relacionadas ao processo de construção de um software incluem a especificação, o desenvolvimento, a validação e a evolução do software. - Ao contrário do modelo em cascata, no qual as fases coincidem com as atividades do processo, o RUP compreende as fases de concepção, elaboração, construção e transição. - O Processo Unificado é iterativo e incremental. Ao final de cada iteração, a qual é um miniprojeto, os modelos que representam o sistema encontram-se em um determinado estado, denominado baseline. As atividades de cada fase de um ciclo de vida podem ser distribuídas entre várias iterações. - No Processo Unificado, atividades são organizadas em fluxos de atividades. Algumas atividades produzem artefatos, que podem ser de engenharia ou gerenciais. Entre os artefatos criados, há modelos que visam especificar o sistema a partir de certos pontos de vista e níveis de abstração. - Uma das principais características do RUP é o uso da iteração, que, por meio de refinamentos sucessivos, melhora o entendimento do problema. - No modelo RUP, a primeira linha de base da arquitetura de um software é produzida ao final da fase de elaboração. - Na fase de construção, muitos componentes do sistema são implementados, testados e integrados. Essas atividades, que partem de uma arquitetura definida, validada e implementada em fases anteriores do ciclo de desenvolvimento, produzem um sistema operacional pronto para ser instalado em um ambiente em que serão feitos testes beta. - A manipulação dos riscos está relacionada, na fase de elaboração, a questões técnicas, envolvendo a arquitetura escolhida. - A fase de elaboração tem os seguintes objetivos: detalhar casos de uso e requisitos do software; refinar a arquitetura proposta e demonstrar que essa arquitetura suporta os requisitos do sistema; testar e avaliar protótipos visando demonstrar que os principais riscos foram avaliados; e construir protótipos executáveis para a avaliação da arquitetura proposta.

35 - No RUP, o planejamento de projeto ocorre em dois níveis: planos de fase, que descrevem todo o projeto; e planos de iteração, que descrevem os passos iterativos. - Elaboração, no contexto do RUP, é uma fase que visa criar a baseline para a arquitetura do sistema a ser desenvolvido e, no contexto de engenharia de requisitos, a elaboração consiste em atividade cujo objetivo é o desenvolvimento de um modelo técnico refinado das funções, características e restrições do sistema. - A área de atividade de requisitos de software apresenta maior interface com a engenharia de sistemas quando comparada à área de análise e projeto de software. - Requisitos descrevem um acordo ou contrato entre duas partes, especificando, entre outros aspectos, o que o sistema de software deve fazer para ser aprovado em um teste de aceitação. - Requisitos funcionais declaram as funções que o sistema deve fornecer, seu comportamento, e ainda, o que o sistema não deve fazer. - A etnografia é uma técnica utilizada para a descoberta de requisitos de sistemas de software na qual, por meio de observações, procura-se compreender os requisitos sociais e organizacionais do ambiente onde o sistema será usado. - A descrição dos cenários de uso com informações acerca da utilização do sistema sob diversos pontos de vista e formas de operação deve fazer parte do levantamento dos requisitos. - A construção de um modelo de casos de uso é um meio para capturar requisitos funcionais com foco no valor dos requisitos para os usuários. Um caso de uso especifica uma seqüência de ações que o sistema pode realizar e que produzem resultados observáveis e de valor para os atores. - Em um modelo de casos de uso, pode haver diferentes tipos de usuários representados por atores. Além de tipos de usuários, atores podem representar outros sistemas ou hardwares que interagem com o sistema a ser desenvolvido. Atores se comunicam com o sistema via casos de uso. - Revisão de requisitos, prototipação e geração de casos de teste são exemplos de técnicas de validação de requisitos. - Uma das formas de resolução de ambigüidades de requisitos consiste em realizar a prototipação de partes do sistema, antes de se adotar uma solução. - A rastreabilidade de requisitos é essencial para que o controle de mudanças possa avaliar o impacto de uma solicitação de Mudança. - A gerência de requisitos tem como objetivo principal controlar a evolução dos requisitos, seja por constatação de novas necessidades, seja por constatação de deficiências nos requisitos registrados até o momento. - O gerenciamento de requisitos deve compreender e controlar mudanças nos requisitos de sistema, além de avaliar os seus impactos. Para atingir esse propósito, podem ser mantidas informações de rastreabilidade a serem usadas para avaliar quais outros requisitos seriam afetados por uma mudança, bem como o impacto da mudança de requisitos no projeto e na implementação do sistema. - Um modelo de análise pode realizar casos de uso. A realização de um caso de uso descreve interações entre objetos. Na UML, essas realizações podem ser documentadas via diagramas de colaboração (v 2.0 =comunicação). - O conceito de herança possibilita a especialização de comportamentos pré-existentes em classes ancestrais. - Uma das desvantagens da herança é a criação de dependência entre as classes envolvidas. - De acordo com a ideia do encapsulamento, é desejável, do ponto de vista de um objeto, que seus atributos internos estejam protegidos contra modificações diretas e que o acesso seja realizado por meio de métodos específicos (setters e getters). - Polimorfismo está relacionado à vinculação dinâmica de mensagens e sobrescrita de métodos, sendo que o método correto a ser chamado só será definido em tempo de execução e dependerá do tipo da instância do objeto referenciado pela mensagem. - Em um modelo de análise, as classes de fronteira modelam interações entre o sistema e os atores. Cada classe de fronteira deve estar relacionada a um ou mais atores. Pode-se também ter classes de entidade, as quais tipicamente modelam dados persistentes. - Se uma classe criada por meio de herança tiver uma única classe- pai, o processo chama-se herança simples. Se tiver mais de uma classe- pai, o processo chama-se herança múltipla. Uma classe derivada