PDF

Universidade de Aveiro
2009
Departamento de Electrnica, Telecomunicaes e
Informtica
Ana Lusa Ferreira Lito

Sistema de gesto da certificao de software
CMMI

Dissertao apresentada Universidade de Aveiro para cumprimento dos
requisitos necessrios obteno do grau de Mestre em Engenharia
Electrnica e Telecomunicaes, realizada sob a orientao cientfica do
Professor Joaquim Arnaldo Martins, Professor Doutor do Departamento de
Electrnica, Telecomunicaes e Informtica da Universidade de Aveiro

Dedico este trabalho minha famlia e aos meus amigos.

o jri

presidente Prof. Doutor Jos Lus Guimares Oliveira
professor associado da Universidade de Aveiro

Prof. Doutor Ademar Manuel Teixeira de Aguiar
professor auxiliar da Faculdade de Engenharia da Universidade do Porto

Prof. Doutor Joaquim Arnaldo Carvalho Martins
professor catedrtico da Universidade de Aveiro

i

agradecimentos

No decorrer deste projecto, foram vrias as pessoas que disponibilizaram a
sua ajuda, to necessria para a sua concretizao. Desta forma, gostaria de
agradecer ao Professor Joaquim Arnaldo Martins e ao Engenheiro Pedro
Almeida pelo apoio e orientao oferecidos durante a realizao do trabalho,
todas as sugestes dadas e pela disponibilidade demonstrada, e aos meus
pais, irm e namorado, pelo seu incondicional apoio e por toda a ajuda que
sempre me deram. Muito obrigada a todos.

palavras-chave

Certificao; CMMI; Gesto de Requisitos; Desenvolvimento de Requisitos;
Soluo Tcnica; Pequenas Empresas.

resumo

O Capability Maturity Model Integration (CMMI) um modelo de optimizao
de processos, desenvolvido pelo Software Engineering Institute de Carnegie
Mellon, que disponibiliza s organizaes os elementos essenciais para gerir
com eficincia projectos de desenvolvimento de software. Uma grande parte
das grandes empresas de desenvolvimento de software a nvel mundial esto
nesta fase a adoptar as medidas necessrias para uma correcta
implementao e monitorizao da certificao CMMI, necessitando para tal
recursos humanos e sistemas informticos que permitam gerir os vrios
requisitos da norma.
Existem vrios estudos a partir dos quais se conclui que pequenas empresas
so capazes de implementar uma melhoria para os seus processos de
software, de forma to eficaz como as grandes empresas. No entanto, para a
maioria destas empresas, o CMMI uma meta bastante desafiadora.
Este trabalho tem como objectivo o estudo aprofundado do modelo CMMI e
das diversas componentes que fazem parte do modelo, e a preparao da
empresa Metatheke para a obteno do nvel de capacidade 2 do modelo
CMMI, nas seguintes reas de processo: Gesto de Requisitos,
Desenvolvimento de Requisitos, e Soluo Tcnica.

keywords

Certification; CMMI; Requirements Management; Requirements Development;
Technical Solution; Small Organisation.

abstract

The Capability Maturity Model Integration (CMMI) is a process optimization
model, developed by Software Engineering Institute of Carnegie Mellon, which
provide to the organisations the essential elements to effectively manage
software projects. A large number of big companies of software development
are now adopting the necessary ways towards a correct implementation and
monitoring of the CMMI certification, requiring human resources and informatic
systems that allow all of the standard requirements.
Enumerous studies evidende that small companies are able to implement a
improvement on its software processes, as effectively as big companies do.
However, CMMI is a big challenge to the most of small companies.
The objective of this work is to study deeply the CMMI model and its various
components, and to prepare the Metatheke company to reach the capacity
level 2 of CMMI model, in the following proces areas: Requirements
Management, Requirements Development, and Technical Solution.

i
ndice
NDICE DE FIGURAS .................................................................................................................................... III
NDICE DE TABELAS ..................................................................................................................................... V
1. INTRODUO ..................................................................................................................................... 1
1.1. CERTIFICAO ...................................................................................................................................... 1
1.2. VANTAGENS DA CERTIFICAO ................................................................................................................ 2
1.3. DESVANTAGENS DA CERTIFICAO ........................................................................................................... 2
1.4. CMMI ............................................................................................................................................... 3
1.4.1. REPRESENTAES DO CMMI .............................................................................................................. 4
1.4.2. NVEIS DO CMMI ............................................................................................................................. 6
1.4.3. REAS DE PROCESSO NO CMMI.......................................................................................................... 9
1.4.4. AVALIAO NO CMMI .................................................................................................................... 11
2. ESTADO DO CMMI ............................................................................................................................ 15
2.1. CMMI EM PORTUGAL ...................................................................................................................... 17
2.2. CMMI NO BRASIL ............................................................................................................................. 18
2.3. CMMI EM OUTROS PASES ................................................................................................................... 19
3. OBJECTIVOS ...................................................................................................................................... 21
4. REA DE PROCESSO GESTO DE REQUISITOS ................................................................................... 25
4.1. REAS DE PROCESSO RELACIONADAS ....................................................................................................... 25
4.2. METAS E PRTICAS DA REA DE PROCESSO GESTO DE REQUISITOS ............................................................... 26
4.2.1. Metas e prticas especficas .................................................................................................. 27
4.2.2. Metas e prticas genricas ................................................................................................... 31
4.3. ALCANAR O NVEL DE CAPACIDADE 2 NA REA DE PROCESSO GESTO DE REQUISITOS ...................................... 33
4.3.1. Implementar as metas especficas ........................................................................................ 34
4.3.2. Implementar as metas genricas .......................................................................................... 41
5. REA DE PROCESSO DESENVOLVIMENTO DE REQUISITOS ................................................................ 51
5.2. METAS E PRTICAS DA REA DE PROCESSO DESENVOLVIMENTO DE REQUISITOS ............................................... 52
5.2.2. Metas e prticas genricas ................................................................................................... 63
5.3. ALCANAR O NVEL DE CAPACIDADE 2 NA REA DE PROCESSO DESENVOLVIMENTO DE REQUISITOS ...................... 66
5.3.1. Implementar as metas especficas ........................................................................................ 66
5.3.2. Implementar as metas genricas .......................................................................................... 77
6. REA DE PROCESSO SOLUO TCNICA ........................................................................................... 87
6.2. METAS E PRTICAS DA REA DE PROCESSO SOLUO TCNICA ...................................................................... 88
6.2.2. Metas e prticas genricas ................................................................................................. 103
6.3. ALCANAR O NVEL DE CAPACIDADE 2 NA REA DE PROCESSO SOLUO TCNICA .......................................... 106
6.3.1. Implementar as metas especficas ...................................................................................... 106
ii

6.3.2. Implementar as metas genricas ........................................................................................ 121
7. CONCLUSES .................................................................................................................................. 131
REFERNCIAS .......................................................................................................................................... 133
ANEXO A TEMPLATE DA ACTA DE REUNIES ........................................................................................ 137
ANEXO B TEMPLATE DO DOCUMENTO DE REQUISITOS ........................................................................ 141
ANEXO C EXEMPLO 1 DO DOCUMENTO DE REQUISITOS ...................................................................... 145
ANEXO D TEMPLATE DO DOCUMENTO DE ALTERAES ...................................................................... 149
ANEXO E EXEMPLO DO DOCUMENTO DE ALTERAES ........................................................................ 153
ANEXO F EXEMPLO 2 DO DOCUMENTO DE REQUISITOS....................................................................... 157
ANEXO G TEMPLATE DO DOCUMENTO DE INCONSISTNCIAS .............................................................. 161
ANEXO H EXEMPLO DO DOCUMENTO DE INCONSISTNCIAS ............................................................... 165
ANEXO I TEMPLATE DA POLTICA DE GESTO DE REQUISITOS ............................................................. 169
ANEXO J TEMPLATE DA POLTICA DE DESENVOLVIMENTO DE REQUISITOS .......................................... 173
ANEXO K TEMPLATE DA POLTICA DE SOLUO TCNICA .................................................................... 179

iii
ndice de Figuras

FIGURA 1 PASES ONDE FORAM REALIZADAS AVALIAES E REPORTADAS AO SEI [17] ..................................................... 16
FIGURA 2 FLUXOGRAMA DE IMPLEMENTAO DA META ESPECFICA 1 DA REA DE PROCESSO GESTO DE REQUISITOS ........... 40
FIGURA 3 PLANO DE GESTO DE REQUISITOS [39] ................................................................................................... 42
FIGURA 4 SECO DO ORGANIGRAMA CORRESPONDENTE GESTO DE REQUISITOS ....................................................... 44
FIGURA 5 FLUXOGRAMA DE IMPLEMENTAO DA META ESPECFICA 1 DA REA DE PROCESSO DESENVOLVIMENTO DE REQUISITOS
................................................................................................................................................................ 68
FIGURA 6 FLUXOGRAMA DE IMPLEMENTAO DA META ESPECFICA 2 DA REA DE PROCESSO DESENVOLVIMENTO DE REQUISITOS
................................................................................................................................................................ 71
FIGURA 7 DOCUMENTO DE CONCEITOS DE OPERAES ............................................................................................. 72
FIGURA 8 RELATRIOS DE DEFEITOS ...................................................................................................................... 73
FIGURA 9 - RELATRIOS DE RISCOS .......................................................................................................................... 74
FIGURA 10 FLUXOGRAMA DE IMPLEMENTAO DA META ESPECFICA 3 DA REA DE PROCESSO DESENVOLVIMENTO DE
REQUISITOS ................................................................................................................................................ 76
FIGURA 11 PLANO DE DESENVOLVIMENTO DE REQUISITOS [39] ................................................................................. 78
FIGURA 12 SECO DO ORGANIGRAMA CORRESPONDENTE AO DESENVOLVIMENTO DE REQUISITOS ................................... 80
FIGURA 13 DOCUMENTO DE SOLUO TCNICA ..................................................................................................... 107
FIGURA 14 RELATRIO DE AVALIAO DE TECNOLOGIAS .......................................................................................... 108
FIGURA 15 RELATRIO DE AVALIAO DE PRODUTOS COTS..................................................................................... 109
FIGURA 16 FLUXOGRAMA DE IMPLEMENTAO DA META ESPECFICA 1 DA REA DE PROCESSO SOLUO TCNICA ............. 110
FIGURA 17 DOCUMENTO DE ARQUITECTURA ......................................................................................................... 111
FIGURA 18 DOCUMENTO DE DESENHO ................................................................................................................. 112
FIGURA 19 DOCUMENTO DE INTERFACE ............................................................................................................... 113
FIGURA 20 DOCUMENTO DE ANLISE DE CONSTRUO, COMPRA OU REUTILIZAO ..................................................... 114
FIGURA 22 DOCUMENTO DE RECOMENDAES PARA A IMPLEMENTAO ................................................................... 116
FIGURA 23 MANUAL DE UTILIZAO ................................................................................................................... 117
FIGURA 24 MANUAL DE INSTALAO .................................................................................................................. 118
FIGURA 25 MANUAL DE OPERAO .................................................................................................................... 118
FIGURA 26 MANUAL DE MANUTENO ................................................................................................................ 119
FIGURA 27 - DOCUMENTO DE RECOMENDAES PARA O DESENVOLVIMENTO DA DOCUMENTAO .................................... 119
FIGURA 29 PLANO DA SOLUO TCNICA [39] ..................................................................................................... 122
FIGURA 30 SECO DO ORGANIGRAMA CORRESPONDENTE SOLUO TCNICA .......................................................... 125

v
ndice de Tabelas

TABELA 1 NVEIS DE CAPACIDADE E DE MATURIDADE ................................................................................................. 8
TABELA 2 REAS DE PROCESSO E SEUS RESPECTIVOS NVEIS E DISCIPLINAS ..................................................................... 11
TABELA 3 NMERO DE AVALIAES REPORTADAS AO SEI POR ANO ............................................................................. 15
TABELA 4 - NMERO DE AVALIAES REPORTADAS AO SEI POR CONTINENTE ................................................................... 16
TABELA 5 PERFIL DE MATURIDADE DOS PROCESSOS DAS ORGANIZAES AVALIADAS ....................................................... 17
TABELA 6 METAS E PRTICAS NECESSRIAS PARA ATINGIR O NVEL DE CAPACIDADE 2 NA REA DE PROCESSO GESTO DE
REQUISITOS ................................................................................................................................................ 27
TABELA 7 LISTA DE CRITRIOS PARA DISTINO DE FONTES ADEQUADAS ........................................................................ 34
TABELA 8 LISTA DE CRITRIOS PARA AVALIAO E ACEITAO DE REQUISITOS ................................................................. 35
TABELA 9 MATRIZ DE RASTREABILIDADE DE REQUISITOS ............................................................................................ 38
TABELA 10 TABELA DE ATRIBUIO DE RESPONSABILIDADES PARA A GESTO DE REQUISITOS ............................................ 44
TABELA 11 TABELA DE IDENTIFICAO DAS PARTES RELEVANTES NO PROCESSO DE GESTO DE REQUISITOS .......................... 47
TABELA 12 METAS E PRTICAS NECESSRIAS PARA ATINGIR O NVEL DE CAPACIDADE 2 NA REA DE PROCESSO
DESENVOLVIMENTO DE REQUISITOS ................................................................................................................. 53
TABELA 13 COLUNAS DA MATRIZ DE RASTREABILIDADE REFERENTES ALOCAO DOS REQUISITOS .................................... 69
TABELA 14 TABELA DE ATRIBUIO DE RESPONSABILIDADES PARA O DESENVOLVIMENTO DE REQUISITOS ............................ 80
TABELA 15 TABELA DE IDENTIFICAO DAS PARTES RELEVANTES NO PROCESSO DE DESENVOLVIMENTO DE REQUISITOS .......... 83
TABELA 16 METAS E PRTICAS NECESSRIAS PARA ATINGIR O NVEL DE CAPACIDADE 2 NA REA DE PROCESSO SOLUO TCNICA
................................................................................................................................................................ 89
TABELA 17 TABELA DE ATRIBUIO DE RESPONSABILIDADES PARA A SOLUO TCNICA ................................................. 124
TABELA 18 TABELA DE IDENTIFICAO DAS PARTES RELEVANTES NO PROCESSO DE SOLUO TCNICA ............................... 128

1
1. Introduo

1.1. Certificao
Para que uma organizao possa fornecer aos seus clientes servios ou produtos que
satisfaam as suas necessidades tem de criar e gerir um sistema da qualidade. As decises
e a aco da organizao devem estar orientadas para objectivos determinados,
decorrentes da poltica da qualidade e da permanente melhoria do seu desempenho.
A certificao consiste em demonstrar a conformidade das caractersticas de um produto,
servio ou sistema face a um documento de referncia preciso que estabelea e
quantifique os parmetros que devem ser verificados. Certificar uma empresa deve
significar o seu limiar mnimo de bom funcionamento e o ponto de partida para atingir a
qualidade [1].
A certificao de uma organizao, qualquer que seja a sua dimenso ou sector de
actividade, obriga em geral ao cumprimento de requisitos de uma norma. As normas dos
sistemas de gesto da qualidade, permitem uma abordagem sistemtica e preventiva de
todas as actividades que possam afectar a qualidade, desde a concepo do servio at
sua prestao ao cliente final, ajudando a organizao a disciplinar os seus processos e
metodologias de trabalho nas reas-chave, a reduzir falhas internas e a antever os
problemas que possam surgir na prestao do servio ou da utilizao de um produto.
No processo de certificao de empresa, emitido um certificado que confirma que um
determinado produto, processo ou servio est em conformidade com os requisitos da
norma. Depois de obter o certificado, o processo de certificao no fica concludo. O
certificado tem geralmente uma validade de poucos anos. A certificao exige assim um
trabalho contnuo onde periodicamente sero efectuadas revises ao sistema, atravs da
realizao de auditorias internas de acompanhamento. Antes de terminar a validade,
indicada no certificado, a empresa ter de recorrer a uma auditoria de renovao [2].
O cumprimento dos requisitos verificado por uma entidade externa e independente
organizao, designado por organismo de certificao ou entidade certificadora, que est
devidamente acreditado para esse efeito. O Instituto Portugus da Qualidade (IPQ) [3]
a entidade nacional responsvel pela acreditao das entidades. Esta entidade assegura a
representao nacional em inmeras estruturas europeias e internacionais relevantes
para a sua misso, como por exemplo, no European Committee for Standardization (CEN)
[4] e na International Organization for Standardization (ISO) [5].

2
1.2. Vantagens da Certificao
Para qualquer organizao, a certificao um factor de credibilidade e apresenta claras
vantagens, que sero apresentadas de seguida.
A certificao deve ser vista pelas empresas como uma oportunidade de melhoria no s
a nvel externo, como tambm a nvel interno.
Internamente, verifica-se uma melhoria do funcionamento da organizao, a diversos
nveis:
Ajuda a reduzir os custos diminuindo desperdcios, rejeies e reclamaes;
Melhora a sistematizao interna e aumenta a disciplina de processos;
Aumenta transparncia nas decises;
Reduz variaes na prestao de servios;
Aumenta a eficcia nas operaes uma vez que so seguidos procedimentos mais
eficazes e documentao de referncia comum;
Determina a definio clara de responsabilidades;
Cria uma nova cultura com a sensibilizao e motivao dos colaboradores,
orientada para a melhoria contnua e para a satisfao dos clientes, melhorando
os objectivos da organizao;
Ajuda na preveno e minimizao de aspectos, perigos e acidentes.
Tudo isto se traduz num significativo aumento da qualidade.

A nvel externo, e num mercado cada vez mais competitivo, a certificao apresenta-se
como um critrio determinante na deciso de compra do cliente:
Confere uma boa imagem da empresa com o intuito de atrair a confiana dos seus
clientes actuais ou potenciais;
Traduz-se num factor de credibilizao da empresa, mesmo a nvel internacional;
D acesso a novos mercados e concursos;
Permite comunicar ao mercado o compromisso da empresa para com a qualidade
e demonstrar que o servio efectuado por profissionais responsveis, eficientes
e munidos das condies tcnicas necessrias em matria de instalaes e
organizao;
Permite uma diferenciao baseada na qualidade, com compromissos concretos
relativamente s caractersticas do servio.

1.3. Desvantagens da Certificao
O processo de certificao, no entanto, pode trazer tambm algumas desvantagens:
3
Pode provocar uma excessiva burocratizao por exagero de detalhe;
Pode criar um sistema desnecessariamente rgido, quando no se introduz no
prprio sistema a flexibilidade que um servio exige;
Os colaboradores podem executar apenas os procedimentos, e em muitos casos
os mesmos no descrevem todos os detalhes possveis;
Este processo no imediato, podendo mesmo demorar alguns anos;
A certificao tem custos elevados, sendo por isso mais acessvel s empresas com
um maior poder financeiro.
Contudo, as vantagens da certificao sobrepem-se s suas desvantagens.

1.4. CMMI
A presso sentida pelas empresas para competir e inovar tem promovido uma relao
crescente entre os objectivos de negcio e a necessidade de possuir aplicaes que as
ajudem a colocar os seus produtos ou servios no mercado. No entanto, a qualidade do
processo de desenvolvimento de software fica muitas vezes remetida para segundo
plano.
Nos ltimos anos, tem vindo a aumentar o interesse e o desenvolvimento de modelos de
qualidade na rea das Tecnologias de Informao. A indstria de software est a passar
por um processo de amadurecimento, no qual as metodologias de desenvolvimento de
software existentes tm vindo a evoluir e a permitir uma melhor gesto da qualidade do
software. A partir desta nova situao, a qualidade do software comeou a receber uma
maior ateno do mercado [6].
Surgiram vrios modelos com o objectivo comum de melhorar os processos da
organizao e aumentar a qualidade dos produtos e servios. No mbito dos Modelos de
Qualidade direccionados para Sistemas e Software, surgiu o Capability Maturity Model
Integration (CMMI) [7]. O modelo CMMI resultou de um projecto iniciado em 1997 pelo
Software Engineering Institute (SEI) [8] e foi lanado em 2000. uma evoluo do
Capability Maturity Model for Software (CMM) [9], um modelo usado por diversas
organizaes para identificar boas prticas e ajud-las a melhorar a produtividade dos
seus processos. Em 2000, o CMM foi evoludo para o CMMI, com o objectivo de se
procurar estabelecer um modelo nico para o processo de melhoria corporativo,
integrando diferentes modelos e disciplinas. O CMMI um modelo integrado que
potencia e optimiza os processos de desenvolvimento e integrao de produtos. Mede a
maturidade e a capacidade dos processos das organizaes e orienta-as no
desenvolvimento de processos de software. composto por um conjunto de boas
4
prticas que abordam actividades de desenvolvimento e manuteno que cobrem o ciclo
de vida do produto desde a concepo at entrega e manuteno.
O modelo CMMI tem comprovado os seus benefcios em centenas de empresas e em
milhares de projectos [10], e reconhecido globalmente como uma medida de
performance para o desenvolvimento de software e para as empresas de engenharia em
todo o mundo, especialmente nos mercados americano e asitico. O reconhecimento
CMMI uma forma da empresa reflectir o seu empenho na estratgia de melhoria
contnua, de modo a propor ao mercado servios e solues cada vez melhor. Para os
clientes, este esforo traduz-se em maiores garantias de cumprimento dos oramentos e
dos prazos acordados, alm do fornecimento de produtos e servios com garantias de
qualidade reconhecidas internacionalmente.
O CMMI mapeado ao ISO 9001:2000 [11], uma norma internacional bastante popular
que especifica um sistema de qualidade para o desenvolvimento e manuteno de
software. A principal diferena entre os dois que o ISO 9001 especifica um nvel de
qualidade mnimo aceitvel para os processos de software, enquanto que o CMMI
estabelece uma estrutura para medio da melhoria contnua dos processos e mais
explcita na definio dos meios para esse fim. Para cada requisito da norma ISO 9001,
uma organizao pode optar por ter dois estados: satisfeito ou no satisfeito. Se
todos os requisitos esto satisfeitos, alcanada a certificao ISO [12].
Nos ltimos tempos, por todo o mundo, tem-se verificado um interesse crescente no
CMMI. Em Portugal, existem ainda poucas empresas com esta certificao. So exemplo
as empresas Novabase, Critical Software e Sinfic. No nosso pas o CMMI no
fundamental para as empresas de tecnologia, no entanto importante para qualquer
empresa obter esta certificao, pois alm da publicidade com a certificao (semelhante
ao ISO 9001), o processo prepara a empresa para novos desafios.

1.4.1. Representaes do CMMI
O CMMI possui duas representaes que permitem organizao utilizar diferentes
caminhos para a melhoria, de acordo com seu interesse:
Representao Contnua;
Representao por Estgios.

Existem vrias razes para a escolha de cada uma das representaes, e cada uma
apresenta as suas vantagens.
5
Representao contnua
A representao contnua oferece maior flexibilidade para a melhoria dos processos, na
medida em que permite organizao escolher o foco dos seus esforos no processo de
melhoria, escolhendo as reas de processo, ou conjunto de reas de processo
relacionadas, que mais beneficiam os objectivos de negcio da organizao. A
organizao pode utilizar a ordem de melhoria que melhor atender os objectivos de
negcio da empresa e pode melhorar processos diferentes em ritmos diferentes. Apesar
de existirem alguns limites na escolha, devido s dependncias entre as reas de
processo, a organizao tem uma considervel liberdade na sua seleco. Se a
organizao conhece os processos que precisam de ser melhorados e percebe as
dependncias entre as reas de processo descritas no CMMI, a representao contnua
uma boa escolha para a organizao [13].

Representao por estgios
A representao por estgios oferece um caminho sistemtico e estruturado para
alcanar a melhoria dos processos, etapa a etapa, determinado ao longo de mais de uma
dcada de pesquisa. Esta representao prescreve uma ordem para a implementao das
reas de processo de acordo com os nveis de maturidade, que definem o caminho para a
melhoria para uma organizao. a mais adequada para uma organizao que no sabe
por onde comear e qual o processo que deve escolher para melhorar [13].

Quando uma organizao escolhe uma representao, existem trs tipos de factores que
podem influenciar a sua deciso [13]:
Factores de negcio: uma organizao com um conhecimento avanado dos seus
prprios objectivos de negcio tem provavelmente um forte mapeamento dos
seus processos aos seus objectivos de negcio. Uma organizao assim pode
considerar a representao contnua til para avaliar os seus processos e para
determinar se os processos da organizao vo ao encontro dos seus objectivos de
negcio.
Se uma organizao focada na linha de produto decide melhorar os processos de
toda a organizao deveria optar pela representao por estgios. Esta
representao ajuda a organizao a seleccionar os processos crticos que devem
ser focados para melhoria.
A mesma organizao poder optar por melhorar os processos por linha de
produto. Neste caso dever escolher a representao contnua, e pode ser
6
alcanado um diferente ritmo da avaliao de capacidade para cada linha de
produto.
Factores culturais: os factores culturais que devem ser considerados na escolha de
uma representao tm a ver com a capacidade da organizao de implementar
um programa de melhoria de processos. Por exemplo, uma organizao pode
escolher a representao contnua se a cultura da empresa for baseada em
processos e tiver experincia em melhoria de processos, ou tenha um processo
especfico que necessite de ser rapidamente melhorado.
Uma organizao que tenha pouca experincia na melhoria de processos pode
escolher a representao por estgios, a qual fornece uma orientao adicional na
ordem pela qual devero surgir as melhoras.
Experincia: Se uma organizao tiver experincia com outro modelo que possua
uma representao por estgios, dever continuar com a representao por
estgios do CMMI. O mesmo acontece com a representao contnua.
As duas representaes fornecem um modo de implementar melhorias nos processos, de
forma a alcanar os objectivos de negcio. Ambas fornecem o mesmo contedo essencial
e utilizam os mesmos componentes do modelo e esto desenhadas para oferecer
resultados equivalentes.

