Cleanroom - Software Engineering

Slides:



Advertisements
Apresentações semelhantes
Rational Unified Process
Advertisements

ENGENHARIA DE REQUISITOS
Débora da Silva Orientadora: Maria Inés Castiñeira
Validação de Requisitos
Planeamento Temporal e Monitorização do Projecto de SW
ISO/IEC – 6 Avaliação do Produto – Módulos de Avaliação
Rational Unified Process(RUP)
Valéria Maria Lauande Março/2010
INTRODUÇÃO A INFORMÁTICA
FACULDADE DOS GUARARAPES
Engenharia de Software I
INTRODUÇÃO À PROGRAMAÇÃO
Processo Desenvolvimento de Software Tradicional
Revisões de Software Parte 1
CMM(Capabililty Matury Model)
Simulação de Sistemas Prof. MSc Sofia Mara de Souza AULA2.
Linguagens de Programação
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Testes – visão geral Vanilson Burégio.
Gerenciamento de Requisitos com Casos de Uso
Princípios e Conceitos de Software(v2)
Introdução a Programação
REDUNDÂNCIA POR SOFTWARE
Estudo de Caso: Técnicas de Teste como parte do Ciclo de Desenvolvimento de Software Aline Pacheco Patric Ribeiro Diego Kreutz.
Desafios do desenvolvimento de software
Visão Geral PRO.NET.
Fundamentos de Engenharia de SW
Cap 2 – Processo de Software
Laboratórios de Informática IV Projecto 6 : Apresentação da 2ª Fase
Prof. Esp. Fernando Barreto
Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
Processos de Desenvolvimento de Software
ANOVA: Análise de Variância APLICAÇÃO.
IEEE Std IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)
Capability Maturity Model (CMM)
Engenharia de Software
Prof. Kelly E. Medeiros Bacharel em Sistemas de Informação
Objetivos das Atividades de Implementação • Implementar as classes do modelo de projeto em termos de componentes (código fonte ou executável, etc.) •
Engenharia de Software
Modelos de Processo de Software
Engenharia de Software
PSBD II Projeto de Sistemas de Banco de Dados II
Qualidade de Processo de Software CMM e CMMI Aldo Rocha.
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Gestão de defeitos.
Processos de Software.
Universidade Salgado de Oliveira Diretória de Pós-Graduação e Pesquisa Especialização em Tecnologia da Informação Prof. MSc. Edigar Antônio Diniz Jr Qualidade.
Modelos de Qualidade para indivíduos e grupos: PSP & TSP
Instituto Superior de Engenharia de Lisboa Departamento de Engenharia de Electrónica e Telecomunicações Licenciatura em Engenharia Informática e de Computadores.
IEEE Melhores Práticas para Descrições de Projeto de Software (DPS)
Linguagem de Modelagem Unificada
Engenharia de Software
Engenharia de Requisitos
Gestão da Configuração do Software
Engenharia de Software
Profª Eliane Costa Santana
CMM – Capability Maturity Model Carlos Augusto Mar Ago/2014.
Qualidade de Software O que é ‘Qualidade de Software’?
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Aula 02 de Eng. de Requisitos
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
CMMI Capability Maturity Model – Integration

Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Engenharia de Produtos
TESTES DE SOFTWARE – AULA 1 Prof. Me. Ronnison Reges Vidal
CMMI Capability Maturity Model Integration
Transcrição da apresentação:

Cleanroom - Software Engineering ESTIG – Engenharia Informatica Docente Maria Fernanda Pedro Jorge Soares 3769 Ricardo Almeida 3477

Introdução Cleanroom software engineering foi desenvolvido por Dr.Harlan Mills e inicialmente utilizado pela IBM na decada de 80 e utilizado actualmente por por muitas outras empresas, ex:US Army, NASA, Texas Instruments.

O que é Cleanroom ? Cleanroom software engineering é um sistema que combina vários métodos formais de requisitos e projecto com uma prova estatística de forma a produzir posteriormente software de alta qualidade com poucos ou nenhuns defeitos.

Origem do nome “Cleanroom” O termo “Cleanroom" tem como origem na industria de electrónica, visto que existiam e existem laboratórios para a fabricação de hardware totalmente limpos para prevenir o aparecimento de hardware defeituoso.

Objectivos do “Cleanroom” É um sistema que tem como principal objectivo seguir um determinado modelo “waterfall”. Consiste em separar e projectar separadamente requisitos, projectos, codificação e testes.

O que são “Box Structures” O Método “Box Structures” é usado para efectuar uma descrição pormenorizada e esboço. A verificação funcional é utilizada para confirmar que o projeto é uma implementação correta da descrição. Portanto, a descrição deve ser definida antes do projecto e da verificação funcional.

Tipos de“Box Structures” Black box - É o modo de conseguir visualizar um determinado objecto mas que não é mostrado nenhuma implementação de dados nem de processos. Neste sistema fica indicado como o sistema responde a estimulos usados numa linguagem especifica. Normalmente organizado em hierarquias de uso. State Box - É o modo de conseguir visualizar um determinado objecto onde é mostrado apenas a implementação de dados mas não mostra a implementação de processos. Descreve como é efectuada a transformação do estado do objecto. Clear Box - É o modo de conseguir visualizar um determinado objecto onde é mostrado as duas implementações a de dados e de processos. Com o objectivo de refinar todos os dados e processos e de os corrigir.

Ordem dos passos do “Cleanroom” A análise de requisitos: produzir e rever “descrições pormenorizadas”. Projeto de alto nível: converter a analise de requisitos em codigo máquinas Projeto detalhado: Um aperfeiçoamento das funções já feitas no projecto de alto nivel.

Ordem dos passos do “Cleanroom” (cont) Programação por Incremento: Desenvolver código e verificar se estão a ser utilizados os metodos inicialmente descritos. Compilar código ou testar codigo nesta altura é proibido. Pré teste por Incremento: gerar casos de teste. Testes baseados em resultados estatisticos: todo o codigo é compilado, iniciado e testado. Todos os resultados são validados e registados.

Cleanroom e o CMM(Capability Maturity Model) O modelo CMM descreve a maneira como os processos do software estão organizados, desde a forma desorganizada até que o processo esteja concluido. Existem 5 niveis no CMM começando no nivel 1 e terminando no nivel 5. Um nivel evoluido é definido no KPA (key process area). Cleanroom é intencionado em aplicar disciplina no desenvolvimento de software no ramo da engenharia.

Cleanroom e o CMM(cont) Nível 1: Nenhum! (Não existem processos para o Cleanroom e Ad hoc) Nível 2: Todas as KPA’s. Tem alta correspondência mas é assegurada a qualidade do software. Nível 3: Todas as KPA’s. Alta correspondência Nível 4: Todas as KPA’s. Nível 5: Todas as KPA’s. Alta correspondência; Mas KPA de “Mudança de Tecnologia”.

Conclusão São efectuados testes estatísticos para atribuir uma taxa de alta fiabilidade do sistema. Antes do codigo começar a ser implementado são efectuadas constantes verificações como primeiro mecanismo de detecção de erros. Cleanroom Software Engineering é uma forma de desenvolver software de alta qualidade.

Bibliografia http://www.sei.cmu.edu/str/descriptions/cleanroom.html http://www.uta.edu/cse/levine/fall99/cse5324/cr/clean/page1.html Diciopédia 2005