Relatório ListEx 07
CE‐237
Tópicos Avançados em Teste de Software
Prof. Dr. Luiz Alberto Vieira Dias
Prof. Dr. Adilson Marques da Cunha
Alunos : Eduardo Mena Barreto Alonso
Jorge Luís Guedes Alves
Outubro/2010
Pós-Graduação em Engenharia Eletrônica e Computação
Área Informática (EEC-I)
Lista de Exercícios 7 (ListEx 07)
CE-237 Tópicos Avançados de Teste de Software
Prof. Dr. Luiz Alberto Vieira Dias
Laboratório 07 – LABTEC da FCMF – ou em casa
Motivação
Aumentar o nível de compreensão e aplicação de conceitos apresentados e
desenvolvidos em sala de aula na matéria Tópicos Avançados em Teste de Software,
através de aulas expositivas e/ou laboratoriais. Conseguir desenvolver um maior senso
crítico em teste de software, através da aplicação das técnicas.
Requisitos
Preparar o Critical Design Review – CDR, para o Segmento da Missão Lunar
2-2010 - módulo CAVAL – Coleta de Amostras pelo Veículo Lunar da Missão Lunar
Brasileira.
Entrega: 22/10/2010 – 23:59h
Listex 7 – CDR – Purpose
1. Determine that detail design of the configuration item (CSCI) under review
satisfies cost (for cost type contracts), schedule, and performance
requirements.
2. Establish detail design compatibility among the configuration item and
other items of equipment, facilities, computer software and personnel.
3. Assess configuration item risk areas (on a technical, cost, and schedule
basis).
4. For new development hardware configuration items; assess the results of
producibility analyses conducted on system hardware.
5. For new development hardware configuration items; review preliminary
hardware product specifications.
6. For configuration items, this review will focus on the determination of the
acceptability of the detailed design, performance, and test characteristics of
the design solution, and on the adequacy of the operation and support
documents.
Description
CDR shall be conducted for each configuration item before release of design for
manufacturing. For large complex configuration items, the CDR may be a
progressive or incremental review, culminating in a system level CDR which
essentially reviews the completeness of preceeding CDRs and ensures adequate
interfaces between the configuration items.
Detailed Checklist – CDR
Entry Criteria:
Successful completion of all action items related to the previous conference (PDR)
1. Published agenda (several days prior to the conference)
2. Acceptance of all applicable CDRLs.
3. See the contract for specific criteria which may be unique to your program
Detailed Check List – CDR
Exit Criteria:
1. Approval of CDR normally establishes the "design freeze" date. This design
freeze does not generally include software design in the sense that software
is always flexible and being modified to reflect improvements. In another
sense, software is frozen where changes to the software would modify the
approved trainer performance requirements
2. Changes in design made before design freeze can usually be made without
the necessity for formal engineering change action, if the change is within
the scope of the contract
3. A change made after design freeze requires a Trainer Engineering Change
Proposal, and negotiation with the contractor, followed by a modification to
the contract to document the nature and extent of the change
4. Acceptance of published minutes to include list of attendees
5. Completion of all action items assigned to the contractor
6. Acceptance of any CDRLs due at the CDR
7. Concurrence from the Government/Contractor IPT members that all issues
in the conference agenda have been addressed
Outputs and Customers
The completion of CDR usually initiates the start of formal configuration
management by the Contractor of the technical baseline. Any changes to that
baseline can only be accomplished with the approval of the Government Tools
Required:
In addition to the published agenda, a checklist of subject areas of concern can be
used to evaluate the contractors coverage of the detailed design.
PDR/CDR Design Review Summary Report Format
1. Introduction
2. Participants
3. Entry Criteria Status
4. Design Review Results. These subparagraphs shall summarize the status of the
design approach and disclosure for each of the following: 1.System level overview;
2. Visual System; 3. Sensors; 4. Computational System; 5. Control Loader &
G-Cueing System; 6. Modeling and Simulation; 7. Tactical Environment; 8.
Instructor Operator Station (IOS); 9. Quality Assurance/Testing; 10. RTIO; 11.
Trainee Station; 12. Aural Cues & Communication; 13. Facilities; 14. Logistics
5. Exit Criteria Status
6. Requirements to complete the PDR or CDR
7. Conclusion
Signed by the PDR/CDR Chairperson
Procedimentos
1. Introduction
Operar um veículo autônomo na Lua, a partir de uma Sala de Controle na Estação
Espacial Internacional (ISS), em órbita na Terra, a 500 km de altitude. O veículo, já na
superfície da Lua, deverá, colher amostras de rochas em pontos pré-determinados,
depositar plataformas de coleta de dados se posicionar no módulo de retorno à Terra,
com as amostras recolhidas. O módulo lunar CAVAL deverá coletar as amostras
lunares com a utilização do veículo lunar, tendo as seguintes funcionalidades:
– Imagear o local da coleta
– Registrar as coordenadas lunares do local
– Imagear as amostras
– Coletar as amostras
2. Participants
Jorge Luís Guedes Alves e Eduardo Mena Barreto
3. Entry Criteria Status
Fases da atividade de teste, análise dos fatores de alto Risco, níveis de serviço,
confiabilidade e continuidade do segmento CAVAL – Coleta de Amostras através do
Veículo Lunar:
Fatores de Teste
1 - Níveis de serviço
Teste
Preocupação – O que foi elaborado de tolerância já foi testado?
Estratégia de Teste - Criar uma suíte de teste para verificar se a tolerância encontra-se
dentro do prazo previsto, ou seja, se está sendo testada.
2 - Confiabilidade
Teste
Preocupação - O reprocessamento para a correção após a detecção de erros foi testado?
Estratégia de Teste - Criar uma suíte de teste para verificar se o reprocessamento para a
correção após a detecção de erros está sendo testada.
3 - Continuidade do tratamento
Teste
Preocupação – A recuperação de um sistema online foi testada?
Estratégia de Teste - Criar uma suíte de teste para verificar se a recuperação de um
sistema online está sendo testada
4. Design Review Results.
These subparagraphs shall summarize the status of the design approach
and disclosure for each of the following:
1. System level overview;
2. Visual System;
3. Sensors;
5. Control Loader & G-Cueing System;
6. Modeling and Simulation;
7. Tactical Environment;
8. Instructor Operator Station (IOS);
9. Quality Assurance/Testing;
10. RTIO;
11. Trainee Station;
12. Aural Cues & Communication;
13. Facilities;
14. Logistics
1. Requisitos funcionais do segmento:
Imagear o local da coleta de amostras
Registrar as coordenadas lunares do local
Imagear as amostras
Coletar as amostras
Fechar o compartimento de amostras
2.Visual System - interface a ser criada em conjunto com os outros módulos.
3.Sensors - N/A.
4.Computational System – Requisitos de Hardware (PC com mínimo de 512Mb de
RAM, com Visual Studio instalado) e Requisitos de Software(licenças Visual
Studio) – opensource – Subversion e TestLink integradas);
5.Control Loader & G-Cueing System - N/A;
6.Modeling and Simulation – Arquitetura inicial e troca de mensagens entre o
Módulo CAVAL – COLETA DE AMOSTRAS e o Módulo 1 - Controle de missão
(CNTRL).
7.Tactical Environment - N/A;
8.Instructor Operator Station (IOS) - o Projeto Segmento da Missão Lunar 2-
2010, depois de integrado, será processado em uma única máquina, tendo o módulo
CNTRL como operador;
9.Quality Assurance/Testing - após a definição da Arquitetura do Projeto, os
Casos de Teste serão detalhados:
9.1. Testar o requisito de validação do local da coleta (coordenadas).
9.2. Testar o requisito de registro das coordenadas.
9.3. Testar o requisito “imagear as amostras”.
9.4. Testar o requisito que valida a coleta das amostras.
10.RTIO – elaborar o procedimento de comunicação em Tempo Real com o módulo
CNTRL. Ex: escrita em 7OUT.txt, leitura de 1IN.txt a cada 200ms;
11.Trainee Station - N/A;
12. Aural Cues & Communication - N/A;
13. Facilities – Disponibilidade de elaboração do Projeto em sala de aula juntamente
com os demais alunos desta disciplina;
14. Logistics – metodologia SCRUM.
5. Exit Criteria Status
As necessidades que vierem a surgir com relação a desenvolvimento do veículo lunar que
afete a coleta de amostras deverão ser autorizadas e devidamente documentadas pelos
membros da equipe do módulo CAVAL.
REVISÃO CRÍTICA DO PROJETO (CDR)
PREPARAÇÃO DA REVISÃO S,N, NA F, O Comentário1 Foram identificados padrões para definir claramente o processo de revisão?
S Os padrões foram definidos segundo a documentação do SW 2 Diretrizes foram usadas para preparar a
revisão?
S
3 O projeto apresentou qualquer pedido de desvios ou renúncias ao processo
definido?
N A especificação do SW está mantida conforme critérios definidos no semestre anterior 4 Foram estabelecidos critérios de entrada
e de saída para a revisão?
S
5 Foi uma agenda preparada e distribuída antes da revisão?
S Foi definida uma agenda durante reuniões do grupo
6 O pacote de revisão foi fornecido com bastante tempo para rever?
S
7 Foram os interessados adequados a participação?
S Foram discutidos durante as aulas
CONTEÚDO DA REVISÃO
8 Foram os objetivos da revisão e algum pré-requisito de reexame previsto?
N
9 Foi abordado o processo de revisão, incluindo o método para a captura de solicitações de ação (RFAs), riscos ou problemas?
S Foram abordados em sala de aula e desenvolvidos nas listas de exercícios
10 Foi uma visão geral do software de projeto/sistema fornecido (por exemplo, metas de missão, principais
funcionalidades, características operacionais)? S Idem item 9 11 É a estrutura de divisão de organização/trabalho (WBS) / projeto de relacionamento apresentada? S As responsabilidades foram estabelecidas bem como a divisão de trabalho.
12 Foi criada alguma ação em função do status do (PDR)?
N
13 É o status de IV & V fornecido? NA
14 São milestones, compilações de software e programações apresentadas?
S Foram abordados em sala de aula e desenvolvidos nas listas de exercícios
S,N,N A
F, O
Comentário 15 Foram apresentados os impactos de
orçamento e cronograma?
NA Trata-se de um projeto acadêmico.
OBJETIVOS
16 O CDR reflete que todos os elementos do projeto são compatíveis com
funcional e requisitos de desempenho?
S
17 O CDR reflete que a abordagem de verificação é viável e confirmará a conformidade com todos os requisitos?
S
18 O CDR reflete que os riscos foram devidamente identificados e atenuados ou estão em curso para a redução de tempo hábil?
S A identificação dos riscos foram relatadas na listex 5
19 O CDR reflete que o projeto está
suficientemente maduro para prosseguir com o desenvolvimento em grande escala?
NA Trata-se de um projeto acadêmico.
20 O CDR reflete que os processos de gestão utilizados pela equipe do projeto são suficientes para desenvolver e operar a missão?
S A especificação foi clara e suficiente para a realização da missão.
21 O CDR reflete que as estimativas de agendamento e custo indicam que a missão estará pronta para lançar e operar no tempo e no orçamento e que os processos de controle são suficientes para garantir a restante dentro dos recursos alocados?
NA
REQUISITOS
22 Os requisitos de fluxo para baixo são rastreáveis?
S 23 Os requisitos restantes "Para ser
determinado" (TBD) foram resolvidos?
N Trata-se de um projeto
acadêmico e necessitaríamos de mais tempo.
24 O pacote de revisão incluiu uma visão geral das alterações, adições ou exclusões para os requisitos desde a PDR?
NA
25 Atualizações e descrições de interface são apresentados (interno e externo)?
N
S,N,N A
F, O
Comentário 26 A matriz de verificação foi atualizada
para refletir todas as alterações de exigência desde a PDR
S A especificação do SW foi mantida conforme definido nos requisitos descritos no endereço HTTP://sites.google.com/site/ce 230toni/ce-229
PROJETO DETALHADO
27 Existe uma definição completa do projeto?
S A especificação do SW foi mantida conforme definido nos requisitos descritos no endereço HTTP://sites.google.com/site/ce 230toni/ce-229
28 O projeto foi elaborado em diagramas de linha de base para um nível suficiente de detalhe?
S Os fluxos e comunicação entre os módulos e diagramas encontram-se na especificação de requisitos.
29 Diagramas de fluxo de lógica detalhadas são apresentados?
NA 30 Diagramas de fluxo de dados detalhados
são apresentados?
NA 31 Foi o código de reutilização ou
patrimônio software abordado, se necessário?
NA
32 O projeto atende a todos os requisitos de segurança de software aplicável?
S Os requisitos de segurança obedecem a especificação do projeto.
33 Atualizações para as estimativas do uso de recursos de vôo são: armazenamento de unidade de processamento central (CPU), memória, bancos de dados e dados apresentado?
NA Projeto foi especificado com somente utilização de arquivos texto no formato TXT
34 As atualizações para os cenários de operações são apresentadas?
N 35 Quaisquer problemas ou recursos de IT
Security foram abordados?
N Trata-se de um projeto acadêmico.
36 O projeto é detalhado sob controle formal de CM?
N
TESTE DE SOFTWARE
37 Foram abordadas as funções dos membros da equipe de teste?
S 38 A documentação de teste foi abordada
títulos e status da matriz de plano de teste, procedimentos e rastreabilidade?
S
39 Cenários de teste de software são consistentes com o plano de teste de software?
S
40 Vários níveis de teste (testes de
unidade, de integração, testes, testes de sistema) foram abordadas?
S Os testes unitários foram baseados na especificação do controle da missão.
41 As compilações/versões diferentes e cronogramas de teste foram abordadas?
N
S,N,N A
F, O
Comentário 42 O ambiente de teste foi abordado? S
43 O processo de aceitação foi abordado? S 44 São os drivers/simuladores para serem
usado no teste foram apresentados?
S A especificação do SW foi mantida conforme definido nos requisitos descritos no endereço HTTP://sites.google.com/site/ce 230toni/ce-229
45 Há recursos adequados, tais como hardware e pessoal para testes?
S Grupo de alunos 46 Há provas de que as análises
comparativas foram realizadas para cada unidade de software e cenários de teste?
S
47 Existe um resumo das atividades de revisão por pares e itens de ação?
S
INSTALAÇÃO E MANUTENÇÃO ENTREGA
48 O processo de entrega foi abordado – código, ferramentas, identificação de versão, documentação, bancos de dados de origem?
N
ESTADO DO SOFTWARE
49 A estimativa de tamanho de software atual foi abordada?
S No desenvolvimento do SW 50 A programação atual foi endereçada
incluindo milestones ?
S 51 O status atual de custo/esforço de
pessoal foram abordados?
N Trata-se de um projeto acadêmico.
RISCOS
52 São documentados problemas com planos de controle e de encerramento, planos de atenuação e riscos técnicos?
S No desenvolvimento do SW
DOCUMENTAÇÃO DO SOFTWARE
53 O pacote de revisão inclui os seguintes documentos aprovados:
53a Documento de requisitos de software (atualizado)
S A especificação do SW foi mantida conforme definido nos requisitos descritos no endereço HTTP://sites.google.com/site/ce 230toni/ce-229.
53b Documento de requisitos de interface de software (atualizado)
N A documentação referente ao modulo Retorno a Terra e 53c Plano de teste de software (atualizado) S Reentrada foi elaborada pelo 53d Documento de projeto de software
(atualizado)
S grupo.
53e Procedimentos de teste de software (rascunho)
S 53f Manual de usuários de software
(rascunho)
N
S=Sim, N=Não, NA=Não se Aplica, F=Finding, O=Observação COMMENTS PAGE _____ of _____ S,N,N A F, O Comentário 54 Na conclusão da revisão chegou-se a
um entendimento técnico sobre a validade e o grau de abrangência da:
54a Especificação de sistema/subsistema? S 54b Projeto e custo de engenharia do
sistema?
N Trata-se de um projeto acadêmico.
55 Todas as partes designadas concordam com a aceitabilidade do CDR?
S 56 Há riscos, questões ou pedido de ações
(RFAs) que requerem acompanhamento?
N Trata-se de um projeto acadêmico.
57 Há um processo de revisão e o encerramento de riscos, questões ou RFAs de controle?
N
58 Todos os artefatos foram colocados sob o controle de configuração formal (por exemplo, pacotes de revisão)?
N O grupo criou artefatos baseados no RUP 59 Foram as lições aprendidas dirigida e
capturadas?
S
REFERENCE ITEMS/DOCUMENTS Information Systems Division (ISD) Checklist 580-CK-009-01, Software Contents of the Mission-Level Critical Design Review (CDR) Information Systems Division (ISD) Checklist 580-CK-008-01, Contents of the Software Critical Design Review (CDR) BK Draft CDR Guidelines, GSFC System Management Office, Design Review Guidelines-CDR NASA Software Safety Guidebook NASA-GB-8719.13, Section 7.5.2.1 IEEE
Data 20/10/2010 Missão Lunar – CAVAL - Coleta de Amostras
Assessores(s):Jorge Luís Guedes Alves , Revisor: Eduardo Mena Barreto Alonso