1.4.2. Nveis do CMMI
Os nveis so usados no CMMI para descrever um caminho de evoluo recomendado
para uma organizao que pretenda melhorar os processos que utiliza para o
desenvolvimento e manuteno dos seus produtos e servios. O CMMI suporta dois
caminhos de melhoria. Um caminho permite que as organizaes, de forma incremental,
melhorem os processos que correspondem a uma rea de processo individual (ou reas
de processo) seleccionada pela organizao. O outro caminho permite que as
organizaes melhorem um conjunto de processos relacionados, abordando
incrementalmente conjuntos sucessivos de reas de processo. Estes dois tipos de
caminho esto associados a dois tipos de nveis que correspondem s duas
representaes [13]. Para a representao contnua usa-se o termo nvel de
capacidade, enquanto que para a representao por estgios usa-se o termo nvel de
maturidade.
Independentemente da representao escolhida, o conceito de nvel o mesmo. Os
nveis caracterizam as melhorias de um estado mal definido para um estado que utiliza
informao quantitativa para determinar e gerir melhorias para o cumprimento dos
objectivos de negcio de uma organizao. Para atingir um determinado nvel, uma
7
organizao deve satisfazer todas as metas da rea de processo, ou conjunto de reas de
processo, que so alvo de melhoria, independentemente de ser um nvel de capacidade
ou de maturidade. Tanto os nveis de capacidade como os nveis de maturidade fornecem
um modo de medir como as organizaes melhoram os seus processos. No entanto, a
abordagem para a melhoria dos processos diferente.

Nveis de Capacidade
Os nveis de capacidade aplicam-se conquista de melhorias na organizao de processos
em reas de processo individuais. Estes nveis so um meio de incrementalmente
melhorar os processos correspondentes a uma dada rea de processo. Existem 6 nveis de
capacidade, numerados de 0 a 5, correspondendo cada um a um objectivo genrico. Um
nvel de capacidade consiste numa meta genrica e nas suas prticas relacionadas, no que
se refere a uma rea de processo. Quando uma organizao satisfaz os objectivos e as
suas prticas em cada nvel de capacidade a organizao ir colher os benefcios da
melhoria dos processos para essa rea de negcio.
A representao contnua caracterizada pelos seguintes nveis de capacidade:
Nvel 0 Incompleto;
Nvel 1 Executado;
Nvel 2 Gerido;
Nvel 3 Definido;
Nvel 4 Gerido quantitativamente;
Nvel 5 Optimizado;

Nveis de Maturidade
Os nveis de maturidade aplicam-se conquista de melhorias na organizao em vrias
reas de processo. Estes nveis so um meio de prever os resultados gerais dos prximos
projectos. Um nvel de maturidade consiste em prticas especficas e genricas
relacionadas para um conjunto pr-definido de reas de processo que melhoram o
desempenho global da organizao.
O CMMI disponibiliza uma sequncia pr-determinada para melhoria baseada em nveis
que no deve ser desconsiderada, pois cada nvel serve de base para o seguinte. Cada
nvel caracterizado por um conjunto de factores que resultam de alteraes no processo
relativamente ao nvel anterior. Existem 5 nveis de maturidade, numerados de 1 a 5:
Nvel 1 Inicial;
8
Nvel 2 Gerido;
Nvel 3 Definido;
Nvel 4 Gerido Quantitativamente;
Nvel 5 Optimizado.
Se uma empresa se encontra num determinado nvel de maturidade significa que
implementa todas as reas de processo do nvel respectivo. Por defeito, todas as
organizaes esto no nvel de maturidade 1. Para alcanar o nvel 2, a organizao deve
satisfazer as metas das reas de processo definidas no nvel 2. Para alcanar o nvel 3,
uma organizao dever executar todas as reas de processo do nvel 2 e as reas de
processo definidas no nvel. Da mesma forma, os nveis de maturidade 4 e 5 exigem a
implementao de novas reas de processo tal como das reas dos nveis inferiores [14].
NaTabela 1 esto apresentados os nveis de capacidade e os nveis de maturidade.

Tabela 1 Nveis de Capacidade e de Maturidade
Nvel Nvel Capacidade Nvel Maturidade
0 Incompleto -
1 Executado Inicial
2 Gerido Gerido
3 Definido Definido
4 Gerido Quantitativamente Gerido Quantitativamente
5 Optimizado Optimizado

No existe o nvel de maturidade 0. No nvel 1, o nvel de capacidade Executado
enquanto que o nvel de maturidade Inicial, ou seja, o ponto de partida diferente
para as duas representaes. Os restantes nveis tm o mesmo nome. A representao
contnua est preocupada em seleccionar uma rea de processo particular para melhorar
o nvel de capacidade para essa rea de processo. Neste contexto, se um processo est
Executado ou Incompleto considerado importante. Assim, o nome Incompleto
dado ao ponto de partida da representao contnua. Como a representao por estgios
est preocupada com a maturidade global da organizao, se os processos individuais
esto realizados ou incompletos no o foco principal. Assim, o nome Inicial dado ao
ponto de partida da representao por estgios [13].

9
1.4.3. reas de Processo no CMMI
O CMMI baseia-se no conceito de rea de processo. Uma rea de processo consiste num
grupo de prticas relacionadas. Existem 22 reas de processo que so consideradas
importantes para a melhoria dos processos de uma organizao [10].
As reas de processo so vistas de forma distinta nas duas representaes.

reas de Processo na Representao Contnua
Na representao contnua, cada rea de processo considerada isoladamente, no
estando alocadas a nenhum nvel em particular. Assim, cada rea de processo recebe a
sua prpria classificao, podendo ir do nvel zero ao nvel cinco do modelo [6].
Para apoiar as organizaes que utilizem a representao contnua, as reas de processo
so organizadas nas 4 categorias seguintes:
Gesto de processos: Contm as actividades do projecto relacionadas com a
definio, o planeamento, a implementao, o acompanhamento, o controlo, a
instruo, a medio, e a melhoria dos processos;
Gesto de projectos: Cobre as actividades de gesto do projecto, relacionadas
com o planeamento, o acompanhamento e o controlo do projecto;
Engenharia: Cobre as actividades de desenvolvimento e manuteno que so
partilhadas pelas disciplinas de engenharia;
Suporte: Cobre as actividades que apoiam o desenvolvimento e a manuteno do
produto.

Depois de a organizao seleccionar as reas de processo, deve escolher quanto gostaria
de amadurecer os processos associados aquelas reas de processo. Uma organizao
pode por exemplo querer esforar-se para alcanar o nvel de capacidade 2 numa rea de
processo e o nvel de capacidade 4 noutra. Quando a organizao alcanar um nvel de
capacidade pode comear a pensar no prximo nvel para uma dessas mesmas reas de
processo ou decidir abordar um maior nmero de reas.
Associado a cada rea de processo est um conjunto de metas que tm de ser satisfeitas
como uma medida para a melhoria nessa rea de processo. As metas so classificadas
como metas genricas e metas especficas. Uma meta genrica descreve as caractersticas
que devem estar presentes para institucionalizar os processos que implementam uma
rea de processo. Uma meta especfica descreve as caractersticas nicas que devem
estar presentes para satisfazer a rea de processo. As prticas so componentes
10
esperadas para satisfazer objectivos e so classificadas como genricas ou especficas.
Uma prtica genrica a descrio de uma actividade que considerada importante para
alcanar a meta genrica associada. Uma prtica especfica a descrio de uma
actividade que considerada importante para alcanar a meta especfica associada [15].

reas de Processo na Representao por Estgios
Na representao por estgios, as reas de processo esto agrupadas em nveis de
maturidade. Cada nvel possui diversas reas de processo e uma rea de processo pode
encontrar-se num nico nvel.
Por exemplo, no nvel de maturidade 2, existe um conjunto de reas de processo que a
organizao iria usar para orientar as suas melhorias nos processos. Assim que o nvel de
maturidade 2 for atingido, a organizao concentra os seus esforos nas reas de
processo do nvel de maturidade 3 e assim por diante.

A Tabela 2 apresenta as 22 reas de processo e seus respectivos nveis e disciplinas.

11
Tabela 2 reas de Processo e seus respectivos nveis e disciplinas

Engenharia Apoio Gesto de Projectos
Gesto de
Processos
Nvel 2
- Gesto de
Requisitos

- Garantia da
qualidade do
processo e do
produto
- Gesto de
Configurao
- Medio e anlise
- Planeamento do
projecto
- Monitorizao e
controlo do
projecto
- Gesto de acordos
com fornecedores

Nvel 3
- Desenvolvimento
de Requisitos
- Soluo Tcnica
- Integrao do
produto
- Verificao
- Validao
- Anlise de deciso
e resoluo

- Gesto integrada
do projecto
- Gesto de riscos

- Foco no processo
organizacional
- Definio do
processo
organizacional
- Formao
organizacional
Nvel 4
- Gesto
quantitativa do
projecto
- Desempenho do
processo
organizacional
Nvel 5
- Anlise causal e
resoluo
- Inovao e
implementao
organizacional

1.4.4. Avaliao no CMMI
O Standard CMMI Appraisal Method for Process Improvement (SCAMPI) [16] o mtodo
de avaliao padro do CMMI para a melhoria de processos.
As avaliaes SCAMPI ajudam as organizaes a identificar os pontos fortes e pontos
fracos dos seus processos, a revelar os riscos de desenvolvimento e a definir prioridades
para planos de melhoria. Como resultado da avaliao obtido o nvel de maturidade ou
capacidade da organizao.
A avaliao segundo o SCAMPI consiste de trs fases:
Planeamento e Preparao;
Avaliao no local de trabalho;
Apresentao dos resultados obtidos.

12
Fase de Planeamento e Preparao
Na fase de Planeamento e Preparao devem ser realizadas as seguintes actividades:
Anlise de Requisitos, para entender as necessidades do negcio para as quais a
avaliao est a ser executada;
Desenvolvimento do plano da avaliao, onde ficam registados os requisitos do
plano de avaliao, acordos, estimativas, riscos, mtodos de adaptao e
consideraes prticas associadas avaliao;
Seleco e preparao da equipa de avaliao, que dever ser uma equipa
treinada, experiente e apropriadamente qualificada para conduzir o processo de
avaliao;
Obteno e anlise das evidncias iniciais, onde se obtm informaes que
identifiquem reas potencialmente problemticas ou falhas na implementao
das prticas;
Preparao para a obteno de evidncias, ou seja, planear e documentar a
coleco de dados incluindo as fontes de dados, ferramentas e tcnicas a serem
usadas e contingncias para gerir o risco da falta de dados.

Fase de Avaliao
Na fase de avaliao no local devem ser realizadas as seguintes actividades:
Preparao dos participantes de modo a assegurar que estes entendem o
objectivo da avaliao e que esto preparados para participar;
Anlise das evidncias, para adquirir informao acerca das prticas
implementadas na empresa e relatar os dados resultantes para o modelo de
referncia da avaliao; efectuar actividades de acordo com o plano de obteno
de dados; realizar aces correctivas e reviso ao plano de obteno de dados se
for necessrio;
Documentao das evidncias, identificando e consolidando os dados e
transformando-os em registos que documentem a implementao das prticas,
assim como suas foras e fraquezas;
Verificao das evidncias, isto , verificao da implementao das prticas na
empresa para cada ponto do plano; cada implementao de cada prtica
verificada de maneira a que possa ser comparada ao modelo das prticas da
avaliao;
Validao das evidncias, descrevendo as falhas na implementao das prticas;
os pontos fracos encontrados so validados com os membros da empresa; os
pontos fortes podem ser realados e so includos tambm nos resultados da
avaliao;
13
Gesto dos resultados da avaliao; mede-se a satisfao dos objectivos baseado
na extenso da implementao da prtica atravs da unidade organizacional; a
extenso da implementao da prtica determinada baseada nos dados
validados, coleccionados de toda a amostra das unidades organizacionais; a
medida do nvel de capacidade ou nvel de maturidade guiada algoritmicamente
pela medida de satisfao do objectivo.

Fase de Apresentao dos Resultados
A ltima fase a apresentao dos resultados. Nesta fase devem ser realizadas as
seguintes actividades:
Apresentao dos resultados da avaliao Disponibilizar resultados da avaliao
que podem ser usados para guiar aces de melhoria. As foras e as fraquezas dos
processos em uso tambm so apresentadas. Alm disso, determina se planeado,
qual o nvel de capacidade ou o nvel de maturidade dos processos em uso;
Empacotamento e arquivo dos resultados da avaliao Guardar registos e dados
importantes da avaliao e disponibilizar o material seleccionado de maneira
apropriada.
15
2. Estado do CMMI

Nos dias de hoje, a indstria de software representa uma importante actividade
econmica para quase todos os pases. A garantia da qualidade do software, atravs da
melhoria de processos e da certificao, cada vez mais uma estratgia das empresas
nesta rea.
O CMMI assegura que a metodologia utilizada pelas organizaes est ao nvel do melhor
que se faz no mundo do ponto de vista do processo produtivo. O CMMI tem sido
adoptado com xito em empresas de diversos pases, e tornou-se um standard de
prestgio reconhecido, associado qualidade do software. Actualmente conta com mais
de mil empresas certificadas a nvel mundial.
O CMMI fundamental para as empresas de Tecnologias de Informao quando estas
tm grandes projectos a nvel internacional ou ligados defesa e ao governo. Existem
diversas instituies internacionais que exigem, pelo menos, o nvel 3. So os casos do
governo americano, da banca e seguros no Brasil e do sector da defesa, segurana,
aeronutica e espao no geral. Na Europa, diversas empresas exigem tambm esta
certificao. Na ndia, as principais empresas produtoras de software possuem esta
certificao. Em Portugal, no entanto, a certificao CMMI no muito reconhecida e
ainda existem poucas empresas com esta certificao.
Segundo os dados avanados pelo SEI em Maro de 2008 [17], foram reportadas ao SEI
3113 avaliaes SCAMPI usando o CMMI. O nmero de organizaes que procura a
certificao CMMI tem vindo a aumentar ano aps ano, desde a sua criao. Na Tabela 3
observa-se o crescimento do nmero de certificaes ao longo dos anos.

Tabela 3 Nmero de avaliaes reportadas ao SEI por ano
Ano Nmero de Avaliaes
2002 52
2003 186
2004 437
2005 598
2006 834
2007 1006

16
O CMMI actualmente implementado em 61 pases, entre os quais se encontram os
Estados Unidos da Amrica, a Argentina, a Blgica, o Brasil, o Canad, a Finlndia, a
Alemanha, a ndia e a Sua. Os ltimos a juntarem-se a esta lista foram o Bangladesh, a
Hungria, a Noruega e a Arbia Saudita. Na Figura 1 esto sinalizados a vermelho os pases
onde foram realizadas avaliaes e reportadas ao SEI.

Figura 1 Pases onde foram realizadas avaliaes e reportadas ao SEI [17]

Os pases com maior nmero de avaliaes reportadas ao SEI so a China (465), ndia
(323), Japo (220), EUA (1034), Frana (112) e Repblica da Coreia (107).
Fora dos EUA, a China, ndia, Espanha, Argentina, Brasil e Malsia so os pases em que o
nmero de avaliaes reportadas cresce mais rapidamente.
Na Tabela 4 encontra-se a distribuio destas organizaes por continente.

Tabela 4 - Nmero de avaliaes reportadas ao SEI por continente
Continente Nmero de Avaliaes
frica 38
sia 1354
Europa 403
Amrica do Norte 1080
Amrica do Sul 208
Ocenia 30
17
As organizaes ligadas ao comrcio so as que mais procuram o CMMI, representando
72.0% do total de avaliaes, as organizaes que prestam servios para o Exrcito ou
para o Governo representam 23% e as Agncias Militares ou do Governo 5.1% (dados
baseados nas 2652 organizaes que reportaram a sua categoria).
Segundo os dados do SEI, a maior parte das organizaes reportadas tem os seus
processos nos nveis de maturidade Gerido ou Definido. A Tabela 5 mostra como esto
distribudos os processos das organizaes pelos nveis de maturidade do CMMI.

Tabela 5 Perfil de Maturidade dos processos das organizaes avaliadas
Perfil de Maturidade Nmero de Organizaes
No definido 8.0 %
Inicial 1.5 %
Gerido 32.9 %
Definido 41.9 %
Gerido Quantitativamente 3.3 %
Em optimizao 12.3 %

Os dados da Tabela 5, so baseados na mais recente avaliao de 2674 organizaes.

2.1. CMMI em PORTUGAL
Neste momento existem cerca de 10 empresas de referncia em Portugal certificadas em
CMMI. De seguida referem-se alguns exemplos.
O Grupo Sopra introduziu no mercado portugus o CMMI [18].
A Sinfic foi a segunda empresa a obter este reconhecimento em Portugal. Esta empresa
internacional privada, que actua na rea dos sistemas e tecnologias de informao,
procurou aumentar a fasquia da qualidade e obteve o processo de reconhecimento CMMI
nvel 2 em Outubro de 2005 [19].
A Novabase outra das empresas nacionais que recebeu a certificao CMMI, de Nvel 3,
passando assim a figurar no restrito e criterioso lote de empresas CMMI certificadas pelo
SEI. A implementao do CMMI na Novabase teve como foco principal a melhoria do
processo produtivo, quer ao nvel da produtividade quer ao nvel da qualidade dos
produtos [20].
18
A Critical Software foi das primeiras e poucas empresas a investir claramente na
certificao CMMI. Esta empresa possui actualmente o nvel 3, mas espera atingir o nvel
5 no final do ano.
A Esprito Santo Informtica obteve a certificao CMMI nvel 2, sendo a primeira
organizao informtica de uma grande instituio financeira em Portugal a obter esta
certificao internacional. A Esprito Santo Informtica (ESI) [21], organizao responsvel
pelos servios de informtica do Grupo BES, segunda maior instituio financeira privada
em Portugal, obteve a certificao CMMI nvel 2 fornecida pelo SEI com o objectivo de
melhorar a qualidade das aplicaes desenvolvidas, aumentar o controlo sobre os
mesmas, reduzir custos de manuteno e melhorar a eficincia [22].
Uma outra empresa que j possui o nvel de maturidade 2 a empresa Edisoft.

2.2. CMMI no BRASIL
No Brasil, existem cerca de 80 empresas com a certificao CMMI.
Exemplos de empresas que atingiram e certificao CMMI so: no nvel 5, a CPM Braxis, a
Ci&T, a IBM Brasil, a BRQ, a Politec, a Stefanini, a EDS Brasil, a Unisys Brasile a TCS do
Brasil; no nvel 3, a CPqD, a DMR Consulting e o Instituto Eldorado; a Resourc, a HB.SIS, a
7comm, a Softcomex e a Vixteam Consultoria e Sistemas, esto no nvel 2 [23].
A NTConsult certificou-se com o nvel 3 do CMMI, sendo uma das 30 empresas brasileiras
neste nvel.
A e-Core, empresa especializada em desenvolvimento de software, obteve a certificao
do CMMI, nvel 2. A empresa iniciou j o processo para a obteno do Nvel 3 do modelo.
A sua expectativa que o investimento na certificao CMMI contribua para o seu
desempenho no Brasil e nos Estados Unidos. Entre os benefcios que obteve com a
certificao, encontram-se a diminuio de 30% do custo de desenvolvimento de
software, de 40% de desvios nos cronogramas, e o aumento de 70% em produtividade e
50% em qualidade. Actualmente, existem pouco mais de 60 empresas no Brasil com o
nvel 2 do CMMI [24].
A CWI Software outra das empresas brasileiras que alcanou o segundo nvel de
maturidade do modelo CMMI para a organizao Fbrica de Projetos, em 2006. Atravs
desta certificao a organizao comprova a excelncia da metodologia de gesto e
desenvolvimento de software [25].
19
A consultoria de TI Stefanini conquistou o nvel 5 do CMMI, certificado que confere
empresa um padro de qualidade internacional na engenharia de software. Apenas 30
empresas possuem o CMMI nvel 5 em todo o mundo. A consultoria foi a primeira
organizao brasileira a obter o grau mximo de maturidade. At ento, apenas
multinacionais que actuam no pas possuam este nvel [26].
Outra organizao a obter a certificao CMMI nvel 5 foi a fbrica de software da EDS em
So Paulo, que j tinha atingido o CMMI nvel 5 para o centro de desenvolvimento que
mantm na capital fluminense [27].

2.3. CMMI em outros pases
Exemplos de organizaes internacionais com CMMI [23]:
Bank of America
BMW
Boeing
Bosch
Ericsson
Fujitsu
General Motors
Honeywell
IBM Global Services
Infosys
Intel
Lockheed Martin
Motorola
NASA
NDIA
NEC
Nokia
NTT Data
Polaris
Reuters
Samsung
U.S. Air Force
U.S. Army
U.S. Navy
20
Zurich Financial Services
Com o CMMI, a General Motors obteve uma melhoria significativa no cumprimento de
prazos, passando de 50 para 95 por cento, enquanto a Boeing Austrlia, aps atingir o
Nvel 2 do CMMI, registou uma reduo de 12% na ocorrncia de erros (e de 40% quando
alcanou o Nvel 3), uma diminuio de 8% nos custos de produo e um corte de 145%
nos desvios dos prazos. Em Espanha, a Caja Madrid, ao atingir a certificao de Nvel 2,
conseguiu baixar o nmero de erros em 15% e aumentar a produtividade em 8% [18].
A empresa Lockheed Martin Integrated Systems & Solutions (IS&S), por sua vez, garante
ter obtido com o CMMI uma diminuio nos custos da produo, um aumento da
produtividade do software, enquanto que a deteco e correco de defeitos diminuram
[28].
A Warner Robins Air Logistics Center (WR-ALC) alcanou em 2004 o nvel de maturidade 5
do CMMI. Depois de alcanar o CMMI, a WR-ALC viu diminudo o atraso nas suas entregas
de software e reduzido o nmero de erros no seu software [28].
A Motorola Software Group (MSG) assistiu a significativas melhorias no custo da
qualidade, na estimativa de exactido e na qualidade dos seus produtos, assim que a
Motorola Software Group China Center obteve a certificao CMMI. Como resultado
desta certificao, o MSG China reduziu os seus custos globais com a qualidade em mais
de um tero e reduziu tambm de forma significativa os erros do software que produz. As
taxas de satisfao dos clientes deste centro, que j eram elevadas, aumentaram ainda
mais [28].

Todos estes resultados demonstram o elevado potencial da melhoria de processos
baseada no CMMI. fcil concluir que o CMMI origina melhorias bastante significativas
na qualidade dos produtos, no desempenho de projectos, e no desempenho da
organizao, seja nacional ou internacional.
As organizaes que optam por esta certificao distinguem-se pela qualidade. A
qualidade representa um importante factor distintivo e uma vantagem competitiva num
mercado que extremamente competitivo. O reconhecimento CMMI uma forma destas
empresas reflectirem o seu empenho na estratgia de melhoria contnua, de modo a
propor ao mercado servios e solues cada vez melhor.

21
3. Objectivos

O objectivo deste trabalho o estudo do modelo CMMI e dos seus componentes. Para
isso vai ser utilizada a empresa Metatheke como caso de estudo.
A Metatheke [29] uma empresa spin-off da Universidade de Aveiro, constituda
oficialmente em Julho de 2007, que presta servios de consultoria e desenvolvimento de
solues relacionadas com todo o tipo de gesto de contedos digitais. Os servios que
presta incluem o desenvolvimento de plataformas integradas para gesto e
armazenamento de contedos digitais, algoritmos de indexao optimizados,
mecanismos de pesquisa multilingue, classificao semntica e sistemas escalveis com
elevada capacidade de armazenamento e processamento.
A empresa Metatheke ser utilizada para exemplificar a implementao do modelo
CMMI, que um modelo orientado essencialmente para grandes empresas, numa
pequena empresa com poucos recursos disponveis (mximo 10 trabalhadores).
Existem vrios estudos a partir dos quais se conclui que pequenas empresas so capazes
de implementar uma melhoria para os seus processos de software, de forma to eficaz
como as grandes empresas [30]. No entanto, para a maioria destas empresas, o CMMI
uma meta bastante desafiadora. O CMMI torna-se crtico na procura de uma forma
adequada de promover a competncia das pequenas e mdias empresas. Os principais
problemas que podem surgir para as pequenas e mdias empresas na adopo deste
modelo so os custos elevados e o grande nmero de relatrios [31]. Segundo M. Staples
et al. [32], num artigo que explora as razes pelas quais as organizaes no adoptam o
CMMI, o tamanho da empresa mesmo o principal motivo dado pelas empresas para no
adoptarem o modelo. Esta justificao (que obteve a maior percentagem de respostas)
pode ser um reflexo da percepo da inaplicabilidade do CMMI, ou pode ser reflexo de
um oramento restringido ou do tempo disponvel. No entanto, a maior parte dos
estudos que comparam o desempenho antes e aps introduo do CMMI em pequenas
empresas chegam a resultados positivos e concluem que as empresas pequenas iro
beneficiar bastante se adoptarem o CMMI, uma vez que a implementao do mesmo
traduzir-se- num futuro promissor com maior eficincia e efeitos [33].
Neste trabalho vo ser estudadas as reas de processo, metas e prticas a implementar
para preparar a empresa Metatheke para a obteno do nvel de capacidade 2 do modelo
CMMI, nas seguintes reas de processo:
Gesto de Requisitos;
Desenvolvimento de Requisitos;
Soluo Tcnica.
22
Foi escolhida a representao contnua por ser a que oferece maior flexibilidade para a
melhoria dos processos, na medida em que permite organizao escolher o foco dos
seus esforos no processo de melhoria, seleccionando as reas de processo que mais
beneficiam os objectivos de negcio da organizao, e por ser a representao mais
adequada para situaes em que os processos que precisam ser melhorados tenham sido
identificados. Outro factor que influenciou esta escolha foi o facto da representao por
estgios indicar uma ordem para a implementao das reas de processo de acordo com
os nveis de maturidade, que dever ser respeitada e, devido s limitaes de tempo e
complexidade na elaborao de cada processo, no seria possvel trabalhar todas as reas
de processo definidas num nvel de maturidade.

