Giovanni Guimarães Cesário
1 Engenharia de Software II Aula 26 Aula 26-21/07/2006 1
2 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap. 22 Seções 22.1 e 22.2) Estimativas (Cap. 23 Seções 23.1 a 23.7) Cronogramação (Cap. 24) Gestão de risco (Cap. 25) Gestão de qualidade (Cap. 26 Seções 26.1 a 26.7) Gestão de modificações (Cap. 27 Seções 27.1 a 27.3) Reengenharia e engenharia reversa Aula 26-21/07/2006 2
3 Gestão de Modificações Modificações são inevitáveis quando software é construído. Modificações podem gerar confusão se: Elas não são analisadas antes de serem feitas. Elas não são registradas antes de serem implementadas. Elas não são comunicadas àqueles que têm necessidade de saber delas. Elas não são controladas para melhorar a qualidade e reduzir os erros. Aula 26-21/07/2006 3
4 Gestão de Modificações Gestão de Modificações = Gestão de Configuração de Software = Software Configuration Management (SCM) É uma atividade guarda-chuva que cuida de: Identificar modificações. Controlar modificações. Garantir que as modificações sejam adequadamente implementadas. Relatar as modificações a outros que possam ter interesse. Aula 26-21/07/2006 4
5 Itens da Configuração de Software (SCIs) Uma configuração de software é formada por: Programas de computador Código-fonte e executável. Produtos de trabalho que descrevem programas de computador Tanto para profissionais como para usuários. Dados Contidos em um programa ou externos a ele. Se cada um dos itens levasse somente à criação de outros itens, pouca confusão resultaria. Porém, cada um desses itens pode (e vai!) ser modificado durante o processo de software. Aula 26-21/07/2006 5
6 Fontes de Modificação Há quatro fontes fundamentais de modificação: Novas condições de negócio ou de mercado levam a modificações nos requisitos ou nas regras de negócio. Novas necessidades do cliente exigem modificação dos dados, funcionalidade ou serviços. Reorganização do negócio causa modificações nas prioridades do projeto ou na estrutura da equipe. Restrição de orçamento ou cronograma causam redefinição do sistema ou produto. Além disso, desenvolvedores podem querer modificar a abordagem técnica. Aula 26-21/07/2006 6
7 Elementos de um Sistema de Gestão de Configuração Elementos de componente Conjunto de ferramentas acoplado a um sistema de arquivos que controla o acesso a cada item da configuração. Elementos de processo Coleção de procedimentos que definem uma abordagem efetiva para a gestão de modificação. Elementos de construção Conjunto de ferramentas que automatizam a construção de software para garantir que a versão correta foi construída. Elementos humanos A equipe deve usar o conjunto de ferramentas e processos efetivamente. Aula 26-21/07/2006 7
8 Referenciais Referencial = baseline Um item que foi formalmente revisto e aprovado e entregue. É um marco no desenvolvimento. Pode ser modificado apenas por meio de procedimentos formais. Antes que o item se torne referencial ele pode ser modificado rápida e informalmente. Aula 26-21/07/2006 8
9 Caminho de Modificação de um SCI Tarefas de engenharia de software Modificados SCIs SCIs Revisões técnicas formais Aprovados SCIs Base de dados do projeto = Repositório do software Armazenados Controles de SCM Extraídos SCIs SCIs Aula 26-21/07/2006 9
10 Exemplos de Itens de Configuração Especificação do sistema Requisitos do software Especificações do projeto Código-fonte Planos de teste/procedimento/dados Ferramentas que foram utilizadas para produzir documentação, código-fonte, código executável e dados. Aula 26-21/07/
11 Organização de SCIs SCIs são organizados para formar objetos de configuração que possam ser catalogados no banco de dados do projeto. Um objeto de configuração tem nome, atributos e é conectado a outros objetos. As conexões indicam determinar que outros objetos são afetados quando um objeto é modificado. Ex.: A especificação de projeto é conectada à especificacão de teste. Aula 26-21/07/
12 O Repositório SCM SCIs são mantidos em um banco de dados ou repositório. O repositório tem as seguintes funções: Integridade de dados Compartilhamento de informação Integração de ferramenta Integração de dados Imposição de metodologia Padronização Aula 26-21/07/
13 Integridade de Dados Valida entradas no repositório. Garante consistência entre objetos relacionados. Executa modificações em cascata quando uma modificação em um objeto exige modificações em outros. Aula 26-21/07/
14 Compartilhamento de Informação Gerencia e controla o acesso de diferentes usuários aos dados, programas e documentos. Bloqueia ou desbloqueia objetos de modo que as modificações não sejam sobrepostas. Aula 26-21/07/
15 Integração de Ferramenta Estabelece um modelo de dados ao qual podem ter acesso várias ferramentas de engenharia de software. Controla o acesso ao modelo de dados. Aula 26-21/07/
16 Integração de Dados Fornece funções de banco de dados que permitem que várias tarefas de SCM sejam executadas em um ou mais SCIs. Aula 26-21/07/
17 Imposição de Metodologia Define o conjunto de passos que precisam ser realizados para construir o conteúdo do repositório. Aula 26-21/07/
18 Padronização de Documentação Define objetos no banco de dados que levem diretamente a uma abordagem normalizada para a criação de documentos de engenharia de software. Templates Aula 26-21/07/
19 Conteúdo do Repositório Regras de negócio Funções de negócio Estrutura da organização Arquitetura da informação Conteúdo do negócio Casos de uso Modelos de análise Diagramas de cenário Diagramas de fluxo Diagramas de classe Modelo de projeto Diagramas arquiteturais Diagramas de interface Diagramas de componente Métricas técnicas Conteúdo do modelo Código-fonte Código-objeto Instruções de construção do sistema Conteúdo da construção Conteúdo de V&V Casos de teste Scripts de teste Resultados de teste Métricas de qualidade Conteúdo de gestão de projeto Estimativas de projeto Cronograma de projeto Requisitos de SCM Solicitações de modificações Relatórios de modificação Requisitos de SQA Plano de projeto Plano SCM/SQA Especificação do sistema Documentos Especificação de requisitos Documento de projeto Plano e procedimento de teste Documentos de apoio Aula 26-21/07/2006 Manual de Usuário 19
20 Características do Repositório Determinação de versão Controla modificações dos produtos de trabalho antes e depois da entrega ao cliente. Deve permitir aos desenvolvedores voltar a versões anteriores. Acompanhamento de dependência e gestão de modificação. Acompanha os relacionamentos entre as múltiplas versões dos produtos de trabalho para proporcionar modificações eficientes. Acompanhamento dos requisitos. Acompanha todos os produtos de trabalho que resultam de uma especificação de requisitos (acompanhamento avante). Identifica qual requisito gerou um produto de trabalho (retroacompanamento). Gestão de configuração Acompanha uma série de configurações representando marcos de projeto ou versões de produto específicos. Pistas de auditoria Estabelece informação adicional sobre quando, por que e por quem modificações foram feitas. Aula 26-21/07/
21 Objetivos do Processo de SCM 1. Identificar todos os itens que definem coletivamente a configuração de software. 2. Gerir modificações em um ou mais desses itens. 3. Facilitar a construção de diferentes versões de uma aplicação. 4. Garantir que a qualidade do software seja mantida à medida que a configuração evolui ao longo do tempo. Aula 26-21/07/
22 Tarefas de SCM Identificação Controle de versão Controle de modificação Auditoria de configuração Preparação de relatórios Aula 26-21/07/
23 Identificação de Objetos Cada item da configuração deve receber um nome e ser gerenciado usando uma abordagem orientada a objetos. Há dois tipos de objetos: Objetos básicos Criados durante a análise, projeto, codificação ou teste. Objetos agregados Coleção de objetos básicos e outros objetos agregados. Cada objeto tem um conjunto de atributos que o identificam unicamente. Nome, descrição, lista de recursos e uma realização (um ponteiro para o produto de trabalho). Diagramas de classes podem ser usados para representar o inter-relacionamento entre os objetos. Aula 26-21/07/
24 Controle de Versão Combina procedimentos e ferramentas para gerir diferentes versões de objetos de configuração. Possui quatro capacidades principais: Repositório que guarda todos os objetos de configuração relevantes. Capacidade de gestão de versão que guarda todas as versões de um objeto de configuração. Ou permite que qualquer versão seja construída a partir de diferenças. Facilidade de construir que permite ao engenheiro de software coletar todos os objetos de configuração relevantes e gerar uma versão específica do software. Acompanhamento de tópicos que permite à equipe registrar e acompanhar o estado de todos os tópicos importantes relacionados a cada objeto. Aula 26-21/07/
25 CVS Sistema de Versões Concorrentes CVS é uma ferramenta amplamente usada para controle de versão. Código aberto, disponível para a maioria das plataformas. Arquitetura cliente/servidor permite o acesso remoto aos arquivos. Foi projetada para código-fonte mas é útil para qualquer arquivo baseado em texto. O sistema CVS: Estabelece um repositório simples. Mantém todas as versões de um arquivo em um único arquivo, armazenando somente as diferenças. Protege contra modificações simultâneas de um arquivo, estabelecendo diretórios diferentes para cada desenvolvedor. O CVS combina modificações quando cada desenvolvedor completa seu trabalho. Outras ferramentas (ex: Makefile) precisam ser integradas para construir versões. Não implementa controle de modificação. Aula 26-21/07/
26 Controle de Modificações A necessidade de modificação é reconhecida Pedido de modificação Em projetos grandes, deve existir um processo formal para controlar modificações de objetos que tenham se tornado referenciais. Avaliação do pedido Relatório de modificação é gerado A autoridade de controle de modificação decide A solicitação é colocada em fila Pedido é negado Objetos de configuração relevantes são retirados A modificação é feita e revisada Objetos de configuração modificados são reintroduzidos Atividades de garantia de qualidade e testes são realizadas Modificações são incluídas na próxima versão que é construída Nova versão é distribuída Aula 26-21/07/
27 Auditoria de Configuração Como podemos garantir que a modificação foi adequadamente implementada? Revisão técnica formal Auditoria de configuração de software A modificação foi feita sem mudanças adicionais? Uma revisão técnica formal foi conduzida para avaliar a correção técnica? A modificação foi especificada e refletida no SCI? Os procedimentos SCM foram seguidos? Todos os SCIs relacionados foram adequadamente atualizados? Aula 26-21/07/
28 Preparação de Relatórios de Estado Um relatório de estado deve responder às seguintes questões: O que aconteceu? Quem fez? Quando aconteceu? O que mais será afetado? O relatório é gerado regularmente e se destima a manter a gerência e os profissionais informados de modificações importantes. Aula 26-21/07/
Tarefas de Gerenciamento de Configuração
Tarefas de Gerenciamento de Configuração 1- Tarefas Preliminares 2- Identificação 3- Controle de Mudanças 4- Controle de Versão 5- Auditoria de Configuração 6- Relato de Situação 7- Controle de Interface
Gerenciamento de Configuração WAZLAWICK, Raul S. Engenharia de Software: Conceitos e Práticas.1 ed. Rio de Janeiro: Elsevier, 2013. PRESSMAN, Roger S. Engenharia de Software. 6 ed.são Paulo: McGraw-Hill,
SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 20 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a Gestão de configuração e Engenharia
Gerência de Configuração Ewelton Yoshio Chiba Yoshidome Alguns problemas Duas pessoas resolveram o mesmo bug; Por que/quando parou de funcionar? versão estável final ou versão integrada ultimate? Hd de
15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos
DCC / ICEx / UFMG Pensar Orientado a Objetos Projeto Orientado a Objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Onde quer que você olhe no mundo real, você vê objetos Pessoas, animais, plantas,
Engenharia de Software II Aula 21 http://www.ic.uff.br/~bianca/engsoft2/ Aula 21-05/07/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software
Visões Arquiteturais. Visões Arquiteturais
Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: QUALIDADE DE SOFTWARE Aula N : 17 Tema:
Informática I. Aula Aula 21-29/11/06 1
Informática I Aula 21 http://www.ic.uff.br/~bianca/informatica1/ Aula 21-29/11/06 1 Ementa Histórico dos Computadores Noções de Hardware e Software Microprocessadores Sistemas Numéricos e Representação
Petter Anderson Lopes Arbitragem, Desenvolvimento Seguro, Segurança Ofensiva e Forense Computacional
Requerente: Metadados Assessoria e Sistemas. Empresa: Metadados Assessoria e Sistemas Especialista: Petter Anderson Lopes. Período: fevereiro de 2019. Modelo: Pentest, OWASP Top 10 2013 compliance. OWASP
DOCUMENTO DE VISÃO 1. TÍTULO DO PROJETO. 2. RESPONSÁVEL PELO DOCUMENTO Ciclano
DOCUMENTO DE VISÃO 1. TÍTULO DO PROJETO Título: SIGLA Sistema de Gestão de Capacitação Coordenador do Projeto: Fulano de Tal E-mail: email@email.com 2. RESPONSÁVEL PELO DOCUMENTO Ciclano 3. FINALIDADE
2016-1 ENGENHARIA DE SOFTWARE Histórico Produtos de software Tipos de aplicações de software Mitos do software Kele Teixeira Belloze kelebelloze@gmail.com HISTÓRICO (ERA PRÉ-ES) 1940s: Primeiro computador
Metamodelos para Banco de Dados. Carlos Julian Menezes Araújo Prof. Dr. Robson do Nascimento Fidalgo
Metamodelos para Banco de Dados Carlos Julian Menezes Araújo cjma@cin.ufpe.br Prof. Dr. Robson do Nascimento Fidalgo 1 Agenda Metadados MDA MOF Metamodelos CWM Pacote Relacional Referências 2 Metadados
DCC / ICEx / UFMG Modelagem Orientada a Objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Atividades de Modelagem OO 1. Definir o contexto do sistema 2. Projetar a arquitetura 3. Identificar
ENGENHARIA DE SOFTWARE. Introdução
ENGENHARIA DE SOFTWARE Introdução AGENDA Conceitos de Engenharia de Software Processo de desenvolvimento de software ENGENHARIA DE SOFTWARE CONCEITOS CENÁRIO INICIAL Desenvolvimento informal e não suficiente
Instituto Federal da Bahia Análise e Desenvolvimento de Sistemas INF022 Tópicos Avançados. Evolução de Software
Instituto Federal da Bahia Análise e Desenvolvimento de Sistemas INF022 Tópicos Avançados Evolução de Software Prof. Dr. Renato L. Novais renato@ifba.edu.br Ian Sommerville 2006 Engenharia de Software,
Engenharia de Software II Aula 13 http://www.ic.uff.br/~bianca/engsoft2/ Aula 13-02/06/2006 1 Ementa Processos de desenvolvimento de software (Caps. 2, 3 e 4 do Pressman) Estratégias e técnicas de teste
1. INTRODUÇÃO A MODELAGEM DE DADOS
1. INTRODUÇÃO A MODELAGEM DE DADOS Para se construir uma casa ou um prédio de qualidade, é essencial fazer um planejamento detalhado, com a finalidade de pensar sobre as formas de construção, fazer estimativas
Prof. Me. Sérgio Carlos Portari Júnior
Prof. Me. Sérgio Carlos Portari Júnior Ambientes que visam desenvolver aplicações que precisam de um processamento paralelo e distribuído deverão saber lidar com algumas dificuldades. Isto decorre da heterogeneidade
A modelagem de Negócio com UML
A modelagem de Negócio com UML Introdução A passagem do Modelo do Negócio para o Modelo do Sistema envolve a definição de quais Casos de Uso do Negócio deverão ser automatizados; No momento em que os requisitos
Universidade Federal de Goiás Estilos Arquiteturais
Universidade Federal de Goiás Estilos Arquiteturais Prof. Helder Brito Nascimento Instituto de Informática helderbn@gmail.com O que é um estilo de arquitetura Como você diferencia uma construção da outra?
Diagrama de Estados. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior
Diagrama de Estados Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Booch, G. et al. The Unified Modeling Language User Guide Medeiros, E.