Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CUROS DE CIÊNCIAS DA COMPUTAÇÃO – BACHARELADO
SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA
NORMA ISO/IEC 12207 – PROCESSOS DO CICLO DE VIDA
DO SOFTWARE.
ALTAIR BERNARDI
BLUMENAU 2003
2003/2-04
ALTAIR BERNARDI
SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA
NORMA ISO/IEC 12207 – PROCESSOS DO CICLO DE VIDA
DO SOFTWARE
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação — Bacharelado.
Prof. Marcel Hugo – Orientador
BLUMENAU 2003
2003/02-04
SOFTWARE DE AUXÍLIO À IMPLANTAÇÃO DA
NORMA ISO/IEC 12207 – PROCESSOS DO CICLO DE VIDA
DO SOFTWARE
Por
ALTAIR BERNARDI
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Marcel Hugo – Orientador, FURB
______________________________________________________ Membro: Prof. Carlos Eduardo Negrão Bizzotto, FURB
______________________________________________________ Membro: Prof. Alexander Roberto Valdameri, FURB
AGRADECIMENTOS
Aos meus pais, pois sem eles não teria chegado até aqui.
Ao meu orientador, Marcel Hugo, pela ajuda e por ter acreditado na conclusão deste
trabalho.
Aos meus amigos, pelo apoio recebido para finalizar este trabalho.
RESUMO
Através do estudo dos processos fundamentais de ciclo de vida de software proposto pela Norma NBR ISO/IEC 12207 foi desenvolvido um questionário que objetiva determinar qual o percentual de adequação dos processos utilizados por uma organização no desenvolvimento de software em relação aos processos definidos pela norma. Para facilitar a aplicação do questionário foi desenvolvido um aplicativo web que pode ser acessado em www.flynet.com.br/12207. O trabalho foi aplicado em uma grande empresa do setor alimentício da região e além de determinar o percentual de adequação de seus processos de desenvolvimento com a norma determinou-se o também o nível CMM da empresa.
Palavras chaves: NBR ISO/IEC 12207; Qualidade; Software.
ABSTRACT
Through the studies about the fundamental processes of software life cycle considered for the Norma NBR ISO/IEC 12207 it was developed a questionnaire that aims to determine which is the adaptation percentage of the processes used by an organization in the software development. In order to make the questionnaire application easier it was developed a web application that can be accessed at www.flynet.com.br/12207. This work was applied in a big company in the food section determining the adaptation percentage of its development processes against the standard and it was also determined the CMM level of the company.
Key-Words: NBR ISO/IEC 12207; Quality; Software.
SUMÁRIO
1 INTRODUÇÃO....................................................................................................................8
1.1 OBJETIVOS DO TRABALHO ........................................................................................10
1.2 ESTRUTURA DO TRABALHO......................................................................................10
2 MODELOS DE QUALIDADE DE SOFTWARE...........................................................11
2.1 MODELOS........................................................................................................................11
2.1.1 ISO 9001/9000-3.............................................................................................................11
2.1.2 CMM...............................................................................................................................12
2.1.3 SPICE..............................................................................................................................14
2.2 TRABALHOS CORRELATOS........................................................................................16
2.2.1 Theilacher........................................................................................................................16
2.2.2 Anacleto ..........................................................................................................................17
2.2.3 Frare ................................................................................................................................18
3 A NORMA ISO/IEC 12207...............................................................................................19
3.1 CARACTERÍSTICAS GERAIS .......................................................................................19
3.1.1 Processos de Software.....................................................................................................19
3.1.2 Objetivo...........................................................................................................................19
3.1.3 Campo de Aplicação .......................................................................................................20
3.1.4 Conformidade..................................................................................................................20
3.1.5 Limitações .......................................................................................................................21
3.2 ESTRUTURA DA NORMA.............................................................................................21
3.2.1 Processos Fundamentais .................................................................................................22
3.2.2 Processos de Apoio .........................................................................................................24
3.2.3 Processos Organizacionais..............................................................................................26
3.3 RELAÇÃO CMM E NBR ISO/IEC 12207.......................................................................27
4 DESENVOLVIMENTO DO TRABALHO.....................................................................30
4.1 DETERMINAÇÃO DO NÍVEL CMM.............................................................................30
4.2 QUESTIONÁRIO DA NORMA NBR ISO/IEC 12207 ...................................................32
4.3 REQUISITOS PRINCIPAIS DO SOFTWARE................................................................34
4.4 ESPECIFICAÇÃO ............................................................................................................37
4.4.1 Casos de Uso...................................................................................................................37
4.4.2 Diagramas de classes.......................................................................................................39
4.4.3 Diagrama de seqüência ...................................................................................................40
4.4.4 Diagrama Entidade Relacionamento...............................................................................45
4.5 IMPLEMENTAÇÃO ........................................................................................................45
4.5.1 Técnicas e Ferramentas utilizadas...................................................................................45
4.6 OPERACIONALIDADE DA IMPLEMENTAÇÃO........................................................48
4.6.1 Acesso .............................................................................................................................48
4.6.2 Cadastro e Logon de usuários .........................................................................................49
4.6.3 Utilização do Aplicativo .................................................................................................50
4.7 RESULTADOS E DISCUSSÃO ......................................................................................63
5 CONCLUSÕES..................................................................................................................65
5.1 EXTENSÕES ....................................................................................................................66
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................67
ANEXO A – Metodologia utilizada pela empresa ...................................................................68
ANEXO B – Questionário 01...................................................................................................69
ANEXO C – Questionário 02...................................................................................................71
ANEXO D – Questionário 03...................................................................................................74
APÊNDICE A – Perguntas criadas a partir da Norma ISO/IEC 12207 ...................................77
8
1 INTRODUÇÃO
Atualmente as organizações estão em busca de certificados que comprovem a
qualidade de seus produtos e processos no intuito de conseguir uma maior competitividade,
participação no mercado e em conseqüência aumentar seus lucros.
Segundo a ISO 8402 (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS,
1997) qualidade é a totalidade das características de uma entidade que lhe confere a
capacidade de satisfazer às necessidades explícitas e implícitas.
Esta definição da qualidade exige alguns complementos, principalmente para definir o
que são as entidades, as necessidades explícitas e as necessidades implícitas. A entidade é o
produto do qual está se falando, que pode ser um bem ou um serviço. As necessidades
explícitas são as próprias condições e objetivos propostos pelo produtor. As necessidades
implícitas incluem as diferenças entre os usuários, a evolução no tempo, as implicações éticas,
as questões de segurança e outras visões subjetivas.
Segundo Barreto [200-] a qualidade de um prato de comida (a entidade, o produto) está
relacionada com a satisfação de necessidades (requisitos) tais como: sabor, aparência,
temperatura, rapidez no serviço, preço, higiene, valor nutricional etc. Para avaliar a qualidade
de um produto, você deve fazer uma lista destas necessidades e analisar cada uma destas
necessidades.
Segundo Fuggeta (apud ROCHA, 2001) uma das evoluções mais importantes no
estudo da qualidade está em notar que a qualidade do produto é algo bom, mas que qualidade
do processo é ainda mais importante, visto que a qualidade de produtos está fortemente
relacionada à qualidade do processo. Em software esta afirmação não é diferente.
Assim houve uma grande preocupação com a modelagem e melhorias no processo de
software. Abordagens importantes como as normas de qualidade ISO 9000 e a ISO/IEC
12207, o modelo Capability Maturity Model (CMM) e o modelo Software Process
Improvement and Capability Determination (SPICE) sugerem que melhorando o processo de
software, pode-se melhorar a qualidade dos produtos (PFLEEGER apud Rocha (2001)).
9
Segundo Curtis (apud ROCHA, 2001) “a organização que for capaz de integrar,
harmonizar e acelerar seu processo de desenvolvimento e manutenção de software terá a
primazia do mercado”.
Observando-se este fato, este trabalho de conclusão almeja determinar quais itens dos
processos Fundamentais do ciclo de vida da Norma NBR ISO/IEC 12207 foram adotados no
processo de software de uma empresa do setor alimentício da região, determinar o nível CMM
para validar os resultados obtidos com a Norma NBR ISO/IEC 12207 e desenvolver um
aplicativo para auxiliar na avaliação da adequação à Norma NBR ISO/IEC 12207.
Conforme se pode observar, a área de desenvolvimento de software não é o foco
principal desta empresa, contudo a mesma está preocupada na qualidade de seus processos de
software, pois poderá ter um aumento em seus lucros se estes puderem ser melhorados.
A determinação dos itens da Norma NBR ISO/IEC 12207 e do nível CMM foi feita
através de levantamento bibliográfico e posteriormente comparados com os métodos adotados
pela empresa no seu processo de desenvolvimento de software.
O aplicativo foi implementado utilizando-se o ambiente Active Servers Page (ASP)
juntamente com o Microsoft Access, sendo especificado utilizando-se a Unified Modeling
Language (UML) com o apoio da ferramenta Rational Rose. Ao ser executado o aplicativo,
será feita uma série de perguntas, cada uma com seu respectivo peso e no seu término será
fornecido ao usuário medidas que devem ser tomadas para que a empresa em questionamento
seja adequada à norma ISO/IEC 12207. Será permitida a inclusão de novas perguntas
juntamente com seus respectivos pesos, sendo que estas juntamente com os resultados ficarão
armazenadas no Microsoft Access.
Existem pelo menos três estudos já realizados interligados com este trabalho de
conclusão de curso: Frare (1998) que especifica um roteiro para a implantação da Norma
NBR ISO/IEC 12207; Theilacher (2000) que realiza a análise de uma organização de software
utilizando o modelo CMM/SEI e Anacleto (1996) que faz a mensuração do processo de
software baseado no modelo CMM/SEI. O que difere este trabalho dos demais é o fato do
mesmo estar focado em determinar se o processo interno utilizado por uma empresa está de
acordo com a Norma NBR ISO/IEC 12207 e caso não esteja fornecer respostas do que a
empresa precisa implantar para ficar de acordo com a norma em questão.
10
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho de conclusão de curso é desenvolver um software para
auxiliar na avaliação da adequação de uma empresa aos Processos Fundamentais do ciclo de
vida da Norma ISO/IEC 12207 e determinar o nível CMM da empresa onde o software foi
utilizado para validar os resultados obtidos.
Os objetivos específicos do trabalho são:
a) permitir a inclusão de um check list com perguntas sobre os tópicos propostos pela
norma;
b) estabelecer quantitativamente o grau de conformidade da empresa em relação a
cada tópico da norma;
c) permitir a inclusão de novas perguntas de acordo com mudanças na norma ou
processos;
d) trazer para a empresa avaliada um relatório apontando críticas sobre a situação da
mesma frente a cada item da norma.
1.2 ESTRUTURA DO TRABALHO
A seguir é descrito brevemente cada capítulo deste trabalho.
O primeiro capítulo apresenta a origem, os objetivos e a estrutura do trabalho.
O segundo capítulo apresenta uma descrição de modelos existentes para a avaliação
dos processos de software e uma breve descrição de trabalhos correlatos.
O terceiro capítulo apresenta a Norma ISO/IEC 12207, seus objetivos, necessidades,
campo de aplicação, conformidade, limitações e estrutura dos processos.
O quarto capítulo apresenta todas as etapas realizadas no desenvolvimento do trabalho
acadêmico.
O quinto capítulo apresenta as conclusões e sugestões para futuros trabalhos.
11
2 MODELOS DE QUALIDADE DE SOFTWARE
Segundo Rocha (2001) a globalização da economia tem influenciado as empresas
produtoras e prestadoras de serviços de software a alcançar o patamar de qualidade e
produtividade internacional para enfrentarem a competitividade cada vez maior.
Este reconhecimento é obtido através de certificações a um ou vários modelos de
qualidade de software.
Segundo Fuggeta (apud ROCHA, 2001) a qualidade de produtos de software está
fortemente relacionada à qualidade do processo de software. Assim, na década de 90 houve
uma grande preocupação com a modelagem e melhorias no processo de software.
Abordagens importantes como as normas ISO 9000, ISO/IEC 12207, o modelo CMM
e o SPICE sugerem que melhorando o processo de software, pode-se melhorar a qualidade
dos produtos (PFLEEGER apud Rocha (2001)).
2.1 MODELOS
A seguir tem-se uma descrição geral dos principais modelos e normas de Qualidade de
Software. A Norma ISO/IEC 12207 será tratada em um capítulo a parte devido sua
importância para este trabalho.
2.1.1 ISO 9001/9000-3
Segundo Rocha (2001) a norma ISO 9001 abrange todo o ciclo de vida de um produto
ou serviço, cobrindo os requisitos para a garantia de qualidade em projetos, desenvolvimento,
produção, instalação e serviços associados e a norma ISO 9000-3 estabelece diretrizes para a
aplicação da norma ISO 9001 ao desenvolvimento, fornecimento e à manutenção de software.
Segundo Barreto [200-] todas as orientações da norma ISO 9000-3 giram em torno de
uma situação contratual, onde uma parte contrata outra para desenvolver um produto de
software. A tabela 1 apresenta os processos definidos da norma ISO 9000-3:
12
Tabela 1 – Processos definidos da norma ISO 9000-3 Grupo Atividade Estrutura do Sistema de Qualidade Responsabilidade do fornecedor;
Responsabilidade do comprador; Análise crítica conjunta.
Atividades do Ciclo de Vida Análise crítica do contrato; Especificação dos requisitos do comprador; Planejamento do desenvolvimento; Projeto e implementação; Testes e validação; Aceitação; Cópia, entrega e instalação; Manutenção.
Atividades de Apoio Gerenciamento de configuração; Controle de documentos; Registros da qualidade; Medição; Regras, convenções; Aquisição; Produto de software incluído; Treinamento.
Fonte: Barreto [200-].
2.1.2 CMM
Segundo Barreto [200-] o modelo CMM (Capability Maturity Model) é uma iniciativa
do SEI (Software Engineering Institute) para avaliar e melhorar a capacitação de empresas
que produzem software e foi financiado pelo Departamento de Defesa do Governo dos
Estados Unidos, que precisava de um modelo formal que permitisse selecionar os seus
fornecedores de software de forma adequada.
2.1.2.1 Maturidade
Segundo Barreto [200-] o CMM é um modelo para medição da maturidade de uma
organização no que diz respeito ao processo de desenvolvimento de software. A definição do
que é Maturidade pode ser mais bem compreendida através da análise da tabela 2.
13
Tabela 2: Maturidade Organizações maduras Organizações imaturas Papéis e responsabilidades bem definidos Processo improvisado Existe base histórica Não existe base histórica É possível julgar a qualidade do produto Não há maneira objetiva de julgar a qualidade
do produto A qualidade dos produtos e processos é monitorada
Qualidade e funcionalidade do produto sacrificadas
O processo pode ser atualizado Não há rigor no processo a ser seguido Existe comunicação entre o gerente e seu grupo
Resolução de crises imediatas
Fonte: Barreto [200-].
2.1.2.2 Níveis
O CMM classifica as organizações em cinco níveis distintos, cada um com suas
características próprias. No nível 1, o das organizações mais imaturas, não há nenhuma
metodologia implementada e tudo ocorre de forma desorganizada. No nível 5, o das
organizações mais maduras, cada detalhe do processo de desenvolvimento está definido,
quantificado e acompanhado e a organização consegue até absorver mudanças no processo
sem prejudicar o desenvolvimento. Veja a tabela 3.
Tabela 3: Níveis CMM Nível CMM Descrição 1) Inicial O processo de desenvolvimento é desorganizado e até caótico. Poucos
processos são definidos e o sucesso depende de esforços individuais e heróicos.
2) Repetível Os processos básicos de gerenciamento de projeto estão estabelecidos e permitem acompanhar custo, cronograma e funcionalidade. É possível repetir o sucesso de um processo utilizado anteriormente em outros projetos similares.
3) Definido Tanto as atividades de gerenciamento quanto de engenharia do processo de desenvolvimento de software estão documentadas, padronizadas e integradas em um padrão de desenvolvimento da organização. Todos os projetos utilizam uma versão aprovada e adaptada do processo padrão de desenvolvimento de software da organização.
4) Gerenciado São coletadas medidas detalhadas da qualidade do produto e processo de desenvolvimento de software. Tanto o produto quanto o processo de desenvolvimento de software são entendidos e controlados quantitativamente.
5) Otimizado O melhoramento contínuo do processo é conseguido através de um "feedback" quantitativo dos processos e pelo uso pioneiro de idéias e tecnologias inovadoras.
Fonte: Barreto [200-].
Uma empresa no nível 1 não dá garantia de prazo, custo ou funcionalidade. No nível 2,
a empresa já consegue produzir bons softwares, no prazo e a um custo previsível. O nível 3
14
garante um excelente nível de qualidade, tanto no produto quanto no processo de
desenvolvimento como um todo. Não há, no mundo, muitas empresas que tenham chegado
aos níveis 4 e 5 (BARRETO [200-]).
2.1.3 SPICE
Segundo Rocha (2001) Spice (Software Process Improvement and Capability
Determination) é o nome do projeto de elaboração da norma ISO/IEC 15504, que se presta à
realização de avaliações de processos de software com dois objetivos:
a) melhoria dos processos;
b) determinação da capacidade de processos de uma organização.
Uma das contribuições do modelo SPICE é definir em seu modelo de referência todos
os processos envolvidos no desenvolvimento de software, agrupados em categorias
(BARRETO [200-]). Observe na tabela 4 a estrutura completa das categorias e dos processos
de cada categoria.
O SPICE, entretanto, não se limita a listar categorias e processos. Seu principal
objetivo é avaliar a capacitação da organização em cada processo e permitir a sua melhoria. O
modelo de referência do SPICE inclui seis níveis de capacidade. Cada um dos processos
mencionados acima deve ser classificado nestes níveis (BARRETO [200-]). Os níveis são
descritos na tabela 5.
15
Tabela 4: Categorias e Processos Processo Descrição CUS – Cliente – Fornecedor Processos que provocam impacto diretamente nos produtos e serviços de software do fornecedor para o cliente. CUS. 1 Adquirir Software. CUS. 2 Gerenciar necessidades do Cliente. CUS. 3 Fornecer Software. CUS. 4 Operar Software. CUS. 5 Prover Serviço ao Cliente. ENG – Engenharia Processos que especificam, implementam ou mantém um sistema ou produto de software e sua documentação. ENG. 1 Desenvolver requisitos e o projeto do sistema. ENG. 2 Desenvolver requisitos de software. ENG. 3 Desenvolver o projeto do software. ENG. 4 Implementar o projeto do software. ENG. 5 Integrar e testar o software. ENG. 6 Integrar e testar o sistema. ENG. 7 Manter o sistema e o software. SUP – Suporte Processos que podem ser empregados por qualquer um dos processos. SUP. 1 Desenvolver a documentação. SUP. 2 Desempenhar a gerência de configuração. SUP. 3 Executar a garantia da qualidade. SUP. 4 Executar a verificação dos produtos de
trabalho. SUP. 5 Executar a validação dos produtos de
trabalho. SUP. 6 Executar revisões conjuntas. SUP. 7 Executar auditorias. SUP. 8 Executar resolução de problemas. MAN – Gerência Processos que contém práticas de natureza genérica que podem ser usadas por quem gerencia projetos ou processos dentro de um ciclo de vida de software. MAN. 1 Gerenciar o projeto. MAN. 2 Gerenciar a qualidade. MAN. 3 Gerenciar riscos. MAN. 4 Gerenciar subcontratantes. ORG – Organização Processos que estabelecem os objetivos de negócios da organização. ORG. 1 Construir o negócio. ORG. 2 Definir o processo. ORG. 3 Melhorar o processo. ORG. 4 Prover recursos de treinamento. ORG. 5 Prover infra-estrutura organizacional. Fonte: Barreto [200-].
16
Tabela 5: Níveis Spice Nível Nome Descrição 0 Incompleto Há uma falha geral em realizar o objetivo do processo. Não existem
produtos de trabalho nem saídas do processo facilmente identificáveis. 1 Realizado O objetivo do processo em geral é atingido, embora não necessariamente
de forma planejada e controlada. Há um consenso na organização de que as ações devem ser realizadas e quando são necessárias. Existem produtos de trabalho para o processo e eles são utilizados para atestar o atendimento dos objetivos.
2 Gerenciado O processo produz os produtos de trabalho com qualidade aceitável e dentro do prazo. Isto é feito de forma planejada e controlado. Os produtos de trabalho estão de acordo com padrões e requisitos.
3 Estabelecido O processo é realizado e gerenciado usando um processo definido, baseado em princípios de Engenharia de Software. As pessoas que implementam o processo usam processos aprovados, que são versões adaptadas do processo padrão documentado.
4 Previsível O processo é realizado de forma consistente, dentro dos limites de controle, para atingir os objetivos. Medidas da realização do processo são coletadas e analisadas. Isto leva a um entendimento quantitativo da capacitação do processo a uma habilidade de predizer a realização.
5 Otimizado A realização do processo é otimizada para atender as necessidades atuais e futuras do negócio. O processo atinge seu objetivo de negócio e consegue ser repetido. São estabelecidos objetivos quantitativos de eficácia e eficiência para o processo, segundo os objetivos da organização. A monitoração constante do processo segundo estes objetivos é conseguida obtendo feedback quantitativo e o melhoramento é conseguido pela análise dos resultados. A otimização do processo envolve o uso piloto de idéias e tecnologias inovadoras, além da mudança de processos ineficientes para atingir os objetivos definidos.
Fonte: Barreto [200-].
2.2 TRABALHOS CORRELATOS
Há pelo menos três estudos desenvolvidos na FURB interligados com este Trabalho de
Conclusão de Curso. São eles: Theilacher (2000), Frare (1998) e Anacleto (1996).
2.2.1 Theilacher
O trabalho desenvolvido por Theilacher (2000) informa a existência de modelos de
qualidade de software, no qual são incluídos a Norma ISO 9001, NBR ISO/IEC 12207,
BOOTSTRAP, SPICE e explica em detalhes o modelo CMM fazendo referência ao seu
histórico, conceito, estrutura, formas de avaliação e evolução. Foi feito em forma de estágio
na empresa Datasul havendo então uma apresentação desta que inclui o seu histórico, áreas da
atuação, processo de software e qualidade já aplicados pela empresa.
17
Em cada fase da avaliação do processo de software ocorre uma descrição das
atividades desenvolvidas incluindo: seleção de equipe de avaliação, aplicação do questionário
da maturidade, análise das respostas, entrevistas e revisões dos documentos, avaliação
baseada no modelo e método proposto pelo CMMI e quadro de verificação das áreas-chave de
processo.
O protótipo de software de apoio foi desenvolvido utilizando-se o Progress versão
8.3C e realiza o gerenciamento dos questionários previstos no modelo.
Além disto o relatório de Estágio Supervisionado incluiu a apresentação, especificação
e demonstração do funcionamento do protótipo.
2.2.2 Anacleto
O trabalho de Anacleto (1996) apresenta um estudo do modelo CMM, propondo uma
forma de mensuração do processo de software.
O modelo CMM é explicado em detalhes incluindo suas origens, conceitos, estrutura e
formas de avaliação além de explicar superficialmente os modelos ISO 9000-3, NBR ISO/IEC
1207, Spice e BOOTSRAPT.
Houve a criação de três questionários do modelo CMM. O primeiro questionário tem o
objetivo de obter o perfil da organização a ser avaliada. O segundo questionário objetiva
verificar se a organização atende as diversas metas definidas para todas as áreas-chave do
processo de software. O terceiro questionário objetiva checar, após a análise dos resultados do
segundo questionário, a efetividade das atividades que sustentam as diversas áreas-chave do
processo e suas metas respectivamente.
O questionário foi aplicado pelos alunos de Análise e Projeto de Sistemas I através de
entrevista em 17 empresas. Com as respostas houve a avaliação das mesmas.
O trabalho também inclui a descrição, definição e explicação do protótipo, sendo que
este foi desenvolvido em Microsoft Access e realiza as perguntas criadas nos três
questionários e fornece o resultado quanto ao atendimento do modelo.
18
2.2.3 Frare
O trabalho de Frare (1998) apresenta conceitos de qualidade de software e os modelos
ISO 9001, ISO 9000-3, CMM, Spice e BOOTSTRAP.
Além disto contém a explicação da Norma NBR ISO/IEC 12207, fases de implantação
e roteiro de aplicação da Norma.
Um roteiro que facilite a implantação da Norma NBR ISO/IEC 12207 é criado e
apresentado através de diagramas servindo então como um guia para o responsável pela
implementação da norma em uma organização.
O roteiro é apoiado por um protótipo de ferramenta, que é um roteiro eletrônico. Todas
as recomendações e ações inseridas nos diagramas podem ser obtidas da mesma forma
usando-se tal ferramenta, guiando assim o responsável pela implantação por computador.
E ainda, o trabalho apresenta sugestões de melhorias do roteiro e da ferramenta
sugerida.
19
3 A NORMA ISO/IEC 12207
Segunda a norma ISO/IEC 12207 (ASSOCIAÇÃO BRASILEIRA DE NORMAS
TÉCNICAS, 1998) software é uma parte fundamental da tecnologia de informação e de
sistemas convencionais, tais como sistemas de transportes, militares, da área médica e
financeira. Atualmente tem havido uma proliferação de normas, procedimentos, métodos,
ferramentas e ambientes de desenvolvimento e de gerência de software. Esta proliferação tem
criado dificuldades na gerência e engenharia de software, principalmente na integração de
produtos e serviços. A disciplina de software necessita migrar desta proliferação para uma
estrutura comum que possa ser usada por profissionais de software para “falar a mesma
língua” na criação e gerência de software. Esta Norma provê tal estrutura comum.
3.1 CARACTERÍSTICAS GERAIS
A seguir tem-se uma descrição completa das características da Norma ISO/IEC 12207.
3.1.1 Processos de Software
É o conjunto de todas as atividades relacionadas ao desenvolvimento, controle,
validação e manutenção de um software operacional, ligado tanto à área técnica quanto à
gerência (HUGO apud Frare (1998)).
O processo de software envolve os recursos disponíveis e é baseado nos requisitos
solicitados para o sistema, gerando os produtos ou serviços de software. Os modelos de
avaliação verificam se um processo de software é capaz de gerar produtos de software com
qualidade garantida (HUGO apud Frare (1998)).
3.1.2 Objetivo
A Norma ISO/IEC 12207 estabelece uma estrutura comum para os processos de ciclo
de vida de software desde a concepção de idéias até a descontinuação do software com uma
terminologia bem definida e é composta de processos, atividades e tarefas que servem para ser
aplicada durante a aquisição de um sistema que contém software, de um produto de software
independente ou de um serviço de software, e durante o fornecimento, desenvolvimento,
operação e manutenção de produtos de software. Além disto a Norma também provê um
20
processo que pode ser utilizado para definir, controlar e melhorar os processos de ciclo de
vida de software (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1998).
3.1.3 Campo de Aplicação
A Norma ISO/IEC 12207 (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS,
1998) aplica-se, quer seja executada interna ou externamente a uma organização, a auxiliar os
envolvidos na produção de software a definir seus papéis, por meio de processos bem
definidos, e assim proporcionar às organizações que a utilizam um melhor entendimento das
atividades a serem executadas nas operações que envolvem, de alguma forma, o software
(Rocha, 2001).
Destina-se a ser utilizada em uma relação que envolva duas partes, sendo que estas
podem pertencer à mesma organização. Esta relação pode ser estabelecida através de um
acordo informal ou um contrato legal e pode ser utilizada por uma única parte por meio de
tarefas impostas a ela mesma.
Os processos formam um conjunto abrangente. Uma organização, dependendo de seu
objetivo, pode selecionar um subconjunto apropriado para satisfazê-lo. Esta Norma é,
portanto, projetada para ser adaptada para uma organização, projeto ou aplicação específicos.
Também é projetada para ser utilizada quando o software é uma entidade independente ou
embutida ou integrada a um sistema.
A norma não se aplica para os produtos de software de prateleira, a menos que eles
estejam incorporados dentro de um produto encomendado e foi escrita para adquirentes de
sistemas e produtos e serviços de software, e para fornecedores, desenvolvedores, operadores,
mantenedores, gerentes, gerentes de garantia de qualidade e usuários dos produtos de
software.
3.1.4 Conformidade
Segundo ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (1998) a
conformidade a esta norma é definida como a execução de todos os processos, atividades e
tarefas. A execução de um processo ou uma atividade é concluída quando todas as suas
tarefas requeridas são executadas de acordo com os critérios preestabelecidos e com os
requisitos especificados no contrato, quando aplicável.
21
Para auxiliar a determinar o grau de requerimento de uma determinada tarefa a Norma
utiliza-se de verbos auxiliares que integram o corpo da tarefa. São eles:
a) deve: expressam uma obrigação entre duas ou mais partes;
b) deverá: expressa uma declaração de objetivo ou intenção de uma das partes;
c) deveria: expressa uma recomendação entre várias possibilidades;
d) pode: indica uma ação permitida dentro dos limites da Norma.
3.1.5 Limitações
Segundo ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (1998) a Norma
ISO/IEC 12207:
a) não especifica os detalhes de como implementar ou executar as atividades e tarefas
incluídas nos processos de ciclo de vida de software;
b) não pretende prescrever o nome, formato ou conteúdo explícito na documentação a
ser produzida. A Norma pode requerer o desenvolvimento de documentos de
mesma categoria ou tipo, contudo não sugere que tais documentos sejam
desenvolvidos ou emitidos separadamente ou combinados de alguma forma. Estas
decisões são deixadas para o usuário da Norma;
c) não prescreve um modelo específico de ciclo de vida ou método de
desenvolvimento de software. As partes envolvidas com esta Norma são
responsáveis pela seleção de um modelo de ciclo de vida para o projeto de software
e pelo mapeamento dos processos, atividades e tarefas da Norma dentro do modelo.
As partes envolvidas são também responsáveis pela seleção e aplicação dos
métodos de desenvolvimento de software e pela execução das atividades e tarefas
adequadas ao projeto de software;
d) não pretende entrar em conflito com quaisquer políticas, normas ou procedimentos
já existentes na organização. Entretanto, qualquer conflito necessita ser resolvido e
quaisquer condições e situações de sobreposição precisam ser citadas por escrito
como exceções para a aplicação da Norma.
3.2 ESTRUTURA DA NORMA
A norma ISO/IEC 12207 agrupa as atividades que podem ser executadas durante o
ciclo de vida de software em cinco processos fundamentais, oito processos de apoio e quatro
22
processos organizacionais. Cada processo de ciclo de vida é dividido em um conjunto de
atividades, cada atividade é então dividida em um conjunto de tarefas. Para maiores detalhes
veja a fig. 1.
Fonte: ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (1998). Figura 1: Estrutura da Norma ISO/IEC 12207
3.2.1 Processos Fundamentais
Segundo (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 1998) os
processos fundamentais constituem um conjunto de cinco processos que atendem as partes
fundamentais (pessoa ou organização) durante o ciclo de vida de software. Uma parte
fundamental é aquela que inicia ou executa o desenvolvimento, operação ou manutenção dos
23
produtos de software. Estas partes fundamentais são o adquirente, o fornecedor, o
desenvolvedor, o operador e o mantenedor do software.
Os conceitos sobre os processos a seguir foram extraídos de (ASSOCIAÇÃO
BRASILEIRA DE NORMAS TÉCNICAS, 1998).
3.2.1.1 Processo de Aquisição
O processo de aquisição contém as atividades e tarefas do adquirente. Inicia-se com a
definição da necessidade de adquirir um sistema, um produto de software ou um serviço de
software. O processo continua com a preparação e emissão de pedido de proposta, seleção de
fornecedor e gerência do processo de aquisição através da aceitação do sistema, produto de
software ou serviço de software.
As organizações individuais, que tem a necessidade, podem ser chamadas de
proprietárias. O proprietário pode contratar algumas ou todas as atividades de aquisição junto
a um agente que, por sua vez conduzirá estas atividades de acordo com o processo de
aquisição. O adquirente então pode ser tanto o proprietário quanto o agente contratado por ele.
3.2.1.2 Processo de Fornecimento
O processo de fornecimento contém as atividades e as tarefas do fornecedor. O
processo pode ser iniciado tanto por uma decisão de preparar uma proposta para responder a
um pedido de proposta de um adquirente quanto pela assinatura e celebração de um contrato
com o adquirente para fornecer o sistema, produto de software ou serviço de software. O
processo continua com a determinação dos procedimentos e recursos necessários para
gerenciar e garantir o projeto, incluindo o desenvolvimento e a execução dos planos de
projeto até a entrega do sistema, produto de software ou serviço de software para o
adquirente.
3.2.1.3 Processo de Desenvolvimento
O processo de desenvolvimento contém as atividades e tarefas do desenvolvedor. O
processo contém as atividades para análise de requisitos, projeto, codificação, integração,
testes, instalação e aceitação relacionadas aos produtos de software. Pode conter atividades
24
relacionadas ao sistema, se estipulado no contrato. O desenvolvedor executa ou apóia as
atividades neste processo, de acordo com o contrato.
3.2.1.4 Processo de Operação
O processo de operação contém as atividades e as tarefas do operador. O processo
cobre a operação do produto de software e o suporte operacional aos usuários. Como a
operação do produto de software está integrada à operação do sistema, as atividades e tarefas
deste processo se referem ao sistema.
3.2.1.5 Processo de Manutenção
O processo de manutenção contém as atividades e tarefas do mantenedor. Este
processo é ativado quando o produto de software é submetido a modificações no código e na
documentação associada devido a um problema, ou à necessidade de melhoria ou adaptação.
O objetivo é modificar um produto de software existente, preservando a sua integridade. Este
processo inclui a migração e a descontinuação do produto de software. O processo termina
com a descontinuação do produto de software.
3.2.2 Processos de Apoio
Os processos de apoio ao ciclo de vida constituem um conjunto de oito processos. Um
processo de apoio auxilia um outro processo como uma parte integrante, com um propósito
distinto, e contribui para o sucesso e qualidade do projeto de software. Um processo de apoio
é empregado e executado, quando necessário, por outro processo. Os processos de apoio são
mostrados a seguir.
3.2.2.1 Processo de Documentação
O processo de documentação é um processo para registrar informações produzidas por
um processo ou atividade do ciclo de vida. O processo contém o conjunto de atividades que
planeja, projeta, desenvolve, produz, edita, distribui e mantém aqueles documentos
necessários a todos os interessados, tais como gerentes, engenheiros e usuários do sistema ou
produto de software.
25
3.2.2.2 Processo de Gerência de Configuração
Processo de gerência de configuração é um processo de aplicação de procedimentos
administrativos e técnicos, por todo o ciclo de vida de software, destinado a identificar e
definir os itens de software em um sistema e estabelecer suas linhas básicas; controlar as
modificações e liberações dos itens; registrar e apresentar a situação dos itens e dos pedidos
de modificação; garantir a completeza, a consistência e a correção dos itens; e controlar o
armazenamento, a manipulação e distribuição dos itens.
3.2.2.3 Processo de Garantia de Qualidade
O processo de garantia de qualidade é um processo para fornecer garantia adequada de
que os processos e produtos de software, no ciclo de vida do projeto, estejam em
conformidade com seus requisitos especificados e sejam aderentes aos planos estabelecidos.
Para ser imparcial, a garantia de qualidade necessita ter autoridade e autonomia
organizacional, independente das pessoas diretamente responsáveis pelo desenvolvimento do
produto de software ou pela execução do processo do projeto.
A garantia de qualidade pode ser interna ou externa, dependendo da necessidade da
qualidade do produto ou do processo ser evidenciado para a gerência do fornecedor ou do
adquirente.
A garantia de qualidade pode utilizar os resultados de outros processos de apoio tais
como: verificação, validação, revisões conjuntas, auditorias e resolução do problema.
3.2.2.4 Processo de Verificação
O processo de verificação é um processo para determinar se os produtos de software de
uma atividade atendem completamente os requisitos ou condições impostas a eles nas
atividades anteriores. Para a eficácia de custo e desempenho, a verificação deveria ser
integrada, o quanto antes, com o processo que a utiliza (tais como fornecimento,
desenvolvimento, operação ou manutenção). Este processo pode incluir análise, revisão e
teste.
26
3.2.2.5 Processo de Validação
O processo de validação é um processo para determinar se os requisitos e o produto
final, sistema ou produto de software construído, atendem ao uso específico pretendido. A
validação pode ser conduzida como parte ou atividade de apoio à aceitação do software.
3.2.2.6 Processo de Revisão Conjunta
O processo de revisão conjunta é um processo para avaliar a situação e produtos de
uma atividade de um projeto, se apropriado. As revisões conjuntas são feitas tanto nos níveis
de gerenciamento do projeto como nos níveis técnicos e são executados durante a vigência do
contrato. Este processo pode ser empregado por qualquer das duas partes, onde uma parte
(parte revisora) revisa a outra parte (parte revisada).
3.2.2.7 Processo de Auditoria
O processo de auditoria é um processo para determinar adequação aos requisitos,
planos e contrato, quando apropriado. Este processo pode ser empregado por quaisquer das
duas partes, onde uma parte (parte auditora) faz a auditoria nos produtos de software ou nas
atividades da outra parte (parte auditada).
3.2.2.8 Processo de Resolução de Problemas
O processo de resolução de problema é um processo para analisar e resolver os
problemas (incluindo não-conformidades), de qualquer natureza ou fonte, que são descobertos
durante a execução do desenvolvimento, operação, manutenção ou outros processos. O
objetivo é prover os meios em tempo adequado e de forma responsável e documentada para
garantir que todos os problemas encontrados sejam analisados e resolvidos e tendências sejam
identificadas.
3.2.3 Processos Organizacionais
Os processos organizacionais de ciclo de vida constituem um conjunto de quatro
processos. Eles são empregados por uma organização para estabelecer e implementar uma
estrutura subjacente, constituída de processos de ciclo de vida e pessoal associado e melhorar
continuamente a estrutura e os processos. Eles são tipicamente empregados fora do domínio
27
de projetos e contratos específicos; entretanto, ensinamentos destes projetos e contratos
contribuem para a melhoria da organização.
3.2.3.1 Processo de Gerência
O processo de gerência contém as atividades e tarefas genéricas que podem ser
empregadas por quaisquer das partes que têm que gerenciar seu(s) respectivo(s) processo(s).
O gerente é responsável pelo gerenciamento de tarefa do(s) processo(s) aplicável(eis), tais
como aquisição, fornecimento, desenvolvimento, operação, manutenção ou processos de
apoio.
3.2.3.2 Processo de Infra-estrutura
O processo de infra-estrutura é um processo para estabelecer e manter a infra-estrutura
necessária para qualquer outro processo. A infra-estrutura pode incluir hardware, software,
ferramentas, técnicas, padrões e recursos para o desenvolvimento, operação ou manutenção.
3.2.3.3 Processo de Melhoria
O processo de melhoria é um processo para estabelecer, avaliar, medir, controlar e
melhorar um processo de ciclo de vida de software.
3.2.3.4 Processo de Treinamento
O processo de treinamento é um processo para prover e manter pessoal treinado. A
aquisição, o fornecimento, o desenvolvimento, a operação ou a manutenção de produtos de
software é extremamente dependente de pessoal com conhecimento e qualificação. Por
exemplo: pessoal de desenvolvimento deveria ter treinamento básico em gerência de software
e engenharia de software. É, portanto, imperativo que o treinamento de pessoal seja planejado
e implementado com antecedência para que o pessoal treinado esteja disponível quando o
produto de software for adquirido, fornecido, desenvolvido, operado ou mantido.
3.3 RELAÇÃO CMM E NBR ISO/IEC 12207
A Norma NBR ISO/IEC 12207 parece alcançar o nível 3 de maturidade do CMM. Esta
correlação fica mais clara através da tabela 6, que demonstra o mapeamento do
28
relacionamento entre as áreas-chave de processo do CMM e os processos da Norma NBR
ISO/IEC 12207 (GRAHL, 1997).
Outros processos da Norma NBR ISO/IEC 12207 não citados na tabela 6 também são
utilizados em sua aplicação. Como por exemplo, o processo de Documentação que provê
meios de registro de informações produzidas por qualquer processo (GRAHL, 1997).
Tabela 6 – Relacionamento entre CMM e Norma NBR ISO/IEC 12207 Nível CMM Áreas-Chave de Processo CMM Processos da ISO/IEC 12207 2 Gerenciamento de Requisitos Aquisição, Fornecimento 2 Planejamento do Projeto de Software Aquisição, Fornecimento, Gerência 2 Acompanhamento e Supervisão do Projeto Gerência, Revisão Conjunta,
Resolução de Problema 2 Gerenciamento da Sub-Contratação de Software Aquisição, Fornecimento 2 Garantia da Qualidade de Software Garantia da Qualidade, Verificação,
Validação, Revisão Conjunta, Auditoria, Resolução de Problema
2 Gerenciamento de Configuração de Software Gerência de Configuração 3 Foco nos Processos da Organização Melhoria 3 Definição do Processo da Organização Melhoria, Desenvolvimento 3 Programa de Treinamento Treinamento 3 Gerenciamento Integrado de Software Gerência, Desenvolvimento 3 Engenharia do Produto de Software Desenvolvimento, Manutenção 3 Coordenação Inter-Grupos Desenvolvimento, Revisão Conjunta,
Resolução de Problema 3 Revisões Revisão Conjunta, Resolução de Problema 4 Gerenciamento Quantitativo do Processo Melhoria 4 Gerenciamento da Qualidade de Software Garantia da Qualidade, Validação 5 Prevenção de Defeitos Resolução de Problema, Melhoria,
Revisão Conjunta 5 Gerenciamento da Mudança de Tecnologia Infra-estrutura 5 Gerenciamento da Mudança do Processo Melhoria Fonte: retirado de Grahl (1997)
A tabela 7 mostra os graus de atendimento de cada área-chave de processo do CMM
pela Norma NBR ISO/IEC 12207. Os resultados apresentados baseiam-se na verificação do
atendimento das metas estabelecidas em cada área-chave. Uma área-chave possui um alto
grau de atendimento quando 2/3 ou mais de suas metas possui relação direta com atividades e
tarefas dos processos da Norma NBR ISO/IEC 12207. Uma área-chave possui um baixo grau
de atendimento quando menos de 1/3 de suas metas possui relação direta com atividades e
tarefas dos processos da Norma NBR ISO/IEC 12207. Finalmente, o grau médio encontra-se
entre as duas faixas citadas (GRAHL, 1997).
29
Tabela 7 - Grau de atendimento de cada área-chave Nível Áreas-Chave de Processo CMM Grau de Atendimento CMM Baixo Médio Alto 2 Gerenciamento de Requisitos 2 Planejamento do Projeto de Software 2 Acompanhamento e Supervisão do Projeto 2 Gerenciamento da Sub-Contratação de
Software
2 Garantia da Qualidade de Software 2 Gerenciamento de Configuração de
Software
3 Foco nos Processos da Organização 3 Definição do Processo da Organização 3 Programa de Treinamento 3 Gerenciamento Integrado de Software 3 Engenharia do Produto de Software 3 Coordenação Inter-Grupos 3 Revisões 4 Gerenciamento Quantitativo do Processo 4 Gerenciamento da Qualidade de Software 5 Prevenção de Defeitos 5 Gerenciamento da Mudança de
Tecnologia
5 Gerenciamento da Mudança do Processo Fonte: retirado de Grahl (1997)
30
4 DESENVOLVIMENTO DO TRABALHO
O objetivo deste trabalho é desenvolver um software para auxiliar na avaliação da
adequação de uma empresa aos Processos Fundamentais do ciclo de vida da Norma NBR
ISO/IEC 12207 e determinar o nível CMM da empresa onde o software foi utilizado para
validar os resultados obtidos.
Através dos resultados fornecidos pelo software desenvolvido são obtidos os itens
adotados nos Processos Fundamentais do ciclo de vida da Norma NBR ISO/IEC 12207. O
nível CMM é obtido através da aplicação dos questionários desenvolvidos por Anacleto
(1996).
O software e os questionários foram aplicados em uma grande empresa do setor
alimentício da região que atualmente possui 13.000 funcionários e que obteve o faturamento
de R$ 1,7 bilhões em 2002.
O setor responsável pelo desenvolvimento de softwares desta empresa é composto de
20 funcionários e 4 terceiros, sendo que todos os itens aplicados foram respondidos pelo
gerente do setor que possui como formação acadêmica o Bacharelado em Ciências Contábeis
(FURB), pós-graduação em Administração de Negócios (INPG) e que trabalha na área de
Informática desde 1979.
4.1 DETERMINAÇÃO DO NÍVEL CMM
Para determinar o atual nível CMM da empresa foram aplicados os questionários
desenvolvidos por Anacleto (1996) e para obter maiores informações sobre os mesmos
Anacleto (1996) pode ser consultada.
A metodologia utilizada pela empresa no desenvolvimento de seus sistemas encontra-
se no Anexo A.
O primeiro questionário que objetiva obter o perfil da organização (ANACLETO,
1996) encontra-se respondido no Anexo B.
O segundo questionário que objetiva verificar se a organização atende as diversas
metas definidas para todas as áreas-chave do processo de software (ANACLETO, 1996)
encontram-se respondido no Anexo C.
31
Com o segundo questionário respondido realizou-se o mapeamento das questões por
áreas-chaves de processo e determinou-se que apenas as perguntas 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 41, 42, 43, 44, 45, 46, 47, 48, 61, 62, 63,
64, 65, 66, 67, 68, 69, 70, 71 e 72 do terceiro questionário deveriam ser feitas à empresa.
O terceiro questionário que objetiva checar a efetividade das atividades que sustentam
as diversas áreas-chaves de processo e suas metas (ANACLETO, 1996) encontra-se
respondido no Anexo D.
Tabela 8 – Atendimento a área-chave de processo CMM Não Atende Atende Parcialmente Atende Nível 1 – Inicial X Nível 2 – Repetitivo X Gerenciamento de Configuração de Software
X
Garantia da Qualidade de Software X Gerenciamento da Sub-Contratação de Software
X
Acompanhamento e Supervisão do Projeto de Software
X
Planejamento do Projeto de Software X Gerenciamento de Requisitos de Software X Nível 3 – Definido X Revisões X Coordenação Inter-Grupos X Engenharia do Produto de Software X Gerenciamento Integrado de Software X Programa de Treinamento X Definição do Processo da Organização X Foco nos Processos da Organização X Nível 4 – Gerenciado X Gerenciamento da Qualidade de Software X Gerenciamento Quantitativo do Processo X Nível 5 – Otimização X Gerenciamento da Mudança do Processo X Gerenciamento da Mudança de Tecnologia X Prevenção de Defeitos X
Analisando-se as respostas obtidas do terceiro questionário pode-se determinar que a
empresa atualmente está no Nível 1 – Inicial do CMM, pois o nível 2 não foi atendido e
especificamente nenhuma área-chave de processo foi atendida no nível 2 (tabela 8).
32
4.2 QUESTIONÁRIO DA NORMA NBR ISO/IEC 12207
O questionário desenvolvido neste trabalho trata os Processos Fundamentais de Ciclo
de Vida da Norma NBR ISO/IEC 12207 e encontra-se no Apêndice A.
Os processos de apoio e organizacionais de ciclo de vida não são tratados neste
trabalho acadêmico.
Como já foi mencionado a Norma NBR ISO/IEC 12207 é dividida em processos,
atividades e tarefas.
As perguntas foram criadas pela análise das tarefas. Através desta determinou-se a
quantidade de ações necessárias para realizar individualmente cada tarefa presente na Norma.
Cada tarefa gerou n perguntas, sendo que n é igual ao número de ações encontradas no
corpo de texto da tarefa.
Cada pergunta gerada possui um peso e este é determinado pelo verbo auxiliar
utilizado no corpo de texto da tarefa. A pergunta gerada por uma tarefa que possui o verbo
deve, deverá, deveria e pode vale, se cumprida, 10, 5,2 e 1 pontos respectivamente.
As perguntas possuem as seguintes respostas possíveis:
a) sim – quando a pergunta foi cumprida. Se selecionada, o valor do peso da pergunta
é acrescido à pontuação total do usuário;
b) não – quando a pergunta não foi cumprida. Se selecionada, nada é acrescido à
pontuação total do usuário;
c) múltipla escolha – a pergunta é composta por uma série de itens de resposta. O
usuário seleciona os itens de resposta cumpridos, sendo que para auxiliar existe o
item de resposta “Todas as opções” que deve ser selecionado quando todos são
cumpridos e o item de resposta “Nenhuma das opções” que deve ser selecionado
quando nenhum é cumprido. Cada item de resposta possui como peso um valor
proporcional ao peso da pergunta. Por exemplo: uma pergunta que tenha como peso
o valor 10 e que possua 5 itens de resposta terá cada item cumprido acrescentando 2
pontos a pontuação total do usuário.
33
O Apêndice A também contém as soluções para os itens de resposta do questionário e
as dependências das perguntas. Com relação às soluções para os itens de resposta do
questionário deve-se observar que os itens de resposta “Sim” e “Todas as opções” indicam
que a pergunta foi cumprida e conseqüentemente não possuem solução e o item de resposta
“Nenhuma das opções” também não possui solução cadastrada, pois quando selecionado fará
que seja mostrada ao usuário a solução de todos os itens de resposta da pergunta.
Um resumo das perguntas criadas pode ser observado na tabela 9.
Tabela 9 – Resumo das perguntas criadas
34
Processo Atividade Perguntas Aquisição Iniciação 11 Preparação do Pedido de Proposta 08 Preparação e atualização do contrato 09 Monitoração do fornecedor 03 Aceitação e Conclusão 06 Fornecimento Iniciação 02 Preparação de resposta 02 Contrato 02 Planejamento 12 Execução e controle 07 Revisão e avaliação 11 Entrega e conclusão 03 Fornecimento Implementação do processo 08 Análise dos requisitos do sistema 06 Projeto da arquitetura do sistema 11 Análise dos requisitos do software 06 Projeto da arquitetura do software 19 Projeto detalhado do software 21 Codificação e testes de software 14 Integração do software 29 Testes de qualificação do software 22 Integração do sistema 08 Teste de qualificação do sistema 09 Instalação do software 10 Apoio à aceitação do software 06 Operação Implementação do processo 05 Teste operacional 03 Operação do sistema 01 Suporte ao usuário 07 Manutenção Implementação do processo 04 Análise do problema e da modificação 10 Implementação da modificação 08 Revisão/aceitação da manutenção 03 Migração 14 Descontinuação da manutenção 10
4.3 REQUISITOS PRINCIPAIS DO SOFTWARE
Procurando facilitar o processo de avaliação optou-se pela criação de um aplicativo
web, pois seu acesso poderá ser feito de qualquer computador conectado a Internet.
A página inicial do aplicativo (www.flynet.com.br/12207) mostrará uma breve
descrição da Norma NBR ISO/IEC 12207, explicando sua importância e informando que será
35
possível determinar ao usuário se os processos utilizados pela sua organização no
desenvolvimento de software estão de acordo com a Norma NBR ISO/IEC 12207.
Para isso será necessário cadastrar-se. Este processo solicitará que seja informado um
usuário, senha, redigitação da senha e endereço de e-mail.
Com o cadastro efetuado o usuário poderá efetuar o logon no software e acessar a área
de questionários, área de relatórios e área administrativa.
Ao acessar a área de questionários o usuário poderá escolher o processo que será
respondido. Não haverá problemas se o usuário efetuar logout sem o processo estar totalmente
respondido. Quando efetuar logon novamente poderá optar por responder um novo processo
ou continuar respondendo um processo iniciado anteriormente. Caso opte por continuar
respondendo um processo a primeira pergunta a ser feita será a próxima da ordem, tomando-
se como referência a última pergunta respondida do processo escolhido.
Após terminar de responder inteiramente um processo o usuário poderá obter a análise
de suas respostas. Estas serão fornecidas na área de relatórios do Software. A análise poderá
ser sintética ou detalhada. A análise sintética informará o percentual de adequação à Norma
NBR ISO/IEC 12207, sendo esta oferecida para cada par Processo/Atividade. A análise
detalhada além de fornecer os dados da análise sintética oferecerá recomendações para a
organização ficar de acordo com a Norma NBR ISO/IEC 12207.
A área administrativa somente será acessada se o usuário utilizado possuir o nível
“Administrador”. O processo de cadastro que estará na página principal fornecerá
automaticamente ao usuário informado o nível “Normal” e este somente poderá ser alterado
na “Manutenção de Usuários” que estará na área administrativa, ou seja, somente quem
possuir o nível “Administrador” poderá alterar o nível de um usuário específico. Também será
permitido na área administrativa:
a) cadastrar processo. Informação requerida: descrição;
b) cadastrar atividade. Informação requerida: processo no qual a nova atividade será
subordinada e descrição;
c) cadastrar pergunta. Informação requerida: processo e atividade no qual a nova
pergunta será subordinada, descrição, tipo (Sim/Não ou Múltipla Escolha) e peso.
Após o envio destas informações será solicitado ao usuário que seja fornecido os
36
Itens de Resposta/Soluções para esta nova pergunta. Se a nova pergunta for do tipo
“Sim/Não” os itens de resposta “Sim” e “Não” serão cadastrados automaticamente
sendo solicitado ao usuário apenas à solução do item de resposta “Não”. Se a nova
pergunta for do tipo “Múltipla Escolha” será solicitado ao usuário que seja
preenchido a descrição e solução de todos os itens de resposta, sendo que não
haverá limite no número destes. Ao cadastrar um novo Item de Resposta/Solução
será possível visualizar todos os Itens de Resposta/Soluções já cadastrados para esta
nova pergunta;
d) alterar processo cadastrado. Informação requerida: nova descrição para o processo;
e) alterar atividade cadastrada. Informação requerida: nova descrição para a atividade;
f) alterar pergunta cadastrada. Informação requerida: nova descrição para a pergunta.
Será também permitido alterar o tipo e peso da pergunta. Caso o tipo (Sim/Não ou
Opções) seja alterado será perguntado ao usuário se realmente deseja aplicar esta
alteração e sendo a resposta afirmativa todas os Itens de Resposta/Soluções serão
excluídos e o cadastramento de novos Itens de Resposta/Soluções conforme o novo
tipo selecionado será solicitado;
g) alterar Item de Resposta/Solução. Informação requerida: nova descrição para o Item
de Resposta/Solução;
h) alterar a ordem em que serão perguntadas as atividades, perguntas e itens de
resposta no questionário;
i) excluir processo;
j) excluir atividade;
k) excluir pergunta;
l) excluir item de resposta;
m) criação de dependências. Informação requerida: determinação do par Item de
Resposta/Pergunta. Todas as perguntas sem dependência serão feitas ao usuário.
Para restringir que uma determinada pergunta seja feita deve-se criar uma
dependência para a mesma. Por exemplo, não seria correto perguntar “A definição e
análise dos requisitos do software é realizada internamente (por conta própria) ou é
terceirizada?” se na pergunta anterior o usuário respondeu que em nenhum
momento ocorre a definição e análise dos requisitos do software. Para evitar esta
situação deve-se criar uma dependência informando que a pergunta “A definição e
análise dos requisitos do software é realizada internamente (por conta própria) ou é
37
terceirizada?” somente seja feita se o usuário selecionar o item de resposta “Sim”
da pergunta “Quanto ao sistema, ocorre a definição e análise de seus requisitos?”.
Será possível criar os seguintes tipos de dependência:
- um Item de resposta/Pergunta. Se o item de resposta for selecionado habilitará
a pergunta no questionário feito ao usuário;
- vários Itens de resposta/Pergunta. Se algum dos itens de resposta estiver
selecionado habilitará a pergunta no questionário feito ao usuário;
- em cascata. Criar uma dependência da dependência.
n) manutenção de usuários: além de permitir que seja possível alterar o nível de um
usuário específico, também será permitido que seja cadastrado novo usuário;
4.4 ESPECIFICAÇÃO
A especificação do aplicativo web foi baseada na técnica Unified Modeling Language
(UML) utilizando a ferramenta Rational Rose. Este ferramenta foi escolhida por ser uma
ferramenta que dá suporte a todos os diagramas UML utilizados nesta especificação, e por ter
sido abordado durante o período acadêmico. Os diagramas utilizados foram: diagrama de
casos de uso, diagrama de classes e diagrama de seqüência.
4.4.1 Casos de Uso
Os casos de uso do aplicativo podem ser observados na fig. 2. Abaixo se tem a
descrição dos mesmos.
Criar Processo: o administrador informa a descrição do processo.
Criar Atividade: o administrador informa o processo em que a atividade estará
subordinada e sua descrição.
Criar Tarefa: o administrador informa o processo e atividade em que a tarefa estará
subordinada, sua descrição, tipo e peso. Se o tipo informado for 1 o administrador informa a
solução do item de resposta “Não” e se o tipo informado for 2 o administrador informa o par
item de resposta/solução, sendo que não há limite para este.
Criar dependência: o administrador seleciona o par pergunta/item de resposta para criar
a dependência.
38
Criar usuário: o administrador e respondente informam usuário, senha, redigitação da
senha e endereço de e-mail. Contudo o administrador possui a opção de selecionar o nível do
novo usuário (“Normal” ou “Administrador”) enquanto todo novo usuário cadastrado pelo
respondente possui nível “Normal”.
FIGURA 2 – Casos de Uso
Responder Questionário: o usuário seleciona o processo que deseja responder e com
isso as perguntas começam a ser feitas. Para cada pergunta o usuário fornece uma resposta.
Com a resposta fornecida a próxima pergunta é feita. Quando não houver mais perguntas a
serem feitas será informado ao usuário que o processo foi respondido completamente.
Gerar relatório de Adequação: o relatório de adequação pode ser sintético ou
detalhado. No relatório sintético o usuário seleciona o processo desejado e é fornecido o
percentual de adequação a Norma para cada par processo/atividade. No relatório detalhado o
usuário seleciona um processo e são fornecidas as informações do relatório sintético e
recomendações para a organização ficar de acordo com a Norma NBR ISO/IEC 12207.
Gerar Relatorio de Adequacao
Responder questionario
Respondente
Criar ProcessoCriar Atividade
Criar Tarefa
Criar Dependencia
Criar usuario
Administrador
39
4.4.2 Diagramas de classes
O diagrama de classes do aplicativo pode ser observado na fig. 3. Abaixo se tem uma
explicação sobre o mesmo.
FIGURA 3 – Diagrama de classes
A classe Processo contém o código e a descrição dos processos da Norma.
A classe Atividade contém o código, descrição e ordem em que a atividade será
perguntada no questionário. Além disso, indica que a classe está subordinada à classe
Processo.
A classe Tarefa contém o código, descrição, tipo, peso e ordem que a tarefa será
perguntada no questionário e indica que a classe está subordinada à classe Atividade.
A classe Opção contém o código, descrição, solução e ordem em que a opção será
perguntada no questionário. Ocorre a indicação que uma tarefa pode ser respondida por uma
ou muitas opções e cada opção pertence a uma tarefa, pois o código da opção é único.
Usuario
cd_usuario : Integerusername : Stringpassword : Stringemail : Stringnivel : Integer
criar()
Processo
cd_processo : Integerds_processo : St ring
Criar()Obter()
Resposta
cd_resposta : Integer
Obter()Fornece()
0..*
1
0..*
1
fornece
Atividade
cd_atividade : Integerds_atividade : Stringord_at ividade : Integer
Criar()Obter()CalculaPercentualAdquacao()ObterSolucao()
1..*
1
1..*
1
Opcao
cd_opcao : Integerds_opcao : Stringsolucao : Stringord_opcao : Integer
Obter()Criar()SetaSolucao()
1..*1 1..*1
contem
Tarefa
cd_tarefa : Integerds_tarefa : Stringtipo : Integerpeso : Integerord_tarefa : Integer
Obter()Criar()InsereDependencia()ObterPeso()
1..*1 1..*1
0.. *
0..*
0.. *
0..*
depende
1..*
1
1..*
1
respondida
40
Também indica que uma tarefa pode depender de nenhuma ou várias opções e que uma opção
pode gerar nenhuma ou várias tarefas.
A classe Resposta armazena as respostas fornecidas pelo usuário.
A classe Usuário contém o código, nome de usuário, senha, endereço de e-mail e nível
dos usuários criados no aplicativo.
4.4.3 Diagrama de seqüência
Abaixo se podem observar os diagramas de seqüência dos casos de uso do aplicativo.
Criar Processo: o diagrama de seqüência pode ser observado na fig. 4.
FIGURA 4 – Diagrama de seqüência do caso de uso Criar Processo
Criar Atividade: o diagrama de seqüência pode ser observado na fig. 5.
: Administrador : Processo
Criar( )
41
FIGURA 5 – Diagrama de seqüência do caso de uso Criar Atividade
Criar Tarefa: o diagrama de seqüência pode ser observado na fig. 6 e na fig.7. Na fig. 6
o tipo informado é 1 e na fig. 7 o tipo informado é 2.
FIGURA 6 – diagrama de seqüência do caso de uso Criar Atividade (Tipo 1)
: Processo : Atividade : Administrador
Criar( )
Obter( )
: Administrador : Processo : Atividade : Tarefa : Opcao
Criar( )
Obter( )
Obter( )
Criar(Sim)
Criar(Nao)
SetaSolucao(Nao)
42
FIGURA 7 – diagrama de seqüência do caso de uso Criar Atividade (Tipo 2)
Criar Dependência: o diagrama de seqüência pode ser observado na fig. 8.
FIGURA 8 – Diagrama de seqüência do caso de uso Criar Dependência
: Respondente : Processo : Atividade : Tarefa
Obter( )
Obter( )
Criar( )
: Opcao
Criar( )
SetaSolucao( )
: Administrador : Tarefa : Opcao
Obter( )
Obter( )
InsereDependencia( )
43
Criar Usuário: o diagrama de seqüência pode ser observado na fig. 9.
FIGURA 9 – diagrama de seqüência do caso de uso Criar Usuário
Responder Questionário: o diagrama de seqüência pode ser observado na fig. 10
FIGURA 10 – diagrama de seqüência do caso de uso Responder Questionário
Gerar Relatório de Adequação: o diagrama de seqüência pode ser observado na fig. 11
e na fig. 12. A fig. 11 é referente ao relatório sintético e a fig. 12 é referente ao relatório
detalhado.
: Administrador : Usuario
criar()
: Respondente : Processo : Atividade : Opcao : Resposta : Tarefa
Obter( )
Obter( )
Obter( )
Obter( )
Fornece( )
44
FIGURA 11 – Diagrama de seqüência do caso de uso Gerar Relatório de Adequação (Sintético)
FIGURA 12 - diagrama de seqüência do caso de uso Gerar Relatório de Adequação (Detalhado)
: Respondente : Processo : Tarefa : Resposta : Atividade
Obter( )
CalculaPercentualAdquacao( )
ObterPeso( )
Obter( )
Obter( )
: Respondente : Processo : Atividade : Tarefa : Resposta : Opcao
Obter( )
CalculaPercentualAdquacao( )
ObterPeso( )
Obter( )
ObterSolucao( )
ObterSolucao( )
Obter( )
Obter( )
45
4.4.4 Diagrama Entidade Relacionamento
A base de dados do aplicativo será salva em um arquivo.mdb do Microsoft Access. Na
fig 13 pode-se observar o diagrama físico do modelo. Este modelo foi criado a partir de um
mapeamento objeto relacional seguindo as regras indicadas por Hugo (2002).
FIGURA 13 – modelo físico da base de dados
4.5 IMPLEMENTAÇÃO
A seguir será descrita a implementação do aplicativo web, ferramentas utilizadas e sua
operacionalidade.
4.5.1 Técnicas e Ferramentas utilizadas
A modelagem do aplicativo foi feita no software Rational Rose que ofereceu suporte a
todos os diagramas UML utilizados na especificação.
Para a base de dados se optou por utilizar um arquivo .mdb do Microsoft Access. Com
isso foi realizado um mapeamento objeto relacional seguindo as regras indicadas por Hugo
CD_ATIVIDADE = CD_ATIVIDADE
CD_PROCESSO = CD_PROCESSO
CD_USUARIO = CD_USUARIO
CD_OPCAO = CD_OPCAO
CD_TAREFA = CD_TAREFA
CD_OPCAO = CD_OPCAO
CD_TAREFA = CD_TAREFA
TAREFA
CD_TAREFA LongIntegerCD_ATIVIDADE LongIntegerDS_TAREFA MemoTIPO LongIntegerPESO LongIntegerORD_TAREFA LongInteger
OPCAO
CD_OPCAO LongIntegerCD_TAREFA LongIntegerDS_OPCAO MemoSOLUCAO MemoORD_OPCAO LongInteger
USUARIO
CD_USUARIO LongIntegerUSERNAME Text(8)PASSWORD Text(8)EMAIL Text(20)NIVEL LongInteger
RESPOSTA
CD_RESPOSTA LongIntegerCD_OPCAO LongIntegerCD_USUARIO LongInteger
PROCESSO
CD_PROCESSO LongIntegerDS_PROCESSO Memo
ATIVIDADE
CD_ATIVIDADE LongIntegerCD_PROCESSO LongIntegerDS_ATIVIDADE MemoORD_ATIVIDADE LongInteger
DEPENDE
CD_OPCAO LongIntegerCD_TAREFA LongInteger
46
(2002) obtendo-se assim o modelo físico da base de dados. O software utilizado para detalhar
o modelo físico e gerar a base de dados foi o PowerDesigner versão 6.1.
O aplicativo web foi desenvolvido no ambiente Active Servers Page (ASP) com
suporte a VBScript sendo utilizado o software Macromedia Dreamweaver MX versão 6.0
como ferramenta de desenvolvimento em um computador com o Microsoft Windows 2000
Professional e Internet Information Server versão 3.0 instalado.
As páginas dinâmicas desenvolvidas seguem o comportamento apresentado na fig. 14.
A fig. 14 indica o comportamento do aplicativo para criar um processo. O usuário faz a
requisição da página de cadastrar processos para o servidor; o servidor processa esta
requisição e envia o resultado para o navegador do computador do usuário; o usuário
preenche as informações necessárias e ao serem enviadas o servidor processa as mesmas e as
armazena na base de dados do aplicativo.
Para facilitar a compreensão dos usuários utilizou-se no aplicativo web os termos
perguntas, itens de resposta, tipo sim/não, tipo múltipla escolha ao invés de tarefas, opções,
tipo1 e tipo2 respectivamente. Estes últimos foram utilizados na modelagem do aplicativo.
FIGURA 14 – comportamento do aplicativo
Além de armazenar as informações do aplicativo foram criadas consultas no Microsoft
Access. Um exemplo de consulta pode ser observado no quadro 1.
spCriarProcesso cpCriarProcesso
<<Build>>
frmCriaProcesso
ds_processobn_Criar_Processocd_processo
spGravarProcesso
<<Submit>>
47
No desenvolvimento do aplicativo foram utilizados os componentes TreeView e
Yaromat. O componente TreeView fornece uma visão em forma de árvore dos processos,
atividades, perguntas e itens de resposta cadastrados no arquivo .mdb. O resultado da consulta
apresentada no quadro 1 pode ser observado na fig. 16 e este é a informação de entrada do
componente TreeView que gera como saída a estrutura em forma de árvore encontrada na
página “alterar_excluir.asp”. O componente Yaromat possui a função de realizar consistências
nas informações fornecidas pelo usuário em um formulário, como por exemplo: verifica se
alguma informação foi ou não fornecida em um campo obrigatório; determina se o endereço
de e-mail informado é ou não válido, etc...
QUADRO 1 – Exemplo de consulta
FIGURA 16 – resultado da consulta do Quadro 1
SELECT [PROCESSO].[CD_PROCESSO], [PROCESSO].[DS_PROCESSO], [ATIVIDADE].[CD_ATIVIDADE], [ATIVIDADE].[DS_ATIVIDA DE], [TAREFA].[CD_TAREFA],
[TAREFA].[DS_TAREFA], [OPCAO].[CD_OPCAO], [OPCAO].[DS_OPCAO], [ATIVIDADE].[ORD_ATIVIDADE], [TAREFA].[ORD_TAREFA], [OPCAO].[ORD_OPCAO] FROM
(PROCESSO LEFT JOIN (ATIVIDADE LEFT JOIN TAREFA ON [ATIVIDADE].[CD_ATIVIDADE]=[TAREFA].[CD_ATIVIDADE]) ON
[PROCESSO].[CD_PROCESSO]=[ATIVIDADE].[CD_PROCESSO]) LEFT JOIN OPCAO ON [TAREFA].[CD_TAREFA]=[OPCAO].[CD_TAREFA] ORDER BY
[PROCESSO].[CD_PROCESSO], [ATIVIDADE].[ORD_ATIVIDADE], [ATIVIDADE].[CD_ATIVIDADE], [TAREFA].[ORD_TAREFA], [TAREFA].[CD_TAREFA], [OPCAO].[ORD_OPCAO],
[OPCAO].[CD_OPCAO];
48
4.6 OPERACIONALIDADE DA IMPLEMENTAÇÃO
A operacionalidade do aplicativo web é descrita a seguir.
4.6.1 Acesso
Para utilizar o aplicativo web desenvolvido é necessário estar conectado a Internet e
acessar o endereço eletrônico www.flynet.com.br/12207.
Realizando-se este acesso a página principal do aplicativo é aberta na fig. 17 e
conforme se observa contém:
a) explicação da necessidade de utilizar a norma NBR ISO/IEC 12207;
b) objetivos do site;
c) link “quero me cadastrar”;
d) campo de texto “Usuário”, “Senha” e botão “Entrar”;
e) link “Questionário”, “Sintético” e “Detalhado”.
FIGURA 17 – Página principal de aplicativo
Se ocorrer a tentativa de acessar o link “Questionário”, “Sintético” ou “Detalhado” sem
que seja efetuado o logon no aplicativo a página principal será aberta novamente. Caso
contrário ao acessar o link “Questionário” o usuário poderá escolher o processo que deseja
49
responder e através do link “Sintético” e “Detalhado” o usuário poderá obter o respectivo
relatório dos processos já finalizados.
4.6.2 Cadastro e Logon de usuários
O cadastro de usuários é feito através do link “quero me cadastrar”. Este link aciona a
página de cadastro de usuários (fig. 18) onde é solicitado que seja fornecido um usuário,
senha, redigitação da senha e endereço de e-mail.
FIGURA 18 – Página de cadastro de usuários
Com os dados preenchidos deve-se clicar no botão “Enviar” para que o novo usuário
seja cadastrado. Caso alguma informação esteja inserida de maneira incorreta o aplicativo fará
o tratamento do erro e informará o que deve ser feito para corrigí-lo. Além disso, o botão
“Enviar” faz com que a página principal do aplicativo seja reaberta e nesta pode ser
informado um usuário e senha já cadastrados no campo de texto usuário e senha e assim
efetuar o logon no aplicativo.
Se o usuário e senha fornecidos estiverem incorretos o aplicativo avisará através da
mensagem “Usuário ou senha inválidos”.
50
4.6.3 Utilização do Aplicativo
A seguir será descrita a operacionalidade do aplicativo em nível de usuário e em nível
de administrador.
4.6.3.1 Utilização do Aplicativo em nível de Usuário
Se o usuário e senha fornecidos estiverem corretos o aplicativo abrirá a página de
logon efetuado com sucesso onde se podem encontrar instruções referentes ao questionário,
obtenção de relatórios e efetuar logout do aplicativo.
A página de logon efetuado com sucesso pode ser observada na fig. 19.
FIGURA 19 – Logon efetuado com sucesso
4.6.3.1.1 Respondendo o Questionário
Ao clicar no link questionário é aberta a página para selecionar o processo que se
deseja responder.
51
Ao selecionar o processo desejado o aplicativo faz a primeira pergunta sobre o mesmo
(fig. 20). Após marcar os itens realizados clique no botão “Responder” para que o aplicativo
faça a próxima pergunta.
Ao responder a última pergunta o usuário será avisado que todas as perguntas já foram
respondidas para o processo selecionado.
FIGURA 20 – Primeira pergunta do processo selecionado
4.6.3.1.2 Relatórios
Somente é possível obter a análise de adequação a Norma NBR ISO/IEC 12207 dos
processos já respondidos completamente. A análise pode ser sintética ou detalhada. A análise
sintética informa o percentual de adequação a Norma NBR ISO/IEC 12207, sendo esta
oferecida para cada par Processo/Atividade. A análise detalhada além de fornecer os dados da
análise sintética oferece recomendações para a organização ficar de acordo com a Norma
NBR ISO/IEC 12207.
Para obter a análise sintética deve-se clicar no link “Sintético”. Com isso será
solicitado que seja selecionado um processo e após haver esta seleção será obtida a análise
sintética das respostas fornecidas para o mesmo.
52
Para obter a análise detalhada deve-se clicar no link “Detalhado”. Com isso também
será solicitado que seja selecionado um processo e após haver esta seleção será obtida a
análise detalhada das respostas fornecidas para o mesmo.
Se o processo selecionado não estiver respondido completamente será avisado que não
é possível gerar o relatório devido à presença de perguntas sem respostas no processo em
questão. Este aviso será dado pelos dois relatórios.
Um exemplo de relatório sintético pode ser observado na fig. 21 e um exemplo de
relatório detalhado pode ser observado na fig. 22.
FIGURA 21 – Relatório Sintético
53
FIGURA 22 – Relatório Detalhado
4.6.3.2 Utilização do Aplicativo em nível de Administrador
Se o logon for efetuado com um usuário e senha que possuem o nível “Administrador”
o aplicativo abrirá a página de logon efetuado com sucesso e esta conterá instruções referentes
aos serviços realizados pelo administrador e acesso a Área Administrativa.
A página de logon efetuado com sucesso em nível de Administrador pode ser
observada na fig. 23.
4.6.3.2.1 Criando Processos
Para criar um novo processo deve-se clicar no link “Processo” que esta logo abaixo de
“Criar”.
Com isso a página para criar processos é aberta (fig. 24). Deve-se informar a descrição
(nome) do novo processo e clicar no botão “Enviar”.
Se o usuário clicar no botão “Enviar” com o campo de texto “Descrição” em branco o
aplicativo solicitará que a descrição do processo seja fornecida.
54
FIGURA 23 – Logon efetuado com sucesso em nível de Administrador
FIGURA 24 – Cadastro de Processos
55
4.6.3.2.2 Criando Atividades
Para criar uma nova atividade deve-se clicar no link “Atividade” que está logo abaixo
de “Criar”.
Com isso a página para criar atividades é aberta (fig. 25). Deve-se selecionar qual o
processo em que a nova atividade estará subordina, informar sua descrição e clicar no botão
“Enviar”.
FIGURA 25 – Cadastro de Atividades
Se o usuário clicar no botão “Enviar” com o campo de texto “Descrição” em branco o
aplicativo solicitará que a descrição da atividade seja fornecida.
4.6.3.2.3 Criando Perguntas
Para criar uma nova pergunta deve-se clicar no link “Pergunta” que está logo abaixo de
“Criar”.
Com isso a página para criar perguntas é aberta (fig. 26). Deve-se selecionar qual o
processo e atividade em que a nova pergunta estará subordinada, informar sua descrição,
escolher seu tipo, selecionar seu peso e clicar no botão enviar.
56
FIGURA 26 – Cadastro de Perguntas
Se o usuário não selecionar a atividade na qual a nova pergunta estará subordinada
e/ou deixar o campo de texto “Descrição” em branco o aplicativo solicitará que a informação
faltante seja fornecida.
Se o Tipo da nova pergunta for “Sim/Não” o aplicativo cadastrará automaticamente os
itens de resposta “Sim” e “Não”. Será solicitado que a descrição da solução para o item de
resposta “Não” seja informado (fig.27), já que o item de resposta “Sim” não apresenta
solução, pois indica que a pergunta foi cumprida. Após informar a descrição da solução para o
item de resposta “Não” deve-se clicar no botão “Enviar”. Se o botão “Enviar” for clicado com
o campo de texto “Descrição” em branco o aplicativo solicitará que seja informada uma
descrição para a solução.
Se o Tipo da nova pergunta for “Múltipla Escolha” o aplicativo solicitará que seja
informado o par item de resposta/solução (fig. 28). À medida que os itens de resposta e
soluções forem sendo cadastrados será possível visualizar todos os itens de resposta/soluções
já cadastrados para a pergunta. Após informar a descrição do item de resposta e solução deve-
se clicar no botão “Enviar”. Se o botão “Enviar” for clicado com o campo de texto “Item de
Resposta” e/ou “Solução” em branco o aplicativo solicitará que a informação faltante seja
fornecida.
57
FIGURA 27 – Solução do item de resposta Não
FIGURA 28 – Cadastro de Item de Resposta/Solução para o tipo Múltipla Escolha
58
4.6.3.2.4 Alterar/Excluir/Alterar Ordem de Processo, Atividade, Pergunta e Item de Resposta.
Abaixo de Alterar/Excluir/Alterar Ordem têm-se os links “Processo”, “Atividade”,
“Pergunta” e “Item de Resposta”. Todos estes links abrem a mesma página (fig. 29). Esta
possui um componente TreeView que fornece uma visão em forma de árvore dos processos,
atividades, perguntas e itens de resposta cadastrados. Para facilitar a identificação incluiu-se
na frente de processo, atividade, pergunta e item de resposta à abreviação “Proc.:”, “Ativ.:”,
“Perg.:” e “I. Resp.:” respectivamente.
FIGURA 29 – Alterar/Excluir/Alterar Ordem
Nesta página é possível realizar três operações distintas e para realizar qualquer uma
delas deve-se clicar no processo, atividade, pergunta ou item de resposta desejado. Para
facilitar a visualização, a descrição do item clicado aparecerá no campo de texto “Descrição”.
Com o item marcado deve-se clicar na operação desejada. Abaixo é explicado em
detalhes o que cada operação faz.
4.6.3.2.4.1 Alterar
Para processo e atividade é possível alterar apenas sua descrição.
59
Para pergunta é possível alterar sua descrição, tipo e peso. Se o Tipo for alterado será
perguntado ao usuário se realmente deseja continuar esta operação, pois havendo a mudança
de tipo ocorre a necessidade de excluir todos os itens de resposta/soluções. Se o usuário
responder “Sim” os itens de resposta/soluções serão excluídos e será solicitado que os itens de
resposta/soluções adequados para o novo tipo sejam cadastrados. Se o usuário responder
“Não” os itens de resposta/soluções cadastrados não serão excluídos, contudo as demais
alterações (se houverem) serão gravadas.
Para o item de resposta é possível alterar sua descrição e solução.
Tanto para processo, atividade, pergunta e item de resposta/solução será feito
consistência impedindo que seja gravada descrição em branco e para gravar a alteração deve-
se clicar no botão “Alterar”.
Caso tenha-se clicado no botão alterar por engano pode-se clicar no botão “Voltar” do
navegador ou clicar em qualquer link do menu do aplicativo para fechar a página de alteração.
4.6.3.2.4.2 Excluir
Clicando-se em “Excluir” o item marcado será excluído. Antes de excluir da base de
dados é solicitado ao usuário se deseja realmente continuar esta operação.
4.6.3.2.4.3 Alterar ordem
É possível alterar a ordem no qual as atividades, perguntas e itens de resposta serão
perguntados no questionário. Para isso deve-se clicar no botão “Alterar Ordem”. Com isso a
página de alterar ordem será aberta (fig. 30) e através dos botões “Para Cima” e “Para Baixo”
será possível definir a ordem desejada. Para gravar a nova ordem deve-se clicar no botão
“Enviar”.
Somente serão permitidas alterações no mesmo nível. Por exemplo, não será permitido
alterar a atividade na qual uma pergunta pertence, nem alterar a pergunta na qual um item de
resposta pertence, apenas a ordem da pergunta e do item de resposta dentro da atividade e
pergunta respectivamente.
60
Também não será permitido alterar a ordem dos processos, pois o usuário seleciona o
processo que deseja responder na Área de Questionários.
FIGURA 30 – Alterar Ordem
4.6.3.2.5 Dependências
A operação de dependência é equivalente ao conceito de pré-requisito. Uma pergunta
somente será feita no questionário se o seu pré-requisito for atendido.
As dependências possíveis são:
a) um item de resposta;
b) conjunto de itens de resposta. Se apenas um item de resposta for atendido a
pergunta será feita.
c) em cascata.
Não será permitido:
a) um item de resposta ativar outro item de resposta em uma pergunta;
b) conjunto de itens de resposta. Todos os itens de resposta devem estar atendidos para
ativar a pergunta.
61
Através do link “Dependências” é possível criar e excluir dependências. A operação de
alterar dependência não é permitida.
A página de “Dependências” (fig. 31) é composta por dois componentes TreeView que
fornecem uma visão em forma de árvore dos processos, atividades, perguntas e itens de
resposta cadastrados. Para facilitar a identificação incluiu-se na frente de processo, atividade,
pergunta e item de resposta à abreviação “Proc.:”, “Ativ.:”, “Perg.:” e “I. Resp.:”
respectivamente.
FIGURA 31 - Dependência
Para criar uma dependência deve-se formar o par Item de Resposta/Pergunta e clicar
no botão “Criar Dependência”. Para isso deve-se selecionar uma pergunta que somente será
feita se o item de resposta selecionado for atendido. É permitido selecionar a mesma pergunta
várias vezes, contudo o item de resposta deve ser outro. Se for o mesmo, o aplicativo
informará que não é possível criar a dependência, pois a mesma já existe.
Se o par item de resposta/pergunta for criado apenas uma vez para uma determinada
pergunta estará formada a dependência de um item de resposta, pois apenas este item poderá
ativar esta pergunta, contudo se o par item de resposta/pergunta for criado várias vezes para
62
uma pergunta, qualquer um dos itens poderá ativar a pergunta e estará formada uma
dependência composta por um conjunto de itens de resposta.
Também é possível criar dependências em cascata, ou seja, criar uma dependência da
dependência. Por exemplo: a pergunta 10 somente será feita se o item de resposta “Sim” da
pergunta 5 for selecionado, contudo para a pergunta 5 ser feita é necessário que o item de
resposta “Sim” da pergunta 3 seja selecionado.
Após criar uma dependência pode-se observar que foi adicionado no TreeView em que
a pergunta é selecionada o item “Depende do I. Resp.:” (fig. 32). Se selecionado informará o
processo, atividade e pergunta em que este item de resposta está localizado além da sua
descrição e pode-se excluir a dependência clicando-se no botão “Excluir Dependência”.
No TreeView em que o item de resposta é selecionado observa-se o item “Habilita
Pergunta:” (fig. 32). Se selecionado informa o processo e atividade em que a pergunta está
localizada além de sua descrição e também se pode excluir a dependência clicando-se no
botão “Excluir Dependência”.
FIGURA 32 - Visualização de Dependências
63
4.6.3.2.6 Manutenção de Usuários
Abaixo de Usuários observam-se os links “Incluir” e “Alterar”.
Clicando-se no link “Incluir” é possível criar novos usuários tendo-se a opção de criar
usuários com o nível de Administrador.
Clicando-se no link “Alterar” são relacionados todos os usuários cadastrados no
aplicativo. Clicando-se sobre um deles é possível alterar seu usuário, senha, endereço de e-
mail e nível.
4.7 RESULTADOS E DISCUSSÃO
O gerente que respondeu os questionários afirmou ter achado bastante interessantes os
mesmos, pois pôde observar vários controles que não são realizados no processo de
Desenvolvimento de software de sua organização. Apenas o processo de Desenvolvimento
desta empresa foi avaliado pelo questionário da Norma ISO/IEC 12207 desenvolvido neste
trabalho e os resultados obtidos podem ser observados na tabela 10.
Tabela 10 – Percentual de Adequação com a Norma Processo Atividade Percentual de Adequação Desenvolvimento Implementação do Processo 90.69% Desenvolvimento Análise dos requisitos do sistema 83.33% Desenvolvimento Projeto da arquitetura do sistema 78.72% Desenvolvimento Análise dos requisitos de software 83.33% Desenvolvimento Projeto de arquitetura do software 86.84% Desenvolvimento Projeto detalhado de software 79.2% Desenvolvimento Codificação e Testes de Software 96.42% Desenvolvimento Integração do software 57.46% Desenvolvimento Teste de qualificação do software 63.33% Desenvolvimento Integração do sistema 93.75% Desenvolvimento Teste de qualificação do sistema 100% Desenvolvimento Instalação do software 100% Desenvolvimento Apoio à aceitação do software 83.33%
Baseado nas respostas obtidas pelo questionário percebe-se que a empresa estaria
bastante adequada à norma. Por outro lado, comparando-se com a avaliação feita através do
CMM, que obteve nível 1 – Inicial, nota-se uma certa incoerência entre os resultados.
A tabela 6 que é encontrada no tópico 3.3 demonstra o mapeamento do relacionamento
entre as áreas-chave de processo do CMM e os processos da Norma NBR ISO/IEC 12207
64
(GRAHL, 1997) e analisando-se a mesma conclui-se que a empresa deveria ter obtido CMM
nível 2 - Repetitivo.
A incoerência nos resultados obtidos foi ocasionada pela não formação do respondente
na área de Informática, pois com afirma Anacleto (1996) somente pessoas com conhecimento
sólido em Engenharia de Software podem responder adequadamente estes questionários.
Outro fator que contribui para esta distinção é que o respondente deveria ser independente, ou
seja, em avaliações desta natureza, que se comportam como auditoria, é importante o não
envolvimento direto com o processo.
65
5 CONCLUSÕES
A avaliação feita a partir do questionário desenvolvido determinou que a empresa
possui um percentual de adequação em torno de 90% para o Processo de Desenvolvimento da
Norma NBR ISO/IEC 12207 e através da analise das respostas dos questionários do Anexo B,
C e D determinou-se que a empresa possui CMM nível 1 – Inicial.
Os resultados obtidos mostraram-se incoerentes, pois a empresa deveria possuir CMM
nível 2 – Repetitivo para um percentual de 90% obtido na Norma NBR ISO/IEC 12207.
Conclui-se que esta incoerência foi gerada pelo fato do respondente não possuir
conhecimentos sólidos em Engenharia de Software e de ter sido o próprio gerente do setor de
desenvolvimento. O correto seria submeter a avaliação a um respondente independente.
Os trabalhos de Anacleto (1996) e Theilacher (2000) foram utilizados para determinar
o nível CMM da empresa. O trabalho de Frare fornece um roteiro de implantação para a
Norma NBR ISO/IEC 12207. O presente trabalho faz a avaliação da adequação dos processos
de software de uma empresa com a Norma NBR ISO/IEC 12207.
Os objetivos do trabalho foram totalmente cumpridos, sendo ainda adicionado no
aplicativo web a facilidade de alterar a ordem em que as atividades, perguntas e itens de
resposta serão feitos no questionário. As ferramentas utilizadas mostraram-se adequadas
durante a realização deste trabalho acadêmico.
A contribuição deste trabalho é permitir que qualquer organização possa determinar o
grau de adequação de seus processos de desenvolvimento com a Norma NBR ISO/IEC 12207.
Para isso basta acessar um site e responder o questionário.
Contudo a área administrativa e base de dados do aplicativo web apresentam
limitações:
a) não é possível ativar uma pergunta no questionário quando ocorre a necessidade de
todos os itens de resposta cadastrados na dependência para esta pergunta serem
atendidos, pois se qualquer um dos itens for atendido a pergunta será ativada no
questionário.
b) item de resposta não tem a capacidade de ativar um item de resposta no
questionário, apenas perguntas;
66
c) somente é possível incluir itens de resposta quando se está cadastrando uma tarefa.
Em nenhum momento na criação do questionário houve a necessidade de uma
pergunta ser acionada somente se um conjunto de itens de resposta fosse atendido e de um
item de resposta acionar um item de resposta em uma outra pergunta. Comenta-se esta
situação pois a mesma pode ser encontrada em processos da norma não verificados neste
trabalho acadêmico. O cadastro de itens de resposta também poderia ser feito em outra área
do aplicativo, proporcionando assim maior praticidade ao administrador do aplicativo.
5.1 EXTENSÕES
Algumas sugestões para futuros trabalhos acadêmicos:
a) estender o questionário para os demais processos da norma;
b) incluir no software a possibilidade da organização realizar avaliações periódicas,
acompanhando assim sua evolução;
c) aplicar este conceito de questionário em uma outra norma.
67
REFERÊNCIAS BIBLIOGRÁFICAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207: tecnologia da informação – processo de ciclo de vida de software. Rio de Janeiro, 1998.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NM ISO 8402: gestão da qualidade e garantia da qualidade – terminologia. Rio de Janeiro, 1997.
ANACLETO, Ana Lúcia. Mensuração do processo de software baseado no modelo CMM/SEI . 1996. 93 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
BARRETO, José. Qualidade de Software, [200-]. Disponível em <http://orbita.starmedia.com/~matiasmpr/home/qualidade/qualidade.htm>. Acesso em: 27 out. 2003.
FRARE, Alexandre. Proposta de roteiro de implantação da norma internacional ISO-IEC 12207 – processos do ciclo de vida do software. 1998. 97 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
GRAHL, Everaldo A.; HUGO, Marcel; COLOMBO, Regina M. T.; FERNANDES, Rosane A. Um comparativo entre o modelo CMM-SEI e a norma ISO/IEC 12207. In: Anais do WQS97 – Workshop de Qualidade de Software. XI Simpósio Brasileiro de Engenharia de Software. Fortaleza, Out de 1997.
ROCHA, Ana Regina Cavalcanti da; MALDONADO, José Carlos; WEBER, Kival Chaves. Qualidade de software: teoria e prática. São Paulo: Prentice Hall, 2001. 303 p.
THEILACHER, Uno. Análise de uma organização de software utilizando o modelo CMMI-SEI v1.0 . 2000. 92 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
68
ANEXO A – Metodologia utilizada pela empresa
A metodologia utilizada pela empresa está descrita nos documentos relacionados na
tabela 11.
Tabela 11 – Metodologia utilizada NA-401 Documentação de Processos Gerenciais NA-406 Padrão de Nomenclatura para Informática NT-4057 Relatórios – Padronização IT-20003 Telas Form’s – Caracter Mode IT-19007 Definição padrões para elaboração de programas PCK IT-19009 Padrões Nomenclatura Programa Cobol/Procobol NT-4063 Definição Ambiente Desenvolvimento no Oracle HP NT-4127 Desenvolvimento de Processos Gerenciais Novos. NT-4128 Nova Tabela para Processos Gerenciais Existentes NT-4129 Inclusão de Atributo em Tabela Existente. NT-4070 Erro nos Programas – Recuperação/Tratamento NT-4071 Reprocesso de Rotinas – Recuperação/Tratamento NT-4075 Dados Históricos – Filosofia / Manipulação NT-4076 Cadastramento de Usuários e Serviços NT-4080 Solicitação Relatórios Batch –Submissão Automática NT-4083 Log de Execução dos Processos NT-4100 Parâmetro - Cadastramento/Utilização NT-4101 Consulta à Base Oracle via Microcomputador NT-4110 Desenvolvimento Software Específico de Terceiros NT-4150 Ambiente Windows – Padrão de Telas
69
ANEXO B – Questionário 01
1. Perfil da Empresa Nome Endereço Completo Cidade/Estado Ramo de atividade Número de funcionários 13.000 Faturamento anual em 2002 R$ 1,7 Bilhões
2. Perfil da Área de Desenvolvimento de Sistemas
Qtd de funcionários da área de informática e na área de desenvolvimento de sistemas
33/20 Sistemas
Plataformas de Hardware HP Unix – Intel/IBM Sistemas Operacionais Unix e Windows 2000 Linguagens de programação Forms Reports, PL/SQL, Pró-Cobol Sistemas Gerenciadores de Banco de Dados Oracle Ferramentas de auxílio a desenvolvimento (Ex: CASE, geradores de programas, etc.).
Designer 6I
3. Processo de Desenvolvimento de Sistemas
3.1 A área de desenvolvimento adota/utiliza formalmente uma Metodologia de Desenvolvimento de Sistema
(MDS)? Sim Não 3.2 A área de desenvolvimento utiliza algumas destas abordagens no desenvolvimento de sistemas? Indique as
utilizadas: Análise Estruturada Análise de Negócio Análise Essencial Engenharia da Informação Prototipação Análise Orientada ao objeto Outras. Quais? Mapeamento de Processos.
3.3 A área de desenvolvimento adota freqüentemente nas etapas do processo de desenvolvimento de sistemas
algumas destas técnicas e subprodutos? Indique as utilizadas: Levantamento de dados
Observações Entrevistas Visitas JAD Outras. Quais?
Especificação de requisitos e projeto de sistemas DFD MER Dicionário de Dados Diagrama Hierárquico Funcional Jackson Diagrama Estruturado Use Cases Lista de Eventos Modelo de Objetos Warnier
70
Diagrama de Transição de Estados Outras. Quais?
Gerenciamento de projetos PERT/CPM Cronograma tradicional Análise de risco Orçamento COCOMO FPA Outras. Quais?
Documentação Contratos e acordos Especificação de sistema Material para treinamento Documentação no código Plano de testes Manual do usuário Help on-line Outras. Quais?
3.4 A área de informática adota alguma forma de terceirização no desenvolvimento de sistemas? Em que
atividades? Levantamento de dados Análise e projeto de sistemas Codificação e testes Implantação Documentação Manutenção Avaliação da qualidade Outras. Quais?
3.5 Quais tecnologias são consideradas prioritárias no desenvolvimento de sistemas nos próximos dois anos?
Indique no máximo 3 e em ordem de prioridade (1 – mais importante, 2 – importante, 3 – menos importante). EDI Multimídia Reengenharia de Sistemas (3) Orientação a objetos Arquitetura Cliente/Servidor (2) Sistemas Abertos Ambientes Gráficos (windows/os2) (1) Outras. Quais?
3.6 Que assuntos ou temas você considera fundamental que o profissional de desenvolvimento de sistemas deva conhecer mais profundamente nos dias de hoje? R: Noções nos negócios da empresa, conhecer os seus processos e estar atualizado tecnologicamente.
4. Comentários
71
ANEXO C – Questionário 02
As respostas possíveis para este questionário são: SIM (a prática é bem estabelecida e consistentemente executada), NÃO (a prática não é bem estabelecida e é inconsistentemente executada), NÃO SE APLICA (o entrevistado conhece a prática, porém a questão não se aplica ao projeto) e NÃO SABE (o entrevistado não conhece a prática ou não sabe responder).
1. Os requisitos definidos para o software são controlados para estabelecer uma diretriz para uso da engenharia
e gerenciamento do software? Sim Não Não se aplica Não Sabe
2. Quando os requisitos definidos para o software mudam, são feitos ajustes nos planos, produtos de software e atividades relacionadas?
Sim Não Não se aplica Não Sabe 3. As estimativas de software (por exemplo: tamanho, custo e programação de atividades) são documentadas
para uso no planejamento e acompanhamento do projeto de software? Sim Não Não se aplica Não Sabe
4. Os planos de software documentam as atividades a serem executadas e os compromissos definidos no projeto de software?
Sim Não Não se aplica Não Sabe 5. Todos os grupos e indivíduos envolvidos com o projeto concordam com os seus compromissos definidos no
projeto de software? Sim Não Não se aplica Não Sabe
6. A execução e os resultados reais (por exemplo, cronograma, tamanho e custo) são acompanhados com base nos planos de software?
Sim Não Não se aplica Não Sabe 7. Ações corretivas são tomadas quando os resultados reais e execuções do projeto desviam significativamente
dos planos de software? Sim Não Não se aplica Não Sabe
8. Todos os grupos e indivíduos envolvidos com o projeto concordam com mudanças nos compromissos do software?
Sim Não Não se aplica Não Sabe 9. Um procedimento documentado é utilizado para selecionar subcontratados de software, baseados em suas
habilidades, para executar o trabalho? Sim Não Não se aplica Não Sabe
10. As mudanças nos compromissos assumidos durante o projeto de software são feitas com a concordância do contratante principal e do subcontratado de software?
Sim Não Não se aplica Não Sabe 11. Existe uma comunicação contínua entre o contratante principal e os subcontratados de software?
Sim Não Não se aplica Não Sabe 12. Os resultados reais e desempenho do subcontratado de software são acompanhados com base nos
compromissos assumidos no projeto de software? Sim Não Não se aplica Não Sabe
13. Atividades de Garantia de Qualidade do Software são planejadas? Sim Não Não se aplica Não Sabe
14. As atividades de Garantia de Qualidade do Software fornecem verificação objetiva do atendimento dos produtos de software e atividades aos padrões, procedimentos e requisitos aplicáveis?
Sim Não Não se aplica Não Sabe 15. Resultados de revisões, auditorias e atividades de Garantia de Qualidade são informadas aos grupos e
indivíduos envolvidos no projeto (por exemplo, aquele que executa o trabalho e aquele que é responsável pelo trabalho)?
Sim Não Não se aplica Não Sabe 16. As questões discordantes, que não podem ser resolvidas dentro do projeto de software, são encaminhadas
para a gerência superior (por exemplo, desvios dos padrões aplicáveis)? Sim Não Não se aplica Não Sabe
17. As atividades de gerenciamento de configuração de software são planejadas para o projeto? Sim Não Não se aplica Não Sabe
18. O projeto tem identificado, controlado e disponibilizado os produtos intermediários de software através do uso do gerenciamento de configuração?
Sim Não Não se aplica Não Sabe
72
19. O projeto segue um procedimento documentado para controlar mudanças de configuração de itens ou unidades?
Sim Não Não se aplica Não Sabe 20. Relatórios padronizados definidos na diretriz do software (por exemplo, planilha de controle da
configuração do software e sumário de mudanças requeridas e relatórios de posicionamentos) são distribuídos para os grupos e indivíduos envolvidos no projeto?
Sim Não Não se aplica Não Sabe 21. As atividades para desenvolvimento e melhoria dos processos de software dos projetos e da organização são
coordenadas através da própria organização (por exemplo, via um grupo de processo de engenharia de software)?
Sim Não Não se aplica Não Sabe 22. Sua organização avalia os processos de software periodicamente?
Sim Não Não se aplica Não Sabe 23. Sua organização segue um plano documentado de atividades para desenvolvimento e melhoria do processo
de software? Sim Não Não se aplica Não Sabe
24. Sua organização desenvolve e mantém um processo padronizado de software? Sim Não Não se aplica Não Sabe
25. A organização coleta, revisa e torna disponíveis informações relacionadas ao uso do processo padronizado de software da organização (por exemplo, estimativas e dados reais de tamanho de software, esforços e custos, dados de produtividade, e avaliações de qualidade)?
Sim Não Não se aplica Não Sabe 26. A atividades de treinamento são planejadas?
Sim Não Não se aplica Não Sabe 27. O treinamento fornece desenvolvimento de habilidades e conhecimento necessários para realizar as funções
gerenciais e técnicas do software? Sim Não Não se aplica Não Sabe
28. Os membros do grupo de engenharia de software ou outros grupos relacionados recebem o treinamento necessário para realizar suas funções?
Sim Não Não se aplica Não Sabe 29. O processo de software definido para o projeto foi adaptado a partir do processo padronizado de software da
organização? Sim Não Não se aplica Não Sabe
30. O projeto é planejado e gerenciado de acordo com o processo de software definido para o projeto? Sim Não Não se aplica Não Sabe
31. Os produtos intermediários de software são produzidos de acordo com o processo de software definido para o projeto?
Sim Não Não se aplica Não Sabe 32. Os produtos intermediários de software são consistentes entre si (por exemplo, a documentação dos
requisitos definidos do software através do projeto, codificação e acompanhamento de casos de teste é mantida)?
Sim Não Não se aplica Não Sabe 33. No projeto, o grupo de engenharia de software e outros grupos de engenharia relacionados ao projeto
colaboram com o cliente para estabelecer os requisitos do sistema? Sim Não Não se aplica Não Sabe
34. Os grupos de engenharia concordam com os compromissos apresentados no plano geral do projeto? Sim Não Não se aplica Não Sabe
35. Os grupos de engenharia identificam, acompanham e resolvem problemas entre os grupos (por exemplo, incompatibilidade de cronogramas, riscos técnicos ou problemas no nível de sistema)?
Sim Não Não se aplica Não Sabe 36. As atividades de Revisões são planejadas?
Sim Não Não se aplica Não Sabe 37. As ações, associadas a defeitos identificados nos produtos intermediários de software durante as revisões,
são acompanhadas até que os defeitos sejam resolvidos? Sim Não Não se aplica Não Sabe
38. O projeto segue um procedimento documento para condução das atividades do gerenciamento quantitativo do processo?
Sim Não Não se aplica Não Sabe
73
39. O desempenho do processo de software definido para o projeto é controlado quantitativamente (por exemplo, através do uso de métodos quantitativos analíticos)?
Sim Não Não se aplica Não Sabe 40. A capacidade do processo padronizado de software da organização é conhecida em termos quantitativos?
Sim Não Não se aplica Não Sabe 41. Atividades de gerenciamento da qualidade de software são planejadas para o projeto?
Sim Não Não se aplica Não Sabe 42. O projeto utiliza metas mensuráveis e prioritárias para gerenciamento da qualidade de seus produtos de
software (por exemplo, funcionalidade, confiabilidade, manutenção e usabilidade)? Sim Não Não se aplica Não Sabe
43. As medidas da qualidade são comparadas com as metas para a qualidade do produto de software para determinar se as metas de qualidade foram alcançadas?
Sim Não Não se aplica Não Sabe 44. As atividades de prevenção de defeitos são planejadas?
Sim Não Não se aplica Não Sabe 45. O projeto conduz reuniões para análise de causas para identificar causas comuns dos defeitos?
Sim Não Não se aplica Não Sabe 46. Uma vez identificadas, as causas comuns de defeitos são priorizadas e eliminadas sistematicamente?
Sim Não Não se aplica Não Sabe 47. A organização segure um plano para gerenciamento da mudança de tecnologia?
Sim Não Não se aplica Não Sabe 48. As novas tecnologias são avaliadas para determinar seus efeitos na qualidade e produtividade?
Sim Não Não se aplica Não Sabe 49. A organização segue um procedimento documentado para incorporar novas tecnologias aos processos
padronizados de software da organização? Sim Não Não se aplica Não Sabe
50. A organização segue um procedimento documentado para desenvolvimento e manutenção de planos de melhoria do processo de software?
Sim Não Não se aplica Não Sabe 51. O pessoal da sua organização participa das atividades de melhoria dos processos de software (por exemplo,
em grupos para desenvolver melhorias de processos de software)? Sim Não Não se aplica Não Sabe
52. As melhorias são efetuadas continuamente para o processo padronizado de software da organização e para os processos de software definidos para os projetos?
Sim Não Não se aplica Não Sabe
74
ANEXO D – Questionário 03
As respostas possíveis para este questionário são: SIM (a prática é bem estabelecida e consistentemente
executada), NÃO (a prática não é bem estabelecida e é inconsistentemente executada), NÃO SE APLICA (o
entrevistado conhece a prática, porém a questão não se aplica ao projeto) e NÃO SABE (o entrevistado não
conhece a prática ou não sabe responder).
1. O projeto segue uma política organizacional documentada para o gerenciamento dos requisitos definidos do sistema para software?
Sim Não Não se aplica Não Sabe 2. As pessoas no projeto que estão encarregadas com o gerenciamento de requisitos definidos foram treinadas
em procedimentos para gerenciamento de definição de requisitos? Sim Não Não se aplica Não Sabe
3. Medidas são usadas para determinar o estado das atividades executadas durante o gerenciamento de requisitos (por exemplo, número total de requisitos alterados que foram propostos, aprovados, e incorporados à diretriz)?
Sim Não Não se aplica Não Sabe 4. Existem atividades para gerenciamento dos requisitos definidos no projeto sujeitas à revisão da garantia de
qualidade do software? Sim Não Não se aplica Não Sabe
5. O projeto segue uma política organizacional documentada para o planejamento do projeto do software. Sim Não Não se aplica Não Sabe
6. Os recursos providos para planejar o projeto do software são adequados? (por exemplo, pessoal disponível e experiente)?
Sim Não Não se aplica Não Sabe 7. Medidas são usadas para determinar o estado das atividades para o planejamento do projeto de software (por
exemplo: complementação de marcos de referência para as atividades de planejamento são comparadas com o plano?).
Sim Não Não se aplica Não Sabe 8. O gerente do projeto revisa as atividades para planejar o projeto do software eventualmente e
periodicamente? Sim Não Não se aplica Não Sabe
9. O projeto segue uma política organizacional documentada para acompanhamento e controle das atividades de desenvolvimento do software?
Sim Não Não se aplica Não Sabe 10. Alguém no projeto é designado especificamente para se responsabilizar pelo acompanhamento das
atividades e produtos intermediários do software (por exemplo: esforço, cronograma e orçamento)? Sim Não Não se aplica Não Sabe
11. Medidas são usadas para determinar o estado das atividades para acompanhamento e supervisão do software (por exemplo, total de esforços despendidos na realização de acompanhamento e supervisão das atividades e falhas?).
Sim Não Não se aplica Não Sabe 12. As atividades de acompanhamento e supervisão do projeto de software são revisadas com a gerência
principal periodicamente (por exemplo, execução do projeto, discordâncias, riscos e itens do plano de ação?).
Sim Não Não se aplica Não Sabe 17. O projeto segue uma política organizacional documentada quanto à implementação da Garantia da
Qualidade de Software? Sim Não Não se aplica Não Sabe
18. Os recursos para execução das atividades da Garantia da Qualidade Software são adequados (por exemplo, gerente disponível e designado que receberá e administrará os itens dos softwares em não-conformidade)?
Sim Não Não se aplica Não Sabe 19. Medidas são usadas para determinar o estado dos custos e cronograma das atividades executadas para a
Garantia da Qualidade do Software (por exemplo, trabalhos completados, esforço e recursos despendidos comparados com o plano)?
Sim Não Não se aplica Não Sabe
75
20. As atividades da Garantia da Qualidade de Software são revisadas com a gerência superior periodicamente? Sim Não Não se aplica Não Sabe
21. O projeto segue uma política organizacional documentada para implementação de atividades de Gerenciamento de Configuração de Software?
Sim Não Não se aplica Não Sabe 22. O pessoal envolvido no projeto foi treinado para executar atividades de gerenciamento de configuração de
software para as atividades pelas quais são responsáveis? Sim Não Não se aplica Não Sabe
23. Medidas são usadas para determinar o estado das atividades de gerenciamento de configuração de software (por exemplo, esforços e recursos despendidos para as atividades de gerenciamento de configuração de software)?
Sim Não Não se aplica Não Sabe 24. São realizadas auditorias periódicas para verificar quais as diretrizes de software que estão em conformidade
com a documentação que as define (por exemplo, pelo grupo de gerenciamento de configuração de software)?
Sim Não Não se aplica Não Sabe 25. A gerência superior patrocina as atividades da organização para desenvolvimento e melhoria dos processos
de software (por exemplo: pelo estabelecimento de planos de longo prazo e pelo comprometimento de disponibilidade de recursos)?
Sim Não Não se aplica Não Sabe 26. Um ou mais indivíduos tem obrigações em tempo integral ou parcial para as atividades do processo de
software de organização (por exemplo, um grupo de engenharia do processo e software)? Sim Não Não se aplica Não Sabe
27. Medidas são usadas para determinar o estado das atividades executadas para desenvolver e melhorar o processo de software da organização (por exemplo, despendido para a avaliação e melhoria do processo de software)?
Sim Não Não se aplica Não Sabe 28. As atividades executadas para desenvolver e melhorar o processo de software são revisadas periodicamente
pela gerência superior? Sim Não Não se aplica Não Sabe
41. O projeto segue uma política organizacional documentada para executar as atividades de engenharia de software (por exemplo, uma política que exige o uso de métodos e ferramentas apropriados para construção e manutenção de produtos de software)?
Sim Não Não se aplica Não Sabe 42. Os recursos adequados são providos para executar as tarefas de engenharia de software (por exemplo,
recursos financeiros, pessoais habilitados e ferramentas apropriadas)? Sim Não Não se aplica Não Sabe
43. As medidas são usadas para determinar a funcionalidade e qualidade dos produtos de software (por exemplo, quantidade, tipos e gravidade dos defeitos identificados)?
Sim Não Não se aplica Não Sabe 44. As atividades e produtos da Engenharia de Software são submetidos a revisões e auditorias da Garantia da
Qualidade de Software? Sim Não Não se aplica Não Sabe
45. Existe uma política organizacional documentada que guia o estabelecimento de equipes interdisciplinares de engenharia?
Sim Não Não se aplica Não Sabe 46. As ferramentas de suporte usadas pelos diferentes grupos de engenharia proporcionam uma comunicação e
coordenação efetiva (por exemplo, sistemas de processamento compatíveis, sistemas de bases de dados e sistemas para monitoração de problemas)?
Sim Não Não se aplica Não Sabe 47. Medidas são usadas para determinar o estado das atividades de coordenação intergrupos (por exemplo,
esforços despendidos pelo grupo de engenharia de software para auxiliar outros grupos)? Sim Não Não se aplica Não Sabe
48. As atividades de coordenação intergrupos são revisadas com o gerente do projeto eventualmente e periodicamente?
Sim Não Não se aplica Não Sabe 61. O projeto segue uma política organizacional documentada para atividades de prevenção de defeitos?
Sim Não Não se aplica Não Sabe
76
62. Os membros do grupo de engenharia de software e outros grupos relacionados a software recebem o treinamento necessário para executar as atividades de prevenção de defeitos (por exemplo, treinamento em métodos de prevenção de defeitos e na condução de reuniões de análise de causas)?
Sim Não Não se aplica Não Sabe 63. Medidas são usadas para determinar o estado das atividades de prevenção de defeitos (por exemplo, o tempo
e custo para identificar e corrigir defeitos e a quantidade de ações propostas e completadas)? Sim Não Não se aplica Não Sabe
64. As atividades e produtos intermediários para prevenção de defeitos são submetidos a auditorias e revisões da Garantia da Qualidade de software?
Sim Não Não se aplica Não Sabe 65. A gerência superior patrocina as atividades da organização para gerenciamento da mudança de tecnologia
(por exemplo, pelo estabelecimento de planos de longo prazo e pelo comprometimento de disponibilidade de recursos)?
Sim Não Não se aplica Não Sabe 66. Dados a respeito do processo existem para auxiliar na seleção de nova tecnologia?
Sim Não Não se aplica Não Sabe 67. Medidas são usadas para determinar o estado das atividades da organização para gerenciamento de
mudanças de tecnologia (por exemplo, os esforços para implementação da mudança tecnológica)? Sim Não Não se aplica Não Sabe
68. As atividades da organização para gerenciamento de mudanças da tecnologia são revisadas com a gerência superior periodicamente?
Sim Não Não se aplica Não Sabe 69. A organização segue uma política organizacional documentada para implementar melhorias no processo de
software? Sim Não Não se aplica Não Sabe
70. O treinamento em melhoria do processo de software é exigido para o pessoal técnico e de gerência? Sim Não Não se aplica Não Sabe
71. Medidas são criadas para determinar o estado das atividades de melhoria do processo de software (por exemplo, o efeito da implementação de cada melhoria de processo comparado a metas definidas)?
Sim Não Não se aplica Não Sabe 72. Os esforços para melhoria do processo de software são revisados com a gerência superior periodicamente?
Sim Não Não se aplica Não Sabe
77
APÊNDICE A – Perguntas criadas a partir da Norma ISO/IEC 12207
Processo: AQUISIÇÃO Atividade: Iniciação
1) O processo de aquisição quando iniciado
contém a descrição de um conceito ou de uma necessidade em adquirir, desenvolver ou melhorar um sistema, produto de software ou serviço de software?
Sim; Não.
(peso 10) Solução: O processo de aquisição quando iniciado deve conter a descrição de um conceito ou de uma necessidade em adquirir, desenvolver ou melhorar um sistema, produto de software ou serviço de software.
2) Quanto ao sistema, ocorre a definição e análise de seus requisitos?
Sim; Não.
(peso 5) Solução: Deverá ser realizadas a definição e análise dos requisitos do sistema. (Se a resposta da questão 2 for “SIM” o software faz a pergunta abaixo).
3) Na definição e análise de requisitos do sistema estão incluídos:
Requisitos de negócio; Requisitos organizacionais; Requisitos de segurança; Requisitos de proteção; Requisitos relacionados às atividades de
projeto; Requisitos relacionados às atividades de
teste; Requisitos relacionados às atividades de
aderência a padrões e procedimentos; Todos as opções; Nenhuma das opções.
(peso 10) Solução: A definição e análise dos requisitos do sistema devem incluir os requisitos de negócio. A definição e análise dos requisitos do sistema devem incluir os requisitos organizacionais. A definição e análise dos requisitos do sistema devem incluir os requisitos de segurança. A definição e análise dos requisitos do sistema devem incluir os requisitos de proteção. A definição e análise dos requisitos do sistema devem incluir os requisitos relacionados às atividades de projeto.
A definição e análise dos requisitos do sistema devem incluir os requisitos relacionados às atividades de teste. A definição e análise dos requisitos do sistema devem incluir os requisitos relacionados às atividades de aderência a padrões e procedimentos. (Se a resposta da questão 2 for “SIM” o software faz a pergunta abaixo).
4) A definição e análise dos requisitos do software são realizadas internamente (por conta própria) ou é terceirizado?
Equipe interna; Terceirizada.
(peso 1) (Se a resposta da questão 4 for “Terceirizada” o software faz a pergunta abaixo).
5) Havendo a terceirização da execução da análise dos requisitos do sistema o contratante em algum momento aprova tais requisitos? (Deverá estar de acordo com os requisitos estipulados pela equipe da empresa terceirizada. Se em um primeiro momento não houver acordo, os requisitos deverão ser revistos até estarem OK para o contratante).
Sim; Não.
(peso 5) Solução: Deverá haver a aprovação da análise dos requisitos do sistema pelo contratante quando a mesma é terceirizada. (Se a resposta da questão 2 for “SIM” o software faz a pergunta abaixo).
6) O Processo de Desenvolvimento foi utilizado na definição e análise dos requisitos do sistema? (utilizado internamente ou pela empresa terceirizada)
Sim; Não.
(peso 2) Solução: O processo de desenvolvimento deveria ser utilizado na definição e análise dos requisitos do sistema.
7) Ocorre o levantamento das alternativas existentes para a solução do problema através de uma análise, com critérios apropriados, incluindo risco, custo e benefícios para cada uma delas. As alternativas incluem:
Comprar um produto de software de prateleira que satisfaça os requisitos;
Internamente desenvolver o produto de software ou obter o serviço de software;
78
Através de contrato, desenvolver o produto de software ou obter o serviço de software;
Uma combinação dos itens anteriores; Melhorar um produto ou serviço de
software existente; Todas as opções; Nenhuma das opções.
(peso 5) Solução: No levantamento das alternativas existentes para a solução do problema deverá estar incluído a opção de comprar um produto de software de prateleira que satisfaça os requisitos. No levantamento das alternativas existentes para a solução do problema deverá estar incluído a opção de desenvolver internamente o produto de software ou obter o serviço de software. No levantamento das alternativas existentes para a solução do problema deverá estar incluído a opção de através de um contrato, desenvolver o produto de software ou obter o serviço de software. No levantamento das alternativas existentes para a solução do problema deverá estar incluído a opção de melhorar um produto ou serviço de software existente.
8) Se a alternativa escolhida foi à aquisição de um produto de software de prateleira quais condições abaixo estão satisfeitas:
Requisitos do produto de software; Documentação disponível; Os direitos de propriedade, de uso, de
autoria, de garantia e de licença; O suporte futuro para o produto de software
esteja planejado; Todas as opções; Nenhum dos itens; Não se aplica.
(peso 5) Solução: O produto de software de prateleira adquirido deverá satisfazer os requisitos do produto de software estabelecidos anteriormente. O produto de software de prateleira adquirido deverá satisfazer a necessidade de documentação disponível (esta estabelecida anteriormente). O produto de software de prateleira adquirido deverá estar legalizado satisfazendo assim os direitos de propriedade, de uso, de autoria, de garantia e de licença. O produto de software de prateleira adquirido deverá satisfazer o planejamento futuro de suporte (este estabelecido anteriormente).
9) A empresa possui algum plano de aquisição? Sim; Não.
(peso 2). Solução: A empresa deveria possuir um plano de aquisição. (Se a resposta da questão 9 for “SIM” o software faz a pergunta abaixo).
10) O plano de aquisição contém: Requisitos para o sistema; Emprego planejado para o sistema; Tipo de contrato a ser empregado; Responsabilidades das organizações
envolvidas; Conceito de suporte a ser usado; Riscos considerados assim como métodos
para gerenciá-los; Todas as opções; Nenhuma das opções.
(peso 2) Solução: O plano de aquisição deveria conter os requisitos do sistema. O plano de aquisição deveria conter o emprego planejado para o sistema O plano de aquisição deveria conter o tipo de contrato a ser empregado. O plano de aquisição deveria conter as responsabilidades das organizações envolvidas. O plano de aquisição deveria conter o conceito de suporte a ser usado. O plano de aquisição deveria conter os riscos considerados assim como métodos para gerenciá-los.
11) Referente a estratégia e condições (critérios) de aceitação do software ocorrem:
Sua definição; Sua documentação; Todas as opções; Nenhuma das opções.
(peso 2) Solução: Na estratégia e condições de aceitação do software deveria estar incluída sua definição. Na estratégia e condições de aceitação do software deveria estar incluída sua documentação.
Processo: AQUISIÇÃO Atividade: Preparação do Pedido de Proposta
1) Ocorre a documentação dos requisitos de
aquisição (Ex: pedido de proposta). Sim; Não.
(peso 2) Solução: Deveria haver a documentação dos requisitos de aquisição (pedido de proposta). (Se a resposta da questão 1 for “SIM” o software faz a pergunta abaixo).
79
2) Esta incluída na documentação dos requisitos de aquisição:
Os requisitos do sistema; A declaração de escopo; As instruções para os proponentes; A lista de produtos de software; Os termos e condições; O controle dos subcontratos; As restrições técnicas (Ex: ambiente-alvo); Todas as opções; Nenhuma das opções.
(peso 2) Solução: Na documentação dos requisitos de aquisição deveriam estar incluídos os requisitos do sistema. Na documentação dos requisitos de aquisição deveria estar incluída a declaração de escopo. Na documentação dos requisitos de aquisição deveriam estar incluídas as instruções para os proponentes. Na documentação dos requisitos de aquisição deveria estar incluída a lista de produtos de software. Na documentação dos requisitos de aquisição deveriam estar incluídos os termos e condições. Na documentação dos requisitos de aquisição deveria estar incluído o controle dos subcontratos. Na documentação dos requisitos de aquisição deveriam estar incluídas as restrições técnicas (ex: ambiente-alvo).
3) Ocorre a determinação de quais processos, atividades e tarefas desta Norma são apropriados para o projeto?
Sim; Não.
(peso 2) Solução: Deveria haver a determinação de quais processos, atividades e tarefas da Norma são apropriadas ao projeto. (Se a resposta da questão 3 for “SIM” o software faz a pergunta abaixo).
4) Estes processos, atividades e tarefas são adaptados ao projeto quando necessário?
Sim; Não.
(peso 2) Solução: Deveria haver a adaptação dos processos, atividades e tarefas da Norma ao projeto quando necessário. (Se a resposta da questão 3 for “SIM” o software faz a pergunta abaixo).
5) No processo de determinação dos processos, atividades e tarefas da Norma que são apropriados ao projeto ocorre:
A especificação dos processos de apoio aplicáveis;
A relação de suas organizações executoras; Definição de responsabilidades; Todas as opções; Nenhuma das opções.
(peso 2) Solução: No processo de determinação dos processos, atividades e tarefas da Norma que são apropriados ao projeto deveria haver a especificação dos processos de apoio aplicáveis. No processo de determinação dos processos, atividades e tarefas da Norma que são apropriados ao projeto deveria haver a relação de suas organizações executoras. No processo de determinação dos processos, atividades e tarefas da Norma que são apropriados ao projeto deveria haver a definição das responsabilidades.
6) Ocorre a definição do escopo (o que vai ser feito) das tarefas referenciadas no contrato?
Sim; Não.
(peso 5) Solução: Deverá ser feita a definição do escopo (o que vai ser feito) das tarefas referenciadas no contrato. (Se a resposta da questão 1 for “SIM” o software faz a pergunta abaixo).
7) No documento de aquisição estão especificados prazos nos quais o andamento do projeto deverá ser revisado e auditado como parte da monitoração da aquisição?
Sim; Não.
(peso 5) Solução: Deverá haver no documento de aquisição a especificação dos prazos nos quais o andamento do projeto deverá ser revisado e auditado como parte da monitoração da aquisição.
8) Quando terceirizado o processo de aquisição os requisitos de aquisição são fornecidos a organização selecionada?
Sim; Não.
(peso 2) Solução: Deveria ser fornecida a organização selecionada os requisitos de aquisição quando o processo de aquisição é terceirizado.
Processo: AQUISIÇÃO Atividade: Preparação e atualização do contrato
80
1) Existem procedimentos para selecionar o fornecedor?
Sim; Não.
(peso 2) Solução: Deveria haver procedimentos para a seleção de fornecedores. (Se a resposta da questão 1 for “SIM” o software faz a pergunta abaixo).
2) Estes procedimentos contem critérios para avaliação de propostas, percebendo assim, a aprovação ou não quanto aos requisitos e exigências antes estabelecidas?
Sim; Não.
(peso 2) Solução: Os procedimentos de seleção dos fornecedores deveriam conter critérios para a avaliação de propostas, percebendo assim, a aprovação ou não quanto aos requisitos e exigências antes estabelecidas.
3) A escolha do fornecedor é baseada na: Avaliação de sua proposta; Capacidade; Outros fatores que precisam ser
considerados; Todas as opções; Nenhuma das opções.
(peso 2) Solução: A escolha do fornecedor também deveria ser baseada na avaliação de sua proposta. A escolha do fornecedor também deveria ser baseada em sua capacidade. A escolha do fornecedor também deveria ser baseada em outros fatores que precisam ser considerados. (faz a pergunta abaixo caso a pergunta 2 da atividade Preparação do Pedido de Proposta tiver como resposta “SIM”).
4) Ocorre o envolvimento de fornecedores em potencial antes do fechamento do contrato no processo de adaptação da Norma ao projeto?
Sim; Não.
(peso 1). Solução: Pode haver o envolvimento de fornecedores em potencial antes do fechamento do contrato no processo de adaptação da Norma ao projeto. (Se a resposta da questão 4 for “SIM” o software faz a pergunta abaixo).
5) A palavra final na versão da adaptação a Norma ao projeto é dada pelo adquirente (quem contrata) ou pelo fornecedor?
Adquirente; Fornecedor.
(peso 5) Solução: A palavra final da versão da adaptação a Norma ao projeto deverá ser dada pelo adquirente. (faz a pergunta abaixo caso a pergunta 2 da atividade Preparação do Pedido de Proposta tiver como resposta “SIM”).
6) A Norma adaptada ao projeto é referenciada ou esta incluída no contrato?
Sim; Não.
(peso 5) Solução: A norma adaptada ao projeto deverá estar referenciada ou incluída no contrato.
7) Com o fornecedor selecionado ocorre a preparação e negociação de um contrato que trate:
Dos requisitos de aquisição; Do custo do produto ou serviço de software
a ser entregue; Do cronograma do produto ou serviço de
software a ser entregue; Dos direitos de uso; Dos direitos de propriedade; Dos diretos de autoria; Dos direitos de garantia; Dos direitos de licença; Todas as opções; Nenhuma das opções.
(peso 5) Solução: Com o fornecedor selecionado deverá ocorrer a preparação e negociação de um contrato que trate dos requisitos de aquisição. Com o fornecedor selecionado deverá ocorrer à preparação e negociação de um contrato que trate do custo do produto ou serviço de software a ser entregue. Com o fornecedor selecionado deverá ocorrer à preparação e negociação de um contrato que trate do cronograma do produto ou serviço de software a ser entregue. Com o fornecedor selecionado deverá ocorrer a preparação e negociação de um contrato que trate dos direitos de uso. Com o fornecedor selecionado deverá ocorrer a preparação e negociação de um contrato que trate dos direitos de propriedade. Com o fornecedor selecionado deverá ocorrer a preparação e negociação de um contrato que trate dos direitos de autoria. Com o fornecedor selecionado deverá ocorrer a preparação e negociação de um contrato que trate dos direitos de garantia. Com o fornecedor selecionado deverá ocorrer a preparação e negociação de um contrato que trate dos direitos de licença.
81
8) Caso haja a necessidade de alterações no contrato durante seu andamento estas são negociadas com o fornecedor?
Sim; Não.
(peso 5) Solução: Caso haja a necessidade de alterações no contrato durante seu andamento estas deverão ser negociadas com o fornecedor.
9) As alterações no contrato são investigadas quanto ao impacto:
Nos planos; Nos custos; Nos benefícios; Na qualidade do projeto; No cronograma do projeto; Todas as opções; Nenhuma das opções.
(peso 5) Solução: As alterações no contrato deverão ser investigadas quanto ao impacto nos planos. As alterações no contrato deverão ser investigadas quanto ao impacto nos custos. As alterações no contrato deverão ser investigadas quanto ao impacto nos benefícios. As alterações no contrato deverão ser investigadas quanto ao impacto na qualidade do projeto. As alterações no contrato deverão ser investigadas quanto ao impacto no cronograma do projeto.
Processo: AQUISIÇÃO Atividade: Monitoração do fornecedor
1) Ocorre monitoração das atividades do
fornecedor de acordo com o processo de revisão conjunta e com o processo de auditoria?
Sim; Não.
(peso 5) Solução: As atividades realizadas pelo fornecedor deverão ser monitoradas de acordo com o processo de revisão conjunta e processo de auditoria.
2) Quando necessário ocorre à complementação da monitoração observando-se o processo de verificação e processo de validação?
Sim; Não.
(peso 2) Solução: Quando necessário à monitoração deveria ser complementada observando-se o processo de verificação e o processo de validação.
3) Ocorre a comunicação com o fornecedor para prover ao mesmo toda a informação necessária no momento oportuno e resolver todos os itens pendentes?
Sim; Não.
(peso 5) Solução: Deverá ocorrer a comunicação com o fornecedor para prover ao mesmo toda a informação necessária e resolver todos os itens pendentes.
Processo: AQUISIÇÃO Atividade: Aceitação e Conclusão
(Se a resposta da questão 11 da Iniciação tiver a opção “sua definição” selecionada o software faz a pergunta abaixo).
1) A aceitação do produto ocorre baseada nas estratégias e condições (critérios) de aceitações definidas anteriormente?
Sim; Não.
(peso 2) Solução: A aceitação do produto deveria ser baseada nas estratégias e condições de aceitações definidas anteriormente.
2) Esta incluída no processo de aceitação: A preparação de caso de testes; A preparação dos dados de teste; Os procedimentos de testes; Definição do ambiente de testes; Todas as opções; Nenhuma das opções.
(peso 2) Solução: Deveria estar incluída no processo de aceitação a preparação de caso de testes. Deveria estar incluída no processo de aceitação a preparação dos dados de teste. Deveriam estar incluído no processo de aceitação os procedimentos de testes. Deveria estar incluída no processo de aceitação a definição do ambiente de testes.
3) No processo de aceitação a abrangência do envolvimento do fornecedor é definida?
Sim; Não.
(peso 2) Solução: A abrangência do envolvimento do fornecedor deveria ser definida no processo de aceitação.
4) A revisão de aceitação e teste de aceitação do produto ou serviço de software é conduzida pelo adquirente?
Sim; Não.
82
(peso 5) Solução: A revisão de aceitação e teste de aceitação do produto ou serviço de software deverá ser conduzida pelo adquirente.
5) O produto ou serviço de software é aceito somente quando todas as condições de aceitação forem satisfeitas?
Sim; Não.
(peso 5) Solução: O produto ou serviço de software deverá ser aceito quando todas as condições de aceitação forem satisfeitas.
6) Após a aceitação o adquirente assume a responsabilidade pela gerência de configuração do produto de software entregue?
Sim; Não.
(peso 2) Solução: Após a aceitação o adquirente deveria assumir a responsabilidade pela gerência de configuração do produto de software.
Processo: FORNECIMENTO Atividade: Iniciação
1) É realizada uma revisão dos requisitos que
constam no pedido de proposta? Sim; Não
(peso 10) Solução: Deve-se realizar uma revisão dos requisitos que constam no pedido de proposta. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
2) No processo de revisão leva-se em conta: As políticas da organização; E outros regulamentos da organização; Todas as opções; Nenhuma das opções.
(peso 10) Solução: No processo de revisão deve-se levar em conta as políticas da organização. No processo de revisão deve-se levar em conta os outros regulamentos da organização.
Processo: FORNECIMENTO Atividade: Preparação da Resposta
1) Ocorre a preparação de uma proposta em
resposta ao pedido de proposta? Sim; Não.
(peso 2)
Solução: Uma proposta deveria ser preparada em resposta ao pedido de proposta. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
2) A proposta que esta sendo preparada inclui a recomendação da adaptação do projeto a Norma ISO/IEC 12207?
Sim; Não.
(peso 2) Solução: A proposta que esta sendo preparada deveria incluir uma recomendação de adaptação do projeto a Norma ISO/IEC 12207.
Processo: FORNECIMENTO Atividade: Contrato
1) Ocorre a negociação e firmamento do contrato
com a organização adquirente para o fornecimento do produto ou serviço de software?
Sim; Não.
(peso 10) Solução: Deve ocorrer uma negociação e firmamento de contrato com a organização adquirente para o fornecimento do produto ou serviço de software.
2) Havendo modificações no contrato, as mesmas são registradas pelo mecanismo de controle de alterações?
Sim; Não.
(peso 1) Solução: O mecanismo de controle de alterações pode registrar modificações do contrato, caso estas ocorram.
Processo: FORNECIMENTO Atividade: Planejamento
1) É realizada uma revisão dos requisitos de
aquisição pelo fornecedor? Sim; Não.
(peso 10) Solução: O fornecedor deve realizar uma revisão dos requisitos de aquisição. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
2) Na revisão dos requisitos de aquisição ocorre a definição:
Da estrutura para gerenciar e garantir o projeto;
83
Da estrutura para garantir a qualidade de produto ou serviço de software;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Na revisão dos requisitos de aquisição deve ocorrer a definição da estrutura para gerenciar e garantir o projeto. Na revisão dos requisitos de aquisição deve ocorrer a definição da estrutura para garantir a qualidade de produto ou serviço de software.
3) Caso não esteja especificado no contrato o fornecedor escolhe ou define um modelo de ciclo de vida de software apropriado para o escopo, magnitude e complexidade do projeto?
Sim; Não.
(peso 10) Solução: Caso não esteja especificado no contrato o fornecedor deve escolher ou definir um modelo de ciclo de vida de software apropriado para o escopo, magnitude e complexidade do projeto.
4) Ocorre a seleção e mapeamento dos processos, atividades e tarefas da norma ISO/IEC 12207 ao modelo de ciclo de vida adotado no projeto?
Sim; Não.
(peso 10) Solução: Deve ocorrer a seleção e mapeamento dos processos, atividades e tarefas da norma ISO/IEC 12207 ao modelo de ciclo de vida adotado no projeto.
5) Ocorre o estabelecimento de requisitos para: O planejamento que esta sendo feito; Gerenciar e garantir o projeto; Garantir a qualidade do produto ou serviço
de software a ser entregue; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve-se estabelecer requisitos para o planejamento que esta sendo feito. Devem-se estabelecer requisitos para gerenciar e garantir o projeto. Devem-se estabelecer requisitos para garantir a qualidade do produto ou serviço de software a ser entregue. (se a pergunta 5 tiver a opção “o planejamento que esta sendo feito” selecionada o software faz a pergunta abaixo).
6) Na definição dos requisitos para este planejamento está incluída:
Necessidades de recursos; Envolvimento do adquirente; Todas as opções;
Nenhuma das opções. (peso 2) Solução: Na definição dos requisitos do planejamento do processo Fornecimento deveria estar incluído nas necessidades de recursos. Na definição dos requisitos do planejamento do processo de Fornecimento deveria estar incluído o envolvimento do adquirente.
7) Ocorre a consideração de opções (maneiras diferentes) para o desenvolvimento do produto de software ou provisão do serviço de software?
Sim; Não.
(peso 10) Solução: Devem ser consideradas opções/maneiras diferentes para o desenvolvimento do produto de software ou provisão do serviço de software. (se a pergunta 7 tiver resposta “SIM” o software faz a pergunta abaixo).
8) Nas opções consideradas está incluído: Desenvolver o produto de software ou
prover o serviço de software usando recursos internos;
Desenvolver o produto de software ou prover o serviço de software através da terceirização;
Obter produtos de software de prateleira a partir de fontes internas ou externas;
Combinação das três opções anteriores; Todas os itens; Nenhuma das opções.
(peso 10) Solução: Nas diferentes opções/maneiras para o desenvolvimento do produto de software ou provisão do serviço de software deve estar incluído “desenvolver o produto de software ou prover o serviço de software usando recursos internos”. Nas diferentes opções/maneiras para o desenvolvimento do produto de software ou provisão do serviço de software deve estar incluído “desenvolver o produto de software ou prover o serviço de software através da terceirização”. Nas diferentes opções/maneiras para o desenvolvimento do produto de software ou provisão do serviço de software deve estar incluído “obter produtos de software de prateleira a partir de fontes internas ou externas”. Nas diferentes opções/maneiras para o desenvolvimento do produto de software ou provisão do serviço de software deve estar incluído a combinação da utilização de
84
recursos internos, com terceirização e com a compra de software de prateleira.
9) Ocorre a criação de um plano de gerência para o projeto?
Sim; Não.
(peso 10) Solução: Deve ser criado um plano de gerência para o projeto. (se a pergunta 9 tiver resposta “SIM” o software faz a pergunta abaixo).
10) É realizada a documentação do plano de gerência?
Sim; Não.
(peso 10) Solução: A documentação do plano de gerência deve ser realizada. (se a pergunta 9 tiver resposta “SIM” o software faz a pergunta abaixo).
11) O plano de gerência do projeto é desenvolvido de acordo com:
Os requisitos de planejamento; As opções consideradas para o
desenvolvimento do produto de software ou provisão do serviço de software;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: O plano de gerência do projeto deve ser desenvolvido de acordo com os requisitos de planejamento. O plano de gerência do projeto deve ser desenvolvido de acordo com as opções consideradas para o desenvolvimento do produto de software ou provisão do serviço de software. (se a pergunta 9 tiver resposta “SIM” o software faz a pergunta abaixo).
12) Marque as opções que estão incluídas no plano de gerência do projeto:
Estrutura organizacional do projeto, autoridade e responsabilidade da cada unidade organizacional, incluindo organizações externas;
Ambiente de engenharia (para desenvolvimento, operação ou manutenção, quando aplicável), incluindo ambiente de testes, biblioteca, equipamento, instalações, padrões, procedimentos e ferramentas;
Estrutura de divisão de trabalho dos processos e atividades de ciclo de vida, incluindo os produtos de software, serviços de software e itens que não serão entregues, a ser executada de acordo com os orçamentos,
pessoal, recursos físicos, tamanho do software e cronogramas associados às tarefas;
Gerenciamento das características da qualidade dos produtos ou serviços de software. Planos para qualidade podem ser desenvolvidos em separado;
Gerenciamento de proteção, segurança e outros requisitos críticos dos produtos ou serviços de software. Planos para proteção e segurança podem ser desenvolvidos em separado;
Gerenciamento do subcontratado, incluindo a sua seleção e o seu envolvimento com o adquirente se houver;
Garantia de qualidade; Verificação e validação, incluindo a
abordagem para a interação com o agente de verificação e interação, se especificado;
Envolvimento do adquirente, isto é, através de revisões conjuntas, auditorias, reuniões informais, relatórios, modificação e alteração; implementação, aprovação, aceitação e acesso às instalações;
Envolvimento do usuário, através de exercícios de consolidação de requisitos, demonstrações de protótipos e avaliações;
Gerenciamento de risco: gerenciamento das áreas do projeto que envolve potenciais riscos técnicos de custo e de cronograma;
Política de segurança: as regras para gestão e acesso às informações em cada nível organizacional do projeto;
Aprovação requerida através de regulamentos, certificações, direitos de propriedade, de uso, de autoria, de garantia e de licença;
Meios para elaborar cronogramas, realizar acompanhamento e elaborar relatórios;
Treinamento para pessoal; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve estar incluído no plano de gerência do projeto a estrutura organizacional do projeto, autoridade e responsabilidade da cada unidade organizacional, incluindo organizações externas. Deve estar incluído no plano de gerência do projeto o ambiente de engenharia (para desenvolvimento, operação ou manutenção, quando aplicável), incluindo ambiente de testes, biblioteca, equipamento, instalações, padrões, procedimentos e ferramentas. Deve estar incluído no plano de gerência do projeto a estrutura de divisão de trabalho dos processos e atividades de ciclo de vida, incluindo os produtos de software, serviços de software e itens que não serão entregues, a ser
85
executada de acordo com os orçamentos, pessoal, recursos físicos, tamanho do software e cronogramas associados às tarefas. Deve estar incluído no plano de gerência do projeto o gerenciamento das características da qualidade dos produtos ou serviços de software. Planos para qualidade podem ser desenvolvidos em separado. Deve estar incluído no plano de gerência do projeto o gerenciamento de proteção, segurança e outros requisitos críticos dos produtos ou serviços de software. Planos para proteção e segurança podem ser desenvolvidos em separado. Deve estar incluído no plano de gerência do projeto o gerenciamento do subcontratado, incluindo a sua seleção e o seu envolvimento com o adquirente se houver. Deve estar incluído no plano de gerência do projeto a garantia de qualidade. Deve estar incluído no plano de gerência do projeto a verificação e validação, incluindo a abordagem para a interação com o agente de verificação e interação, se especificado. Deve estar incluído no plano de gerência do projeto o envolvimento do adquirente, isto é, através de revisões conjuntas, auditorias, reuniões informais, relatórios, modificação e alteração; implementação, aprovação, aceitação e acesso às instalações. Deve estar incluído no plano de gerência do projeto o envolvimento do usuário, através de exercícios de consolidação de requisitos, demonstrações de protótipos e avaliações. Deve estar incluído no plano de gerência do projeto o gerenciamento de risco: gerenciamento das áreas do projeto que envolve potenciais riscos técnicos de custo e de cronograma. Deve estar incluído no plano de gerência do projeto a política de segurança: as regras para gestão e acesso às informações em cada nível organizacional do projeto. Deve estar incluído no plano de gerência do projeto a aprovação requerida através de regulamentos, certificações, direitos de propriedade, de uso, de autoria, de garantia e de licença. Devem estar incluído no plano de gerência do projeto os meios para elaborar cronogramas, realizar acompanhamento e elaborar relatórios. Deve estar incluído no plano de gerência do projeto um treinamento para pessoal.
Processo: FORNECIMENTO Atividade: Execução e Controle
(Se a pergunta 10 da atividade Planejamento tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
1) Ocorre a implementação e execução do plano de gerenciamento do projeto baseado em sua documentação?
Sim; Não.
(peso 10) Solução: Deve ocorrer a implementação e execução do plano de gerenciamento do projeto baseado em sua documentação.
2) Marque os itens abaixo que são realizados pelo fornecedor:
Desenvolver o produto de software de acordo com o processo de desenvolvimento;
Operar o produto de software de acordo com o processo de operação;
Manter o produto de software de acordo com processo de manutenção;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: O fornecedor deve desenvolver o produto de software de acordo com o processo de desenvolvimento. O fornecedor deve operar o produto de software de acordo com o processo de operação. O fornecedor deve manter o produto de software de acordo com o processo de manutenção.
3) Através do ciclo de vida do projeto ocorre o monitoramento e controle:
Do progresso (do projeto); Da qualidade dos produtos ou serviços de
software do projeto; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Através do ciclo de vida do projeto deve ocorrer o monitoramento e controle do progresso do projeto. Através do ciclo de vida do projeto deve ocorrer o monitoramento e controle da qualidade dos produtos ou serviços de software do projeto.
4) Ocorre o gerenciamento e controle dos terceirizados de acordo com o processo de aquisição?
Sim; Não.
(peso 10) Solução:
86
O gerenciamento e controle dos terceiros devem ocorrer de acordo com o processo de aquisição.
5) Todos os requisitos contratuais necessários são verificados para assegurar que o produto ou serviço de software entregue ao adquirente foi desenvolvido ou executado de acordo com os requisitos do contrato original?
Sim; Não.
(peso 10) Solução: Todos os requisitos contratuais necessários devem ser verificados para assegurar que o produto ou serviço de software entregue ao adquirente foi desenvolvido ou executado de acordo com os requisitos do contrato original.
6) Ocorre a interação do fornecedor com agentes independentes:
De verificação; De validação; De testes; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ocorrer a interação do fornecedor com agentes independentes de verificação. Deve ocorrer a interação do fornecedor com agentes independentes de validação. Deve ocorrer a interação do fornecedor com agentes independentes de testes.
7) O fornecedor interage com as outras partes (subcontratado, adquirente, agente independente, etc...), obedecendo ao contrato e os planos do projeto?
Sim; Não.
(peso 10) Solução: O fornecedor deve interagir com as outras partes (subcontratado, adquirente, agente independente, etc...), obedecendo ao contrato e os planos do projeto.
Processo: FORNECIMENTO Atividade: Revisão e avaliação 1) O fornecedor realiza a coordenação das
atividades: De revisão do contrato; De interações com a organização do
adquirente; De comunicação com a organização do
adquirente; Todas as opções; Nenhuma das opções.
(peso 10) Solução:
Deve ser realizada pelo fornecedor a coordenação das atividades de revisão do contrato. Deve ser realizadas pelo fornecedor a coordenação das atividades de interações com a organização do adquirente. Deve ser realizada pelo fornecedor a coordenação das atividades de comunicação com a organização do adquirente.
2) O fornecedor conduz ou da suporte: As reuniões informais; As revisões de aceitação; Aos testes de aceitação; As revisões conjuntas; As auditorias com o adquirente; Todas as opções; Nenhuma das opções.
(peso 10) Solução: O fornecedor deve conduzir ou dar suporte as reuniões informais. O fornecedor deve conduzir ou dar suporte as revisões de aceitação. O fornecedor deve conduzir ou dar suporte aos testes de aceitação. O fornecedor deve conduzir ou dar suporte as revisões conjuntas. O fornecedor deve conduzir ou dar suporte as auditorias com o adquirente. (Se a pergunta 2 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
3) A condução ou prestação de suporte por parte do fornecedor é feita conforme especificado no contrato e planos do projeto?
Sim; Não.
(peso 10) Solução: A condução ou prestação de suporte por parte do fornecedor deve ser feita conforme especificado no contrato e planos do projeto. (Se a pergunta 2 tiver a opção “as revisões conjuntas” selecionada o software faz a pergunta abaixo).
4) As revisões conjuntas são realizadas de acordo com o processo de Revisão Conjunta?
Sim; Não.
(peso 10) Solução: As revisões conjuntas devem ser realizadas de acordo com o processo de revisão conjunta. (Se a pergunta 2 tiver a opção “as auditorias com o adquirente” selecionada o software faz a pergunta abaixo).
5) As auditorias são conduzidas de acordo com o Processo de Auditoria?
Sim; Não.
87
(peso 10) Solução: As auditorias devem ser conduzidas de acordo com o processo de auditoria.
6) O fornecedor realiza o processo de verificação e validação para demonstrar que os produtos ou serviços de software e os processos satisfaçam completamente os seus respectivos requisitos?
Sim; Não.
(peso 10) Solução: Deve ser realizado pelo fornecedor o processo de verificação e validação para demonstrar que os produtos ou serviços de software e os processo satisfaçam completamente os seus respectivos requisitos.
7) Ocorre a disponibilização para o adquirente: Dos relatórios de avaliação; Das revisões; Das auditorias; Dos testes; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ocorrer a disponibilização dos relatórios de avaliação para o adquirente. Deve ocorrer a disponibilização das revisões para o adquirente. Deve ocorrer a disponibilização das auditorias para o adquirente. Deve ocorrer a disponibilização dos testes para o adquirente. (Se a pergunta 7 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
8) Esta disponibilização (questão anterior) ocorre conforme está especificado no contrato?
Sim; Não.
(peso 10) Solução: A disponibilização de informações para o adquirente deve ocorrer conforme especificado no contrato.
9) É provido ao adquirente acesso aos recursos do fornecedor e subcontratados para a realização da revisão dos produtos ou serviços de software?
Sim; Não.
(peso 10) Solução: Deve ser provido ao adquirente acesso aos recursos do fornecedor e subcontratados para a realização da revisão dos produtos ou serviços de software. (se a pergunta 9 tiver resposta “SIM” o software faz a pergunta abaixo).
10) A revisão dos produtos ou serviços de software é realizada conforme sua especificação no contrato?
Sim; Não.
(peso 10) Solução: A revisão dos produtos ou serviços de software deve ser realizada conforme sua especificação no contrato.
11) As atividades do processo de Garantia de Qualidade são executadas pelo fornecedor?
Sim; Não.
(peso 10) Solução: Deve ser executada pelo fornecedor a atividade do processo de garantia de qualidade.
Processo: FORNECIMENTO Atividade: Entrega e Conclusão 1) O produto ou serviço de software é entregue
conforme especificado no contrato? Sim; Não.
(peso 10) Solução: O produto ou serviço de software deve ser entregue conforme especificado no contrato.
2) É provida assistência ao adquirente no suporte ao produto ou serviço de software entregue?
Sim; Não.
(peso 10) Solução: Deve ser provida assistência ao adquirente no suporte ao produto ou serviço de software entregue. (se a pergunta 2 tiver resposta “SIM” o software faz a pergunta abaixo).
3) A assistência provida ao adquirente esta de acordo com a sua especificação no contrato?
Sim; Não.
(peso 10) Solução: A assistência provida ao adquirente deve estar de acordo com a sua especificação no contrato.
Processo: DESENVOLVIMENTO Atividade: Implementação do Processo 1) Caso não esteja especificado no contrato ocorre
à definição ou escolha de um modelo de ciclo de vida apropriado ao projeto pelo desenvolvedor?
Sim; Não.
88
(peso 10) Solução: Deve-se haver a definição ou escolha de um modelo de ciclo de vida apropriado ao projeto.
2) As atividades e tarefas do processo de desenvolvimento são selecionadas e mapeadas ao modelo de ciclo de vida do projeto?
Sim; Não.
(peso 10) Solução: Deve-se haver a seleção e mapeamento das atividades e tarefas do processo de desenvolvimento ao modelo de ciclo de vida do projeto.
3) Marque as tarefas abaixo executadas pelo desenvolvedor.
Documentar os resultados, de acordo com o processo de documentação;
Colocar os resultados sob o processo de gerência de configuração e executar controle de alterações, de acordo com ele;
Documentar e resolver problemas e não-conformidades encontradas nos produtos de software e tarefas, de acordo com o processo de resolução de problemas;
Executar os processos de apoio, conforme especificado no contrato;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Devem-se documentar os resultados de acordo com o processo de documentação. Devem-se colocar os resultados sob o processo de gerência de configuração e executar o controle de alterações, de acordo com ele. Deve-se documentar e resolver problemas e não-conformidades encontradas nos produtos de software e tarefas, de acordo com o processo de resolução de problemas. Devem-se executar os processos de apoio, conforme especificado no contrato.
4) Se não estipulado no contrato, para realizar a execução das atividades do processo de desenvolvimento e processo de apoio o desenvolvedor:
Seleciona os padrões, métodos, ferramentas e linguagens de computador que sejam documentados, apropriados e estabelecidos pela organização;
Adapta os padrões, métodos, ferramentas e linguagens de computador que sejam documentados, apropriados e estabelecidos pela organização;
Utiliza os padrões, métodos, ferramentas e linguagens de computador que sejam documentados, apropriados e estabelecidos pela organização;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve-se haver a seleção de padrões, métodos, ferramentas e linguagens de computador que sejam documentados, apropriados e estabelecidos pela organização para realizar a execução das atividades do processo de desenvolvimento e processo de apoio ao desenvolvedor. Deve-se haver a adaptação aos padrões, métodos, ferramentas e linguagens de computador que sejam documentados, apropriados e estabelecidos pela organização para realizar a execução das atividades do processo de desenvolvimento e processo de apoio ao desenvolvedor. Deve-se haver a utilização dos padrões, métodos, ferramentas e linguagens de computador que sejam documentados, apropriados e estabelecidos pela organização para realizar a execução das atividades do processo de desenvolvimento e processo de apoio ao desenvolvedor.
5) Ocorre o desenvolvimento de planos para conduzir as atividades do processo de desenvolvimento?
Sim; Não.
(peso 10) Solução: Deve-se haver o desenvolvimento de planos para conduzir as atividades do processo de desenvolvimento. (se a pergunta 5 tiver resposta “SIM” o software faz a pergunta abaixo).
6) Está incluído nos planos de condução das atividades do processo de desenvolvimento:
Padrões específicos; Métodos; Ferramentas; Ações; Responsabilidades associadas com o
desenvolvimento; Qualificação de todos os requisitos,
incluindo proteção e segurança; Todas as opções; Nenhuma das opções.
(peso 2) Solução: Deveria ser incluído nos planos de condução das atividades do processo de desenvolvimento o padrão específico do mesmo. Deveria ser incluído nos planos de condução das atividades do processo de desenvolvimento o método utilizado no mesmo.
89
Deveria ser incluída nos planos de condução das atividades do processo de desenvolvimento a ferramenta utilizada no mesmo. Deveria ser incluída nos planos de condução das atividades do processo de desenvolvimento a ação realizada no mesmo. Deveria ser incluída nos planos de condução das atividades do processo de desenvolvimento a responsabilidade associada com o desenvolvimento. Deveria ser incluída nos planos de condução das atividades do processo de desenvolvimento a qualificação de todos os requisitos, incluindo proteção e segurança. (se a pergunta 5 tiver resposta “SIM” o software faz a pergunta abaixo).
7) Os planos desenvolvidos para a condução das atividades do processo de desenvolvimento são:
Documentados; Executados; Todas as opções; Nenhum dos itens;
(peso 10) Solução: Devem-se documentar os planos de condução das atividades do processo de desenvolvimento. Devem-se executar os planos de condução das atividades do processo de desenvolvimento.
8) Itens que não serão entregues na versão final do produto de software podem ser empregados em seu desenvolvimento. Entretanto, é assegurado que a operação e manutenção do produto de software sejam independentes daqueles itens?
Sim; Não.
(peso 10) Solução: Deve-se assegurar que a operação e manutenção do produto de software sejam independentes dos itens que não são entregues na versão final do produto de software e que, contudo foram utilizados durante seu desenvolvimento.
Processo: DESENVOLVIMENTO Atividade: Análise dos requisitos do sistema 1) O uso específico do sistema (foco) a ser
desenvolvido é analisado para especificar seus requisitos?
Sim; Não.
(peso 10) Solução:
Deve-se analisar o uso específico do sistema (foco) a ser desenvolvido durante a especificação de seus requisitos.
2) A especificação dos requisitos do sistema contém:
Funções e capacidades do sistema; Requisitos de negócio; Requisitos organizacionais; Requisitos do usuário; Requisitos de proteção; Requisitos de segurança; Requisitos de engenharia de fatores
humanos (ergonomia); Requisitos de interface; Requisitos de operação; Requisitos de manutenção; Restrições de projeto; Requisitos de qualificação; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A especificação dos requisitos do sistema deve conter funções e capacidades do sistema. A especificação dos requisitos do sistema deve conter requisitos do negócio. A especificação dos requisitos do sistema deve conter requisitos organizacionais. A especificação dos requisitos do sistema deve conter requisitos do usuário. A especificação dos requisitos do sistema deve conter requisitos de proteção. A especificação dos requisitos do sistema deve conter requisitos de segurança. A especificação dos requisitos do sistema deve conter requisitos de engenharia de fatores humanos (ergonomia). A especificação dos requisitos do sistema deve conter requisitos de interface. A especificação dos requisitos do sistema deve conter requisitos de operação. A especificação dos requisitos do sistema deve conter requisitos de manutenção. A especificação dos requisitos do sistema deve conter restrições de projeto. A especificação dos requisitos do sistema deve conter requisitos de qualificação. (Se a pergunta 2 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
3) A especificação dos requisitos do sistema é documentada?
Sim; Não.
(peso 10) Solução: Deve-se haver a documentação dos requisitos do sistema. (Se a pergunta 2 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
90
4) Ocorre a avaliação dos requisitos do sistema? Sim; Não.
(peso 10) Solução: Deve-se haver a avaliação dos requisitos do sistema. (se a pergunta 4 tiver resposta “SIM” o software faz a pergunta abaixo).
5) A avaliação dos requisitos do sistema considera os critérios de:
Rastreabilidade para as necessidades de aquisição;
Consistência com as necessidades de aquisição;
Testabilidade; Viabilidade do projeto da arquitetura do
sistema; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação dos requisitos do sistema deve considerar os critérios de rastreabilidade para as necessidades de aquisição. A avaliação dos requisitos do sistema deve considerar os critérios de consistência com as necessidades de aquisição. A avaliação dos requisitos do sistema deve considerar os critérios de testabilidade. A avaliação dos requisitos do sistema deve considerar os critérios de viabilidade do projeto da arquitetura do sistema. A avaliação dos requisitos do sistema deve considerar os critérios de viabilidade da operação e manutenção. (se a pergunta 4 tiver resposta “SIM” o software faz a pergunta abaixo).
6) O resultado da avaliação dos requisitos de sistema é documentado?
Sim; Não.
(peso 10) Solução: Deve-se haver a documentação da avaliação dos requisitos de sistema.
Processo: DESENVOLVIMENTO Atividade: Projeto da arquitetura do sistema 1) Ocorre o estabelecimento de uma arquitetura
de alto nível para o sistema? Sim; Não.
(peso 10) Solução: Deve ser estabelecida uma arquitetura de alto nível para o sistema.
(se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
2) A arquitetura identifica: Itens de hardware; Itens de software; Operações manuais; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A arquitetura estabelecida para o sistema deve identificar itens de hardware. A arquitetura estabelecida para o sistema deve identificar itens de software. A arquitetura estabelecida para o sistema deve identificar operações manuais. (Se a pergunta 2 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
3) Todos os requisitos do sistema são alocados entre os itens identificados pela arquitetura?
Sim; Não.
(peso 10) Solução: Todos os requisitos do sistema devem ser alocados entre os itens identificados pela arquitetura do sistema. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
4) Ocorre a documentação da arquitetura estabelecida para o sistema?
Sim; Não.
(peso 10) Solução: A arquitetura estabelecida para o sistema deve ser documentada. (Se a pergunta 2 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
5) Ocorre a documentação dos requisitos de sistema alocados aos itens identificados pela arquitetura estabelecida para o sistema?
Sim; Não.
(peso 10) Solução: Deve ocorrer a documentação dos requisitos de sistema alocados aos itens identificados pela arquitetura estabelecida para o sistema. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
6) Ocorre a avaliação da arquitetura estabelecida para o sistema?
Sim; Não.
(peso 10) Solução:
91
Deve ocorrer a avaliação da arquitetura de alto nível estabelecida para o sistema. (se a pergunta 6 tiver resposta “SIM” o sistema faz a pergunta abaixo)
7) A avaliação da arquitetura estabelecida para o sistema considera os critérios de:
A rastreabilidade para os requisitos do sistema;
A consistência com os requisitos do sistema;
A adequação dos métodos e padrões de projeto utilizados;
A viabilidade de os itens de software atenderem seus requisitos alocados;
Viabilidade da operação e da manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação da arquitetura de alto nível estabelecida para o sistema deve considerar os critérios de rastreabilidade para os requisitos do sistema. A avaliação da arquitetura de alto nível estabelecida para o sistema deve considerar os critérios de consistência com os requisitos do sistema. A avaliação da arquitetura de alto nível estabelecida para o sistema deve considerar os critérios de adequação dos métodos e padrões de projeto utilizados. A avaliação da arquitetura de alto nível estabelecida para o sistema deve considerar os critérios de viabilidade para os itens de software atenderem seus requisitos alocados. A avaliação da arquitetura de alto nível estabelecida para o sistema deve considerar os critérios de viabilidade da operação e da manutenção. (Se a pergunta 2 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
8) Ocorre a avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema?
Sim; Não.
(peso 10) Solução: Deve ocorrer a avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema. (se a pergunta 8 tiver resposta “SIM” o software faz a pergunta abaixo).
9) A avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema considera os critérios de:
A rastreabilidade para os requisitos do sistema;
A consistência com os requisitos do sistema;
A adequação dos métodos e padrões de projeto utilizados;
A viabilidade de os itens de software atenderem seus requisitos alocados;
viabilidade da operação e da manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema deve considerar critérios de rastreabilidade para os requisitos do sistema. A avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema deve considerar critérios de consistência com os requisitos do sistema. A avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema deve considerar critérios de adequação dos métodos e padrões de projeto utilizados. A avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema deve considerar critérios de viabilidade para os itens de software atenderem seus requisitos alocados. A avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema deve considerar critérios de viabilidade da operação e da manutenção. (se a pergunta 6 tiver resposta “SIM” o software faz a pergunta abaixo).
10) O resultado da avaliação da arquitetura estabelecida para o sistema é documentado?
Sim; Não.
(peso 10) Solução: A avaliação da arquitetura de alto nível estabelecida para o sistema deve ser documentada. (se a pergunta 8 tiver resposta “SIM” o software faz a pergunta abaixo).
11) O resultado da avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema é documentado?
Sim; Não.
(peso 10) Solução: O resultado da avaliação dos requisitos para os itens identificados pela arquitetura estabelecida para o sistema deve ser documentado.
Processo: DESENVOLVIMENTO Atividade: Análise dos requisitos de software
92
1) O desenvolvedor determina e documenta:
Os requisitos de software; Especificações funcionais e de capacidade,
incluindo desempenho, características físicas e condições do ambiente sob o qual o item de software será executado;
Interfaces externas ao item de software; Requisitos de qualificação; Especificação de proteção, incluindo
aquelas relacionadas aos métodos de operação e manutenção, influência do ambiente e danos pessoais;
Especificações de segurança, incluindo aquelas relacionadas com o comprometimento de informações sigilosas;
Especificações de engenharia de fatores humanos (ergonomia), incluindo aquelas relacionadas com operações manuais, interações entre homem-máquina, restrições a pessoal e áreas que necessitam de maior atenção humana, que são sensíveis a erros humanos e treinamento;
Definição de dados e requisitos de base de dados;
Requisitos de instalação e aceitação do produto de software entregue no(s) local (ais) de operação e manutenção;
Documentação do usuário; Requisitos do usuário para execução e
operação; Requisitos do usuário para manutenção; Todas as opções; Nenhum dos itens;
(peso 10) Solução: O desenvolvedor deve determinar e documentar os requisitos de software. O desenvolvedor deve determinar e documentar especificações funcionais e de capacidade, incluindo desempenho, características físicas e condições do ambiente sob o qual o item de software será executado. O desenvolvedor deve determinar e documentar as interfaces externas ao item de software. O desenvolvedor deve determinar e documentar os requisitos de qualificação. O desenvolvedor deve determinar e documentar a especificação de proteção, incluindo aquelas relacionadas aos métodos de operação e manutenção, influência do ambiente e danos pessoais. O desenvolvedor deve determinar e documentar as especificações de segurança, incluindo aquelas relacionadas com o comprometimento de informações sigilosas. O desenvolvedor deve determinar e documentar as especificações de engenharia de
fatores humanos (ergonomia), incluindo aquelas relacionadas com operações manuais, interações entre homem-máquina, restrições a pessoal e áreas que necessitam de maior atenção humana, que são sensíveis a erros humanos e treinamento. O desenvolvedor deve determinar e documentar a definição de dados e requisitos de base de dados; O desenvolvedor deve determinar e documentar os requisitos de instalação e aceitação do produto de software entregue no(s) local (ais) de operação e manutenção. O desenvolvedor deve determinar e documentar a documentação do usuário. O desenvolvedor deve determinar e documentar os requisitos do usuário para execução e operação do sistema. O desenvolvedor deve determinar e documentar os requisitos do usuário para manutenção.
2) Ocorre a avaliação dos requisitos de software? Sim; Não.
(peso 10) Solução: Deve-se haver a avaliação dos requisitos de software. (se a pergunta 2 tiver resposta “SIM” o software faz a pergunta abaixo).
3) A avaliação dos requisitos de software considera os critérios de:
Rastreabilidade para os requisitos de sistema e projeto do sistema;
Consistência externa com os requisitos do sistema;
Consistência interna; Testabilidade; Viabilidade do projeto de software; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação dos requisitos do software deve considerar os critérios de rastreabilidade para os requisitos de sistema e projeto do sistema. A avaliação dos requisitos do software deve considerar os critérios de consistência externa com os requisitos do sistema. A avaliação dos requisitos do software deve considerar os critérios de consistência interna. A avaliação dos requisitos do software deve considerar os critérios de testabilidade. A avaliação dos requisitos do software deve considerar os critérios de viabilidade do projeto de software.
93
A avaliação dos requisitos do software deve considerar os critérios de viabilidade da operação e manutenção. (se a pergunta 2 tiver resposta “SIM” o software faz a pergunta abaixo).
4) O resultado da avaliação dos requisitos de software é documentado?
Sim; Não.
(peso 10) Solução: Deve-se haver a documentação do resultado da avaliação dos requisitos de software.
5) Ocorre a realização de revisões conjuntas de acordo com o processo de revisão conjunta?
Sim; Não.
(peso 10) Solução: Devem-se realizar revisões conjuntas de acordo com o processo de revisão conjunta. (se a pergunta 5 tiver resposta “SIM” o sistema faz a pergunta abaixo)
6) As revisões conjuntas possuindo conclusões bem sucedidas desencadeiam o estabelecimento de uma linha básica (baseline) para os requisitos do item de software?
Sim; Não.
(peso 10) Solução: Deve-se haver o estabelecimento de uma linha básica (baseline) para os requisitos do item de software quando o resultado das revisões conjuntas é bem sucedido.
Processo: DESENVOLVIMENTO Atividade: Projeto de arquitetura do software: 1) O desenvolvedor realiza a transformação dos
requisitos para o item de software em uma arquitetura que descreve sua estrutura de alto nível e identifica seus componentes?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve realizar a transformação dos requisitos para o item de software em uma arquitetura que descreva sua estrutura de alto nível e identifica seus componentes.
2) Ocorre a alocação de todos os requisitos do item de software aos seus respectivos componentes de software?
Sim; Não.
(peso 10) Solução:
Deve ocorrer a alocação de todos os requisitos do item de software aos seus respectivos componentes de software.
3) Ocorre a documentação da arquitetura do item de software?
Sim; Não.
(peso 10) Solução: Deve ocorrer a documentação da arquitetura do item de software.
4) Um projeto de alto nível (visão macro do sistema) para as interfaces externas ao item de software é:
Desenvolvido; Documentado; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ser desenvolvido um projeto de alto nível para as interfaces externas ao item de software. O projeto de alto nível desenvolvido para as interfaces externas ao item de software deve ser documentado.
5) Um projeto de alto nível para os componentes de software do item de software é:
Desenvolvido; Documentado; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ser desenvolvido um projeto de alto nível para os componentes de software do item de software. O projeto de alto nível desenvolvido para os componentes de software do item de software deve ser documentado.
6) Um projeto de alto nível para a base de dados é:
Desenvolvido; Documentado; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ser desenvolvido um projeto de alto nível para a base de dados. O projeto de alto nível para a base de dados deve ser documentado.
7) Versões preliminares da documentação do usuário são:
Desenvolvidas; Documentadas; Todas as opções; Nenhuma das opções.
(peso 10) Solução:
94
Versões preliminares da documentação do usuário devem ser desenvolvidas. Versões preliminares da documentação do usuário devem ser documentadas.
8) Os requisitos preliminares de teste do software são:
Definidos; Documentados; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Devem ser definidos os requisitos preliminares de teste do software. Os requisitos preliminares do teste de software devem ser documentados.
9) O cronograma para a integração do software é: Definido; Documentado; Todas as opções; Nenhum dos itens;
(peso 10) Solução: O cronograma para a integração do software deve ser definido. O cronograma para a integração do software deve ser documentado. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
10) Ocorre a avaliação da arquitetura do item de software?
Sim; Não.
(peso 10) Solução: A arquitetura do item de software deve ser avaliada. (se a pergunta 4 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
11) Ocorre a avaliação dos projetos para as interfaces externas ao item de software?
Sim; Não.
(peso 10) Solução: Os projetos para as interfaces externas ao item de software devem ser avaliados. (se a pergunta 6 tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
12) Ocorre a avaliação do projeto da base de dados?
Sim; Não.
(peso 10) Solução: A base de dados desenvolvida deve ser analisa. (se a pergunta 10 tiver resposta “SIM” o software faz a pergunta abaixo).
13) A avaliação da arquitetura do item de software é realizada levando-se em conta:
A rastreabilidade para os requisitos do item de software;
A consistência externa com os requisitos do item de software;
A consistência interna entre os componentes de software;
A adequação dos métodos e padrões de projeto utilizados;
A viabilidade do projeto detalhado; A viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ser levado em conta na avaliação da arquitetura do item de software a rastreabilidade para os requisitos do item de software. Deve ser levada em conta na avaliação da arquitetura do item de software a consistência externa com os requisitos do item de software. Deve ser levada em conta na avaliação da arquitetura do item de software a consistência interna entre os componentes de software. Deve ser levada em conta na avaliação da arquitetura do item de software a adequação dos métodos e padrões de projeto utilizados. Deve ser levada em conta na avaliação da arquitetura do item de software a viabilidade do projeto detalhado. Deve ser levada em conta na avaliação da arquitetura do item de software a viabilidade da operação e manutenção. (se a pergunta 11 tiver resposta “SIM” o software faz a pergunta abaixo).
14) A avaliação dos projetos para as interfaces externas ao item de software é realizada levando-se em conta:
A rastreabilidade para os requisitos do item de software;
A consistência externa com os requisitos do item de software;
A consistência interna entre os componentes de software;
A adequação dos métodos e padrões de projeto utilizados;
A viabilidade do projeto detalhado; A viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ser levado em conta na avaliação dos projetos para as interfaces externas ao item de software a rastreabilidade para os requisitos do item de software.
95
Deve ser levada em conta na avaliação dos projetos para as interfaces externas ao item de software a consistência externa com os requisitos do item de software. Deve ser levada em conta na avaliação dos projetos para as interfaces externas ao item de software a consistência interna entre os componentes de software. Deve ser levada em conta na avaliação dos projetos para as interfaces externas ao item de software a adequação dos métodos e padrões de projeto utilizados. Deve ser levada em conta na avaliação dos projetos para as interfaces externas ao item de software a viabilidade do projeto detalhado. Deve ser levada em conta na avaliação dos projetos para as interfaces externas ao item de software a viabilidade da operação e manutenção. (se a pergunta 12 tiver resposta “SIM” o software faz a pergunta abaixo).
15) A avaliação do projeto da base de dados é realizada levando-se em conta:
A rastreabilidade para os requisitos do item de software;
A consistência externa com os requisitos do item de software;
A consistência interna entre os componentes de software;
A adequação dos métodos e padrões de projeto utilizados;
A viabilidade do projeto detalhado; A viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ser levado em conta na avaliação do projeto da base de dados a rastreabilidade para os requisitos do item de software. Deve ser levada em conta na avaliação do projeto da base de dados à consistência externa com os requisitos do item de software. Deve ser levada em conta na avaliação do projeto da base de dados à consistência interna entre os componentes de software. Deve ser levada em conta na avaliação do projeto da base de dados à adequação dos métodos e padrões de projeto utilizados. Deve ser levada em conta na avaliação do projeto da base de dados à viabilidade do projeto detalhado. Deve ser levada em conta na avaliação do projeto da base de dados à viabilidade da operação e manutenção. (se a pergunta 10 tiver resposta “SIM” o software faz a pergunta abaixo).
16) A avaliação da arquitetura do item de software é documentada?
Sim; Não.
(peso 10) Solução: A avaliação da arquitetura do item de software deve ser documentada. (se a pergunta 11 tiver resposta “SIM” o software faz a pergunta abaixo).
17) A avaliação dos projetos de interface é documentada?
Sim; Não.
(peso 10) Solução: A avaliação dos projetos de interface deve ser documentada. (se a pergunta 12 tiver resposta “SIM” o software faz a pergunta abaixo).
18) A avaliação da base de dados é documentada? Sim; Não;
(peso 10) Solução: A avaliação da base de dados deve ser documentada.
19) Ocorre a realização de revisões conjuntas de acordo com o processo de revisão conjunta?
Sim; Não.
(peso 10) Solução: Deve ocorrer a realização de revisões conjuntas de acordo com processo de revisão conjunta.
Processo: DESENVOLVIMENTO Atividade: Projeto detalhado de software
1) Ocorre o desenvolvimento de um projeto
detalhado para cada componente de software do item de software?
Sim; Não.
(peso 10) Solução: Deve ocorrer o desenvolvimento de um projeto detalhado para cada componente de software do item de software.
2) Os componentes de software são refinados em níveis mais baixos (maior detalhamento)?
Sim; Não.
(peso 10) Solução: Deve ocorrer o refinamento (maior detalhamento) em níveis mais baixos dos componentes de software. (se a pergunta 2 tiver resposta “SIM” o software faz a pergunta abaixo)
96
3) O componente de software já refinado contém unidades de software que possam ser codificadas, compiladas e testadas?
Sim; Não.
(peso 10) Solução: Os componentes de software já refinados devem conter unidades de software que possam ser codificadas, compiladas e testadas.
4) Ocorre a alocação de todos os requisitos de software para unidades de software a partir dos componentes de software?
Sim; Não.
(peso 10) Solução: Deve ocorrer a alocação de todos os requisitos de software para unidades de software a partir dos componentes de software. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
5) Ocorre a documentação do projeto para cada componente de software do item de software?
Sim; Não.
(peso 10) Solução: Deve ocorrer a documentação do projeto para cada componente de software do item de software.
6) Um projeto detalhado das interfaces externas ao item de software, entre os componentes de software e entre as unidades de software é:
Desenvolvido; Documentado; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Um projeto detalhado das interfaces externas ao item de software, entre os componentes de software e entre as unidades de software deve ser desenvolvido. Um projeto detalhado das interfaces externas ao item de software, entre os componentes de software e entre as unidades de software deve ser documentado. (se a pergunta 6 tiver pontuação total ou parcial o software faz a pergunta abaixo).
7) O projeto detalhado das interfaces externas permite a codificação sem a necessidade de informação adicional?
Sim; Não.
(peso 10) Solução:
O projeto detalhado das interfaces externas deve permitir a codificação sem a necessidade de informação adicional.
8) Um projeto detalhado para a base de dados é: Desenvolvido; Documentado; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ocorrer o desenvolvimento de um projeto detalhado para a base de dados. Deve ocorrer a documentação do projeto para a base de dados.
9) O desenvolvedor atualização da documentação do usuário quando necessário?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve atualizar a documentação do usuário quando necessário.
10) Os requisitos de teste do software são: Definidos; Documentados; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Os requisitos de teste do software devem ser definidos. Os requisitos de teste do software devem ser documentados.
11) O cronograma para testar as unidades de software é:
Definido; Documentado; Todas as opções; Nenhuma das opções.
(peso 10) O cronograma para testar as unidades de software deve ser definido. O cronograma para testar as unidades de software deve ser documentado. (se a pergunta 10 tiver pontuação total ou parcial o software faz a pergunta abaixo).
12) Testes de estresse da unidade de software, até o limite de seus requisitos estão incluídos nos requisitos de teste de software?
Sim; Não.
(peso 2) Solução: Deveria estar incluído nos requisitos de teste do software teste de estresse da unidade de software até o limite de seus requisitos. (se a pergunta 10 tiver pontuação total ou parcial o software faz a pergunta abaixo).
97
13) O desenvolvedor atualiza os requisitos de teste de software?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve atualizar os requisitos de teste de software. (se a pergunta 11 tiver pontuação total ou parcial o software faz a pergunta abaixo).
14) O cronograma para a integração do software é atualizado pelo desenvolvedor?
Sim; Não.
(peso 10) Solução: O cronograma para integração do software deve ser atualizado pelo desenvolvedor. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
15) Ocorre a avaliação do projeto detalhado do software?
Sim; Não.
(peso 10) Solução: Deve ocorrer a avaliação do projeto detalhado do software. (se a pergunta 10 tiver obtido pontuação total ou parcial o sistema faz a pergunta abaixo).
16) Ocorre a avaliação dos requisitos de teste de software?
Sim; Não.
(peso 10) Solução: Deve ocorrer a avaliação dos requisitos de teste de software. (se a pergunta 15 tiver resposta “SIM” o software faz a pergunta abaixo).
17) A avaliação do projeto detalhado do software é realizada levando-se em conta a:
Rastreabilidade para os requisitos do item de software;
Consistência interna entre os componentes e unidade de software;
Consistência externa com o projeto da arquitetura;
Adequação dos métodos e padrões de projeto utilizados;
Viabilidade dos testes; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do projeto detalhado de software deve ser realizada levando-se em conta a
rastreabilidade para os requisitos do item de software. A avaliação do projeto detalhado de software deve ser realizada levando-se em conta a consistência interna entre os componentes e unidade de software. A avaliação do projeto detalhado de software deve ser realizada levando-se em conta a consistência externa com o projeto da arquitetura. A avaliação do projeto detalhado de software deve ser realizada levando-se em conta a adequação dos métodos e padrões de projeto utilizados. A avaliação do projeto detalhado de software deve ser realizada levando-se em conta a viabilidade dos testes. A avaliação do projeto detalhado de software deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 16 tiver resposta “SIM” o software faz a pergunta abaixo).
18) A avaliação dos requisitos de teste de software é realizada levando-se em conta:
Rastreabilidade para os requisitos do item de software;
Consistência interna entre os componentes e unidade de software;
Consistência externa com o projeto da arquitetura;
Adequação dos métodos e padrões de projeto utilizados;
Viabilidade dos testes; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação dos requisitos de teste de software deve ser realizada levando-se em conta a rastreabilidade para os requisitos do item de software. A avaliação dos requisitos de teste de software deve ser realizada levando-se em conta a consistência interna entre os componentes e unidade de software. A avaliação dos requisitos de teste de software deve ser realizada levando-se em conta a consistência externa com o projeto da arquitetura. A avaliação dos requisitos de teste de software deve ser realizada levando-se em conta a adequação dos métodos e padrões de projeto utilizados. A avaliação dos requisitos de teste de software deve ser realizada levando-se em conta a viabilidade dos testes.
98
A avaliação dos requisitos de teste de software deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 15 tiver resposta “SIM” o software faz a pergunta abaixo).
19) É realizada a documentação da avaliação do projeto detalhado do software?
Sim; Não.
(peso 10) Solução: A documentação da avaliação do projeto detalhado do software deve ser realizada. (se a pergunta 16 tiver resposta “SIM” o software faz a pergunta abaixo).
20) É realizada a documentação da avaliação dos requisitos de teste de software?
Sim; Não.
(peso 10) Solução: A documentação da avaliação dos requisitos de teste de software deve ser realizada.
21) Ocorre a realização de revisões conjuntas de acordo com o processo de revisão conjunta?
Sim; Não.
(peso 10) Solução: Deve ocorrer a realização de revisões conjuntas de acordo com o processo de revisão conjunta.
Processo: DESENVOLVIMENTO Atividade: Codificação e Testes de Software 1) Ocorre:
O desenvolvimento de cada unidade de software;
O desenvolvimento da base de dados; A documentação de cada unidade de
software; A documentação da base de dados; O teste de cada unidade de software; O teste da base de dados; A documentação dos testes de cada unidade
de software; A documentação dos testes da base de
dados; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve-se realizar o desenvolvimento de cada unidade de software. Deve-se realizar o desenvolvimento da base de dados. Deve-se realizar a documentação de cada unidade de software.
Deve-se realizar a documentação da base de dados. Deve-se realizar o teste de cada unidade de software. Deve-se realizar o teste da base de dados. Deve-se realizar a documentação dos testes de cada unidade de software. Deve realizar a documentação dos testes da base de software.
2) Ocorre: O desenvolvimento de procedimentos de
teste; O desenvolvimento de dados para testar
cada unidade de software; O desenvolvimento de dados para testar a
base de dados; A documentação dos procedimentos de
teste; A documentação dos dados para testar cada
unidade de software; A documentação dos dados para testes a
base de dados; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve-se realizar o desenvolvimento de procedimentos de testes. Deve-se realizar o desenvolvimento de dados para testar cada unidade de software. Deve-se realizar o desenvolvimento de dados para testar a base de dados. Deve-se realizar a documentação dos procedimentos de teste. Deve-se realizar a documentação dos dados para testar cada unidade de software; Deve-se realizar a documentação dos dados para testes a base de dados.
3) O desenvolvedor atualiza a documentação do usuário quando necessário?
Sim; Não.
(peso 10) Solução: Deve-se haver a atualização da documentação do usuário quando necessário. (se a pergunta 10 da atividade “Projeto detalhado do software” tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
4) Na integração do software o desenvolvedor atualiza os requisitos de teste?
Sim; Não.
(peso 10) Solução: Para realizar a integração do software o desenvolvedor deve atualizar os requisitos de teste.
99
(se a pergunta 11 da atividade “Projeto detalhado do software” tiver obtido pontuação total ou parcial o software faz a pergunta abaixo).
5) O cronograma é atualizado na integração do software?
Sim; Não.
(peso 10) Solução: Para realizar a integração do software o desenvolvedor deve atualizar o cronograma.
6) Ocorre a avaliação do código de software? Sim; Não.
(peso 10) Solução: Deve-se avaliar o código de software. (o software faz a pergunta abaixo se a opção “o teste de cada unidade de software” da questão 1 estiver selecionada).
7) Ocorre a avaliação do resultado dos testes de cada unidade de software?
Sim; Não.
(peso 10) Solução: Deve-se avaliar o resultado dos testes de cada unidade de software. (o software faz a pergunta abaixo se a opção “o teste da base de dados” da questão 1 estiver selecionada).
8) Ocorre a avaliação do resultado dos testes da base de dados?
Sim; Não.
(peso 10) Solução: Deve-se avaliar o resultado dos testes da base de dados. (se a pergunta 6 tiver resposta “SIM” o software faz a pergunta abaixo).
9) A avaliação do código de software ocorre levando-se em conta:
A rastreabilidade para os requisitos e projeto do item de software;
A consistência externa com os requisitos e projeto do item de software;
A consistência interna entre os requisitos da unidade;
A cobertura de teste das unidades; A adequação dos métodos e padrões de
codificação utilizados; A viabilidade da integração e testes de
software; A viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10)
Solução: A avaliação do código de software deve levar em conta a rastreabilidade para os requisitos e projeto do item de software. A avaliação do código de software leva em conta a consistência externa com os requisitos e projeto do item de software. A avaliação do código de software leva em conta a consistência interna entre os requisitos da unidade. A avaliação do código de software leva em conta a cobertura de testes das unidades. A avaliação do código de software leva em conta a adequação dos métodos e padrões de codificação utilizados. A avaliação do código de software leva em conta a viabilidade da integração e testes de software. A avaliação do código de software leva em conta a viabilidade da operação e manutenção. (se a pergunta 7 tiver resposta “SIM” o software faz a pergunta abaixo).
10) A avaliação do resultado dos testes de cada unidade de software ocorre levando-se em conta:
A rastreabilidade para os requisitos e projeto do item de software;
A consistência externa com os requisitos e projeto do item de software;
A consistência interna entre os requisitos da unidade;
A cobertura de teste das unidades; A adequação dos métodos e padrões de
codificação utilizados; A viabilidade da integração e testes de
software; A viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do resultado dos testes de cada unidade de software deve levar em conta a rastreabilidade para os requisitos e projeto do item de software. A avaliação do resultado dos testes de cada unidade de software leva em conta a consistência externa com os requisitos e projeto do item de software. A avaliação do resultado dos testes de cada unidade de software leva em conta a consistência interna entre os requisitos da unidade. A avaliação do resultado dos testes de cada unidade de software leva em conta a cobertura de testes das unidades. A avaliação do resultado dos testes de cada unidade de software leva em conta a adequação
100
dos métodos e padrões de codificação utilizados. A avaliação do resultado dos testes de cada unidade de software leva em conta a viabilidade da integração e testes de software. A avaliação do resultado dos testes de cada unidade de software leva em conta a viabilidade da operação e manutenção. (se a pergunta 8 tiver resposta “SIM” o software faz a pergunta abaixo).
11) A avaliação do resultado dos testes da base de dados ocorre levando-se em conta:
A rastreabilidade para os requisitos e projeto do item de software;
A consistência externa com os requisitos e projeto do item de software;
A consistência interna entre os requisitos da unidade;
A cobertura de teste das unidades; A adequação dos métodos e padrões de
codificação utilizados; A viabilidade da integração e testes de
software; A viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do resultado dos testes da base de dados deve levar em conta a rastreabilidade para os requisitos e projeto do item de software. A avaliação do resultado dos testes da base de dados leva em conta a consistência externa com os requisitos e projeto do item de software. A avaliação do resultado dos testes da base de dados leva em conta a consistência interna entre os requisitos da unidade. A avaliação do resultado dos testes da base de dados leva em conta a cobertura de testes das unidades. A avaliação do resultado dos testes da base de dados leva em conta a adequação dos métodos e padrões de codificação utilizados. A avaliação do resultado dos testes da base de dados leva em conta a viabilidade da integração e testes de software. A avaliação do resultado dos testes da base de dados leva em conta a viabilidade da operação e manutenção. (se a pergunta 6 tiver resposta “SIM” o software faz a pergunta abaixo).
12) É realizada a documentação da avaliação do código de software?
Sim; Não.
(peso 10) Solução:
Deve-se realizar a documentação da avaliação do código de software. (se a pergunta 7 tiver resposta “SIM” o software faz a pergunta abaixo).
13) É realizada a documentação da avaliação do resultado dos testes de cada unidade de software?
Sim; Não.
(peso 10) Solução: Deve-se realizar a documentação da avaliação do resultado dos testes de cada unidade de software. (se a pergunta 8 tiver resposta “SIM” o software faz a pergunta abaixo).
14) É realizada a documentação da avaliação do resultado dos testes da base de dados?
Sim; Não.
(peso 10) Solução: Deve-se realizar a documentação da avaliação do resultado dos testes da base de dados.
Processo: DESENVOLVIMENTO Atividade: Integração do software 1) Ocorre o desenvolvimento de um plano de
integração do software? Sim; Não.
(peso 10) Solução: Deve-se realizar o desenvolvimento de um plano de integração do software. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
2) Esta incluída no plano de integração: Integração das unidades de software; Integração dos componentes de software no
item de software; Requisitos de teste; Procedimentos; Dados; Responsabilidades; Cronograma; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve estar descrito no plano de integração de software a integração das unidades de software. Deve estar descrito no plano de integração de software a integração dos componentes de software no item de software. Deve estar descrito no plano de integração de software o requisito de testes.
101
Deve estar descrito no plano de integração de software o procedimento dos testes. Devem estar descrito no plano de integração de software os dados de testes. Devem estar descrito no plano de integração de software as responsabilidades da integração. Deve estar descrito no plano de integração de software o cronograma da integração. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
3) O plano de integração é documentado? Sim; Não.
(peso 10) Solução: Deve-se haver a documentação do plano de integração.
4) A integração das unidades e componentes de software são testadas pelo desenvolvedor à medida que vão sendo feitas?
Sim; Não.
(peso 10) Solução: Devem-se realizar testes na medida em que vão sendo feitas as integrações das unidades e componentes de software pelo desenvolvedor.
5) É garantido: Que cada agregação atenda os requisitos do
item de software; Que o item de software esteja integrado na
conclusão da atividade de integração; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ser garantido que cada agregação atenda os requisitos do item de software. Deve ser garantido que o item de software esteja integrado na conclusão da atividade de integração.
6) É realizada a documentação dos resultados da integração?
Sim; Não.
(peso 10) Solução: Deve-se realizar a documentação dos resultados da integração. (se a pergunta 4 tiver resposta “SIM” o software faz a pergunta abaixo).
7) É realizada a documentação dos testes realizados na integração?
Sim; Não.
(peso 10) Solução:
Deve-se realizar a documentação dos testes realizados durante a integração das unidades e componentes.
8) O desenvolvedor atualiza a documentação do usuário quando necessário no processo de integração do software?
Sim; Não.
(peso 10) Solução: A documentação do usuário deve ser atualizada quando necessário durante o processo de integração do software.
9) Para cada requisito da qualificação do item de software ocorre:
Desenvolvimento de um conjunto de testes; Desenvolvimento de casos de teste
(entradas, saídas e critérios de teste); Desenvolvimento de procedimentos de
testes; Documentação do conjunto de testes; Documentação dos casos de testes; Documentação dos procedimentos de teste; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve-se para cada requisito da qualificação do item de software realizar-se o desenvolvimento de um conjunto de testes. Deve-se para cada requisito da qualificação do item de software realizar-se o desenvolvimento de casos de teste (entradas, saídas e critérios de teste). Deve-se para cada requisito da qualificação do item de software realizar-se o desenvolvimento de procedimentos de testes. Deve-se para cada requisito da qualificação do item de software realizar-se a documentação do conjunto de testes. Deve-se para cada requisito da qualificação do item de software realizar-se a documentação dos casos de teste. Deve-se para cada requisito da qualificação do item de software realizar-se a documentação dos procedimentos de testes.
10) O desenvolvedor garante que o item de software integrado está pronto para o teste de qualificação do software?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve garantir que o item de software integrado esteja pronto para o teste de qualificação do software. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
11) É realizada a avaliação do plano de integração?
102
Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação do plano de integração.
12) É realizada a avaliação do projeto? Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação do projeto.
13) É realizada a avaliação do código? Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação do código. (se a pergunta 4 tiver resposta “SIM” o software faz a pergunta abaixo).
14) É realizada a avaliação dos testes de integração das unidades e componentes de software?
Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação dos testes de integração das unidades e componentes de software. (se a pergunta 7 tiver resposta “SIM” o software faz a pergunta abaixo).
15) É realizada a avaliação do resultado dos testes de integração das unidades e componentes de software?
Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação do resultado dos testes de integração das unidades e componentes de software.
16) É realizada a avaliação da documentação do usuário?
Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação da documentação do usuário. (se a pergunta 11 tiver resposta “SIM” o software faz a pergunta abaixo).
17) A avaliação do plano de integração é realizada levando-se em conta a:
Rastreabilidade para os requisitos do sistema;
Consistência externa com os requisitos do sistema;
Consistência interna;
Cobertura de teste dos requisitos do item de software;
Adequação dos métodos e padrões de testes utilizados;
Conformidade com os resultados esperados; Viabilidade do teste de qualificação do
software; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do plano de integração é realizada levando-se em conta a rastreabilidade para os requisitos do sistema. A avaliação do plano de integração deve ser realizada levando-se em conta a consistência externa com os requisitos do sistema. A avaliação do plano de integração deve ser realizada levando-se em conta a consistência interna. A avaliação do plano de integração deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação do plano de integração deve ser realizada levando-se em conta a adequação dos métodos e padrões de testes utilizados. A avaliação do plano de integração deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do plano de integração deve ser realizada levando-se em conta a viabilidade do teste de qualificação do software. A avaliação do plano de integração deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 12 tiver resposta “SIM” o software faz a pergunta abaixo).
18) A avaliação do projeto é realizada levando-se em conta a:
Rastreabilidade para os requisitos do sistema;
Consistência externa com os requisitos do sistema;
Consistência interna; Cobertura de teste dos requisitos do item de
software; Adequação dos métodos e padrões de testes
utilizados; Conformidade com os resultados esperados; Viabilidade do teste de qualificação do
software; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução:
103
A avaliação do projeto é realizada levando-se em conta a rastreabilidade para os requisitos do sistema. A avaliação do projeto deve ser realizada levando-se em conta a consistência externa com os requisitos do sistema. A avaliação do projeto deve ser realizada levando-se em conta a consistência interna. A avaliação do projeto deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação do projeto deve ser realizada levando-se em conta a adequação dos métodos e padrões de testes utilizados. A avaliação do projeto deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do projeto deve ser realizada levando-se em conta a viabilidade do teste de qualificação do software. A avaliação do projeto deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 13 tiver resposta “SIM” o software faz a pergunta abaixo).
19) A avaliação do código é realizada levando-se em conta a:
Rastreabilidade para os requisitos do sistema;
Consistência externa com os requisitos do sistema;
Consistência interna; Cobertura de teste dos requisitos do item de
software; Adequação dos métodos e padrões de testes
utilizados; Conformidade com os resultados esperados; Viabilidade do teste de qualificação do
software; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do código é realizada levando-se em conta a rastreabilidade para os requisitos do sistema. A avaliação do código deve ser realizada levando-se em conta a consistência externa com os requisitos do sistema. A avaliação do código deve ser realizada levando-se em conta a consistência interna. A avaliação do código deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação do código deve ser realizada levando-se em conta a adequação dos métodos e padrões de testes utilizados.
A avaliação do código deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do código deve ser realizada levando-se em conta a viabilidade do teste de qualificação do software. A avaliação do código deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 14 tiver resposta “SIM” o software faz a pergunta abaixo).
20) A avaliação dos testes de integração das unidades e componentes de software é realizada levando-se em conta a:
Rastreabilidade para os requisitos do sistema;
Consistência externa com os requisitos do sistema;
Consistência interna; Cobertura de teste dos requisitos do item de
software; Adequação dos métodos e padrões de testes
utilizados; Conformidade com os resultados esperados; Viabilidade do teste de qualificação do
software; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação dos testes de integração das unidades e componentes de software é realizada levando-se em conta a rastreabilidade para os requisitos do sistema. A avaliação dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a consistência externa com os requisitos do sistema. A avaliação dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a consistência interna. A avaliação dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a adequação dos métodos e padrões de testes utilizados. A avaliação dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a viabilidade do teste de qualificação do software.
104
A avaliação dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 15 tiver resposta “SIM” o software faz a pergunta abaixo).
21) A avaliação do resultado dos testes de integração das unidades e componentes de software é realizada levando-se em conta a:
Rastreabilidade para os requisitos do sistema;
Consistência externa com os requisitos do sistema;
Consistência interna; Cobertura de teste dos requisitos do item de
software; Adequação dos métodos e padrões de testes
utilizados; Conformidade com os resultados esperados; Viabilidade do teste de qualificação do
software; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do resultado dos testes de integração das unidades e componentes de software é realizada levando-se em conta a rastreabilidade para os requisitos do sistema. A avaliação do resultado dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a consistência externa com os requisitos do sistema. A avaliação do resultado dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a consistência interna. A avaliação do resultado dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação do resultado dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a adequação dos métodos e padrões de testes utilizados. A avaliação do resultado dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do resultado dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a viabilidade do teste de qualificação do software.
A avaliação do resultado dos testes de integração das unidades e componentes de software deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 16 tiver resposta “SIM” o software faz a pergunta abaixo).
22) A avaliação da documentação do usuário é realizada levando-se em conta:
Rastreabilidade para os requisitos do sistema;
Consistência externa com os requisitos do sistema;
Consistência interna; Cobertura de teste dos requisitos do item de
software; Adequação dos métodos e padrões de testes
utilizados; Conformidade com os resultados esperados; Viabilidade do teste de qualificação do
software; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação da documentação do usuário é realizada levando-se em conta a rastreabilidade para os requisitos do sistema. A avaliação da documentação do usuário deve ser realizada levando-se em conta a consistência externa com os requisitos do sistema. A avaliação da documentação do usuário deve ser realizada levando-se em conta a consistência interna. A avaliação da documentação do usuário deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação da documentação do usuário deve ser realizada levando-se em conta a adequação dos métodos e padrões de testes utilizados. A avaliação da documentação do usuário deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação da documentação do usuário deve ser realizada levando-se em conta a viabilidade do teste de qualificação do software. A avaliação da documentação do usuário deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 11 tiver resposta “SIM” o software faz a pergunta abaixo).
23) É realizada a documentação da avaliação do plano de integração?
Sim; Não.
(peso 10) Solução:
105
Deve ser realizada a documentação da avaliação do plano de integração. (se a pergunta 12 tiver resposta “SIM” o software faz a pergunta abaixo).
24) É realizada a documentação da avaliação do projeto?
Sim; Não.
(peso 10) Solução: Deve ser realizada a documentação da avaliação do projeto. (se a pergunta 13 tiver resposta “SIM” o software faz a pergunta abaixo).
25) É realizada a documentação da avaliação do código?
Sim; Não.
(peso 10) Solução: Deve ser realizada a documentação da avaliação do código. (se a pergunta 14 tiver resposta “SIM” o software faz a pergunta abaixo).
26) É realizada a documentação da avaliação dos testes de integração das unidades e componentes de software?
Sim; Não.
(peso 10) Solução: Deve ser realizada a documentação da avaliação dos testes de integração das unidades e componentes de software. (se a pergunta 15 tiver resposta “SIM” o software faz a pergunta abaixo).
27) É realizada a documentação da avaliação do resultado dos testes de integração das unidades e componentes de software?
Sim; Não.
(peso 10) Solução: Deve ser realizada a documentação da avaliação do resultado dos testes de integração das unidades e componentes de software. (se a pergunta 16 tiver resposta “SIM” o software faz a pergunta abaixo).
28) É realizada a documentação da avaliação da documentação do usuário?
Sim; Não.
(peso 10) Solução: Deve ser realizada a documentação da avaliação da documentação do usuário.
29) Ocorre a realização de revisões conjuntas de acordo com o processo de revisão conjunta?
Sim;
Não. (peso 10) Solução: Deve ocorrer a realização de revisões conjuntas de acordo com o processo de revisão conjunta.
Processo: DESENVOLVIMENTO Atividade: Teste de qualificação do software 1) Os testes de qualificação são conduzidos pelo
desenvolvedor de acordo com os requisitos de qualificação para o item de software?
Sim; Não.
(peso 10) Solução: Os testes de qualificação devem ser conduzidos pelo desenvolvedor de acordo com os requisitos de qualificação para o item de software.
2) A implementação de cada requisito de software é testada para conformidade?
Sim; Não.
(peso 10) Solução: A implementação de cada requisito de software deve ser testada para conformidade. (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo)
3) Os resultados dos testes de qualificação são documentados?
Sim; Não.
(peso 10) Solução: Os resultados dos testes de qualificação devem ser documentados.
4) O desenvolvedor atualiza a documentação do usuário quando necessário no processo de teste de qualificação do software?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve atualizar a documentação do usuário quando necessário no processo de teste de qualificação do software.
5) Ocorre a avaliação do projeto? Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação do projeto.
6) Ocorre a avaliação do código? Sim; Não.
(peso 10) Solução:
106
Deve-se realizar a avaliação do código. (se a pergunta 1 tiver resposta “SIM” o software faz a pergunta abaixo).
7) Ocorre a avaliação dos testes de qualificação? Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação dos testes de qualificação. (se a pergunta 3 tiver resposta “SIM” o software faz a pergunta abaixo).
8) Ocorre a avaliação do resultado dos testes de qualificação?
Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação do resultado dos testes de qualificação.
9) Ocorre a avaliação da documentação do usuário?
Sim; Não.
(peso 10) Solução: Deve-se realizar a avaliação da documentação do usuário. (se a pergunta 5 tiver resposta “SIM” o software faz a pergunta abaixo).
10) A avaliação do projeto é realizada levando-se em conta a:
Cobertura de teste dos requisitos do item de software;
Conformidade com os resultados esperados; Viabilidade da integração e testes do
sistema, se conduzidos; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do projeto deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação do projeto deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do projeto deve ser realizada levando-se em conta a viabilidade da integração e testes do sistema, se conduzidos. A avaliação do projeto deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 6 tiver resposta “SIM” o software faz a pergunta abaixo).
11) A avaliação do código é realizada levando-se em conta a:
Cobertura de teste dos requisitos do item de software;
Conformidade com os resultados esperados; Viabilidade da integração e testes do
sistema, se conduzidos; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do código deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação do código deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do código deve ser realizada levando-se em conta a viabilidade da integração e testes do sistema, se conduzidos. A avaliação do código deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 7 tiver resposta “SIM” o software faz a pergunta abaixo).
12) A avaliação dos testes de qualificação é realizada levando-se em conta a:
Cobertura de teste dos requisitos do item de software;
Conformidade com os resultados esperados; Viabilidade da integração e testes do
sistema, se conduzidos; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação dos testes de qualificação deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação dos testes de qualificação deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação dos testes de qualificação deve ser realizada levando-se em conta a viabilidade da integração e testes do sistema, se conduzidos. A avaliação dos testes de qualificação deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 8 tiver resposta “SIM” o software faz a pergunta abaixo).
13) A avaliação do resultado dos testes de qualificação é realizada levando-se em conta a:
Cobertura de teste dos requisitos do item de software;
Conformidade com os resultados esperados; Viabilidade da integração e testes do
sistema, se conduzidos; Viabilidade da operação e manutenção; Todas as opções;
107
Nenhuma das opções. (peso 10) Solução: A avaliação do resultado dos testes de qualificação deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação do resultado dos testes de qualificação deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do resultado dos testes de qualificação deve ser realizada levando-se em conta a viabilidade da integração e testes do sistema, se conduzidos. A avaliação do resultado dos testes de qualificação deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 9 tiver resposta “SIM” o software faz a pergunta abaixo).
14) A avaliação da documentação do usuário ocorre levando-se em conta a:
Cobertura de teste dos requisitos do item de software;
Conformidade com os resultados esperados; Viabilidade da integração e testes do
sistema, se conduzidos; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação da documentação do usuário deve ser realizada levando-se em conta a cobertura de teste dos requisitos do item de software. A avaliação da documentação do usuário deve ser realizada levando-se em conta a conformidade com os resultados esperados. A avaliação da documentação do usuário deve ser realizada levando-se em conta a viabilidade da integração e testes do sistema, se conduzidos. A avaliação da documentação do usuário deve ser realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 5 tiver resposta “SIM” o software faz a pergunta abaixo).
15) É realizada a documentação da avaliação do projeto?
Sim; Não.
(peso 10) Solução: A documentação da avaliação do projeto deve ser realizada. (se a pergunta 6 tiver resposta “SIM” o software faz a pergunta abaixo).
16) É realizada a documentação da avaliação do código?
Sim; Não.
(peso 10) Solução: A documentação da avaliação do código deve ser realizada. (se a pergunta 7 tiver resposta “SIM” o software faz a pergunta abaixo).
17) É realizada a documentação da avaliação dos testes de qualificação?
Sim; Não.
(peso 10) Solução: A documentação da avaliação dos testes de qualificação deve ser realizada. (se a pergunta 8 tiver resposta “SIM” o software faz a pergunta abaixo).
18) É realizada a documentação do resultado dos testes de qualificação?
Sim; Não.
(peso 10) Solução: A documentação da avaliação dos testes de qualificação deve ser realizada. (se a pergunta 9 tiver resposta “SIM” o software faz a pergunta abaixo).
19) É realizada a documentação da avaliação da documentação do usuário?
Sim; Não.
(peso 10) Solução: A documentação da avaliação da documentação do usuário deve ser realizada.
20) O desenvolvedor apóia as auditorias de acordo com o Processo de Auditoria?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve apoiar as auditorias de acordo com o Processo de Auditoria. (se a pergunta 20 tiver resposta “SIM” o software faz a pergunta abaixo).
21) O resultado da auditoria é documentado? Sim; Não.
(peso 10) Solução: O resultado da auditoria deve ser documentado. (se a pergunta 20 tiver resposta “SIM” o software faz a pergunta abaixo).
22) Uma vez bem sucedida a conclusão das auditorias, o desenvolvedor deve:
Atualizar e preparar o produto de software a ser entregue para a integração do sistema;
108
Atualizar e preparar o produto de software a ser entregue ao teste de qualificação do sistema;
Atualizar e preparar o produto de software a ser entregue a instalação ou apoio à aceitação do software, quando aplicável;
Estabelecer uma linha básica para o projeto e código do item de software.
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Uma vez bem sucedida a conclusão das auditorias o desenvolvedor deve atualizar e preparar o produto de software a ser entregue para a integração do sistema. Uma vez bem sucedida a conclusão das auditorias o desenvolvedor deve atualizar e preparar o produto de software a ser entregue a instalação ou apoio à aceitação do software, quando aplicável. Uma vez bem sucedida a conclusão das auditorias o desenvolvedor deve estabelecer uma linha básica para o projeto e código do item de software.
Processo: DESENVOLVIMENTO Atividade: Integração do sistema 1) Os itens de configuração de software são
integrados ao sistema com os itens de configuração de hardware, com operações manuais e com outros sistemas, quando necessário?
Sim; Não.
(peso 10) Solução: Os itens de configuração de software devem ser integrados com os itens de configuração de hardware, com operações manuais e com os outros sistemas quando necessário.
2) As agregações são testadas no momento da integração, de acordo com seus requisitos?
Sim; Não.
(peso 10) Solução: As agregações devem ser testadas no momento da integração de acordo com seus requisitos.
3) É realizada a documentação da integração do software?
Sim; Não.
(peso 10) Solução: A documentação da integração do software deve ser realizada.
4) Para cada requisito da qualificação do sistema ocorre:
Desenvolvimento de um conjunto de testes; Desenvolvimento de casos de teste
(entradas, saídas e critérios de teste); Desenvolvimento de procedimentos de
testes; Documentação do conjunto de testes; Documentação dos casos de testes; Documentação dos procedimentos de teste; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ocorrer o desenvolvimento de um conjunto de testes para cada requisito da qualificação do sistema. Deve ocorrer o desenvolvimento de casos de teste (entradas, saídas e critérios de teste) para cada requisito da qualificação do sistema. Deve ocorrer o desenvolvimento de procedimentos de testes para cada requisito da qualificação do sistema. Deve ocorrer à documentação do conjunto de testes para cada requisito da qualificação do sistema. Deve ocorrer à documentação dos casos de testes para cada requisito da qualificação do sistema. Deve ocorrer à documentação dos procedimentos de teste para cada requisito da qualificação do sistema.
5) O desenvolvedor garante que o sistema integrado está pronto para o teste de qualificação do sistema?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve garantir que o sistema integrado esteja pronto para o teste de qualificação do sistema.
6) O sistema integrado é avaliado? Sim; Não.
(peso 10) Solução: O sistema integrado deve ser avaliado. (se a pergunta 6 tiver resposta “SIM” o sistema faz a pergunta abaixo).
7) A avaliação é realizada levando-se em conta a: Cobertura de teste dos requisitos do
sistema; Adequação dos métodos e padrões de teste
utilizados; Conformidade com os resultados esperados; Viabilidade do teste de qualificação do
sistema; Viabilidade da operação e manutenção;
109
Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do sistema integrado é realizada levando-se em conta a cobertura de teste dos requisitos do sistema. A avaliação do sistema integrado é realizada levando-se em conta a adequação dos métodos e padrões de teste utilizados. A avaliação do sistema integrado é realizada levando-se em conta a conformidade com os resultados esperados. A avaliação do sistema integrado é realizada levando-se em conta a viabilidade do teste de qualificação do sistema. A avaliação do sistema integrado é realizada levando-se em conta a viabilidade da operação e manutenção. (se a pergunta 6 tiver resposta “SIM” o sistema faz a pergunta abaixo).
8) A avaliação do sistema integrado é documentada?
Sim; Não.
(peso 10) Solução: A avaliação do sistema integrado deve ser documentada.
Processo: DESENVOLVIMENTO Atividade: Teste de qualificação do sistema 1) Os testes de qualificação são conduzidos pelo
desenvolvedor de acordo com os requisitos de qualificação especificados para o sistema?
Sim; Não.
(peso 10) Solução: Os testes de qualificação devem ser conduzidos pelo desenvolvedor de acordo com os requisitos de qualificação especificados para o sistema.
2) A implementação de cada requisito do sistema é testada para conformidade?
Sim; Não.
(peso 10) Solução: Deve ser testada para conformidade a implementação de cada requisito do sistema. (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo)
3) Os resultados dos testes de qualificação são documentados?
Sim; Não.
(peso 10) Solução: Deve-se documentar o resultado dos testes de qualificação do sistema.
4) Ocorre a avaliação do sistema (finalizado)? Sim; Não.
(peso 10) Solução: O sistema finalizado deve ser avaliado. (se a pergunta 4 tiver resposta “SIM” o sistema faz a pergunta abaixo)
5) A avaliação ocorre levando-se em conta a: Cobertura de teste dos requisitos do
sistema; Conformidade com os resultados esperados; Viabilidade da operação e manutenção; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A avaliação do sistema finalizado leva em conta a cobertura de teste dos requisitos do sistema. A avaliação do sistema finalizado leva em conta a conformidade com os resultados esperados. A avaliação do sistema finalizado leva em conta a viabilidade da operação e manutenção.
6) A avaliação do sistema é documentada? Sim; Não.
(peso 10) Solução: A avaliação do sistema finalizado deve ser documentada.
7) O desenvolvedor apóia as auditorias de acordo com o Processo de Auditoria?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve apoiar as auditorias de acordo com o Processo de Auditoria. (se a pergunta 7 tiver resposta “SIM” o sistema faz a pergunta abaixo).
8) O resultado da auditoria é documentado? Sim; Não.
(peso 10) Solução: O resultado da auditoria deve ser documentado. (se a pergunta 7 tiver resposta “SIM” o sistema faz a pergunta abaixo).
9) Uma vez bem sucedida a conclusão das auditorias, o desenvolvedor deve:
Atualizar e preparar o produto de software a ser entregue para a instalação do software;
110
Atualizar e preparar o produto de software a ser entregue para o apoio à aceitação do software;
Estabelecer uma linha básica para o projeto e código de cada item de configuração de software;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Uma vez bem sucedida a conclusão das auditorias o desenvolvedor deve atualizar e preparar o produto de software a ser entregue para a instalação do software. Uma vez bem sucedida a conclusão das auditorias o desenvolvedor deve atualizar e preparar o produto de software a ser entregue para o apoio à aceitação do software. Uma vez bem sucedida a conclusão das auditorias o desenvolvedor deve estabelecer uma linha básica para o projeto e código de cada item de configuração de software.
Processo: DESENVOLVIMENTO Atividade: Instalação do software 1) Um plano para instalar o produto de software
no ambiente-alvo é desenvolvido? Sim; Não.
(peso 10) Solução: Deve ser desenvolvido um plano para instalar o produto de software no ambiente-alvo. (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo).
2) O plano desenvolvido esta de acordo com o contrato?
Sim; Não.
(peso 10) Solução: O plano para instalar o produto de software no ambiente-alvo deve estar de acordo com o contrato.
3) Os recursos e informações para instalar o produto de software são determinados e estão disponíveis?
Sim; Não.
(peso 10) Solução: Devem estar determinados e disponíveis os recursos e informações para instalar o produto de software. (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo)
4) O plano de instalação desenvolvido é documentado?
Sim; Não.
(peso 10) Solução: O plano de instalação desenvolvido para instalar o software no ambiente-alvo deve ser documentado.
5) Quando especificado no contrato o desenvolvedor auxilia o adquirente com as atividades de preparação?
Sim; Não; Não aplicável.
(peso 10) Solução: Se especificado no contrato o desenvolvedor deve auxiliar o adquirente com as atividades de preparação.
6) O produto de software a ser instalado está substituindo um sistema existente?
Sim; Não.
(peso 1) Solução: O produto de software a ser instalado pode substituir um sistema existente. (se a pergunta 6 tiver resposta “SIM” o sistema faz a pergunta abaixo).
7) O desenvolvedor apóia a execução de qualquer atividade paralela, conforme especificado no contrato?
Sim; Não; Não aplicável.
Solução: O desenvolvedor deve apoiar a execução de qualquer atividade paralela conforme especificado no contrato. (peso 10) (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo).
8) O desenvolvedor realiza a instalação do produto de software conforme especificado no plano de instalação?
Sim; Não.
(peso 10) Solução: A instalação do produto de software deve ser realizada pelo desenvolvedor conforme especificado no plano de instalação.
9) O código de software e as bases de dados, conforme especificado no contrato são:
Iniciadas; Executadas; Finalizadas; Todas as opções; Nenhuma das opções.
(peso 10)
111
Solução: O código de software e a base de dados devem ser iniciados conforme especificado no contrato. O código de software e a base de dados devem ser executados conforme especificado no contrato. O código de software e a base de dados devem ser finalizados conforme especificado no contrato.
10) Os eventos e resultados da instalação são documentados?
Sim; Não.
(peso 10) Solução: Os eventos e resultados da instalação devem ser documentados.
Processo: DESENVOLVIMENTO Atividade: Apoio à aceitação do software 1) É realizada revisão de aceitação e testes do
produto de software pelo adquirente? Sim; Não.
(peso 10) Solução: Deve ser realizado pelo adquirente revisão de aceitação e testes do produto de software. (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo).
2) O desenvolvedor apóia a revisão de aceitação do adquirente e testes do produto de software?
Sim; Não.
(peso 10) Solução: Deve ser apoiada pelo desenvolvedor a revisão de aceitação e testes do produto de software feito pelo adquirente. (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo);
3) A revisão de aceitação e testes considera o: Resultado de revisões conjuntas; Resultado de auditorias; Teste de qualificação do software; Teste de qualificação do sistema; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A revisão de aceitação e testes do produto de software deve considerar o resultado de revisões conjuntas. A revisão de aceitação e testes do produto de software deve considerar o resultado de auditorias.
A revisão de aceitação e testes do produto de software deve considerar o teste de qualificação do software. A revisão de aceitação e testes do produto de software deve considerar o teste de qualificação do sistema. (se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo).
4) Os resultados da revisão de aceitação e testes são documentados?
Sim; Não.
(peso 10) Solução: Os resultados da revisão de aceitação e testes devem ser documentados.
5) O desenvolvedor conclui e entrega o produto de software conforme especificado no contrato?
Sim; Não.
(peso 10) Solução: O desenvolvedor deve concluir a entrega do produto de software conforme especificado no contrato.
6) O desenvolvedor prove, conforme especificado no contrato:
Treinamento inicial; Suporte; Todas as opções; Nenhum dos itens
(peso 10) Solução: O desenvolvedor deve prover, conforme especificado no contrato, treinamento inicial. O desenvolvedor deve prover, conforme especificado no contrato, suporte.
Processo: OPERAÇÃO Atividade: Implementação do Processo 1) Ocorre o desenvolvimento de um plano e de
um conjunto de padrões de operação para colocar em prática as atividades e tarefas do Processo de Operação?
Sim; Não.
(peso 10). Solução: Deve-se realizar o desenvolvimento de um plano e de um conjunto de padrões de operação para colocar em prática as atividades e tarefas do Processo de Operação. (Se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo).
2) O plano desenvolvido é: Documentado; Executado (na prática);
112
Todas as opções; Nenhuma das opções.
(peso 10) Solução Deve-se realizar a documentação do plano de Processo de Operação. Deve se executado em sua totalidade o plano de Processo de Operação.
3) Ocorre o estabelecimento de procedimentos para:
Receber problemas; Registrar problemas; Resolver problemas; Rastrear problemas; Prover realimentação (feedback); Todas as opções; Nenhuma das opções.
(peso 10); Solução Devem-se estabelecer procedimentos para a recepção de problemas. Devem-se estabelecer procedimentos para o registro dos problemas. Devem-se estabelecer procedimentos para a resolução dos problemas. Devem-se estabelecer procedimentos para o feedback.
4) Quando é descoberto um problema o mesmo é: Registrado; Incluído no processo de resolução de
problema; Todas as opções; Nenhuma das opções.
(peso 10); Solução: Ao ser descoberto um problema o mesmo deve ser registrado. Ao ser descoberto um problema o mesmo deve ser incluído no processo de resolução de problema.
5) Ocorre o estabelecimento de procedimentos para:
Testar o produto de software no seu ambiente de operação;
Inserir relatórios de problemas e pedidos de modificação no processo de manutenção;
Liberar o produto de software para uso operacional;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Devem-se estabelecer procedimentos para testar o produto de software em seu ambiente de operação. Devem-se estabelecer procedimentos para a inserção de relatórios de problemas e pedidos de modificação no processo de manutenção.
Devem-se estabelecer procedimentos para a liberação do produto de software para o uso operacional.
Processo: OPERAÇÃO Atividade: Teste operacional 1) Para cada liberação do produto de software o
operador: Executa testes operacionais; Satisfaz os critérios especificados; Todas as opções; Nenhuma das opções.
(peso 10). Solução: Testes operacionais devem ser executados antes da liberação do produto de software. Os critérios especificados devem ser atendidos antes da liberação do produto de software. (Se a pergunta 1 da atividade Implementação do Processo tiver resposta “SIM” o sistema faz a pergunta abaixo).
2) O código de software e as bases de dados são: Iniciados; Executados; Finalizados; Todas as opções; Nenhuma das opções.
(peso 10). Solução: O código de software e a base de dados devem ser iniciados. O código de software e a base de dados devem ser executados. O código de software e a base de dados devem ser finalizados. (Se a pergunta 2 tiver obtido pontuação total ou parcial o sistema faz a pergunta abaixo)
3) Os procedimentos realizados no código de software e bases de dados (questão anterior) seguem o que está determinado no plano para colocar em prática as atividades e tarefas do Processo de Operação?
Sim; Não.
(peso 10). Solução: Os procedimentos realizados no código de software e bases de dados devem seguir o que está determinado no plano para colocar em prática as atividades e tarefas do Processo de Operação.
Processo: OPERAÇÃO Atividade: Operação do Sistema 1) O sistema é operado no ambiente para o qual
foi pretendido (desenvolvido), de acordo com a documentação do usuário?
113
Sim; Não.
(peso 10). Solução: O sistema deve ser operado no ambiente para o qual foi desenvolvido de acordo com a documentação do usuário.
Processo: OPERAÇÃO Atividade: Suporte ao Usuário 1) Quando solicitado o operador provê assistência
e consultoria aos usuários? Sim; Não.
(peso 10). Solução: O operador deve prover assistência e consultoria quando solicitado pelos usuários. (Se a pergunta 1 tiver resposta “SIM” o sistema faz a pergunta abaixo).
2) Estas solicitações e ações subseqüentes (referente à assistência e consultoria) são:
Registradas; Monitoradas; Todas as opções; Nenhuma das opções.
(peso 10). Solução: Os pedidos de assistência e consultoria solicitadas pelos usuários devem ser registrados. Os pedidos de assistência e consultoria solicitadas pelos usuários devem ser monitorados.
3) Quando necessário o operador encaminha as solicitações do usuário para resolução no processo de manutenção?
Sim; Não.
(peso 10). Solução: O operador deve encaminhar as solicitações do usuário para resolução no processo de manutenção quando necessário. (Se a pergunta 3 tiver resposta “SIM” o sistema faz a pergunta abaixo).
4) As ações que forem planejadas e executadas no processo de manutenção são relatadas aos solicitantes?
Sim; Não.
(peso 10) As ações que foram planejadas e executadas no processo de manutenção devem ser relatadas aos solicitantes. (Se a pergunta 3 tiver resposta “SIM” o sistema faz a pergunta abaixo).
5) Ocorre o monitoramento de todas as resoluções até a sua conclusão?
Sim; Não.
(peso 10) Solução: Deve haver o monitoramento de todas as resoluções até a sua conclusão.
6) É dada ao solicitante a opção de usar uma solução provisória para seu problema caso não tenha sido encontrado ainda uma solução definitiva para o mesmo?
Sim; Não.
(peso 10) Solução: Deve ser dada ao solicitante a opção de usar uma solução provisória para seu problema caso não tenha sido encontrado uma solução definitiva para o mesmo.
7) É aplicado ao produto de software em operação, utilizando-se o processo de manutenção a:
Correções definitivas; Liberações que incluem funções ou
características previamente omitidas; Melhorias do sistema; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve-se aplicar ao produto de software em operação correções definitivas. Deve-se aplicar ao produto de software em operação liberações que incluem funções ou características previamente omitidas. Deve-se aplicar ao produto de software em operação melhorias do sistema.
Processo: MANUTENÇÃO Atividade: Implementação do processo 1) Ocorre o desenvolvimento, documentação e
execução de planos e procedimentos para executar as atividades e tarefas do Processo de Manutenção?
Sim; Não.
(peso 10) Solução: Deve ocorrer o desenvolvimento, documentação e execução de planos e procedimentos para executar as atividade e tarefas do processo de manutenção.
2) Ocorre o estabelecimento de procedimentos para:
Receber problemas; Registrar problemas; Rastrear relatórios de problemas;
114
Rastrear pedidos de modificação dos usuários;
Prover realimentação (feedback) para os usuários;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve ocorrer o estabelecimento de procedimentos para receber problemas. Deve ocorrer o estabelecimento de procedimentos para registrar problemas. Deve ocorrer o estabelecimento de procedimentos para rastrear relatórios de problemas. Deve ocorrer o estabelecimento de procedimentos para rastrear pedidos de modificação dos usuários. Deve ocorrer o estabelecimento de procedimentos para prover realimentação para os usuários.
3) Quando é descoberto um problema o mesmo é: Registrado; Incluído no processo de resolução de
problema; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Um problema deve ser registrado quando descoberto. Um problema deve se incluído no processo de resolução de problemas quando descoberto.
4) Ocorre a implementação do processo de gerência de configuração no intuito de gerenciar modificações realizadas no sistema?
Sim; Não.
(peso 10) Solução: Deve ocorrer a implementação do processo de gerência de configuração no intuito de gerenciar modificações realizadas no sistema.
Processo: MANUTENÇÃO Atividade: Análise do problema e da modificação 1) Para cada relatório de problema ou pedido de
modificação ocorre uma análise segundo o seu impacto:
Para a organização; Em si mesmo; Nos sistemas com o qual interage; Todas as opções; Nenhuma das opções.
(peso 10) Solução:
Para cada relatório de problema ou pedido de modificação deve ocorrer uma análise segundo seu impacto para a organização. Para cada relatório de problema ou pedido de modificação deve ocorrer uma análise segundo seu impacto em si mesmo. Para cada relatório de problema ou pedido de modificação deve ocorrer uma análise segundo seu impacto nos sistemas como qual interage.
2) Para cada relatório de problema ou pedido de modificação ocorre uma análise em relação ao seu:
Tipo: por exemplo, corretivo, melhoria, prevenção, adaptação para um novo ambiente;
Escopo: por exemplo: tamanho da modificação, custo envolvido, prazo para modificar.
Criticidade: por exemplo, impacto no desempenho, proteção ou segurança.
Todas as opções; Nenhuma das opções.
(peso 10) Solução: Para cada relatório de problema ou pedido de modificação deve ocorrer uma análise em relação ao seu tipo. Para cada relatório de problema ou pedido de modificação deve ocorrer uma análise em relação ao seu escopo. Para cada relatório de problema ou pedido de modificação deve ocorrer uma análise em relação a sua criticidade.
3) Ocorre a reprodução ou verificação do problema?
Sim; Não.
(peso 10) Solução: Deve-se reproduzir ou verificar o problema.
4) Ocorre o desenvolvimento de alternativas para a implantação da modificação?
Sim; Não.
(peso 10) Solução: Deve ocorrer o desenvolvimento de alternativas para a implantação da modificação. (Se a resposta da pergunta 4 for “SIM” o sistema faz a pergunta abaixo).
5) Estas alternativas são baseadas na análise do relatório de problema ou pedido de modificação?
Sim; Não.
(peso 10) Solução: As alternativas para a implantação da modificação devem ser baseadas na análise do
115
relatório do problema ou pedido de modificação.
6) Ocorre a documentação do relatório de problema ou pedido de modificação?
Sim; Não.
(peso 10) Solução: Deve ocorrer a documentação do relatório de problema ou pedido de modificação. (Se a pergunta 1 ou 2 tiverem obtido pontuação total ou parcial o sistema faz a pergunta abaixo).
7) Ocorre a documentação do resultado da análise do relatório de problema ou pedido de modificação?
Sim; Não.
(peso 10) Solução: Deve-se documentar o resultado da análise do relatório de problema e pedido de modificação. (Se a resposta da pergunta 4 for “SIM” o sistema faz a pergunta abaixo).
8) Ocorre a documentação das alternativas de implantação da modificação?
Sim; Não.
(peso 10) Solução: Devem-se documentar as alternativas encontradas para a implantação da modificação. (Se a resposta da pergunta 4 for “SIM” o sistema faz a pergunta abaixo).
9) A alternativa de modificação que é selecionada é aprovada pelo adquirente?
Sim; Não.
(peso 10) Solução: Deve ser aprovada pelo adquirente a alternativa de modificação selecionada. (Se a resposta da pergunta 9 for “SIM” o sistema faz a pergunta abaixo).
10) O processo de aprovação da modificação ocorre conforme especificado no contrato?
Sim; Não.
(peso 10) Solução: O processo de aprovação deve ocorrer conforme especificado no contrato.
Processo: MANUTENÇÃO Atividade: Implementação da modificação 1) É realizada alguma análise para determinar se
os itens abaixo necessitam ser modificados.
Unidades de software; Versões destas (unidades de software); Documentação; Todas as opções; Nenhuma das opções.
(peso 10) Solução: Deve-se realizar alguma análise para determinar se existe a necessidade de modificar as unidades de software. Deve-se realizar alguma análise para determinar se existe a necessidade de modificar as versões das unidades de software. Deve-se realizar alguma análise para determinar se existe a necessidade de modificar a documentação. (Se a pergunta 1 obter pontuação total ou parcial o sistema faz a pergunta abaixo).
2) A análise para determinar a necessidade de modificações é documentada?
Sim; Não.
(peso 10) Solução: Deve-se documentar a análise para determinar a necessidade de modificações.
3) Para implantar as modificações o Processo de Desenvolvimento é utilizado?
Sim; Não.
(peso 10) Solução: O processo de desenvolvimento deve ser utilizado para implantar as modificações. (Se a resposta da pergunta 3 for “SIM” o sistema faz a pergunta abaixo).
4) O Processo de Desenvolvimento é complementado com:
Definição de critério de testes; Documentação de critério de teste; Definição de critérios de avaliação; Documentação dos critérios de avaliação; Todas as opções; Nenhuma das opções.
(peso 10). Solução: O processo de desenvolvimento deve ser complementado com a definição de critério de testes. O processo de desenvolvimento deve ser complementado com a documentação de critérios de testes. O processo de desenvolvimento deve ser complementado com a definição de critérios de avaliação. O processo de desenvolvimento deve ser complementado com a documentação dos critérios de avaliação.
116
(Se a pergunta 4 obter pontuação total ou parcial o sistema faz a pergunta abaixo).
5) A complementação do Processo de Desenvolvimento é utilizada para:
Testar partes modificadas do sistema; Avaliar partes modificadas do sistema; Testar partes não modificadas do sistema; Avaliar partes não modificadas do sistema; Todas as opções; Nenhuma das opções.
(peso 10) Solução: A complementação do processo de desenvolvimento deve ser utilizada para testar partes modificadas do sistema. A complementação do processo de desenvolvimento deve ser utilizada para avaliar partes modificadas do sistema. A complementação do processo de desenvolvimento deve ser utilizada para testar partes não modificadas do sistema. A complementação do processo de desenvolvimento deve ser utilizada para avaliar partes não modificadas do sistema. (Se a resposta da pergunta 3 for “SIM” o sistema faz a pergunta abaixo).
6) É garantida a completa e correta implementação dos requisitos novos e dos modificados?
Sim; Não.
(peso 10) Solução: Deve ser garantida a completa e correta implementação dos requisitos novos e dos modificados no sistema. (Se a resposta da pergunta 3 for “SIM” o sistema faz a pergunta abaixo).
7) É garantido que os requisitos originais não modificados não foram afetados?
Sim; Não.
(peso 10) Solução: Aos requisitos originais não modificados deve ser garantido que estes não sejam afetados. (Se a resposta da pergunta 3 for “SIM” o sistema faz a pergunta abaixo).
8) Quando realizado os testes, seus resultados são documentados?
Sim; Não.
(peso 10) Solução: Quando realizado os testes nas modificações estes devem ser documentados.
Processo: MANUTENÇÃO Atividade: Revisão/aceitação da manutenção
1) São feitas revisões com a organização que
autorizou a modificação para determinar a integridade do sistema?
Sim; Não.
(peso 10) Solução: Devem ser realizadas revisões com a organização que autorizou a modificação para determinar-se a integridade do sistema.
2) É obtida a aprovação para a conclusão das modificações?
Sim; Não.
(peso 10) Solução: Deve ser obtida a aprovação para a conclusão das modificações no sistema. (Se a resposta da pergunta 2 for “SIM” o sistema faz a pergunta abaixo).
3) Esta aprovação ocorre de acordo com o que está especificado no contrato?
Sim; Não.
(peso 10) Solução: A aprovação das modificações deve ocorrer de acordo com o que está especificado no contrato.
Processo: MANUTENÇÃO Atividade: Migração 1) Quando ocorre a migração de um sistema ou
produto de software é assegurado que qualquer produto de software ou dados produzidos ou modificados durante a migração estejam de acordo com a Norma ISO / IEC 12207.
Sim; Não.
(peso 10) Solução: Deve ser assegurado que durante a migração de um sistema ou produto de software que qualquer produto ou dados produzidos ou modificados estejam de acordo com a norma ISO/IEC 12207.
2) Ocorre o desenvolvimento e execução de um plano de migração?
Sim; Não.
(peso 10) Solução: Deve ser realizados o desenvolvimento e execução de um plano de migração. (Se a resposta da pergunta 2 for “SIM” o sistema faz a pergunta abaixo).
3) Ocorre a documentação do Plano de migração?
117
Sim; Não.
(peso 10) Solução: O plano de migração desenvolvido deve ser documentado. (se a resposta da pergunta 2 for “SIM” o sistema faz a pergunta abaixo).
4) As atividades de planejamento incluem os usuários?
Sim; Não.
(peso 10) Solução: Os usuários devem estar incluídos nas atividades de planejamento do plano de migração. (se a resposta da pergunta 2 for “SIM” o sistema faz a pergunta abaixo).
5) O plano de migração contém: A análise e definição dos requisitos de
migração; O desenvolvimento de ferramentas de
migração; A conversão de produtos de software e
dados; A execução da migração; A verificação da migração; O suporte para o ambiente antigo; Todas as opções; Nenhuma das opções.
(peso 10) Solução: O plano de migração deve descrever a análise e definição dos requisitos de migração. O plano de migração deve descrever o desenvolvimento de ferramentas de migração. O plano de migração deve descrever a conversão de produtos e software e dados. O plano de migração deve descrever a execução da migração. O plano de migração deve descrever a verificação da migração. O plano de migração deve descrever o suporte para o ambiente antigo.
6) Os usuários são notificados dos planos e atividades de migração?
Sim; Não.
(peso 10) Solução: Os usuários devem ser notificados dos planos e atividades da migração. (se a resposta da pergunta 6 for “SIM” o sistema faz a pergunta abaixo).
7) As notificações enviadas para os usuários contem:
Explicação do porquê o ambiente antigo não será mais suportado;
Discriminação do novo ambiente com sua data de disponibilização;
Descrição de outras opções de suporte disponível, se existirem, uma vez que o suporte para o ambiente antigo seja descontinuado;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: As notificações dos planos e atividades da migração enviadas aos usuários devem conter a explicação do porquê o ambiente antigo não será mais suportado. As notificações dos planos e atividades da migração enviadas aos usuários devem conter a discriminação do novo ambiente com sua data de disponibilização. As notificações dos planos e atividades da migração enviadas aos usuários devem conter a descrição de outras opções de suporte disponível, se existirem, uma vez que o suporte para o ambiente antigo seja descontinuado.
8) Operações paralelas do ambiente antigo e novo podem ser conduzidas para a transição gradual ao novo ambiente. Caso esta situação ocorra é provido treinamento necessário aos usuários?
Sim; Não.
(peso 10) Solução: Deve ser dado treinamento para os usuários caso o ambiente antigo e novo venham a trabalharem juntos, constituindo assim uma fase de transição gradual para a operação total do novo ambiente.
9) Quando a migração é iniciada ocorre o envio de notificações a todos os interessados?
Sim; Não.
(peso 10) Solução: Devem ser enviadas notificações a todos os interessados quando ocorre o início da migração.
10) Referente ao ambiente antigo ocorre o arquivamento:
Da documentação; Do histórico (logs); Do código; Todas as opções; Nenhuma das opções.
(peso 2) Solução: A documentação do ambiente antigo deveria ser arquivada. O histórico (logs) do ambiente antigo deveria ser arquivado. O código do ambiente antigo deveria ser arquivado.
118
11) É realizada uma revisão para avaliar o impacto da mudança para o novo ambiente após o término da migração?
Sim; Não.
(peso 10) Solução: Deve ser realizada uma revisão para avaliar o impacto da transição para o novo ambiente após o término da migração. (Se a resposta da pergunta 11 for “SIM” o sistema faz a pergunta abaixo).
12) Os resultados da revisão são enviados as autoridades apropriadas (gerente, supervisor, diretor, de acordo com o caso) para informação, (orientação e providência)?
Sim; Não.
(peso 10) Solução: O resultado da revisão de impacto da transição para o novo ambiente deve ser enviado as autoridades apropriadas (gerente, supervisor, diretor, de acordo com o caso) para informação, orientação e providência.
13) Os dados utilizados ou associados com o ambiente antigo estão acessíveis?
Sim; Não.
(peso 10) Solução: Os dados utilizados ou associados com o ambiente antigo devem estar acessíveis. (se a resposta da pergunta 13 for “SIM” o sistema faz a pergunta abaixo).
14) A acessibilidade esta de acordo com os requisitos do contrato para preservação e auditoria dos dados?
Sim; Não.
(peso 10) Solução: A acessibilidade dos dados utilizados ou associados com o ambiente antigo deve estar de acordo com os requisitos do contrato para preservação e auditoria dos dados.
Processo: MANUTENÇÃO Atividade: Descontinuação do Software 1) Ocorre o desenvolvimento e documentação de
um plano (plano de descontinuação) para remover o suporte ativo das organizações responsáveis pela operação e manutenção?
Sim; Não.
(peso 10) Solução:
Deve ocorrer o desenvolvimento e documentação de um plano para remover o suporte ativo das organizações responsáveis pela operação e manutenção. (se a resposta da pergunta 1 for “SIM” o sistema faz a pergunta abaixo)
2) O plano de descontinuação inclui: Cessação total ou parcial de suporte após
um certo período de tempo; Arquivamento do produto de software e sua
documentação associada; Responsabilidade por quaisquer questões
futuras de suporte residual; Transição para o novo produto de software
se aplicável; Disponibilidade de cópia de arquivos de
dados. Todas as opções; Nenhuma das opções.
(peso 10) Solução: O plano para remover o suporte ativo das organizações responsáveis pela operação e manutenção deve descrever a cessação total ou parcial de suporte após um certo período de tempo. O plano para remover o suporte ativo das organizações responsáveis pela operação e manutenção deve descrever o arquivamento do produto de software e de sua documentação associada. O plano para remover o suporte ativo das organizações responsáveis pela operação e manutenção deve descrever a responsabilidade por quaisquer questões futuras de suporte residual. O plano para remover o suporte ativo das organizações responsáveis pela operação e manutenção deve descrever a transição para o novo produto de software se aplicável. O plano para remover o suporte ativo das organizações responsáveis pela operação e manutenção deve descrever a disponibilidade de cópia de arquivos de dados.
3) Ocorre o envio de notificação referentes aos planos e atividades de descontinuação para o usuário?
Sim; Não.
(peso 10) Solução: Deve ocorrer o envio de notificação referente aos planos e atividades de descontinuação para o usuário. (se a resposta da pergunta 3 for “SIM” o sistema faz a pergunta abaixo).
4) As notificações enviadas contêm: Descrição da substituição ou atualização
com sua data de disponibilidade;
119
Explicação do porquê o produto de software não receberá mais suporte;
Descrição de outras opções de suporte disponíveis, uma vez que o suporte seja descontinuado;
Todas as opções; Nenhuma das opções.
(peso 10) Solução: As notificações referentes aos planos e atividades de descontinuação enviadas para o usuário devem conter a descrição da substituição ou atualização com sua data de disponibilidade. As notificações referentes aos planos e atividades de descontinuação enviadas para o usuário devem conter a explicação do porquê o produto de software não receberá mais suporte. As notificações referentes aos planos e atividades de descontinuação enviadas para o usuário devem conter a descrição de outras opções de suporte disponíveis, uma vez que o suporte seja descontinuado.
5) Operações paralelas do produto de software em descontinuação e do novo produto são conduzidas para transição gradual ao novo sistema?
Sim; Não.
(peso 2) Solução: Operações paralelas do produto de software em descontinuação e do novo produto deveriam ser conduzidas para a transição gradual ao novo sistema. (se a resposta da pergunta 5 for “SIM” o sistema faz a pergunta abaixo).
6) Durante o período de transição é provido treinamento aos usuários?
Sim; Não.
(peso 10) Solução: Durante o período de transição deve ser provido treinamento aos usuários.
7) Quando ocorre a descontinuação do produto são enviadas notificações a todos os interessados?
Sim;
Não. (peso 10) Solução: Devem ser enviadas notificações a todos os interessados quando ocorre a descontinuação do produto de software.
8) Em relação ao produto de software descontinuado ocorre o arquivamento:
De sua documentação; De seu histórico; De seu código; Todas as opções; Nenhuma das opções.
(peso 2) Solução: Deveria ocorrer o arquivamento da documentação do produto de software descontinuado. Deveria ocorrer o arquivamento do histórico do produto de software descontinuado. Deveria ocorrer o arquivamento do código do produto de software descontinuado.
9) Os dados utilizados ou associados com o produto de software descontinuado estão acessíveis?
Sim; Não.
(peso 10) Solução: Os dados utilizados ou associados ao produto de software descontinuado devem estar acessíveis. (se a resposta da pergunta 9 for “SIM” o sistema faz a pergunta abaixo).
10) A acessibilidade esta de acordo com os requisitos do contrato para preservação e auditoria dos dados?
Sim; Não.
(peso 10) Solução: A acessibilidade aos dados utilizados ou associados ao produto de software descontinuado deve estar de acordo com os requisitos do contrato para preservação e auditoria dos dados.
120
![ANEXO VIII Detalhamento da folha de pagamento de pessoal ... · [iii] Auxílio alimentação, Auxílio transporte, Auxílio Pré-escolar ... Janeiro/2013 Nome Lotação Cargo](https://img.pdfslide.tips/doc/110x75/5c0d9f6f09d3f282728ba5c7/anexo-viii-detalhamento-da-folha-de-pagamento-de-pessoal-iii-auxilio.jpg)