As empresas que optam pela representao contnua tm de seleccionar os processos
que so mais importantes para os seus objectivos de negcio. Uma vez que existem 22
reas de processo para escolher, um nmero elevado quando se inicia o processo,
comum a empresa seleccionar as reas de processo nas quais se deve focar a melhoria
dos processos.
A escolha das reas de processo a melhorar uma deciso essencial que deve ser tomada
pelas organizaes de software que adoptam a representao contnua do CMMI. No
entanto, os modelos CMMI no fornecem, a quem os adopta, qualquer orientao sobre
como fazer essa escolha. Assim, os gestores fazem muitas vezes uma seleco subjectiva
das reas de processo nas quais vo implementar a melhoria dos processos. Vrios
factores afectam a deciso da escolha das reas de processo com maior prioridade
quando a organizao escolhe a representao contnua. Esses factores podem incluir o
estado actual do ambiente de desenvolvimento, consideraes de rentabilidade, e os
requisitos dos clientes [34]. Atendendo s necessidades e prioridades da Metatheke, o
objectivo deste trabalho preparar a empresa para melhorar as seguintes reas de
processo, pertencentes rea de Engenharia:
Gesto de Requisitos: o objectivo da Gesto de Requisitos gerir os requisitos dos
produtos do projecto e componentes do produto e identificar inconsistncias
entre estes requisitos e os planos e os trabalhos do projecto [35].
Desenvolvimento de Requisitos: o objectivo do Desenvolvimento de Requisitos
produzir e analisar os requisitos de cliente, de produto e de componente de
produto [36].
Soluo Tcnica: o objectivo da Soluo Tcnica desenhar, desenvolver, e
implementar solues para os requisitos. As solues, desenhos, e
implementaes abrangem produtos, componentes de produto, e produtos do
23
ciclo de vida do processo, individualmente ou combinados conforme for mais
adequado [37].

Na representao contnua medida a capacidade em reas de processo individuais,
podendo uma empresa atingir um nvel de capacidade elevado numa determinada rea
de processo, enquanto mantm apenas o nvel de capacidade 2 em outras [31]. No
entanto o objectivo o nvel de capacidade 2 para todas as reas de processo escolhidas
para a melhoria.
Para entender a melhoria necessria para cada rea de processo necessrio analisar os
processos de cada rea de processo [13]:
Os processos da rea de processo em questo esto j esto implementados?
Caso no estejam, o objectivo de melhoria de processos dever ser atingir o nvel
de capacidade 1.
Os processos da rea de processo em questo esto implementados para cada
projecto, mas no so processos geridos (no existe uma infra-estrutura de
suporte)? O objectivo de melhoria de processos dever ser atingir o nvel de
capacidade 2.
Todos os processos da rea de processo em questo esto implementados, mas
cada projecto executa estes processos de forma diferente? O objectivo de
melhoria de processos dever ser atingir o nvel de capacidade 3.
Os processos da rea de processo em questo so geridos e desempenhados,
mas no existe uma forma objectiva de controlar e melhorar esses processos? O
objectivo de melhoria de processos dever ser atingir o nvel de capacidade 4.
A empresa quer garantir que est a escolher os processos certos para melhorar,
baseados em objectivos quantitativos para maximizar o negcio? O objectivo de
melhoria de processos dever ser atingir o nvel de capacidade 5.

No final deste trabalho pretende-se que a Metatheke saiba como melhorar os seus
processos de forma a conseguir alcanar o nvel de capacidade 2 do modelo CMMI, nas
trs reas de processo seleccionadas. Alcanar o nvel 2 nestas reas de processo,
significa que os processos associados so caracterizados como processos geridos. Um
processo gerido um processo executado que tem a infra-estrutura bsica no local para
suportar o processo; planeado e executado de acordo com a poltica de melhoria;
emprega pessoas qualificadas que tm recursos suficientes para produzir resultados
controlados; envolve as partes interessadas; monitorizado, controlado, e revisto; e
avaliado pela adeso descrio do processo [38].
24
Associado a cada rea de processo existe um conjunto de metas genricas e especficas
que tm de ser satisfeitas como uma medida para a melhoria nessa rea de processo.
Para alcanar o nvel 2 nas reas de processo escolhidas, a Metatheke ter que satisfazer
todas as metas desse conjunto de reas de processo.

25
4. rea de processo Gesto de Requisitos

O objectivo da rea de processo Gesto de Requisitos gerir os requisitos dos produtos e
seus componentes, e do projecto, e identificar inconsistncias entre estes requisitos e o
plano e os trabalhos do projecto. Os processos da gesto de requisitos gerem todos os
requisitos recebidos ou gerados pelo projecto, incluindo os requisitos tcnicos e no-
tcnicos assim como os requisitos adicionados ao projecto pela organizao [39].
A gesto de requisitos visa garantir que o projecto segue os passos apropriados para
assegurar que o conjunto de requisitos acordado gerido para suportar as necessidades
de planeamento e de execuo do projecto. Quando um projecto recebe requisitos de um
fornecedor de requisitos aprovado, os requisitos so revistos com a fonte de requisitos
para resolver problemas e prevenir incompreenses antes de serem incorporados no
plano do projecto. Depois da fonte de requisitos e da organizao chegarem a um acordo,
obtido um compromisso dos participantes do projecto para os requisitos. O processo
gere alteraes aos requisitos medida que eles evoluem e identifica inconsistncias que
ocorrem ao longo do plano, dos trabalhos, e dos requisitos. Parte da gesto de requisitos
consiste em documentar alteraes nos requisitos, e manter a rastreabilidade
bidireccional entre a fonte dos requisitos e todos os requisitos do produto [39].
Todos os projectos tm requisitos. No caso de um projecto focado em actividades de
manuteno, as alteraes ao produto baseiam-se em alteraes aos requisitos
existentes, desenho, ou implementao. As alteraes aos requisitos, caso existam,
podem ser documentadas em pedidos de alterao do cliente ou dos utilizadores, ou
podem ter a forma de novos requisitos recebidos do processo de desenvolvimento de
requisitos. Independentemente da sua fonte ou forma, as actividades de manuteno que
derivam das alteraes dos requisitos so geridas conformemente [35].

4.1. reas de processo relacionadas
A rea de processo Gesto de Requisitos relaciona-se com outras reas de processo que
esto envolvidas com as suas prticas ou sub-prticas. A anlise completa e o desenho do
modelo de processo dever ser obtido considerando todas as reas de processo
relacionadas. As reas de processo relacionadas com a Gesto de Requisitos so as
seguintes [39]:
Desenvolvimento de Requisitos: transformao das necessidades dos interessados
em requisitos para o produto e diviso de como alocar ou distribuir requisitos
pelos componentes do produto;
Soluo Tcnica: transformao dos requisitos em solues;
26
Planeamento do Projecto: de que forma o plano do projecto reflecte os requisitos
e precisa de ser revisto com a alterao dos requisitos;
Gesto de Configurao: ponto de partida e controlo das alteraes da
documentao de configurao para requisitos;
Monitorizao e controlo do projecto: acompanhamento e controlo das
actividades dos trabalhos baseados nos requisitos e tomada de aces de
correco apropriadas;
Gesto de Riscos: identificao e tratamento dos riscos associados aos requisitos.

4.2. Metas e prticas da rea de processo gesto de requisitos
O nvel de capacidade que se pretende atingir vai determinar quais as metas e prticas
genricas que sero aplicadas rea de processo seleccionada.
As metas genricas aplicam-se a todos as reas de processo. Todas as metas e prticas
genricas so utilizadas na representao contnua. Para atingir um nvel de capacidade
numa rea de processo necessrio satisfazer todas as metas (genricas e especficas)
dessa rea de processo.
Uma organizao que pretenda alcanar o nvel de capacidade 2 do CMMI nesta rea de
processo ter que satisfazer as metas especficas e genricas:
Meta especfica 1: Gesto de requisitos
Meta genrica 1: Atingir as metas especficas
Meta genrica 2: Institucionalizar um processo gerido

Na Tabela 6 encontram-se enumeradas as prticas relacionadas com cada uma das metas,
genrica e especficas [35].

27
Tabela 6 Metas e Prticas necessrias para atingir o nvel de capacidade 2 na rea de processo Gesto de requisitos
META PRTICAS
Meta Especfica 1: Gesto de
Requisitos
Prtica especfica 1.1: Obter um entendimento dos requisitos
Prtica especfica 1.2: Obter um acordo para os requisitos
Prtica especfica 1.3: Gerir alteraes aos requisitos
Prtica especfica 1.4: Manter rastreabilidade bidireccional de requisitos
Prtica especfica 1.5: Identificar inconsistncias entre os trabalhos e os
requisitos
Meta Genrica 1: Atingir as
metas especficas
Prtica genrica 1.1: Realizar as prticas especficas
Meta Genrica 2:
Institucionalizar um processo
gerido
Prtica genrica 2.1: Estabelecer uma poltica organizacional
Prtica genrica 2.2: Planear o processo
Prtica genrica 2.3: Disponibilizar recursos
Prtica genrica 2.4: Atribuir responsabilidades
Prtica genrica 2.5: Formar as pessoas
Prtica genrica 2.6: Gerir configuraes
Prtica genrica 2.7: Identificar e envolver as partes interessadas
Prtica genrica 2.8: Monitorizar e controlar o processo
Prtica genrica 2.9: Avaliar objectivamente a adeso
Prtica genrica 2.10: Rever o estado com gesto de alto nvel

4.2.1. Metas e prticas especficas
A meta especfica 1, GESTO DE REQUISITOS garante que os requisitos so geridos e as
inconsistncias com os planos e os trabalhos do projecto so identificadas. O projecto
mantm um conjunto de requisitos actualizado e aprovado ao longo do seu tempo de
vida:
Gerindo todas as alteraes aos requisitos;
Mantendo as relaes entre os requisitos, os planos do projecto, e os trabalhos;
Identificando inconsistncias entre os requisitos, os planos do projecto e os
trabalhos;
Tomando aces correctivas.

Esta meta especfica composta por cinco prticas especficas [35]:
Prtica especfica 1.1: Obter um entendimento dos requisitos
O objectivo desta prtica desenvolver um entendimento com a fonte dos
requisitos sobre o significado dos requisitos.
28
medida que o projecto amadurece e os requisitos so derivados, todas as
actividades ou disciplinas iro receber requisitos. Para evitar que os requisitos se
arrastem, so estabelecidos critrios para designar canais apropriados, ou fontes
oficiais, por onde devero ser recebidos os requisitos. As actividades de recepo
conduzem a anlises dos requisitos com a fonte de requisitos para assegurar que
uma compreenso compatvel e uma partilhada sobre o significado dos requisitos
atingida. O resultado desta anlise e dilogo um acordo para o conjunto de
requisitos.
Trabalhos tpicos:
1. Lista de critrios para distino de fontes de requisitos adequados;
2. Critrios de avaliao e de aceitao de requisitos;
3. Resultados das anlises face aos critrios;
4. Um acordo sobre o conjunto de requisitos.
Subprticas:
1. Estabelecer critrios para distino de fontes de requisitos adequados;
2. Estabelecer critrios objectivos para a avaliao e aceitao de requisitos.
A falta de critrios de avaliao e aceitao resulta muitas vezes em
verificaes inadequadas, retrabalho dispendioso, ou na rejeio dos clientes;
3. Analisar os requisitos para assegurar que os critrios estabelecidos so
cumpridos;
4. Alcanar um entendimento dos requisitos com a fonte de requisitos para que
os participantes do projecto possam chegar a um acordo para eles.

Prtica especfica 1.2: Obter um acordo para requisitos
O objectivo desta prtica obter um acordo dos participantes do projecto para os
requisitos.
Os requisitos evoluem ao longo do projecto. medida que os requisitos evoluem,
esta prtica especfica assegura que os participantes do projecto comprometem-
se com os requisitos actuais e aprovados e com as alteraes resultantes nos
planos do projecto, actividades e trabalho.
Trabalhos tpicos:
1. Avaliaes do impacto dos requisitos;
2. Acordos documentados dos requisitos e alteraes aos requisitos.

29
Subprticas:
1. Avaliar o impacto dos requisitos nos compromissos existentes.
O impacto nos participantes do projecto deve ser avaliado quando os
requisitos alteram ou no incio de um novo requisito;
2. Negociar e registar acordos.
Alteraes aos acordos existentes devem ser negociadas antes do acordo dos
participantes do projecto dos requisitos ou alteraes aos requisitos.

Prtica especfica 1.3: Gerir alteraes aos requisitos
O objectivo desta prtica gerir alteraes aos requisitos medida que eles
evoluem ao longo do projecto.
Durante o projecto os requisitos variam por diversas razes. medida que so
necessrias alteraes e os trabalhos prosseguem, surgem requisitos adicionais e
podem ter que ser efectuadas alteraes aos requisitos existentes. essencial
gerir essas adies e alteraes de forma eficiente e efectiva. Para se analisar o
impacto das alteraes, necessrio que a fonte de cada requisito seja conhecida
e a razo para qualquer alterao seja documentada.
Trabalhos tpicos:
1. Estado dos requisitos;
2. Base de dados de requisitos;
3. Base de dados de deciso de requisitos.
Subprticas:
1. Documentar todos os requisitos e alteraes aos requisitos que so dadas ou
gerados pelo projecto;
2. Manter o histrico de alteraes aos requisitos com a razo para as
alteraes;
3. Avaliar o impacto das alteraes aos requisitos do ponto de vista das partes
interessadas;
4. Manter os dados dos requisitos e alteraes disponveis para o projecto.

Prtica especfica 1.4: Manter a Rastreabilidade Bidireccional de Requisitos
A inteno desta prtica especfica manter a rastreabilidade bidireccional de
requisitos para cada nvel de composio do produto. Quando os requisitos so
bem geridos, a rastreabilidade pode ser estabelecida desde um requisito fonte at
30
aos requisitos de mais baixo nvel, e destes de volta para o seu requisito fonte.
Esta rastreabilidade bidireccional ajuda a determinar que todos os requisitos fonte
foram completamente abordadas e que todos os requisitos de menor nvel podem
ser atribudos a uma fonte vlida.
A rastreabilidade dos requisitos tambm pode abranger as relaes com outras
entidades como trabalhos intermdios e final, mudanas na documentao de
concepo, e planos de teste. A rastreabilidade pode tambm abranger as
relaes horizontais, como atravs de interfaces, assim como as relaes verticais.
A rastreabilidade particularmente necessria na conduo da avaliao do
impacto das alteraes aos requisitos nas actividades e trabalhos do projecto.
Trabalhos tpicos:
1. Matriz de rastreabilidade de requisitos;
2. Sistema de monitorizao de requisitos.
Subprticas:
1. Manter a rastreabilidade de requisitos para assegurar que a fonte dos
requisitos de nvel mais baixo documentada;
2. Manter a rastreabilidade de requisitos de um requisito para os requisitos dele
derivados e atribuio de funes, interfaces, objectos, pessoas, processos, e
trabalhos;
3. Manter a rastreabilidade horizontal de funo para funo e entre interfaces;
4. Gerar a matriz de rastreabilidade de requisitos.

Prtica especfica 1.5: Identificar inconsistncias entre os trabalhos e os requisitos
O objectivo desta prtica identificar inconsistncias entre os trabalhos e os
requisitos.
Esta prtica especfica localiza as inconsistncias entre os requisitos e os planos e
trabalhos do projecto e inicia as aces correctivas para as resolver.
Trabalhos tpicos:
1. Documentao das inconsistncias incluindo as fontes, condies, e razes;
2. Aces correctivas.

31
Subprticas:
1. Rever os planos do projecto, actividades, e trabalhos para a consistncia com
os requisitos e as alteraes feitas a estes;
2. Identificar as fontes da inconsistncia e a razo;
3. Identificar alteraes que necessitam de ser feitas nos planos e nos trabalhos
resultantes das alteraes aos requisitos iniciais;
4. Iniciar aces correctivas.

4.2.2. Metas e prticas genricas
A meta genrica 1, ALCANAR AS METAS ESPECFICAS, garante que o processo suporta e
permite alcanar as metas especficas da rea de processo.
Esta meta genrica composta por uma prtica genrica: Realizar as prticas especficas.
O objectivo desta prtica realizar as prticas especficas do processo de gesto de
requisitos para produzir trabalhos e fornecer servios para alcanar as metas especficas
da rea de processo.

A meta genrica 2, INSTITUCIONALIZAR UM PROCESSO GERIDO, garante que o processo
institucionalizado como um processo gerido.
Esta meta genrica composta por dez prticas genricas [35]:
Prtica genrica 2.1: Estabelecer uma Poltica Organizacional
O objectivo desta prtica estabelecer e manter uma Poltica Organizacional para
planear e executar o processo de gesto de requisitos.
Elaborao:
Esta poltica estabelece expectativas organizacionais para gerir requisitos e
identificar inconsistncias entre os requisitos e os planos e trabalhos do projecto.

Prtica genrica 2.2: Planear o Processo
O objectivo desta prtica estabelecer e manter o plano para executar o processo
de gesto de requisitos.
32
Elaborao:
Este plano para executar o processo de gesto de requisitos pode fazer parte do
plano do projecto, ou ser referenciado por este.
O objectivo desta prtica disponibilizar os recursos adequados para executar o
processo de gesto de requisitos, desenvolver os trabalhos e fornecer os servios
do processo.

O objectivo desta prtica atribuir a responsabilidade e autoridade para executar
o processo, desenvolver os trabalhos, e fornecer os servios do processo de
gesto de requisitos.

O objectivo desta prtica formar as pessoas para realizar ou apoiar o processo
de gesto de requisitos como for necessrio.

Prtica genrica 2.6: Gerir Configuraes
O objectivo desta prtica colocar os trabalhos designados do processo de gesto
de requisitos em nveis adequados de controlo.

O objectivo desta prtica identificar e envolver as partes interessadas no
processo de gesto de requisitos como planeado.
Elaborao:
Seleccionar as partes interessadas entre clientes, utilizadores finais,
programadores, produtores, testadores, fornecedores, comerciantes, e outro
pessoal que possa estar afectado ou afectar o produto assim como o processo.
33
Prtica genrica 2.8: Monitorizar e Controlar o Processo
O objectivo desta prtica monitorizar e controlar o processo de gesto de
requisitos face ao plano para executar o processo e tomar as aces correctivas
apropriadas.

Prtica genrica 2.9: Avaliar Objectivamente a Adeso
O objectivo desta prtica avaliar objectivamente a adeso do processo de gesto
de requisitos sua descrio, normas e procedimentos, e tratar as no
conformidades.

Prtica genrica 2.10: Rever o Estado com o nvel mais alto de Gesto
O objectivo desta prtica rever as actividades, estado, e resultados do processo
de gesto de requisitos com elevado nvel de gesto e resolver os problemas.
Elaborao:
As alteraes propostas aos compromissos so revistas com o nvel mais alto de
gesto para assegurar que todos os compromissos possam ser realizados.

4.3. Alcanar o nvel de capacidade 2 na rea de processo Gesto de
Requisitos
O CMMI define a rea de processo Gesto de Requisitos mas no descreve como devero
as organizaes proceder para a alcanar, endereando apenas as melhores prticas do
ponto de vista da gesto.
De seguida, encontram-se descritos os artefactos, papis e actividades que devero ser
seguidos pela Metatheke para a implementao das prticas especficas e genricas da
rea de processo Gesto de Requisitos.
Todos os artefactos apresentados devero ser revistos e validados pela gesto da
empresa e por uma equipa de garantia de qualidade.

34
4.3.1. Implementar as metas especficas
De acordo com o objectivo da prtica especfica 1.1, Obter um entendimento dos
requisitos, dever existir uma lista de critrios para distinguir as fontes de requisitos
adequadas, assim como uma lista de critrios para avaliar e aceitar os requisitos
fornecidos pela fonte.
1. Lista de critrios para distino de fontes adequadas
Todas as fontes de requisitos autorizadas, ou seja, todos aqueles canais por onde
podem ser recebidos os requisitos, devero ser conhecidas e identificadas. Dever ser
criada uma base de dados para registo desta informao. Sempre que uma nova fonte
for avaliada como adequada, dever ser acrescentada a essa base de dados.
A base de dados de fornecedores aceites, necessita apenas da seguinte informao:
Id: identificador nico da fonte;
Fonte: nome da fonte.
A lista de critrios servir para avaliar se uma determinada fonte de requisitos ou
no adequada.
Na Tabela 7 apresentado um exemplo de uma lista de critrios que poder ser
seguida pela Metatheke para avaliao da fonte.

Tabela 7 Lista de critrios para distino de fontes adequadas
Critrios Satisfaz? (S/N)
Pertence lista de fornecedores aceites?
cliente do projecto?
Trabalha no projecto?
fornecedor de software para a empresa?
gestor ou administrador da empresa?
utilizador do projecto?
patrocinador do projecto?

35
Se a fonte satisfazer pelo menos um destes critrios poder ser considerada
adequada para disponibilizar novos requisitos.
Sempre que se justificar, poder ser adicionado um novo critrio lista anterior.
2. Critrios de avaliao e aceitao de requisitos
Sempre que recebido um requisito ter que ser efectuada a sua avaliao de acordo
com os critrios determinados pela empresa para avaliao e aceitao dos requisitos.
Na Tabela 8 apresentado um exemplo de uma lista de critrios que poder ser
seguida pela Metatheke para avaliao dos requisitos recebidos.

Tabela 8 Lista de critrios para avaliao e aceitao de requisitos
Critrios Satisfaz? (S/N)
Determinado de forma clara?
Completo?
Coerente entre si?
Singularmente identificados?
Apropriado para implementar?
Verificvel e testvel?
Rastrevel?
Realmente necessrio?
No traz risco para o projecto?

Para cada requisito ser aceite ter que satisfazer todos os critrios apresentados na
lista. Sempre que se justificar, poder ser adicionado um novo critrio lista anterior.

De acordo com o objectivo da prtica especfica 1.2, Obter um acordo para os requisitos,
dever existir um documento de requisitos que servir para obter um acordo com a fonte
36
de requisitos, chegar a um acordo sobre os requisitos solicitados e sobre as mudanas
que estes sofrem.
1. Acta das reunies
Os acordos sobre o conjunto de requisitos surgem aps reunies de clarificao com
as fontes de requisitos. No final destas reunies dever ser elaborada a Acta da
reunio e distribuda por todos os participantes para reviso.
No Anexo A encontra-se o template que dever ser utilizado para elaborao das Acta
das reunies da Metatheke.
2. Documento de requisitos
O formato do documento de requisitos (Anexo B) deve ser mutuamente aceite. Neste
documento devero estar documentados os compromissos sobre os requisitos e
alteraes aos requisitos.
O documento dever ser revisto e validado internamente e pela fonte dos requisitos.
A reviso interna ser feita por uma disciplina multi-disciplinar para assegurar que
cada disciplina e funo de suporte necessrias para o projecto partilham o mesmo
entendimento do requisito [40]. A reviso pela fonte pretende garantir que o
conjunto total de requisitos exactamente o que foi solicitado pelo cliente.
Um exemplo simples que ilustra a especificao de um requisito no documento de
requisitos, aps a sua anlise completa, apresentado no Anexo C. O exemplo
consiste num requisito de um projecto da Metatheke destinado a um jornal nacional
dirio para o desenvolvimento de um sistema, denominado EdiesOnline, que
permite a transferncia para consulta das edies do jornal.

De acordo com o objectivo da prtica especfica 1.3, Gerir alteraes aos requisitos,
dever existir um documento para registo de alteraes que ocorrerem nos requisitos ou
nos planos, uma base de dados de requisitos e uma base de dados de deciso de
requisitos.
1. Documento de alteraes
O formato do documento de alteraes (Anexo D) deve ser mutuamente aceite. Neste
documento devero estar documentadas as propostas de alterao aos requisitos. As
37
alteraes aos compromissos devem ser renegociados com todas as partes
interessados que foram envolvidas na reviso e aprovao do conjunto inicial de
requisitos. As alteraes externas aos compromissos devero ser revistas pela equipa
de gesto [40].
No anexo E apresentado um exemplo do documento de alteraes, que descreve
uma alterao proposta para o requisito do exemplo anterior. No anexo F encontra-se
a segunda verso do documento de requisitos aps esta alterao do requisito.
2. Base de Dados de Requisitos
Na base de dados de requisitos sero registados todos os requisitos do projecto e
todas as alteraes que possam ocorrer, mantendo-se assim um histrico sempre
actualizado de requisitos.
Na base de dados de requisitos, ficar guardada a seguinte informao:
Cdigo: identificador nico do requisito;
Descrio: descrio completa do requisito;
Tipo: tipo de requisito (funcional, de interface, de configurao, etc.);
Produto: identificao do produto ao qual pertence o requisito;
Verso: identificao da verso do produto ao qual pertence o requisito;
Origem: fonte do requisito;
Data: data em que o requisito foi recebido;
Prioridade: prioridade de implementao do requisito;
Estado: estado actual em que se encontra o requisito (em anlise, analisado,
implementado, testado, etc.);
Risco: risco que a implementao do requisito traz para o projecto;
Responsveis: identificao das pessoas responsveis pelo controlo do
requisito em todo o seu tempo de vida;
Requisitos relacionados: identificao de todos os requisitos relacionados;
Alteraes: identificao das alteraes relacionadas com o requisito (campo
Id da base de dados de alteraes);
Observaes: outras informaes relacionadas com o requisito que seja
importante registar.
3. Base de dados de alteraes
Na base de dados de alteraes sero registadas todas alteraes que possam ocorrer
no projecto. Na base de dados de alteraes, ficar guardada a seguinte informao:
38
Id: identificador nico da alterao (usado por exemplo para identificar a
alterao na base de dados do requisito);
Alterao: descrio detalhada da alterao;
Data: data em que foi efectuada a alterao;
Responsvel: identificao da pessoa que fez a alterao;
Justificao: indicao do motivo da alterao;
Observaes: outras informaes relacionadas com a alterao que seja
importante registar.

De acordo com o objectivo da prtica especfica 1.4, Manter rastreabilidade bidireccional
de requisitos, dever existir uma matriz de rastreabilidade dos requisitos para o projecto.
1. Matriz de rastreabilidade
Um requisito rastrevel se for conhecida a sua fonte, o motivo do requisito, os
requisitos relacionados e a forma como o requisito est relacionado com outra
informao como, por exemplo, arquitectura do sistema, implementao ou
documentao. Na matriz de rastreabilidade do projecto dever ser registada toda
esta informao [40].
Na Tabela 9 apresentado um modelo para a matriz de rastreabilidade que
dever ser seguida pela Metatheke para os seus projectos.

Tabela 9 Matriz de rastreabilidade de requisitos
Requisito Requisitos relacionados Informao associada
Requisito Fonte Motivo Dependentes Depende de Implementao Testes Planos Documentao

A informao de rastreabilidade dos requisitos inserida na matriz dever ser
actualizada ao longo do ciclo de vida dos requisitos.
39
Toda a informao de rastraebilidade dos requisitos ficar tambm armazenada
numa base de dados.
De acordo com o objectivo da prtica especfica 1.5, Identificar inconsistncias entre os
trabalhos e os requisitos, dever existir um documento para o registo de inconsistncias.
1. No documento de inconsistncias (Anexo G) devero ser registadas as
inconsistncias, nos planos ou nos trabalhos.
Para facilitar a elaborao do documento de inconsistncias, encontra-se no
Anexo H um exemplo de preenchimento deste documento, que descreve uma
inconsistncia encontrada entre o requisito especificado, apresentado atrs como
exemplo, e o desenvolvimento do requisito.

A Figura 2 representa um fluxograma de implementao da rea de processo Gesto de
Requisitos, que tem em considerao todas as metas especficas desta rea de processo.
40

Figura 2 Fluxograma de implementao da meta especfica 1 da rea de processo Gesto de Requisitos

41
4.3.2. Implementar as metas genricas
Realizando todas as metas especficas desta rea de processo, implementa-se a Meta
Genrica 1, ATINGIR AS METAS ESPECFICAS.
Para atingir a Meta Genrica 2, INSTITUCIONALIZAR UM PROCESSO GERIDO, e assim
alcanar o nvel de capacidade 2, a Metatheke ter que implementar as 10 prticas
genricas apresentadas de seguida.

De acordo com o objectivo da prtica genrica 2.1, Estabelecer uma poltica
organizacional, dever ser definida uma Poltica Organizacional para a gesto de
requisitos. A poltica organizacional da Metatheke ficar descrita num documento editado
pela equipa de gesto que descreve o comportamento esperado dos trabalhadores no
processo de gesto de requisitos [40].
No Anexo I [41] apresentada a poltica de gesto de requisitos, que ser seguida pela
Metatheke nos seus projectos.

De acordo com o objectivo da prtica genrica 2.2, Planear o processo, dever ser
definido um plano para a Gesto de Requisitos. Neste plano devero constar todas as
tarefas necessrias para a execuo do processo de gesto dos requisitos, revisto e
acordado por todas as partes relevantes [40].
No planeamento da Metatheke deve ser considerado:
A descrio do processo definido;
O calendrio no qual o processo de gesto de requisitos deve ser executado;
Os recursos necessrios para a execuo do processo de gesto de requisitos,
incluindo financiamento, pessoas e ferramentas;
Formao necessria;
Trabalhos a serem colocados na Gesto de Configurao;
Requisitos de medida para fornecer uma viso detalhada do desempenho do
processo de gesto de requisitos, seus trabalhos e servios;
Actividades objectivas de verificao para o processo e trabalhos.

42
Na Figura 3 apresentado o que dever ser includo no plano de Gesto de Requisitos da
Metatheke.

Figura 3 Plano de Gesto de Requisitos [39]

De acordo com o objectivo da prtica genrica 2.3, Disponibilizar recursos, devero ser
disponibilizados os recursos necessrios para a Gesto de Requisitos, tais como:
Oramento adequado
Instalaes fsicas apropriadas:
ndice
Revises
Glossrio
1.0 Introduo
2.0 Objectivo
2.1 mbito
2.2 Definies
2.3 Objectivos
3.0 Gesto
3.1 Organizao
3.2 Tarefas
3.3 Responsabilidades
3.3.1 Gesto
3.3.2 Gestor do Programa
3.3.3 Liderana do Projecto
3.3.4 Membros da Equipa
3.3.5 Cliente
3.4 Plano
3.5 Recursos
3.6 Formaes
4.0 Processo de Gesto de Requisitos de Software
4.1 Propostas de Requisitos
4.2 Anlise de Requisitos
4.3 Especificao de Requisitos
4.4 Propostas de Alteraes aos Requisitos
4.5 Rastreabilidade de Requisitos
5.0 Medies e Mtricas de Software
6.0 Verificao e Validao
7.0 Gesto de Configuraes de Software
8.0 Desenvolvimento da Especificao de Requisitos de Software
Documentos Anexos
43
sala de reunies
sala para equipa de requisitos
Pessoas qualificadas, ou formao e acompanhamento para ajudar as pessoas a
obter o conhecimento e a qualificao necessrios:
Em gesto de requisitos
Em gesto de projectos
Em gesto da qualidade
Ferramentas adequadas:
Sistemas de base de dados
Ferramentas de modelao de sistemas
Ferramentas de anlise estatstica
Ferramentas de gesto de projectos
Ferramentas de rastreabilidade

De acordo com o objectivo da prtica genrica 2.4, Atribuir responsabilidades, a
atribuio de responsabilidades dever ser feita para o processo de gesto de requisitos.
A Metatheke actualmente emprega menos de 10 pessoas. Para solucionar a limitao de
recursos, que torna este modelo complicado de implementar, os colaboradores da
empresa assumem vrios papis em paralelo.
Na Tabela 10 apresentada a tabela de atribuies de responsabilidades para o processo
de gesto de requisitos da Metatheke. Nesta tabela, para cada equipa envolvida no
processo de gesto de requisitos, indicado o nome e o contacto de cada membro,
juntamente com a indicao da sua responsabilidade.

Tabela 10 Tabela de atribuio de responsabilidades para a Gesto de requisitos
Equipa Nome
Administrao
Pedro Almeida
Marco Fernandes

Gesto
Pedro Almeida

Qualidade
Joana Martins

Gesto
Projectos
Sara Martins
Pedro Pais

Requisitos
Joo Oliveira
Marco Fernandes

No organigrama da empresa (
das equipas envolvidas no processo de Gesto de Requisitos.
Figura 4 Seco do o
Equipa Gesto
Pedro Almeida
Tabela de atribuio de responsabilidades para a Gesto de requisitos
Contacto Responsabilidade
dgeral@metatheke.com Director Geral
Marco Fernandes did@metatheke.com Director I&D


dqualidade@metatheke.com Director de Qualidade

gprojectos@metatheke.com Gestor de Projectos
gprojectosint@metatheke.com Gestor de Projectos Internacionais

tinformatica@metatheke.com Tcnico Superior de
Marco Fernandes did@metatheke.com

(Figura 4) dever ficar claramente representada a
das equipas envolvidas no processo de Gesto de Requisitos.
Seco do organigrama correspondente Gesto de Requisitos
Administrao
Pedro Almeida
Marco Fernandes
Equipa Qualidade
Joana Martins
Equipa Engenharia
Gesto Projectos
Sara Martins
Pedro Pais
Requisitos
Joo Oliveira
Marco Fernandes

Responsabilidade
Qualidade
Gestor de Projectos
Gestor de Projectos Internacionais
Tcnico Superior de Informtica
dever ficar claramente representada a hierarquia

Requisitos
Joo Oliveira
Marco Fernandes
45
De acordo com o objectivo da prtica genrica 2.5, Formar as pessoas, dever existir
formao para todas as pessoas envolvidas no processo de gesto de requisitos.
Alguns exemplos de tpicos de formao so:
Definio, anlise, reviso e gesto de requisitos;
Ferramentas de gesto de requisitos;
Gesto de configuraes;
Negociao e resoluo de conflitos.
A Metatheke dever definir o modelo e regras das formaes de gesto de requisitos. A
ttulo de exemplo, todos os envolvidos no processo devero participar em 2 formaes
por ano, sendo que cada um destes dever escolher as formaes mais adequadas com a
sua funo, e esta escolha dever ser aprovada pela gesto.
Todos os anos dever ser criada e apresentada a todos os envolvidos, uma lista com as
formaes disponveis. Para cada formao contida nessa lista dever ser apresentado:
Nome da formao;
Durao da formao (em horas);
Local da formao;
Data da formao;
Destinatrios da formao;
Objectivos da formao;
Pr-requisitos da formao;
Contedo da formao;
Competncias adquiridas.
Dever existir na Metatheke uma base de dados de registo de formaes, com a seguinte
informao para cada trabalhador envolvido na gesto de requisitos:
Nome do trabalhador;
Nome da formao;
Local da formao;
Data da formao;
Contedo da formao;
Competncias adquiridas;
46
Classificao: classificao obtida na formao (caso exista).
De acordo com o objectivo da prtica genrica 2.6, Gerir configuraes, a Metatheke
dever gerir as configuraes do sistema para a Gesto de Requisitos.
O objectivo da gesto de configurao estabelecer e manter a integridade dos
requisitos ao longo do ciclo de vida do projecto, evitando que verses corrigidas sejam
perdidas. Todas as modificaes nos artefactos necessrios para o processo de gesto de
requisitos (documento de requisitos, documento de alteraes, documento de
inconsistncias, matriz de rastreabilidade, actas de reunies, planos) sero organizadas e
registadas numa base de dados, com a seguinte informao:
Artefacto: identificao geral do tipo de artefacto no qual foi realizada a
modificao (por exemplo: Documento de Requisitos);
Identificao do artefacto: identificao nica do artefacto no qual foi realizada a
modificao (por exemplo: id do documento de requisitos em questo);
Modificao: descrio da modificao efectuada no artefacto;
Autor: identificao do responsvel pela realizao da modificao;
Data: data em que foi realizao a modificao;
Justificao: descrio do motivo pelo qual foi realizada a modificao.

De acordo com o objectivo da prtica genrica 2.7, Identificar e envolver as partes
interessadas, a Metatheke dever identificar e envolver as partes relevantes na gesto de
requisitos. Para isso dever [42]:
Nas actas das reunies de anlise de requisitos, de controlo e de gesto, indicar
quais as partes interessadas que participaram na reunio e incluir todos os itens
de aco atribudos s partes interessadas;
Nos documentos de requisitos, alteraes e inconsistncias, incluir os nomes das
partes interessadas envolvidas;
Criar matriz das partes interessadas indicando os respectivos papis.
Alguns exemplos de actividades de envolvimento das partes interessadas so:
Resolver questes na compreenso dos requisitos;
Avaliar o impacto das alteraes nos requisitos;
Comunicar a rastreabilidade bidireccional;
Identificar as inconsistncias ao longo do plano do projecto, trabalhos e requisitos.
47
Na Tabela 11 apresentado um exemplo da matriz das partes relevantes do processo de
gesto dos requisitos para um projecto da Metatheke.

Tabela 11 Tabela de identificao das partes relevantes no processo de Gesto de requisitos
Papel Nome
Gestor de Projecto Sara Martins
Director de Qualidade Joana Martins
Requisitos
Joo Oliveira
Marco Fernandes

De acordo com o objectivo da prtica genrica 2.8, Monitorizar e controlar o processo, a
Metatheke dever monitorizar e controlar a gesto dos requisitos.
Exemplos de medidas e trabalhos usados na Metatheke para monitorizao e controlo
[35], [40]:
Medio da volatilidade dos requisitos (percentagem de alteraes aos
requisitos);
Planeamento para a coordenao de requisitos;
Planeamento para a anlise de uma alterao aos requisitos proposta;
Recolha e anlise de medidas de desempenho face ao plano de gesto de
requisitos;
Reviso do cumprimento e dos resultados do processo de gesto de requisitos
face ao planeado;
Tomar aces correctivas quando os objectivos da gesto de requisitos no esto
a ser satisfeitos, quando os problemas esto identificados, ou quando o progresso
difere significativamente do plano [43]:
Trabalhar com as partes interessadas para ajudar na minimizao das
alteraes;
Aplicar recursos extra para a definio de requisitos se o conjunto de
requisitos para o produto no estiver definido;
Envolver pessoas de equipas diferentes;
Disponibilizar mais formao para as pessoas da equipa.
Seguir de perto as aces correctivas.
48
Seguir os itens de aco das reunies semanais de controlo.
A gesto dos requisitos dever ser analisada em reunies semanais de controlo do
projecto.
No final da reunio de controlo dever ser feita a Acta da reunio, que ser revista pela
gesto, e enviado o ponto de situao para todos os envolvidos no projecto. No ponto de
situao dever constar a seguinte informao:
Identificao e breve descrio do projecto;
Contacto do Responsvel de cada uma das reas envolvidas na gesto de
requisitos, indicando:
rea;
Responsvel;
Contacto (email, por exemplo).
Resumo e estado de todas as actividades de gesto de requisitos, indicando:
rea;
Actividade;
Estado da actividade;
Data alvo da actividade.
Itens de aco relacionados com a gesto de requisitos, indicando:
Aco;
Responsvel pela aco;
Estado actual da aco;
Data alvo da aco.

De acordo com o objectivo da prtica genrica 2.9, Avaliar objectivamente a adeso, na
Metatheke dever ser analisada a aderncia ao processo de Gesto de Requisitos.
A avaliao da aderncia ser realizada atravs das avaliaes de processo, onde sero
analisadas as seguintes questes [40]:
O processo de gesto de requisitos implementado como planeado?
O processo de gesto de requisitos planeado satisfaz os requisitos e objectivos?
49
Os resultados de seguir o processo de gesto de requisitos satisfazem os seus
requisitos?
Alm das avaliaes, a equipa de Qualidade dever realizar auditorias peridicas. Devero
ser feitos relatrios das auditorias, revises objectivas das actas das reunies, relatrios
de falhas, e uma reviso por parte da gesto dos resultados das auditorias [42].

De acordo com o objectivo da prtica genrica 2.10, Rever o estado com gesto de alto
nvel, a Metatheke dever rever o estado da Gesto de Requisitos com elevado nvel de
gesto. Para isso, semanalmente dever ser efectuada uma reunio de gesto, para a
reviso das actividades, estado, e resultados do processo de gesto de requisitos com um
nvel alto de gesto e resolver todas as questes existentes.
Nas reunies de gesto, a gesto da Metatheke deve considerar os relatrios de
auditorias, relatrios de falhas, e pontos de situao semanais do processo de
desenvolvimento de requisitos.

51
5. rea de processo Desenvolvimento de Requisitos

O objectivo do desenvolvimento de requisitos produzir e analisar os requisitos de
cliente, de produto e de componentes do produto [39].
Esta rea de processo descreve trs tipos de requisitos: requisitos de cliente, requisitos
de produto e requisitos de componentes de produto. Em conjunto, estes requisitos
atendem s necessidades das partes interessadas relevantes, includo as pertinentes s
vrias fases do ciclo de vida do projecto e atributos do produto. Os requisitos atendem
tambm s limitaes causadas pela escolha das solues de concepo [39].
Todos os projectos de desenvolvimento tm requisitos. No caso de um projecto focado
em actividades de manuteno, as alteraes ao produto ou aos seus componentes so
baseadas nas alteraes aos requisitos, concepo ou implementao existentes. As
alteraes aos requisitos, se existirem, podem ser documentadas em pedidos de
alteraes do cliente ou dos utilizadores, ou podem tomar a forma de novos requisitos
recebidos do processo de desenvolvimento de requisitos [36].
Os requisitos so a base da concepo. O desenvolvimento de requisitos inclui as
seguintes actividades [39]:
Elicitao, anlise, validao, e comunicao das necessidades do cliente,
expectativas, e limitaes para a obteno dos requisitos do cliente, que
constituem um entendimento do que ir satisfazer as partes interessadas;
Recolha e coordenao das necessidades das partes interessadas;
Desenvolvimento de requisitos do ciclo de vida do produto;
Estabelecimento de requisitos do cliente;
Estabelecimento de requisitos do produto e componentes do produto, coerentes
com os requisitos do cliente.

A rea de processo Desenvolvimento de Requisitos relaciona-se com outras reas de
processo que esto envolvidas com as suas prticas ou sub-prticas. As reas de processo
relacionadas com o Desenvolvimento de Requisitos so as seguintes [39]:
52
Gesto de Requisitos: gesto dos requisitos de cliente e produto, obteno de um
acordo com o fornecedor de requisitos, obteno compromissos para a
implementao dos requisitos, e manuteno da rastreabilidade;
Soluo Tcnica: modo como os resultados dos processos de desenvolvimento de
requisitos so utilizados e desenvolvimento de solues e concepes alternativas
utilizadas no aperfeioamento e derivao de requisitos;
Integrao do Produto: requisitos de interface e gesto de interfaces;
Verificao: verificao que o produto resultante cumpre os requisitos;
Validao: modo como o produto construdo vai ser validado face s necessidades
do cliente;
Gesto de Riscos: identificao e gesto de riscos relacionados com os requisitos;
Gesto de Configuraes: garantia que os trabalhos chave so controlados e
geridos.

5.2. Metas e prticas da rea de processo desenvolvimento de requisitos
Meta especfica 1: Desenvolver requisitos de cliente
Meta especfica 2: Desenvolver requisitos de produto
Meta especfica 3: Analisar e validar os requisitos

Na Tabela 12 encontram-se enumeradas as prticas relacionadas com cada uma das
metas, genrica e especficas [36].

53
Tabela 12 Metas e Prticas necessrias para atingir o nvel de capacidade 2 na rea de processo Desenvolvimento de
requisitos
META PRTICAS
Meta Especfica 1: Desenvolver
Requisitos de Cliente
Prtica especfica 1.1-1: Recolher necessidades
Prtica especfica 1.1-2: Elicitar necessidades
Prtica especfica 1.2: Desenvolver os requisitos de cliente
Requisitos de Produto
Prtica especfica 2.1: Estabelecer requisitos de produto e de
componentes de produto
Prtica especfica 2.2: Alocar requisitos de componentes de produto
Prtica especfica 2.3: Identificar requisitos de interface
Meta Especfica 3: Analisar e
Validar os Requisitos
Prtica especfica 3.1: Estabelecer conceitos operacionais e cenrios
Prtica especfica 3.2: Estabelecer uma definio da funcionalidade
requerida
Prtica especfica 3.3: Analisar os requisitos
Prtica especfica 3.4: Analisar os requisitos para alcanar o equilbrio
Prtica especfica 3.5: Validar os requisitos
metas especficas
Meta Genrica 2:
gerido

A rea de processo Desenvolvimento de Requisitos inclui trs metas especficas. A meta
especfica 1, Desenvolver os Requisitos de Cliente, aborda a definio de um conjunto de
requisitos de cliente. A meta especfica 2, Desenvolver os Requisitos do Produto, aborda a
definio de um conjunto de requisitos do produto ou componentes do produto para
utilizar na concepo dos produtos e componentes de produto. A terceira meta
especfica, Analisar e Validar os Requisitos, aborda a necessidade de anlise dos requisitos
de cliente, do produto e dos componentes do produto para definir, derivar e entender os
requisitos. As prticas especficas da terceira meta especfica destinam-se a ajudar as
prticas especficas das duas primeiras metas especficas [36].

54
A meta especfica 1, DESENVOLVER REQUISITOS DE CLIENTE, garante que as
necessidades, expectativas, limitaes e interfaces das partes interessadas so recolhidas
e traduzidas em requisitos de cliente [36].
As necessidades dos intervenientes (por exemplo: clientes, utilizadores finais,
fornecedores, testadores, ou produtores) so a base para a determinao dos requisitos
de cliente. As necessidades, expectativas, limitaes e interfaces das partes interessadas,
conceitos operacionais, e conceitos do produto so analisados, harmonizados,
aperfeioados, e elaborados para serem traduzidos num conjunto de requisitos [36].
As necessidades, expectativas, limitaes e interfaces das partes interessadas devem ser
claramente identificadas e compreendidas, sendo por isso utilizado normalmente um
processo interactivo ao longo da vida do projecto para cumprir este objectivo. Limitaes
ambientais, legais, entre outras, devero ser consideradas na criao e resoluo do
conjunto de requisitos do cliente [36].

Esta meta especfica composta por duas prticas especficas.
Prtica especfica 1.1, Elicitar Necessidades [36]:
O objectivo desta prtica elicitar as necessidades, expectativas, limitaes, e
interfaces para todas as fases do ciclo de vida do produto. A elicitao vai alm da
recolha dos requisitos, consiste em identificar proactivamente requisitos
adicionais no previstos expressamente pelos clientes. Os requisitos adicionais
devem abranger as vrias actividades do ciclo de vida do produto e os seus
impactos no produto.
Exemplos de tcnicas para elicitar as necessidades:
Demonstraes de tecnologia;
Revises intercalares do projecto;
Questionrios, entrevistas, e cenrios operacionais obtidos dos utilizadores
finais;
Tutoriais operacionais e tarefas de anlise do utilizador final;
Prottipos e modelos;
Desenvolvimento de uma funo de qualidade;
Estudos de mercado;
Teste de verses beta;
Extraco de fontes como documentos, normas, ou especificaes;
Observao dos produtos, ambientes e padres de fluxo de trabalho
existentes;
Casos de utilizao;
Anlises de casos de negcio;
Inquritos satisfao dos clientes.
55
Exemplos de origem de requisitos que podem no ser identificadas pelo cliente:
Polticas de negcio;
Normas;
Requisitos de ambiente de negcio (por exemplo, laboratrios, testes e
outras instalaes, e infra-estrutura de tecnologia de informao);
Tecnologia;
Produtos ou componentes de produto legados (reutilizar componentes de
produto).
Subprticas:
1. Envolver as partes interessadas mais relevantes utilizando mtodos para
elicitao de necessidades, expectativas, limitaes e interfaces externas.

Prtica especfica 1.2, Desenvolver os Requisitos de Cliente [36]:
O objectivo desta prtica transformar as necessidades, expectativas, limitaes e
interfaces das partes interessadas, em requisitos de cliente.
Os diversos contributos das partes interessadas relevantes devem ser
consolidados, as informaes em falta devem ser obtidas, os conflitos devem ser
resolvidos, e deve ser documentado o conjunto conhecido de requisitos de cliente.
Os requisitos de cliente podem incluir necessidades, expectativas e limitaes no
que respeita verificao e validao.
O cliente pode fornecer um conjunto de requisitos para o projecto, ou os
requisitos podem resultar de uma actividade anterior do projecto. Nestas
situaes, as necessidades do cliente podem entrar em conflito com as
necessidades, expectativas, limitaes e interfaces das partes interessadas, sendo
transformados num conjunto reconhecido de requisitos de cliente depois da
resoluo apropriada dos conflitos.
Trabalhos tpicos:
1. Requisitos de cliente;
2. Limitaes do cliente na conduo da verificao;
3. Limitaes do cliente na conduo da validao;
Subprticas:
1. Traduzir as necessidades, expectativas, limitaes e interfaces das partes
interessadas em requisitos de cliente documentados;
2. Definir as limitaes para a verificao e validao.
56
A meta especfica 2, DESENVOLVER REQUISITOS DE PRODUTO, garante que os requisitos
de cliente so aperfeioados e elaborados para desenvolver requisitos de produto e de
componente de produto [36].
Os requisitos de cliente so analisados em combinao com o desenvolvimento do
conceito operacional para obter conjuntos de requisitos mais detalhados e precisos
denominados requisitos de produto ou de componente de produto. Os requisitos de
produto e de componente de produto atendem as necessidades associadas a cada fase
do ciclo de vida do produto. Os requisitos derivados surgem a partir de limitaes,
considerao de questes implcitas, mas no explicitamente declaradas na base dos
requisitos de cliente, e outros factores introduzidos pela arquitectura seleccionada, pela
concepo, e consideraes de negcio [36].
Os requisitos so reexaminados e o conceito de produto aperfeioado. Os requisitos so
alocados s funes do produto e componentes do produto, incluindo objectos, pessoas e
processos. A rastreabilidade dos requisitos a funes, objectos, testes, questes, ou
outras entidades documentada. Assim que os componentes internos so desenvolvidos,
interfaces adicionais so definidos e requisitos de interface so estabelecidos [36].

Esta meta especfica composta por trs prticas especficas.
Prtica especfica 2.1, Estabelecer requisitos de Produto e de Componentes de
Produto [36]:
O objectivo desta prtica estabelecer e manter requisitos de produto e de
componentes de produto, baseados nos requisitos de cliente.
Os requisitos de cliente podem ser expressos nos termos do cliente e podem ser
descries no-tcnicas. Os requisitos de produto so a expresso desses
requisitos em termos tcnicos que podem ser utilizados para as decises de
concepo.
Os requisitos de produto e de componentes de produto abordam a satisfao dos
clientes, do negcio, e os objectivos do projecto e atributos associados, tais como
eficcia e acessibilidade. Os requisitos derivados abordam tambm o custo e a
performance de outras fases do ciclo de vida (por exemplo: produo, e operao)
de forma compatvel com os objectivos de negcio.
Trabalhos tpicos:
1. Requisitos derivados;
2. Requisitos de produto;
3. Requisitos de componentes de produto.
57
Subprticas:
1. Desenvolver os requisitos em termos tcnicos necessrios para a
concepo do produto e componentes de produto;
2. Derivar requisitos que resultam de decises de concepo;
3. Estabelecer e manter relaes entre os requisitos para ter em considerao
a gesto das alteraes e a alocao de requisitos.

Prtica especfica 2.2, Alocar Requisitos de Componente de Produto [36]:
O objectivo desta prtica alocar os requisitos a cada componente de produto.
Os requisitos para os componentes de produto da soluo definida incluem
alocao do desempenho do produto, limitaes de concepo, medida, forma, e
funo para cumprir os requisitos e facilitar a produo. Nos casos em que um
requisito de nvel mais elevado especifica desempenho que ser da
responsabilidade de dois ou mais componentes de produto, o desempenho deve
ser particionado para uma alocao nica a cada componente de produto como
um requisito derivado.
Trabalhos tpicos:
1. Folhas de alocao de requisitos;
2. Alocaes de requisitos provisrias;
3. Limitaes de concepo;
4. Requisitos derivados;
5. Relaes entre requisitos derivados.
Subprticas:
1. Alocar os requisitos a funes;
2. Alocar os requisitos a componentes de produto;
3. Alocar as limitaes de concepo a componentes de produto;
4. Documentar as relaes entre os requisitos alocados.
As relaes incluem dependncias em que a alterao num requisito pode afectar
outros requisitos.

Prtica especfica 2.3, Identificar Requisitos de Interface [36]:
O objectivo desta prtica identificar requisitos de interface.
58
Os requisitos de interface entre produtos ou componentes de produto
identificados na arquitectura do produto so definidos. Estes requisitos so
controlados como uma parte da integrao do produto e componentes de
produto e so uma parte integral da definio da arquitectura.
Trabalhos tpicos:
1. Requisitos de interface.
Subprticas:
1. Identificar as interfaces externas e internas ao produto (entre parties
funcionais ou objectos).
medida que a concepo prossegue, a arquitectura do produto vai
sendo alterada pelos processos da soluo tcnica, criando novas
interfaces entre os componentes de produto e os componentes externos
ao produto. As interfaces com produtos do ciclo de vida do processo
devem tambm ser identificadas. Exemplos destas interfaces incluem
interfaces com equipamento de teste, sistemas de transporte, sistemas de
suporte, e instalaes de produo.
2. Desenvolver os requisitos para as interfaces identificadas.

A meta especfica 3, ANALISAR E VALIDAR OS REQUISITOS garante que os requisitos so
analisados e validados, e desenvolvida uma definio da funcionalidade requerida [36].
As prticas especficas desta meta especfica suportam o desenvolvimento de requisitos
nas metas especficas: Desenvolver Requisitos de Cliente e Desenvolver Requisitos de
Produto [36].
As anlises so realizadas para determinar qual o impacto que o ambiente operacional
pretendido vai ter sobre a capacidade de satisfazer as necessidades, expectativas,
limitaes e interfaces das partes interessadas. Consideraes como viabilidade,
necessidades, limitaes de custo, tamanho do mercado potencial, e estratgia de
aquisio, devem ser tidas em conta, dependendo do contexto do produto. A definio da
funcionalidade requerida tambm estabelecida. Todos os modos de utilizao para o
produto especificados so considerados, e gerada uma anlise do cronograma para a
sequncia temporal crtica de funes [36].
O objectivo da anlise determinar requisitos candidatos para os conceitos do produto
que iro satisfazer as necessidades, expectativas, e limitaes das partes interessadas, e
traduzir esses conceitos em requisitos. Em paralelo com esta actividade, os parmetros
que sero utilizados para avaliar a eficcia do produto so determinados com base no
pedido do cliente e no conceito de produto preliminar.
59
Os requisitos so validados para aumentar a probabilidade do produto resultante ter a
eficcia pretendida, no ambiente de utilizao [36].

Esta meta especfica composta por cinco prticas especficas.
Prtica especfica 3.1, Estabelecer Conceitos Operacionais e Cenrios [36]:
O objectivo desta prtica estabelecer e manter conceitos operacionais e os
cenrios associados.
Um cenrio tipicamente uma sequncia de eventos que podem ocorrer na
utilizao do produto, que utilizado para tornar explcitas algumas das
necessidades das partes interessadas. Um conceito operacional para um produto
depende normalmente tanto da soluo de concepo como do cenrio. Os
conceitos operacionais so aperfeioados medida que as decises da soluo so
tomadas e so desenvolvidos requisitos de mais baixo nvel.
Os conceitos operacionais e os cenrios so evoludos para facilitar a seleco de
solues de componentes de produto que, quando implementadas, iro satisfazer
a utilizao pretendida do produto. Os conceitos operacionais e os cenrios
documentam a interaco dos componentes de produto com o ambiente,
utilizadores, e outros componentes de produto, independentemente da disciplina
de engenharia. Eles devero ser documentados para todos os modos e estados de
operaes, desenvolvimento do produto, entrega, suporte, formao, e venda.
Trabalhos tpicos:
1. Conceito operacional;
2. Conceitos de instalao, operao, manuteno e suporte do produto ou
componentes de produto;
3. Conceitos de eliminao;
4. Casos de utilizao;
5. Cenrios de cronograma;
6. Novos requisitos.
Subprticas:
1. Desenvolver conceitos operacionais e cenrios que incluem
funcionalidade, desempenho, manuteno, suporte e eliminao,
conforme o caso.
2. Definir o ambiente no qual o produto ou componente de produto ir
operar, incluindo limites e restries.
3. Rever os conceitos operacionais e cenrios para aperfeioar e descobrir
requisitos.
60
O desenvolvimento de conceitos operacionais e cenrios um processo
iterativo. As revises devem ser realizadas de forma peridica para
assegurar que esto de acordo com os requisitos.
4. Desenvolver um conceito operacional detalhado, medida que os
produtos ou componentes de produto so seleccionados, que define a
interaco do produto, do utilizador final, e do ambiente, e que satisfaz as
necessidades operacionais, de manuteno, de suporte, e de eliminao.

Prtica especfica 3.2, Estabelecer uma Definio da Funcionalidade Requerida
[36]:
O objectivo desta prtica estabelecer e manter uma definio da funcionalidade
requerida.
A definio da funcionalidade, ou anlise funcional, a descrio daquilo que o
produto se destina a fazer. A definio da funcionalidade pode incluir aces,
sequncias, entradas, sadas, ou outra informao que comunica a forma na qual o
produto ser utilizado.
Trabalhos tpicos:
1. Arquitectura funcional;
2. Diagramas de actividade e casos de utilizao;
3. Anlise orientada a objectos com identificao de servios ou mtodos.
Subprticas:
1. Analisar e quantificar a funcionalidade requerida pelos utilizadores finais;
2. Analisar os requisitos para identificar as parties lgicas ou funcionais
(por exemplo, subfunes);
3. Particionar os requisitos em grupos, com base em critrios estabelecidos
(por exemplo, funcionalidade semelhante, desempenho, ou ligao), para
facilitar e focar a anlise dos requisitos;
4. Considerar a sequncia de funes crticas, no incio do projecto e durante
o desenvolvimento do produto;
5. Alocar os requisitos de cliente a parties funcionais, objectos, pessoas,
ou elementos de suporte para suportar a sntese da soluo;
6. Alocar os requisitos funcionais e de desempenho a funes e subfunes.

61
Prtica especfica 3.3, Analisar Requisitos [36]:
O objectivo desta prtica analisar os requisitos para assegurar que so
necessrios e suficientes.
luz do conceito operacional e cenrios, os requisitos para um nvel da hierarquia
de produto so analisados para determinar se so necessrios e suficientes para
cumprir os objectivos dos nveis superiores da hierarquia do produto. Os
requisitos analisados providenciam depois a base para os requisitos mais
detalhados e precisos para os nveis mais baixos da hierarquia do produto.
medida que os requisitos so definidos, a sua relao com os requisitos de mais
alto nvel e funcionalidade definida de mais alto nvel deve ser compreendida.
Devem ser determinados os requisitos chave que iro ser utilizados para
acompanhar o progresso.
Trabalhos tpicos:
1. Relatrios de defeitos de requisitos;
2. Alteraes propostas aos requisitos para resolver os defeitos;
3. Requisitos chave;
4. Medidas de desempenho tcnico.
Subprticas:
1. Analisar as necessidades, expectativas, limitaes e interfaces externas
das partes interessadas para remover conflitos e para as organizar em
temas relacionados.
2. Analisar os requisitos para determinar se estes satisfazem os objectivos
dos requisitos de mais alto nvel.
3. Analisar os requisitos para assegurar que esto completos, viveis,
realizveis, e verificveis.
4. Identificar os requisitos chave que tm uma forte influncia no custo, na
calendarizao, na funcionalidade, no risco, ou no desempenho.
5. Identificar medidas de desempenho tcnico que sero controladas
durante o esforo de desenvolvimento.
6. Analisar os conceitos operacionais e cenrios para aperfeioar as
necessidades, expectativas, limitaes e interfaces das partes interessadas
e para descobrir novos requisitos.
Esta anlise pode resultar em conceitos operacionais e cenrios mais
detalhados, e suportar a derivao de novos requisitos.

62
Prtica especfica 3.4, Analisar Requisitos para Alcanar Equilbrio [36]:
A inteno desta prtica especfica analisar os requisitos para alcanar o
equilbrio entre as necessidades e limitaes das partes interessadas.
As necessidades e limitaes das partes interessadas podem abordar o custo,
calendrio, desempenho, funcionalidade, componentes reutilizveis, manuteno,
ou risco.
Trabalhos tpicos:
1. Avaliao de riscos relacionados com os requisitos.
Subprticas:
1. Utilizao de modelos comprovados, simulaes, e prototipagem para
analisar o equilbrio das necessidades e limitaes das partes
interessadas.
Os resultados das anlises podem ser utilizados para reduzir o custo do
produto e o risco em desenvolver o produto.
2. Realizar uma avaliao do risco nos requisitos e arquitectura funcional.
3. Examinar os conceitos do ciclo de vida do produto para impactos dos
requisitos no risco.

Prtica especfica 3.5, Validar Requisitos [36]:
O objectivo desta prtica validar os requisitos para assegurar que o desempenho
do produto resultante o esperado no ambiente do utilizador.
A validao dos requisitos executada no incio do esforo do desenvolvimento
com os utilizadores finais, de forma a obter a confiana de que os requisitos so
capazes de conduzir um desenvolvimento que resulta numa validao final com
sucesso.
Exemplos de tcnicas utilizadas para validao de requisitos:
Anlise;
Simulaes;
Prototipagem;
Demonstraes.
Trabalhos tpicos:
1. Registo de mtodos e resultados de anlise.
63
Subprticas:
1. Analisar os requisitos para determinar o risco de o desempenho do
produto resultante no ser o apropriado no ambiente do utilizador final.
2. Explorar a adequao e a plenitude dos requisitos desenvolvendo
representaes do produto (por exemplo, prottipos, simulaes,
modelos, cenrios) e obtendo um feedback sobre elas, das partes
interessadas.
3. Avaliar a concepo medida que vai amadurecendo no contexto do
ambiente de validao dos requisitos, para identificar problemas de
validao e expor as necessidades e requisitos de cliente no declarados.

O objectivo desta prtica realizar as prticas especficas do processo de
desenvolvimento de requisitos para produzir trabalhos e fornecer servios para alcanar
as metas especficas da rea de processo.

planear e executar o processo de desenvolvimento de requisitos.
Elaborao:
Esta poltica estabelece expectativas organizacionais para recolher as
necessidades das partes interessadas, formular requisitos de produto e de
componentes de produto, e analisar e validar esses requisitos.

64
de desenvolvimento de requisitos.
Elaborao:
Este plano para executar o processo de desenvolvimento de requisitos pode fazer
parte do plano do projecto, ou ser referenciado por este.

processo de desenvolvimento de requisitos, desenvolver os trabalhos e fornecer
os servios do processo.
Elaborao:
Conhecimentos especficos no domnio da aplicao, mtodos para elicitao das
necessidades das partes interessadas, e mtodos e ferramentas para especificar e
analisar requisitos de clientes, produto e componentes de produto podem ser
exigidos.


de desenvolvimento de requisitos como for necessrio.

O objectivo desta prtica colocar os trabalhos designados do processo de
desenvolvimento de requisitos em nveis adequados de controlo.
65
processo de desenvolvimento de requisitos como planeado.
Elaborao:
pessoal que possa estar afectado ou afectar o produto, assim como o processo.

O objectivo desta prtica monitorizar e controlar o processo de
desenvolvimento de requisitos face ao plano para executar o processo e tomar as
aces correctivas apropriadas.

O objectivo desta prtica avaliar objectivamente a adeso do processo de
desenvolvimento de requisitos sua descrio, normas e procedimentos, e tratar
as no conformidades.

de desenvolvimento de requisitos com elevado nvel de gesto e resolver os
problemas.
Elaborao:
As alteraes propostas aos compromissos so revistas com o nvel mais alto de
gesto para assegurar que todos os compromissos possam ser realizados.

66
5.3. Alcanar o nvel de capacidade 2 na rea de processo Desenvolvimento de
Requisitos
O CMMI define a rea de processo Desenvolvimento de Requisitos mas no descreve
como devero as organizaes proceder para a alcanar.
rea de processo Desenvolvimento de Requisitos.

De acordo com o objectivo da prtica especfica 1.1-1, Recolher necessidades, e da prtica
especfica 1.1-2, Elicitar necessidades, da rea de processo Desenvolvimento de
Requisitos, a Metatheke dever definir o seu conjunto de tcnicas de recolha e de
elicitao das necessidades das partes interessadas.
1. Tcnicas de recolha
As necessidades, expectativas e limitaes sero recolhidas atravs de interaco
directa com as partes interessadas, que devero ficar registadas nas Actas nas
reunies (Anexo A).
A Metatheke poder utilizar mtodos adicionais, como entrevistas e inquritos,
sempre que se justifique a sua necessidade.
2. Tcnicas de elicitao
A Metatheke dever elicitar as necessidades das partes interessadas atravs da
anlise das actas das reunies, da observao do sistema existente, da anlise de
caso de uso, e atravs do desenvolvimento de modelos e prottipos.

De acordo com o objectivo da prtica especfica 1.2, Desenvolver os requisitos de cliente,
da rea de processo Desenvolvimento de Requisitos, dever existir um documento de
67
requisitos para documentar as necessidades recolhidas, e uma base de dados para registo
dos requisitos.
Os requisitos iniciais (requisitos de cliente) devero ficar definidos no documento
de requisitos (Anexo B), de forma compreensvel para o cliente, juntamente com
as limitaes dos clientes na verificao e validao dos requisitos.
2. Base de dados de requisitos
Na base de dados de requisitos, dever existir um campo para distinguir os
requisitos de cliente dos requisitos de produto e de componentes de produto. Na
Metatheke esta distino pode ser feita atravs do campo Estado da base de
dados onde, por exemplo, o estado Aprovado indique que se trata de um
requisito de cliente.

A Figura 5 representa um fluxograma de implementao da meta especfica 1 da rea
de processo de Desenvolvimento de Requisitos.

68

Figura 5 Fluxograma de implementao da meta especfica 1 da rea de processo Desenvolvimento de Requisitos

De acordo com o objectivo da prtica especfica 2.1, Estabelecer requisitos de produto e
de componentes de produto, da rea de processo Desenvolvimento de Requisitos, dever
existir um documento de requisitos para a especificao detalhada dos requisitos, uma
base de dados e uma matriz de rastreabilidade dos requisitos.

69
Depois de tornar os requisitos mais detalhados e precisos, o documento de
requisitos (Anexo B) dever ser actualizado. A especificao dos requisitos dever
utilizar termos tcnicos e poder ser complementada com a adio de casos de
utilizao, ou outras formas de anlise.

Os requisitos de produto podero ser distinguidos dos requisitos de cliente
atravs do campo Estado da base de dados de requisitos dos projectos da
Metatheke sendo, por exemplo, o Incorporado o estado correspondente aos
requisitos de produto e componentes de produto.

O relacionamento entre os requisitos de cliente e os requisitos de produto poder
ser mantido na matriz de rastreabilidade que a Metatheke utiliza para os seus
projectos (Tabela 9).

De acordo com o objectivo da prtica especfica 2.2, Alocar requisitos de componentes de
produto, da rea de processo Desenvolvimento de Requisitos, a matriz de rastreabilidade
de requisitos dever permitir registar a alocao dos requisitos:
A alocao de requisitos a funes, componentes de produto e limitaes dever
ser registada na matriz de rastreabilidade de requisitos. Para isso, na matriz de
rastreabilidade de requisitos da Metatheke (Tabela 9), devero ser acrescentadas
as colunas apresentadas na Tabela 13.

Tabela 13 Colunas da matriz de rastreabilidade referentes alocao dos requisitos
Alocaes
Componentes de Produto Funes Limitaes de Anlise Limitaes de Verificao

70
De acordo com o objectivo da prtica especfica 2.3, Identificar requisitos de interface, da
rea de processo Desenvolvimento de Requisitos, dever existir uma base de dados para
registar os requisitos de interface.
Os requisitos de interface de produto podero ser identificados atravs do campo
Tipo da base de dados de requisitos dos projectos da Metatheke sendo, por
exemplo, Interface o tipo correspondente aos requisitos de interface de
produto.

A Figura 6 representa um fluxograma de implementao da meta especfica 2 da rea de
processo de Desenvolvimento de Requisitos.
71


72
De acordo com o objectivo da prtica especfica 3.1, Estabelecer conceitos operacionais e
cenrios, da rea de processo Desenvolvimento de Requisitos, dever existir para cada
projecto da Metatheke um documento de conceitos e cenrios.
1. Documento de conceitos e cenrios
O documento de Conceito de Operaes consiste numa definio de alto nvel da
funcionalidade desejada e dever ser aprovado pela gesto da Metatheke.
Os cenrios consistem numa srie de eventos que ocorrem no uso do produto,
sendo usados para tornar explcitas algumas necessidades das partes interessadas.
Na Figura 7 apresentado o que dever ser includo no Documento de Conceitos
de Operaes dos projectos da Metatheke.

ndice
Revises
Glossrio
1. Resumo
1.1. Resumo do Documento
1.2. Resumo do Sistema
2. Conceitos para o Sistema proposto
2.1. Objectivos
2.2. Polticas e Limitaes Operacionais
2.3. Descrio do Sistema Proposto
2.4. Modos de Operao
2.5. Ambiente de Utilizao e Interaco
2.6. Ambiente de Suporte
3. Cenrios Operacionais
4. Impactos
4.1. Impactos Operacionais
4.2. Impactos Organizacionais
5. Anlise do Sistema Proposto
5.1. Melhorias
5.2. Desvantagens e Limitaes
5.3. Alternativas
6. Documentos Anexos

Figura 7 Documento de Conceitos de Operaes
73
De acordo com o objectivo da prtica especfica 3.2, Estabelecer uma definio da
funcionalidade requerida, da rea de processo Desenvolvimento de Requisitos, dever ser
definida a anlise funcional dos produtos desenvolvidos pela Metatheke.
1. Anlise funcional
Na anlise funcional dever ficar a descrio do que o produto se destina a fazer.
Na anlise funcional, devero ser utilizados os cenrios estabelecidos
anteriormente e podero ser adoptadas tcnicas de modelagem orientada a
objectos, como diagramas de actividades e de casos de utilizao, para auxiliar na
definio da funcionalidade do produto.

De acordo com o objectivo da prtica especfica 3.3, Analisar os requisitos, da rea de
processo Desenvolvimento de Requisitos, devero existir relatrios de defeitos de
requisitos e relatrios das anlises efectuadas.
1. Relatrios de defeitos de requisitos
Os defeitos que surgirem na anlise dos requisitos, para verificar se atendem as
exigncias do cliente, devero ficar registados. A Figura 8 apresenta a informao
que dever ser registada nos relatrios de defeitos na Metatheke.

Defeitos
Identificao
Defeito
Identificao
Requisito
Descrio Responsvel Estado
Data
Deteco
Data
Resoluo

Figura 8 Relatrios de defeitos

A informao relacionada com os defeitos dos requisitos ficar tambm
armazenada numa base de dados.

74
2. Relatrio das anlises
A Anlise de Requisitos, para verificar se atendem as exigncias do cliente, dever
ficar registada num documento, onde sero referidas as alteraes a nvel de
requisitos que ocorreram aps a aquisio de um conhecimento mais
aprofundado dos requisitos do sistema.
As mudanas propostas nos requisitos para resolver os defeitos detectados nas
anlises devero ficar descritas no documento de alterao de requisitos (Anexo
D).

De acordo com o objectivo da prtica especfica 3.4, Analisar os requisitos para alcanar o
equilbrio, da rea de processo Desenvolvimento de Requisitos, os riscos identificados nas
anlises dos requisitos devero ficar registados.
1. Relatrio de riscos
O resultado da tarefa de alcanar o equilbrio entre os requisitos, as limitaes e
os riscos uma avaliao de riscos documentada, associada aos requisitos. A
Figura 9 apresenta a informao que dever ser registada nos relatrios de riscos
na Metatheke.

Figura 9 - Relatrios de riscos

A informao relacionada com os defeitos dos requisitos ficar tambm
armazenada numa base de dados.

De acordo com o objectivo da prtica especfica 3.5, Validar os requisitos, da rea de
processo Desenvolvimento de Requisitos, a Metatheke dever definir as tcnicas de
Riscos
Descrio Nvel Impacto Aco Responsvel rea

75
validao dos seus requisitos e registar o resultado das anlises efectuadas aos requisitos
dos seus projectos.
1. Tcnicas de validao
A Metatheke dever validar os requisitos para assegurar que o produto est de
acordo com o esperado pelo cliente. As validaes podem ocorrer em reunies
com os clientes, que devero ficar documentadas em actas (Anexo A), ou atravs
de outras tcnicas, como simulaes e prottipos.
2. Registo do mtodo e resultado das anlises
A Anlise de Requisitos dever ficar registada num documento, onde ficar
documentado qual o mtodo utilizado pela Metatheke para validar os requisitos e
qual o resultado da validao.

processo de Desenvolvimento de Requisitos.

76

77

organizacional, dever ser definida uma poltica organizacional para o desenvolvimento
de requisitos. A poltica organizacional da Metatheke ficar descrita num documento
editado pela equipa de gesto que descreve o comportamento esperado dos
trabalhadores no processo de desenvolvimento de requisitos [40].
No Anexo J [41] apresentada a poltica de desenvolvimento de requisitos, que ser
seguida pela Metatheke nos seus projectos.

definido um plano para o desenvolvimento de requisitos. Neste plano devero constar
todas as tarefas necessrias para a execuo do processo de desenvolvimento dos
requisitos, revisto e acordado por todas as partes relevantes [40].
A descrio do processo de desenvolvimento de requisitos definido;
O calendrio no qual o processo de desenvolvimento de requisitos deve ser
executado;
Os recursos necessrios para a execuo do processo de desenvolvimento de
requisitos, incluindo financiamento, pessoas e ferramentas;
Formao necessria;
processo de desenvolvimento de requisitos, seus trabalhos e servios;
78
Na Figura 11 apresentado o que dever ser includo no plano de Desenvolvimento de
Requisitos da Metatheke.

Figura 11 Plano de Desenvolvimento de Requisitos [39]

disponibilizados os recursos necessrios para o Desenvolvimento de Requisitos, tais
como:
Oramento adequado
ndice
Revises
Glossrio
1.0 Introduo
2.0 Objectivo
2.1 mbito
2.2 Definies
2.3 Objectivos
3.0 Gesto
3.1 Organizao
3.2 Tarefas
3.3.1 Gesto
3.3.5 Cliente
3.4 Plano
3.5 Recursos
3.6 Formaes
4.0 Processo de Desenvolvimento de Requisitos de Software
4.1 Elicitao de requisitos
4.2 Especificao de Requisitos
4.3 Anlise de Requisitos
4.4 Verificao de Requisitos
8.0 Desenvolvimento da Especificao de Requisitos de Software
Documentos Anexos

79
sala de reunies
sala para equipa de requisitos
Elicitao de requisitos
Especificao de requisitos
Anlise de requisitos
Verificao de requisitos
Ferramentas de simulao e modelao de sistemas
Ferramentas de especificao de requisitos
Ferramentas de definio de cenrios

atribuio de responsabilidades dever ser feita para o processo de desenvolvimento de
requisitos.
A Metatheke dever atribuir aos membros envolvidos neste processo as seguintes
funes:
Elicitao das necessidades, expectativas e limitaes das partes interessadas;
Anlise e manuteno do documento de requisitos;
Manuteno da rastreabilidade entre os requisitos e as necessidades das partes
interessadas;
Manter os requisitos sempre actualizados.

de desenvolvimento de requisitos da Metatheke. Nesta tabela, para cada equipa
envolvida no processo de desenvolvimento de requisitos, indicado o nome e o contacto
de cada membro, juntamente com a indicao da sua responsabilidade.

Tabela 14 Tabela de atribuio de responsabilidades para o Desenvolvimento de Requisitos
Equipa Nome
Administrao
Pedro Almeida
Marco Fernandes

Gesto
Pedro Almeida

Qualidade
Joana Martins

Gesto
Projectos
Sara Martins
Pedro Pais

Requisitos
Joo Oliveira
Marco Fernandes

No organigrama da empresa (
hierarquia das equipas envolvidas no processo de Des
Figura 12 Seco do organigrama
Equipa Gesto
Pedro Almeida
Tabela de atribuio de responsabilidades para o Desenvolvimento de Requisitos
Contacto Responsabilidade


dqualidade@metatheke.com Director de Qualidade

gprojectos@metatheke.com Gestor de Projectos
gprojectosint@metatheke.com Gestor de Projectos Internacionais

tinformatica@metatheke.com Tcnico Superior de Informtica

No organigrama da empresa (Figura 12) dever ficar claramente representada a
hierarquia das equipas envolvidas no processo de Desenvolvimento de Requisitos.
do organigrama correspondente ao Desenvolvimento de Requisitos
Administrao
Pedro Almeida
Marco Fernandes
Equipa Qualidade
Joana Martins
Equipa Engenharia
Gesto Projectos
Sara Martins
Pedro Pais
Requisitos
Joo Oliveira
Marco Fernandes
Tabela de atribuio de responsabilidades para o Desenvolvimento de Requisitos
Responsabilidade
Director de Qualidade
Gestor de Projectos
Gestor de Projectos Internacionais
Superior de Informtica
) dever ficar claramente representada a
nvolvimento de Requisitos.

de Requisitos
Requisitos
Joo Oliveira
Marco Fernandes
81
De acordo com o objectivo da prtica genrica 2.5, Formar pessoas, dever existir
formao para todas as pessoas envolvidas no processo de desenvolvimento de
requisitos.
Elicitao de requisitos;
Especificao de requisitos;
Anlise e modelao de requisitos;
Gesto de configuraes;
Negociao e resoluo de conflitos.
A Metatheke dever definir o modelo e regras das formaes de desenvolvimento de
requisitos. A ttulo de exemplo, todos os envolvidos no processo devero participar em 2
formaes por ano, sendo que cada um destes dever escolher as formaes mais
adequadas com a sua funo, e esta escolha dever ser aprovada pela gesto.
Nome da formao;
Local da formao;
Data da formao;
Contedo da formao;
informao para cada trabalhador envolvido no desenvolvimento de requisitos:
Nome da formao;
Local da formao;
Data da formao;
82
Contedo da formao;

dever gerir configuraes para o Desenvolvimento de Requisitos.
O objectivo da gesto da configurao estabelecer e manter a integridade dos
requisitos ao longo do ciclo de vida do projecto, evitando que verses corrigidas sejam
perdidas. Todas as modificaes nos artefactos necessrios para o processo de
desenvolvimento de requisitos (documento de requisitos, anlise funcional, conceito
operacional) sero organizadas e registadas numa base de dados, com a seguinte
informao:
modificao (por exemplo: Documento de Conceitos de Operao);
modificao (por exemplo: id do documento de conceitos em questo);
Dever ser atribudo a um membro da equipa de requisitos a funo de assegurar a
integralidade e manuteno dos artefactos.

interessadas, a Metatheke dever identificar e envolver as partes relevantes no
desenvolvimento de requisitos. Para isso dever [42]:
Nas actas das reunies de desenvolvimento de requisitos indicar quais as partes
interessadas que participaram na reunio e incluir todos os itens de aco
atribudos s partes interessadas;
Nos documentos de requisitos, anlise funcional e documento de conceito
operacional incluir os nomes das partes interessadas envolvidas;
83
Estabelecimento dos casos de utilizao e cenrios;
Estabelecimento dos requisitos de produto e de componentes de produto;
Reviso e avaliao da adequao dos requisitos.

desenvolvimento dos requisitos para um projecto da Metatheke.

Tabela 15 Tabela de identificao das partes relevantes no processo de desenvolvimento de requisitos
Papel Nome
Requisitos
Joo Oliveira
Marco Fernandes

Metatheke dever monitorizar e controlar o desenvolvimento dos requisitos.
[36], [40]:
Medio da volatilidade dos requisitos (percentagem de alteraes aos
requisitos);
Planeamento para a especificao de requisitos;
Planeamento para a anlise de requisitos;
Recolha e anlise de medidas de desempenho face ao plano de desenvolvimento
de requisitos;
Reviso do cumprimento e dos resultados do processo de desenvolvimento de
requisitos face ao planeado;
Tomar aces correctivas quando os objectivos do desenvolvimento de requisitos
no esto a ser satisfeitos, quando os problemas esto identificados, ou quando o
progresso difere significativamente do plano [43]:
84
alteraes;
Aplicar recursos extra para a definio de requisitos se o conjunto de
requisitos para o produto no estiver definido;
O desenvolvimento dos requisitos dever ser analisado em reunies semanais de controlo
do projecto.
Contacto do Responsvel de cada uma das reas envolvidas no desenvolvimento
de requisitos, indicando:
rea;
Responsvel;
Resumo e estado de todas as actividades de desenvolvimento de requisitos,
indicando:
rea;
Actividade;
Itens de aco relacionados com o desenvolvimento de requisitos, indicando:
Aco;
Data alvo da aco.

85
Metatheke dever ser analisada a aderncia ao processo de desenvolvimento de
requisitos.
O processo de desenvolvimento de requisitos implementado como planeado?
O processo de desenvolvimento de requisitos planeado satisfaz os requisitos e
objectivos?
Os resultados de seguir o processo de desenvolvimento de requisitos satisfazem
os seus requisitos?

nvel, a Metatheke dever rever o estado do Desenvolvimento de Requisitos com elevado
nvel de gesto. Para isso, semanalmente dever ser efectuada uma reunio de gesto,
para a reviso das actividades, estado, e resultados do processo de desenvolvimento de
requisitos com um nvel alto de gesto e resolver todas as questes existentes.
auditorias, relatrios de falhas, e pontos de situao semanais do processo de

87
6. rea de processo Soluo Tcnica
O objectivo da Soluo Tcnica projectar (desenhar), desenvolver e implementar
solues para os requisitos, envolvendo produtos, componentes de produto, e produtos
do ciclo de vida do processo, individualmente ou combinados.
A rea de processo Soluo Tcnica aplica-se a qualquer nvel da arquitectura do produto
e a todos os produtos, componentes de produto, e produtos do ciclo de vida do processo.
Esta rea de processo foca-se em:
Avaliar e seleccionar solues que potencialmente satisfazem um conjunto
apropriado de requisitos alocados;
Desenvolver projectos (desenhos) detalhados para as solues seleccionadas, isto
, contendo toda a informao necessria para produo, cdigo, ou
implementao do projecto como um produto ou componente de produto.
Tipicamente, estas actividades suportam-se interactivamente. Um determinado nvel de
desenho, por vezes bastante detalhado, pode ser necessrio para seleccionar solues.
Prottipos ou pilotos podem ser utilizados como uma forma de adquirir o conhecimento
suficiente para desenvolver um pacote de dados tcnicos ou um conjunto completo de
requisitos.
A Soluo Tcnica especifica prticas aplicadas no s ao produto e componentes de
produto mas tambm aos produtos do ciclo de vida do processo. Os produtos do ciclo de
vida do processo so desenvolvidos de acordo com o produto e componentes de produto.
Este desenvolvimento pode incluir a seleco e adopo de processos existentes, assim
como o desenvolvimento de novos processos.
Os processos associados com a rea de Soluo Tcnica recebem os requisitos de produto
e componentes de produto dos processos da Gesto de Requisitos. Para a manuteno
ou sustentao do produto, os requisitos que necessitam de aces de manuteno ou de
ser redesenhados podem ser conduzidos pelas necessidades do utilizador ou defeitos
latentes nos componentes de produto. Novos requisitos podem surgir de alteraes no
ambiente de operao. Estes requisitos podem surgir durante a verificao do(s)
produto(s) onde o desempenho actual comparado com o desempenho especificado.
[39].

88
A rea de processo Soluo Tcnica relaciona-se com outras reas de processo que esto
envolvidas com as suas prticas ou sub-prticas. As reas de processo relacionadas com a
Soluo Tcnica so as seguintes [39]:
Gesto de Requisitos: gesto dos requisitos de cliente e produto, obteno de um
acordo com o fornecedor de requisitos, obteno de compromissos para a
implementao dos requisitos, e manuteno da rastreabilidade;
Verificao: verificao que o produto resultante cumpre os requisitos;
Desenvolvimento de Requisitos: transformao das necessidades dos interessados
em requisitos para o produto e deciso de como alocar ou distribuir requisitos
pelos componentes do produto;
Anlise de Deciso e Resoluo: anlise de possveis solues utilizando um
processo de avaliao formal que avalia as alternativas identificadas face aos
critrios estabelecidos;
Inovao e Desenvolvimento Organizacional: seleco e desenvolvimento
incremental e melhorias inovadoras que melhoram os processos e as tecnologias
da empresa.

6.2. Metas e prticas da rea de processo soluo tcnica
Meta especfica 1: Seleccionar solues de componentes de produto
Meta especfica 2: Desenvolver o projecto
Meta especfica 3: Implementar o projecto do produto

Na Tabela 16 encontram-se enumeradas as prticas relacionadas com cada uma das
metas, genricas e especficas [37].

89
Tabela 16 Metas e Prticas necessrias para atingir o nvel de capacidade 2 na rea de processo Soluo Tcnica
META PRTICAS
Meta Especfica 1: Seleccionar
solues de componentes de
produto
Prtica especfica 1.1: Desenvolver solues alternativas e critrios de
seleco
Prtica especfica 1.2: Seleccionar solues de componentes de produto
o projecto
Prtica especfica 2.1: Projectar o produto ou componente de produto
Prtica especfica 2.2: Estabelecer um pacote de dados tcnicos
Prtica especfica 2.3: Projectar os interfaces utilizando critrios
Prtica especfica 2.4: Executar anlises de construo, compra, ou
reutilizao
Meta Especfica 3: Implementar
o projecto do produto
Prtica especfica 3.1: Implementar o projecto
Prtica especfica 3.2: Desenvolver a documentao de suporte do
produto
metas especficas
Meta Genrica 2:
gerido

A rea de processo Soluo Tcnica inclui trs metas especficas.
A meta especfica 1, SELECCIONAR SOLUES DE COMPONENTES DE PRODUTO, garante
que as solues de produtos ou componentes de produto so seleccionadas de solues
alternativas.
As solues alternativas e os seus valores relativos so considerados antecipadamente
para seleccionar uma soluo. Requisitos chave, questes de desenho e restries so
estabelecidas para serem utilizados na anlise de solues alternativas. As caractersticas
arquitecturais que fornecem uma base para uma melhoria e evoluo dos produtos
devem ser consideradas. considerada a possvel utilizao de componentes de produto
j existentes no mercado, Commercial Off-The-Shelf Software (COTS), tendo em
considerao o custo, calendrio, desempenho, e risco. Estas alternativas COTS podem
ser utilizadas com ou sem modificaes. Por vezes estes itens podem requerer
90
modificaes em aspectos como interfaces ou uma customizao de algumas das
caractersticas para melhor alcanar os requisitos do produto.
O facto de um projecto ser escolhido depois de comparado e avaliado com solues
alternativas, um indicador de um bom processo de projecto. Nas escolhas do projecto
so abordadas, tipicamente, decises na arquitectura, desenvolvimento de costumizao
versus mercado, e modularizao de componentes de produto. Algumas destas decises
podem necessitar de um processo de avaliao formal.
No caso geral, as solues so definidas como um conjunto, isto , quando se define a
camada seguinte de componentes de produto, estabelecida a soluo para cada um dos
componentes de produto do conjunto. As solues alternativas no so apenas formas
diferentes de abordagem dos mesmos requisitos, mas tambm reflectem uma alocao
diferente dos requisitos entre os componentes de produto. O objectivo optimizar o
conjunto como um todo e no as peas individuais. Dever existir uma interaco
significativa com os processos associados com a rea de processo Desenvolvimento de
Requisitos para suportar as alocaes provisrias para os componentes de produto at
ser seleccionado um conjunto soluo e as alocaes finais serem estabelecidas.
Os produtos do ciclo de vida do processo esto entre as solues de componente de
produto que so seleccionadas de solues alternativas. Exemplos desses processos so
os processos de produo, entrega, e suporte [37].
Prtica especfica 1.1, Desenvolver Solues Alternativas e Critrios de Seleco
[37]:
O objectivo desta prtica desenvolver solues alternativas e critrios de
seleco.
As solues alternativas precisam de ser identificadas e analisadas para permitir a
seleco de uma soluo equilibrada em termos de custo, calendrio, e
desempenho. Estas solues so baseadas nas arquitecturas propostas do
produto que abordam as qualidades crticas do produto e alcanam um espao de
desenho de solues viveis. Prticas especficas associadas com a meta especfica
Desenvolver o Projecto disponibilizam mais informao sobre o desenvolvimento
de arquitecturas potenciais que podem ser incorporadas em solues alternativas
para o produto.
As solues alternativas envolvem frequentemente alocaes alternativas de
requisitos em diferentes componentes de produto. Estas solues alternativas
podem tambm incluir a utilizao de solues COTS na arquitectura do produto.
Os processos associados com a rea de processo Desenvolvimento de Requisitos
devero ser empregues para se realizar uma alocao provisria de requisitos
mais completa e robusta para as solues alternativas.
91
As solues alternativas atingem custos, calendrio, e desempenho aceitveis. Os
requisitos de componentes de produto so recebidos e utilizados juntamente com
o projecto, limitaes, e critrios para desenvolver as solues alternativas. Os
critrios de seleco vo tipicamente enderear custos (por exemplo: tempo,
pessoas, e dinheiro), benefcios (por exemplo: desempenho, capacidade, e
eficcia), e riscos (por exemplo: tcnicos, custos, e de calendrio).
Consideraes para solues alternativas e critrios de seleco incluem:
Custo do desenvolvimento, produo, aquisio, manuteno, e suporte,
entre outros;
Desempenho;
Complexidade do componente de produto e produtos do ciclo de vida do
processo;
Robustez da operao do produto e condies de utilizao, modos de
operao, ambientes, e variaes nos produtos do ciclo de vida do
processo;
Expanso e crescimento do produto;
Limitaes tecnolgicas;
Sensibilidade para mtodos de construo e materiais;
Riscos;
Evoluo dos requisitos e tecnologia;
Remoo;
Capacidades e limitaes dos utilizadores finais e operadores;
Caractersticas dos produtos COTS;
As consideraes apresentadas so um conjunto bsico; as organizaes devero
desenvolver critrios para diminuir a lista de alternativas que sejam consistentes
com os seus objectivos de negcio. Os critrios utilizados em seleces das
solues finais devem fornecer uma aproximao equilibrada para os custos,
benefcios, e riscos.
Trabalhos tpicos:
1. Critrios de seleco para as solues alternativas;
2. Relatrios de avaliao de novas tecnologias;
3. Solues alternativas;
4. Critrios de seleco para a seleco final;
5. Relatrios de avaliao de produtos COTS.
Subprticas:
1. Identificar critrios para seleccionar um conjunto de solues alternativas
para considerao;
2. Identificar tecnologias actualmente em uso e novas tecnologias de produto
com vantagens competitivas;
92
O projecto dever identificar as tecnologias aplicadas aos produtos e
processos correntes e monitorizar o progresso das tecnologias
actualmente em uso ao longo da vida do projecto. O projecto dever
tambm identificar, seleccionar, avaliar, e investir em novas tecnologias
para alcanar vantagens competitivas. As solues alternativas podem
incluir novas tecnologias desenvolvidas, incluir a aplicao de tecnologias
amadurecidas em diferentes aplicaes ou manter os mtodos correntes.
3. Identificar produtos COTS candidatos que satisfazem os requisitos;
Estes requisitos incluem:
Funcionalidade, desempenho, qualidade, e fiabilidade;
Termos e condies de garantias para os produtos;
Riscos;
Responsabilidades dos fornecedores para manuteno contnua e
suporte dos produtos.
4. Gerar solues alternativas;
5. Obter uma alocao completa dos requisitos para cada alternativa;
6. Desenvolver os critrios para seleccionar a melhor soluo alternativa.
Devero ser includos critrios que abordam as questes de desenho para
a vida do produto, assim como a facilidade de inserir novas tecnologias ou
a habilidade para melhor tirar partido de produtos comerciais. Exemplos
incluem critrios relacionados com conceitos de desenho aberto ou
arquitectura aberta para as alternativas serem avaliadas.

Prtica especfica 1.2, Seleccionar Solues de Componentes de Produto [37]:
O objectivo desta prtica seleccionar as solues de componentes de produto
que melhor satisfazem os critrios estabelecidos.
A seleco dos componentes de produto que melhor satisfazem os critrios
estabelece a alocao dos requisitos aos componentes de produto. Os requisitos
de mais baixo nvel so gerados a partir das alternativas seleccionadas e utilizados
para desenvolver o desenho dos componentes de produto. Os requisitos de
interface entre os componentes de produto so descritos, em primeiro lugar
funcionalmente. As descries de interfaces fsicas so includas na documentao
para interfaces para itens e actividades externas ao produto.
A descrio das solues e a razo para a seleco so documentadas. A
documentao evolui ao longo do desenvolvimento medida que as solues e os
desenhos detalhados so desenvolvidos. A manuteno de um registo da razo
crtica para a tomada de deciso seguinte.
Trabalhos tpicos:
1. Decises e razo da seleco dos componentes de produto;
93
2. Relaes documentadas entre requisitos e componentes de produto;
3. Solues, avaliaes e razo documentadas.
Subprticas:
1. Avaliar cada soluo alternativa ou conjunto de solues alternativas face
aos critrios de seleco estabelecidos no contexto dos conceitos de
operao e cenrios.
Desenvolver cenrios temporais para a operao do produto e interaco
com o utilizador para cada soluo alternativa.
2. Com base na avaliao de alternativas, avaliar a adequao dos critrios
de seleco e actualizar esses critrios se necessrio.
3. Identificar e resolver questes com as solues alternativas e requisitos.
4. Seleccionar o melhor conjunto de solues alternativas que satisfaz os
critrios de seleco estabelecidos.
5. Estabelecer os requisitos associados com o conjunto de alternativas
seleccionado e o conjunto de requisitos alocados a esses componentes de
produto.
6. Identificar as solues de componentes de produto que sero reutilizadas
ou adquiridas.
7. Estabelecer e manter a documentao das solues, avaliaes, e razo
das escolhas efectuadas.

A meta especfica 2, DESENVOLVER O PROJECTO, indica que os projectos de produtos ou
componentes de produto devem disponibilizar um contedo apropriado no apenas para
a implementao, mas tambm para as restantes fases do ciclo de vida do produto, como
modificao, reaquisio, manuteno, sustentao, e instalao. A documentao de
projecto fornece uma referncia para um entendimento mtuo do projecto pelas partes
interessadas relevantes e suporta a alterao de caractersticas para o projecto durante o
desenvolvimento e nas fases seguintes do ciclo de vida do projecto. A descrio completa
do desenho deve ser documentada num pacote de dados tcnicos que inclui um conjunto
completo de caractersticas e parmetros incluindo forma, funo, interface,
caractersticas do processo de produo, entre outros parmetros. As normas de projecto
estabelecidas (por exemplo: checklists, templates, e estruturas) formam a base para
atingir um elevado grau de definio e perfeio na documentao do desenho [37].
Esta meta especfica composta por quatro prticas especficas.
Prtica especfica 2.1, Projectar o Produto ou Componente de Produto [37].
O objectivo desta prtica desenvolver um projecto para o produto ou
componentes de produto.
94
O projecto do produto composto por duas fases, as quais podem coincidir
durante a execuo: desenho preliminar e desenho detalhado. O desenho
preliminar estabelece as capacidades do produto e a arquitectura do produto,
incluindo as parties do produto, identificaes de componentes de produto,
estados e modos do sistema, interfaces entre os componentes mais importantes,
e interfaces de produtos externos. O desenho detalhado define, de forma
completa, a estrutura e capacidades dos componentes de produto.
A definio da arquitectura conduzida a partir de um conjunto de requisitos
arquitecturais desenvolvidos durante os processos de desenvolvimento de
requisitos. Esses requisitos expressam os pontos de qualidades e desempenho que
so crticos para o sucesso do produto. A arquitectura define os elementos
estruturais e mecanismos de coordenao que satisfazem directamente os
requisitos ou suportam a obteno dos requisitos medida que os detalhes do
desenho do produto so estabelecidos. As arquitecturas podem incluir normas e
regras de desenho que regulam o desenvolvimento dos componentes de produto
e as suas interfaces, assim como um guia para auxiliar os programadores do
produto. As prticas especficas na meta especfica Seleccionar as Solues de
Componente de Produto contm mais informao sobre a utilizao das
arquitecturas do produto como uma base para as solues alternativas.
Os responsveis pela arquitectura desenvolvem um modelo do produto, decidindo
sobre a alocao dos requisitos aos componentes de produto. Mltiplas
arquitecturas, que suportam as diferentes solues alternativas, podem ser
desenvolvidas e analisadas para determinar vantagens e desvantagens, no
contexto dos requisitos arquitecturais.
Os conceitos operacionais e os cenrios so utilizados para gerar casos de
utilizao e cenrios de qualidade que so utilizados para aperfeioar a
arquitectura. So tambm utilizados como uma medida para avaliar a adequao
da arquitectura durante avaliaes da arquitectura, conduzidas periodicamente ao
longo do desenho do produto.
Exemplos de tarefas de definio da arquitectura:
Estabelecer as relaes estruturais de parties e regras relacionadas com
interfaces entre elementos dentro de parties, e entre diferentes
parties;
Identificar as interfaces internas mais importantes e todas as interfaces
externas;
Identificar os componentes de produto e interfaces entre eles;
Definir mecanismos de coordenao (por exemplo: para o software e
hardware);
Estabelecer capacidades de infra-estrutura e servios;
Desenvolver templates ou classes e estruturas de componentes de
produto;
95
Estabelecer regras de desenho e autoridade para tomada de decises;
Definir um modelo de processo/thread;
Definir o desenvolvimento fsico de software para hardware;
Identificar propostas de reutilizao e fontes mais importantes.
Durante o projecto detalhado, os detalhes da arquitectura de produto so
finalizados, os componentes de produto so definidos de uma forma completa, e
as interfaces so totalmente caracterizadas. Os responsveis pelo desenho podem
avaliar a utilizao de produtos legados ou COTS para os componentes de
produto. medida que o desenho amadurece, os requisitos atribudos aos
componentes de produto de baixo nvel so monitorizados para assegurar que
sero satisfeitos.
O projecto detalhado foca-se no desenvolvimento de componentes de produto de
software. A estrutura interna dos componentes de produto definida, so
gerados esquemas de dados, desenvolvidos algoritmos, e estabelecidas heursticas
para as capacidades dos componentes de produto que satisfazem os requisitos
alocados.
Trabalhos tpicos:
1. Arquitectura do produto;
2. Projectos de componente de produto.
Subprticas:
1. Estabelecer e manter critrios para avaliao do projecto.
Exemplos de atributos, em adio do desempenho esperado, para os
quais os critrios de desenho devem ser estabelecidos:
Modular;
Claro;
Simples;
Fcil manuteno;
Verificvel;
Porttil;
Confivel;
Preciso;
Seguro;
Expansvel;
Utilizvel.
2. Identificar, desenvolver, ou adquirir os mtodos de projecto apropriados
para o produto.
Os mtodos de projecto eficazes podem incorporar um conjunto alargado
de actividades, ferramentas, e tcnicas descritivas. Se um determinado
mtodo eficaz ou no depende da situao, e tambm da assistncia
dada ao responsvel pelo desenho, e do custo da eficcia da assistncia.
96
Os mtodos que utilizam ferramentas para garantir que o projecto ir
englobar todos os atributos necessrios para implementar o projecto do
componente de produto podem ser bastante eficazes.
Exemplos de tcnicas e mtodos que facilitam um projecto eficaz:
Prottipos;
Modelos estruturais;
Desenho orientado a objectos;
Anlise de sistemas essenciais;
Modelos de relao entre entidades;
Reutilizao de projectos;
Padres de projecto.
3. Garantir que o projecto adere s normas e critrios aplicveis de projecto.
Exemplos de normas de projecto:
Normas de interface entre operadores;
Cenrios de teste;
Normas de segurana;
Limitaes de projecto (por exemplo: compatibilidade
electromagntica, integridade de sinal, e ambientais);
Limitaes de produo;
Tolerncia de projecto;
Normas de peas (por exemplo: restos e desperdcios de produo.
4. Garantir que o projecto adere aos requisitos alocados.
Os componentes de produto COTS identificados devem ser tidos em
conta. Por exemplo, a colocao de componentes de produto existentes
na arquitectura do produto pode modificar os requisitos e a alocao dos
requisitos.
5. Documentar o projecto.

Prtica especfica 2.2, Estabelecer um Pacote de Dados Tcnicos [37]:
O objectivo desta prtica estabelecer e manter um pacote de dados tcnicos.
Um pacote de dados tcnicos fornece ao programador uma descrio
compreensvel do produto ou componente de produto, medida que este
desenvolvido. Este pacote fornece tambm flexibilidade de aquisio numa
variedade de circunstncias, como a contratao com base no desempenho.
O projecto registado num pacote de dados tcnicos, criado durante o projecto
preliminar para documentar a definio da arquitectura. Este pacote mantido ao
longo da vida do produto para registo dos detalhes essenciais do projecto do
produto. O pacote de dados tcnicos fornece a descrio do produto ou
componente de produto que suporta uma estratgia de aquisio,
implementao, produo, engenharia, e fases de suporte logstico do ciclo de
vida do produto. A descrio inclu a definio da configurao e procedimentos
97
do projecto necessrios para garantir um desempenho adequado do produto ou
componente de produto. Inclui todos os dados tcnicos aplicveis, como
desenhos, listas associadas, especificaes, descries do desenho, base de dados
do projecto, normas, requisitos de desempenho, previses de garantia de
qualidade, e detalhes de empacotamento. O pacote de dados tcnicos inclui uma
descrio da soluo alternativa seleccionada que foi escolhida para
implementao.
Um pacote de dados tcnicos dever incluir o seguinte, quando apropriado ao tipo
de produto e componente de produto:
Descrio da arquitectura do produto;
Requisitos alocados;
Descries de componentes de produto;
Descries dos produtos do ciclo de vida do processo, caso no estejam
descritas como componentes de produto separados;
Caractersticas chave do produto;
Caractersticas e limitaes fsicas requeridas;
Requisitos de interface;
Requisitos de materiais (propostas de material e caractersticas do
material);
Requisitos de fabricao e produo;
Critrios de verificao utilizados para garantir que os requisitos foram
alcanados;
Condies de utilizao (ambientes) e cenrios de utilizao/operao,
modos e estados para as operaes, suporte, formao, produo,
remoo, e verificaes ao longo da vida do produto;
Razo para decises e caractersticas (requisitos, alocao de requisitos, e
escolhas do projecto).
Uma vez que as descries do desenho podem envolver uma grande quantidade
de dados e podem ser cruciais para o sucesso do desenvolvimento dos
componentes de produto, aconselhvel o estabelecimento de critrios para
organizar os dados e para seleccionar o contedo dos dados. particularmente
til utilizar a arquitectura do produto como um meio de organizao destes dados
e perspectivas que so claros e relevantes para uma questo ou uma caracterstica
de interesse. Estas perspectivas incluem:
Clientes;
Requisitos;
Ambiente;
Funcional;
Lgica;
Segurana;
Dados;
Estados/Modos;
98
Construo;
Gesto.
Trabalhos tpicos:
1. Pacote de dados tcnicos.
Subprticas:
1. Determinar o nmero de nveis de desenho e o nvel apropriado de
documentao para cada nvel de desenho.
Determinar o nmero de nveis de componentes de produto (por exemplo:
subsistema, item de configurao de hardware, placa de circuito, item de
configurao de software do computador, componente de produto de
software do computador, e unidade de software do computador) que
requer documentao e rastreabilidade dos requisitos, importante para
gerir os custos de documentao e para suportar os planos de integrao e
verificao.
2. Descries detalhadas do projecto base dos requisitos alocados de
componentes de produto, arquitectura, e nveis mais elevados de desenho;
3. Documentar o projecto no pacote de dados tcnicos;
4. Documentar a razo para as decises chave tomadas ou definidas;
5. Reformular o pacote de dados tcnicos se necessrio.

Prtica especfica 2.3, Projectar os Interfaces Utilizando os Critrios [37]:
O objectivo desta prtica desenhar as interfaces de componentes de produto
utilizando os critrios estabelecidos.
Os projectos de interface incluem:
Origem;
Destino;
Estmulos e caractersticas de dados para o software;
Caractersticas elctricas, mecnicas, e funcionais para o hardware;
Linhas de servio de comunicao.
Os critrios para as interfaces reflectem normalmente os parmetros crticos que
devem ser definidos, ou pelo menos investigados, para comprovar a sua
aplicabilidade.
Trabalhos tpicos:
1. Especificaes de projecto de interface;
99
2. Documentos de controlo de interface;
3. Critrios de especificao de interface;
4. Razo para o projecto de interface seleccionado.
Subprticas:
1. Definir os critrios de interface;
2. Identificar as interfaces associadas a outros componentes de produto;
3. Identificar as interfaces associadas com itens externos;
4. Identificar as interfaces entre componentes de produto e os processos
relacionados com o ciclo de vida do projecto;
5. Aplicar os critrios aos projectos alternativos de interfaces;
6. Documentar os projectos de interface seleccionados e a razo para a
seleco.

Prtica especfica 2.4, Executar Anlises de Construo, Compra, ou Reutilizao
[37]:
O objectivo desta prtica avaliar se os componentes de produto devem ser
desenvolvidos, adquiridos, ou reutilizados com base nos critrios estabelecidos.
A determinao de quais os produtos ou componentes de produto que sero
adquiridos referida frequentemente como anlise de construir ou comprar.
baseada na anlise das necessidades do projecto. Esta anlise inicia-se no incio do
projecto, durante a primeira iterao do desenho, continua durante o processo de
desenho, e termina com a deciso de desenvolver, adquirir, ou reutilizar o
produto.
Factores que afectam a deciso de construir ou comprar:
Funes que os produtos iro fornecem e como estas funes vo ajustar-
se ao projecto;
Recursos e competncias do projecto disponveis;
Custos de aquisio versus desenvolver internamente;
Datas crticas de entrega e integrao;
Alianas estratgicas de negcio, incluindo requisitos de alto nvel de
negcio;
Pesquisas de mercado de produtos disponveis, incluindo produtos COTS;
Funcionalidade e qualidade dos produtos disponveis;
Competncias e capacidades de potenciais fornecedores;
Impacto em competncias essenciais;
Licenas, garantias, responsabilidades, e limitaes associadas com os
produtos que so adquiridos;
Disponibilidade do produto;
100
Questes de propriedade;
Reduo de riscos.
A deciso de construir ou comprar pode ser conduzida utilizando-se uma
abordagem de avaliao formal.
Quando a opo adquirir um componente de produto, os requisitos so
utilizados para estabelecer um acordo com o fornecedor.
Trabalhos tpicos:
1. Critrios para reutilizao de projectos e componentes de produto;
2. Anlises de construir ou comprar;
3. Orientaes para a escolha de componentes de produto COTS;
Subprticas:
1. Desenvolver critrios para a reutilizao de desenhos de componentes de
produto;
2. Analisar projectos para determinar se os componentes de produto devem
ser desenvolvidos, reutilizados, ou adquiridos;
3. Analisar implicaes para a manuteno quando se considera itens
adquiridos ou no que no se desenvolvem (por exemplo: COTS, e
reutilizveis);
Exemplos de implicaes para a manuteno:
Compatibilidade com verses futuras de produtos COTS;
Gesto de configurao de mudanas dos vendedores;
Defeitos nos itens que no se desenvolvem, e sua resoluo;
Obsolescncia no planeada.

A meta especfica 3, IMPLEMENTAR O PROJECTO DO PRODUTO garante que os
componentes de produto, e a documentao de suporte associada, so implementados a
partir do seu projecto.
Os componentes de produto so implementados a partir dos seus projectos, pelas
prticas especficas na meta especfica Implementar o Projecto. A implementao inclui
normalmente testes unitrios para os componentes de produto antes de os enviar para
integrao do produto e desenvolver a documentao para o utilizador final [37].

101
Prtica especfica 3.1, Implementar o Projecto [37]:
O objectivo desta prtica implementar os projectos dos componentes de
produto.
Uma vez concludo o projecto, ser implementado como um componente de
produto. As caractersticas dessa implementao dependem do tipo de
componente de produto.
A implementao do projecto no nvel superior da hierarquia do produto envolve
a especificao de cada componente de produto no nvel seguinte da hierarquia
do produto. Esta actividade inclui a alocao, o aperfeioamento, e a verificao
de cada componente de produto. Envolve tambm a coordenao entre o
desenvolvimento dos diversos componentes.
Exemplo de caractersticas desta implementao:
O software codificado;
Os dados so documentados;
Os servios so documentados;
As peas elctricas e mecnicas so fabricadas;
Os processos de fabrico de produto exclusivo so postos em operao;
Os processos so documentados;
As instalaes so produzidas;
Os materiais so produzidos.
Trabalhos tpicos:
1. Projecto implementado.
Subprticas:
1. Utilizar mtodos eficazes para implementar os componentes de produto.
Exemplos de mtodos de codificao de software:
Programao estruturada;
Programao orientada a objectos;
Gerao automtica de cdigo;
Reutilizao de cdigo de software;
Utilizao de padres de desenho aplicveis.
2. Aderir a normas e critrios aplicveis.
Exemplos de normas de implementao:
Normas de linguagens (por exemplo: normas para linguagens de
programao de software e linguagens de descrio de hardware);
Requisitos de desenho;
Listas de peas standard;
Peas fabricadas;
102
Estrutura e hierarquia de componentes de produto de software;
Normas de processos e qualidade.
Exemplos de critrios:
Modularidade;
Clareza;
Simplicidade;
Confiabilidade;
Segurana;
Manuteno.
3. Conduzir revises dos componentes de produto seleccionados.
4. Executar testes unitrios aos componentes de produto, se apropriado.
5. Rever o componente de produto, quando necessrio.
Um exemplo de quando poder ser necessrio rever um componente de
produto quando surgem problemas durante a implementao que no
poderiam ser previstos durante a concepo.

Prtica especfica 3.2, Desenvolver a documentao de suporte do produto [37]:
O objectivo desta prtica desenvolver e manter a documentao para o
utilizador final.
Esta prtica especfica desenvolve e mantm a documentao que ser utilizada
na instalao, operao, e manuteno do produto.
Trabalhos tpicos:
1. Matrias de formao para o utilizador final;
2. Manual de utilizao;
3. Manual de operao;
4. Manual de manuteno;
5. Ajuda online.
Subprticas:
1. Rever os requisitos, projecto, produto, e resultados de teste para garantir
que as questes que afectam a documentao de instalao, operao, e
manuteno so identificadas e resolvidas;
2. Utilizar mtodos eficazes para desenvolver a documentao de
instalao, operao, e manuteno;
3. Aderir a normas de documentao aplicveis.
Exemplos de normas de documentao:
Compatibilidade com os processadores de texto designados;
Fontes aceitveis;
Numerao de pginas, seces e pargrafos;
103
Coerncia com o estilo designado para o manual;
Utilizao de abreviaturas;
Requisitos de internacionalizao.
4. Desenvolver verses preliminares da documentao de instalao,
operao, e manuteno nas primeiras fases do ciclo de vida do projecto
para reviso pelas partes interessadas relevante;
5. Conduzir revises da documentao de instalao, operao e
manuteno;
6. Rever a documentao de instalao, operao e manuteno, se
necessrio.
Exemplos de quando a documentao pode necessitar de ser revista:
Alteraes nos requisitos;
Alteraes no projecto;
Alteraes no produto;
Identificao de erros na documentao;
Identificao de correces.

O objectivo desta prtica realizar as prticas especficas do processo de soluo tcnica
para produzir trabalhos e fornecer servios para alcanar as metas especficas da rea de
processo.

planear e executar o processo de soluo tcnica.

104
Elaborao:
Esta poltica estabelece expectativas organizacionais para abordar o ciclo iterativo
no qual so seleccionadas as solues dos componentes de produto, os projectos
dos produtos e componentes de produto so desenvolvidos, e os projectos de
componentes de produto so implementados.

de soluo tcnica.
Elaborao:
Este plano para executar o processo de soluo tcnica pode fazer parte do plano
do projecto, ou ser referenciado por este.

processo de soluo tcnica, desenvolver os trabalhos e fornecer os servios do
processo.
Elaborao:
Podem ser necessrias instalaes especiais para o desenvolvimento, projecto, e
implementao de solues para os requisitos. Quando necessrias, as instalaes
necessrias para as actividades da rea de processo Soluo Tcnica so
desenvolvidas ou compradas.

soluo tcnica.

105
de soluo tcnica como for necessrio.

O objectivo desta prtica colocar os trabalhos designados do processo de
soluo tcnica em nveis adequados de controlo.

processo de soluo tcnica como planeado.
Elaborao:
pessoal que possa estar afectado ou afectar o produto assim como o processo.

O objectivo desta prtica monitorizar e controlar o processo de soluo tcnica
face ao plano para executar o processo e tomar as aces correctivas apropriadas.

O objectivo desta prtica avaliar objectivamente a adeso do processo de
soluo tcnica sua descrio, normas e procedimentos, e tratar as no
conformidades.

106
de soluo tcnica com elevado nvel de gesto e resolver os problemas.

6.3. Alcanar o nvel de capacidade 2 na rea de processo Soluo Tcnica
O CMMI define a rea de processo Soluo Tcnica mas no descreve como devero as
organizaes proceder para a alcanar.
rea de processo Soluo Tcnica.

De acordo com o objectivo da prtica especfica 1.1, Desenvolver solues alternativas e
critrios de seleco, da rea de processo Soluo Tcnica, para cada projecto
desenvolvido pela Metatheke dever existir um documento de soluo tcnica, onde
sero registados os critrios de seleco de solues alternativas e os critrios de
seleco da soluo final, e descritas as diferentes solues alternativas. Para alm deste
documento, devero existir relatrios de avaliao de novas tecnologias e relatrios de
avaliao de produtos COTS.
1. Documento de soluo tcnica
No documento de soluo tcnica devero ficar descritas detalhadamente as
solues alternativas identificadas para o projecto em questo.
As solues alternativas envolvem diferentes alocaes de requisitos. O registo
das alocaes dos requisitos aos componentes de produto poder ser mantido no
documento de soluo tcnica.
Neste documento devero tambm ser apresentados os critrios de seleco de
solues alternativas, que so utilizados na avaliao e seleco do conjunto de
107
solues alternativas a ser considerado, assim como os critrios de seleco da
soluo, que vo permitir seleccionar a soluo mais adequada. Estes critrios
podem variar significativamente entre produtos, dependendo do tipo de produto,
do ambiente operacional, dos requisitos de desempenho, dos requisitos de
suporte, e dos custos e prazos da entrega [39].
Na Figura 13 apresentado o que dever ser includo no documento de soluo
tcnica dos projectos da Metatheke.

Figura 13 Documento de soluo tcnica

2. Relatrio de avaliao de tecnologias
O relatrio de avaliao de tecnologias consiste num relatrio tcnico, onde
dever ficar documentada a avaliao efectuada a novas tecnologias e a
tecnologias em uso, com as suas vantagens e desvantagens de cada uma.
ndice
Revises
Glossrio
7. Introduo
7.1. Objectivos
7.2. Descrio do sistema
7.3. Limitaes do sistema
8. Critrios estabelecidos
8.1. Critrios de seleco de solues alternativas
8.2. Critrios de seleco da soluo final
9. Solues alternativas
9.1. Soluo A
9.1.1. Descrio
9.1.2. Requisitos atendidos
9.1.3. Avaliao
9.2. Soluo B
9.2.1. Descrio
9.2.2. Requisitos atendidos
9.2.3. Avaliao
9.3. ...
10. Soluo seleccionada
10.1. Descrio detalhada
10.2. Razo da seleco
11. Avaliao dos critrios

108
Na Figura 14 apresentado o que dever ser includo no relatrio de avaliao de
tecnologias dos projectos da Metatheke.

Figura 14 Relatrio de avaliao de tecnologias

3. Relatrio de avaliao de produtos COTS
O relatrio de avaliao de produtos COTS consiste tambm num relatrio
tcnico, onde dever ficar documentada a avaliao efectuada a este tipo de
produtos.
Na Figura 15 apresentado o que dever ser includo no relatrio de avaliao de
produtos COTS dos projectos da Metatheke.

ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Novas tecnologias
2.1. Tecnologia A
2.1.1. Descrio
2.1.2. Avaliao
2.2. Tecnologia B
2.2.1. Descrio
2.2.2. Avaliao
2.3. ...
3. Tecnologias em uso
3.1. Tecnologia C
3.1.1. Descrio
3.1.2. Avaliao
3.2. Tecnologia D
3.2.1. Descrio
3.2.2. Avaliao
3.3. ...

109

Figura 15 Relatrio de avaliao de produtos COTS

De acordo com o objectivo da prtica especfica 1.2, Seleccionar solues de
componentes de produto, da rea de processo Soluo Tcnica, dever existir na
Metatheke um documento para descrio das solues e registo da razo para a seleco.
1. Documento de soluo tcnica
Depois das solues alternativas serem avaliadas, dever ser seleccionada a
melhor soluo alternativa. A avaliao e a argumentao que levaram escolha
da soluo final devero ser registadas no documento de soluo tcnica (Figura
13).

processo de Soluo Tcnica.
ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Produtos COTS
2.1. Produto A
2.1.1. Descrio
2.1.2. Avaliao
2.2. Produto B
2.2.1. Descrio
2.2.2. Avaliao
2.3. ...

110

Figura 16 Fluxograma de implementao da meta especfica 1 da rea de processo Soluo Tcnica

De acordo com o objectivo da prtica especfica 2.1, Projectar o produto ou componente
de produto, da rea de processo Soluo Tcnica, a Metatheke dever criar um
111
documento de arquitectura do produto e um documento do projecto ou desenho para os
componentes de produto.
1. Documento de arquitectura
O documento de arquitectura do projecto permite detalhar a arquitectura
adoptada do produto e dos seus componentes. Os critrios para avaliao do
projecto e os mtodos de projecto apropriados, estabelecidos pela Metatheke,
devero ser descritos neste documento.
Na Figura 17 apresentado o que dever ser includo no documento de
arquitectura dos projectos da Metatheke.

Figura 17 Documento de arquitectura
2. Documento de desenho
Dever ser elaborado um documento de desenho para cada componente de
produto, onde estes devero ficar descritos de forma completa.
Na Figura 18 apresentado o que dever ser includo no documento de desenho
dos projectos da Metatheke.
ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Arquitectura do sistema
2.1. Descrio da arquitectural do sistema
2.2. Perspectiva lgica
2.3. Perspectiva funcional
2.4. Perspectiva fsica
2.5. Componentes
2.6. Interfaces
2.7. Modelo de dados
2.8. Casos de utilizao
3. Critrios de avaliao do projecto
4. Mtodos de projecto
112

Figura 18 Documento de desenho

De acordo com o objectivo da prtica especfica 2.2, Estabelecer um pacote de dados
tcnicos, da rea de processo Soluo Tcnica, dever ser criado um pacote de dados
tcnicos para os componentes de produto.
1. Pacote de dados tcnicos
O pacote de dados tcnicos deve conter uma descrio tcnica do desenho do
produto, por exemplo:
Descrio da arquitectura do projecto
Requisitos alocados
Descrio de componentes de produto
Caractersticas do produto
Requisitos de interface
Condies de uso

A Metatheke dever determinar qual a informao essencial para uma completa
descrio e entendimento do produto ou componente de produto que est a ser
desenvolvido. O pacote de dados tcnicos ser o conjunto de toda essa
informao, que dever ser definida previamente e agregada pela Metatheke.

ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Requisitos
3. Arquitectura do sistema
4. Componente
4.1. Descrio funcional
4.2. Estrutura interna
4.3. Interfaces
5. Desenho detalhado do componente
113
De acordo com o objectivo da prtica especfica 2.3, Projectar os interfaces utilizando os
critrios, da rea de processo Soluo Tcnica, devero ser estabelecidos critrios para as
interfaces de componentes de produto e dever existir um documento de especificao
do projecto de interface.
1. Documento de Interface
A Metatheke dever desenvolver para os seus projectos um documento de
especificao de interfaces, onde cada interface ficar detalhadamente descrita,
juntamente com critrios para interfaces estabelecidos, e a razo da seleco do
projecto da interface.
Na Figura 19 apresentado o que dever ser includo no documento de interface

Figura 19 Documento de interface

De acordo com o objectivo da prtica especfica 2.4, Executar anlises de construo,
compra, ou reutilizao, da rea de processo Soluo Tcnica, dever existir um
documento de anlise de construo, compra ou reutilizao, onde se apresentam os
critrios para a deciso e o resultado da anlise.
1. Documento de anlise de construo, compra ou reutilizao
A Metatheke dever decidir se vai desenvolver internamente um determinado
componente, contratar uma empresa para fazer esse desenvolvimento, ou
reutilizar um componente j disponvel na empresa. Os resultados dessa anlise
ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Interfaces
2.1. Descrio detalhada da interface
2.2. Razo da seleco
3. Critrios de interfaces

114
devero ficar registados no documento de anlise de construo, compra ou
reutilizao.
Na Figura 20 apresentado o que dever ser includo no documento de anlise de
construo, compra ou reutilizao dos projectos da Metatheke.

Figura 20 Documento de anlise de construo, compra ou reutilizao

ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
1.3. Descrio do componente
2. Requisitos
3. Componentes que podem ser adquiridos
3.1. Componente A
3.1.1. Descrio
3.1.2. Fornecedor
3.1.3. Anlise
3.2. Componente B
3.2.1. Descrio
3.2.2. Fornecedor
3.2.3. Anlise
3.3. ...
4. Componentes que existem na organizao
4.1. Componente C
4.1.1. Descrio
4.1.2. Anlise
4.2. Componente D
4.2.1. Descrio
4.2.2. Anlise
4.3. ...
5. Critrios de seleco
6. Resultados da anlise

115

116
De acordo com o objectivo da prtica especfica 3.1, Implementar o projecto, da rea de
processo Soluo Tcnica, devero ser utilizados mtodos eficazes de implementao de
componentes de produto e estabelecidas normas e critrios, que ficaro descritos num
documento de recomendaes para a implementao.
1. Documento de recomendaes para a implementao
Os componentes de produto sero implementados seguindo a soluo
seleccionada. Para tal, a Metatheke dever utilizar mtodos eficazes de
implementao, como por exemplo:
Utilizao de uma ferramenta UML para automaticamente gerar o cdigo;
Utilizao de padres de desenho para permitir uma melhor manuteno
do cdigo;
Desenho dos casos de teste, uma vez que os testes unitrios fazem parte
da implementao.
Os mtodos de implementao devero ser includos no documento de
recomendaes para a implementao.
Tambm neste documento, devero encontrar-se documentadas as normas e
critrios de implementao que devero ser seguidos pela Metatheke.
Na Figura 22 apresentado o que dever ser includo no documento de
recomendaes para a implementao dos projectos da Metatheke.

Figura 22 Documento de recomendaes para a implementao

ndice
Revises
Glossrio
1. Objectivos
2. Regras e recomendaes
3. Normas de implementao
4. Critrios de implementao

117
De acordo com o objectivo da prtica especfica 3.2, Desenvolver a documentao de
suporte do produto, da rea de processo Soluo Tcnica, a Metatheke dever
desenvolver e manter a documentao dos seus produtos.
1. Documentao tcnica
A documentao tcnica associada aos produtos desenvolvidos na Metatheke
dever incluir:
Manual de utilizao: o manual de utilizao descreve todos os detalhes de
utilizao do sistema;
Na Figura 23 apresentado o que dever ser includo no Manual de utilizao

Figura 23 Manual de utilizao
Manual de instalao: o manual de instalao descreve a forma de execuo
das actividades de instalao do sistema;
Na Figura 24 apresentado o que dever ser includo no Manual de instalao
ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
1.2. Descrio do manual
2. Apresentao do sistema
3. Funcionalidades do sistema
118

Figura 24 Manual de instalao
Manual de operao: o manual de operao descreve a forma de execuo das
actividades de operao do sistema;
Na Figura 25 apresentado o que dever ser includo no Manual de operao

Figura 25 Manual de Operao
Manual de manuteno: o manual de manuteno descreve a forma de
execuo das actividades de manuteno do sistema.
Na Figura 26 apresentado o que dever ser includo no Documento Manual
de manuteno dos projectos da Metatheke.
ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Modo de operao

ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Requisitos mnimos
3. Instalar
4. Configurar
5. Remover
119

Figura 26 Manual de manuteno
2. Documento de recomendaes para o desenvolvimento da documentao
Para o desenvolvimento da documentao associada ao sistema, a Metatheke
dever utilizar mtodos eficazes e normas de documentao aplicveis, que
estaro apresentadas num documento de recomendaes para o
desenvolvimento da documentao.
Na Figura 27 apresentado o que dever ser includo no Documento de
recomendaes para o desenvolvimento da documentao dos projectos da
Metatheke.

Figura 27 - Documento de recomendaes para o desenvolvimento da documentao
A arquitectura, o desenho e a implementao no ficam completas at a documentao
que ser utilizada para a utilizao, operao e manuteno do produto seja tambm
desenvolvida, revista e, se necessrio, corrigida.
ndice
Revises
Glossrio
3. Objectivos
4. Regras e recomendaes
5. Normas de desenvolvimento de documentao tcnica
6. Critrios de desenvolvimento de documentao tcnica

ndice
Revises
Glossrio
1. Introduo
1.1. Objectivos
2. Manuteno

120


121

organizacional, dever ser definida uma poltica organizacional para a soluo tcnica. A
poltica organizacional da Metatheke ficar descrita num documento editado pela equipa
de gesto que descreve o comportamento esperado dos trabalhadores no processo de
soluo tcnica [40].
No Anexo K [41] apresentada a poltica do processo de soluo tcnica, que ser
seguida pela Metatheke nos seus projectos.

definido um plano para a soluo tcnica. Neste plano devero constar todas as tarefas
necessrias para a execuo do processo, revisto e acordado por todas as partes
relevantes [40].
A descrio do processo de soluo tcnica definido;
O calendrio no qual o processo de soluo tcnica deve ser executado;
Os recursos necessrios para a execuo do processo de soluo tcnica, incluindo
financiamento, pessoas e ferramentas;
Formao necessria;
processo de soluo tcnica, seus trabalhos e servios;
Na Figura 29 apresentado o que dever ser includo no plano da Soluo Tcnica da
Metatheke.
122

Figura 29 Plano da Soluo Tcnica [39]

disponibilizados os recursos necessrios para a Soluo Tcnica, tais como:
Oramento adequado
sala de reunies
sala para equipa de desenvolvimento
ndice
Revises
Glossrio
1.0 Introduo
2.0 Objectivo
2.1 mbito
2.2 Definies
2.3 Objectivos
3.0 Gesto
3.1 Organizao
3.2 Tarefas
3.3.1 Gesto
3.3.5 Cliente
3.4 Plano
3.5 Recursos
3.6 Formaes
4.0 Processo de Soluo Tcnica
4.1 Solues Alternativas
4.2 Seleco da Soluo
4.3 Projecto do Produto ou Componentes de Produto
4.4 Projecto de Interfaces
4.5 Anlise de Construo, Compra ou Reutilizao
4.6 Implementao dos Componentes de Produto e Documentao Associada
8.0 Desenvolvimento das Solues para os Requisitos
Documentos Anexos

123
Desenvolvimento de solues para os requisitos
Projecto de solues para os requisitos
Implementao de solues para os requisitos
Ferramentas de especificao do projecto
Simuladores e ferramentas de modelao
Ferramentas de prottipos
Ferramentas de definio e gesto de cenrios
Ferramentas de monitorizao de requisitos
Ferramentas de documentao interactiva

atribuio de responsabilidades dever ser feita para o processo de soluo tcnica.
A Metatheke dever atribuir aos membros envolvidos neste processo as seguintes
funes:
Definio de solues alternativas para os requisitos;
Anlise e seleco das solues alternativas;
Implementao das solues seleccionadas para os requisitos;
Desenvolvimento e manuteno da documentao associada.

de soluo tcnica da Metatheke. Nesta tabela, para cada equipa envolvida no processo
de soluo tcnica, indicado o nome e o contacto de cada membro, juntamente com a
indicao da sua responsabilidade.

124
Tabela 17 Tabela de atribuio de responsabilidades para a Soluo Tcnica
Equipa Nome Contacto Responsabilidade
Administrao
Pedro Almeida dgeral@metatheke.com Director Geral

Gesto
Pedro Almeida dgeral@metatheke.com Director Geral

Qualidade
Joana Martins dqualidade@metatheke.com Director de Qualidade

Gesto
Projectos
Sara Martins gprojectos@metatheke.com Gestor de Projectos
Pedro Pais gprojectosint@metatheke.com Gestor de Projectos
Internacionais

Requisitos
Joo Oliveira tinformatica@metatheke.com Tcnico Superior de
Informtica

Arquitectura e
Projecto
Sandra Cruz dcriativo@metatheke.com Director Criativo
Marco Fernandes did@metatheke.com Arquitecto de Sistemas
Pedro Almeida dgeral@metatheke.com Arquitecto de Sistemas
Implementao
Joo Oliveira tinformatica@metatheke.com Tcnico de Informtica
Sara Martins gprojectos@metatheke.com Tcnico de Informtica
Carlos Gonalves tinformatica@metatheke.com Tcnico de Informtica

No organigrama da empresa (Figura 30) dever ficar claramente representada a
hierarquia das equipas envolvidas no processo de Soluo Tcnica.

Figura 30 Seco do organigrama

De acordo com o objectivo da prtica genrica 2.5,
formao para todas as pessoas envolvidas no processo de
Domnio da aplicao do produto e componentes de produto;
Mtodos de desenho;
Desenho de interfaces;
Tcnicas de teste unitrio
Normas (por exemplo: de produto, de segurana, de factores humanos, e
ambientais)
A Metatheke dever definir o modelo e regras das formaes de
de exemplo, todos os envolvidos no processo devero participar em 2 formaes por ano,
Administrao
Pedro Almeida
Marco Fernandes
Equipa Gesto
Pedro Almeida
Equipa Qualidade
Joana Martins
Gesto Projectos
Sara Martins
Pedro Pais
Seco do organigrama correspondente Soluo Tcnica

De acordo com o objectivo da prtica genrica 2.5, Formar pessoas, dever existir
formao para todas as pessoas envolvidas no processo de soluo tcnica.
exemplos de tpicos de formao so:
da aplicao do produto e componentes de produto;

de interfaces;
teste unitrio;
A Metatheke dever definir o modelo e regras das formaes de soluo tcnica
Administrao
Pedro Almeida
Marco Fernandes
Equipa Qualidade
Joana Martins
Equipa
Engenharia
Gesto Projectos
Sara Martins
Pedro Pais
Requisitos
Joo Oliveira
Marco Fernandes
Desenvolvimento
Arquitectura e
Projecto
Sandra Cruz
M. Fernandes
Pedro Almeida
125

dever existir

soluo tcnica. A ttulo
Desenvolvimento
Implementao
Joo Oliveira
Sara Martins
C. Gonalves
126
sendo que cada um destes dever escolher as formaes mais adequadas com a sua
funo, e esta escolha dever ser aprovada pela gesto.
Nome da formao;
Local da formao;
Data da formao;
Contedo da formao;
informao para cada trabalhador envolvido no desenvolvimento de requisitos:
Nome da formao;
Local da formao;
Data da formao;
Contedo da formao;

dever gerir configuraes para a Soluo Tcnica.
O objectivo da gesto da configurao estabelecer e manter a integridade do projecto
ao longo do ciclo de vida do projecto, evitando que verses corrigidas sejam perdidas.
Todas as modificaes nos artefactos necessrios para o processo de soluo tcnica
(projecto do produto ou componentes de produto, pacote de dados tcnicos,
documentos de projecto de interface, manuais do utilizador, de instalao, de operao,
127
e de manuteno) sero organizadas e registadas numa base de dados, com a seguinte
informao:
modificao (por exemplo: Manual do Utilizador);
modificao (por exemplo: id do manual do utilizador em questo);
Dever ser atribudo a um membro da equipa de desenvolvimento a funo de assegurar
a integralidade e manuteno dos artefactos.

interessadas, a Metatheke dever identificar e envolver as partes relevantes na soluo
tcnica. Para isso dever [42]:
Nas actas das reunies de desenvolvimento indicar quais as partes interessadas
que participaram na reunio e incluir todos os itens de aco atribudos s partes
interessadas;
Nos documentos do projecto incluir os nomes das partes interessadas envolvidas;
Desenvolver solues alternativas e critrios de seleco;
Obter a aprovao das especificaes das interfaces externas e descries do
projecto;
Desenvolver o pacote de dados tcnicos;
Avaliar a construo, compra ou reutilizao para os componentes de produto;
Implementar o projecto.

soluo tcnica para um projecto da Metatheke.

128
Tabela 18 Tabela de identificao das partes relevantes no processo de soluo tcnica
Papel Nome
Requisitos
Joo Oliveira
Marco Fernandes
Arquitectura Pedro Almeida
Desenvolvimento
Joo Oliveira
Sara Martins

Metatheke dever monitorizar e controlar o processo de soluo tcnica.
[37], [40]:
Planeamento para a soluo tcnica;
Percentagem de requisitos abordados no projecto do produto ou componentes de
produto;
Tamanho e complexidade do produto, componentes de produto, interfaces, e
documentao.
Densidade de defeitos dos trabalhos da soluo tcnica;
Recolha e anlise de medidas de desempenho face ao plano de soluo tcnica;
Reviso do cumprimento e dos resultados do processo de soluo tcnica face ao
planeado;
Tomar aces correctivas quando os objectivos da soluo tcnica no esto a ser
satisfeitos, quando os problemas esto identificados, ou quando o progresso
difere significativamente do plano [43]:
alteraes;

A soluo tcnica dever ser analisada em reunies semanais de controlo do projecto.
129
Contacto do Responsvel de cada uma das reas envolvidas na soluo tcnica,
indicando:
rea;
Responsvel;
Resumo e estado de todas as actividades de soluo tcnica, indicando:
rea;
Actividade;
Itens de aco relacionados com a soluo tcnica, indicando:
Aco;
Data alvo da aco.

Metatheke dever ser analisada a aderncia ao processo de soluo tcnica.
O processo de soluo tcnica implementado como planeado?
O processo de soluo tcnica planeado satisfaz os requisitos e objectivos?
Os resultados de seguir o processo de soluo tcnica satisfazem os seus
requisitos?
130
nvel, a Metatheke dever rever o estado do processo de Soluo Tcnica com elevado
nvel de gesto. Para isso, semanalmente dever ser efectuada uma reunio de gesto,
para a reviso das actividades, estado, e resultados do processo de soluo tcnica com
um nvel alto de gesto e resolver todas as questes existentes.
auditorias, todos relatrios de falhas, e pontos de situao semanais do processo de
soluo tcnica.

131
7. Concluses

Este trabalho teve como objectivo principal a preparao da Metatheke para atingir o
nvel 2 de certificao CMMI em trs reas de processo, Gesto de Requisitos,
Desenvolvimento de Requisitos e Soluo Tcnica, por serem consideradas as reas cuja
melhoria seria mais importante para a organizao.
Para isso, foram propostos papis, fluxos de actividades, e artefactos necessrios para
alcanar as metas e prticas definidas no CMMI para as reas de processo seleccionadas.
O principal problema encontrado durante a fase de estudo do modelo, foi a dificuldade
em encontrar informao sobre como implementar os processos de melhoria, dado que o
CMMI define as metas e prticas relacionadas com as reas de processo mas no
descreve como devero as organizaes proceder para as alcanar. Outra dificuldade
encontrada nesta fase, foi isolar a documentao das actividades das reas de processo
escolhidas, das restantes reas de processo definidas no modelo, pois as 22 reas de
processo do CMMI esto fortemente relacionadas, e o objectivo deste trabalho consistia
na melhoria de apenas trs reas de processo.
Durante a elaborao do processo de preparao na Metatheke encontraram-se tambm
algumas dificuldades, sendo a principal, o reduzido nmero de recursos disponveis na
empresa para a melhoria dos processos.
O processo proposto necessita de algumas melhorias para atender s exigncias das
prticas especficas e existem ainda alguns pontos do processo que podem evoluir e
contribuir para o amadurecimento deste processo. No entanto, o objectivo do trabalho
foi alcanado.

133
Referncias

[1] http://www.iapmei.pt/iapmei-art-03.php?id=338, consultado em Novembro de 2008.
[2] http://www.dqa.pt/002.aspx?dqa=0:0:0:14:40:17%3B8%3B40:-1:0:0, consultado em
Novembro de 2008.
[3] http://www.ipq.pt, consultado em Novembro de 2008.
[4] http://www.cen.eu, consultado em Novembro de 2008.
[5] http://www.iso.org, consultado em Novembro de 2008.
[6] D. F. Barbosa, E. S. Furtado, A. S. Gomes, Uma Proposta de Institucionalizao da
Usabilidade Alinhada com Prticas do Modelo CMMI e Foco nas Necessidades da
Organizao, Proceedings of VII Brazilian symposium on Human factors in computing
systems, 45 48, 2006.
[7] http://www.sei.cmu.edu/cmmi/general/, consultado em Novembro de 2008.
[8] http://www.sei.cmu.edu, consultado em Novembro de 2008.
[9] http://www.sei.cmu.edu/cmm/, consultado em Novembro de 2008.
[10] S. Mishra, B.H. Schlingloff, Compliance of CMMI Process Area with Specification
Based Development, Sixth International Conference on Software Engineering Research,
Management and Applications, 77 84, 2008.
[11] http://www.iso.org/iso/iso_catalogue/management_standards/certification.htm,
consultado em Novembro de 2008.
[12] C. Yoo, J. Yoon, B. Lee, C. Lee, J Lee, S. Hyun, C. Wu, An Integrated Model of ISO
9001:2000 and CMMI for ISO Registered Organizations, Proceedings of the 11th Asia-
Pacific Software Engineering Conference, 150 - 157, 2004.
[13] CMMI Product Team, CMMI for Development, Version 1.2 - Improving processes for
better products, Agosto 2006, pp 13-85.
[14] T. Jokela, T. Lalli, Usability and CMMI: Does A Higher Maturity Level in Product
Development Mean Better Usability?, Conference on Human Factors in Computing
Systems, CHI '03, Ft. Lauderdale, USA, 1010 1011, 2003.
134
[15] M. B. Chrissis, M. Konrad, S. Shrum, CMMI Guidelines for Process Integration and
Product Improvement, Addison-Wesley, 2003.
[16] www.sei.cmu.edu/cmmi/appraisals, consultado em Novembro de 2008.
[17] http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2008MarCMMI.pdf,
consultado em Fevereiro de 2009.
[18] http://www.semanainformatica.xl.pt/806/act/300.shtml, consultado em Fevereiro
de 2009.
[19] http://www.sinfic.pt/SinficWeb/conteudo/homepage.do2, consultado em Fevereiro
de 2009.
[20] http://www.novabase.pt/showNews.asp?idProd=pr_cmmi, consultado em Fevereiro
de 2009.
[21] http://www.esi.pt/, consultado em Fevereiro de 2009.
[22] https://www.bes.pt/sitebes/cms.aspx?plg=8fd7f1be-2c59-4590-8ac5-a3db8af1d595,
consultado em Fevereiro de 2009.
[23] http://sas.sei.cmu.edu/pars/pars.aspx, consultado em Fevereiro de 2009.
[24] http://www.itweb.com.br/voce_informa/interna.asp?cod=3964, consultado em
Fevereiro de 2009.
[25] http://www.cwi.com.br/cmmi.asp, consultado em Fevereiro de 2009.
[26] http://info.abril.com.br/aberto/infonews/122005/20122005-8.shl, consultado em
Fevereiro de 2009.
[27] http://info.abril.com.br/aberto/infonews/062006/13062006-0.shl, consultado em
Fevereiro de 2009.
[28] http://www.sei.cmu.edu/cmmi/results.html, consultado em Fevereiro de 2009.
[29] http://www.metatheke.com, consultado em Fevereiro de 2009.
[30] B. Shen and T. Ruan, A Case Study of Software Process Improvement in a Chinese
Small Company, 2008 International Conference on Computer Science and Software
Engineering, 609-612, 2008.
135
[31] A. Omran, AGILE CMMI from SMEs perspective, IEEE Software Engineering, 3rd
International Conference on Information and Communication Technologies: From Theory
to Applications, 1 8, 2008.
[32] M. Staples, M. Niazi, R. Jeffery, A. Abrahams, P. Byatt, R. Murphy, An exploratory
study of why organizations do not adopt CMMI, The Journal of Systems and Software 80,
883895, 2007.
[33] L. Jing, Application of CMMI in Innovation Management, International Conference on
Wireless Communications, Networking and Mobile Computing, 4966 - 4969, 2007.
[34] S. Huang , W. Han, Selection priority of process areas based on CMMI continuous
representation, Information & Management 43, 297307, 2006.
better products, Agosto 2006, pp. 468-494.
[39] M. Chrissis, M. Konrad, CMMI: Guidelines for Process Integration and Product
Improvement, Addison Wesley, 2003.
[40] T. Kasse, A Practical Guide to CMMI Implementation, Artech House Publishers, 2004.
[41] M. Kulpa, K. Johnson, Interpreting the CMMI: A Process Improvement Approach,
Auerbach Publications, 2003.
[42] D. Ahern, J. Armstrong, A. Clouse, J. Ferguson, W. Hayes, K. Nidiffer, CMMI SCAMPI
Distilled: Appraisals for Process Improvement, Addison-Wesley Professional.
[43] E. Page, Monitoring and Controlling Your Project, Software Process Improvement
(SPI) Project.
137

ANEXO A Template da Acta de Reunies
139

Acta de Reunio

Id: Data Criao: Autor:

Data:
Local:
Assunto:
Participantes:

Resumo da reunio:
Action points Responsvel Data alvo

141

ANEXO B Template do Documento de Requisitos
143

Documento de Requisitos


Projecto:
Verso:

Cdigo:
Requisito:
Fonte: Data:
Tipo: Prioridade:
Dependncias: Estado:
Risco: Estimativa:
Descrio:

Restries:
Observaes:

Histrico revises
Verso Data Responsveis Observaes

145

ANEXO C Exemplo 1 do Documento de Requisitos
147


Id: 120 Data Criao: 10/02/2009 Autor: Marco Fernandes

Projecto: EdiesOnline Consulta e transferncia de edies online
Verso: v2.0

Cdigo: R06
Requisito: Consulta de edies da semana
Fonte: Cliente Data: 02/02/2009
Tipo: Funcional Prioridade: Alta
Dependncias: No apresenta Estado: Analisado
Risco: No apresenta Estimativa: 15 HDs
Descrio: Os utilizadores do sistema podero transferir para consulta apenas as edies da
semana. Na seco de pesquisa devero ser listadas as todas edies disponveis para
consulta.

Restries: Uma edio diria s dever estar disponvel para consulta no dia seguinte da
sua edio.
Observaes:

Histrico revises
v0.1 10/02/2009 Marco Fernandes Descrio do requisito
v1.0 24/02/2009 Marco Fernandes Actualizao do doc. aps anlise do requisito

149

ANEXO D Template do Documento de Alteraes
151

Documento de Alteraes


Projecto:
Verso:

Cdigo:
Data:
Origem:
Requisito associado:

Descrio:

Razo:

Observaes:

153

ANEXO E Exemplo do Documento de Alteraes

155

Documento de Alteraes

Id: 135 Data Criao: 16/03/2009 Autor: Joo Oliveira

Verso: v2.0

Cdigo: A01
Data: 10/03/2009
Origem: Cliente
Requisito associado: R06 Consulta de edies da semana

Descrio: Apenas os assinantes do jornal podero transferir as edies do jornal, aps o seu
registo no sistema. Os restantes utilizadores podero apenas consultar a primeira pgina das
edies.

Razo: Mudana do pedido do cliente.

Observaes:

157

ANEXO F Exemplo 2 do Documento de Requisitos
159


Id: 120 Data Criao: 10/02/2009 Autor: Marco Fernandes

Verso: v2.0

Cdigo: R06
Requisito: Consulta de edies da semana
Fonte: Cliente Data: 02/02/2009
Tipo: Funcional Prioridade: Alta
Dependncias: No apresenta Estado: Analisado
Risco: Risco de atraso da entrega Estimativa: 15 HDs
Descrio: Os utilizadores do sistema, que sejam assinantes do jornal, podero, aps registo
no sistema, transferir para consulta apenas as edies da semana. Na seco de pesquisa
devero ser listadas as edies que esto disponveis para consulta. Os utilizadores no
registados tm acesso apenas primeira pgina das edies.

Restries: Uma edio diria s dever estar disponvel para consulta no dia seguinte da
sua edio.
Observaes:

Histrico revises
v0.1 10/02/2009 Marco Fernandes Descrio do requisito
v1.0 24/02/2009 Marco Fernandes Actualizao do doc. aps anlise do requisito
v2.0 20/03/2009 Marco Fernandes Alterao do requisito
161

ANEXO G Template do Documento de Inconsistncias
163

Documento de Inconsistncias


Projecto:
Verso:

Cdigo:
Data:
Origem:
Requisito associado:

Descrio:

Razo:

Condies:

Aco correctiva:

Observaes:

165

ANEXO H Exemplo do Documento de Inconsistncias

167

Documento de Inconsistncias

Id: 015 Data Criao: 22/04/2009 Autor: Joo Oliveira

Verso: v2.0

Cdigo: I01
Data: 20/04/2009
Origem: Equipa de desenvolvimento
Requisito associado: R06 Consulta de edies da semana

Descrio: A listagem das edies do jornal disponveis para consulta, surge depois do
registo do utilizador. Assim, os utilizadores no registados no tm a possibilidade de
consultar a primeira pgina das edies da semana, com foi pedido pelo cliente.

Razo: O requisito no foi implementado conforme especificado.

Condies:

Aco correctiva: Vai ser alterado para ser cumprido o requisito do cliente

Observaes: A correco desta inconsistncia ir ter impacto nas datas de entrega do
produto ao cliente.

169

ANEXO I Template da Poltica de Gesto de Requisitos

171

Poltica de Gesto de Requisitos

1.0 Objectivo
O objectivo da Gesto de Requisitos gerir os requisitos dos produtos do
projecto e dos componentes do produto e identificar inconsistncias entre
esses requisitos, os planos e os trabalhos do projecto

2.0 mbito
Esta poltica aplica-se aos projectos de software da Metatheke. O termo
projecto, como usado nesta poltica, inclui engenharia de sistema e de
software, manuteno, converso, acessrios, e projectos de aquisio.

O Gestor de Projecto deve assegurar que o processo de Gesto de Requisitos
seguido. Cada projecto ir seguir um processo que assegura que os requisitos
sero documentados, geridos e rastreados.

4.0 Verificao
As actividades de Gesto de Requisitos sero revistas com um elevado nvel de
gesto, e o processo ser avaliado objectivamente pela sua aderncia, por uma
equipa de Garantia de Qualidade.

5.0 Assinaturas
Os seguintes devero rever e aprovar esta poltica:
Director Associado
Garantia de Qualidade
Presidente
173

ANEXO J Template da Poltica de Desenvolvimento de Requisitos

177

Poltica de Desenvolvimento de Requisitos

1.0 Objectivo
O objectivo do Desenvolvimento de Requisitos desenvolver e analisar os
requisitos de cliente, de produto e de componente de produto do projecto.

2.0 mbito

O Gestor de Projecto deve assegurar que o processo de Desenvolvimento de
Requisitos seguido. Cada projecto ir seguir um processo que assegura que
os requisitos sero especificados, analisados e revistos.

4.0 Verificao
As actividades de Desenvolvimento de Requisitos sero revistas com um
elevado nvel de gesto, e o processo ser avaliado objectivamente pela sua
aderncia, por uma equipa de Garantia de Qualidade.

5.0 Assinaturas
Director Associado
Presidente
179

ANEXO K Template da Poltica de Soluo Tcnica

181

Poltica de Soluo Tcnica

1.0 Objectivo
O objectivo da Soluo Tcnica projectar, desenvolver e implementar as
solues para os requisitos.

2.0 mbito

O Gestor de Projecto deve assegurar que o processo de Soluo Tcnica
seguido. Cada projecto ir seguir um processo que assegura que os requisitos
so convertidos na arquitectura do produto, no projecto dos componentes de
produto e na implementao desses componentes de produto.

4.0 Verificao
As actividades de Soluo Tcnica sero revistas com um elevado nvel de
gesto, e o processo ser avaliado objectivamente pela sua aderncia, por uma
equipa de Garantia de Qualidade.

5.0 Assinaturas
Director Associado
Presidente

PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PDF

Transféré par

Droits d'auteur :

Formats disponibles

Universidade de Aveiro

Vous aimerez peut-être aussi