AndreaPadovanJubileu PDF

Modelo de Gesto do Processo de
Venda e Desenvolvimento de
Software On-Demand
para MPEs
Andrea Padovan Jubileu
Tese apresentada Escola de Engenharia de So

Carlos, da Universidade de So Paulo, como parte dos
requisitos para obteno do ttulo de Doutor em
Engenharia de Produo.
Orientador: Professor Titular Henrique Rozenfeld
So Carlos
2008
Ao meu esposo Renato e
aos meus pais Geraldo e Matilde.

AGRADECIMENTOS
A Deus, por guiar os meus passos.
Ao Renato, meu grande amor e companheiro, grande incentivador desse trabalho.
A toda minha famlia, em especial aos meus pais (Geraldo e Matilde) que sempre me apoiaram em
todos os momentos de minha vida, aos meus irmos (Cassiano, Adriano), minha tia Ivanilde, meu
sogro (Alceu) e minha sogra (Elvira), minhas sobrinhas (Lavnia e Lorena), meu sobrinho (Igor) e
minhas cunhadas (Haline e Adriane) que estiveram sempre ao meu lado e souberam compreender as
minhas ausncias quando necessrio.
A todos que colaboraram direta ou indiretamente para que fosse possvel a realizao desse trabalho:
Moacir, Haroldo, Robson, Douglas e, em especial, Sayuri, Jana, Agla, Maria Jos, Marcelo (Mo),
Emerson, Rogrio, Marcos, Ana Cristina e Mrcio.
A todos os amigos que me incentivaram durante a realizao desse trabalho: Ana Lcia, Francis,
Sayuri, Jana, Simone, Ana Claudia, Helien, Eve, Eduardo, Dani, Ana Paula, Cris, Leandro, Mo,
Agla, Maria Jos, Emerson, Roger, Dbora, Gisele e Ivani.
A todos os professores que encontrei durante minha vida acadmica. Em especial, Rosely que com
seu conhecimento e experincia enriqueceu minha vida profissional e pessoal, e ao prof. Henrique
que me deu a oportunidade de desenvolver esse trabalho de pesquisa e, conseqentemente,
contribuiu para o meu crescimento profissional.
Aos proprietrios das empresas onde foi realizada a pesquisa-ao, Paulo e Marcos, e aos
funcionrios dessas empresas.
Aos funcionrios e docentes do Departamento de Engenharia de Produo da EESC, em especial ao

Z Luis.
RESUMO
JUBILEU, A. P. Modelo de Gesto do Processo de Venda e Desenvolvimento de

Software On-demand para MPEs. 2008. 330p. Tese (Doutorado) Escola de Engenharia de
So Carlos, Universidade de So Paulo, So Carlos, 2008.
A maioria das micro e pequenas empresas (MPEs) de desenvolvimento de software
brasileiras so voltadas para o desenvolvimento de software on-demand. Normalmente,
essas MPEs tm dificuldades em formalizar um processo de software padro. O presente
trabalho de pesquisa tem por objetivo apresentar uma proposta de integrao de
modelos/normas de capacidade de processo com modelos de ciclo de vida de software, em
um contexto de gesto de processos de negcio. Como resultado, obteve-se o Modelo de
Gesto do Processo de Venda e Desenvolvimento de Software On-demand para MPEs
(ProcSoftVD - Gesto), composto pelo Mtodo de Melhoria de Processo de Software
(ProcSoftVD Melhoria) e pelo Modelo de Processo de Venda e Desenvolvimento de
Software On-demand para MPEs (ProcSoftVD). O Mtodo de Melhoria de Processo de
Software foi criado a partir de abordagens existentes e complementares, voltadas s MPEs.
O ProcSoftVD foi originado com base no framework Unified Process, possibilitando a
visualizao do processo em duas perspectivas fases e reas de conhecimento, e nos
modelos/normas de capacidade de processo CMMI-DEV e ISO/IEC 15504-5, elaborado em
um processo iterativo e evolutivo de pesquisa-ao com a participao de duas MPEs. Um
diferencial dessa proposta a considerao de atividades de comercializao do software
junto ao processo de desenvolvimento de software, o que auxilia na delimitao do escopo
do projeto de desenvolvimento de software para um acordo contratual. Outro diferencial o
detalhamento das atividades do processo por meio de tarefas, sugesto de papis
desempenhados pelos responsveis das atividades e disponibilizao de templates com
exemplos para cada um dos artefatos elaborados na execuo da atividade.
Palavras-chave: Modelo de Processo de Software, Qualidade de Processo de Software,
Melhoria de Processo de Software.

ABSTRACT
JUBILEU, A. P. Management Model of Selling and On-demand Software

Development Process. 2008 PhD Thesis Sao Carlos Engineering School, Sao Paulo
University, Sao Carlos, 2008.
The majority of the software development micro and small companies are turned to
the development of on-demand software. Usually, for these small companies the
formalization of a standard process for software development is very difficult. For that reason
the goal of this research is to propose an integration of capability processes
models/standards within software life cycle models, in a perspective of business process
management. The main result of this research is a Management Model of Selling and On-
demand Software Development Process, which embraces the Software Process
Improvement Method and the Selling and on-demand Software Development Process Model.
The Software Process Improvement Method was build from complementary and existents
tailored approaches for micro and small companies. The Selling and on-demand Software
Development Process Model was created based on the models/standards of process
capability CMMI-DEV and ISO/IEC 15504-5 and on the Unified Process Framework, allowing
the process view from two perspectives phases and knowledge areas. The model was
elaborated in an iterative and evolutionary action-research process carried out within two
micro and small companies. The originality of this proposal is the consideration of software
sale activities jointly with software development process, assisting the scope delimitation of a
software development project for contractual agreement. Other aspect of this research which
makes it distinctive is the detail of the process activities by mean of tasks, suggestions of
people roles for each activities and provision of templates with examples for each artifact
created during the activities.
Key words: Software Process Model, Software Quality Process, Software Process
Improvement.
Lista de Figuras/Tabelas/Quadros
Figura 2.1 Modelo de Processo de Software Clssico (Cascata) ...................................................... 26

Figura 2.2 Modelo Incremental ........................................................................................................... 27
Figura 2.3 Modelo Espiral ................................................................................................................... 28
Figura 2.4 - Modelo RAD ....................................................................................................................... 29
Figura 2.4 Unified Process. Fonte: Traduzido de (AMBLER, 2005) .................................................. 31
Figura 2.5 OpenUP ............................................................................................................................. 32
Fonte: Traduzido de (Eclipse Process Framework Community, 2008) ................................................. 32
Figura 2.6 ISO/IEC 12207 - Processos de Ciclo de Vida de Software .............................................. 34
Fonte: Traduzido de (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 2001) ............ 34
Figura 3.1 Componentes dos modelos do CMMI ............................................................................... 53
Fonte: Traduzido de (SOFTWARE ENGINEERING INSTITUTE, 2006) .............................................. 53
Figura 5.1 Modelo de Gesto do Processo de Venda e Desenvolvimento de Software On-demand
para MPEs (ProcSoftVD - GESTO) .................................................................................................... 74
Figura 5.2 Primeira Verso do Modelo Genrico Do PV&DS On-demand ........................................ 76
Figura 5.3 Instncia do Modelo Genrico Do PV&DS on-demand para a Empresa 1 ...................... 78
Figura 5.4 - Viso Grfica Da Fase Vender .......................................................................................... 79
Figura 5.5- Visualizao grfica do contedo dos artefatos do processo proposto.............................. 80
Figura 5.6 - Visualizao grfica do contedo do artefato documento de requisitos ......................... 81
Figura 5.7 - Detalhamento de uma Atividade do Modelo de Processo Proposto ................................. 82
Figura 5.8 Exemplo de Template ....................................................................................................... 83
Figura 5.9 Meta-modelo do ProcSoftVD............................................................................................. 86
Quadro 5.11 Associao das reas de conhecimento do ProcSoftVD com outros modelos ............. 91
Figura 5.12 Atividades da rea de Gesto de Conhecimento do Modelo ProcSoftVD ...................... 96
Quadro 5.13 Quadro Comparativo dos Mtodos de Melhoria de Processo ...................................... 97
Tabela 5.14 Pontuao para as reas de conhecimento (SALVIANO, 2006) ................................. 100
Figura 5.15 Pgina Principal do GProcSoftVD ................................................................................. 105
Figura 5.16 Exemplo de Viso Grfica fase de prospeco ......................................................... 106
Figura 5.17 Viso Textual: Perspectiva por Fases e por reas de Conhecimento.......................... 107
Figura 5.18 Exemplo de uma Atividade - fase de prospeco ......................................................... 108
Figura 5.19 Exemplo de Detalhamento de Atividade ....................................................................... 109
Figura 5.20 Atividades da rea de Conhecimento Gesto de Conhecimento .............................. 110
Figura 5.21 Mapeamento do ProcSoftVD com CMMI e ISO/IEC 15504-5 ...................................... 111
Figura 5.22 Exemplo de Mapeamento da Atividade Definir escopo do Projeto ............................ 112
Quadro 6.1 Caractersticas de qualidade do Modelo ProcSoftVD ................................................... 120
Figura 6.2 Grfico de relao entre as respostas dos profissionais ................................................ 120
Figura A1.1 Planilha de Relevncia (Descrio do processo) ......................................................... 135
Figura A1.2 Planilha de Relevncia (Comentrio referente cada questo) .................................. 136
Figura A1.3 Planilha de Relevncia (Seleo de alternativas) ........................................................ 136
Figura A2.1 Tabulao da Importncia versus Risco das reas de Conhecimento para a Empresa
............................................................................................................................................................. 137
Quadro A3.1 Entradas, Atividades e Sadas da fase Prospeco ................................................... 139
Quadro A3.2 Entradas, Atividades e Sadas da fase Concepo .................................................... 140
Quadro A3.2 Entradas, Atividades e Sadas da fase Concepo (Cont.)........................................ 141
Quadro A3.3 Entradas, Atividades e Sadas da fase Negociao ................................................... 142
Quadro A3.3 Entradas, Atividades e Sadas da fase Negociao (Cont.) ....................................... 143
Quadro A3.4 Entradas, Atividades e Sadas da fase Elaborao .................................................... 143
Quadro A3.4 Entradas, Atividades e Sadas da fase Elaborao (Cont.)........................................ 144
Quadro A3.5 Entradas, Atividades e Sadas da fase Construo ................................................... 144
Quadro A3.5 Entradas, Atividades e Sadas da fase Construo (Cont.) ....................................... 145
Quadro A3.6 Entradas, Atividades e Sadas da fase Transio ...................................................... 145
Quadro A3.6 Entradas, Atividades e Sadas da fase Transio (Cont.) .......................................... 146
Quadro A3.7 Entradas, Atividades e Sadas da rea de Conhecimento Comercializao ............. 147
Quadro A3.7 Entradas, Atividades e Sadas da rea de Conhecimento Comercializao (Cont.) . 148
Quadro A3.8 Entradas, Atividades e Sadas da rea de Conhecimento Modelagem de Negcio . 149
Quadro A3.9 Entradas, Atividades e Sadas da rea de Conhecimento Produo de Requisitos . 149
Quadro A3.9 Entradas, Atividades e Sadas da rea de Conhecimento Produo de Requisitos
(Cont.) .................................................................................................................................................. 150
Quadro A3.10 Entradas, Atividades e Sadas da rea de Conhecimento Projeto, Codificao &
Integrao de Produto ......................................................................................................................... 151
Quadro A3.11 Entradas, Atividades e Sadas da rea de Conhecimento Verificao & Validao 152
Quadro A3.11 Entradas, Atividades e Sadas da rea de Conhecimento Verificao & Validao
(Cont.) .................................................................................................................................................. 153
Quadro A3.12 Entradas, Atividades e Sadas da rea de Conhecimento Implantao .................. 153
Quadro A3.13 Entradas, Atividades e Sadas da rea de Conhecimento Aquisio ...................... 153
Quadro A3.14 Entradas, Atividades e Sadas da rea de Conhecimento Medio ........................ 154
Quadro A3.14 Entradas, Atividades e Sadas da rea de Conhecimento Medio (Cont.) ............ 155
Quadro A3.14 Entradas, Atividades e Sadas da rea de Conhecimento Medio (Cont.) ............ 156
Quadro A3.15 Entradas, Atividades e Sadas da rea de Conhecimento Garantia da Qualidade de
Produto e Processo ............................................................................................................................. 156
Quadro A3.15 Entradas, Atividades e Sadas da rea de Conhecimento Garantia da Qualidade de
Produto e Processo (Cont.) ................................................................................................................. 157
Quadro A3.16 Entradas, Atividades e Sadas da rea de Conhecimento Gesto de Requisitos ... 158
Quadro A3.17 Entradas, Atividades e Sadas da rea de Conhecimento Gesto de Mudanas e
Configurao ....................................................................................................................................... 158
Quadro A3.17 Entradas, Atividades e Sadas da rea de Conhecimento Gesto de Mudanas e
Configurao (Cont.) ........................................................................................................................... 159
Quadro A3.18 Entradas, Atividades e Sadas da rea de Conhecimento Gesto de Projetos ...... 159
Quadro A3.18 Entradas, Atividades e Sadas da rea de Conhecimento Gesto de Projetos (Cont.)
............................................................................................................................................................. 160
............................................................................................................................................................. 161
............................................................................................................................................................. 162
............................................................................................................................................................. 163
............................................................................................................................................................. 164
Quadro A3.19 Entradas, Atividades e Sadas da rea de Conhecimento Gesto de Conhecimento
............................................................................................................................................................. 164
Figura A3.20 Viso Grfica Fase: Prospeco ............................................................................. 165
Quadro A3.20.1 Detalhamento da Atividade P01 ............................................................................ 165
Figura A3.21 Viso Grfica Fase: Concepco ............................................................................ 170
Quadro A3.21.1 Detalhamento da Atividade Cp01 .......................................................................... 171
Quadro A3.21.1 Detalhamento da Atividade Cp01 (Cont.) .............................................................. 172
Quadro A3.21.10 Detalhamento da Atividade Cp10 ........................................................................ 181
Figura A3.22 Viso Grfica Fase: Negociao ............................................................................. 185
Quadro A3.22.1 Detalhamento da Atividade N01 ............................................................................ 186
Figura A3.23 Viso Grfica Fase: Elaborao .............................................................................. 192
Quadro A3.23.1 Detalhamento da Atividade E01 ............................................................................ 193
Quadro A3.23.5 Detalhamento da Atividade E05 (Cont.) ................................................................ 197
Figura A3.24 Viso Grfica Fase: Construo .............................................................................. 200
Quadro A3.24.1 Detalhamento da Atividade Ct01 ........................................................................... 201
Quadro A3.24.2 Detalhamento da Atividade Ct02 (Cont.) ............................................................... 202
Quadro A3.24.5 Detalhamento da Atividade Ct05 (Cont.) ............................................................... 204
Figura A3.25 Viso Grfica Fase: Transio ................................................................................ 206
Quadro A3.25.1 Detalhamento da Atividade T01 ............................................................................. 207
Quadro A5.1 Legenda do Mapeamento das Atividades................................................................... 293
Quadro A5.1 Legenda do Mapeamento das Atividades (Cont.) ...................................................... 294
Quadro A5.2 Mapeamento das Atividades da Fase de Prospeco ............................................... 294
Quadro A5.3 Mapeamento das Atividades da Fase de Concepo ................................................ 295
Quadro A5.3 Mapeamento das Atividades da Fase de Concepo (Cont.) .................................... 296
Quadro A5.4 Mapeamento das Atividades da Fase de Negociao ............................................... 299
Quadro A5.4 Mapeamento das Atividades da Fase de Negociao (Cont.) ................................... 300
Quadro A5.4 Mapeamento das Atividades da Fase de Negociao (Cont.) ................................... 301
Quadro A5.5 Mapeamento das Atividades da Fase de Elaborao ................................................ 302
Quadro A5.5 Mapeamento das Atividades da Fase de Elaborao (Cont.) .................................... 303
Quadro A5.6 Mapeamento das Atividades da Fase de Construo ................................................ 306
Quadro A5.6 Mapeamento das Atividades da Fase de Construo (Cont.) .................................... 307
Quadro A5.6 Mapeamento das Atividades da Fase de Construo (Cont.) .................................... 308
Quadro A5.7 Mapeamento das Atividades da Fase de Transio ................................................... 309
Quadro A5.7 Mapeamento das Atividades da Fase de Transio (Cont.)....................................... 310
Quadro A5.7 Mapeamento das Atividades da Fase de Transio (Cont.)....................................... 311
Quadro A8.1 Transcrio das Respostas rea de Conhecimento Produo de Requisitos ........ 321
Quadro A8.2 Transcrio das Respostas rea de Conhecimento Modelagem de Negcios ...... 321
Quadro A8.3 Transcrio das Respostas rea de Conhecimento Comercializao .................... 322
Quadro A8.4 Transcrio das Respostas rea de Conhecimento ............................................... 322
Projeto, Codificao & Integrao de Produto .................................................................................... 322
Quadro A8.5 Transcrio das Respostas rea de Conhecimento Aquisio .............................. 323
Quadro A8.6 Transcrio das Respostas rea de Conhecimento Medio ................................ 323
Quadro A8.7 Transcrio das Respostas rea de Conhecimento Implantao .......................... 323
Quadro A8.8 Transcrio das Respostas rea de Conhecimento V&V ....................................... 324
Quadro A8.9 Transcrio das Respostas rea de Conhecimento Garantia da ........................... 324
Qualidade de Produto e Processo ...................................................................................................... 324
Quadro A8.10 Transcrio das Respostas rea de Conhecimento Gesto de Conhecimento ... 324
Quadro A8.11 Transcrio das Respostas rea de Conhecimento Gesto de Requisitos ......... 325
Quadro A8.12 Transcrio das Respostas rea de Conhecimento Gesto de Projetos ............. 325
Quadro A8.13 Transcrio das Respostas rea de Conhecimento Gesto de Mudanas e
Configurao ....................................................................................................................................... 326
Lista de Abreviaturas e Siglas
ASPE/MSC Approach for Software Process Establishment in Micro and Small Companies
BPM Business Process Management
BPR Business Process Reengineering
CMMI Capability Maturity Model Integration
CMMI-DEV CMMI for Development
IDEAL Initiating, Diagnosing, Establishing, Acting, Learning
ISO/IEC 12207 Information technology -- Software life cycle processes
ISO/IEC 15504 Information technology -- Process assessment
ISO/IEC 15504-5 Information technology -- Process assessment - Part 5: An exemplar Process
Assessment Model
KM Knowledge Management
MPEs Micro e Pequenas Empresas
MPS Melhoria do Processo de Software
MPS.BR Melhoria de Processos do Software Brasileiro
MSC Micro and Small Companies
PA Process Area (CMMI)
PDCA Plan, Do, Check, Action
PDS Processo de Desenvolvimento de Software
ProcSoftVD Modelo do Processo de Venda e Desenvolvimento de Software On-demand
para MPEs
ProcSoftVD - Gesto Modelo de Gesto do Processo de Venda e Desenvolvimento de Software
On-demand para MPEs
ProcSoftVD - Melhoria Mtodo de Melhoria do Processo de Venda e Desenvolvimento de Software
On-demand para MPEs
PRO2PI Perfil de Capacidade de Processo para Melhoria de Processo
PRO2PI-WORK PRO2PI Establishment Workshop Method
PSEE Process-Centered Software Engineering Environment
PV&DS Processo de Venda e Desenvolvimento de Software
RAD Rapid Application Development
RUP Rational Unified Process
SG Specific Goal
SOFTEX Associao para Promoo da Excelncia do Software Brasileiro
SPI Software Process Improvement
TI Tecnologia da Informao
TQM Total Quality Management
UP Unified Process
SUMRIO
LISTA DE FIGURAS/TABELAS/QUADROS ................................................................................................... 8

LISTA DE ABREVIATURAS E SIGLAS ........................................................................................................ 12
1. INTRODUO .......................................................................................................................................... 15
1.1. CONTEXTO DO TRABALHO DE PESQUISA ............................................................................................. 15
1.2. QUESTO DE PESQUISA ....................................................................................................................... 18
1.3. OBJETIVO ............................................................................................................................................ 18
1.4. JUSTIFICATIVA .................................................................................................................................... 18
1.5. LIMITAES ........................................................................................................................................ 21
1.6. ESTRUTURA DE APRESENTAO DO TRABALHO ................................................................................. 22
2. PROCESSO DE SOFTWARE.................................................................................................................. 24
2.1. CONSIDERAES INICIAIS ................................................................................................................... 24
2.2. MODELO CASCATA ............................................................................................................................. 26
2.3. MODELO INCREMENTAL...................................................................................................................... 26
2.4. MODELO ESPIRAL ............................................................................................................................... 28
2.5. RAD RAPID APPLICATION DEVELOPMENT ......................................................................................... 29
2.6. UNIFIED PROCESS ............................................................................................................................... 30
2.7. OPEN/UP ............................................................................................................................................. 32
2.8. ISO/IEC 12207 PROCESSOS DE CICLO DE VIDA DE SOFTWARE ........................................................ 33
2.9. CONSIDERAES FINAIS ..................................................................................................................... 34
3. MELHORIA DE PROCESSO DE SOFTWARE .................................................................................... 37
3.2. GESTO DE PROCESSOS DE NEGCIO CONCEITOS BSICOS ............................................................. 38
3.3. ALGUMAS ABORDAGENS PARA MELHORIA DE PROCESSO................................................................... 41
3.3.1. PDCA............................................................................................................................................. 41
3.3.2. IDEAL ............................................................................................................................................ 41
3.3.3. Ciclo de Melhoria da ISO/IEC 15504 ........................................................................................... 42
3.3.4. Metodologia de Gesto de Mudanas ........................................................................................... 43
3.3.5. PRO2PI-CYCLE ............................................................................................................................ 45
3.3.6. ASPE/MSC ..................................................................................................................................... 47
3.4. MODELOS DE REFERNCIA UTILIZADOS PARA MELHORIA DE PROCESSO ............................................ 48
3.4.1. Framework ISO/IEC 15504 e Modelo 15504-5 ............................................................................. 48
3.4.2. Framework SEI CMMI e Modelo CMMI-DEV .............................................................................. 52
3.4.3. MPS.BR e Modelo MR-MPS .......................................................................................................... 61
3.4.4. ISO 9000 ........................................................................................................................................ 62
3.4.5. PMBOK ......................................................................................................................................... 63
3.4.6. SWEBOK ....................................................................................................................................... 64
4. METODOLOGIA DE PESQUISA ........................................................................................................... 65
4.2. ABORDAGENS E MTODOS DE PESQUISA.............................................................................................. 66
4.3. ETAPAS DO TRABALHO ........................................................................................................................ 68
5. MODELO DE GESTO DO PROCESSO DE VENDA E DESENVOLVIMENTO DE SOFTWARE
ON-DEMAND PARA MPES (PROCSOFTVD GESTO) ........................................................................... 74
5.2. EVOLUO DO MODELO DE PROCESSO DE VENDA E DESENVOLVIMENTO DE SOFTWARE ON-DEMAND
PARA MPES (PROCSOFTVD) ............................................................................................................................. 75
5.2.1. Requisitos do ProcSoftVD ............................................................................................................. 85
5.2.2. Meta-modelo do ProcSoftVD ......................................................................................................... 86
5.2.3. Perspectivas do ProcSoftVD.......................................................................................................... 87
5.3. MTODO DE MELHORIA DO PROCESSO DE VENDA E DESENVOLVIMENTO DE SOFTWARE ON-DEMAND
PARA MPES (PROCSOFTVD MELHORIA) ........................................................................................................ 97
5.4. PUBLICAO WEB DO MODELO DE GESTO DO PROCESSO DE VENDA E DESENVOLVIMENTO ON-
DEMAND PARA MPES ....................................................................................................................................... 104
5.5. CONSIDERAES FINAIS .................................................................................................................... 112
6. APLICAES E RESULTADOS DO MODELO PROCSOFTVD - GESTO ................................ 113
6.1. CONSIDERAES INICIAIS ................................................................................................................. 113
6.2. APLICAO DO PROCSOFTVD - GESTO .......................................................................................... 113
6.3. ANLISE DOS PONTOS FORTES E FRACOS DO MODELO PROCSOFTVD .............................................. 114
6.4. ANLISE DAS CARACTERSTICAS DE QUALIDADE DO MODELO PROCSOFTVD................................... 119
7. CONCLUSES E TRABALHOS FUTUROS ....................................................................................... 123
7.1. CONSIDERAES INICIAIS ................................................................................................................. 123
7.2. CONCLUSES ..................................................................................................................................... 123
7.3. TRABALHOS FUTUROS ....................................................................................................................... 125
REFERNCIAS ................................................................................................................................................. 126
APNDICE 1 QUESTIONRIO PARA LEVANTAMENTO DE REAS DE CONHECIMENTO
RELEVANTES PARA ALGUMAS MPES ..................................................................................................... 132
APNDICE 2 RESULTADO DA ANLISE DO QUESTIONRIO DEFINIDO NO APNDICE 1.... 137
APNDICE 3 MODELO PROCSOFTVD (ATIVIDADES) ...................................................................... 139
APNDICE 4 MODELO PROCSOFTVD (TEMPLATES) ........................................................................ 213
APNDICE 5 MODELO PROCSOFTVD (MAPEAMENTO COM O CMMI E ISO/IEC 15504)........ 293
APNDICE 6 APLICAO DO PROCSOFTVD MELHORIA ............................................................ 312
APNDICE 7 QUESTIONRIO DE AVALIAO DO PROCSOFTVD ............................................... 317
APNDICE 8 PONTOS FORTES E FRACOS TRANSCRITOS DAS RESPOSTAS DO
QUESTIONRIO ENTREGUE AOS PROFISSIONAIS ............................................................................. 321
APNDICE 9 RESPOSTAS DO QUESTIONRIO RESPONDIDO PELOS PROFISSIONAIS .......... 327
Captulo 1. Introduo P g i n a | 15
1. INTRODUO
1.1. Contexto do Trabalho de Pesquisa

Segundo uma pesquisa realizada pelo Ministrio da Cincia e Tecnologia (MCT,
2005) sobre populao alvo constituda por empresas desenvolvedoras de software (de
pacote, sob encomenda (on-demand), embarcado e para uso prprio) e por empresas
distribuidoras ou editoras de software de terceiros, no total de 488 empresas, 396 so
empresas que desenvolvem software on-demand (81,1%). Adotando-se o critrio aplicado
fora de trabalho efetiva - microempresas (de 1 a 9 pessoas), pequenas (de 10 a 49
pessoas), mdias (de 50 a 99 pessoas) e grandes (100 ou mais pessoas) - 80,9% das micro
empresas e 85,9% das pequenas empresas desenvolvem software on-demand,
confirmando-se a predominncia de micro e pequenas empresas (MPEs) no cenrio de
desenvolvimento de software on-demand no Brasil.
Em busca de melhorar tanto a qualidade de seus produtos de software quanto a
produtividade do desenvolvimento de software, cada vez mais as MPEs esto percebendo a
importncia da existncia de um processo1 de software2 formalizado na empresa e
investindo na melhoria do processo de software. Essa afirmao pautada nos resultados
de uma reviso sistemtica, elaborada por PINO et al. (2008), realizada nas fontes: Science
Direct, Wiley InterScience, IEEE Digital Library, ACM Digital Library e um relatrio especial
Proceedings of the First International Research Workshop for Process Improvement in
Small Settings da SEI (Software Engineering Institute). No contexto brasileiro, comprova-se
um aumento do desempenho de processos de software o que auxilia na melhoria da
qualidade de produtos de software e no aumento das vantagens competitivas das empresas
brasileiras tanto no mercado nacional quanto internacional (ROCHA et al., 2005).
1
Processo: segundo a ABNT (Associao Brasileira de Normas Tcnicas), um conjunto de atividades inter-
relacionadas ou interativas, que transforma insumos (entradas) em produtos (sadas).
2
Processo de Software: segundo a IEEE (Institute of Electrical and Electronics Engineers), trata-se de uma
abordagem sistemtica, disciplinada e quantificvel para o desenvolvimento, operao e manuteno do
software.
Um processo de software bem estabelecido, compreendido e controlado auxilia aos
desenvolvedores obter um produto final com qualidade (SOFTWARE ENGINEERING
INSTITUTE, 2006).
Para o estabelecimento de um processo de desenvolvimento de software podem ser
usados como referncias: modelos3 de processo4 que descrevem atividades, como o Modelo
Cascata, Incremental, Espiral e RAD (Rapid Application Development) (PRESSMAN, 2006;
SOMMERVILLE, 2007); um framework de processo, tal como o UP (Unified Process)
(JACOBSON et al., 1999); uma norma, como a ISO/IEC 12207 (INTERNATIONAL
ORGANIZATION FOR STANDARDIZATION, 2001), que define as atividades, objetivos e
resultados de processos relacionados ao ciclo de vida do software e/ou, ainda, modelos e
normas de capacidade de processo5 que prescrevem melhores prticas, tais como CMMI
(SOFTWARE ENGINEERING INSTITUTE, 2002), ISO/IEC 15504 (INTERNATIONAL
ORGANIZATION FOR STANDARDIZATION, 2003) e MPS.BR (WEBER et al., 2005a),
metodologias geis, como Extreme Programming (WELLS, 2006) entre outras referncias.
De acordo com os dados disponibilizados pelo PBQP Software6 (WEBER et al.,
2006): 63,3% conhecem, mas no usam o CMMI (SOFTWARE ENGINEERING INSTITUTE,
op. cit); 65% conhecem, mas no usam a norma ISO/IEC 12207 (INTERNATIONAL
ORGANIZATION FOR STANDARDIZATION, op. cit) e 71,1% conhecem, mas no usam a
norma ISO/IEC 15504 (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, op.
cit).
3
Segundo Vernadat (1996), um modelo uma representao til de algum objeto. uma abstrao da realidade
expressa em termos de algum formalismo (ou linguagem) definido por um mtodo de modelagem em funo do
objetivo do usurio.
4
Modelos de processo de software: podem ser prescritivos, quando enfatizam a definio, identificao e
aplicao detalhada de atividades e tarefas de processo, e podem ser geis, quando enfatizam a adaptabilidade
(PRESSMAN, 2006). Neste trabalho de pesquisa, so chamados modelos de processo de software aqueles a
partir dos quais se pode definir, identificar e aplicar detalhadamente atividades e tarefas de processo. J os de
carter gil so denominados metodologias geis e no modelos.
5
Modelos/Normas de capacidade de processo: segundo a ISO/IEC 15504, capacidade de processo uma
caracterizao da habilidade do processo atingir aos objetivos de negcio atuais ou futuros. Sendo assim, neste
trabalho de pesquisa so denominados modelos/normas de capacidade de processo aqueles que possibilitam a
determinao da capacidade de um determinado processo.
6
Programa Brasileiro da Qualidade e Produtividade em Software que tem por objetivo atingir padres
internacionais de Qualidade e Produtividade no Setor de Software no Brasil. O PBQP Software composto por
voluntrios, interessados na melhoria da qualidade e produtividade em software, ligados ao Governo, Academia
e Indstria.
Devido dificuldade e alto custo de implantao e avaliao de modelos, como o
CMMI, pelas MPEs e a necessidade de expandir o mercado de software brasileiro, a
Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX) iniciou um
programa mobilizador denominado MPS.BR - Melhoria de Processo de Software Brasileiro
(WEBER et al., 2005a) - com o intuito de melhorar continuamente a qualidade de software
no Brasil a um custo acessvel (WEBER & ARAUJO, 2006; ROCHA et al., 2006).
O Modelo MPS.BR (Melhoria de Processos do Software Brasileiro) teve como bases
de construo as normas ISO/IEC 12207 e a ISO/IEC 15504 e as melhores prticas da
engenharia de software, alm de manter compatibilidade com o CMMI. A sua originalidade
no est no contedo, mas sim na estratgia de implementao, criada para a realidade
brasileira (SOFTEX, 2007).
Apesar da estratgia de implementao do MPS.BR ser mais adequada s MPEs
brasileiras, os relatos de implantao/melhoria de processos (em vrios nveis de
maturidade estabelecidos pelo MPS) por parte das MPEs citam o auxlio de consultores e
parcerias com universidades (BORSSATTO, 2008; MONTEIRO et al., 2008; OLIVEIRA et
al., 2008; PORTO et al., 2008; SCHEID et al., 2008; VARGAS, et al., 2008). Este fato
evidencia certa dificuldade por parte dessas MPEs em definir, implantar e melhorar seus
processos.
Melhorar continuamente os processos de negcio um dos objetivos da Gesto de
Processos de Negcio (BPM) - uma fonte de vantagem competitiva para a empresa (HUNG,
2006). Segundo Jeston & Nelis (2008) BPM tem por princpio alcanar os objetivos
estratgicos da organizao por meio da melhoria, gesto e controle de processos de
negcio essenciais.
Considerando esse contexto, seria bastante til alguma maneira de permitir s
prprias MPEs definirem, implantarem e melhorarem seu processo de software, atendendo
a modelos de capacidade de processo tais como o CMMI e a ISO/IEC 15504-5, de modo a
minimizar a necessidade de consultorias externas.

1.2. Questo de Pesquisa

De acordo com o exposto anteriormente, foi originada a seguinte questo de pesquisa
- a cuja resposta se pretende contribuir:
Considerando o contexto de gesto de processos de negcio, possvel criar um
modelo que auxilie as MPEs a definir seu processo padro7 de venda e desenvolvimento de
software on-demand, minimizando suas dificuldades em utilizar modelos/normas de
capacidade de processo, tais como CMMI, ISO/IEC 15504-5 e MPS.BR, e minimizando a
necessidade de consultorias externas?
1.3. Objetivo
Considerando a questo de pesquisa, este trabalho tem como principal objetivo criar
um modelo que oriente uma MPE, de maneira mais detalhada do que a sugerida pelos
modelos de capacidade de processo, na definio de seu processo padro de venda e
desenvolvimento de software on-demand, considerando o contexto de melhoria de
processo.
O objetivo secundrio do trabalho possibilitar que o modelo a ser criado permita
que a empresa selecione as reas de conhecimento que sero abordadas em cada ciclo de
melhoria do processo, de acordo com as suas prioridades.
1.4. Justificativa
Em busca de melhorar a qualidade de seus produtos de software e de ter maior
visibilidade das atividades do projeto de desenvolvimento de software, cada vez mais as
empresas esto enxergando a importncia de melhorar o seu processo de software e ter um
7
Processo padro: segundo o estabelecido no CMMI, uma definio operacional dos processos bsicos que
guiam o estabelecimento de um processo comum em uma organizao. Um processo padro descreve os
elementos de processo fundamentais que se espera serem incorporados em algum processo definido (processo
adaptado a partir do conjunto de processo padro, de acordo com as diretrizes de adaptao da organizao).
processo formalizado que sirva de guia para todos os envolvidos em um projeto, permitindo
uma viso comum entre eles.
Para auxiliar nessa misso, h na literatura, os chamados modelos de processo de
software, frameworks e normas de processo de software que tm por objetivo orientar na
definio de um processo de software e, tambm, os mtodos, modelos e abordagens para
orientarem na melhoria do processo de software.
Quanto aos mtodos, modelos e abordagens que orientam na melhoria do processo
de software, h vrios na literatura, como Ciclo PDCA (DEMING, 1986), Abordagem
IDEALSM (MCFEELEY, 1996), Ciclo de Melhoria da ISO/IEC 15504 (INTERNATIONAL
ORGANIZATION FOR STANDARDIZATION, 2003), Metodologia de Mudanas (COSTA,
2006) e alguns voltados para MPEs por serem mais detalhados, como PRO2PI-CYCLE
(SALVIANO, 2006) e ASPE/MSC (WEBER et al., 2005b).
Quanto aos modelos de processo de software, normalmente, eles prescrevem
apenas as atividades a serem realizadas sem fornecer detalhes, que facilitariam o
entendimento e uso do modelo por parte das MPEs. Alguns exemplos desses detalhes so:
os responsveis pelas atividades, suas tarefas, os artefatos de entrada necessrios para a
realizao das atividades, os artefatos resultantes da execuo das atividades, recursos que
podem ser utilizados e templates que fornecem informaes do contedo de cada um dos
artefatos.
A maioria dos modelos de processo de software existentes na literatura foca o
desenvolvimento do software. Entretanto, neste trabalho de pesquisa considera-se que a
comercializao do software uma rea relevante, no caso de desenvolvimento on-demand
(sob encomenda), pois a elicitao dos requisitos do produto a ser desenvolvido
inicialmente realizada durante as atividades de comercializao, a fim de se ter subsdio
para negociar um contrato. Assim, essa rea deve ser considerada juntamente ao
desenvolvimento de software.
Algumas limitaes dos modelos de processo de software existentes na literatura
so: no abordar a rea de comercializao junto ao desenvolvimento de software on-

demand e no dar nfase nas atividades de gesto de conhecimento e gesto de
habilidades e competncia em meio ao desenvolvimento do software. Por isso, como meta
para o modelo proposto buscou-se incorporar as atividades relacionadas s reas de
comercializao, gesto de conhecimento e gesto de habilidades e competncias.
Existem processos, tal como o RUP (Rational Unified Process) - embutido em
algumas ferramentas da Rational (KRUTCHEN, 2004) e o OpenUP (ECLIPSE PROCESS
FRAMEWORK COMMUNITY, 2008) um processo unificado gil embutido na ferramenta
free EPF Composer (Eclipse Process Framework) - que atendem s necessidades
anteriormente descritas e poderiam servir como modelo a ser utilizado pelas MPEs, mas
tambm no incluem atividades relacionadas comercializao de software, o que auxiliaria
as MPEs durante a negociao da venda do software para o cliente e acompanhamento do
fluxo de caixa e, tambm, no incluem atividades relacionadas ao gerenciamento da
memria organizacional da empresa - Gesto de Conhecimento - e nem atividades
relacionadas gesto de habilidades e competncias dentro da empresa o que auxilia a
criar a sua memria organizacional.
A engenharia de software pode ser vista como um processo de intensivo
conhecimento (BOGEN et al., 2005). Isso porque ela consiste de diferentes campos de
conhecimento, tais como anlise de requisitos, projeto de software, teste de software e
gesto de configurao de software (SWEBOK, 2004), e todos esses campos de
conhecimento tm em comum a existncia de uma grande variedade de fontes, uma alta
demanda por comunicao, um perodo de vida curto de conhecimento e alto custo no
processo.
importante para uma organizao de software saber trilhar quem conhece o qu
para fazer uso do conhecimento no documentado (conhecimento tcito). Uma boa soluo
para esse problema a gesto de competncias ou gesto de habilidades. O aprendizado a
partir da experincia requer uma memria de projeto e produto. O ambiente no qual o
engenheiro de software conduz seu trabalho dirio d suporte criao da memria. O
controle de verso, gesto de mudanas, documentao de decises de projeto (design

rationale) e rastreabilidade de requisitos so exemplos de prticas de engenharia de
software que auxiliam a construir memrias como uma forma efetiva de desenvolvimento de
software (RUS & LINDVALL, 2002).
Apesar de algumas barreiras para o uso efetivo de gesto de conhecimento (KM
Knowledge Management) na engenharia de software (DeSOUZA, 2003), foram encontradas
na literatura vrias abordagens de KM no PDS que relatam sobre experincias bem
sucedidas (MONTONI et al., 2004a, 2004b, 2005 e 2007; FALBO et al., 2004 e SEGRINI et
al., 2006; LIMA et al., 2006). Um exemplo de barreira a resistncia de ser conhecido como
um especialista: alguns especialistas tm receio de serem alocados somente em projetos
relacionados s suas experincias no passado ao invs de serem lanados a ele desafios
intelectuais (oportunidade de aprendizado) (DeSOUZA, 2003).
Pode-se dizer que, um processo de software tambm deve considerar, alm das
atividades de desenvolvimento propriamente ditas, outras atividades relacionadas aos
processos organizacionais e de apoio, tais como gesto de projeto, gesto de
conhecimento, gesto de requisitos e gesto de mudanas e de configurao. Essas
atividades so abordadas em modelos e normas, tais como ISO/IEC 12207, CMMI, ISO/IEC
15504 e MPS.BR, que prescrevem melhores prticas com o intuito de auxiliar na definio e
melhoria de processos de software. Contudo, para as MPEs, definir seu processo padro a
partir desses modelos uma tarefa rdua, pois requer especialistas com conhecimento em
qualidade de software e em modelagem de processo.
1.5. Limitaes
O modelo proposto neste trabalho de pesquisa tem as seguintes limitaes:
No est inserido em um Ambiente de Engenharia de Software Centrado em
Processo (PSEE), o que facilitaria para as MPEs a adequao do modelo para a
sua realidade. Um PSEE (Process-Centered Software Engineering Environment)
tambm conhecido por PCE (Process Centered Environments), PSE (Process

Sensitive Environments) ou PSS (Process Support System) (ARBAQUI et al.,
2002). PSEE constitui um tipo especial de ambiente de desenvolvimento de
software para apoiar a definio de processos de software, objetivando
automatizar a gerncia do desenvolvimento. Esses ambientes provem servios
para anlise, simulao, execuo e reutilizao das definies de processos,
que cooperam no aperfeioamento contnuo de processos.
Atende somente s reas de processo definidas para se alcanar o nvel 2 de
maturidade do CMMI e s reas de processo da categoria Engenharia para se
alcanar o nvel 3 de maturidade. Sendo assim, processos como suporte e
manuteno do software no so abordados pelo modelo elaborado neste
trabalho de pesquisa.
No est mapeado diretamente com os resultados esperados definidos pelo
MPS.BR. Entretanto, uma vez que o MPS.BR foi elaborado em consonncia com
os modelos internacionais CMMI e ISO/IEC 15504-5 e o modelo elaborado neste
trabalho de pesquisa est mapeado com os objetivos especficos do CMMI-DEV
e com as prticas-base da ISO/IEC 15504-5, pode-se dizer que o modelo
elaborado atende aos resultados esperados do MPS.BR.
No atende aos princpios definidos por metodologias geis, como Extreme
Programming (XP), SCRUM, FDD, entre outras.
Para ser utilizado como meio de certificao da empresa em nvel 2 de
maturidade CMMI-DEV, toda vez que o CMMI-DEV for atualizado, o mapeamento
das atividades do ProcSoftVD em relao ao CMMI e, se necessrio, as
atividades do ProcSoftVD devem ser atualizadas.
1.6. Estrutura de Apresentao do Trabalho

Este trabalho est organizado em captulos. No Captulo 2 so apresentados alguns
modelos de processo de software que auxiliam as empresas a definirem os processos e

atividades que faro parte do seu processo padro e a norma ISO/IEC 12207 que define os
processos de ciclo de vida do software.
O Captulo 3 apresenta alguns conceitos bsicos relacionados gesto de
processos de negcio (que tem como um dos objetivos a melhoria dos processos) e
algumas abordagens, mtodos e modelos que podem ser utilizados na melhoria de
processo de software. Apresenta, tambm, alguns modelos de capacidade de processo
utilizados como referncia pelas empresas para definirem o seu processo de software
padro e os outros modelos que poderiam ser utilizados como referncia.
No Captulo 4 so apresentados as abordagens e mtodos de pesquisa, e as etapas
realizadas no trabalho.
O Captulo 5 apresenta o Modelo de Gesto do Processo de Venda e
Desenvolvimento de Software On-Demand em MPEs (ProcSoftVD - Gesto), resultante
desse trabalho de pesquisa.
No Captulo 6 so apresentadas as aplicaes e anlises realizadas no ProcSoftVD -
Gesto, alm dos resultados das aplicaes. E, finalmente, no Captulo 7 so apresentados
as concluses e trabalhos futuros, as referncias bibliogrficas e os apndices.

2. PROCESSO DE SOFTWARE
2.1. Consideraes Iniciais

Segundo a IEEE, a engenharia de software a aplicao de uma abordagem
sistemtica, disciplinada e quantificvel para o desenvolvimento, operao e
manuteno do software. Sistemtica por partir do princpio de que existe um processo
de desenvolvimento definindo as atividades que devero ser executadas. Disciplinada,
pois parte do princpio de que os processos definidos sero seguidos. Quantificvel
por que se deve definir um conjunto de medidas a serem extradas do processo
durante o desenvolvimento, de forma que as tomadas de deciso relacionadas ao
desenvolvimento do software (por exemplo, melhoria de processo) sejam embasadas
em dados reais (SPNOLA & VILA, 2008). Essa abordagem refere-se a um processo
de software.
Segundo Paulk et al. (1995), para um processo de software funcionar
satisfatoriamente, deve possuir: procedimentos e mtodos que descrevam a relao
entre as tarefas; ferramentas e equipamentos que dem suporte realizao das
tarefas, simplificando e automatizando o trabalho; pessoas com perfil adequado,
treinadas nos mtodos e nas ferramentas para poderem realizar as atividades
adequadamente.
Para Salviano (2006), processo de software o que as pessoas fazem para
um determinado propsito, utilizando suas habilidades e conhecimento, com o apoio
de artefatos, ferramentas e outros recursos, para produzir software e seus produtos
associados.
Devido alta rotatividade de pessoas na indstria de software, h uma grande
probabilidade dos desenvolvedores originais no estarem disponveis quando surgirem
os problemas e forem necessrias modificaes (FIGUEIREDO et al., 2006). Esse
um dos motivos pelo qual se justifica a importncia de utilizar processos como guias
Captulo 2. Processo de Software P g i n a | 25
de conduo das atividades fundamentais de processo de desenvolvimento de
software (PDS) e das atividades gerenciais, organizacionais e de apoio relacionados
ao PDS.
H na literatura vrios modelos de processo de software que surgiram na
tentativa de auxiliar na definio de processos de software com qualidade cada um
deles com suas peculiaridades (PRESSMAN, 2006). Modelos de processo de
software so abstraes do processo de software descritos com uma linguagem formal
ou semi-formal denominada PML (Process Modeling Language or Formalism)
(CONRADI et al., 19928 apud ARBAQUI et al., 2002; LONCHAMP, 19939 apud
ARBAQUI et al., 2002). Podem ser entendidos como uma representao simplificada
do processo de software.
A fim de fornecer mecanismos de apoio aos realizadores de processo de
software, surgiram os Ambientes de Engenharia de Software Orientados a Processos
(PSEE Process-Centered Software Engineering Environment). Esses ambientes
permitem a customizao de um modelo de processo para um projeto especfico por
meio do refinamento e adaptao de um modelo de processo genrico (ARBAQUI et
al., 2002). Alguns exemplos de PSEE so: Eclipse Process Framework - EPF
(ECLIPSE FOUNDATION, 2008), Rational Method Composer (IBM, 2006), Visual
Studio Team System - VSTS (MICROSOFT, 2006), TABA (MONTONI et al., 2004a,
2004b, 2005 e 2007), Ontology-based Development Environment - ODE (FALBO et al.,
2004; SEGRINI et al., 2006) e WebAPSEE (LIMA et al., 2006).
Neste captulo sero abordados alguns modelos de processo de software, um
framework e uma norma que define os processos de ciclo de vida do software. Esses
8
CONRADI, R. C.; FERNSTROM, A.; FUGGETA, A.; SNOWDON, B. (1992). Towards a Reference
Framework for Process Concepts. In: Proceedings of the 2nd European Workshop on the Software
Process Technology, Lecture Notes in Computer Science, vol. 635, Trondheim, Norway.
9
LONCHAMP, J. (1993). A Structured Conceptual and Terminological Framework for Software Process
nd
Engineering. In: Proceeding of the 2 International Conference on the Software Process, IEEE Computer
Society Press, Berlin, Germany.
foram investigados para servirem de guia para uma MPE definir o seu processo
padro10.
2.2. Modelo Cascata

Trata-se do modelo mais antigo da engenharia de software (PRESSMAN,
2006; SOMMERVILLE, 2007) o qual sugere uma abordagem sistemtica e seqencial
ao desenvolvimento de software (Figura 2.1). O enfoque desse modelo est nos
documentos e nos artefatos.
Engenharia de
Sistemas
Anlise de
Requisitos
Projeto
Codificao
Testes
Manuteno
FIGURA 2.1 MODELO DE PROCESSO DE SOFTWARE CLSSICO (CASCATA)
Porm, apesar de ser bastante conhecido, a utilizao dele apresenta alguns
problemas: projetos reais raramente seguem o fluxo seqencial que o modelo prope;
logo no incio difcil estabelecer explicitamente todos os requisitos, pois no comeo
dos projetos sempre existe uma incerteza natural; o cliente deve ter pacincia, pois
uma verso executvel do software s fica disponvel em uma etapa avanada do
desenvolvimento.
2.3. Modelo Incremental

O Modelo Incremental combina elementos do modelo cascata de maneira
iterativa. Essa abordagem foi sugerida por Mills et al. (1987)11 apud (PRESSMAN,
10
Segundo o CMMI, Processo Padro refere-se definio operacional do processo bsico que guia o
estabelecimento de um processo comum na organizao.
2006) como um meio de reduzir o re-trabalho no processo de desenvolvimento de
software e de proporcionar aos clientes algumas oportunidades de adiar decises
sobre seus requisitos detalhados, at que eles tenham alguma experincia com o
sistema.
Os clientes identificam, em um esboo, as funes a serem fornecidas pelo
sistema (Figura 2.2). Eles identificam quais funes so mais prioritrias e, em
seguida, definida uma srie de estgios de entrega, com cada estgio fornecendo
um subconjunto das funcionalidades do sistema, de acordo com a priorizao do
cliente.
FIGURA 2.2 MODELO INCREMENTAL
As vantagens desse modelo so:
os clientes no precisam esperar que a verso final do software seja

entregue para us-lo;
os clientes podem utilizar os primeiros incrementos desenvolvidos como um
prottipo, de forma a definir melhor alguns requisitos do software;
existe um risco menor de fracasso do software;
como as funes prioritrias so entregues primeiro, inevitvel que estas
passem por um perodo de testes mais intensivo.
11
MILLS, H. D.; DYER, M.; LINGER, R. (1987). Cleanroom Software Engineering. IEEE Software,
setembro de 1987, p. 19-25.
2.4. Modelo Espiral

O Modelo Espiral (Figura 2.3), originalmente proposto por Boehm (1988)12
apud (BOEHM et al., 1998), usa uma abordagem cclica para desenvolver um sistema,
resultando em entregas incrementais da capacidade operacional do sistema.
DETERMINAR OBJETIVOS, AVALIAR ALTERNATIVAS

ALTERNATIVAS E IDENTIFICAR, RESOLVER RISCOS
Restries4
RESTRIES
Anlise de
Riscos 4
Alternativas4 Restries3
Anlise de
Riscos 3
Alternativas3 Restries2 Anlise de
Riscos 2
Alternativas2
Restries1 Anlise
Alternativas1 de Protti-
Oramento4 Oramento3 Oramento2 Oramento1 Riscos1 po1 Prottipo2 Prottipo3 Prottipo4
Concepo
Plano de Requisitos
da Requisitos de Projeto
Plano do ciclo de vida
Operao Software Detalhado
Plano de
Projeto de
Desenvolvimento
Validao de Software
Cdigo
requisitos
Plano de testes Testes de

Projeto verificado
Unidades
e de integrao e validado
Teste do
Sistema
PLANEJAR PRXIMA FASE Plano de Teste de
Implementao aceitao
DESENVOLVER, VERIFICAR O
PRODUTO NO PRXIMO NVEL
FIGURA 2.3 MODELO ESPIRAL
Cada ciclo envolve quatro principais atividades:
Elaborar os objetivos de processo e produto, restries e alternativas.
Avaliar as alternativas em relao aos objetivos e restries; identificar e
solucionar as principais fontes de risco do processo e produto.
Elaborar a definio do produto e processo.
Planejar o prximo ciclo e alterar o plano de ciclo de vida, incluindo a
partio do sistema em subsistemas para ser distribuda em ciclos
paralelos.
Pode-se dizer que o modelo espiral engloba os elementos do modelo cascata,
com a caracterstica de iterao do modelo incremental, adicionando um novo
12
Boehm, B.W. (1988). A Spiral Model of Software Development and Enhancement. Computer 21, 5, 61
72.
elemento: a Anlise de Risco. Pode ser criado um prottipo em qualquer etapa da
evoluo do produto, como mecanismo de reduo de riscos (SOMMERVILLE, 2007).
2.5. RAD Rapid Application Development

Trata-se de um modelo de processo de software incremental que enfatiza um
ciclo de desenvolvimento curto (MARTIN, 199113 apud SOMMERVILLE, 2007). Pode-
se dizer que uma adaptao do modelo cascata, onde o desenvolvimento rpido (em
um perodo de 60 a 90 dias) obtido devido abordagem de construo ser realizada
com base em componentes junto ao desenvolvimento realizado por vrias equipes
trabalhando em paralelo (Figura 2.4).
equipe # n
equipe # 2
equipe # 1 modelagem
modelagem do do negcio
modelagem do negcio modelagem
negcio
modelagem dos dados
modelagem dos dos dados modelagem
dados do processo
modelagem do
gerao da
modelagem do processo
aplicao
processo gerao da teste e
aplicao modificao
gerao da
aplicao teste e
modificao
teste e
modificao
60-90 dias
FIGURA 2.4 - MODELO RAD
Entretanto, para utilizar esse modelo necessrio que os requisitos sejam bem
compreendidos, antes de iniciar a construo do software. Algumas desvantagens
desse modelo: (1) para projetos grandes, o RAD exige recursos humanos suficientes
para criar um nmero adequado de equipes RAD; (2) se os desenvolvedores e clientes
no estiverem comprometidos com as atividades continuamente rpidas, o projeto
13
MARTIN, J. (1991). Rapid Application Development. Prentice-Hall.
falhar; (3) se o sistema no puder ser adequadamente modularizado, a construo
dos componentes necessrios ser problemtica; (4) o RAD pode no ser adequado
quando riscos tcnicos so altos (PRESSMAN, 2006).
2.6. Unified Process

O Unified Process (UP) um framework genrico para o desenvolvimento de
software que pode ser customizado para empresas ou projetos especficos. Esse
framework fundamentado em um conjunto de seis melhores prticas: desenvolver
software de forma iterativa, gerenciar os requisitos, utilizar arquitetura baseada em
componentes, modelar o software de forma visual, verificar a qualidade do software e
controlar as mudanas do software (JACOBSON et al., 1999). O RUP (Rational Unified
Process) foi originado do UP elaborado pela Rational Software Corporation que foi
adquirida pela IBM (KRUCHTEN, 2004).
Um dos princpios fundamentais do UP (Figura 2.4) o fato de ser iterativo e
incremental. Por isso, o projeto para desenvolvimento de sistema deve ser dividido em
mini-projetos, chamados iteraes.
Uma iterao uma seqncia completa de disciplinas (workflows), sendo que
o resultado de uma iterao um artefato ou uma srie de artefatos. Um artefato pode
ser um cdigo-fonte, um modelo, etc. Uma vez que os artefatos para uma fase
especfica foram completados ocorre a passagem para a prxima fase.

FIGURA 2.4 UNIFIED PROCESS. FONTE: TRADUZIDO DE (AMBLER, 2005)
As fases do UP so (AMBLER, 2005):
Concepo: nessa fase define-se o escopo do projeto, avalia-se a
tecnologia, os principais riscos so relacionados, as reas mais crticas a
serem tratadas so detectadas, verifica-se a viabilidade do projeto e
desenvolvido um planejamento para a natureza incremental e iterativa do
projeto.
Elaborao: nessa fase os requisitos so especificados em detalhes e a
arquitetura do software identificada e avaliada.
Construo: nessa fase o produto construdo e as suas verses beta so
testadas.
Transio: a verso do produto para entrega ao cliente testada e o
sistema implantado.
2.7. Open/UP
OpenUP (ECLIPSE PROCESS FRAMEWORK COMMUNITY, 2008) um
Processo Unificado enxuto que aplica as abordagens iterativas e incrementais dentro
de um ciclo de vida estruturado. Incorpora uma filosofia gil e que foca a natureza
colaborativa de desenvolvimento de software.
Em um projeto que utiliza OpenUP os esforos pessoais so organizados em
micro-incrementos. Esses representam pequenas unidades de trabalho produzidas em
poucas horas ou dias que fornecem feedback para direcionar decises adaptativas em
cada iterao (Figura 2.5).
OpenUP utiliza um ciclo de vida de iterao que estrutura como os micro-
incrementos so aplicados para produzir entregas estveis do sistema em semanas.
Essas iteraes so planejadas em um ciclo de vida de projeto composto por quatro
fases: concepo, elaborao, construo e transio.
FIGURA 2.5 OPENUP

FONTE: TRADUZIDO DE (ECLIPSE PROCESS FRAMEWORK COMMUNITY, 2008)
2.8. ISO/IEC 12207 Processos de Ciclo de Vida de Software

Essa norma junto s suas emendas - ISO/IEC 12207 AMD1 e AMD2
(INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 2001) - estabelece
uma estrutura comum para os processos de ciclo de vida de software, que pode ser
referenciada pela indstria de software. A estrutura contm processos, atividades e
tarefas que servem para ser aplicadas durante (a) a aquisio de um sistema que
contm software, de um produto de software independente ou de um servio de
software; (b) o fornecimento, desenvolvimento, operao e manuteno de produtos
de software.
A norma no especifica o como implementar ou executar as atividades e
tarefas, no determina um modelo de processo de software ou mtodo de
desenvolvimento e deve ser adaptada de acordo com o organizao e projetos
especficos.
Os processos de ciclo de vida esto organizados em categorias de processos
fundamentais, processos de apoio e processos organizacionais (Figura 2.6). Cada
categoria subdividida em grupos de processo.
Os Processos Fundamentais de Ciclo de Vida constituem um conjunto de
quatro grupos de processo que atendem as partes fundamentais (pessoa ou
organizao) durante o ciclo de vida de software: aquisio, fornecimento, engenharia
e operao.
Os Processos Organizacionais de Ciclo de Vida constituem um conjunto de
quatro grupos de processo que so empregados por uma organizao para
estabelecer e implementar uma estrutura subjacente, constituda de processos de ciclo
de vida e pessoal associado, e melhorar continuamente a estrutura e os processos. Os
grupos de processos organizacionais so: gerncia, melhoria de Processo, recursos e
infra-estrutura, e reuso.
Os Processos de Apoio de Ciclo de Vida constituem um conjunto de processos
que auxiliam a um outro processo contribuindo para o sucesso e qualidade do projeto

de software. Um processo de apoio empregado e executado, quando necessrio, por
outro processo. Os processos de apoio so: controle de configurao e garantia da
qualidade.
Processos de Ciclo de Vida Processos de Ciclo de Vida

FUNDAMENTAIS ORGANIZACIONAIS
Grupo de Processo Aquisio (ACQ) Grupo de Processo Gesto (MAN)

ACQ.1 Preparao da Aquisio MAN.1 Alinhamento Organizacional
ACQ.2 Seleo do Fornecedor MAN.2 Gesto Organizacional
ACQ.3 Acordo Contratual MAN.3 Gesto de Projetos
ACQ.4 Monitoramento do fornecedor MAN.4 Gesto de Qualidade
ACQ.5 Aceitao do cliente MAN.5 Gesto de Riscos
MAN.6 Medio
Grupo de Processo Fornecimento (SPL)
SPL.1 Prospeco de Fornecedor Grupo de Processo Melhoria de Processo (PIM)
SPL.2 Entrega do Produto PIM.1 Estabelecimento de Processo
SPL.3 Suporte de aceitao do produto PIM.2 Avaliao de Processo
PIM.3 Melhoria de Processo
Grupo de Processo Desenvolvimento (ENG)
ENG.1 Elicitao de Requisitos Grupo de Processo Infra-estrutura e Recurso (RIN)
ENG.2 Anlise de Requisitos de Sistema RIN.1 Gesto de Recursos Humanos
ENG.3 Projeto Arquitetural de Sistema RIN.2 Treinamento
ENG.4 Anlise de Requisitos de Software RIN.3 Gesto de Conhecimento
ENG.5 Projeto de Software RIN.4 Infra-estrutura
ENG.6 Construo de Software
ENG.7 Integrao de Software Grupo de Processo Reuso (REU)
ENG.8 Teste de Software REU.1 Gesto de Ativos
ENG.9 Integrao de Sistema REU.2 Gesto de Programa de Reuso
ENG.10 Teste de Sistema REU.3 Engenharia de Domnio
ENG.11 Instalao de Software
ENG.12 Manuteno de Software e Sistema
Grupo de Processo Operao (OPE)

OPE.1 Uso operacional
OPE.2 Suporte ao cliente
Processos de Ciclo de Vida SUPORTE
Grupo de Processo Suporte (SUP)

SUP.1 Garantia de Qualidade SUP6. Avaliao de Produto
SUP.2 Verificao SUP.7 Documentao
SUP3. Validao SUP.8 Gesto de Configurao
SUP4. Reviso Conjunta SUP.9 Gesto de Resoluo de Problema
SUP.5 Auditoria SUP.10 Gesto de Solicitao de Mudanas
FIGURA 2.6 ISO/IEC 12207 - PROCESSOS DE CICLO DE VIDA DE SOFTWARE

FONTE: TRADUZIDO DE (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 2001)
2.9. Consideraes Finais

Os modelos cascata, espiral, incremental e RAD (PRESSMAN, 2006;
SOMMERVILLE, 2007) so considerados modelos tradicionais e tm caractersticas
de modelos prescritivos modelos que prescrevem um conjunto de elementos de
processo e tem nfase em documentao e controles.
O Modelo Cascata no retrata fielmente o que acontece no desenvolvimento de
projetos reais, devido sua caracterstica de desenvolvimento seqencial (conclui-se

uma fase para posteriormente iniciar a prxima). Essa deficincia foi suprida pelos
modelos incremental e espiral que foram utilizados como base do framework de
processo UP (Unified Process) (JACOBSON et al., 1999), pois sugere que o processo
seja realizado de forma incremental e iterativa.
O modelo RAD til em situaes peculiares: quando o desenvolvedor
compreende todos os requisitos do software e re-utiliza componentes para agilizar o
processo de desenvolvimento que deve ser realizado em um perodo de 60 a 90 dias.
Todos esses modelos (cascata, incremental, espiral e RAD), apesar de serem
prescritivos, prescrevem apenas as atividades a serem realizadas sem fornecer mais
detalhes (como os responsveis pelas atividades, suas tarefas, os artefatos de entrada
necessrios para a realizao das atividades, os artefatos resultantes da execuo
das atividades, recursos que podem ser utilizados e templates que fornecem
informaes do contedo de cada um dos artefatos), o que facilitaria o entendimento e
uso do modelo por parte das MPEs.
O RUP - Rational Unified Process (KRUTCHEN, 2004) - embutido em algumas
ferramentas da Rational e o OpenUP (ECLIPSE PROCESS FRAMEWORK
COMMUNITY, 2008) um processo unificado gil embutido na ferramenta free EPF
Composer (Eclipse Process Framework) prescrevem elementos alm das atividades
a serem realizadas e poderiam servir como modelo a ser utilizado pelas MPEs, mas
no incluem atividades relacionadas comercializao de software, o que auxiliaria as
MPEs durante a negociao da venda do software para o cliente e acompanhamento
do fluxo de caixa e, tambm, no incluem atividades relacionadas ao gerenciamento
da memria organizacional da empresa - Gesto de Conhecimento e nem atividades
relacionadas gesto de habilidades e competncias dentro da empresa.
A norma ISO/IEC 12207 (INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION, 2001) prescreve as atividades do processo de ciclo de vida de
software, porm no define a seqncia de execuo das atividades (por exemplo,
linear ou evolutiva), o que definido pelos modelos cascata, espiral, incremental,

framework UP e outros. Entretanto, pode ser utilizada como referncia para a definio
do processo de software padro de uma empresa.

3. MELHORIA DE PROCESSO DE SOFTWARE

Melhorar continuamente os processos de negcio um dos objetivos da
Gesto de Processos de Negcio (BPM) - uma fonte de vantagem competitiva para a
empresa (HUNG, 2006). Segundo Jeston & Nelis (2008) BPM tem por princpio
alcanar os objetivos estratgicos da organizao por meio da melhoria, gesto e
controle de processos de negcio essenciais. A melhoria tem o objetivo de tornar os
processos de negcio mais eficientes e eficazes. A gesto refere-se medio e
gerenciamento do desempenho dos processos e das pessoas. E, o controle obtido
por meio da medio dos processos de negcio em um ciclo de melhoria, tal como o
PDCA (DEMING, 1986).
A melhoria do processo de software considerada parte da engenharia de
processo de software (EL EMAM, 2004). Esta pode ser examinada em dois nveis: o
primeiro refere-se s atividades tcnicas e gerenciais dentro dos processos de ciclo de
vida que so realizados durante a aquisio, desenvolvimento, manuteno e retirada
do software; o segundo um meta-nvel, referente definio, implementao,
avaliao, medio, gerenciamento, mudanas e melhorias dos prprios processos de
ciclo de vida.
Segundo Salviano (2006), Melhoria de Processo de Software uma
abordagem para a melhoria de organizaes intensivas em software, baseada em
modelos de capacidade de processo de software, por meio do estabelecimento,
avaliao e melhoria da capacidade de seus processos mais importantes,
relacionados s atividades de aquisio, fornecimento, operao, desenvolvimento,
manuteno, gerncia, melhoria e/ou apoio de sistemas de software, com o objetivo
de satisfazer de forma mais eficiente e eficaz os objetivos estratgicos da
organizao.
Captulo 3. Melhoria de Processo de Software P g i n a | 38
H na literatura vrias abordagens para melhoria de processo, que podem ser
utilizadas como guia, tais como: PDCA (DEMING, 1986), IDEAL (MCFEELEY, 1996),
Ciclo de Melhoria da 15504 (INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION, 2003), Metodologia de Gesto de Mudanas (COSTA, 2006).
H, tambm, algumas abordagens elaboradas especificamente para o caso de MPEs,
como PRO2PI-CYCLE (SALVIANO, 2006) e ASPE/MSC (WEBER et al., 2005b), por
terem orientao detalhada das atividades a serem realizadas (como fazer). Essas
abordagens so comentadas neste captulo.
A melhoria de processo utiliza um ou mais modelos como referncia para
orientar as aes de melhoria. Dentre esses modelos de referncia14 esto os modelos
de capacidade de processo, tais como OPM3 (PROJECT MANAGEMENT INSTITUTE,
2003), os modelos de capacidade do CMMI (SOFTWARE ENGINEERING INSTITUTE,
2006) e da ISO/IEC 15504 (INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION, 2003), MR-MPS (WEBER et al., 2005a; SOFTEX, 2006) e
outros modelos como PMBOK (PROJECT MANAGEMENT INSTITUTE, 2004),
SWEBOK (ABRAN et al., 2004) e ISO 9000 (INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION, 2000). Alguns desses modelos de referncia so comentados
neste captulo.
3.2. Gesto de Processos de Negcio Conceitos Bsicos

Processos de negcio so fatores chaves na integrao de uma empresa
(AGUILAR-SAVN & OLHAGER, 2002). Segundo Rozenfeld et al. (2006), processos
de negcio compreendem um conjunto de atividades organizadas entre si visando
produzir um bem ou servio para um tipo especfico de cliente (interno ou externo
14
Modelo de referncia pode ser definido como um framework para entendimento de relacionamentos
significativos entre as entidades de algum ambiente, e para o desenvolvimento de padres ou
especificaes consistentes que apiam o ambiente (Consultative Committee for Space Data Systems,
Reference Model for an Open Archival Information System (OAIS), CCSDS 650.0-R-1.2, Red Book, June
2001) apud (SALVIANO, 2006).
empresa). Os processos de negcio podem representar operaes repetitivas da
empresa, que normalmente so estruturadas (exemplo: gesto financeira e gesto de
produo). Outros processos de negcio no so to estruturados, como o caso do
PDS (processo de desenvolvimento de software on-demand), uma vez que cada
desenvolvimento de um software especfico pode ser diferente.
Esses processos de negcio precisam ser gerenciados, de acordo com os
objetivos estratgicos da organizao para alcanar de modo eficiente esses objetivos.
Por isso, importante que estes processos estejam associados a uma abordagem de
gesto a Gesto de Processos de Negcio (BPM Business Process Management).
Essa abordagem pode ser visualizada tanto pela perspectiva de negcios quanto de
tecnologia (SMITH & FINGAR, 2003). Considerando a perspectiva de negcios, BPM
considerada uma das melhores prticas dentre os princpios de gesto para auxiliar as
organizaes a sustentarem sua vantagem competitiva (KILMANN, 1995).
As razes da BPM podem sem encontradas voltando na dcada de 80 com a
filosofia de TQM (Total Quality Management Gesto da Qualidade Total) e na
dcada de 90 com a Reengenharia de Processo de Negcio (Business Process
Reengineering - BPR). Os estudos de Davenport (1993) e Zairi & Sinclair (1995)
indicam que TQM de natureza incremental, evolucionria e contnua. Em oposio,
BPR de natureza radical, revolucionria e ocorre de uma vez s. A partir de uma
perspectiva holstica, BPM integra as abordagens TQM e BPR as quais podem ser
consideradas como apropriadas para a melhoria de desempenho de processos de
negcio na maioria das circunstncias (HUNG, 2006).
BPM tem o objetivo de entender e organizar a empresa como processos de
negcio (SMITH & FINGAR, 2003). Por outro lado, existem autores que enfatizam
BPM como uma ferramenta tecnolgica, vista como uma evoluo de sistemas de
gesto de workflow (AALST et al., 2003). Neste caso, o ciclo de vida de BPM tem
quatro fases: projeto de processo, configurao de sistema, promulgao e
diagnstico. O foco de sistemas tradicionais de gesto de workflow nas fases de

projeto de processo e promulgao de processo do ciclo de vida de BPM. Esta
definio de BPM estende a tradicional abordagem de gesto de workflow para
suportar a fase de diagnstico e permite por meio de novos caminhos apoiar o
processo operacional (AALST et al., 2003; AALST, 2004).
No presente trabalho de pesquisa o escopo considerar a melhoria do modelo
de Processo de Venda e Desenvolvimento de Software (PV&DS) on-demand em um
contexto de BPM mais abrangente - o foco sobre a viso de negcio de BPM. De
qualquer modo, a implementao de tecnologia BPM uma questo muito importante,
tanto que considerada em sistemas de Gesto de Ciclo de Vida de Produto (Product
Lifecycle Management PLM).
Para Zairi (1997) essa abordagem dependente de elementos estratgicos,
elementos operacionais, do uso de ferramentas e tcnicas modernas, do envolvimento
de pessoas e, o mais importante, tem um foco horizontal que possibilita o atendimento
dos requisitos do cliente da melhor forma possvel. Em BPM, o alinhamento das
operaes de negcio com as prioridades estratgicas e o envolvimento de pessoas
so conceitos fundamentais na busca pela competitividade (ZAIRI, 1997; MCKAY &
RADNOR, 1998).
Hung (2006) entende BPM como uma filosofia de gesto integrada e um
conjunto de prticas que incluem mudanas incrementais e radicais no processo de
negcio, e enfatiza a melhoria contnua, satisfao do cliente e envolvimento dos
funcionrios. Nesse contexto, a gesto de mudanas se integra abordagem BPM.
Zairi (1997) afirma que o BPM tem que ser governado por alguns princpios,
dentre eles: (1) as principais atividades tm que ser devidamente mapeadas e
documentadas; (2) BPM cria um foco nos clientes por meio de ligaes horizontais
entre as atividades; (3) BPM dependente de sistemas e procedimentos
documentados para assegurar disciplina, consistncia e repetibilidade no desempenho
da qualidade; (4) BPM dependente de atividades de medio para avaliar o

desempenho de cada processo individualmente; (5) BPM tem base em uma
abordagem contnua de otimizao e (6) BPM uma abordagem de mudana cultural.
A fim de complementar a definio dos princpios da BPM, Hung (2001)15 apud
Hung (2006) inclui: a viso holstica, a autoridade estratgica, a TI (tecnologia da
informao) que permite o gerenciamento dos processos de negcio, a transformao
do negcio, o impacto por toda a organizao e a nfase inter-funcional da gesto do
processo.
3.3. Algumas Abordagens para Melhoria de Processo

3.3.1. PDCA
A idia original do PDCA (Plan, Do, Check, Action) foi desenvolvida na dcada
de 1930 por Shewhart e popularizado por Deming (1986) como sendo um ciclo de
controle estatstico do processo que pode ser repetido continuamente sobre qualquer
processo ou problema. O incio do ciclo PDCA se d com o planejamento do que ser
feito e com a definio de metas e mtodos para atingir essas metas. Este plano
implantado, coletando-se dados e realizada a verificao dos resultados em relao
s metas definidas. Posteriormente, so tomadas aes corretivas ou de melhoria,
caso necessrio.
3.3.2. IDEAL
O modelo IDEAL (Initiating, Diagnosing, Establishing, Acting, Learning) foi
criado pelo SEI (Software Engineering Institute) para o aprimoramento contnuo do
processo de desenvolvimento de software (MCFEELEY, 1996). Foi desenvolvido para
ser uma ferramenta de apoio implantao do CMM (Capability Maturity Model) para
software.
15
HUNG, R. Y. (2001). An empirical examination of the relationship between BPM and business
performance: a study of Australias top 1000 companies (unpublished PhD dissertation, The University of
Sydney).
Trata-se de um modelo de programa de melhoria de processo de software (SPI
Software Process Improvement) usado para guiar o desenvolvimento de um plano
integrado para inicializao e gerenciamento de um programa de SPI. Esse modelo
composto por 5 fases que compem o ciclo de melhoria. importante ressaltar que o
tempo para completar um ciclo por completo pode variar de organizao para
organizao.
O ciclo de melhoria comea com a fase de Inicializao que foca o
comprometimento dos recursos iniciais e o estabelecimento da infra-estrutura
necessria para a melhoria. A segunda fase o Diagnstico que estabelece os nveis
atuais de maturidade de processo, a descrio atual do processo e inicia o
desenvolvimento de um plano de ao. A terceira fase o Estabelecimento com o
objetivo de estabelecer metas e prioridades e completar o plano de ao. A quarta
fase a Ao na qual realiza-se a pesquisa e so desenvolvidas solues para os
problemas do processo, expandindo as melhorias de processo com sucesso para toda
a organizao. Por fim, a fase Alavancagem tem o objetivo a preparao para o
prximo ciclo, a partir da fase de Diagnstico, e aplicao das lies aprendidas para
refinar o processo de SPI.
3.3.3. Ciclo de Melhoria da ISO/IEC 15504
A parte 4 da norma ISO/IEC 15504 (INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION, 2003) descreve orientaes para utilizao de modelos para
melhoria de processo ou determinao da capacidade de processo.
O guia de melhoria de processo composto por 8 (oito) etapas. Na primeira
etapa examinam-se os objetivos de negcio da organizao e a motivao existente
para melhorar. Na segunda etapa o programa de melhoria do processo iniciado; ele
deve ser implementado e gerenciado como um projeto com definio de responsveis,
oramento, cronograma, milestones, entre outros. Na terceira etapa avalia-se a

capacidade atual do processo, utilizando como referncia as partes 2 (framework de
avaliao) e 3 (guia de execuo da avaliao) da ISO/EC 15504. Na quarta etapa, o
resultado da avaliao analisado e confrontado com os objetivos de negcios da
organizao para: identificar, analisar e listar as reas de melhoria; definir os objetivos
especficos da melhoria e derivar um plano de ao. Na quinta etapa, o plano de ao
implementado para melhorar os processos da organizao. Essa implementao
pode ser simples ou complexa, dependendo do contedo do plano de ao e das
caractersticas da organizao. Em geral, vrios projetos de implementao podem ser
iniciados, cada um concentrado em implementar uma ou mais aes definidas no
plano de ao. Na sexta etapa, quando os projetos de implementao foram
realizados, a organizao deve: confirmar se os objetivos planejados foram
alcanados e se os benefcios esperados se concretizaram; checar se os processos e
prticas apropriados foram adotados; confirmar que a cultura organizacional foi
modificada, conforme apropriado; re-avaliar os riscos associados ao programa de
melhoria do projeto e re-avaliar os custos e benefcios. Na stima etapa devem ser
sustentadas as melhorias, mantendo a melhoria do nvel de capacidade alcanado.
Isso requer gerenciamento para monitorar a institucionalizao dos processos
melhorados. A ltima etapa tem como objetivo monitorar continuamente o
desempenho dos processos da organizao e iniciar melhorias em novos processos,
como parte do programa de melhoria contnua.
3.3.4. Metodologia de Gesto de Mudanas
A Metodologia de Gesto de Mudanas foi concebida a partir da sistematizao
das atividades de mtodos de gesto de mudana analisados por Costa (2006).
Na primeira fase da metodologia (Figura 3.1), Definio da Mudana, avalia-
se a necessidade de mudana e seus objetivos juntamente estratgia empresa. Na
fase de Diagnstico realizada a anlise da situao atual. Na fase seguinte, Definir

portflio de projetos, as propostas de projetos de mudanas existentes so analisadas
e suas implantaes so priorizadas. importante ressaltar que essa fase s ocorre
quando existem vrios projetos de mudana.
FIGURA 3.1 METODOLOGIA DE GESTO DE MUDANAS. FONTE: (COSTA, 2006)
Para cada um dos projetos selecionados, dado incio fase Planejar a
mudana, em que por meio do escopo do projeto, so definidos e refinados os
objetivos da mudana e planejadas as aes necessrias para se alcanar esses
objetivos. Nessa fase, tambm so elaborados a WBS (work breakdown structure) e o
cronograma do projeto. Na fase Analisar a situao atual, feito um diagnstico mais
detalhado da situao corrente, levantados os requisitos da mudana e os dados
quantitativos e qualitativos da situao em que o projeto de melhoria est intervindo.
Na fase seguinte, Projetar a situao futura, projetada a soluo,
considerando-se os objetivos iniciais do projeto de melhoria e a opinio dos
interessados (stakeholders) no projeto de mudana, para que as possveis resistncias
sejam minimizadas. Na fase Implementar a mudana so realizados os treinamentos
e implantada a mudana e comunicada a todos os envolvidos. Por fim, na fase
Validar a mudana, aps um perodo de institucionalizao da mudana, verificado
se houve algum desvio na implantao. analisado se o problema inicial e a

necessidade de mudana foram satisfeitos e, por fim, comunicado o encerramento do
projeto em questo.
3.3.5. PRO2PI-CYCLE
Salviano (2006), em sua pesquisa, caracteriza as diferenas e similaridades
entre as arquiteturas estagiada e contnua para modelos de capacidade de processo e
faz reflexes sobre tais arquiteturas para subsidiar uma evoluo da atual melhoria de
processo para uma melhoria mais vivel e mais adequada ao contexto e objetivos
estratgicos da organizao: uma Engenharia de Processo Dirigida por Perfil de
Capacidade de Processo (Process Capability Profile Driven Process Engineering
PDCE). A partir dessas reflexes, identifica trs geraes de arquiteturas de modelos
de capacidade de processo. So elas:
Arquitetura estagiada fixa (1 gerao): os modelos desta gerao so
compostos por uma seqncia de PCP (perfil de capacidade de processo), onde cada
um composto por uma combinao fixa de reas de processo em um determinado
nvel de capacidade de processo. A utilizao de um modelo deste tipo deve seguir
exatamente o que ele prope, podendo apenas ser interpretadas as orientaes para
o contexto da utilizao. Exemplos: modelo na representao estagiada do CMMI,
MR-MPS (Modelo de Referncia) do MPS.BR.
Arquitetura contnua fechada (2 gerao): as reas de processo e os
nveis de capacidade de processo so fixos e as suas combinaes so variveis. A
utilizao de um modelo com este tipo de arquitetura passa pela escolha de um PCP,
a partir dos nveis de capacidade de processo e reas de processo, seguindo as
regras de composio. Exemplos: ISO/IEC 15504-5 e modelo na representao
contnua do CMMI.
Arquitetura contnua aberta (3 gerao): apenas os nveis de capacidade
so fixos. Com isto, podem ser definidos conjuntos de reas de processo e, ento,
definidas combinaes de reas de processo e nveis de capacidade de processo em
PCPs. A utilizao de modelos com este tipo de arquitetura passa por uma etapa
anterior s da utilizao de modelos com arquitetura da 2 gerao, pois inclui a
escolha ou definio de reas de processo. Assim, aumenta-se a flexibilidade e as
oportunidades de melhor alinhamento da melhoria com a organizao. Entretanto,
aumenta-se o risco de escolhas inadequadas, o que leva ao aumento da necessidade
de metodologias para sua utilizao.
A evoluo da atual melhoria de processo - PDCE, proposta por Salviano
(2006), fundamentada na utilizao da 3 gerao de arquitetura de modelos de
capacidade contnua aberta. Como representante dessa gerao, Salviano (2006)
prope a extenso do ISO/IEC 15504. Ele defende que, em geral, a melhoria de
processo pode ser baseada em PCPs dinmicos e especficos, ou ainda, em nveis de
maturidade dinmicos e especficos. Assim, diluda a separao rigorosa entre
definio de modelos (hoje feita mais por institutos) e a utilizao de modelos, uma
vez que uma organizao ao fazer a melhoria de processo, tambm define modelos
por meio de PCPs.
O estabelecimento de perfil de capacidade de processo pode ser visto como
uma rea de processo, segundo o CMMI, ou como um processo do grupo de melhoria
de processo PIM (Process Improvement Process Group) da norma ISO/IEC 12207 e
do modelo ISO/IEC 15504-5.
Para experimentar, validar e evoluir a Engenharia de Processo Dirigida por
Perfil de Capacidade de Processo (PDCE), Salviano (2006) prope a abordagem
PRO2PI16 (Perfil de Capacidade de Processo para Melhoria de Processo).
PRO2PI-CYCLE um processo para ciclo de melhoria com PRO2PI, composto
por seis fases: 1. Inicia o ciclo de melhoria, 2. Avalia prticas correntes, 3. Planeja
16
PRO2PI: uma abstrao, segundo o aspecto de capacidade de processo, de um processo, e pode ser
utilizado como referncia para a melhoria do processo atual para o estado estabelecido por ele, em uma
organizao.
aes de melhoria, 4. Realiza aes de melhoria, 5. Prepara a institucionalizao da
melhoria e 6. Institucionaliza a melhoria.
Para tornar vivel para MPEs intensivas em software, com processos de baixa
capacidade (que buscam at o nvel 3 de capacidade, segundo a 15504, por exemplo),
iniciarem um ciclo de melhoria, estabelecendo um PRO2PI, Salviano (2006) definiu um
mtodo, denominado PRO2PI-WORK (PRO2PI Establishment Workshop Method).
Esse mtodo realiza de forma compactada as atividades das trs primeiras etapas do
ciclo de melhoria PRO2PI-CYCLE.
3.3.6. ASPE/MSC
ASPE/MSC (Approach for Software Process Establishment in Micro and Small
Companies) tem o objetivo de estabelecer processos de software voltada para MPEs,
de forma incremental, visando a melhoria contnua (WEBER et al., 2005b).
Para o estabelecimento de processos de software no contexto de MPEs
necessrio que haja baixo investimento, fcil compreenso, orientao detalhada das
atividades a serem executadas (como fazer), ser de domnio pblico, suporte de guias
para sua implantao e adaptao, entre outros.
As fases dessa abordagem so: 1. Diagnstico do Processo de Software Atual,
obtido por meio de um mtodo de avaliao especfico para MPEs); 2. Anlise
Estratgica para definio e priorizao das aes para o estabelecimento de
processos na empresa; 3. Definio do Processo, de forma explcita e descritiva para
que as pessoas se orientem na execuo das atividades; 4. Implantao do Processo
por meio da institucionalizao e avaliao do processo que foi definido na
organizao.
3.4. Modelos de Referncia utilizados para Melhoria de

Processo
Alguns modelos de referncia existentes na literatura, tanto modelos de
capacidade de processo quanto outros modelos que podem ser usados como
referncias para a melhoria de processo so apresentados, a seguir.
3.4.1. Framework ISO/IEC 15504 e Modelo 15504-5
A ISO/IEC 15504 (INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION, 2003) um framework de avaliao de processo genrico para
qualquer rea de tecnologia, inclusive a engenharia de software, com dois contextos
de uso: Melhoria do Processo e Determinao da Capacidade de Processo. No
primeiro contexto, o resultado identifica a capacidade do processo que utilizada para
identificar mudanas de melhoria. J no segundo contexto, a capacidade identificada
utilizada para descobrir riscos que o processo avaliado incorre e, tambm, pode ser
utilizado como motivao para a melhoria do processo.
A norma ISO/IEC 15504 est descrita em cinco partes: a parte 1 refere-se aos
conceitos, a parte 2 descreve o framework de avaliao, a parte 3 descreve
orientaes para uso do framework descrito na parte 2 e a parte 4 descreve
orientaes para utilizao de modelos para melhoria ou determinao da capacidade.
A parte 5 - 15504-5 (Information Technology An exemplar Process Assessment
Model) - refere-se a um modelo de avaliao exemplo que apia a realizao de uma
avaliao por meio de indicadores que orientam na interpretao dos objetivos e
resultados definidos nas emendas Amd 1 e Amd 2 da ISO/IEC 12207 e dos atributos
de processo definidos na 15504-2. Esse modelo aborda a rea de engenharia de
software, embora a ISO/IEC 15504 possa ser utilizada em qualquer rea tecnolgica.
A arquitetura definida pela ISO/IEC 15504 contnua, com duas dimenses:
uma que define os processos (dimenso de processo) e outra que define os nveis de
capacidade que cada um dos processos pode ter ao serem estabelecidos na
organizao (dimenso de capacidade).
A dimenso de processo usa as definies de processos das emendas Amd1 e
Amd2 da ISO/IEC 12207 (INTERNATIONAL ORGANIZATION FOR
STANDARDIZATION, 2001) para identificar um Modelo de Referncia de Processo.
Os processos do Modelo de Referncia so classificados em trs categorias:
fundamentais do ciclo de vida, de apoio ao ciclo de vida e organizacionais. Os
processos fundamentais so essenciais durante o ciclo de vida do software e esto
agrupados em: processos de aquisio, de fornecimento, de desenvolvimento e de
operao. Os processos organizacionais so utilizados para estabelecer e
implementar uma estrutura subjacente na organizao, e tambm, para melhorar
continuamente a estrutura e os processos. Esses processos esto agrupados em:
processos de gerenciamento, de melhoria de processo, de infraestrutura e recursos, e
de reuso. J os processos de apoio ao ciclo de vida consistem de processos que do
suporte a outros processos como uma parte integrante, com um propsito distinto, e
contribui para o sucesso e qualidade do projeto de software.
Cada processo no Modelo de Avaliao descrito em termos da declarao de
um propsito. A lista de resultados associada a cada declarao do propsito do
processo, como uma lista de resultados positivos esperados da realizao, ou melhor,
do desempenho do processo. A satisfao do propsito de um processo representa o
primeiro passo em direo ao nvel 1 de capacidade de processo onde os resultados
esperados so observveis.
O Modelo de Avaliao de Processo expande as definies de processo do
Modelo de Referncia de Processo incluindo um conjunto de indicadores de
desempenho de processo: prticas base e produtos de trabalho. Uma prtica base
uma atividade direcionada ao propsito de um processo que identifica o qu deve ser
feito, sem especificar o como. Para cada processo, de acordo com a dimenso
processo, h um conjunto de prticas base definidas ao qual, uma vez realizado,

proporciona o alcance dos resultados que refletem o propsito do processo; cada
prtica base explicitamente associada a um resultado do processo. A realizao de
um processo produz produtos de trabalho que so identificveis e utilizados para
alcanar o propsito do processo; cada produto de trabalho de entrada e sada
relacionado a um ou mais resultados. As prticas base e produtos de trabalho so
usados para medir o grau de alcance do atributo desempenho do processo avaliado,
ou seja, do suporte avaliao de um processo em relao ao nvel 1 de
capacidade. Cada produto de trabalho tem um conjunto de caractersticas do produto
que o identifica e pode ser usado como referncia na reviso do produto de trabalho a
fim de avaliar a realizao/desempenho efetivo de um processo.
A dimenso de capacidade do Modelo de Avaliao de Processo utiliza as
definies de nveis de capacidade e atributos de processo da 15504-2 e expande
cada um dos nove atributos por meio da incluso de um conjunto de indicadores de
capacidade de processo (prticas genricas, recursos genricos e produtos de
trabalho genricos). Atributos de processo (PA process attributes) so
caractersticas de um processo que podem ser avaliadas de acordo com uma escala
de desempenho, fornecendo uma medida da capacidade do processo. Cada atributo
mede um aspecto particular da capacidade do processo necessrio para apoiar a
melhoria do processo e a determinao da capacidade. Um nvel de capacidade um
conjunto de atributos de processo que trabalham juntos para fornecer uma
alavancagem na capacidade de desempenho de um processo. Esses nveis
constituem um caminho racional de progresso por meio da melhoria da capacidade de
algum processo.
As prticas genricas (GP) so atividades genricas que fornecem um guia
para a implementao dos atributos de processo; muitas delas so prticas gerenciais.
Os recursos genricos (GR) so pessoas, ferramentas, mtodos e infraestrutura que
podem ser usados na realizao dos atributos de processo. E, os produtos de trabalho
genricos (GWP) so conjuntos de caractersticas evidenciadas nos produtos de

trabalho como resultado da realizao de um atributo. Os GWP so identificados de
01-00 21-00; para cada um deles h produtos de trabalho especficos (SWP)
identificados pelos dois primeiros dgitos do identificador do GWP seguido de dois
dgitos seqenciais. Exemplo: 05-00 o identificador do GWP objetivos do negcio e
05-01, 05-02, 05-03 so exemplos de identificadores de SWP desse GWP.
H seis nveis de capacidade, incorporando nove atributos de processo. E,
para cada um desses atributos existem prticas genricas (GP), recursos genricos e
produtos de trabalho genricos. Os nveis de capacidade so:
Nvel 0: Processo incompleto: o processo no implementado, ou falha na
tentativa de alcanar os propsitos do processo. Neste nvel, h poucas ou
nenhuma evidncia de alguma realizao sistemtica do propsito do
processo.
Nvel 1: Processo executado: o processo implementado atinge ao propsito
do processo.
Nvel 2: Processo gerenciado: o processo realizado (nvel 1) agora
implementado em um estilo gerenciado (planejado, monitorado e ajustado)
e os produtos de trabalho so apropriadamente estabelecidos, controlados
e mantidos.
Nvel 3: Processo estabelecido: o processo gerenciado (nvel 2) agora
implementado usando um processo definido que capaz de alcanar os
resultados do processo.
Nvel 4: Processo previsvel: o processo estabelecido (nvel 3) opera dentro
de limites definidos para alcanar os resultados do processo.
Nvel 5: Processo em otimizao: o processo previsvel (nvel 4)
melhorado continuamente para atingir objetivos de negcio projetados e
relevantes.
3.4.2. Framework SEI CMMI e Modelo CMMI-DEV
O propsito do framework CMMI (Capability Maturity Model Integration)
fornecer orientao para melhorar o processo da organizao e gerenciar o
desenvolvimento, aquisio e manuteno de produtos e servios (SOFTWARE
ENGINEERING INSTITUTE, 2006).
A arquitetura do modelo CMMI foi melhorada para apoiar vrias constelaes e
o compartilhamento das melhores prticas entre as constelaes e os seus modelos.
Uma constelao CMMI um conjunto de componentes que inclui um modelo,
o seu material didtico, e mtodos de avaliao para apoiar uma rea de interesse.
Atualmente, existem trs constelaes: desenvolvimento (CMMI-DEV), servios
(CMMI-SVC) e aquisio (CMMI-ACQ). Os modelos do CMMI que j estavam
disponveis na comunidade antes de 2006 foram considerados parte da constelao
do CMMI para o Desenvolvimento (CMMI-DEV).
CMMI-DEV um modelo de referncia que consiste de melhores prticas que
abordam atividades de desenvolvimento e manuteno aplicadas a produtos e
servios. Ele contm prticas que cobrem gesto de projetos, gesto de processos,
engenharia de sistemas, engenharia de hardware e outros processos de apoio usados
no desenvolvimento e manuteno, substituindo os modelos CMMI-SE/SW da verso
anterior.
A constelao CMMI-DEV consiste em dois modelos: CMMI for Development e
CMMI for Development +IPPD (contm objetivos e prticas adicionais que cobrem o
uso de equipes integradas nas atividades de desenvolvimento e manuteno).
Os componentes do modelo so agrupados em trs categorias: requeridos,
esperados e informativos (Figura 3.1).

Os componentes requeridos descrevem o qu uma organizao deve alcanar
para satisfazer rea de processo17 (PA process area). Os componentes esperados
descrevem o qu uma organizao pode implementar para alcanar um componente
requerido. Os componentes informativos fornecem detalhes que auxiliam as
organizaes a pensarem em como abordar os componentes requeridos e esperados.
As sub-prticas e os produtos de trabalho so exemplos de componentes informativos.
FIGURA 3.1 COMPONENTES DOS MODELOS DO CMMI

FONTE: TRADUZIDO DE (SOFTWARE ENGINEERING INSTITUTE, 2006)
A arquitetura dos modelos do CMMI composta basicamente por reas de
processo, organizadas em duas representaes: contnua e por estgios.
A arquitetura por estgios utiliza-se dos nveis de maturidade para representar
a melhoria em um conjunto de reas de processo e, por conseqncia, na
organizao. J a arquitetura contnua utiliza-se dos nveis de capacidade para
representar a melhoria em reas de processo selecionadas. Por isso, os nveis de
17
Uma rea de processo um grupo de prticas relacionadas em uma rea que, quando implementadas
coletivamente, satisfazem um conjunto de objetivos considerados importantes para realizar a melhoria
nessa rea.
maturidade de 2 a 5 usam os mesmos termos que os nveis de capacidade de 2 a 5.
Isso intencional devido os conceitos de nveis de maturidade e capacidade serem
complementares. Os nves de maturidade, de 1 a 5, so:
1. Inicial: no nvel de maturidade 1, os processos so usualmente ad hoc e
caticos. A organizao usualmente no fornece um ambiente estvel para
apoiar os processos. O sucesso nessas organizaes depende da competncia
de pessoas da organizao e no do uso de processos comprovados. Apesar
desse caos, as organizaes desse nvel de maturidade freqentemente
produzem produtos e servios que funcionam; de qualquer modo, elas
freqentemente excedem seus oramentos e no atendem aos seus
cronogramas. Alm disso, so caracterizadas por abandonar seus processos
em tempo de crise e pela no habilidade de repetir seus sucessos.
2. Gerenciado: no nvel de maturidade 2, os projetos da organizao tem
assegurado que os processos so planejados e executados de acordo com
uma poltica; os projetos empregam pessoas habilitadas que tem recursos
adequados para produzir os resultados controlados; envolvem stakeholders
relevantes; so monitorados, controlados e revisados; e so avaliados pela
aderncia s descries de seus processos. Os estados dos produtos de
trabalho e da entrega de servios so visveis para o gerenciamento nos
pontos definidos (ex, em milestones). Os compromissos so estabelecidos
entre os stakeholders relevantes e so revisados quando necessrio.
Os produtos de trabalho so apropriadamente controlados e tanto os produtos
de trabalho quanto os servios satisfazem suas descries de processo,
padres e procedimentos.
3. Definido: no nvel de maturidade 3, os processos so bem caracterizados e
compreendidos, e so descritos em padres, procedimentos, ferramentas e
mtodos. O conjunto de processos padro da organizao, os quais so base
para a maturidade no nvel 3, estabelecido e melhorado com o passar do

tempo. Esses processos padro so usados para estabelecer consistncia
atravs da organizao. Os projetos estabelecem seus processos definidos a
partir desse conjunto de processos padro. Nesse nvel, o objetivo genrico 3 e
suas prticas genricas (no endereadas no nvel de maturidade 2) so
aplicados nas PAs do nvel de maturidade 2 e 3, para alcanar o nvel de
maturidade 3.
4. Gerenciado Quantitativamente: no nvel de maturidade 4, a organizao e os
projetos estabelecem os objetivos quantitativos para a qualidade e
desempenho dos processos e usa-os como critrios para o gerenciamento dos
processos. Os objetivos quantitativos so baseados nas necessidades do
cliente, usurios finais, organizao e implementadores de processo. A
qualidade e o desempenho do processo so entendidos em termos estatsticos
e gerenciado ao longo da vida do processo.
Para sub-processos selecionados, as medidas detalhadas do desempenho do
processo so coletadas e analisadas estatisticamente. Essas medidas so
incorporadas em um repositrio de medidas da organizao para apoiar na
tomada de deciso.
As causas especiais de variao de processo so identificadas e,
quando apropriadas, as origens das causas especiais so corrigidas para a
preveno de ocorrncias futuras. A diferena entre os nveis de maturidade 3
e 4 a previsibilidade do desempenho do processo; no nvel de maturidade 4,
o desempenho dos processos controlado usando tcnicas estatsticas e
outras tcnicas quantitativas, e previsvel quantitativamente. No nvel de
maturidade 3, os processos so tipicamente previsveis somente
qualitativamente.
5. Em otimizao: no nvel de maturidade 5, uma organizao melhora
continuamente seus processos com base no entendimento quantitativo das
causas comuns de variao inerentes no processo. Esse nvel de maturidade

foca na melhoria contnua do desempenho de processo por meio de melhorias
tecnolgicas e de processo incrementais e inovadoras. Os objetivos de
melhoria de processo quantitativo para uma organizao so estabelecidos,
continuamente revisados para refletir as mudanas dos objetivos do negcio, e
usados como critrios para o gerenciamento da melhoria do processo. Os
efeitos das melhorias de processo implantadas so medidos e avaliados em
relao aos objetivos de melhoria quantitativa de processo. Tanto os processos
definidos quanto o conjunto de processos padro da organizao so alvos de
atividades de melhoria mensurveis.
A diferena entre os nveis de maturidade 4 e 5 o tipo de variao de
processo endereada. No nvel de maturidade 4, a organizao est
preocupada em enderear causas especiais de variao de processo e
fornecer previsibilidade estatstica dos resultados. Embora os processos
possam produzir resultados previsveis, os resultados podem ser insuficientes
para alcanar os objetivos estabelecidos. No nvel de maturidade 5, a
organizao est preocupada em enderear causas comuns de variao do
processo e mudar o processo a fim de melhorar o desempenho do processo e
alcanar os objetivos quantitativos de melhoria do processo.
Os nveis de capacidade de 2 a 5 usam os mesmos termos que os objetivos
genricos de 2 a 5. Isso intencional devido a cada um dos objetivos e prticas
genricas refletirem o significado dos nveis de capacidade em termos de objetivos e
prticas que podem ser implementadas. Os seis nveis de capacidade, de 0 a 5, so:
0. Incompleto: um processo incompleto um processo que ou no realizado
ou parcialmente realizado. Um ou mais objetivos especficos (SG) das PAs
no so satisfeitos, e nenhum objetivo genrico existe para este nvel, uma vez
que no h razo para institucionalizar um processo realizado parcialmente.
1. Realizado: um processo realizado aquele que satisfaz os SGs das PAs.
Ele apia e possibilita que o trabalho necessrio para produzir os produtos de

trabalho seja realizado. Embora o nvel de capacidade 1 resulte em importantes
melhorias, elas podem ser perdidas com o tempo se elas no forem
institucionalizadas. A aplicao da institucionalizao (as prticas genricas
dos nveis de capacidade 2 a 5) auxiliam a assegurar que aquelas melhorias
sejam mantidas.
2. Gerenciado: um processo gerenciado um processo realizado (nvel de
capacidade 1) que tem uma infraestrutura bsica para apoiar o processo. Ele
planejado e executado de acordo com uma poltica; emprega pessoas
habilitadas que tem recursos adequados para produzir resultados controlados;
envolve stakeholders relevantes; monitorado, controlado e revisado; e
avaliado pela aderncia sua descrio. A disciplina de processos com nvel
de capacidade 2 auxilia a assegurar que prticas existentes sejam conservadas
durante perodos de estresse.
3. Definido: um processo definido um processo gerenciado (nvel de
capacidade 2) que obtido a partir de um conjunto de processos padro de
acordo com as diretrizes da organizao. A distino entre os nveis de
capacidade 2 e 3 que o escopo de padres, descries de processos e
procedimentos podem ser diferentes para cada instncia especfica do
processo (para um projeto, por ex).
No nvel de capacidade 2, os padres, descries de processo e
procedimentos so diferentes para cada instncia especfica do processo (para
um projeto particular, por ex.). J no nvel de capacidade 3, os padres,
descries de processo e procedimentos para um projeto so adequados a
partir de um conjunto de processos padro e, portanto, so mais consistentes.
Alm disso, no nvel de capacidade 3, os processos so tipicamente descritos
de modo mais rigorosos do que no nvel de capacidade 2.
Um processo definido define claramente o propsito, entradas, critrios de
entrada, atividades, papis, medidas, passos de verificao, sadas e critrios

de sada. No nvel de capacidade 3, os processos so gerenciados mais
proativamente usando um entendimento dos inter-relacionamentos entre as
atividades do processo e medidas detalhadas do processo, seus produtos de
trabalho e servios.
4. Gerenciado Quantitativamente: um processo gerenciado quantativamente
um processo definido (nvel de capacidade 3) que controlado usando tcnicas
estatsticas e outras quantitativas. Objetivos quantitativos para a qualidade e
desempenho do processo so estabelecidos e usados como critrios para
gerenciar o processo. A qualidade e o desempenho do processo entendido
em termos estatsticos e gerenciado durante toda a vida do processo.
5. Em otimizao: um processo em otimizao um processo gerenciado
quantitativamente (nvel de capacidade 4) que melhorado com base no
entendimento das causas comuns de variao no processo. O foco de um
processo em otimizao melhorar continuamente o espectro do desempenho
por meio de melhorias incrementais e inovadoras.
As regras para se alcanar determinado nvel de maturidade so:
- Para alcanar o nvel de maturidade 2, todas as PAs alinhadas ao nvel de
maturidade 2 devem atingir ao nvel de capacidade 2 ou mais alto.
- Para alcanar o nvel de maturidade 3, todas as PAs alinhadas aos nveis de
maturidade 2 e 3 devem atingir ao nvel de capacidade 3 ou mais alto.
- Para alcanar o nvel de maturidade 4, todas as PAs alinhadas aos nveis de
maturidade 2, 3 e 4 devem atingir ao nvel de capacidade 3 ou mais alto.
- Para alcanar o nvel de maturidade 5, todas as PAs devem atingir ao nvel
de capacidade 3 ou mais alto.
O nvel de capacidade 4 para PAs no pode ser pr-determinado porque as
escolhas dependem da seleo feita pela organizao em implementar as PAs do
nvel de maturidade 4. O mesmo acontece para o nvel de maturidade 5.

Todos os objetivos e prticas genricas so usados na representao contnua.
Na representao por estgios, somente os objetivos genricos 2 e 3 so usados.
Quando se tenta alcanar o nvel 2, usa-se as PAs no nvel de maturidade 2 e o
objetivo genrico 2 com suas respectivas prticas. Os objetivos genricos 4 e 5 e suas
prticas genricas associadas no so usados porque nem todos os processos sero
elevados ao nvel acima de um "processo definido". Somente os processos
selecionados e sub-processos sero gerenciados quantitativamente e otimizados, e
quais processos e sub-processos so selecionados endereado pelas PAs no nvel
de maturidade 4 e 5.
Quando se alcana os nveis de maturidade 3, 4 e 5, usa-se PAs nos nves de
maturidade apropriados e todas as PAs dos nveis de maturidade mais baixos. Em
adio, o objetivo genrico 3 e suas prticas genricas associadas (as quais incluem
as prticas genricas associadas com o objetivo genrico 2) so aplicadas para todas
as PAs. Isso significa que se j foi alcanado o nvel de maturidade 2, para alcanar o
nvel de maturidade 3 deve-se retornar para as PAs do nvel de maturidade 2 e aplicar
o objetivo genrico 3 e suas respectivas prticas.
Segundo Chrissis et al. (2003), trs categorias de fatores podem influenciar a
deciso sobre a escolha da arquitetura contnua ou por estgios: fatores de negcio,
culturais e legados.
Curtis (1998) defende que os modelos contnuos so aqueles que desejam
liberdade para escolher o foco da melhoria (atuando na melhoria de cada processo em
separado) e que os modelos por estgios so aqueles que desejam a mudana da
cultura da organizao.
J para Kasse18 (2004) apud (SALVIANO, 2006), a arquitetura por estgios
auxilia a organizao a priorizar seus esforos de melhoria, especialmente quando a
organizao principiante na rea de melhoria de processo ou est em um nvel baixo
de maturidade e tem pouca experincia em estabelecimento de processo. E, a
18
KASSE, T. (2004). Practical Insight into CMMI. Artech House Publishers.
arquitetura contnua do CMMI auxilia a organizao a construir um perfil alvo de reas
de processo que auxiliar a organizao a resolver objetivos estratgicos conhecidos.
Olson19 (2003) apud (SALVIANO, 2006) diz que a questo no qual
representao, por estgios ou contnua, deve ser usada. Primeiramente, devem ser
identificadas as metas de qualidade, objetivos e estratgia da organizao para depois
definir uma estratgia de melhoria: melhoria da qualidade, controle da qualidade ou
planejamento da qualidade. Por exemplo: (1) se uma organizao tem o oramento
limitado, precisa economizar recursos e ter um retorno de investimento rpido, ento
deve escolher uma estratgia de melhoria da qualidade, o que sugere a arquitetura
contnua com a escolha de uma rea de processo para orientar a melhoria; (2) se uma
organizao deseja ser a melhor dentre o seu nicho de mercado em um prazo longo, e
deseja chegar nesta posio de forma ordenada, pode selecionar a estratgia de
planejamento da qualidade, o que sugere a arquitetura por estgios.
Embora existam muitas razes para usar a representao contnua, os ndices
fornecidos pelos perfis de capacidade de processo20 so limitados em sua habilidade
de fornecer s organizaes um caminho para compar-la, de modo geral, com outras
organizaes. Os perfis de capacidade podem ser usados, nesse caso, se cada
organizao seleciona as mesmas PAs; de qualquer maneira, os nves de maturidade
tem sido usados para comparar as organizaes ao longo dos anos e j fornece um
conjunto pr-definido de PAs. Por isso, foi criada uma equivalncia entre perfis de
nveis de capacidade e nveis de maturidade. Assim, uma organizao que usa a
representao contnua para uma avaliao, pode converter o perfil de capacidade de
processo a um nvel de maturidade associado (SOFTWARE ENGINEERING
INSTITUTE, 2006).
19
OLSON, T. G. (2003). Staged or Continuous: Which Model Should I Choose?, Slides from
presentation at Third Annual CMMI Technology Conference and Users Group, USA, November 2003.
20
Um perfil de capacidade uma lista de PAs e os nveis de capacidade correspondentes para cada. O
perfil possibilita que uma organizao rastreei seu nvel de capacidade em relao s PAs. O perfil
denominado perfil realizado quando representa o progresso atual de cada PA. Alternativamente, o perfil
um perfil almejado quando representa objetivos planejados de melhoria dos processos da organizao.
3.4.3. MPS.BR e Modelo MR-MPS
A Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX)
iniciou um programa mobilizador denominado MPS.BR (Melhoria de Processos do
Software Brasileiro) com o intuito de melhorar continuamente a qualidade de software
no Brasil a um custo acessvel. Isso devido dificuldade e alto custo de implantao e
avaliao do CMMI (SOFTWARE ENGINEERING INSTITUTE, 2002) e a necessidade
de expandir o mercado de software brasileiro (WEBER et al., 2005b).
O Modelo MPS.BR teve como bases de construo as normas ISO/IEC 12207
(INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 2001) e ISO/IEC
15504 (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 2003) e as
melhores prticas da engenharia de software, e mantm compatibilidade com o CMMI.
A sua originalidade no est no contedo, mas sim na estratgia de
implementao, criada para a realidade brasileira (SOFTEX, 2006). Esse modelo
possui trs componentes:
- Modelo de Referncia (MR-MPS): definido por meio de nveis de
maturidade, seqenciais e acumulativos. Cada nvel de maturidade uma
juno entre processos e capacidade dos processos, ou seja, composto
por um conjunto de processos em um determinado nvel de capacidade. O
progresso e o atendimento do nvel de maturidade se obtm quando so
atendidos todos os resultados e propsito do processo; e os atributos de
processo relacionados aquele nvel.
- Mtodo de Avaliao (MA-MPS): descreve o modo como a avaliao deve
ser efetuada, quais os requisitos dos avaliadores e os requisitos para
atender ao MR-MPS. O MA-MPS foi definido em conformidade com os
requisitos para modelos de referncia de processo e mtodos de avaliao
de processos estabelecidos na norma ISO/IEC 15504-2 e atende aos
requisitos especficos do Programa MPS.BR. Assim, o mtodo est em
conformidade com a ISO/IEC 15504 e compatvel com o mtodo SCAMPI

para avaliao, segundo o modelo CMMI, tambm definido com base na
ISO/IEC 15504.
- Modelo de Negcio (MN-MPS): compreende (i) um Modelo de Negcio
Cooperado (MNC-MPS) - prprio para grupos de pequenas e mdias
empresas que necessitam melhorar radicalmente seus processos de
software; (ii) um Modelo de Negcio Especfico (MNE-MPS) - prprio para
empresas de qualquer porte e natureza que no querem compartilhar com
outras empresas a melhoria de seus processos de software.
3.4.4. ISO 9000
A srie ISO 9000 foi elaborada atravs de um consenso internacional sobre as
prticas que uma empresa pode tomar a fim de atender plenamente os requisitos de
qualidade do cliente. A ISO 9000 no fixa metas a serem atingidas pelas empresas a
serem certificadas, a prpria empresa quem estabelece as metas a serem atingidas.
As normas da famlia ISO 9000-2000 foram desenvolvidas para apoiar
organizaes, de todos os tipos e tamanhos, na implementao e operao de
sistemas de gesto da qualidade eficazes.
ISO 9000 inclui as seguintes normas: ISO 9000:2000, ISO 9001:2000 e ISO
9004:2000. A ISO 9000 descreve os fundamentos de sistemas de gesto da qualidade
e estabelece a terminologia para estes sistemas. A ISO 9001 (INTERNATIONAL
ORGANIZATION FOR STANDARDIZATION, 2000) especifica requisitos para um
sistema de gesto da qualidade, onde uma organizao precisa demonstrar sua
capacidade para fornecer produtos que atendam os requisitos do cliente e os
requisitos regulamentares aplicveis, e objetiva aumentar a satisfao do cliente. A
ISO 9004 fornece diretrizes que consideram tanto a eficcia como a eficincia do
sistema de gesto da qualidade. O objetivo desta norma melhorar o desempenho da
organizao e a satisfao dos clientes e das outras partes interessadas.

3.4.5. PMBOK
O Corpo de Conhecimento da Gesto de Projeto (PMBOK Project
Management Body of Knowledge) foi desenvolvido pelo Project Management Institute
(PMI) para ser um guia que disponibiliza conhecimento relacionado gesto de
projetos.
Contm um conjunto de prticas j sedimentadas em gesto de projetos,
coletadas por profissionais envolvidos em projetos de todo o mundo. E, passa por
evolues de 4 em 4 anos, baseadas em contribuies de seus membros. aplicvel
em qualquer rea inclusive em projetos de software.
De acordo com o PMBOK (PROJECT MANAGEMENT INSTITUTE, 2004), a
gesto de projetos ocorrer em reas de conhecimento, por meio da aplicao e
integrao de processos. As reas de conhecimento totalizam nove: escopo do
projeto, tempo, custo, qualidade, recursos humanos, comunicaes, riscos, aquisies
e integrao do projeto.
As fases da gesto de projeto que cobrem as reas de conhecimento com
maior ou menor nfase so: Iniciao, onde definido e autorizado o projeto ou fase
do projeto; Planejamento, onde so definidos e refinados os objetivos, planejada a
ao necessria para alcanar os objetivos e o escopo do projeto; Execuo, onde h
a integrao das pessoas e outros recursos para a realizao do plano de gesto do
projeto; Monitoramento e Controle do progresso do projeto para identificar variaes
em relao ao plano de gesto do projeto, de forma que possam ser tomadas aes
corretivas quando necessrio para atender aos objetivos do projeto; Encerramento,
onde formalizado a aceitao do produto, servio ou resultado, conduzindo ao final
do projeto ou de fase do projeto.

3.4.6. SWEBOK
O Corpo de Conhecimento de Engenharia de Software (SWEBOK Software
Engineering Body of Knowledge) coordenado por um projeto da IEEE Computer
Society e ACM (Association for Computing Machinery) em busca dos seguintes
objetivos: promover uma viso consistente mundialmente da engenharia de software,
caracterizar o contedo da engenharia de software, esclarecer o escopo e limites da
engenharia de software em relao a outras disciplinas (como engenharia da
computao, cincia da computao, matemtica, gesto de projetos, gesto da
qualidade, ergonomia de software e engenharia de sistemas) e prover uma fundao
para o desenvolvimento de currculos e material para certificaes individuais (ABRAN
et al., 2004).
O primeiro dos objetivos anteriormente citados promover uma viso
consistente mundialmente da engenharia de software foi suportado por um processo
de desenvolvimento no qual estavam engajados, aproximadamente, 500 revisores de
42 pases na elaborao da verso experimental (1998-2001) e, depois, mais 120
revisores de 21 pases no ano de 2003 na elaborao da verso 2004.

H na literatura vrios modelos de melhoria de processo, como os
apresentados neste captulo, que podem ser utilizados como referncia para compor o
contexto de utilizao de um modelo de processo de software.
Os frameworks para modelos de capacidade de processo21 e mtodos de
avaliao de processo - CMMI e ISO/IEC 15504 - so os mais relevantes no setor de
software (SALVIANO, 2006). O MPS.BR compatvel com o CMMI.
21
Alguns modelos utilizam nveis de maturidade, tais como: SW-CMM, CMMI-SE/SW e CMMI-DEV.
Essa maturidade definida em funo da capacidade de processo, por isso, o termo capacidade
suficiente para caracterizar esses modelos, tambm.
Captulo 4. Metodologia de Pesquisa P g i n a | 65
4. METODOLOGIA DE PESQUISA

A pesquisa uma atividade voltada para a soluo de problemas tericos ou
prticos com o emprego de processos cientficos, ou seja, ela parte de uma dvida ou
problema, e com o uso do mtodo cientfico, busca uma resposta ou soluo (CERVO
& BERVIAN, 2002).
Mtodo cientfico o conjunto de processos ou operaes mentais que se
devem empregar na investigao. a linha de raciocnio adotada no processo de
pesquisa.
Para o estabelecimento do mtodo cientfico necessrio definir o referencial
terico, isto , a categoria de mtodos de pesquisa mais amplos - aqueles diretamente
relacionados com as correntes que estudam mtodos de pesquisa dentro da rea de
epistemologia (PDUA, 1996). Os referenciais tericos existentes so: dedutivo,
indutivo, dialtico, fenomenolgico e hipottico-dedutivo (GIL,1999; MARCONI &
LAKATOS, 2000).
Na literatura, h diversas classificaes de tipos de pesquisas, sendo que os
critrios para essas classificaes variam de acordo com o enfoque dado (BRYMAN,
1989; DANE, 1990; PDUA, 1996; GIL, 1999; CERVO & BERVIAN, 2002; MARKONI
& LAKATOS, 2000). H classificaes do ponto de vista da natureza da pesquisa, dos
objetivos de pesquisa e dos procedimentos tcnicos da pesquisa.
Neste captulo ser apresentado o referencial terico que embasou a pesquisa
realizada neste trabalho e as classificaes da pesquisa, de acordo com os vrios
critrios existentes.
4.2. Abordagens e mtodos de pesquisa

O referencial terico adotado neste trabalho o hipottico-dedutivo, que se
inicia pela percepo de uma lacuna nos conhecimentos, acerca da qual se formula
hipteses e, pelo processo de inferncia dedutiva, testa-se a predio da ocorrncia
de fenmenos abrangidos pela hiptese. Desse modo, a busca da soluo do
problema feita quando teorias ou leis falham na soluo de um problema (refutao)
e, ento, proposta uma nova teoria ou lei (conjectura) que resolva o problema e
incorpore a teoria ou lei anterior. Assim, cada vez que a teoria resistir a um teste para
refutao ser considerada mais robusta (POPPER22, 1975 apud MARCONI &
LAKATOS, 2000).
Tal referencial terico adequado a este trabalho de pesquisa, uma vez que a
anlise do Modelo elaborado foi realizada por meio da tentativa de refutao de uma
hiptese, durante a implantao das atividades do modelo em ambientes reais de
MPEs e durante as anlises crticas de profissionais da rea.
O presente trabalho considerou a seguinte hiptese: possvel criar um
modelo que considere tanto um modelo de processo de software quanto modelos de
capacidade de processo em um contexto de melhoria de processo, a fim de orientar a
definio por parte de uma MPE de seu processo padro de venda e desenvolvimento
de software on-demand, de maneira mais detalhada do que a sugerida pelos modelos
de capacidade de processo.
Do ponto de vista da natureza da pesquisa, ela pode ser classificada em
pesquisa pura ou bsica e pesquisa aplicada (CERVO & BERVIAN, 2002). Nesse
aspecto, este trabalho de pesquisa classificado como uma pesquisa aplicada, uma
vez que objetiva gerar conhecimentos para aplicao prtica dirigida soluo de um
problema especfico: auxiliar as MPEs na definio e melhoria de seu processo de
22
POPPER, K. S. (1975). A lgica da pesquisa cientfica. 2 ed. So Paulo: Cultrix.
venda e desenvolvimento de software, em conformidade com os modelos de
capacidade de processo CMMI e ISO/IEC 15504.
Do ponto de vista da forma de abordagem do problema, a classificao de
pesquisa pode ser: quantitativa e qualitativa (BRYMAN, 1989). Considerando que este
trabalho de pesquisa no buscou provar estatisticamente os benefcios e adequao
da integrao do modelo de processo de software aos modelos de capacidade de
processo, pode ser caracterizado do ponto de vista da forma de abordagem do
problema como uma abordagem qualitativa.
Do ponto de vista dos objetivos de pesquisa, ela pode ser classificada,
segundo GIL (1999), como exploratria, descritiva e explicativa. Para Dane (1990),
alm dessas h a pesquisa preditiva e a pesquisa ao.
De acordo com o objetivo da pesquisa esse trabalho pode ser classificado
como pesquisa-ao. Segundo Thiollent (2002), na pesquisa-ao os pesquisadores
desempenham um papel ativo no equacionamento dos problemas encontrados, no
acompanhamento e na avaliao das aes desencadeadas em funo dos
problemas. Sendo assim, neste tipo de pesquisa, alm da exigncia do envolvimento
ativo do pesquisador e ao por parte das pessoas ou dos grupos envolvidos no
problema, necessrio produzir conhecimentos, adquirir experincia, contribuir para a
discusso da rea estudada ou fazer avanar o debate acerca das questes
abordadas.
Neste trabalho de pesquisa, o pesquisador agiu na busca de uma soluo para
orientar mais detalhadamente s MPEs durante a definio e melhoria de seu
processo de venda e desenvolvimento de software on-demand. Isso foi realizado
aplicando o modelo elaborado neste trabalho de pesquisa em duas MPEs, aprendendo
com os resultados, obtendo crticas e sugestes de profissionais da rea.
Do ponto de vista dos procedimentos tcnicos, as principais classificaes so
(PDUA, 1996; CERVO & BERVIAN, 1983): pesquisa bibliogrfica, pesquisa
documental, pesquisa experimental, levantamento, pesquisa de campo e estudo de

caso. Nesse trabalho de pesquisa foram utilizadas: a pesquisa bibliogrfica para o
levantamento dos assuntos abordados no trabalho de pesquisas.
Dentre o conjunto de tcnicas de coleta de dados existente na literatura
(MARCONI & LAKATOS, 1999), nesse trabalho de pesquisa foram utilizados: 1) um
questionrio (Apndice 1) aplicado a 5 (cinco) MPEs que desenvolvem software e 9
(nove) CPDs (Centro de Processamento de Dados) de empresas diversas os quais
desenvolvem software para uso interno, que confirmou a seleo das reas de
conhecimento definidas no Modelo ProcSoftVD e indicou a importncia de outras
reas de conhecimento que sero consideradas em um trabalho futuro; 2) um
questionrio (Apndice 7) entregue a profissionais que trabalham em MPEs ou j
trabalharam em empresas e tambm profissionais com mestrado e doutorado na rea,
para levantarem os pontos fortes e fracos do modelo e para estabelecerem o nvel de
atendimento do modelo em relao s caractersticas de qualidade: funcionalidade,
usabilidade, manutenibilidade, portabilidade e eficincia; 3) entrevistas com esses
profissionais a fim de obter sugestes para melhorar o modelo.
4.3. Etapas do trabalho

Primeiramente, foi realizada a reviso bibliogrfica para fundamentar a proposta
elaborada nesse trabalho de pesquisa. Os assuntos pesquisados foram: modelos de
processo de software, modelos de capacidade de processo e
modelos/mtodos/abordagens de melhoria de processo.
As outras atividades realizadas neste trabalho de pesquisa foram agrupadas em
trs etapas (Figura 4.1):

R evis o B ibliog rfic a
E tapa 1 - 1 vers o do Modelo P roc S oftVD
1.1 Mapeamento do C MMI e IS O /IE C 15504-5

1.2 P ropos io da 1 vers o do Modelo P rocS oftV D
1.3 Implantao do Modelo P rocS oftV D
E tapa 2 - 2 vers o do Modelo P roc S oftVD
2.1 Anlis e dos pontos fracos da 1 verso do modelo

2.2 Atualiz ao do mapeamento do C MMI e IS O /IE C
15504-5
2.3 P ropos io da 2 vers o do Modelo P rocS oftV D
E tapa 3 Modelo de G es to de P roc es s o (P roc S oftVD - G es to)

P rocS oftVD - G es to
Mo delo s d e C apacid ad e d e P ro ces s o F ramewo rk d e P roc es s o

3.1 Avaliao de abordagens /metodologias /modelos
15504-5 Unified P roc es s
P roc S oftVD relacionados melhoria de proces s o

3.2 P ropos io do Mtodo de Melhoria de P roces so de
P rocS oftVD -
S oftware (P rocS oftV D Melhoria)
Melhoria
3.3 P ropos io do P rocS oftV D - G es to

P roc es s o P adro
Ins tncia para MP E S
3.4 Implantao do P rocS oftV D - G esto
F a se 1 A tividades
F a se 2
F as e 3 F as e N
Ativida des de Apoio
informa o
entre gas
templates papis
rec ursos
3.5 Avaliao do P rocS oftV D - G es to
FIGURA 4.1 ETAPAS DO TRABALHO DE PESQUISA
Etapa 1: a principal entrega dessa etapa foi uma primeira verso do modelo
ProcSoftVD (seo 5.2). Para isso, foram realizadas as seguintes
atividades:
1.1 Mapeamento do CMMI e ISO/IEC 15504-5: foi mapeada a equivalncia
dos objetivos especficos do nvel de maturidade 2 do CMMI em relao
s prticas-base da parte 5 do relatrio tcnico da ISO/IEC 15504 para,
posteriormente, associar cada uma das atividades do modelo de
processo proposto (item 1.2) a esses objetivos especficos e prticas-
base. Essa associao das atividades do modelo ProcSoftVD com o

CMMI e ISO/IEC 15504-5 serve para mostrar ao usurio do modelo,
caso seja necessrio, que as atividades do modelo ProcSoftVD
atendem s melhores prticas sugeridas pelo CMMI e ISO/IEC 15504-5;
que o modelo ProcSoftVD est em consonncia com modelos/normas
internacionais de qualidade de processo.
1.2 Proposio da 1 verso do Modelo ProcSoftVD: essa verso do
modelo foi elaborada com base na estrutura do modelo de processo
cascata; uma estrutura seqencial e linear que dificilmente retrata a
maioria dos projetos de desenvolvimento de software on-demand.
Foram definidas as atividades de cada uma das fases, suas tarefas,
artefatos de entrada e sada, papis dos responsveis pela execuo
das atividades, recursos a serem utilizados e templates (formulrios
com uma estrutura definida para cada documento a ser criado pelas
atividades do modelo). Foram elaborados: um pster contendo a viso
grfica de todas as atividades de cada uma das fases do modelo
(Figura 5.2); um pster contendo a viso grfica dos documentos a
serem utilizados/criados nas/pelas atividades do modelo (Figuras 5.5 e
5.6); um manual contendo o detalhamento de cada uma das atividades
das fases do modelo (Figura 5.7) e um manual contendo a estrutura de
cada um dos documentos a serem utilizados/criados nas/pelas
atividades do modelo (Figura 5.8).
1.3 Implantao do Modelo ProcSoftVD: o modelo definido anteriormente foi
instanciado para a Empresa 1 (Figura 5.3) e, a partir dessa instncia,
por meio da pesquisa-ao foram implantadas duas fases - fases
Vender e Planejar Projeto.

Etapa 2: a principal entrega dessa etapa foi uma segunda verso do
modelo ProcSoftVD (seo 5.2). Para isso, foram realizadas as seguintes
atividades:
2.1 Anlises dos pontos fracos da 1 verso do modelo: durante a pesquisa-
ao realizada na Empresa 1, os funcionrios da empresa junto ao
pesquisador deste trabalho detectaram que a estrutura do modelo
(seqencial e linear) no era adequada para o projeto piloto o qual foi
utilizado durante a implantao das fases Vender e Planejar Projeto.
Percebeu-se, assim, a necessidade de alterao na estrutura do
modelo ProcSoftVD para atender a maioria dos projetos de
desenvolvimento de software on-demand. Tambm foram detectados
alguns pontos fracos em algumas atividades do modelo que deveriam
ser melhorados em uma prxima verso do modelo.
2.2 Atualizao do mapeamento do CMMI e ISO/IEC 15504-5: foi publicada
uma verso mais atual do CMMI CMMI-DEV v1.2 e foi obtida a norma
ISO/IEC 15504. Por isso, foi realizada a atualizao do mapeamento.
2.3 Proposio da 2 verso do Modelo ProcSoftVD: uma vez identificada a
deficincia da estrutura do modelo (item 2.1), a estrutura do modelo foi
modificada para aceitar projetos de desenvolvimento de software mais
condizentes realidade: feitos de forma incremental e evolutiva. Foram
tambm definidos, em meio pesquisa-ao, os requisitos (seo
5.2.1) a serem atendidos pelo modelo ProcSoftVD; foram re-elaborados
os elementos do modelo: atividades, tarefas, artefatos de entrada e
sada, papis, recursos e templates para cada atividade do modelo
ProcSoftVD e para facilitar o entendimento da associao dos
elementos do modelo ProcSoftVD foi elaborado um meta-modelo
(seo 5.2.2).
Etapa 3: a principal entrega dessa etapa foi o Modelo de Gesto do
Processo de Venda e Desenvolvimento de Software On-demand para
MPEs (ProcSoftVD - Gesto) a integrao do modelo ProcSoftVD com
um mtodo de melhoria de processo (captulo 5). Para isso, foram
realizadas as seguintes atividades:
3.1 Avaliao de abordagens, metodologias e modelos relacionados
melhoria de processo: para a implantao de algumas fases da 1
verso do modelo ProcSoftVD na Empresa 1, foi utilizada a Metodologia
de Gesto de Mudanas elaborada por Costa (2006). Questionou-se
sobre a existncia na literatura de outras
metodologias/abordagens/mtodos voltadas especificamente para
melhoria de processo de software para MPEs. Foi realizado, ento, um
levantamento bibliogrfico sobre abordagens de melhoria de processo
existentes na literatura e, posteriormente, foi realizada uma seleo,
entre as abordagens de melhoria de processo levantadas, das mais
adequadas para serem utilizadas pelas MPEs de software.
3.2 Proposio do Mtodo de Melhoria de Processo de Software
(ProcSoftVD Melhoria) (seo 5.3): a partir da avaliao das
abordagens, metodologias e modelos relacionados melhoria de
processo (item 3.1) foi identificada a complementaridade entre algumas
delas e, com base nessa complementaridade foi elaborado um mtodo
de melhoria de processo (ProcSoftVD Melhoria).
3.3 Proposio do ProcSoftVD Gesto (captulo 5): considerando o
contexto de gesto de processos de negcio, mais especificamente o
de melhoria, foi elaborado o ProcSoftVD Gesto (Figura 5.1), um
Modelo de Gesto do Processo de Venda e Desenvolvimento de
Software On-demand que tem o objetivo de orientar de maneira

detalhada s MPEs a definirem o seu processo padro de venda e
desenvolvimento de software on-demand.
3.4 Implantao do ProcSoftVD - Gesto (seo 6.2): foi aplicado o Mtodo
de Melhoria de Processo (ProcSoftVD Melhoria), elaborado
anteriormente, em uma MPE (Empresa 2) (Apndice 6). Nessa
aplicao foram definidos ciclos de melhoria compostos por reas de
conhecimento a serem implantadas, de acordo com a prioridade da
empresa. Assim, foi realizada a implantao das reas de
conhecimento Modelagem de Negcios e Produo de Requisitos do
Modelo de Processo de Venda e Desenvolvimento de Software On-
demand para MPEs (ProcSoftVD).
3.5 Avaliao do ProcSoftVD - Gesto (seo 6.3): foram realizados
questionrios (Apndice 7) e entrevistas com 6 (seis) profissionais da
rea de computao, sendo que 5 (cinco) deles tem experincia como
analista de sistemas/programador e 4 (quatro) deles tem
mestrado/doutorado na rea de computao e atuantes como docente
em universidades.

Neste captulo foram apresentados o referencial terico que embasou a
pesquisa realizada neste trabalho, as classificaes da pesquisa, de acordo com os
vrios critrios existentes e as etapas do trabalho de pesquisa.
No prximo captulo ser apresentado a principal entrega resultante deste
trabalho de pesquisa o Modelo ProcSoftVD Gesto.

Captulo 5. Modelo ProcSoftVD - Gesto P g i n a | 74
5. Modelo de Gesto do Processo de Venda e

Desenvolvimento de Software On-demand para
MPEs (ProcSoftVD Gesto)

Neste captulo apresentado o ProcSoftVD - Gesto (Figura 5.1) - um modelo
de Gesto do Processo de Venda e Desenvolvimento de software on-demand para
MPEs, elaborado a partir da integrao do Modelo do Processo de Venda e
Desenvolvimento de software on-demand para MPEs (ProcSoftVD) (seo 5.2) com o
Mtodo de Melhoria do Processo de Software (ProcSoftVD Melhoria) (seo 5.3).
P roc S oftVD - G es to
Modelos de C apac idade de P roc es s o F ramework de P roc es s o
15504-5 Unified P roc es s
P roc S oftVD
P roc S oftVD -
Melhoria
Ins tncia para MP E S
P roc es s o P adro
F as e 1 A tividades
F as e 2
informao templates papis
F as e 3 F as e N
entregas recurs os
Atividades de Apoio
FIGURA 5.1 MODELO DE GESTO DO PROCESSO DE VENDA E DESENVOLVIMENTO DE SOFTWARE ON-DEMAND

PARA MPES (PROCSOFT VD - GESTO)
Alm disso, na seo 5.4, apresentada a publicao web do modelo
ProcSoftVD Gesto que pode ser acessada por qualquer interessado.
5.2. Evoluo do Modelo de Processo de Venda e

Desenvolvimento de Software On-demand para MPEs
(ProcSoftVD)
Inicialmente, esse projeto de pesquisa tinha como objetivo principal melhorar o
desempenho de empresas que pertenciam a um APL (arranjo produtivo local)
(CASSIOLATO & LASTRES, 2001); participavam do projeto duas empresas. Para
isso, foram definidos alguns objetivos secundrios, dentre eles o de modelar um
Processo Genrico para Venda e Desenvolvimento de Software (PV&DS) On-Demand
Colaborativo. Um dos resultados parciais desse projeto foi uma verso inicial do
Modelo Genrico do PV&DS on-demand (Figura 5.2), elaborada a partir do
mapeamento das prticas do nvel de maturidade 2 do CMMI v1.1 com as prticas
definidas no modelo ISO/IEC TR 15504-1998.
Entretanto, depois de um ano de andamento do projeto anteriormente referido,
devido a mudanas estratgicas de uma das empresas do APL, apenas a Empresa 1
continuou no projeto. Trata-se de uma pequena empresa de base tecnolgica, fundada
em janeiro de 2000, cujo alvo o desenvolvimento de software, mais especificamente
o desenvolvimento de sistemas para Internet, e-learning e software sob encomenda.

Estratgia Vender PP01: Doc de Requisitos PP03: Determinar

Validar PP02: Estimar o WBS
estimativas de esforo Especificar e Integrar
requisitos escopo do projeto e custo
V01: Manual do
Analisar Contatos
Plano do Projeto Configurao EC06:
Produto EC07:Desenvolver a
contatos V10:Elaborar V11:Analisar WBS documentao de
contrato contrato Montar os suporte do produto
V02:Solicitar Contrato PP04: componentes e
proposta Planejar Plano do Projeto Estabelecer avaliar a Soluo
oramento e integrao
PP06: Planejar os
Proposta
V03:Definir Projeto Plano de cronograma
Contrato e o recursos do
necessidades Recursos
Solicitao de Rel. de anlise do contrato projeto
Soluo
Doc de Requisitos proposta PP11:
PP09: Revisar Componentes
V07:Analisar Plano de Recursos Integrar
modificaes Plano do Projeto Plano de Software outras
V08:Entender os V12:Analisar Planos planos
na proposta modificaes Plano de Hardware
Plano do Projeto
requisitos
do contrato PP07: Planejar EC02: Realizar anlise para
conhecimentos e Plano do Projeto desenvolver, comprar ou reusar
Rel. de anlise da
Doc de Requisitos habilidades componentes de produto
Plano de Hardware
Plano de Recursos e
Contrato
EC05: Estabelecer
Proposta e o
necessrias
proposta
Plano de Riscos seqncia, ambiente,
Plano de Software
V09:Determinar Doc de Requisitos V05: Doc de Plano de Plano do procedimentos e critrios
os requisitos Elaborar Requisitos Conh. e Hab. PP10: Projeto de integrao
dos clientes proposta Revisar
V13:Formalizar
Proposta
Plano do planos Solues Solues
incio Projeto PP12: Obter
Rel. Viabilidade do projeto PP08: Definir comprometimento
alternativas alternativas
Doc de Requisitos Plano de
time do projeto Soluo
do Projeto
V06:Analisar Riscos com o plano

proposta Plano do Projeto
V04:Verificar a PP05:
viabilidade Identificar EC01:Selecionar e EC04:Projetar, revisar
econmica da Plano de Recursos riscos do Plano do Projeto Avaliar Solues de EC03:Conceituar o e gerenciar as
proposta
Rel. Viabilidade
projeto Componentes produto integrado Soluo
do Projeto interfaces
Doc de Requisitos
Vender ER07:Analisar os
dados da peer WBS
review Doc de Req Software PPS01: Estimar o Software PPS02: Determinar
escopo do projeto estimativas de esforo
e custo
Pedido de
Itens de Configurao
Especificar
Mudana de IC Gerenciar Configurao Planejar
e Integrar
Rel de Inspeo
WBS Software
Plano de Software
Projeto PPS03:
GC01: Identificar Configurao ER06:Conduzir as
peer review Plano de Software Estabelecer
os itens de oramento e
configurao e PPS05: Planejar Plano de Rec cronograma
Itens de Itens de os recursos do
cronograma Rel de Inspeo de Software
Configurao Configurao projeto
Administrar
Relatrio de Recursos do ER05: Plano de Rec de Software PPS07:
Plano de Software
Plano de Software
Acompanhamento Estabelecer o ambiente, Revisar
Autorizao de GC04: do Projeto GC05:
Doc Requisitos
Projeto Desenvolver procedimentos e planos
GC02: Criar ou Mudana de IC Controlar os Gerenciar critrios de verificao
liberar baselines itens de mudanas dos Doc Req Software
Software PPS06: Planejar
configurao requisitos conhecimentos e
Doc de Req de Software habilidades
necessrias Plano de Conh. e Hab.
Acompanhar de Software Plano de
Plano de Software Riscos de
Controlar ER04:Validar os Plano de Conh. e Hab. Software
Autorizao de requisitos por meio de Software
Mudana de IC Relatrio de Projeto Implantar de mtodos
GC03: Acompanhamento PPS04:
Acompanhar os do Projeto Produto Identificar
pedidos de Relatrio de Plano de Rec de Software riscos do
mudana Acomp. projeto
Gerenciar Desenvolver do Software
Doc de Req
Configurao Hardware de Software
Plano de Riscos de Software Componentes
ER03:Analisar
os requisitos
para alcanar
um equilbrio
PS01:
Doc Req Software Desenvolver solues
Acompanhar E controlar Projeto Rel Viabilidade do Projeto
Doc de Req
alternativas detalhadas
de Software e um critrio de seleo
PS03:Selecionar solues de
Plano do Projeto EI02: componentes dos produtos Solues Alternativas
Doc de Requisitos
ACP01:Conduzir Estabecer a
revises e funcionalidade PS02:Realizar anlise
Solues de Solues Alternativas
comunicar para desenvolver,
resultados Soluo Doc de Req Software comprar ou reusar
de Software componentes de
Doc Req Software PS04:Estabelecer e alocar produto
Plano de Projeto ACP09:Analisar ER01: requisitos do produto e dos
relatrio de Analisar os componentes do produto Projeto Dados/
viabilidade do requisitos Funcional
Relatrio de projeto Projeto Dados / Funcional
Acompanhamento Plano de recursos Plano de recursos Software
do Projeto Relatrio de PS05:Identificar os PS06:Projetar o produto
Duplicatas pagas Projeto Arquitetural
requisitos de interface ou seus componentes
e projet-la Projeto Dados / Funcional
Relatrio de ACP07:Efetu ARP01:Determinar Doc Req Software Projeto Arquitetural
ACP08:Cobrar Duplicatas pagas ar baixa das o tipo de aquisio
Rel Duplicatas Projeto HCI
pagamentos duplicatas
atrasados pagas
ACP02:Gerenciar pagas PS07:Estabelecer
o projeto Soluo Desenvolver Software um conjunto
utilizando planos (pacote) de dados
integrados Solicitao de Solicitao de
Compra Compra tcnicos
Produtos de Trabalho
Relatrio de
Duplicatas emitidas IP01:
Relatrio de Empacotar e
Acompanhamento entregar o
ACP06:Cadastrar e Contrato Contrato com produto ou
do Projeto Emitir Notas Fiscais ARP03:Aceitar o Fornecedor
ARP02:Selecionar componente VVT01:Selecionar Plano de Plano de VVT02:Selecionar os
Relatrio de fornecedores e os produtos para produtos de trabalho Projeto Dados / Funcional Projeto Dados / Funcional
produto adquirido Teste Teste
Acompanhamento estabelecer acordo validao para verificao Projeto Arquitetural Projeto Arquitetural
do Projeto Projeto HCI Projeto HCI
ACP03:Gerenciar ACP04:Manter Produtos de Plano de Plano de Produtos de
dependncias rastreabilidade dos Trabalho Teste Teste Trabalho
Relatrio de requisitos Produto
VVT03:Realizar
Relatrio de Comprado VVT05:Realizar VVT04:Estabelecer
Acompanhamento validao um ambiente, verificao
do Projeto Acompanhamento
ACP05: Gerenciar procedimentos e CS02: Desenvolver Cdigo CS01:
do Projeto Relatrio de Teste Relatrio de Teste
o envolvimento dos critrios de validao a documentao de Implementar
Stakeholders e verificao suporte do produto o Projeto
VVT06:Analisar os VVT07:Analisar os
Implantar Produto Implantar Produto resultados de validao resultados da verificao e
identificar as aes
Doc de requisito corretivas
Doc Req Software
FIGURA 5.2 PRIMEIRA VERSO DO MODELO GENRICO DO PV&DS ON-DEMAND

Aplicando a Metodologia de Gesto de Mudanas proposta em COSTA (2006)
na Empresa 1, foi revelado que no existiam padres de documentos e nem uma
viso sistemtica de suas atividades, implicando no desenvolvimento de projetos de
sistemas com base na experincia do gerente de projeto em conduzir esses projetos.
Alm disso, havia uma grande rotatividade de pessoal na empresa dificultando o
desenvolvimento de sistemas a contento de ambas as partes envolvidas cliente e
empresa, no prazo estabelecido.
Foi, ento, definido um portflio de projetos de mudana para a Empresa 1,
tendo como primeiro projeto de mudana a instanciao do Modelo Genrico do
PV&DS on-demand para a Empresa 1. As entregas dessa instanciao foram: um
pster com a viso geral das atividades do modelo proposto, agrupadas em fases,
com seus respectivos fluxos de entradas e sadas (Figura 5.3; nessa figura esto
destacadas em vermelho pontilhado as atividades da fase Vender que podem ser
melhor visualizadas na Figura 5.4); um pster do contedo dos documentos do modelo
instanciado para facilitar o entendimento comum a todos (Figura 5.5; nessa figura est
destacado em vermelho pontilhado o artefato Documento de Requisitos que pode ser
melhor visualizado na Figura 5.6); um manual contendo o detalhamento de todas as
atividades do modelo de processo proposto (Figura 5.7) e um manual com os
templates (modelos de documentos) (Figura 5.8) para os artefatos utilizados/criados
nas/por meio das atividades do modelo de processo proposto.

Vender
Estratgia V01: Rel. de Visita Doc. Requisito
Contatos V02:Prospectar
Buscar
cliente
no XRMS Rel. Viabilidade do Projeto
Cronograma
Vender
contatos
Contatos Rel. de anlise contrato
V09:
V03:Visitar Elaborar
Desenvolver software: Administrar Recursos do
V04:Definir Contrato V10:Analisar
Requisitos do Cliente contrato contrato
Planejar Projeto Projeto
cliente Solicitao de
proposta
Contrato
Desenvolver software: Desenvolver software: Desenvolver software:
Lista Requisitos Cliente V06:Verificar Implantar Produto
a viabilidade Rel. Viabilidade Engenharia de Requisitos Projeto de Software Codificao
Projeto
Documento de financeira do Proposta
V05:Determinar Requisitos projeto
Requisitos
Rel. Viabilidade do Projeto
Acompanhar Controlar Projeto
do produto Doc
Proj Arquitetural Inicializao
V07: V11:Formalizar do Projeto
Proposta V08:Analisar
Elaborar incio Gerenciar Configurao
Documento de proposta
Requisitos proposta do projeto
Rel. anlise proposta Proposta
Proposta
Estratgia Planejar Projeto Administrar Recursos
Doc de Requisitos
Cronograma de Referencia
Projeto Arquitetural
Lista de Prod. De Trab. Reut. Rel. de Viabilidade
Escopo do Projeto
PP01: Estimar o escopo
Cronograma do projeto Cronograma PP02: Determinar Cron. de Referencia
estimativas de esforo e
custo
Doc de Requisitos
Rel. de Viabilidade
Planilha de Recursos Cronograma Plano Rec
PP04:
Planejar os recursos do
projeto Cronograma
Rel. de Viabilidade
ARP01:Determinar o
Plano de Recursos PP03: Estabelecer
oramento e durao tipo de aquisio
Cronograma Proposta
Solicitao de Solicitao de
Plano de Conhec. e Hab. Compra Compra
Cronograma
PP06: Definir Cronograma
time do projeto
Cal. de Colaboradores
Produto
Rel. de ARP02:Selecionar
Lista de Integrantes do Time ARP03:Aceitar o comprado
PP05: Identificar Viabilidade fornecedores e
riscos do projeto produto adquirido
estabelecer acordo
Plano de Recursos
PP07: Planejar
conhecimentos e PP08: Obter comprometimento
Plano de Riscos
Habilidades com o plano
Produto
necessrias
Plano de Conhec. e Hab. Atas de Reunio comprado
Plano de o Projeto
Planilha de Competncias
PP09:Detalhar produtos de trabalho, mtodos e Plano de Teste
critrios para VV&T
Doc de Engenharia Projeto de Software Codificao Implantar Produto

ER01:Detalhar Projeto Arquitetural
Requisitos
requisitos e
de Projeto Arquitetural Projeto HCI
funcionalidade Requisitos Doc de Requisitos
Proj Dados / Funcional
Cronograma
Doc de Requisitos Projeto Arquitetural
Doc de Requisitos Projeto de Dados Proj Dados / Funcional
PS01:Propor CS01:Refinar o Plano de Teste Arquivo de Cdigo Soluo
/ Funcional Projeto Arquitetural Doc de Requisitos
solues planejamento e CS04: Analisar Arquivo de Cdigo Doc de Requisitos
Plano de Riscos ER02:Analisar Plano de Riscos alternativas controlar a Arquivo CS03: Relatrio os resultados Relatrio Projeto Arquitetural
Empresa 1 criticamente os codificao de cdigo Proj Dados/Funcional

Verificar e validar de Teste da VV&T e de Teste CS05: Realizar
requisitos Doc de Requisitos PS02: Projetar Projeto de Dados / Funcional componentes/ identificar as aes corretivas IP01:
PS03: Projetar
Componentes
dados e Lista de tarefas mdulos aes Empacotar e
arquitetura Componentes Proj HCI
Doc de Requisitos funes corretivas entregar o produto
Projeto Arquitetural
Projeto de Dados
CS02: ou componente
Proj Dados / Funcional
ER03: Verificar / Funcional
PS04:Verificar Implementar o Doc de Requisitos Plano de Teste CS08:
e Consolidar Relatrio de Teste Desenvolver
requisitos projeto Relatrio de Teste Relatrio de Teste
Projeto Arquitetural Arquivo de cdigo
projeto Arquivo de Cdigo a documentao
Doc de Requisitos Relatrio de implantao
Projeto Arquitetural de suporte do
Doc de Requisitos
Projeto de Dados / Funcional Projeto HCI CS07: Realizar Teste CS06: Replanejar e produto
Proj Dados / Funcional de Regresso Plano de Teste realizar testes
Manual do Usurio
Plano de Teste ER04:Refinar e Plano de Teste PS05: Elaborar Plano de Teste Relatrio de Teste Manual de Instalao
detalhar os Doc de Requisitos projeto HCI Projeto HCI Arquivo de cdigo Plano de Teste
casos de teste
Gerenciar Configurao
Itens de Configurao
Itens de Configurao GC01:Identificar os Itens de Configurao GC02: Criar / Itens de Configurao GC03: Solicitar Pedido de mudana GC04: Analisar Autorizao de mudana GC05: Implementar Autorizao de mudana GC06: Liberar Baseline Documento de Requisitos Relatrio de Auditoria
GC08: Realizar a Relatrio de Auditoria
itens de GC07: Gerenciar Documento de Requisitos auditoria de
liberar baselines mudana mudana mudana Itens de Configurao mudana requisitos
configurao configurao
Acompanhar e Controlar Projeto

Entregveis Plano de Projeto Relatrio de Viabilidade do Projeto
Relatrio de duplicatas pagas
Relatrio de acompanhamento Relatrio de acompanhamento
ACP01:Conduzir do projeto Relatrio de acompanhamento
Plano de Projeto do projeto ACP02:Acompanhar Relatrio de duplicatas pagas Relatrio de duplicatas pagas ACP05:Cobrar ACP06:Analisar
revises de do projeto ACP03:Cadastrar e ACP04:Efetuar baixa Relatrio de Viabilidade do Projeto
o projeto Dados de desempenho pagamentos relatrio de
milestones Contrato Emitir Notas Fiscais das duplicatas pagas
atrasados viabilidade do projeto
Lies aprendidas
Relatrio de duplicatas emitidas
FIGURA 5.3 INSTNCIA DO MODELO GENRICO DO PV&DS ON-DEMAND PARA A EMPRESA 1

FIGURA 5.4 - VISO GRFICA DA FASE VENDER

FIGURA 5.5- VISUALIZAO GRFICA DO CONTEDO DOS ARTEFATOS DO PROCESSO PROPOSTO

FIGURA 5.6 - VISUALIZAO GRFICA DO CONTEDO DO ARTEFATO DOCUMENTO DE REQUISITOS

FIGURA 5.7 - DETALHAMENTO DE UMA ATIVIDADE DO MODELO DE PROCESSO PROPOSTO

FIGURA 5.8 EXEMPLO DE TEMPLATE
Aps uma anlise crtica em relao s entregas, citadas anteriormente, por
parte dos colaboradores da Empresa 1, foi iniciado o projeto de implementao da
fase de Vendas e Planejamento de Projeto do PV&DS on-demand instanciado para a
Empresa 1. Alguns resultados qualitativos do projeto de mudana implementao da

fase de Vendas do Processo de V&DS on-demand foram: um aumento nas vendas de
projetos de sistemas, a reduo no tempo de criao de propostas para o cliente (em
mdia, de 10 dias para 2 dias, segundo os vendedores da empresa) e melhor
comunicao entre os colaboradores da rea de venda e da rea tcnica da empresa.
A descrio detalhada da aplicao da Metodologia de Gesto de Mudana
encontra-se na dissertao de mestrado de Costa (COSTA, 2006).
Com o lanamento da verso 1.2 do CMMI, foi realizado um novo mapeamento
dos objetivos especficos definidos para cada rea de processo do CMMI-DEV em
relao s prticas-base da norma ISO/IEC 15504-5.
Durante a implantao de duas fases do modelo na Empresa 1 percebeu-se a
necessidade de alterar a estrutura do modelo (seqencial e linear) para retratar mais
fielmente os projetos normalmente existentes.
Foram estudados vrios modelos de processo de software existentes na
literatura (MILLS et al. 1987; BOEHM et al., 1998; JACOBSON et al., 1999;
PRESSMAN, 2006; SOMMERVILLE, 2007; ECLIPSE PROCESS FRAMEWORK
COMMUNITY, 2008) para ser definida a nova estrutura do modelo de descrio de
processo, agora denominado ProcSoftVD.
Selecionou-se o framework UP (Unified Process), pois propicia o
desenvolvimento incremental e evolutivo do software, o que se acredita ser o mais
voltado realidade. Alm disso, sua estrutura bi-dimensional permite a visualizao
das disciplinas ou workflows (neste trabalho de pesquisa denominado reas de
conhecimento) com maior ou menor nfase em cada uma das fases que compem o
processo e permite, tambm, que possam ser selecionadas as reas de conhecimento
que a empresa acredita serem prioritrias em cada ciclo de melhoria. .
Para essa nova verso do Modelo ProcSoftVD foram definidos alguns
requisitos, descritos na seo 5.2.1. Com o intuito de facilitar a visualizao do
relacionamento entre os elementos que compem o modelo ProcSoftVD foi elaborado
um meta-modelo, apresentado na seo 5.2.2. Na seo 5.2.3 so apresentadas as

duas perspectivas dessa nova verso do Modelo ProcSoftVD: fases e reas de
conhecimento.
5.2.1. Requisitos do ProcSoftVD
Os requisitos definidos nesta seo foram identificados durante a pesquisa-
ao realizada na Empresa 1. So eles:
As atividades do processo devem ser agrupadas por fases e tambm por
reas de conhecimento para auxiliar na visualizao, utilizao e controle
do processo;
Cada atividade deve ter uma descrio geral e um detalhamento em forma
de tarefas;
Para cada atividade devem ser indicados os possveis papis
desempenhados pelos responsveis em executar a atividade;
Para cada atividade devem ser indicados possveis recursos
(principalmente ferramentas computacionais) que poderiam auxiliar na
realizao da atividade;
Para cada atividade devem ser indicados os artefatos de entrada e sada
necessrios;
Para cada artefato do processo deve ser elaborado um template (formulrio
com a possvel estrutura dos artefatos), a fim de facilitar para uma MPE
saber o contedo que pode compor cada artefato;
Deve-se permitir que o usurio tenha, alm da viso textual das atividades
do processo, uma viso grfica. Essa viso grfica permite a visualizao
dos relacionamentos das atividades (o que difcil muitas vezes de ser
identificado na viso textual);
Deve-se permitir que o usurio tenha acesso s atividades de uma
determinada fase do processo selecionada (tanto na viso grfica quanto

na textual) e, a partir do acesso de uma delas, deve-se ter acesso s
respectivas atividades e seus artefatos de entrada e sada. A partir do
acesso de uma atividade deve ser possvel visualizar as tarefas, o(s)
recurso(s) necessrio(s) para realizao da atividade e o(s) papel(is)
desempenhado(s) pelo(s) responsvel(is);
Deve-se permitir que o usurio tenha acesso s atividades, de acordo com
uma determinada rea de conhecimento selecionada;
Deve-se permitir que o usurio tenha acesso aos objetivos especficos do
CMMI e s prticas-base da norma ISO/IEC 15504-5 que so atendidos por
cada uma das atividades pertencentes ao ProcSoftVD.
5.2.2. Meta-modelo do ProcSoftVD
O meta-modelo, apresentado na Figura 5.9, foi elaborado para facilitar a
visualizao do relacionamento entre os elementos que compem o modelo
ProcSoftVD.
Processo
composto estaticamente por composto dinamicamente por
reas de Conhecimento Fases

Classificam So agrupadas por
So agrupadas por
Classificam
So obtidos durante Entradas

Lies a realizao de / Sadas
Aprendidas Atividades Artefatos
So
incorporados So detalhadas Entradas
So nas Podem ser / Sadas
em um conjunto So realizadas
transformadas realizadas Atendem a de
Agregam de por
em com
Normas e Outras
Conhecimentos Tarefas Responsveis/ Modelos de fases
Recursos
Papis Capacidade
de Processo Possuem
Templates
FIGURA 5.9 META-MODELO DO PROCSOFTVD

O ProcSoftVD composto estaticamente por reas de conhecimento e
dinamicamente por fases. Assim, o modelo permite que o usurio tenha acesso s
atividades do processo, agrupadas por fase ou agrupadas por reas de conhecimento.
As atividades so detalhadas em um conjunto de tarefas, so realizadas por
responsveis que desempenham papis na organizao e podem ser realizadas com
recursos (como ferramentas).
Para a realizao das atividades tm-se como entrada artefatos e aps a
realizao das atividades so criados/modificados artefatos (sadas). Esses artefatos
possuem templates (formulrios que apresentam uma possvel estrutura para os
artefatos; alm disso, como suporte para os usurios, no prprio template h uma
breve reviso bibliogrfica relacionada ao artefato e em alguns casos, h alguns
exemplos).
As atividades do processo atendem s normas e modelos de capacidade de
processo (no caso, CMMI-DEV e ISO/IEC 15504-5). Durante a realizao de cada
uma das atividades, os responsveis podem registrar lies aprendidas que so
classificadas por reas de conhecimento e podem ser transformadas em
conhecimento integrante da memria organizacional da empresa que utilizada como
subsdio nos ciclos de melhoria do processo da empresa. Dessa forma, o
conhecimento obtido incorporado nas atividades do processo. Esses conhecimentos
so classificados por reas de conhecimento.
5.2.3. Perspectivas do ProcSoftVD
Como citado anteriormente, o ProcSoftVD possui duas perspectivas: fases e
reas de conhecimento.
a) Perspectiva - Fases
No modelo ProcSoftVD (Figura 5.10) foram adicionadas duas fases, alm das
fases sugeridas pelo UP: a fase de prospeco sugerida devido o modelo abranger
no s o desenvolvimento, mas tambm a venda do software. E, a fase de negociao
foi includa no modelo, pois os modelos de processo existentes no abordam
atividades relacionadas negociao de um contrato com o cliente para o
desenvolvimento do software. Essa fase de negociao importante para se
estabelecer o escopo do projeto e firm-lo em um contrato.
Ciclo de desenvolvimento
Fases
reas de Prospeco Concepo Negociao Elaborao Construo Transio
Conhecimento
Comercializao
Modelagem de Negcio
Produo de Requisitos
Projeto, Codificao & Integrao de Produto
V&V
Implantao
Aquisio
Medio
Garantia da Qualidade de Produto e Processo
Gesto de Requisitos
Gesto de Mudanas e Configurao
Gesto de Projeto
Gesto de Conhecimento
Milestones
FIGURA 5.10 MODELO PROCSOFTVD
Uma vez realizada a busca de potenciais clientes e algum deles tenha
solicitado uma proposta (fase de prospeco), inicia-se a fase de concepo. A fase
de prospeco realizada, normalmente, em apenas uma iterao.
A partir da fase de concepo at a fase de transio, forma-se o ciclo de
desenvolvimento que ocorre a cada release (verso entregue ao cliente) do produto
elaborado, ou seja, o software elaborado de forma incremental e evolutiva.
Entretanto, normalmente, o ciclo de desenvolvimento ocorre entre as fases de
elaborao a transio, pois se estender para a fase de concepo nos casos onde o
cliente solicita mudanas que implicam em criao de um novo contrato com novos
acordos relacionados ao escopo do projeto, prazo de entrega e preo. Na fase de

concepo tem-se uma viso geral do produto e seu trmino marcado pelo estudo
de viabilidade do projeto. Nessa fase h tantas iteraes quanto necessrias at que
haja um acordo entre as partes envolvidas em relao ao contrato. Tambm, nessa
fase estimada a quantidade de ciclos de desenvolvimento necessria para o produto
final ser concebido. Assim, para cada ciclo de desenvolvimento: na fase de elaborao
os requisitos so detalhados e so planejados os testes; na fase de construo os
requisitos so transformados em uma verso do produto e os testes planejados so
executados; e na fase de transio feito o teste de validao tanto pela empresa
desenvolvedora, a partir dos critrios de validao estabelecidos pelo cliente, quanto
pelo prprio cliente e realizada a implantao da verso no cliente. So realizados
os outros ciclos de desenvolvimento estimados para compor a verso final do produto.
De acordo com os feedbacks (retornos) do cliente, as verses podem ter que passar
por mais ciclos de desenvolvimento at estar de acordo com os requisitos
estabelecidos pelo cliente.
Para cada fase realizada tm-se atividades com maior nfase em determinadas
reas de conhecimento. Por exemplo, a rea de conhecimento Modelagem de
Negcio ocorre com maior nfase nas fases de prospeco e concepo, mas se
necessrio podem ser executadas atividades dessa rea na fase de elaborao,
tambm. Em cada fase podem existir vrias iteraes (repeties) das atividades que
a compem, dependendo da necessidade.
A cada trmino de fase h um milestone (marco de referncia) que indica o que
se espera como produto final de cada fase, alm de ser o marco onde so realizadas
atividades relacionadas garantia da qualidade do produto e do processo de software.
b) Perspectiva reas de Conhecimento
As micro e pequenas empresas (MPEs) podem optar por iniciar a melhoria do
processo de venda e desenvolvimento de software de sua empresa aos poucos,
selecionando as reas de conhecimento que acreditam ser de mais alta prioridade.

Para isso, utiliza-se o Mtodo para Melhoria do Processo de Software voltado para
MPEs (seo 5.3). Nesse caso, ela deve utilizar o modelo ProcSoftVD pela
perspectiva esttica, ou seja, pelas reas de conhecimento. Assim, acessando uma
rea de conhecimento, sero apresentadas todas as atividades de cada uma das
fases do modelo relacionadas de alguma maneira a essa rea de conhecimento. Cada
uma das atividades identificada por uma sigla seguida de um nmero seqencial que
reiniciado em cada fase (por exemplo: P01. Buscar contatos, CP02. Definir escopo
do projeto). Na fase de prospeco, as atividades so identificadas pela sigla P, na
fase de concepo por CP, na fase de negociao por N, na fase de elaborao por
E, na fase de construo por CT e na fase de transio por T.
As reas de conhecimentoGCf - Gesto de Mudanas e Configurao e GCo
- Gesto de Conhecimento permeiam todas as fases do modelo ProcSoftVD. Por isso,
podem ser acessadas a qualquer momento em meio realizao das atividades.
Quanto s reas de conhecimento consideradas nessa verso do ProcSoftVD,
tem-se todas as reas de processo do nvel de maturidade 2 do CMMI-DEV e o
restante das reas de processo da categoria Engenharia do CMMI no nvel de
capacidade 2. Em alguns casos, o nome da rea de conhecimento no o mesmo do
nome da rea de processo do CMMI, pois o nome sugerido no modelo ProcSoftVD foi
definido neste trabalho a partir da anlise da descrio das reas de processo do
CMMI, dos processos utilizados na ISO/IEC 15504-5 e dos workflows definidos pelo
Unified Process (UP). O Quadro 5.11 apresenta as reas de conhecimento cobertas
pelo ProcSoftVD e a associao com as reas de processo do CMMI, com os
processos da ISO/IEC 15504-5 e com os workflows do UP.

QUADRO 5.11 ASSOCIAO DAS REAS DE CONHECIMENTO DO PROCSOFTVD COM OUTROS MODELOS
reas de conhecimento do ProcSoftVD CMMI-DEV ISO/IEC 15504-5 Unified Process
- Prospeco do Fornecedor
Comercializao
- Acordado Contratual
Modelagem de Negcios Modelagem de Negcios
- Elicitao de Requisitos
Produo de Requisitos - Desenvolvimento de Requisitos - Anlise de Requisitos do Sistema
- Anlise de Requisitos do Software
- Projeto do Software
- Soluo Tcnica
Projeto, Codificao & Integrao de Produto - Integrao do Software - Implementao
- Integrao de Produto
- Integrao do Sistema
- Verificao
- Verificao - Validao
V&V - Teste
- Validao - Teste de Software
- Teste de Sistema
Implantao - Entrega de Produto - Implantao
Aquisio - Gesto de Acordo com o Fornecedor - Aquisio
Medio - Anlise e Medio - Medio
- Garantia da Qualidade de Produto e - Garantia da Qualidade de Produto e
Garantia da Qualidade de Produto e Processo
Processo Processo
Gesto de Requisitos - Gesto de Requisitos
- Gesto de Configurao - Gerenciamento de
Gesto de Mudanas e Configurao - Gesto de Configurao
- Gesto de Solicitao de Mudanas Configurao e Mudana
- Planejamento de Projeto
Gesto de Projeto - Monitoramento e Controle de - Gesto de Projeto - Gerenciamento de Projetos
Projeto
Gesto de Conhecimento Gesto de Conhecimento
Foi elaborado um questionrio (Apndice 1) aplicado a 5 (cinco) MPEs que
desenvolvem software on-demand e 9 (nove) CPDs (Centro de Processamento de
Dados) de empresas diversas os quais desenvolvem software on-demand para uso
interno, que confirmou a importncia de algumas reas de conhecimento definidas no
Modelo ProcSoftVD (Apndice 2) e indicou a importncia de outras reas de
conhecimento que sero melhor investigadas em um trabalho futuro.
Durante a anlise desse questionrio respondido pelas MPEs, notou-se que
quase todas elas acreditam ser muito importante entender e modelar o negcio do
cliente, entretanto, a maioria no o faz. Sendo assim, foi considerada tambm no
ProcSoftVD a rea de conhecimento Modelagem de Negcio, indicada pelo modelo
Unified Process. A rea de conhecimento Comercializao, apesar de no ser citada
pelo CMMI-DEV, bastante importante para as MPEs buscarem novos clientes,
elaborarem/submeterem propostas ao cliente, negociarem um contrato claro e sem
ambigidades que especifique as expectativas, responsabilidades, entregas e
compromissos de ambas as partes cliente e fornecedor, realizar a viabilidade
financeira do projeto e controlar os pagamentos dos produtos/servios vendidos pela
empresa.
As reas de conhecimento abordadas no ProcSoftVD e uma breve descrio
de cada uma delas feita, a seguir.
Comercializao: essa rea de conhecimento foi criada para abordar (1)
atividades relacionadas prospeco de potenciais clientes para a empresa (o que
no coberto pelo CMMI, nem pela ISO/IEC 15504-5); (2) atividades relacionadas
elaborao/submisso de propostas ao cliente e negociao e aprovao de contrato
sem ambigidades que especifique as expectativas, responsabilidades, entregas e
compromissos de ambas as partes cliente e fornecedor; (3) atividades relacionadas
viabilidade financeira do projeto e relacionadas ao pagamento dos produtos/servios
vendidos pela empresa. As atividades do item (2) foram definidas com subsdio dos
processos Prospeco do Fornecedor e Acordado Contratual da ISO/IEC 15504-5.
Modelagem de Negcio: o objetivo dessa rea de conhecimento
documentar os processos de negcio usando casos de uso de negcio23, a fim de
assegurar um entendimento comum entre todos os stakeholders (envolvidos) sobre as
necessidades existentes no processo de negcio da organizao cliente. Essa rea de
conhecimento teve sua origem no Unified Process.
Produo de Requisitos: tem o objetivo de produzir e analisar os requisitos do
cliente, do produto e dos componentes de produto. Essa rea de conhecimento teve
sua origem relacionada rea de processo Desenvolvimento de Requisitos do
CMMI-DEV e aos processos Elicitao de Requisitos, Anlise de Requisitos do
Sistema e Anlise de Requisitos do Software da ISO/IEC 15504-5.
Projeto, Codificao & Integrao de Produto: Engloba os processos
Projeto do Software, Integrao do Software e Integrao do Sistema da 15504-5,
o workflow Implementao do UP e as reas de processo Soluo Tcnica e
Integrao de Produto do CMMI-DEV. Segundo a 15504-5, o processo Projeto de
23
Ver RUP Rational Unified Process. Modelo integrado ferramenta CASE Rational Rose.
Software tem o objetivo de fornecer um design para o software que implementado e
pode ser verificado em confronto aos requisitos; o processo Integrao de Software
tem o objetivo de combinar as unidades de software, produzindo itens de software
integrados, consistentes com o projeto de software, os quais demonstram que os
requisitos funcionais e no-funcionais foram satisfeitos; e o processo Integrao do
Sistema tem como objetivo integrar os elementos do sistema (incluindo os itens de
software, itens de hardware, operaes manuais e outros sistemas, se necessrio)
para produzir um sistema completo que satisfaa ao projeto do sistema e s
expectativas do cliente, expressadas em requisitos do sistema. Segundo o modelo
CMMI-DEV, a rea de processo Soluo Tcnica tem como objetivo projetar,
desenvolver e implementar solues para os requisitos, solues essas que envolvem
produtos, componentes de produtos e processos de ciclo de vida relacionados ao
produto; e a rea de processo Integrao do Produto tem o objetivo de montar o
produto, a partir dos componentes de produto, assegurar que o produto ao ser
integrado funcione adequadamente, e entregar o produto.
V&V: Engloba as reas de processo (CMMI) e processos (15504-5) Validao
e Verificao e os processos Teste de Software e Teste de Sistema da 15504-5.
O objetivo da rea de processo/processo Validao demonstrar que o produto ou
componente do produto atenda ao uso pretendido quando colocado no ambiente
destinado. J o objetivo da rea de processo/processo Verificao assegurar que
produtos de trabalho (e servios, no caso do CMMI) selecionados alcancem seus
requisitos especificados. Testes desempenham um papel extremamente importante
em V&V (Verificao e Validao). Segundo o modelo 15504-5, o processo Teste
pode ser realizado tanto no software quanto no sistema. O processo Teste de
Software tem como objetivo confirmar que o produto de software integrado atende
aos requisitos definidos. E, o processo Teste de Sistema tem o objetivo de assegurar
que a implementao de cada requisito de sistema seja testada quanto sua
conformidade e que o sistema esteja pronto para entrega.

Implantao: o objetivo entregar o produto produzido para os usurios finais,
por meio das atividades de codificao, teste, empacotamento e instalao do
software. Essa rea de conhecimento teve sua origem no UP e tambm est
relacionada ao processo Entrega de Produto da 15504-5.
Aquisio: essa rea de conhecimento tem o objetivo de gerenciar a aquisio
de produtos de fornecedores, sejam equipamentos ou at mesmo componentes de
software do produto (no caso de terceirizao do servio). Exemplos de produtos e
componentes de produtos que podem ser adquiridos pelo projeto: subsistemas (por
exemplo, um sistema navegacional de uma aeronave), software, hardware,
documentao (como manuais de instalao, de operao e do usurio). A origem
dessa rea de conhecimento est relacionada ao grupo de processo Aquisio da
15504-5 rea de processo denominada Gesto de Acordo com Fornecedor do
CMMI-DEV.
Medio: essa rea de conhecimento tem o objetivo de coletar e analisar
dados relacionados aos produtos desenvolvidos e aos processos implementados
dentro da organizao por meio de projetos, a fim de dar um suporte efetivo gesto
dos processos e demonstrar objetivamente a qualidade dos produtos. Sua origem est
relacionada rea de processo Anlise e Medio do CMMI-DEV e do processo
Medio da 15504-5.
Garantia da Qualidade de Produto e Processo: o objetivo dessa rea de
conhecimento fornecer a garantia da qualidade dos processos e produtos de
trabalho. Sua origem est relacionada tanto ao CMMI quanto ISO/IEC 15504.
Gesto de Requisitos: o objetivo dessa rea de conhecimento, que teve sua
origem no CMMI-DEV, gerenciar os requisitos dos produtos e componentes de
produtos dos projetos e identificar inconsistncias entre esses requisitos e os planos e
produtos de trabalho dos projetos. Para isso, essa rea trata do rastreamento dos
requisitos em meio ao projeto e das mudanas desses requisitos. As mudanas

relacionadas aos requisitos utilizam algumas das atividades definidas pela rea de
conhecimento Gesto de Mudanas e Configurao.
Gesto de Mudanas e Configurao: essa rea de conhecimento engloba a
rea de processo Gesto de Configurao do CMMI-DEV e os processos Gesto de
Configurao e Gesto de Solicitao de Mudanas da 15504-5. O objetivo dessa
rea de conhecimento estabelecer e manter a integridade de produtos de trabalho
usando a identificao de configurao, controle de configurao, prestao de contas
(explicao) do status da configurao e auditoria da configurao, alm de assegurar
que solicitaes de mudanas no projeto sejam gerenciadas, rastreadas e controladas.
Gesto de Projetos: o objetivo dessa rea de processo identificar,
estabelecer, coordenar e monitorar as atividades, tarefas e recursos necessrios para
um projeto produzir um produto e/ou servio, no contexto dos requisitos e restries de
projetos. Engloba tanto o processo Gesto de Projetos da 15504-5 quanto as reas
de processo Planejamento de Projeto e Monitoramento e Controle de Projeto do
CMMI.
Gesto de Conhecimento: tem como objetivo assegurar que o conhecimento,
informao e habilidades individuais sejam coletadas, compartilhadas, reusadas e
melhoradas por toda a organizao. Sua origem est relacionada ao processo Gesto
de Conhecimento da ISO/IEC 15504. A Figura 5.12 apresenta as atividades da rea
de conhecimento Gesto de Conhecimento, por meio da notao SADT adaptada, e o
relacionamento dessas no contexto de melhoria de processo. Essa rea de
conhecimento permeia todo o processo de software, por isso, os responsveis durante
a realizao de atividades podem ter alguma lio aprendida (conhecimento) a ser
registrada. Essas lies aprendidas devem ser lapidadas por algum membro da
empresa que desempenhe o papel de avaliador do conhecimento (mesmo que tenha
subsdio da experincia de outros funcionrios), integrando a memria organizacional
da empresa. Uma vez que o conhecimento lapidado, pode ser disseminado para
todos os outros envolvidos no processo, por meio dos prximos ciclos de melhoria
definidos durante a aplicao do Mtodo de Melhoria do Processo de Software
(ProcSoftVD - Melhoria).
Sistema de Gesto
Conhecimento GCo01 Capturar o de Conhecimento
conhecimento
Responsveis
Lies Aprendidas e
Conhecimento
Sistema de Gesto
GCo02 Lapidar o de Conhecimento
conhecimento
Memria Organizacional
GCo03 Disseminar Memria Organizacional

o conhecimento
Ciclos de Melhoria
de Processo de
Software
FIGURA 5.12 ATIVIDADES DA REA DE GESTO DE CONHECIMENTO DO MODELO PROCSOFTVD
O Modelo ProcSoftVD completo encontra-se nos Apndices 3, 4 e 5 deste
trabalho. O Apndice 3 apresenta as atividades do modelo na viso textual, agrupadas
por fases e por reas de conhecimento, e na viso grfica. Alm disso, apresenta cada
uma das atividades com sua respectiva descrio, responsveis, artefatos de entrada
e sada, recursos e tarefas. O Apndice 4 apresenta todos os templates de artefatos
criado/utilizado no modelo e o Apndice 5 mostra o mapeamento das atividades do
modelo ProcSoftVD com os objetivos especficos do CMMI-DEV e as prticas-base da
ISO/IEC 15504-5.
5.3. Mtodo de Melhoria do Processo de Venda e

Desenvolvimento de Software On-demand para MPEs
(ProcSoftVD Melhoria)
Quando a empresa decide realizar algum tipo de melhoria em seus processos,
importante que essa melhoria seja analisada e planejada, antes de ser executada.
Existem vrios mtodos de melhoria disponveis na literatura (DEMING, 1986;
MCFEELEY, 1996; INTERNATIONAL ORGANIZATION FOR STANDARDIZATION,
2003; WEBER et al., 2005b; SALVIANO, 2006; COSTA, 2006). Para utilizar o
ProcSoftVD em um contexto de gesto de processos poderia ser utilizado,
inicialmente, qualquer um desses mtodos. Entretanto, realizando uma anlise desses
mtodos (Quadro 5.13) percebeu-se uma complementaridade entre alguns deles e,
por isso, foi elaborado o Mtodo de Melhoria de Processo (ProcSoftVD Melhoria),
descrito nessa seo, a partir da combinao de trs abordagens: ASPE/MSC
(WEBER et al., 2005b), PRO2PI-WORK (SALVIANO, 2006) e Metodologia de Gesto
de Mudanas (COSTA, 2006).
QUADRO 5.13 QUADRO COMPARATIVO DOS MTODOS DE MELHORIA DE PROCESSO

Metodologia de Gesto de
ProcSoftVD - Melhoria ASPE/MSC PRO2PI-WORK
Mudanas
Diagnstico do Processo de
Fase 1 - Diagnstico do Processo de Software Atual e Definio do Perfil-Alvo
Software Atual Definio do Perfil-Alvo
1.1 Descrever o processo de software atual X X
1.2 Identificar com os diretores da empresa os objetivos estratgicos do negcio,
X
considerando metas de melhoria
1.3 Definir os perfis-alvo do processo X
Fase 2 - Anlise Estratgica e Planejamento da Mudana Anlise Estratgica Planejamento da Mudana
2.1 Identificar, analisar e priorizar as reas de conhecimento a serem melhoradas, com

X
base nos perfis-alvo definidos na fase 1
2.2 Definir um plano de ao X (superficialmente) X (detalhadamente)
Fase 3 - Definio das atividades da(s) rea(s) de conhecimento X

3.1 Identificar as principais atividades que sero executadas durante a realizao da
X
rea de conhecimento
3.2 Identificar os papis e as responsabilidades relacionadas a cada atividade
X
selecionada
3.3 Identificar os artefatos que sero consumidos ou produzidos durante a execuo de X

cada atividade, e, caso existam, seus respectivos templates
3.4 Identificar as medidas que devem ser coletadas durante a execuo de uma
X
atividade
3.5 Identificar outras informaes importantes, como critrios de entrada e de sada,
X
mtodos e ferramentas
Fase 4 - Implantao da(s) rea(s) de conhecimento X

X
4.1 Planejar como ser avaliada a rea de conhecimento durante a sua execuo
4.2 Definir escopo de utilizao da rea de conhecimento X
4.3 Treinar e motivar os participantes envolvidos X
4.4 Iniciar o uso do guia X
4.5 Analisar e interpretar os dados coletados durante a utilizao do guia X
4.6 Apresentar os resultados da anlise para a diretoria X
A primeira refere-se a uma abordagem para estabelecimento de processo de
software em MPEs, a segunda refere-se a um mtodo para estabelecimento do perfil
de capacidade de processo para melhoria de processo em MPEs e a terceira refere-se
a uma metodologia de gesto de mudanas que incorpora melhores prticas de
gesto de projeto ao tratar as mudanas a serem realizadas por meio de projetos de
mudanas.
O ProcSoftVD - Melhoria composto por quatro fases, descritas a seguir,
sugeridas pela ASPE/MSC (WEBER et al., 2005b) e adaptadas neste trabalho de
pesquisa, a atividade de definio do perfil de processo realizada utilizando a
estratgia definida no PRO2PI-WORK (SALVIANO, 2006) e a atividade relacionada
definio de um plano de ao realizada com base nas melhores prticas de gesto
de projetos sugeridas por Costa (2006) em sua Metodologia de Gesto de Mudanas.

Fase 1. Diagnstico do Processo de Software Atual e Definio do Perfil-Alvo
Nessa fase deve ser realizado o diagnstico do processo de software
atualmente utilizado na MPE. As atividades pertencentes a essa fase so:
1.1 Descrever o processo de software atual da empresa em alto nvel. Para isso pode
ser usada qualquer representao de modelagem de processo, tais como: SADT
(Structured Analysis and Design Technique) (MCGOWAN & MARCA, 1987), IDEF0
(Integration definition for function modeling) (AIR FORCE, 1980), EPC (Event-
driven process chain) (SCHEER, 1998), UML (Unified Modeling Language) e
BPMN (Business Process Modeling Notation) (BUSINESS PROCESS
MANAGEMENT INITIATIVE, 2008) ou at mesmo uma descrio textual.
1.2 Identificar com os diretores da empresa os objetivos estratgicos de negcio,
considerando metas de melhoria.
1.3 Definir os perfis-alvo do processo, ou seja, quais so as reas de conhecimento
mais importantes para a empresa e qual o respectivo nvel de capacidade que elas
devem possuir para que os objetivos estratgicos e de melhoria sejam alcanados,
considerando o escopo do modelo de referncia utilizado (no caso, sugere-se o
Modelo ProcSoftVD proposto neste trabalho de pesquisa). Isso pode ser realizado
em uma reunio com pessoas representantes do nvel gerencial e operacional da
empresa. Para cada rea de conhecimento devem ser realizadas as tarefas, a
seguir, da forma mais rpida possvel24 :
apresenta-se a definio da rea de conhecimento, conforme o modelo de
referncia utilizado; os principais sintomas tpicos quando ela no bem
executada e os principais benefcios que justificam porque ela importante.
discute-se e identifica-se a correspondncia da rea de conhecimento na
organizao.
identifica-se como a rea de conhecimento executada atualmente, ou seja,
em qual nvel de capacidade e justificativas.
24
Em Salviano (2006) sugerido no exceder 20 minutos.
define-se a importncia da rea de conhecimento para os objetivos
estratgicos da organizao, observando os benefcios tpicos de sua
execuo, com pontuao baixa, mdia ou alta, descrevendo as razes da
pontuao.
define-se o risco em continuar executando a rea de conhecimento da forma
como executada atualmente na empresa, definindo uma pontuao (baixa,
mdia ou alta), e descreve-se as razes da pontuao.
posiciona-se cada rea de conhecimento no quadro de importncia versus
risco e atribui-se uma pontuao para as combinaes, com preferncia para a
importncia. A pontuao, apresentada na Tabela 5.14, sugerida em
Salviano (2006).
TABELA 5.14 PONTUAO PARA AS REAS DE CONHECIMENTO (SALVIANO, 2006)

Risco Baixo Mdio Alto
Importncia
Alta 6 9 10
Mdia 4 7 8
Baixa 2 3 5
Fase 2. Anlise Estratgica e Planejamento da Mudana
Esta fase tem por objetivo a definio e priorizao das aes para o
estabelecimento de reas de conhecimento na empresa, baseado no diagnstico e de
acordo com os objetivos estratgicos e as metas de melhoria. Essas aes sero
tratadas como um projeto de mudana. As atividades a serem realizadas nessa fase
so:
2.1 Identificar, analisar e priorizar as reas de conhecimento a serem melhoradas, com
base nos perfis-alvo definidos na fase 1. As reas de conhecimento a serem
priorizadas so as com maior pontuao, atribuda durante a atividade 1.3. Dentre
essas reas de conhecimento selecionadas pode(m) ser definida(s), ainda, a(s)

mais prioritria(s) a ser(em) considerada(s) nos primeiros ciclos de melhoria. Para
isso devem ser considerados benefcios, custos estimados, interdependncia entre
reas de conhecimento, metas de negcio e melhoria, freqncia de uso da rea
de conhecimento, grau de divergncia entre seus executores, nmero de atores
envolvidos, etc. Poucas reas de conhecimento devem ser selecionadas para
serem estabelecidas em cada ciclo de melhoria.
2.2 Definir um plano de ao. Para isso, deve-se:
Definir um patrocinador dentro da organizao cujas responsabilidades
englobam assegurar o comprometimento da alta gerncia e assegurar
verba para que os recursos necessrios durante o processo de mudana
sejam fornecidos.
Definir o escopo do projeto de mudana: deve-se definir, em detalhes, as
entregas do projeto de mudana e as aes necessrias para criar essas
entregas. Devem ser documentados caractersticas e limites do projeto,
alm dos mtodos de aceitao e controle do escopo. O escopo do projeto
de mudana deve fornecer um entendimento comum a todos os
stakeholders e descrever os principais objetivos do projeto.
Criar a WBS (Work Breakdown Structure): o objetivo desta atividade
dividir as principais entregas do projeto e os pacotes de trabalho em
componentes menores, ou seja, em atividades que se deseja controlar e
monitorar durante o projeto.
Elaborar o cronograma do projeto: deve-se estabelecer a programao do
projeto, na qual estaro definidas as datas de incio e trmino de cada
atividade planejada, a precedncia entre elas, as pessoas responsveis por
cada uma delas e os recursos necessrios para a sua execuo. Quando o
cronograma estiver elaborado, deve-se nivelar o esforo das pessoas da
equipe em relao realizao das atividades para evitar sobrecarga de
algum colaborador, ou criar gargalos no desenvolvimento do projeto de

mudana, decorrentes de excesso de atividades atribudas mesma
pessoa.
Avaliar os riscos: importante identificar os principais riscos do projeto de
mudana e administrar os riscos. Uma vez identificados, para administr-los
preciso definir a probabilidade de ocorrncia e o impacto de cada um
deles. Para os riscos de maior importncia e probabilidade de ocorrncia,
deve ser criado um plano de ao para sua mitigao e um plano de
contingncia.
Garantir a infra-estrutura: deve-se garantir como a empresa vai dar
suporte mudana. Devem ser definidos os treinamentos para as equipes,
como elas sero avaliadas, quais as ferramentas necessrias para a
execuo da mudana, e se a infra-estrutura existente adequada.
Fase 3. Definio das atividades da(s) rea(s) de conhecimento
Nessa fase deve ser realizada a definio/adaptao das atividades das reas
de conhecimento, selecionadas no projeto de mudana anteriormente planejado, de
forma explcita e descritiva, para que as pessoas se orientem durante a execuo
dessas atividades. Para isso, poderiam ser utilizados normas e modelos de referncia,
tais como ISO/IEC 12207, CMMI, ISO/IEC 15504 e, at mesmo, processos
proprietrios como o RUP. Neste trabalho de pesquisa, sugere-se a utilizao do
Modelo ProcSoftVD.
As atividades que compem essa fase so:
3.1 Identificar as principais atividades que sero executadas durante a realizao da
rea de conhecimento. A seqncia de execuo que elas acontecem e os desvios
condicionais existentes podem ser visualizados por meio de um fluxograma ou de
diagramas SADT.
3.2 Identificar os papis e as responsabilidades relacionados a cada atividade
selecionada.
3.3 Identificar os artefatos que sero consumidos ou produzidos durante a execuo
de cada atividade, e, caso existam, seus respectivos templates.
3.4 Identificar as medidas que devem ser coletadas durante a execuo de uma
atividade, pois estabelecem quais dados quantitativos e qualitativos sero
coletados para dar suporte gerncia de projetos, a melhoria e a garantia da
qualidade.
3.5 Identificar outras informaes importantes, como critrios de entrada e de sada,
mtodos e ferramentas.
Fase 4. Implantao da(s) rea(s) de conhecimento
Nessa fase a rea de conhecimento definida anteriormente deve ser
institucionalizada e avaliada. Para isso, deve-se garantir que todos os envolvidos
conheam e utilizem a rea de conhecimento e sejam coletados dados que dem
informaes sobre os resultados obtidos. As atividades a serem realizadas so:
4.1 Planejar como ser avaliada a rea de conhecimento durante a sua execuo. So
definidas medidas que devem ser coletadas durante o uso da rea de
conhecimento, visando anlise das metas que foram definidas na fase de anlise
estratgica. Para isso, pode ser usado o mtodo GQM (Goal-Question-Metric)
(BASILI & WEISS, 1984).
4.2 Definir o escopo de utilizao da rea de conhecimento, ou seja, decidir se o guia
elaborado ser utilizado inicialmente em todos os projetos da empresa ou apenas
ser executado um projeto piloto para avaliao.
4.3 Treinar e motivar os participantes envolvidos, dentro do escopo que foi definido,
para que estejam aptos a desempenhar suas atividades. O objetivo desta atividade
mobilizar as pessoas integrantes da equipe do projeto de mudana, preparar e
aplicar os treinamentos definidos como sendo requisitos para garantir a eficcia do
projeto de mudana.
4.4 Iniciar o uso do guia. Durante a utilizao, as dvidas que surgem so
esclarecidas, sugestes e observaes so anotadas e as medidas definidas
durante o planejamento da avaliao so coletadas.
4.5 Analisar e interpretar os dados coletados durante a utilizao do guia. Essa
atividade deve ser realizada pelo engenheiro de processo junto a alguma outra
pessoa da organizao.
4.6 Apresentar os resultados da anlise para a diretoria, para a tomada de deciso
relacionada iniciao de um novo ciclo de melhoria projeto de mudana.
5.4. Publicao web do Modelo de Gesto do Processo de

Venda e Desenvolvimento On-demand para MPEs
O ProcSoftVD Gesto encontra-se disponvel no endereo
www.numa.org.br/GProcSoftVD. Na pgina principal (Figura 5.15) encontra-se uma
breve introduo sobre o modelo. H um menu do lado esquerdo com quatro links:
Viso Grfica, Viso Textual, Mapeamento com CMMI e ISO/IEC 15504 e
ProcSoftVD - Melhoria. O primeiro link Viso Grfica refere-se apresentao do
modelo em forma grfica, onde as atividades sero representadas com a notao
SADT (MCGOWAN & MARCA, 1987) adaptada.

FIGURA 5.15 PGINA PRINCIPAL DO GPROCSOFTVD
Acessando o link Viso Grfica possvel visualizar as atividades do modelo
e a seqncia entre elas. A Figura 5.16 apresenta um exemplo de viso grfica.

FIGURA 5.16 EXEMPLO DE VISO GRFICA FASE DE PROSPECO
Acessando o link Viso Textual possvel ter uma viso dinmica (por fases)
e esttica (por reas de conhecimento) do modelo (Figura 5.17). Clicando nas fases,
tem-se acesso a uma pgina que mostra todas as atividades do modelo com suas
respectivas entradas e sadas. Um exemplo apresentado na Figura 5.18. Clicando
nas atividades, tem-se acesso a uma pgina com todos os detalhes dessa atividade.
Nessa pgina, as entradas e sadas que possurem templates tero um link e os
documentos com templates citados nas tarefas, sero representados com a marcao
( T ) (Figura 5.19). Os templates so formulrios com uma possvel estrutura para o
artefato correspondente e, em alguns deles h exemplos e at mesmo uma breve
reviso bibliogrfica para explicar os conceitos pertinentes ao artefato.

FIGURA 5.17 VISO TEXTUAL: PERSPECTIVA POR FASES E POR REAS DE CONHECIMENTO
FIGURA 5.18 EXEMPLO DE UMA ATIVIDADE - FASE DE PROSPECO

FIGURA 5.19 EXEMPLO DE DETALHAMENTO DE ATIVIDADE
Acessando o link Viso Textual tambm possvel visualizar as reas de
conhecimento do modelo no menu esquerda. Clicando nas reas de conhecimento,
tem-se acesso a uma pgina que mostra todas as atividades do modelo que possuem
algo a ser realizado relativo quela rea de conhecimento (Figura 5.20). Clicando nas
atividades, voc tem acesso a uma pgina com todos os detalhes dessa atividade,
como mostrado na Figura 5.19. Essa opo de visualizar as atividades por rea de
conhecimento interessante para as MPEs que definiram um perfil de capacidade de
processo a ser alcanado, ou seja, quais so as reas de conhecimento de mais alta

prioridade a serem melhoradas em sua empresa, por meio da aplicao do Modelo
para Melhoria do Processo de Software voltado para MPEs (acessado por meio da
pgina inicial do site, ao clicar no link Melhoria do Processo de Software voltado para
MPEs no menu do lado esquerdo).
FIGURA 5.20 ATIVIDADES DA REA DE CONHECIMENTO GESTO DE CONHECIMENTO
O mapeamento de todas as atividades do modelo ProcSoftVD com os objetivos

especficos do CMMI-DEV e prticas-base da ISO/IEC 15504-5 est disponvel por
meio do acesso ao link Mapeamento com CMMI e ISO/IEC 15504 no menu do lado
esquerdo da pgina inicial do site (Figuras 5.21 e 5.22).
FIGURA 5.21 M APEAMENTO DO PROCSOFTVD COM CMMI E ISO/IEC 15504-5

FIGURA 5.22 EXEMPLO DE MAPEAMENTO DA ATIVIDADE DEFINIR ESCOPO DO PROJETO
Os Apndices 3, 4 e 5 apresentam o modelo ProcSoftVD por completo.
Este captulo apresentou o processo de desenvolvimento da principal entrega
deste trabalho de pesquisa: o Modelo de Gesto do Processo de Venda e
Desenvolvimento de Software On-demand para MPEs (ProcSoftVD Gesto).
No prximo captulo so apresentadas as aplicaes do Modelo ProcSoftVD -
Gesto e os resultados obtidos durante essas aplicaes.

Captulo 6. Aplicaes e Resultados P g i n a | 113
6. Aplicaes e Resultados do Modelo ProcSoftVD -

Gesto

O ProcSoftVD - Gesto foi aplicado em uma MPE (seo 6.2) e o ProcSoftVD
foi verificado em dois tipos de avaliao: anlise dos pontos fortes e fracos do modelo
por parte de profissionais da rea (seo 6.3) e anlise do modelo quanto s
caractersticas de qualidade de produto (seo 6.4).
6.2. Aplicao do ProcSoftVD - Gesto

A aplicao foi realizada em uma MPE (Empresa 2) que possui uma carteira de
40 (quarenta) clientes, aproximadamente, e possui 3 (trs) funcionrios.
Aps a aplicao do mtodo de melhoria de processo ProcSoftVD - Melhoria,
descrita no Apndice 6, as reas de conhecimento Modelagem de Negcios e
Produo de Requisitos foram selecionadas como mais prioritrias e, por isso, foram
implantadas no primeiro ciclo de melhoria nessa MPE.
Foi relatado pelo desenvolvedor que aplicando as atividades e templates
sugeridos para essas reas de conhecimento, pde perceber o quo mais fcil
desenvolver um software quando se entende realmente o negcio do cliente e quando
esse negcio documentado de alguma forma que lhe d subsdio para tirar eventuais
dvidas durante a definio dos requisitos do software a ser desenvolvido.
Anteriormente aplicao dessas reas de conhecimento, no se tinha
nenhuma sistemtica em relao a elas na empresa, alm de no se ter templates
para facilitar o registro das informaes obtidas com o cliente. O desenvolvedor da
empresa tambm relatou que o tempo investido para realizar as atividades de
modelagem de negcios e produo de requisitos foi compensado por meio da

minimizao de erros encontrados no software ao realizar os testes de mesa, da forma
como realizam na empresa.
6.3. Anlise dos Pontos Fortes e Fracos do Modelo

ProcSoftVD
Foi realizada uma anlise do modelo ProcSoftVD por 6 (seis) profissionais da
rea de computao, a partir de um questionrio (Apndice 7).
Os critrios a serem atendidos para selecionar esses profissionais foram: ter
experincia como analista de sistemas e desenvolvedor de programas e ter
conhecimentos a respeito da rea de engenharia de software. O perfil de cada um dos
profissionais descrito, a seguir.
- Um profissional (P1) com graduao na rea de computao e mestrado na
rea de informtica educacional que j trabalhou em empresas desempenhando as
funes de analista de sistemas/programador e at mesmo de gerente de CPD.
Atualmente, docente em uma universidade e leciona disciplinas, tais como:
Fundamentos de Sistemas de Informao, Gesto da Informao e de Sistemas de
Informao, Ingls Tcnico, Introduo Cincia da Computao e Engenharia de
Software.
- Um profissional (P2) com graduao e mestrado na rea de computao que
j trabalhou em um CPD de uma universidade desempenhando as funes de analista
de sistemas/programador. Atualmente, docente em uma universidade e leciona
disciplinas, tais como: Algoritmos, Engenharia de Software, Banco de Dados,
Linguagens de Programao (Delphi, JavaScript).
- Um profissional (P3) com graduao e mestrado na rea de computao que
atua como coordenador do Curso em Cincia da Computao em uma universidade e
docente de disciplinas, tais como: Anlise e Projeto de Sistemas Orientados a Objetos,
Engenharia de Software, Banco de Dados, Algoritmos e Linguagens de Programao.

- Um profissional (P4) com graduao, mestrado e doutorado na rea de
computao que j trabalhou desempenhando o papel de analista de
sistemas/programador em uma empresa. Atualmente, docente em uma universidade
pblica e leciona as disciplinas: Engenharia de Software, Linguagens de Programao
(JAVA), Compiladores e Teoria da Computao. J atuou como programador em
empresas.
- Um profissional (P5) que est finalizando seu curso de graduao em
Sistemas de Informao, entretanto, proprietrio de uma empresa de
desenvolvimento de software que est no mercado h 8 anos e tem uma carteira de,
aproximadamente, 40 clientes de um determinado produto da empresa a MPE onde
foram aplicadas as reas de conhecimento Modelagem de Negcios e Produo de
Requisitos.
- Um profissional (P6) que est finalizando seu curso de graduao em
Sistemas de Informao, tem uma empresa de desenvolvimento de software incubada
na INTEPP (Incubadora Tecnolgica de Presidente Prudente) e adotou o modelo de
processo, elaborado nesse trabalho de pesquisa, como guia para orientar nas
atividades de venda e desenvolvimento de software na sua empresa.
As respostas desses 6 (seis) profissionais da rea de computao podem ser
visualizadas no Apndice 8. Os resultados consolidados, a partir dessas respostas,
so:
Quanto rea de Conhecimento Comercializao: o modelo cobre
atividades relacionadas comercializao as quais a organizao
desenvolvedora deve se preocupar. Essas atividades fornecem condies
para o gerenciamento do contato com o cliente, transmitindo eficincia e
credibilidade perante o cliente, alm de abranger aspectos formais da
comercializao sem exageros, por meio de uma linguagem de fcil
entendimento.
Quanto rea de Conhecimento Modelagem de Negcios: as tarefas
que incluem a modelagem de negcio esto claramente definidas, com foco
em aspectos fundamentais dessa rea de conhecimento. H clareza na
exposio das atividades e riqueza de detalhes por meio dos templates que
mostram exemplos e sugestes.
Quanto rea de Conhecimento Produo de Requisitos: Tempo
despendido em modelagem, anlise e produo de requisitos um
excelente investimento, e no um gasto - comentrio realizado por um dos
profissionais. O modelo apresenta as atividades e templates relacionados
produo de requisitos de modo completo, seguindo diretrizes do padro de
documentao de requisitos IEEE 830 e atendendo aos objetivos
especficos do CMMI em relao rea de processo Desenvolvimento de
Requisitos. Entretanto, um dos profissionais relatou que o material para ser
lido, analisado, documentado e empreendido, para autnomos e equipes
pequenas, bastante extenso.
Quanto rea de Conhecimento Projeto, Codificao & Integrao de
Produto: um dos profissionais relatou que um software deve ser bem
projetado para ser desenvolvido de forma a permitir uma fcil manuteno e
evoluo dele, pois os custos de manuteno so muito superiores ao
custo de desenvolvimento. O modelo apresenta um vasto material de apoio
para a transformao dos requisitos em uma soluo de projeto,
fornecendo subsdios para o incio da codificao por parte dos
responsveis pelo desenvolvimento do software.
Quanto rea de Conhecimento V&V: as atividades de V&V,
especialmente os testes, tm grande importncia durante o
desenvolvimento do software. Essas atividades foram bem distribudas nas
fases do modelo ProcSoftVD, tendo uma presena marcante no modelo.

Quanto rea de Conhecimento Implantao: o modelo apresenta
atividades relacionadas implantao dos releases do produto ao cliente
de forma completa, facilitando o gerenciamento das entregas ao cliente.
Quanto rea de Conhecimento Aquisio: o modelo contribui com
essa rea de conhecimento, pois mostra com clareza o que pode ser
realizado para realizar a cotao e anlise dos melhores fornecedores para
viabilizar o projeto de desenvolvimento para a empresa e para ter controle
da qualidade dos produtos/servios adquiridos.
Quanto rea de Conhecimento Medio: o modelo fornece subsdios
para se obter dados relacionados aos projetos da empresa, dados como
tempo estimado e concretizado, valor cobrado, entre outros, que sero
utilizados para estimativas em projetos futuros. Alm disso, deixa evidente
a importncia da definio de critrios de medio e coleta de medidas para
o aprimoramento do processo e para a garantia da qualidade do produto.
Quanto rea de Conhecimento Garantia da Qualidade de Produto e
Processo: a garantia da qualidade tanto do produto quanto do processo foi
apontada no modelo em todas as etapas de desenvolvimento, o que
representa uma potencialidade do modelo.
Quanto rea de Conhecimento Gesto de Requisitos: a gesto de
requisitos abordada no modelo de maneira bem articulada e completa.
Durante o avano nas fases do modelo, nas atividades onde podem ser
realizadas modificaes nos requisitos, o modelo apresenta atividades de
rastreamento dos requisitos e direciona as modificaes para serem
tratadas pelas atividades de gesto de mudanas e configurao. Um ponto
vulnervel detectado foi o caso de no estar explcito no modelo o
gerenciamento dos requisitos relacionados aos possveis componentes (de
software, por exemplo) adquiridos de fornecedores.

Quanto rea de Conhecimento Gesto de Projetos: importante
entender o escopo do projeto e fazer o planejamento preliminar desse
escopo, a fim de ser ter uma viso macro em relao ao que se pretende
atingir com o produto resultante do projeto, quanto custar, quanto tempo
demorar para ser produzido e qual o retorno financeiro desse projeto. E,
tambm, importante fazer o monitoramento e controle desse projeto para
que se possa tomar medidas reativas e at mesmo pr-ativas. O modelo
ProcSoftVD atende a esses requisitos.
Quanto rea de Conhecimento Gesto de Mudanas e Configurao:
o modelo mostra os cuidados que devem ser tomados e os controles
necessrios ao ser realizada alguma modificao no projeto em
desenvolvimento. Entretanto, seria interessante que o modelo explicitasse
alguma forma de help-desk para auxiliar no controle das solicitaes de
modificaes, principalmente do cliente.
Quanto rea de Conhecimento Gesto de Conhecimento: o modelo
mostra uma forma de gerenciar o conhecimento de todos os colaboradores
da empresa, fazendo com que o conhecimento e experincia de um
colaborador sejam disseminados para outros interessados.
Alm de identificar pontos fracos e fortes do modelo em relao a cada rea de
conhecimento, os seis profissionais responderam a quatro questes. As respostas
para essas questes encontram-se no Apndice 9. Para os profissionais que no
conheciam o CMMI e a ISO/IEC 15504, foi realizada uma apresentao, expondo os
conceitos, estrutura e funcionamento de cada um deles.
Quanto anlise do mapeamento das atividades do modelo ProcSoftVD para
com os objetivos especficos do CMMI e as prticas-base da ISO/IEC 15504-5, foram
realizadas entrevistas desestruturadas com os profissionais (P1, P2, P3, P4, P5 e P6).
De forma geral, esses profissionais acreditam que esse mapeamento possa ser
bastante interessante para o caso de empresas que desejam futuramente iniciar um
processo de certificao pelo CMMI ou MPS.BR, e at mesmo para que as empresas
tenham conscincia que as atividades sugeridas pelo modelo ProcSoftVD so
condizentes com o que modelos de capacidade de processo existentes no mercado
definem como sendo o ideal.
6.4. Anlise das caractersticas de qualidade do Modelo

ProcSoftVD
O modelo ProcSoftVD foi avaliado pelos profissionais (P1, P2, P3, P4, P5 e P6)
quanto a cinco caractersticas de qualidade definidas pela ISO/IEC 9126-125,
adaptadas para o produto modelo de processo de software. As caractersticas
avaliadas so: funcionalidade, usabilidade, manutenibilidade, portabilidade e
eficincia.
Os profissionais selecionaram entre os nveis de atendimento alto, mdio,
baixo e NA no se aplica do modelo ProcSoftVD para cada uma das
subcaractersticas da caracterstica avaliada e, tambm, fizeram comentrios
justificando suas respostas. As opes selecionadas pelos profissionais quanto s
subcaractersticas foram organizadas no Quadro 6.1.
25
ISO/IEC 9126-1: International Standard Organization (2001). Software Engineering - Product Quality.
Part 1: Qualit Model.
QUADRO 6.1 CARACTERSTICAS DE QUALIDADE DO MODELO PROCSOFTVD

Caractersticas Subcaractersticas P1 P2 P3 P4 P5 P6
Adequao: Prope-se a fazer o que apropriado? Alto Alto Alto Mdio Alto Alto
Funcionalidade:
Acurcia: Faz o que foi proposto de forma precisa? Alto Alto Mdio Baixo Mdio Alto
Satisfaz as
Interoperabilidade: Interage com modelos/normas especificados? Alto Alto Mdio Mdio Mdio Alto
necessidades?
Segurana: Evita acesso no autorizado aos dados? Baixo NA NA NA NA Baixo
Inteligibilidade: fcil entender sua aplicao e operao? Alto Alto Mdio Baixo Mdio Alto
Usabilidade: fcil de Aprendizagem: fcil de aprender a usar? Alto Mdio Mdio Baixo Mdio Mdio
usar? Operacionalizao: fcil de operar e controlar? Alto Alto Mdio Baixo Mdio Mdio
Atratividade: Pode ser atraente ao usurio? Alto Alto Mdio Baixo Mdio Alto
Analisabilidade: fcil de encontrar uma falha, quando ocorre? Alto Mdio Baixo Baixo Alto Alto
Manutenibilidade: Modificabilidade: fcil modificar e adaptar? Mdio Alto Mdio Baixo Alto Alto
fcil de modificar? Estabilidade: H grande risco quando se faz alteraes? Alto Alto Alto Baixo Mdio Mdio
Testabilidade: fcil testar quando se faz alteraes? Alto Alto Mdio Baixo Mdio Mdio
Adaptabilidade: fcil adaptar a outros ambientes (no caso, outras

Mdio Mdio Alto NA Mdio Alto
MPEs)?
Portabilidade: fcil Capacidade para ser instalado: fcil instalar em diversos ambientes
Baixo Alto Alto NA Mdio Alto
de usar em outro (no caso, em diversas MPEs)?
ambiente (no caso, em Capacidade para co-existir: capaz de repartir os recursos com outro
Alto Mdio Mdio NA Mdio Alto
outra MPE)? modelo de processo de software?
Capacidade para substituir: Ele pode facilmente substituir outro modelo
NA Alto Baixo NA NA Alto
de processo de software?
Tempo de resposta: Qual o tempo de resposta, a velocidade de

Alto Alto Baixo Baixo Mdio Mdio
Eficincia: rpido e execuo?
"enxuto"?
Baixo Alto Alto Alto Alto Alto
Recursos empregados: Quanto recurso usa? Durante quanto tempo?
Pode-se verificar divergncia nas respostas dos profissionais P1, P2, P3, P4,
P5 e P6 (Figura 6.2), uma vez que no houve consenso em relao a nenhuma
caracterstica analisada, evidenciando a influncia dos conhecimentos prvios desses
profissionais.
Funcionalidade: Satisfaz as
necessidades?
4
3.5
2.5
1.5
Eficincia: rpido e "enxuto"? Usabilidade: fcil de usar?
1 P1
P2
0.5
P3
0
P4
P5
P6
Portabilidade: fcil de usar em Manutenibilidade: fcil de

outro ambiente (MPE)? modificar?
FIGURA 6.2 GRFICO DE RELAO ENTRE AS RESPOSTAS DOS PROFISSIONAIS

Entretanto, os comentrios dos profissionais relacionado a cada uma das
subcaractersticas foram compilados e resultaram nas seguintes informaes:
Quanto funcionalidade do modelo ProcSoftVD: o modelo prope-se
a realizar o que apropriado, pois oferece um guia de melhoria do
processo de software para MPEs com templates bem elaborados e
sugestivos que conduzem o usurio. Entretanto, a estrutura organizacional
da empresa (considerando o conhecimento dos colaboradores e infra-
estrutura da organizao) um fator determinante para o sucesso da
aplicao do modelo.
Quanto usabilidade do modelo ProcSoftVD: o modelo apresenta as
atividades com um nvel de esclarecimento, explicaes e orientaes
muito bom e, portanto, fcil de entender. Entretanto, o uso do modelo se
torna mais fcil quando o usurio j tem conhecimentos relacionados aos
processos de desenvolvimento. A apresentao do modelo em um site
permite que o modelo seja consultado por qualquer usurio que navegue
pela internet em busca de possveis solues para os problemas em sua
empresa por falta de um processo bem definido.
Quanto manutenibilidade do modelo ProcSoftVD: como qualquer outro
modelo, o ProcSoftVD apresenta relacionamentos entre as atividades das
diversas reas de conhecimento. Sendo assim, durante o processo de
instanciao do modelo em uma MPE, preciso ter ateno ao serem
realizadas as adaptaes pertinentes, pois uma modificao em uma
atividade pode impactar vrias outras atividades do modelo.
Quanto portabilidade do modelo ProcSoftVD: existe a possibilidade de
instanciar todo o modelo para empresa ou instanciar apenas determinadas
reas de conhecimento para ser utilizada em uma MPE. Entretanto, sugere-
se que a instncia do modelo para a empresa seja realizada por algum

que tenha conhecimento sobre atividades existentes em modelos de
processo de software.
Quanto eficincia do modelo ProcSoftVD: considerando que a
eficincia refere-se rapidez de aplicao do modelo e tambm questo
de recursos necessrios para essa aplicao, preciso realizar a
implantao do modelo em outras MPEs para se ter uma amostra mais
significativa para se chegar a uma concluso quanto a essa caracterstica.
De qualquer modo, difcil quantificar os recursos a serem usados, pois
uma mesma pessoa na empresa (principalmente em MPEs) pode realizar
vrios papis. Alm disso, instanciar um modelo no uma tarefa rpida e
trivial. Em princpio, acredita-se que enquanto os usurios no estiverem
familiarizados com o processo esse tende a ser realizado de maneira lenta.

Neste captulo foram apresentados os resultados da aplicao do modelo em
uma MPE e as avaliaes do modelo, segundo seus pontos fortes e fracos e segundo
as caractersticas de qualidade, por 6 (seis) profissionais da rea de computao.
O prximo captulo discorrer sobre as concluses e trabalhos futuros.

Captulo 7. Concluses e Trabalhos Futuros P g i n a | 123
7. Concluses e Trabalhos Futuros

O presente trabalho de pesquisa prope um Modelo de Gesto do Processo de
Venda e Desenvolvimento de Software On-demand para MPEs (ProcSoftVD - Gesto)
que integra os modelos/normas de capacidade de processo CMMI-DEV e ISO/IEC
15504-5 com o framework Unified Process, no contexto de gesto de processos de
negcio.
A avaliao do modelo foi realizada utilizando uma amostra de seis
profissionais da rea e duas MPEs, amostra essa considerada pequena dada a
complexidade do assunto analisado. Isso evidencia uma restrio metodolgica do
trabalho, j que no foi possvel considerar uma amostra representativa. Assim, as
concluses aqui expostas referem-se a uma viso parcial. Entretanto, essa viso
permitiu identificar algumas evidncias sobre pontos vulnerveis do modelo que sero
expostos (juntamente aos pontos fortes do modelo) na prxima seo, e que devero
ser explorados com maior rigor em trabalhos futuros, descritos na seo 7.3.
7.2. Concluses
Por meio da anlise dos dados obtidos durante as avaliaes do modelo, pode-
se concluir que para as MPEs analisadas foi mais interessante utilizar como modelo de
referncia para criar o seu processo padro o ProcSoftVD, ao invs de criar o seu
processo padro a partir de modelos de capacidade de processo, tais como o CMMI e
a ISO/IEC 15504-5, devido ao nvel de detalhamento das atividades por meio das
tarefas e templates sugeridos.
O modelo ProcSoftVD aborda vrios aspectos relevantes do processo de
desenvolvimento de software para as MPEs. vivel, pois alm de descrever cada
fase do modelo proposto com um vocabulrio de fcil entendimento, ainda

indica/sugere formas para sua aplicao na empresa. Alm disso, os artefatos criados
pelas atividades possuem referncias, fundamentao terica e exemplos sobre cada
assunto que pode no ser trivial ao seu pblico-alvo.
Mostrou-se til para conscientizar uma MPE sobre a necessidade e vantagens
de se ter um processo padro, uma vez que atualmente vrias empresas esto
perdendo licitaes por no atenderem aos modelos de capacidade de processo,
como o CMMI. Uma certificao desse tipo bastante cara e talvez uma MPE ainda
no tenha recursos o suficiente para tal. Nesse contexto, o ProcSoftVD - Gesto pode
ser acessado por qualquer MPE brasileira, pois seu acesso livre e gratuito, o que
minimiza os investimentos com consultoria externa.
Uma das caractersticas relevantes do modelo ProcSoftVD a possibilidade de
selecionar as reas de conhecimento mais prioritrias a serem implantadas na
empresa aos poucos, de acordo com os ciclos de melhoria definidos na aplicao do
Mtodo de Melhoria de Processo de Venda e Desenvolvimento de Software on-
demand (ProcSoftVD Melhoria) elaborado neste trabalho de pesquisa. Essa
caracterstica foi evidenciada durante a instanciao do modelo ProcSoftVD nas duas
MPEs participantes do projeto de pesquisa.
Uma caracterstica indita identificada foi a abordagem de atividades da rea
de conhecimento Comercializao (alm das sugeridas pela ISO/IEC 15504-5) e as
fases de Prospeco e Negociao no processo de desenvolvimento de software
on-demand, pois envolvem atividades de busca por potenciais clientes, atividades de
entendimento das necessidades do cliente para que haja um acordo entre as partes
envolvidas - o cliente e a empresa - em relao aos requisitos a serem atendidos,
atividades relacionadas viabilidade financeira do projeto e relacionadas ao
pagamento dos produtos/servios vendidos pela empresa.
Em relao rea de conhecimento Gesto de Conhecimento, no foi
possvel no mbito deste trabalho encontrar evidncias a respeito de sua efetividade,
pois nos ciclos de melhoria definidos pelas MPEs participantes do projeto essa rea
no foi considerada nos primeiros ciclos de melhoria. Acompanhar o ciclo completo de
melhoria do processo na empresa requer mais tempo de implantao e anlise.
7.3. Trabalhos Futuros

Alguns trabalhos futuros propostos, a partir da anlise dos resultados e
concluses expostos so:
Aplicao do modelo em outras MPEs para se ter uma amostra mais
significativa;
Definio de um ambiente (PSEE) que apie a definio do modelo de
processo de uma MPE, a partir do Modelo ProcSoftVD;
Expanso do modelo para cobertura de outras reas de conhecimento;
Definio de perfis de capacidade de processo voltados a possveis
situaes enfrentadas por MPEs;
Anlise da incluso de prticas geis no Modelo ProcSoftVD;
Mapeamento das atividades do Modelo ProcSoftVD com os resultados
esperados do MPS.BR;
Investigao de como utilizar o Modelo ProcSoftVD como material de
treinamento para melhoria de processos em MPEs;
Adaptao do modelo para o caso de incubadoras.

Este captulo apresentou as concluses sintetizadas a partir dos resultados
desse trabalho de pesquisa, alm dos trabalhos que podem ser desenvolvidos na linha
de evoluo do Modelo ProcSoftVD Gesto.

Referncias P g i n a | 126
Referncias
AALST, W. M. P. van der; HOFSTEDE, A. H. M. ter; WESKE, M. (2003). Business
Process Management: A Survey. BPM Center Report BPM-03-02, BPMcenter.org,
2003. Disponvel em: <http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2003/BPM-
03-02.pdf>. Acesso em: 20 fev 2007.
AALST, W. M. P. van der (2004). Business Process Management Demystified: A

Tutorial on Models, Systems and Standards for Workflow Management. In: Desel,
J.; Reisig, W.; Rozenberg, G. (Eds): ACPN 2003, LNCS 3098, pp. 1-65, Springer-
Verlag Berlin Heidelberg, 2004.
ABRAN, A.; MOORE, J. W.; BOURQUE, P.; DUPUIS, R.; TRIPP, L. L. (2004). Guide to
the Software Engineering Body of Knowledge - SWEBOK, 2004 version, The
Institute of Electrical and Electronics Engineers, Inc. - IEEE, 210 pages.
AGUILAR-SVEN, R. S. & OLHAGER, J. (2002). Integration of product, process

and functional orientations: Principals and a case study. In: International
Conference on Advance Production Management Systems. The Netherland.
AIR FORCE (1980). IDEF0 CAM. Arlington, Texas: AIR FORCE, 1980.
AMBLER, S. W. (2005). A Managers Introduction to The Rational Unified Process

(RUP). Disponvel em:
<http://www.ambysoft.com/downloads/managersIntroToRUP.pdf>. Acessado em: 26
out 2006.
ARBAQUI, S.; DERNIAME, J. C.; OQUENDO, F.; VERJUS, H. (2002). A Comparative

Review of Process-Centered Software Engineering Environments. In: Annals of
Software Engineering 14, 311-340, Kluwer Academic Publishers.
BASILI, V. R.; WEISS, D. M. (1984). A Methodology for Collecting Valid Software

Engineering Data. In: IEEE Transactions on Software Engineering, SE-10(6), 728-
738.
BOEHM, B.; EGYED, A.; PORT, D.; SHAH, A.; KWAN, J.; MADACHY, R. (1998). A
stakeholder winwin approach to software engineering education. Annals of
Software Engineering 6 (1998) 295321.
BOGEN, J.; GRONAU, N.;SCHMID, S. (2005). Improvement of software

engineering by modeling of knowledge intensive business processes, Technical
Report, WI 12/2005. Disponvel em: <http://wi.uni-
potsdam.de/hp.nsf/0/B0F253DF0812167CC12570180031E56F/$FILE/WI-2005-
12.pdf>. Acessado em: 10 nov 2006.
BORSSATTO, I. (2008). A implementao do MPS.BR nvel F na Synos. Disponvel

em: <http://www.softex.br/mpsBr/_artigos/artigo.asp?id=1828>. Acesso em: 05 jun
2008.
BUSINESS PROCESS MANAGEMENT INITIATIVE (2008). BPMN Business

Process Modeling Notation. Disponvel em: <http://www.bpmi.org>. Acesso em: 05
mai 2008.
BRYMAN, A. (1989). Research Methods and Organization Studies. Routledge.
CASSIOLATO, J. E.; LASTRES, H. M. M. (2001). Arranjos e Sistemas Produtivos

Locais na Indstria Brasileira. Revista de Economia Contempornea. Rio de
Janeiro: UFRJ. Disponvel em:
<http://www.desenvolvimento.gov.br/arquivo/sti/publicacoes/futAmaDilOportunidades/r
ev20010424_04.pdf> . Acesso em: 30 set 2005.
CERVO, A. L. & BERVIAN, P. A. (2002). Metodologia Cientfica. 5 ed. So Paulo:

Pearson Prentice Hall.
CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. (2003). CMMI: Guidelines for Process
Integration and Product Improvement, Addison-Wesley Pub Co, 2003.
COSTA, J.M.H. (2006). Proposta de uma metodologia de gesto de mudanas:

aplicao em uma empresa desenvolvedora de software. 208f. Dissertao
(Mestrado) Escola de Engenharia de So Carlos, Universidade de So Paulo, So
Carlos, 2006.
CURTIS, B. (1998). Which Comes First, the Organization or its Processes. IEEE
Software, pgs 10-13, November/December 1998.
DANE, F. C. (1990). Research Methods. Belmont, California, Brooks/Cole.
DAVENPORT, T. H. (1993). Need radical innovation and continuous

improvement? Integrate process reengineering and TQM. Planning Review, 21 (3),
p. 6-12.
DEMING, E. (1986). Out of the Crisis. Cambridge. MIT Center for Advanced
Engineering Study, 1986.
DeSOUZA, K. C. (2003). Barries to Effective Use of Knowledge Management

Systems in Software Engineering. Communications of the ACM, January, 2003, v.
46, n.1, p. 99-101.
ECLIPSE FOUNDATION (2008). Eclipse Process Framework. Disponvel em: <

http://www.eclipse.org/epf/>. Acesso em: 15 mai 2008.
ECLIPSE PROCESS FRAMEWORK COMMUNITY (2008). OpenUP. Disponvel em: <

http://epf.eclipse.org/wikis/openup/>. Acesso em: 15 mai 2008.
EL EMAM, K. (2004). Software Engineering Process. In: Chapter 9 of Guide to the

SoftwareEngineering Body of Knowledge (SWEBOK), 2004 version, (Abran et al.
2004), pgs 9-1 to 9-14. Disponvel em: <http://www.swebok.org/>. Acesso em: 15 mai
2008.
FALBO, R. A.; ARANTES, D. O.; NATALI, A. C. C. (2004). Integrating Knowledge

Management and Groupware in a Software Development Environment. In: D.
Karagiannis and U. Reimer (eds.): PAKM 2004, LNAAI 3336, pp. 94-105.
FIGUEIREDO, S.; SANTOS, G.; MONTONI, M.; ROCHA, A. R.; BARRETO, Andra.;
BARRETO, Ahilton; FERREIRA, A. (2006). Taba Workkstation: Supporting
Technical Solution Through Knowledge Management of Design Rationale. In:
REIMER, U. & KARAGIANNIS, D. (Eds.): PAKM 2006, LNAI 4333, Springer-Verlag
Berlin Heidelberg, p. 61-72.
GIL, A. C. (1999). Mtodos e Tcnicas da Pesquisa Social. 5 ed. So Paulo: Atlas.

HUNG, R. Y. (2006). Business process management as competitive advantage: a

review and empirical study. Total quality management. 17(1), 2140, jan, 2006.
IBM. (2006). Rational Method Composer. Disponvel em: <http://www-

128.ibm.com/developerworks/downloads/r/rup/support.html?S_TACT=105AGX28&S_
CMP=DLMAIN>. Acesso em: 02 fev 2006.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. (2000). ISO

9001:2000. Quality management systems. Requirements.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. (2001). ISO/IEC

12207 AMD1 e AMD2: Information technology Software life cycle processes.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. (2003). ISO/IEC

15504: Information Technology Process Assessment.
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. (1999). The Unified Software

development Process. Addison Wesley.
JESTON, J.; NELIS, J. (2008). Business Process Management Practical

Guidelines to Successful Implementations. 2th edition. Butterworth-Heinemann.
KILMANN, R. (1995). A holistic program and critical success factors of corporate

transformation. European Management Journal, 13 (2), p. 175-186.
KRUCHTEN, P. (2004). The Rational Unified Process: An Introduction. Addison-

Wesley.
LIMA, A.; FRANA, B.; SCHLEBBE, H.; REIS, R. Q.; REIS, C. L. (2006). WebAPSEE:
Um Ambiente Livre e Flexvel para Gerncia de Processos de Software. VII
Workshop de Software Livre. Porto Alegre, abr.
MCFEELEY, B. (1996). IDEALSM: A Users Guide for Software Process

Improvement. Handbook CMU/SEI-96-HB-001. Disponvel em:
<http://www.sei.cmu.edu/pub/documents/96.reports/pdf/hb001.96.pdf>. Acesso em: 15
mai 2008.
MCGOWAN, D. A.; MARCA, C. L. (1987). SADT: Structured Analysis and Design

Technique. McGraw-Hill, New York.
McKAY, A. & RADNOR, Z. (1998). A characterization of a business process.

International Journal of Operational and Production Management, 18 (9/10), p. 924-
936.
MCT (2005). Qualidade e Produtividade no Setor Brasileiro. Pesquisa 2005.

Disponvel em: <http://www.mct.gov.br/index.php/content/view/3253.html>. Acesso em:
15 mai 2008.
MICROSOFT. (2006). Visual Studio Team System. Disponvel em:

<https://ms.helifan.net/brasil/msdn/teamsystem/default.mspx>. Acesso em: 02 fev
2006.
MONTEIRO, R. W.; MARTINS, C.; CABRAL, R.; ROCHA, A. R. (2008). A Empresa de

Processamento de Dados do Estado do Par Rumo ao Nvel F do MR-MPS.
Disponvel em: <http://www.softex.br/mpsBr/_artigos/artigo.asp?id=1828>. Acesso em:

05 jun 2008.
MONTONI, M.; MIRANDA, R.; ROCHA, A. R.; TRAVASSOS, G. H. (2004a).

Knowledge Acquisition and Communities of Practice: An Approach to Convert
Individual Knowledge into Multi-organizational knowledge. In: G. Melnik and H. Holz
(eds.): LSO 2004, LNCS 3096, pp. 110-121.
MONTONI, M.; SANTOS, G.; VILLELA, K.; MIRANDA, R.; ROCHA, A. R.;
TRAVASSOS, G. H.; FIGUEIREDO, S.; MAFRA, S. (2004b). Knowledge
Management in an Enterprise-Oriented Software Development Environment. In:
D. Karagiannis and U. Reimer (eds.): PAKM 2004, LNAI 3336, pp. 117-128.
MONTONI, M.; SANTOS, G.; VILLELA, K.; ROCHA, A. R.; TRAVASSOS, G.

H.;FIGUEIREDO, S.; MAFRA, S.; ALBUQUERQUE, A.; MIAN, P. (2005). Enterprise-
Oriented Software Development Environments to Support Software Products and
Process Quality Improvement. In: BOMARIUS, F. & SIRVIO, K. (Eds.): PROFES
2005, LNCS 3547, Springer-Verlag Berlin Heidelberg, p. 370-384.
MONTONI, M.; SANTOS, G.; ROCHA, A. R. WEBER, K. C.; ARAJO, E. E. R. (2007).

MPS Model and TABA Workstation: Implementing Software Process
Improvement Initiatives in Small Settings. In: Fifth International Workshop on
Software Quality (WoSQ07), IEEE Computer Society.
OLIVEIRA, A. C. G.; GUIMARES, F. A.; FONSECA, I. A. (2008). Utilizando

Metodologias geis para Atingir MPS.BR Nvel F na PowerLogic. Disponvel em:
<http://www.softex.br/mpsBr/_artigos/artigo.asp?id=1828>. Acesso em: 05 jun 2008.
PDUA, E. M. M. (1996). Metodologia da Pesquisa: Abordagem Terico-Prtica.

Campinas-SP: Papirus.
PAULK, M. C.; WEBER, C. V.; CURTIS, B.; CHRISSIS, M. B. (1995). The Capability
Maturity Model: Guidelines for Improving the Software Process. SEI Series in
Software Enginnering, Addison-Wesley.
PINO, F. J.; GARCIA, F.; PIATTINI, M. (2008). Software Process Improvement in

Small and Medium Software Enterprises: a Systematic Review. In: Software
Quality Journal, 16:237-261.
PORTO, J.B.; LPEZ, P. A. P.; ALBERTUNI, I.; RICHTER, L. A.; CORRA NETO, J.
A. (2008). A Experincia de Avaliao MPS.BR Nvel F na Qualit. Disponvel em:
PRESSMAN, R. S. (2006). Engenharia de Software. 6 ed. So Paulo: McGraw-Hill.
PROJECT MANAGEMENT INSTITUTE (2003). Organizational Project Management

Maturity Model Handbook (OPM3), December 2003.
PROJECT MANAGEMENT INSTITUTE (2004). A Guide to the Project Management

Body of Knowledge, PMBOK Guide, Third Edition, PMI.
ROCHA, A. R.; MONTONI, M.; SANTOS, G.; MAFRA, S.; FIGUEIREDO, S.;
ALBUQUERQUE, A.; MIAN, P. (2005). Reference Model for Software Process
Improvement: A Brazilian Experience. In: I. Richardson et al. (Eds.): EuroSPI 2005,
Lecture Notes in Computer Science (LNCS) 3792, pp. 130-141.
ROCHA, A.R.; MONTONI, M.; SANTOS, G.; OLIVEIRA, K.; NATALI, A. C.; MIAN, P.;
CONTE, T.; MAFRA, S.; BARRETO, A.; ALBUQUERQUE, A.; FIGUEIREDO, S.;
SOARES, A.; BIANCHI, F.; CABRAL, R.; NETO, A. D. (2006). Success Factors and
Difficulties in Software Process Deployment Experiences based on CMMI and
MR-MPS.BR, In: Proc. Of the 6th International Workshop on Learning Software
Organizations (LSO2006), Rio de Janeiro, Brazil, september, 2006, pp. 77-87.
ROZENFELD, H.; FORCELLINI, F. A.; AMARAL, D. C.; TOLEDO, J. C. de; SILVA, S.

L. da; ALLIPRANDINI, D. H.; SCALICE, R. K. (2006). Gesto de Desenvolvimento de
Produtos Uma referncia para a melhoria do processo. So Paulo: Saraiva.
RUS, I. & LINDVALL, M. (2002). Knowledge Management in Software Engineering.

IEEE Software, May/Jun, 26-38.
SALVIANO, C. F. (2006). Uma proposta orientada a perfis de capacidade de

processo para evoluo da melhoria de processo de software. Tese de Doutorado
sob orientao de Mrio Jino. Departamento de Engenharia Eltrica. Universidade
Estadual de Campinas, UNICAMP, Brasil.
SCHEER, A.W. (1998). Business Process Engineering: reference models for

industrial enterprises, Heidelberg, Springer-Verlag.
SCHEID, M.; PESSOA, M. V.; GOMES, R. F.; RAIMUNDO, E. S.; OLIVEIRA, M. A. A.

de; SANTOS, G.; FIGUEIREDO, S.; ROCHA, A. R. (2008). Implantao do MR-MPS
Nvel E no Centro de Computao da Aeronutica de So Jos dos Campos.
Disponvel em: <http://www.softex.br/mpsBr/_artigos/artigo.asp?id=1828>. Acesso em:
05 jun 2008.
SEGRINI, B. M.; BERTOLLO, G.; FALBO, R. A. (2006). Evoluindo a Definio de

Processos de Software em ODE. In: XIII Sesso de Ferramentas do SBES (Simpsio
Brasileiro de Engenharia de Software). Florianpolis/SC, Brasil, p. 109-114.
SMITH, H.; FINGAR, P. (2003). Business Process Management: The third wave.
Meghan-Kiffer Press, 2003.
SOFTEX (2007). MPS.BR- Melhoria de Processo do Software Brasileiro . Guia

Geral. Disponvel em:
<http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.2.pdf>. Acesso em: 15
mai 2008.
SOFTWARE ENGINEERING INSTITUTE (2002). Capability Maturity Model

Integration CMMI, version 1.1.
SOFTWARE ENGINEERING INSTITUTE (2006). CMMI for Development, version

1.2 - CMMI-DEV. Disponvel em:
<http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf>. Acesso em: 27
out 2008.
SOMMERVILLE, I. (2007). Engenharia de Software. 8 ed. So Paulo: Pearson

Addison Wesley.
SPNOLA, R. O.; VILA, A. L. (2008). Introduo Engenharia de Requisitos. In:

Engenharia de Software Magazine, Edio 01, pg 46-54, DevMedia, Disponvel em: <
http://www.devmedia.com.br/articles/viewcomp.asp?comp=8034&hl>. Acesso em: 27
out 2008.
SWEBOK (2004). SWEBOK Software Engineering Body of Knowledge.

Disponvel em: <http://www.swebok.org/>. Acesso em: 08 out 2005.
THIOLLENT, M. (1995). Metodologia da Pesquisa-Ao. So Paulo: Cortez.
VARGAS, D.; NIGRI, M.; KRIEGER, M.; BARRETO, A.; MONTONI, M.; CABRAL, R.;
ROCHA, A. R. (2008). Melhoria de Processos na Marlin. Disponvel em:
WEBER, K. C.; ARAJO, E. R.; ROCHA, A. R.; MACHADO, C. F.; SCALET, D.;
SALVIANO, C. F. (2005a). Brazilian Software Process Reference Model and
Assessment Method, In: P. Yolum et al. (Eds), Proceedings of ISCIS 2005 (20th Int.
Symp. On Computer and Info. Sciences), LNCS 3733, pp. 402-411. Copyright
Springer-Verlag, Berlin Heindelberg.
WEBER, S.; HAUCK, J. C. R.; VON WANGENHEIM, C. (2005b). Estabelecendo

Processos de Software em Micro e Pequenas Empresas. SBQS Simpsio
Brasileiro de Qualidade de Software, Porto Alegre, Brasil.
WEBER, K. C.; ARAUJO, E. (2006). Avaliao do Modelo MPS em Empresas em

2005 e 2006. Disponvel em:
<http://golden.softex.br/portal/softexweb/uploadDocuments/_mpsbr/PBQP%202006%2
0Artigo%20Projeto%204.pdf>. Acesso em: 15 mai 2008.
WEBER, K. C.; NASCIMENTO, C. J. do; MARINHO, D. S. (2006). Programa

Brasileiro da Qualidade e Produtividade em Software: Treze anos
acompanhando e disseminando a cultura da qualidade. Disponvel em:
<http://www.mct.gov.br/upd_blob/0006/6446.pdf>. Acesso em: 15 mai 2008.
WELLS, D. (2006). Extreme Programming: A gentle introduction. Disponvel em:

<http://www.extremeprogramming.org>. Acesso em: 15 mai 2008.
ZAIRI, M. & SINCLAIR, D. (1995). BPR and process management: a survey of

current practice and future trends in integrated management. Business Process Re-
engineering and Management Journal, 1 (1), p. 8-29.
ZAIRI, M. (1997). Business process management: a boundaryless approach to

modern competitiveness. Business Process Management Journal, 3 (1), p. 64-80.
Apndice 1 Questionrio P g i n a | 132
Apndice 1 Questionrio para Levantamento de reas

de Conhecimento relevantes para algumas MPEs
QUESTIONRIO
1. Identificao
1.1 Seu nome (opcional): ..............................................................................................................
1.2 E-mail pessoal para contato: ....................................................................................................
1.3 Qual a sua formao acadmica?

R. ....................................................................................................................................................
1.4 Qual o nome da faculdade onde se formou? E, em que ano?

R. ....................................................................................................................................................
1.5 Funo que voc exerce na empresa:

a. ( ) Gerente/Supervisor
b. ( ) Gerente de Projetos
c. ( ) Analista de Sistemas
d. ( ) Programador
e. ( ) Outra. Qual ? ...............................................................................................................
1.6 Voc tem autoridade para fazer alguma modificao na forma de conduzir as atividades de
desenvolvimento de software dentro da empresa?
( ) Sim.
( ) No.
2. Caracterizao da Empresa de Desenvolvimento de Software ou CPD
2.1 Nome da Empresa/local onde trabalha (opcional): ..................................................................
2.2 Quantidade de funcionrios:

( ) Na empresa
( ) No CPD da empresa (se for o caso)
2.3 Quanto s atividades de desenvolvimento de software na empresa ou no CPD da empresa

(se for o caso), tem-se:
a. ( ) Desenvolvimento de software de prateleira (pacote de software). Ex: software pronto
vendido em supermercados.
b. ( ) Desenvolvimento de software sob encomenda (solicitado por um determinado cliente).
c. ( ) Desenvolvimento de software embarcado (que controla outros equipamentos).
d. ( ) Desenvolvimento de software para internet.

e. ( ) Desenvolvimento de software para uso prprio.
f. ( ) Desenvolvimento e distribuio de um nico software.
g. ( ) Outra. Qual? ............................................................................................................
2.4 Qual(is) o(s) tipo(s) de software(s) desenvolvido(s)?

( ) Administrao Comercial
( ) Administrao Escolar
( ) Administrao Pblica
( ) Administrao de Recursos Humanos
( ) Agropecurio
( ) Automao Bancria
( ) Automao de Escritrios
( ) Comrcio Eletrnico
( ) Contabilidade
( ) Educacional
( ) Entretenimento
( ) Ferramentas de desenvolvimento de sistemas
( ) Financeiro
( ) Processador de imagens
( ) Outro(s). Qual(is)? ......................................................................................................
2.5 As pessoas que trabalham na equipe de desenvolvimento de software so resistentes s

mudanas?
( ) Sim.
( ) No.
Comentrios:
............................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
3. Comercializao do Produto Software
Para quem no assinalou a opo (e.) da questo 2.3, por gentileza, responda s questes de 3.1 a 3.4.
3.1 Quanto venda do produto, considerando o total de produtos j desenvolvidos em sua
empresa:
a. ( ) Quantos produtos foram vendidos junto ao cdigo-fonte, documentao do produto e
manual do usurio?
b. ( ) Quantos foram vendidos apenas com o cdigo-fonte?
c. ( ) Quantos foram vendidos apenas com o executvel?
d. ( ) Quantos produtos foram vendidos por licenas?
e. ( ) Outra situao. Qual? ..........................................................................................................
3.2 O desenvolvimento do sistema feito por mdulos (partes)?

( ) Sim.
Nesse caso, a cobrana ao cliente feita a cada trmino do mdulo entregue?
( ) Sim.
( ) No. Como realizada? ..........................................................................................
( ) No. Como realizada a cobrana? ......................................................................................
3.3 utilizada alguma ferramenta para auxiliar no controle de cobranas?

( ) Sim. Qual(is)? ..........................................................................................................................
( ) No.
3.4 Voc acha que seria til definir algumas atividades e formulrios para auxiliar a fase de
comercializao do produto de software desenvolvido?
( ) Sim.
( ) No.
Independente da resposta, por qu?
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
4. Definio e Construo do Software
4.1 Na empresa onde trabalha, h alguma descrio (seja em documentos ou site ou em uma
ferramenta/aplicativo utilizado) referente s atividades que devem ser realizadas para a
definio do produto a ser desenvolvido?
( ) Sim.
( ) No.
4.2 Voc acha importante entender o negcio do cliente antes de construir um software para
que esse atenda aos objetivos do negcio?
( ) Sim.
( ) No.
4.3 Na empresa onde trabalha, elaborada alguma modelagem do negcio do cliente para
facilitar o entendimento a todos os envolvidos no projeto de desenvolvimento do software?
( ) Sim.
( ) No.
4.4 Voc acha importante que haja algum tipo de modelagem do negcio do cliente para
facilitar o entendimento a todos os envolvidos no projeto de desenvolvimento do software?
( ) Sim.
( ) No.
Independente da resposta, por qu?
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
4.5 Aps realizar o entendimento das necessidades do cliente, vocs realizam alguma
atividade anterior codificao do software, tal como a elaborao de um documento de
requisitos e/ou de um modelo de dados?
( ) Sim. Quais so as atividades?
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
( ) No.
4.6 Quais as ferramentas/aplicativos que vocs usam durante o processo de desenvolvimento

de software, considerando desde a atividade de obteno dos requisitos do cliente at a
entrega e/ou implantao do software no cliente e at mesmo o suporte ao cliente?
R:
.........................................................................................................................................................
.........................................................................................................................................................
.........................................................................................................................................................
5. Relevncia dos Processos relacionados ao
Ciclo de Vida do Software
5.1 Junto ao questionrio foi enviada uma planilha denominada RELEVANCIA_PROCESSOS

onde devem ser selecionadas uma das alternativas disponibilizadas para cada questo.
Nessa planilha esto definidos alguns processos que podem ser utilizados durante o
ciclo de vida do software. Na coluna A encontra-se o nome do processo e na coluna F
encontra-se uma breve descrio do respectivo processo (para acessar, basta clicar em cima
da clula desejada e a descrio aparecer na barra de frmulas, como apresentado na Figura
A1.1).
Barra de frmulas
FIGURA A1.1 PLANILHA DE RELEVNCIA (DESCRIO DO PROCESSO)
Independente se a sua empresa tem ou no atividades formalizadas em relao ao

desenvolvimento do software, defina:
o grau de importncia de cada um dos processos na sua empresa;
o risco em continuar executando o processo em questo da forma como
executado atualmente.
se o processo executado ou no na empresa, atualmente.
quais processos voc escolheria para serem melhorados em sua empresa.
Uma explicao para cada um dos itens anteriores fornecida como comentrio. Para
acessar, basta posicionar o mouse em cima da coluna desejada, como mostrado na Figura
A1.2.
FIGURA A1.2 PLANILHA DE RELEVNCIA (COMENTRIO REFERENTE CADA QUESTO)
Para selecionar uma resposta para cada questo, clique na clula correspondente
linha do processo analisado. Aparecer o cone , como mostrado na Figura A1.3; Clique
nesse cone para selecionar a opo desejada.
FIGURA A1.3 PLANILHA DE RELEVNCIA (SELEO DE ALTERNATIVAS)
5.2 Voc acredita que um modelo de processo de desenvolvimento de software auxiliaria as

pessoas envolvidas no desenvolvimento do software, servindo como um guia comum para
todos?
( ) Sim.
( ) No. Por qu?
.........................................................................................................................................................
.........................................................................................................................................................
5.3 Voc tem interesse nos resultados dessa pesquisa, depois de finalizada?
( ) Sim.
( ) No.
5.4 Voc tem interesse em conhecer o modelo de processo de desenvolvimento de software

que ser criado nesse trabalho de doutorado?
( ) Sim.
( ) No.
Apndice 2 Resultado P g i n a | 137
Apndice 2 Resultado da Anlise do Questionrio

definido no Apndice 1
A partir dos questionrios respondidos pelas 5 (cinco) MPEs que desenvolvem
software e 9 (nove) CPDs (Centro de Processamento de Dados) de empresas diversas
os quais desenvolvem software para uso interno, foram confirmadas as reas de
conhecimento definidas no Modelo ProcSoftVD e foi indicada a importncia de outras
reas de conhecimento que sero consideradas em um trabalho futuro. A Figura A2.1
apresenta a tabulao das reas de conhecimento investigadas quanto ao grau de
importncia de cada uma delas para a empresa e quanto ao grau de risco para a
empresa caso no sejam realizadas atividades das respectivas reas de
conhecimento.
Legenda
Im p o rt n c ia A lta
VAL, VER, ADR = Anlise de Deciso e Resoluo

TOrg Proj, STec Doc SCli ADR GProj Impl (50%)
Teste Acq = Aquisio
Impl (50%)
DPO = Definio do Processo Organizacional
DPO AMP Gris Inst Acq GReq
Proj, STec = Design
Doc = Documentao
GQua DReq IProd DReq = Elicitao e Anlise de Requisitos
ForSoft = Fornecimento
Gconh ForSoft
GQua = Garantia de Qualidade
Im p o rt n c ia M d ia
Gconf = Gesto de Configurao

Gconh = Gesto de Conhecimento
Med GProj = Gesto de Projetos
GReq = Gesto de Requisitos
Gris = Gesto de Riscos
Gconf Impl = Implementao
Im p o rt n c ia B a ix a
Inst = Instalao
IProd = Integrao do Produto
Med = Medio
AMP = Melhoria do Processo Organizacional
SCli = Suporte ao cliente
TOrg = Treinamento
Risco Baixo Risco Mdio Risco Alto VAL, VER, Teste = Verificao, Validao e Teste
FIGURA A2.1 TABULAO DA IMPORTNCIA VERSUS RISCO DAS REAS DE CONHECIMENTO PARA A EMPRESA
Percebe-se que para as empresas investigadas as reas de conhecimento com
mais alta prioridade so as que tm alta importncia e alto risco caso continue sendo
realizada pela empresa da forma que est atualmente. So elas: Gesto de Projetos,
Aquisio, Gesto de Requisitos, Elicitao e Anlise de Requisitos, Integrao do
Produto, Anlise de Deciso e Resoluo. Como segunda prioridade, foram
estabelecidas as reas de conhecimento: Garantia da Qualidade, Instalao e Suporte
ao Cliente. Projeto (design), Verificao, Validao e Testes foram considerados de

Apndice 2 Resultado P g i n a | 138
alta importncia, porm de risco mediano caso no sejam definidas atividades
formalizadas para a empresa.

Apndice 3 Modelo ProcSoftVD (Atividades) P g i n a | 139
Apndice 3 Modelo ProcSoftVD (Atividades)
Este apndice apresenta as atividades do modelo ProcSoftVD, agrupadas por
fases (Quadros A3.1 a A3.6) e agrupadas por reas de conhecimento (Quadros A3.7 a
A3.19). Alm disso, apresenta a viso grfica do modelo (Figuras A3.20 a A3.26) e o
detalhamento de cada uma das atividades (Quadros A3.27 a A3.77).
QUADRO A3.1 ENTRADAS, ATIVIDADES E SADAS DA FASE PROSPECO

PROSPECO: Esta fase realizada, principalmente, nos casos em que a empresa j tem algum produto/servio
desenvolvido/oferecido ou em fase de desenvolvimento e deseja buscar potenciais clientes para esses tipos de
produtos/servios, a fim de conseguir a solicitao de algumas propostas. Caso no haja a necessidade de prospectar o
cliente, realizar as atividades a partir da atividade "P04. Criar infra-estrutura do projeto".
ENTRADAS ATIVIDADES SADAS
Plano de Negcios
(j deve existir na
empresa)
Plano de Marketing
(j deve existir na
empresa)
Lista de Contatos
Plano de Ao P01 - Buscar contatos
(j deve existir na
empresa)
Base de contatos
(j deve existir na
empresa)
Lista de Contatos
Lista de Contatos
Plano de Marketing P02 - Prospectar cliente

Roteiro de
Prospeco
Modelo de
Negcio
Material de
divulgao
Lista de Contatos
P03 - Visitar cliente Lista de Contatos
Lista de
Requisitos do
Cliente
Controle de
Projetos
Solicitao de Proposta
P04 - Criar infra-estrutura do projeto Proposta do
Cliente Impressa
Plano de Ao P05 - Controlar custos despendidos na fase de Plano de Ao

prospeco
Milestone: Solicitao de uma proposta pelo cliente

QUADRO A3.2 ENTRADAS, ATIVIDADES E SADAS DA FASE CONCEPO
CONCEPO: Esta fase tem como objetivo entender o negcio do cliente, verificar a viabilidade tcnica e financeira do projeto
para a empresa desenvolvedora, bem como os riscos, ter a viso geral do sistema e sintetizar uma arquitetura candidata para
o software. Assim, tm-se subsdios para negociar o contrato com o cliente.
Controle de Projetos
Modelo de Negcio
Modelo de Negcio
Lista de Requisitos do
Cliente
Lista de Requisitos do
CP01 - Entender o negcio e as Infra-Estrutura do
Cliente
necessidades do cliente Cliente
Relatrio de Anlise
Relatrio de Anlise
dos Requisitos
dos Requisitos
Documento de
Plano de Projeto
Requisitos CP02 - Definir escopo do projeto
Modelo de Negcio
Documento de Documento de
Requisitos Requisitos
Lista de Requisitos CP03 - Determinar requisitos do produto
Projeto IHM
Padro do Produto (j
existente na empresa)
Documento de
Requisitos
Checklist de
Requisitos Relatrio de Anlise
Modelo de Negcio CP04 - Verificar e Validar os requisitos dos Requisitos
Projeto IHM
Relatrio de Anlise
dos Requisitos
Arquitetura do
Software
Documento de Requisitos
CP05 - Estudar solues alternativas de
arquitetura do software
Documento de
Requisitos
Documento de
Requisitos Cronograma
Cronograma CP06 - Definir/Redefinir cronograma do
Plano de Projeto
projeto
Plano de Projeto
Documento de
Requisitos
Base de Dados Cronograma
Histrica da empresa CP07 - Determinar estimativas de esforo e
tempo
Plano de Projeto
Cronograma
Plano de Projeto
QUADRO A3.2 ENTRADAS, ATIVIDADES E SADAS DA FASE CONCEPO (CONT.)

Documento de
Requisitos
Plano de Projeto Plano de Projeto
Arquitetura do Relatrio de
Software CP08 - Verificar a viabilidade tcnica e Viabilidade do Projeto
financeira do projeto
Plano de Ao Fluxo de Caixa
Infra-Estrutura do
Cliente
Cronograma Plano de Projeto

Controle de Projetos Controle de Projetos
CP09 - Planejar os recursos do projeto
Plano de Projeto Pedido de Compra

Plano de Projeto
CP10 - Identificar conhecimentos e
habilidades necessrias
Plano de Projeto
Cronograma
Relatrio de
Viabilidade do Projeto Plano de Projeto
CP11 - Identificar riscos inerentes ao projeto
Fluxo de Caixa
Plano de Projeto
Controle de Projetos Relatrio de
Plano de Projeto CP12 - Acompanhar o andamento do projeto Acompanhamento do
Projeto
Plano de Ao CP13 - Controlar custos despendidos na fase Plano de Ao

de concepo
Milestone: Estudo de Viabilidade do Projeto
Plano de Garantia da
Qualidade (j
existente na empresa) Relatrio sobre
CP14 - Conduzir reviso do milestone:
Produto de Trabalho:
Estudo de Viabilidade do Projeto
Garantia da Qualidade
Relatrio de
Viabilidade do Projeto
QUADRO A3.3 ENTRADAS, ATIVIDADES E SADAS DA FASE NEGOCIAO
NEGOCIAO: Esta fase tem por objetivo fechar um contrato com o cliente. Para isso, ser elaborada, primeiramente, uma
proposta pautada no estudo de viabilidade do projeto e no planejamento inicial sob a qual ser feita a negociao.
Documento de Proposta Tcnica

Requisitos
Proposta Comercial
Relatrio de
Viabilidade do Projeto Relatrio de Viabilidade do
N01 - Elaborar a proposta Projeto
Relatrio de Anlise da
Proposta Cronograma
Cronograma Documento de Requisitos
Proposta Comercial Relatrio de Anlise da

Proposta Tcnica N02 - Analisar proposta Proposta
Proposta
Relatrio de Anlise do Contrato
N03 - Elaborar contrato
Contrato
Contrato
Relatrio de Anlise do
N04 - Analisar contrato Contrato
Cronograma
Plano de Projeto
Plano de Projeto
Cronograma
Controle de Projetos N05 - Definir time do projeto
Contrato assinado
Contrato
Proposta Tcnica
Documento de
formalizao do projeto
Pedido de Compra
Pedido de Compra
N06 - Formalizar incio do projeto
Plano de Projeto
Plano de Projeto
Relatrio de
Relatrio de N07 - Acompanhar o andamento do
Acompanhamento do
Acompanhamento do projeto
Projeto
Projeto
Plano de Ao N08 - Controlar custos despendidos na Plano de Ao

fase de negociao
Milestone: Contrato
QUADRO A3.3 ENTRADAS, ATIVIDADES E SADAS DA FASE NEGOCIAO (CONT.)

Qualidade
Produto de Trabalho: Relatrio sobre Garantia
Contrato N09 - Conduzir reviso do milestone: da Qualidade
Contrato
Relatrio sobre
QUADRO A3.4 ENTRADAS, ATIVIDADES E SADAS DA FASE ELABORAO
ELABORAO: Esta fase tem o objetivo de definir uma baseline da arquitetura do software para fornecer uma base estvel
para o esforo de implementao na fase de construo e, tambm, detalhar os requisitos, refinar o cronograma e planejar os
testes a serem realizados em cada ciclo de desenvolvimento estimado na fase de concepo.
Documento de Requisitos Documento de

Projeto IHM Requisitos
Cronograma E01 - Detalhar requisitos Projeto IHM
Modelo de Negcio Modelo de Negcio
Documento de Requisitos
Checklist de Requisitos
Modelo de Negcio Relatrio de Anlise
Projeto IHM E02 - Verificar e Validar os requisitos dos Requisitos
Relatrio de Anlise dos
Requisitos
Arquitetura do
Arquitetura do Software Software
Documento de Requisitos Documento de
E03- Definir soluo de projeto
Cronograma Requisitos
Modelo de Design
Cronograma Controle de Tarefas

E04 - Detalhar o cronograma
Plano de Projeto
Cronograma
Biblioteca de Casos de Teste Planilha de Teste
Padro E05 - Definir tcnicas e critrios para Plano de Projeto
Documento de Requisitos V&V Cronograma
Modelo de Design
Arquitetura do Software
QUADRO A3.4 ENTRADAS, ATIVIDADES E SADAS DA FASE ELABORAO (CONT.)

Plano de Projeto Relatrio de

Relatrio de Acompanhamento de
Acompanhamento de Projeto Projeto
E06 - Monitorar e controlar o projeto Controle de Projetos
Cronograma Cronograma
Relatrio de Viabilidade do
Cobrana
Projeto E07 - Monitorar e Controlar questes
Fluxo de caixa
financeiras Fluxo de Caixa
Milestone: Arquitetura do Software
Qualidade
Produto de trabalho:
Relatrio sobre
E08 - Conduzir reviso do milestone: Garantia de
Arquitetura do Software Qualidade
Relatrio sobre Garantia de
Qualidade
QUADRO A3.5 ENTRADAS, ATIVIDADES E SADAS DA FASE CONSTRUO
CONSTRUO: Essa fase tem por objetivo elaborar verses utilizveis (alpha, beta, e outras entregas testadas) e completar a
anlise, projeto, desenvolvimento e teste de todas as funcionalidades requeridas.
Arquitetura do
Software
Modelo de Design
Projeto IHM
Arquivo de Cdigo
Controle de Tarefas
CT01 - Codificar componentes Controle de Tarefas
Arquivo de Cdigo
Planilha de Teste
Plano de Projeto
Planilha de Teste
Planilha de Teste
CT02 - Realizar teste de unidade Arquivo de Cdigo
Arquivo de Cdigo
Arquivo de Cdigo
Planilha de Teste
Planilha de Teste CT03 - Analisar os resultados de teste
Arquivo de Cdigo
Planilha de Teste
Plano de Projeto CT04 - Integrar e testar integrao entre
Arquivo de Cdigo
Planilha de Teste componentes
QUADRO A3.5 ENTRADAS, ATIVIDADES E SADAS DA FASE CONSTRUO (CONT.)

Plano de Projeto
Relatrio de
Acompanhamento de Projeto
Projeto CT05 - Monitorar e controlar o projeto Controle de Projetos
Cronograma
Cronograma
Relatrio de
Cobrana
Viabilidade do Projeto CT06 - Monitorar e Controlar questes
Fluxo de caixa
financeiras Fluxo de caixa
Milestone: Capacidade Operacional
Qualidade
Arquivo de Cdigo
(Capacidade
Relatrio sobre
CT07 - Conduzir reviso do milestone: Garantia da Qualidade
Operacional do Capacidade Operacional
Produto)
Relatrio sobre
QUADRO A3.6 ENTRADAS, ATIVIDADES E SADAS DA FASE TRANSIO

TRANSIO: Essa fase tem por objetivo assegurar que o software esteja disponvel para os usurios finais. Essa fase pode
atravessar muitas iteraes, e inclui testes do produto em preparao para a entrega, e faz os ajustes baseado no feedback do
usurio. Esses feedbacks devem focar principalmente o ajuste do produto, a configurao, instalao e questes de
usabilidade.
Arquivo de Cdigo
Plano de Projeto
Documento de Planilha de Teste
T01 - Validar a verso do produto
Requisitos
Planilha de Teste
Arquivo de Cdigo Arquivo de Cdigo

Planilha de Teste T02 - Analisar e Ajustar a verso do produto Planilha de Teste
Plano de Projeto
Planilha de Teste Planilha de Teste
T03 - Realizar testes de regresso
Arquivo de Cdigo
QUADRO A3.6 ENTRADAS, ATIVIDADES E SADAS DA FASE TRANSIO (CONT.)

Verso do Produto
Arquivo de Cdigo
Documento de Aceite
Manual do Usurio T04 - Entregar/Instalar a verso do produto

Manual do Usurio
Arquivo para
Instalao
Plano de Projeto
Relatrio de
Projeto T05 - Monitorar e controlar o projeto Controle de Projetos
Cronograma
Cronograma
Relatrio de
Cobrana
Viabilidade do Projeto T06 - Monitorar e Controlar questes
Fluxo de caixa
Milestone: Entrega do Produto
Qualidade
Produto de Trabalho: Relatrio sobre
Entrega do Produto T07 - conduzir reviso do milestone: entrega Garantia da Qualidade
do produto
Relatrio sobre
A seguir, os quadros A3.7 a A3.19 apresentam as atividades do modelo
ProcSoftVD, com suas respectivas entradas e sadas, agrupadas pelas reas de
conhecimento que compem o modelo: Comercializao, Modelagem de Negcio,
Produo de Requisitos, Projeto, Codificao & Integrao de Produto, V&V,
Implantao, Aquisio, Medio, Garantia da Qualidade de Produto e Processo,
Gesto de Requisitos, Gesto de Mudanas e Configurao, Gesto de Projeto e
Gesto do Conhecimento.
QUADRO A3.7 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO COMERCIALIZAO
COMERCIALIZAO: essa rea de conhecimento foi criada para abordar (1) atividades relacionadas prospeco de
potenciais clientes para a empresa (o que no coberto pelo CMMI, nem pela ISO/IEC 15504-5); (2) atividades relacionadas
elaborao/submisso de propostas ao cliente e negociao e aprovao de contrato sem ambigidades que especifique as
expectativas, responsabilidades, entregas e compromissos de ambas as partes cliente e fornecedor; (3) atividades
relacionadas viabilidade financeira do projeto e relacionadas ao pagamento dos produtos/servios vendidos pela empresa. As
atividades do item (2) foram definidas com subsdio dos processos Prospeco do Fornecedor e Acordado Contratual da
ISO/IEC 15504-5.
Plano de Negcios
(j deve existir na
empresa)
Plano de Marketing
(j deve existir na
empresa)
Lista de Contatos
Plano de Ao P01 - Buscar contatos
(j deve existir na
empresa)
Base de contatos
(j deve existir na
empresa)
Lista de Contatos Lista de Contatos

Plano de Marketing P02 - Prospectar cliente Roteiro de Prospeco
Modelo de Negcio
Lista de Contatos Material de divulgao
P03 - Visitar cliente
Lista de Contatos
Documento de
Requisitos
Plano de Projeto
Arquitetura do
Plano de Projeto
Software
Fluxo de Caixa
Relatrio de
CP08 - Verificar a viabilidade tcnica e Viabilidade
Plano de Ao financeira do projeto
Fluxo de Caixa
Relatrio de
Infra-Estrutura do
Cliente
Documento de
Requisitos Proposta Tcnica
Relatrio de Proposta Comercial
Relatrio de
Relatrio de Anlise Viabilidade do Projeto
da Proposta N01 - Elaborar a proposta
Cronograma
Proposta Tcnica
Documento de
Proposta Comercial Requisitos
Cronograma
QUADRO A3.7 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO COMERCIALIZAO (CONT.)

Proposta Comercial
Proposta Comercial Proposta Tcnica
Proposta Tcnica N02 - Analisar proposta Relatrio de Anlise
da Proposta
Proposta
Relatrio de
Contrato
Relatrio de Anlise N03 - Elaborar contrato
do Contrato
Cronograma
Relatrio de Anlise
Contrato do Contrato
N04 - Analisar contrato
Contrato
Contrato Documento de
Proposta Tcnica formalizao do
Pedido de Compra projeto
N06 - Formalizar incio do projeto Pedido de Compra
Plano de Projeto Controle de Projetos
Contrato
Relatrio de
Controle de Projetos Viabilidade do Projeto
E07 - Monitorar e Controlar questes
Relatrio de financeiras Cobrana
Fluxo de Caixa
Verso do Produto
Arquivo de Cdigo Documento de Aceite
Manual do Usurio T04 - Entregar/Instalar a verso do produto Manual do Usurio
Arquivo para Instalao
QUADRO A3.8 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO MODELAGEM DE NEGCIO
MODELAGEM DE NEGCIO: o objetivo dessa rea de conhecimento documentar os processos de negcio usando casos
de uso de negcio, a fim de assegurar um entendimento comum entre todos os stakeholders (envolvidos) sobre as
necessidades existentes no processo de negcio da organizao cliente. Essa rea de conhecimento teve sua origem no
Unified Process.
Modelo de Negcio
Lista de Contatos
Modelo de Negcio
Modelo de Negcio
Documento de
CP01 - Entender o negcio e as Requisitos
Lista de Requisitos do necessidades do cliente Infra-Estrutura do
Cliente
Cliente
Documento de
Requisitos Documento de
Requisitos
Projeto IHM
E01 - Detalhar requisitos Projeto IHM
Cronograma
Modelo de Negcio
Modelo de Negcio
QUADRO A3.9 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO PRODUO DE REQUISITOS
PRODUO DE REQUISITOS: tem o objetivo de produzir e analisar os requisitos do cliente, do produto e dos componentes
de produto. Essa rea de conhecimento teve sua origem relacionada rea de processo Desenvolvimento de Requisitos do
CMMI-DEV e aos processos Elicitao de Requisitos, Anlise de Requisitos do Sistema e Anlise de Requisitos do
Software da ISO/IEC 15504-5.
Modelo de Negcio
Lista de Contatos
Modelo de Negcio
Modelo de Negcio
Documento de
CP01 - Entender o negcio e as Requisitos
Lista de Requisitos do necessidades do cliente Infra-Estrutura do
Cliente
Cliente
Documento de
Plano de Projeto
Modelo de Negcio
Lista de Requisitos CP03 - Determinar requisitos do produto
Projeto IHM
Padro do Produto (j
existente na empresa)
QUADRO A3.9 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO PRODUO DE REQUISITOS

(CONT.)
Checklist de Relatrio de Anlise
Requisitos CP04 - Verificar e Validar os requisitos dos Requisitos
Arquitetura do
Software
CP05 - Estudar solues alternativas de
Documento de
Requisitos arquitetura do software
Documento de
Requisitos
Cronograma
Relatrio de
Fluxo de Caixa
Plano de Projeto
Documento de
Requisitos
Projeto IHM
Cronograma
Modelo de Negcio
Modelo de Negcio
Checklist de Relatrio de Anlise
Requisitos E02 - Verificar e Validar os requisitos dos Requisitos
QUADRO A3.10 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO PROJETO, CODIFICAO &
INTEGRAO DE PRODUTO
PROJETO, CODIFICAO & INTEGRAO DE PRODUTO: Engloba os processos Projeto do Software, Integrao do
Software e Integrao do Sistema da 15504-5, o workflow Implementao do UP e as reas de processo Soluo Tcnica
e Integrao de Produto do CMMI-DEV. Segundo a 15504-5, o processo Projeto de Software tem o objetivo de fornecer um
design para o software que implementado e pode ser verificado em confronto aos requisitos; o processo Integrao de
Software tem o objetivo de combinar as unidades de software, produzindo itens de software integrados, consistentes com o
projeto de software, os quais demonstram que os requisitos funcionais e no-funcionais foram satisfeitos; e o processo
Integrao do Sistema tem como objetivo integrar os elementos do sistema (incluindo os itens de software, itens de hardware,
operaes manuais e outros sistemas, se necessrio) para produzir um sistema completo que satisfaa ao projeto do sistema e
s expectativas do cliente, expressadas em requisitos do sistema. Segundo o modelo CMMI-DEV, a rea de processo Soluo
Tcnica tem como objetivo projetar, desenvolver e implementar solues para os requisitos, solues essas que envolvem
produtos, componentes de produtos e processos de ciclo de vida relacionados ao produto; e a rea de processo Integrao do
Produto tem o objetivo de montar o produto, a partir dos componentes de produto, assegurar que o produto ao ser integrado
funcione adequadamente, e entregar o produto.
Documento de CP05 - Estudar solues alternativas de Documento de
Requisitos arquitetura do software Requisitos
Documento de
E03- Definir soluo de projeto Requisitos
Modelo de Design
Modelo de Design
Cronograma
Plano de Projeto
Cronograma
Biblioteca de Casos de Planilha de Teste
Teste Padro
Plano de Projeto
Documento de E05 - Definir tcnicas e critrios para V&V
Modelo de Design
Modelo de Design
Arquivo de Cdigo
Projeto IHM
CT01 - Codificar componentes Controle de Tarefas
Controle de Tarefas
Arquivo de Cdigo
Arquivo de Cdigo
Arquivo de Cdigo
Planilha de Teste T02 - Ajustar a verso do produto
Verso do Produto
Arquivo de Cdigo Documento de Aceite
Manual do Usurio T04 - Entregar/Instalar a verso do produto Manual do Usurio
Arquivo para Instalao
QUADRO A3.11 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO VERIFICAO & VALIDAO
V&V: Engloba as reas de processo (CMMI) e processos (15504-5) Validao e Verificao e os processos Teste de
Software e Teste de Sistema da 15504-5. O objetivo da rea de processo/processo Validao demonstrar que o produto
ou componente do produto atenda ao uso pretendido quando colocado no ambiente destinado. J o objetivo da rea de
processo/processo Verificao assegurar que produtos de trabalho (e servios, no caso do CMMI) selecionados alcancem
seus requisitos especificados. Testes desempenham um papel extremamente importante em V&V (Verificao e Validao).
Segundo o modelo 15504-5, o processo Teste pode ser realizado tanto no software quanto no sistema. O processo Teste de
Software tem como objetivo confirmar que o produto de software integrado atende aos requisitos definidos. E, o processo
Teste de Sistema tem o objetivo de assegurar que a implementao de cada requisito de sistema seja testada quanto sua
conformidade e que o sistema esteja pronto para entrega.
Documento de
Documento de
Requisitos
Requisitos
CP04 - Verificar e Validar os requisitos Requisitos
Modelo de Negcio
Modelo de Negcio
Documento de
Documento de
Requisitos
Requisitos
E02 - Verificar e Validar os requisitos Requisitos
Modelo de Negcio
Modelo de Negcio
Plano de Projeto
Cronograma
Biblioteca de Casos de Planilha de Teste
Teste Padro
Plano de Projeto
Documento de E05 - Definir tcnicas e critrios para V&V
Modelo de Design
Plano de Projeto
CT02 - Realizar teste de unidade
Arquivo de Cdigo
Arquivo de Cdigo
Planilha de Teste
Arquivo de Cdigo
Planilha de Teste
Arquivo de Cdigo
Arquivo de Cdigo
Plano de Teste
Planilha de Teste
Documento de T01 - Validar a verso do produto
Requisitos
QUADRO A3.11 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO VERIFICAO & VALIDAO
(CONT.)
Arquivo de Cdigo
Arquivo de Cdigo
Planilha de Teste T02 - Ajustar a verso do produto
Plano de Projeto
Planilha de Teste
Planilha de Teste
T03 - Realizar testes de regresso Arquivo de Cdigo
Arquivo de Cdigo
QUADRO A3.12 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO IMPLANTAO
IMPLANTAO: o objetivo entregar o produto produzido para os usurios finais, por meio das atividades de codificao,
teste, empacotamento e instalao do software. Essa rea de conhecimento teve sua origem no UP e tambm est
Verso do Produto
Arquivo de Cdigo
Documento de Aceite
Manual do Usurio T04 - Entregar/Instalar a verso do produto

Manual do Usurio
Arquivo para
Instalao
QUADRO A3.13 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO AQUISIO
AQUISIO: essa rea de conhecimento tem o objetivo de gerenciar a aquisio de produtos de fornecedores, sejam
equipamentos ou at mesmo componentes de software do produto (no caso de terceirizao do servio). Exemplos de
produtos e componentes de produtos que podem ser adquiridos pelo projeto: subsistemas (por exemplo, um sistema
navegacional de uma aeronave), software, hardware, documentao (como manuais de instalao, de operao e do usurio).
A origem dessa rea de conhecimento est relacionada ao grupo de processo Aquisio da 15504-5 rea de processo
denominada Gesto de Acordo com Fornecedor do CMMI-DEV.

Pedido de Compras ACQ01 - Selecionar fornecedores e Produto comprado

estabelecer acordo
Pedido de Compras Produto comprado

Produto comprado ACQ02 - Aceitar o produto adquirido aceito
QUADRO A3.14 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO MEDIO
MEDIO: essa rea de conhecimento tem o objetivo de coletar e analisar dados relacionados aos produtos desenvolvidos e
aos processos implementados dentro da organizao por meio de projetos, a fim de dar um suporte efetivo gesto dos
processos e demonstrar objetivamente a qualidade dos produtos. Sua origem est relacionada rea de processo Anlise e
Medio do CMMI-DEV e do processo Medio da 15504-5.
Documento de
Base de Dados Documento de
Histrica da empresa CP07 - Determinar estimativas de esforo e Requisitos
tempo
Plano de Projeto
Documento de
Requisitos
Plano de Projeto
Arquitetura do
Plano de Projeto
Software
Fluxo de Caixa
Relatrio de
CP08 - Verificar a viabilidade tcnica e Viabilidade do Projeto
Fluxo de Caixa
Relatrio de
Infra-Estrutura do
Cliente
Cronograma
Relatrio de
Fluxo de Caixa
Plano de Projeto
Plano de Projeto
Qualidade (j Relatrio sobre
existente na empresa) CP14 - Conduzir reviso do milestone: Garantia de Qualidade
Estudo de Viabilidade
do Projeto
Plano de Projeto
Plano de Garantia da Relatrio sobre
Qualidade N09 - Conduzir reviso do milestone: Garantia de Qualidade
Contrato
Contrato
QUADRO A3.14 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO MEDIO (CONT.)

Plano de Projeto
Relatrio sobre
Qualidade E08 - Conduzir reviso do milestone: Garantia de Qualidade
Arquitetura do Arquitetura do Software
Software
Plano de Projeto
CT02 - Realizar teste de unidade
Arquivo de Cdigo
Arquivo de Cdigo
Planilha de Teste
Arquivo de Cdigo
Planilha de Teste
Arquivo de Cdigo
Qualidade
Arquivo de Cdigo
(Capacidade
Relatrio sobre
Produto)
Relatrio sobre
Arquivo de Cdigo
Plano de Teste
Planilha de Teste
Documento de T01 - Validar a verso do produto
Requisitos
Arquivo de Cdigo Arquivo de Cdigo

Planilha de Teste T02 - Analisar e Ajustar a verso do produto Planilha de Teste
Plano de Projeto
Planilha de Teste
Planilha de Teste
T03 - Realizar testes de regresso Arquivo de Cdigo
Arquivo de Cdigo
QUADRO A3.14 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO MEDIO (CONT.)

Qualidade
do produto
Relatrio sobre
Critrios Plano de Garantia de

estabelecidos Gqpp00 - Desenvolver um Plano de Garantia Qualidade
da Qualidade
Plano de Garantia de Relatrio sobre

Qualidade GqPP01 - Avaliar o processo e assegurar Garantia da Qualidade
resoluo de no conformidades

Qualidade GqPP02 - Avaliar os produtos de trabalho e Garantia da Qualidade
assegurar resoluo de no conformidades
QUADRO A3.15 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GARANTIA DA QUALIDADE DE

PRODUTO E PROCESSO
GARANTIA DA QUALIDADE DE PRODUTO E PROCESSO: o objetivo dessa rea de conhecimento fornecer a garantia de
que processos e produtos de trabalho estejam em conformidade com planos e provises pr-definidos. Sua origem est
relacionada tanto ao CMMI quanto ISO/IEC 15504.
Plano de Projeto
do Projeto
Plano de Projeto
Contrato
Contrato
Plano de Projeto
Relatrio sobre
Software
QUADRO A3.15 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GARANTIA DA QUALIDADE DE

PRODUTO E PROCESSO (CONT.)
Qualidade
Arquivo de Cdigo
(Capacidade
Relatrio sobre
Produto)
Relatrio sobre
Qualidade
do produto
Relatrio sobre

Qualidade GqPP01 - Avaliar o processo e assegurar Garantia da Qualidade
resoluo de no conformidades

Qualidade GqPP02 - Avaliar os produtos de trabalho e Garantia da Qualidade
assegurar resoluo de no conformidades
QUADRO A3.16 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GESTO DE REQUISITOS
GESTO DE REQUISITOS: o objetivo dessa rea de conhecimento, que teve sua origem no CMMI-DEV, gerenciar os
requisitos dos produtos e componentes de produtos dos projetos e identificar inconsistncias entre esses requisitos e os planos
e produtos de trabalho dos projetos. Para isso, essa rea trata do rastreamento dos requisitos em meio ao projeto e das
mudanas desses requisitos. As mudanas relacionadas aos requisitos utilizam algumas das atividades definidas pela rea de
conhecimento Gesto de Mudanas e Configurao.
Documento de
Requisitos
Projeto IHM
Cronograma
Modelo de Negcio
Modelo de Negcio
Mudana interna ou
externa Banco de Dados de
Plano de Gesto de GCf03 - Solicitar mudana(s) Configurao
Configurao
Banco de Dados de Banco de Dados de

Configurao GCf04. Analisar/Autorizar e Planejar Configurao
mudana(s)
Plano de Gesto de
Configurao Banco de Dados de
Banco de Dados de Configurao
Configurao GCf05 - Implementar mudana(s) Itens de configurao
Itens de configurao afetados
afetados
QUADRO A3.17 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GESTO DE MUDANAS E

CONFIGURAO
GESTO DE MUDANAS E CONFIGURAO: essa rea de conhecimento engloba a rea de processo Gesto de
Configurao do CMMI-DEV e os processos Gesto de Configurao e Gesto de Solicitao de Mudanas da 15504-5. O
objetivo dessa rea de conhecimento estabelecer e manter a integridade de produtos de trabalho usando a identificao de
configurao, controle de configurao, prestao de contas (explicao) do status da configurao e auditoria da
configurao, alm de assegurar que solicitaes de mudanas no projeto sejam gerenciadas, rastreadas e controladas.
Critrios Plano de Gesto de

estabelecidos Gqpp00 - Desenvolver um Plano de Gesto Configurao
de Configurao
Templates das
Itens de configurao
atividades
identificados
correspondentes GCf01 - Criar e identificar os itens de
Plano de Gesto de configurao
Banco de Dados de
Configurao
Configurao
QUADRO A3.17 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GESTO DE MUDANAS E

CONFIGURAO (CONT.)
Itens de configurao
Baseline
identificados
Banco de Dados de GCf02 - Criar e liberar as baselines
Banco de Dados de
Configurao
Configurao
Mudana interna ou
externa Banco de Dados de
Plano de Gesto de GCf03 - Solicitar mudana(s) Configurao
Configurao

Configurao GCf04. Analisar/Autorizar e Planejar Configurao
mudana(s)
Plano de Gesto de
Configurao Banco de Dados de
Banco de Dados de Configurao
Configurao GCf05 - Implementar mudana(s) Itens de configurao
Itens de configurao afetados
afetados

Configurao Configurao
GCf06 - Verificar/Validar e Liberar
Itens de configurao
mudana(s)
Itens de configurao
afetados afetados
QUADRO A3.18 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GESTO DE PROJETOS
GESTO DE PROJETOS: o objetivo dessa rea de processo identificar, estabelecer, coordenar e monitorar as atividades,
tarefas e recursos necessrios para um projeto produzir um produto e/ou servio, no contexto dos requisitos e restries de
projetos. Engloba tanto o processo Gesto de Projetos da 15504-5 quanto s reas de processo Planejamento de Projeto e
Monitoramento e Controle de Projeto do CMMI.
Critrios Plano de Gesto de

estabelecidos Gcf00 - Desenvolver um Plano de Gesto de Configurao
Configurao
Critrios Plano de Garantia de

estabelecidos Gqpp00 - Desenvolver um Plano de Garantia Qualidade
da Qualidade
QUADRO A3.18 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GESTO DE PROJETOS (CONT.)
Sistema de Gesto de
Gco00 - Estabelecer um sistema e estratgia Conhecimento
para gesto do conhecimento
Solicitao de
Proposta P04 - Criar infra-estrutura do projeto
Documento de
Plano de Projeto
Documento de
Requisitos CP06 - Definir/Redefinir cronograma do Cronograma
Cronograma projeto
Documento de
Base de Dados Documento de
Histrica da empresa CP07 - Determinar estimativas de esforo e Requisitos
tempo
Plano de Projeto
Documento de
Requisitos
Plano de Projeto
Arquitetura do
Plano de Projeto
Software
Fluxo de Caixa
Relatrio de
CP08 - Verificar a viabilidade tcnica e Viabilidade do Projeto
Fluxo de Caixa
Relatrio de
Infra-Estrutura do
Cliente


Plano de Projeto
CP10 - Planejar conhecimentos e habilidades
necessrias
Plano de Projeto
Cronograma
Relatrio de
Fluxo de Caixa
Plano de Projeto
Plano de Projeto
Relatrio de
Relatrio de CP12 - Acompanhar o andamento do projeto Acompanhamento do
Acompanhamento do Projeto
Projeto
Plano de Ao CP13 - Controlar custos dispendidos nessa Plano de Ao

fase
Plano de Projeto
do Projeto
Documento de
Requisitos Proposta Tcnica
Relatrio de Proposta Comercial
Relatrio de
Relatrio de Anlise Viabilidade do Projeto
da Proposta N01 - Elaborar a proposta
Cronograma
Proposta Tcnica
Documento de
Proposta Comercial Requisitos
Cronograma
Cronograma
Plano de Projeto
Plano de Projeto
N05 - Definir time do projeto Cronograma
Contrato Documento de
Proposta Tcnica formalizao do
Pedido de Compra projeto
N06 - Formalizar incio do projeto Pedido de Compra
Plano de Projeto Controle de Projetos
Plano de Projeto
Relatrio de
Relatrio de N07 - Acompanhar o andamento do projeto Acompanhamento do
Acompanhamento do Projeto
Projeto
Plano de Ao N08 - Controlar custos dispendidos nessa Plano de Ao

fase
Plano de Projeto
Contrato
Contrato
Cronograma
Controle de Tarefas
Controle de Tarefas E04 - Detalhar o cronograma
Plano de Projeto
Cronograma
Biblioteca de Casos
de Teste Padro Planilha de Teste
Documento de Plano de Projeto
E05 - Definir tcnicas e critrios para V&V
Modelo de Design
Arquitetura do
Software
Plano de Projeto
Relatrio de
Acompanhamento Projeto
de Projeto E06 - Monitorar e controlar o projeto Controle de Projetos
Cronograma
Cronograma
Contrato
Relatrio de
Controle de Projetos Viabilidade do
Relatrio de E07 - Monitorar e Controlar questes Projeto
financeiras
Viabilidade do Cobrana
Projeto
Fluxo de Caixa
Plano de Projeto
Relatrio sobre
Software
Plano de Projeto
Relatrio de
Projeto CT05 - Monitorar e controlar o projeto Controle de Projetos
Cronograma
Cronograma
Relatrio de
Cobrana
Viabilidade do Projeto CT06 - Monitorar e Controlar questes
Fluxo de caixa
Qualidade
Arquivo de Cdigo
(Capacidade
Relatrio sobre
Produto)
Relatrio sobre
Plano de Projeto
Relatrio de
Projeto T05 - Monitorar e controlar o projeto Controle de Projetos
Cronograma
Cronograma
Relatrio de
Cobrana
Viabilidade do Projeto T06 - Monitorar e Controlar questes
Fluxo de caixa
Qualidade
do produto
Relatrio sobre
QUADRO A3.19 ENTRADAS, ATIVIDADES E SADAS DA REA DE CONHECIMENTO GESTO DE CONHECIMENTO
GESTO DE CONHECIMENTO: tem como objetivo assegurar que o conhecimento, informao e habilidades individuais sejam
coletadas, compartilhadas, reusadas e melhoradas por toda a organizao. Sua origem est relacionada ao processo Gesto
de Conhecimento da ISO/IEC 15504.
Sistema de Gesto de
Gco00 - Estabelecer um sistema e estratgia Conhecimento
para gesto do conhecimento
Conhecimento
Lies aprendidas e
Sistema de Gesto de
GCo01 - Capturar o conhecimento conhecimento
Conhecimento
Lies aprendidas e
conhecimento Memria
Sistema de Gesto de GCo02 - Lapidar o conhecimento Organizacional
Conhecimento
Memria Memria
Organizacional GCo03 - Disseminar o conhecimento Organizacional
As Figuras A3.20 a A3.25, a seguir, apresentam a viso grfica das atividades
em fases. Os Quadros A3.20.1 a A3.20.5 apresentam o detalhamento de cada uma
das atividades (responsvel, descrio, recursos, entradas, sadas e tarefas) da fase
de prospeco. Os Quadros A3.21.1 a A3.21.14 o detalhamento das atividades da
fase de concepo, os Quadros A3.22.1 a A.3.22.9 da fase de negociao, os
Quadros A3.23.1 a A3.23.8 da fase de elaborao, os Quadros A3.24.1 a A3.24.7 da
fase de construo e os Quadros A3.25.1 a A3.25.7 da fase de transio.

FIGURA A3.20 VISO GRFICA FASE: PROSPECO
QUADRO A3.20.1 DETALHAMENTO DA ATIVIDADE P01

Atividade P01. Buscar contatos
Responsveis Equipe de Vendas
Descrio Essa atividade tem como objetivo buscar na internet ou na base de contatos
da empresa os potenciais clientes, de acordo com os perfis estabelecidos no
plano de marketing e na estratgia da empresa para o perodo em questo.
Recursos - Ferramentas de relacionamento com cliente (CRM), tais como: VTIGER,
DBMKT, newsletter, e-mail marketing, mecanismos de buscas, websites
Entradas e1) Plano de Negcios (j deve existir na empresa)
e2) Plano de Marketing (j deve existir na empresa)
e3) Plano de Ao (j deve existir na empresa)
e4) Base de contatos (j deve existir na empresa)
Sadas s1) Lista de Contatos
Tarefas - Executar as atividades para busca de potenciais clientes (item 3.2 do
"Plano de Marketing").
* Executar a etapa 1 definida no item "Plano de Ao" (item 4 do "Plano
de Marketing"), a fim de validar os contatos, com base no planejamento
definido na planilha "Plano de Ao" do arquivo "Plano de Ao".
* Criar planilha Lista de Contatos (conforme GCf01) e registrar os
contatos validados na planilha "Lista de Contatos", a partir da "Base de
Contatos" da empresa.
* Registrar a data de realizao da etapa 1 descrita no item 4 do "Plano
de Marketing" na planilha "Controle de Visitas" do arquivo "Lista de
Contatos", para todos os contatos validados.

Atividade P02. Prospectar cliente
Descrio Essa atividade tem como objetivo fazer com que a empresa desenvolvedora
entre em contato com o cliente para averiguar a possibilidade de um projeto.
Recursos - Ferramentas de relacionamento com cliente (CRM), tais como: VTIGER,

DBMKT, newsletter, e-mail marketing, mecanismos de buscas, websites
Entradas e1) Lista de Contatos

e2) Plano de Marketing
Sadas s1) Lista de Contatos
s2) Roteiro de Prospeco
Tarefas - Selecionar abordagem do cliente, priorizando contatos que demonstraram
interesse depois de executada a etapa 1 do item 4 do "Plano de Marketing".
Exemplo de abordagem selecionada: etapa 2 do plano de ao - Contato
telefnico
- Identificar contato chave para processo de prospeco e registrar na
planilha "Lista de Contatos" do arquivo "Lista de Contatos". Exemplo:
Contato que tem poder de deciso
- Levantar informaes sobre o cliente e registrar na planilha "Lista de
Contatos" do arquivo "Lista de Contatos". Exemplo: Verificao de gargalos
e necessidades, nvel de satisfao com o atual prestador de servios, etc
- Criar "Roteiro de Prospeco" (conforme GCf01), de acordo com o item 4
(plano de ao) do "Plano de Marketing"
- Entrar em contato com o cliente utilizando o roteiro de prospeco
- Registrar a data de comunicao com o cliente na coluna "Etapa 2" na
"Lista de Contatos"
- Verificar o interesse do cliente por uma proposta e registrar na coluna
"Interesse por proposta"

Atividade P03. Visitar cliente

Cliente
Descrio Essa atividade tem como objetivo iniciar um relacionamento personalizado
com o cliente, a fim de averiguar o interesse do cliente na solicitao de
uma proposta de soluo para as demandas colocadas.
Recursos - Meios de deslocamento
- Laptop
- Ferramenta de modelagem de negcio (ex: Rational Rose, ARPO)
Entradas e1) Lista de Contatos
Sadas s1) Modelo de Negcio

s2) Material de divulgao
s3) Lista de Contatos
s4) Lista de Requisitos do Cliente
Tarefas - Pesquisar informaes sobre a atividade do cliente e de solues
utilizadas pelo mesmo e registrar na planilha "Lista de Contatos" do arquivo
"Lista de Contatos"
- Preparar material de divulgao, no caso de existir na empresa algum
produto que se encaixe na necessidade do cliente
* Levantar situaes onde a empresa desenvolvedora teve sucesso no
atendimento de clientes com problemas anlogos
* Preparar demonstraes (.ppt, flash) sobre as situaes anlogas
levantadas
- Na reunio com o cliente, levantar possveis demandas, necessidades e
informaes do cliente, inclusive os casos de uso de negcio do cliente,
caso necessrio.
* Criar arquivo "Lista de Requisitos do Cliente" (conforme GCf01) para
armazenar as demandas e necessidades do cliente
* Solicitar ao cliente que a empresa seja procurada quando surgirem
demandas futuras.
* Cadastrar a data da visita na planilha "Controle de Visitas" do arquivo
"Lista de Contatos"
* Criar o arquivo "Modelo de Negcio" (conforme GCf01) e registrar as
informaes obtidas relacionadas ao vocabulrio do negcio (item 1), aos
casos de uso de negcio (item 2) e s regras de negcio (item 3)

Atividade P04. Criar infra-estrutura do projeto
Responsveis Gerente de Projeto
Descrio A qualquer momento, um cliente pode solicitar uma proposta e, nesse caso,
deve-se criar a infra-estrutura necessria para dar incio ao projeto.
Recursos Ferramenta de gesto de projetos (ex: dotProject, MS-Project, Primavera)
Entradas e1) Solicitao de Proposta
Sadas s1) Controle de Projetos

s2) Proposta do Cliente Impressa
Tarefas - Caso o arquivo "Controle de Projetos" ainda no tenha sido criado, cri-lo
(conforme GCf01)
- Definir o ID do projeto (h uma sugesto no item 4 "Estratgia de
identificao dos itens de configurao" do "Plano de Gesto de
Configurao")
- Criar projeto na planilha "Identificao de Projetos" do arquivo "Controle
de Projetos" da empresa e preencher os campos: id_projeto e descrio
- Criar pasta fsica e pasta lgica e marcar "sim" nas respectivas colunas da
planilha "Identificao de Projetos" do arquivo "Controle de Projetos"
* Quanto proposta solicitada pelo cliente, se for o caso:
- Registrar data de solicitao da proposta pelo cliente, caso ocorra, na
planilha "Controle de Visitas" do arquivo "Lista de Contatos"
- Digitalizar a proposta solicitada pelo cliente
- Anexar a proposta na pasta lgica
- Imprimir a proposta e solicitar que o cliente a assine para que seja
armazenada na pasta fsica.
- Selecionar projeto na planilha "Acompanhamento" do arquivo "Controle de
Projetos" da empresa e preencher os campos: situao (selecionar a opo
"inicializado" do combo-box), data de inicializao do projeto, marcar a fase
de concepo, ciclo de desenvolvimento e data de incio da fase de
concepo

Atividade P05. Controlar custos despendidos na fase de prospeco
Descrio Essa atividade tem como objetivo registrar todos os custos referentes
execuo das atividades dessa fase.
Recursos
Entradas e1) Plano de Ao
Sadas s1) Plano de Ao
Tarefas - Atualizar na planilha "Acompanhamento" (item "Atividades") do arquivo

"Plano de Ao" a quantidade de atividades realizadas de fato
- Atualizar na planilha "Acompanhamento" (item "Custos") os custos reais
referentes execuo de todas as atividades dessa fase
FIGURA A3.21 VISO GRFICA FASE: CONCEPCO

QUADRO A3.21.1 DETALHAMENTO DA ATIVIDADE CP01

Atividade Cp01. Entender o negcio e as necessidades do cliente

Engenheiro de Requisitos
Cliente
Descrio Essa atividade tem por objetivo entender o negcio do cliente, as
necessidades do cliente e as regras de seu negcio, por meio de tcnicas
de levantamentos de requisitos, a fim de definir com clareza os requisitos do
sistema.
Recursos - Ferramenta de modelagem de negcio (ex: Rational Rose, ARPO)
- Tcnica JAD
- Ferramenta de Prototipao
Entradas e1) Controle de Projetos
e2) Modelo de Negcio
e3) Lista de Requisitos do Cliente
e4) Relatrio de Anlise dos Requisitos
Sadas s1) Modelo de Negcio
s2) Lista de Requisitos do Cliente
s3) Infra-Estrutura do Cliente
s4) Relatrio de Anlise dos Requisitos
QUADRO A3.21.1 DETALHAMENTO DA ATIVIDADE CP01 (CONT.)

Tarefas No caso de j ter sido realizada a atividade "Cp04. Verificar e validar os
requisitos" e, se necessrio:
- Realizar reunies com o cliente para elucidar os conflitos entre os
requisitos detectados na peer review
* Fazer as alteraes no "Modelo de Negcio", caso necessrio
* Descrever a soluo adotada no item 1 do "Relatrio de Anlise dos
Requisitos"
Em outros casos:
- Identificar fontes de requisitos (documentos, pessoas, sistemas de
informao utilizados). Por exemplo, caso haja um projeto que ir influenciar
na maneira de trabalhar de toda a organizao, relevante saber quais so
as pessoas chave de cada rea da empresa, quais sistemas so utilizados
em cada rea, etc.
- Selecionar tcnicas de levantamento de requisitos. Por exemplo,
entrevistas, questionrios, brainstorming, prototipao, JAD, entre outras.
Caso seja utilizada a tcnica de prototipao, os prottipos podem ser
registrados no Apndice 3 do arquivo "Documento de Requisitos".
- Preparar as reunies de levantamento de requisitos, de acordo com as
tcnicas selecionadas.
* Com base nas fontes de requisitos, definir os participantes das reunies
e as disponibilidades de cada um.
* Agendar cronograma das reunies
* Preparar o material que ser utilizado, de acordo com as tcnicas
selecionadas. Por exemplo, preparar um questionrio, etc
- Levantar/complementar as necessidades do cliente, a partir das reunies,
e compilar os dados obtidos, atualizando a "Lista de Requisitos do Cliente"
(Apndice 1 do Documento de Requisitos).
- Entender o negcio do cliente
* Caso ainda no exista, criar "Modelo de Negcio" (conforme GCf01)
* Levantar/complementar os casos de uso de negcio e registr-los no item
2 do arquivo "Modelo de Negcio".
* Levantar/complementar as regras do negcio e vocabulrio e registr-los
nos respectivos itens do arquivo "Modelo de Negcio".
- Criar arquivo "Infra-Estrutura do Cliente" (conforme GCf01) e registrar
sobre a infra-estrutura atual do cliente, pois influenciar na soluo a ser
proposta.
- Obs: Para fazer alteraes nos artefatos, acione a rea de Gesto de
Mudanas e Configurao, a partir da atividade "GCf03. Solicitar mudanas"

Atividade Cp02. Definir escopo do projeto

Descrio Essa atividade dever ser realizada para dar incio ao planejamento do
projeto e para dar suporte realizao da proposta que dever ser enviada
ao cliente.
Recursos
Entradas e1) Lista de Requisitos do Cliente
Sadas s1) Plano de Projeto
Tarefas - Criar Plano do Projeto (conforme GCf01)

- A partir do levantamento de requisitos, descrever o escopo do projeto do
arquivo "Plano de Projeto".
* Descrever o cenrio (item 1.1):
- identificar as necessidades que motivaram o cliente a solicitar o
projeto, a partir da "Lista de Requisitos do Cliente"
- definir os stakeholders (interessados) e usurios do sistema (quem
so e quais as necessidades de cada um) e
- descrever as expectativas que o projeto visa atender
* Definir premissas, limitaes e restries do projeto (item 1.3)
- Definir os critrios de aceitao do cliente e registr-los no item 1.4 do
"Plano de Projeto"
* Descrever como o projeto atender s expectativas do cliente
* Descrever itens de sucesso para o cliente, como antecipao de
prazos

Atividade Cp03. Determinar requisitos do produto
Responsveis Engenheiro de Requisitos
Descrio Transformar os requisitos do cliente em requisitos do produto, uma vez que

uma necessidade do cliente pode ser traduzida em mais de um requisito do
produto; a descrio dos requisitos depender do nvel de detalhamento
definido. Tambm, quando necessrio, devem ser utilizados prottipos para
auxiliar na melhor definio dos requisitos.
Recursos
Entradas e1) Modelo de Negcio

e2) Documento de Requisitos
e3) Lista de Requisitos Padro do Produto (j existente na empresa)
Sadas s1) Documento de Requisitos
s2) Projeto IHM
s3) Relatrio de Anlise dos Requisitos
Tarefas No caso de j ter sido realizada a atividade "Cp04. Verificar e validar os
* Fazer as alteraes no "Documento de Requisitos", caso necessrio
* Descrever a soluo adotada no item 2 do "Relatrio de Anlise dos
Requisitos"
Em outros casos:
- Descrever/Atualizar o escopo do produto; as siglas, abreviaes e
definies utilizadas e as referncias adquiridas e registr-los no arquivo
"Documento de Requisitos".
* Criar/Atualizar o arquivo "Documento de Requisitos" (conforme GCf01)
- Definir/Atualizar e registrar no captulo 2 do "Documento de Requisitos", a
partir da Lista de Requisitos do Cliente (apndice do arquivo "Documento de
Requisitos") e do "Modelo de Negcio": a Perspectiva do Produto, as
principais Funes do Produto, as Caractersticas dos Usurios, os Limites,
Suposies e Dependncias
* Caso se trate de algum produto j desenvolvido pela empresa, deve-se
selecionar a partir da "Lista de Requisitos do Padro Produto", aqueles
requisitos que sero colocados na proposta ao cliente.
- Definir/Atualizar volatilidade dos requisitos, isto , probabilidade de
mudana dos requisitos elicitados
- Caso o sistema tenha que atender diferentes tipos de perfis de usurios:
* Criar/Atualizar Projeto IHM (conforme GCf01)
* Definir perfis de usurios e registrar no item 1 do "Projeto IHM" (Projeto
de Interface Homem Mquina)

Atividade Cp04. Verificar e Validar os requisitos
Responsveis Equipe de Teste

Cliente
Descrio Essa atividade tem por objetivo a realizao da verificao dos requisitos e,
posteriormente, da validao dos mesmos junto ao cliente.
Recursos
Entradas e1) Documento de Requisitos

e2) Checklist de Requisitos
e4) Projeto IHM
Sadas s2) Relatrio de Anlise dos Requisitos
Tarefas - Realizar peer review (uma das pessoas no deve ter participado do
desenvolvimento do Documento de requisitos)
* Analisar os requisitos a partir do "Documento de Requisitos", "Modelo de
Negcio" e "Projeto IHM" e, se for o caso, do "Relatrio de Anlise dos
Requisitos" para ver se h conflitos entre as solicitaes dos stakeholders,
documentando tais conflitos no "Relatrio de Anlise dos Requisitos"
(criar/atualizar "Relatrio de Anlise dos Requisitos", conforme GCf01)
* Para dar subsdio ao peer review, pode ser utilizado um checklist (vide
"Checklist de Requisitos")
- Realizar reunies com o cliente para validar os requisitos (averiguar se o
que est descrito est de acordo com as necessidades do cliente)
* Registrar eventuais conflitos no "Relatrio de Anlise dos Requisitos"

Atividade Cp05. Estudar solues alternativas de arquitetura do software
Responsveis Equipe de Desenvolvimento

Descrio Essa atividade realizada com base nos requisitos mais crticos para ser
sugerida a arquitetura do software.
Recursos Ferramenta de Modelagem de Software (ex: ArgoUML, Rational Rose,

Eclipse, JUDE)
Sadas s1) Arquitetura do Software

s2) Documento de Requisitos
Tarefas - Criar/Atualizar o arquivo "Arquitetura do Software" (conforme GCf01)
- Definir os Fatores Arquiteturais, ou seja, os requisitos no funcionais que
influenciaro na escolha da arquitetura, e registr-los no item 1 do
documento "Arquitetura do Software".
- Definir/Atualizar a arquitetura lgica do sistema, ou seja, a organizao
em larga escala das classes de software em pacotes, subsistemas, e
dependendo do caso em camadas, e registr-la no item 2 do documento
"Arquitetura do Software".
- Definir/Atualizar a topologia do sistema, ou seja, como os elementos
fsicos do sistema estaro dispostos e registrar no item 3 do documento
- Descrever as decises arquiteturais e registrar no item 4 do documento
- Averiguar quais componentes podem ser adquiridos sem custos, quais j
esto prontos e quais compensam ser comprados/terceirizados, e registrar
no Apndice 2 do "Documento de Requisitos".
- Complementar o item "Perspectiva do Produto" do "Documento de
Requisitos", dependendo do que foi definido como sendo a arquitetura do
software.

Atividade Cp06. Definir/Redefinir cronograma do projeto
Descrio Essa atividade tem como objetivo definir/redefinir o cronograma do projeto, a

partir da WBS elaborada.
Recursos Ferramenta de gerenciamento de projeto (ex: dot Project, MS-Project,

Primavera)

e2) Cronograma
e3) Plano de Projeto
Sadas s1) Cronograma
s2) Plano de Projeto
Tarefas - Elaborar/Atualizar WBS (Work Breakdown Structure) no arquivo
"Cronograma"
* Pode ser usada uma ferramenta de gerenciamento de projeto, como dot
Project
* Definir/Redefinir quantos ciclos de desenvolvimento o projeto ter (cada
ciclo de desenvolvimento passa, normalmente, pelas fases elaborao,
construo e transio, com menor ou maior nfase em algumas delas.
Entretanto, pode existir a ocasio em que seja necessrio voltar fase de
concepo para renegociar mudanas relevantes no projeto e, por
conseqncia, no contrato). Cada ciclo de desenvolvimento produz um
release do software.
* Definir/Redefinir as fases do projeto, se achar pertinente
* Definir/Redefinir as entregas do projeto, que so desdobramentos do
produto do projeto em resultados tangveis, a partir do "Documento de
Requisitos". A caracterstica fundamental das entregas a capacidade de
serem medidas e avaliadas. Por ex: manual do usurio, manual do sistema,
verso do sistema.
* Criar/Atualizar arquivo "Plano de Projeto" (conforme GCf01) e registrar
quem so as entregas no escopo do projeto desse arquivo
* Definir/Redefinir pacotes de trabalho os quais representam um conjunto
de atividades que precisam ser feitas para obteno de uma entrega ou de
um produto de projeto.
- Definir/Redefinir a inter-dependncia e seqncia das atividades
* Baseado nos pacotes de trabalho, definidos anteriormente, relacionar
entradas e sadas de cada atividade
* Definir/Redefinir quais as entradas e sadas so mutuamente
dependentes

Atividade Cp07. Determinar estimativas de esforo e tempo

Equipe de Desenvolvimento
Descrio Essa atividade dever ser realizada para estimar o esforo e durao das
atividades do projeto com base em cronogramas de referncia, base de
dados histrica da empresa ou em experincias adquiridas, para que o
projeto possa ser medido e controlado.
Primavera)

e2) Base de Dados Histrica da empresa
e3) Cronograma
Sadas s1) Cronograma
Tarefas - Definir/Redefinir a dimenso (tamanho) do sistema a ser desenvolvido.
* Podem ser usadas as mtricas pontos por funo, quantidade de casos
de uso ou qualquer outra mtrica que achar pertinente
- Procurar algum projeto similar na Base de Dados Histrica da empresa
(criada com o decorrer dos projetos da empresa), de acordo com alguns
parmetros, tais como: domnio de negcio do sistema, tamanho do
sistema, funcionalidades do sistema, plataforma utilizada, nvel de
conhecimento dos colaboradores.
- Calcular estimativas de esforo e durao em horas das atividades da
WBS.
* Criar/Atualizar arquivo "Cronograma" (conforme GCf01)
* Os clculos devem ser registrados no "Cronograma"
* Utilizar a Base de Dados Histrica da empresa ou experincia de
especialistas, alm do "Documento de Requisitos" do projeto em andamento
para embasar as estimativas de esforo e durao das atividades a serem
realizadas.
- Definir/Redefinir os papis que devem executar cada uma das atividades e
registrar no "Cronograma". Por exemplo, a atividade elaborar cronograma
deve ser executada por um gerente de projeto e no por um colaborador da
equipe de teste
- Colocar no cronograma o valor da hora do papel que deve executar cada
atividade, a fim de calcular o custo de cada atividade, e do projeto como um
todo
- Estabelecer/Restabelecer prazos mximos no escopo do projeto do "Plano
de Projeto", a partir do cronograma elaborado.

Atividade Cp08. Verificar a viabilidade tcnica e financeira do projeto

Equipe de Vendas
Descrio Essa atividade tem como objetivo avaliar se vivel a execuo do projeto
em termos tcnicos e financeiros.

Primavera)

e3) Arquitetura do Software
e4) Plano de Ao
e5) Infra-Estrutura do Cliente
s2) Relatrio de Viabilidade do Projeto
s3) Fluxo de Caixa
Tarefas - Definir/Redefinir o custo operacional geral do produto para a empresa
desenvolvedora
* Criar/Atualizar arquivo "Relatrio de Viabilidade" (conforme GCf01)
* Descrever os itens da configurao tcnica para a soluo a ser
concebida, a partir do documento "Arquitetura do Software" e registrar na
"Tabela de Custos" do "Relatrio de Viabilidade".
* Descrever os outros direcionadores de custo (cost driver), tal como valor
da mo-de-obra
* Definir/Redefinir valor da unidade dos cost drivers
* Estimar valores de possveis aquisies
* Considerar as restries do projeto descritas no escopo do projeto no
arquivo "Plano de Projeto"
- Descrever relao custo x benefcio para o cliente da soluo proposta e
registrar no "Relatrio de Viabilidade", considerando as informaes
contidas na "Infra-Estrutura do Cliente"
- Fazer/Refazer o fluxo de caixa do projeto
* Criar/Atualizar arquivo "Fluxo de Caixa" (conforme GCf01)
* Utilizar dados relacionados aos custos at o fechamento do contrato,
advindos do "Plano de Ao"
- Definir/Redefinir o cronograma de recebimentos e registrar no "Relatrio de
Viabilidade"
- Definir/Redefinir o preo do produto final do projeto e registrar no "Relatrio
de Viabilidade"
- Registrar custo operacional geral e preo-meta do produto do projeto no
escopo do projeto do "Plano de Projeto"
- Verificar no Fluxo de Caixa, o valor que poder ser investido no projeto por
ms, para que possam ser alocados colaboradores e recursos de forma
otimizada e que no inviabilize a questo financeira do projeto para a
empresa desenvolvedora

Atividade Cp09. Planejar os recursos do projeto

Equipe de Compras
Descrio Essa atividade tem como objetivo levantar quais so os recursos
necessrios para o desenvolvimento do projeto. Entende-se por recursos
todos os equipamentos, ferramentas e materiais.
Primavera)
Entradas e1) Cronograma

e2) Controle de Projetos
s2) Controle de Projetos
s3) Pedido de Compra
Tarefas - Verificar no "Cronograma" quais atividades ou entregas necessitam de
recursos e preencher no item "Plano de Recursos" do "Plano de Projeto"
- Verificar na planilha "Identificao de Recursos" do arquivo "Controle de
Projetos" se os recursos necessrios existem e esto disponveis ou se
precisam ser adquiridos.
* Se existirem e estiverem disponveis, o gerente de projetos deve
assinalar na planilha "Alocao de Recursos" do "Controle de Projetos" a
data de alocao e a previso de uso desse recurso em qual projeto.
* Se no existirem, criar o arquivo "Pedido de Compra" (conforme CGf01)
e preench-lo. Inserir no "Pedido de Compra" o status "congelado", que ser
alterado para "liberado" caso o cliente feche o contrato.

Atividade Cp10. Identificar conhecimentos e habilidades necessrias
Descrio Essa atividade tem como objetivo levantar quais so os conhecimentos e

habilidades necessrias para o desenvolvimento do projeto.

Primavera)

Tarefas - Identificar quais habilidades/conhecimentos sero necessrios para o
desenvolvimento do projeto e registrar no item "Plano de Habilidades e
Conhecimento" do "Plano de Projeto"
- Verificar no item "Plano de Recursos" do "Plano de Projeto", quais
ferramentas sero utilizadas no projeto para confrontar na planilha
"identificao de colaboradores" do arquivo "Controle de Projetos" quais so
os mais indicados para fazer parte do time
- Sugerir o time, baseado na anlise realizada anteriormente, e registr-lo
junto ao "Plano de Habilidades e Conhecimento" do "Plano de Projeto"
- Registrar na planilha "Alocao de Colaboradores", os colaboradores do
projeto que foram sugeridos para compor o time, a possvel data de
alocao, previso do trmino da alocao
- Definir status dos colaboradores pertencentes ao time como "reservado"
na planilha "Alocao de Colaboradores" do "Controle de Projetos"

Atividade Cp11. Identificar riscos inerentes ao projeto

Analista de Riscos
Descrio Essa atividade tem como objetivo identificar os riscos inerentes ao projeto e
estabelecer um plano de contingncia.
Recursos

e2) Relatrio de Viabilidade do Projeto
e3) Fluxo de Caixa
Tarefas - Identificar os riscos oramentrios analisando o relatrio de viabilidade

- Identificar os riscos de prazo verificando o caminho crtico (PERT/CPM) no
cronograma
- Identificar os riscos de rotatividade de pessoal baseado no histrico da
empresa
- Identificar riscos tcnicos, riscos de projeto e de negcio
- Definir a escala dos riscos: booleana, qualitativa ou quantitativa. Por ex:
booleana: sim ou no; qualitativa: altamente, pouco, moderado, etc;
quantitativo: em termos numricos como %
- Elaborar/Atualizar checklists (conjuntos de questes) para classificar os
riscos ou utilizar checklists existentes, baseado na escala definida
anteriormente
- Definir/Redefinir a probabilidade de ocorrncia dos riscos baseado na
classificao anterior
- Definir/Redefinir os impactos dos riscos, ou seja, quais as conseqncias
caso os riscos ocorram
- Definir/Redefinir prioridade dos riscos a serem atacados, uma vez que se
conhece os impactos dos mesmos
- Definir/Redefinir aes pr-ativas para no deixar que os riscos negativos
priorizados se concretizem e para garantir que os riscos positivos
priorizados se concretizem
- Elaborar/Atualizar o plano de contingncia que ser utilizado caso algum
risco venha a se concretizar e registr-lo no apndice "Plano de
Contingncia" do "Plano de Projeto"

Atividade Cp12. Acompanhar o andamento do projeto
Descrio Essa atividade tem como objetivo o acompanhamento do projeto.
Recursos

s2) Relatrio de Acompanhamento do Projeto
Tarefas - Inserir a data de trmino da fase do projeto na planilha "Acompanhamento
de Projetos" do arquivo "Controle de Projetos", replicar a linha do projeto e
inserir a nova fase com sua data de incio
- Inserir na planilha "Acompanhamento de Projetos" do arquivo "Controle de
Projetos" a quantidade de horas trabalhadas de cada um dos colaboradores
nessa fase.
- Revisar a documentao quanto aos riscos no arquivo "Plano de Projeto"
no contexto atual do projeto
* Em casos de problemas, acionar o "Plano de Contingncia" (Apndice 1
do "Plano de Projeto")
* Criar arquivo "Relatrio de Acompanhamento do Projeto" (conforme
GCf01)
* Registrar informaes no arquivo "Relatrio de Acompanhamento do
Projeto" referentes ao acionamento do "Plano de Contingncia"

Atividade Cp13. Controlar custos despendidos na fase de concepo

Gerente de Projeto
Recursos

"Plano de Ao" a quantidade de atividades realizadas de fato.
referentes execuo de todas as atividades dessa fase.

Atividade Cp14. Conduzir reviso do milestone: Estudo de Viabilidade do Projeto
Responsveis Equipe de Qualidade

Gerente de Projeto
Descrio Essa atividade tem o objetivo de revisar o milestone que marca o final dessa
fase.
Recursos
Entradas e1) Plano de Garantia da Qualidade (j existente na empresa)

e2) Produto de Trabalho: Relatrio de Viabilidade do Projeto
Sadas s1) Relatrio sobre Garantia da Qualidade
Tarefas - Realizar a atividade "GqPP01. Avaliar o processo e assegurar resoluo

de no conformidades"
- Realizar a atividade "GqPP02. Avaliar os produtos de trabalho e assegurar
resoluo de no conformidades"
FIGURA A3.22 VISO GRFICA FASE: NEGOCIAO

QUADRO A3.22.1 DETALHAMENTO DA ATIVIDADE N01

Atividade N01. Elaborar proposta
Responsveis Gerente do Projeto

Equipe de Vendas
Descrio Elaborar a proposta do projeto baseado no Documento de Requisitos e no
cronograma de recebimentos estipulado no Relatrio de Viabilidade do
Projeto, alm de considerar o feedback do cliente encontrado no Relatrio
de Anlise da Proposta.
Recursos

e3) Relatrio de Anlise da Proposta
e4) Cronograma
Sadas s1) Proposta Tcnica
s2) Proposta Comercial
s3) Relatrio de Viabilidade do Projeto
s4) Cronograma
Tarefas - Criar/Atualizar arquivo "Proposta Comercial" (conforme GCf01) e
preencher:
* os dados completos do cliente (Razo Social, CNPJ, Endereo,
Telefones, Contato)
* a relao custo x benefcio da soluo proposta para o cliente, advinda
do "Relatrio de Viabilidade do Projeto"
* o cronograma estimado de entregas baseado no Cronograma (WBS)
* o preo baseado no "Relatrio de Viabilidade do Projeto"
* o cronograma de pagamentos do cliente baseado no cronograma de
recebimentos do "Relatrio de Viabilidade do Projeto"
- Determinar a validade da "Proposta Comercial"
- Criar/Atualizar arquivo "Proposta Tcnica" (conforme GCf01) e:
* registrar os dados da empresa de desenvolvimento
* inserir, como apndice, na "Proposta Tcnica" os requisitos descritos no
item "2.2 Funes do Produto" do arquivo "Documento de Requisitos"
- Registrar o ID da "Proposta Tcnica" na "Proposta Comercial"
- Analisar o "Relatrio de Anlise da Proposta" vindo do cliente com o
"Relatrio de Viabilidade do Projeto"
- Realizar as possveis modificaes na proposta e, se necessrio:
* acessar a atividade "Cp03. Determinar requisitos do produto" para
modificar o "Documento de Requisitos"
* acessar a atividade "Cp06. Definir/Redefinir cronograma do projeto" para
modificar o cronograma estimado de entregas do "Cronograma" (WBS)
* acessar a atividade "Cp08. Verificar a viabilidade tcnica e financeira do
projeto" para modificar o cronograma de recebimentos do "Relatrio de
Viabilidade do Projeto"

Atividade N02. Analisar proposta
Responsveis Cliente
Descrio O cliente deve analisar a proposta; no caso de estar de acordo deve

devolv-la assinada, caso contrrio, deve enviar as alteraes necessrias
que sero registradas como um Relatrio de Anlise da Proposta.
Recursos
Entradas e1) Proposta (Comercial e Tcnica)
Sadas s2) Relatrio de Anlise da Proposta
Tarefas - Obter o feedback do cliente a respeito da proposta enviada.

* Caso o cliente esteja de acordo, deve assinar a proposta

Atividade N03. Elaborar contrato

Gerente de projetos
Assessor Jurdico
Descrio Elaborar o contrato do projeto baseado na Proposta assinada pelo cliente,
alm de considerar o feedback dado pelo cliente encontrado no Relatrio de
Anlise do Contrato.
Recursos
Entradas e1) Proposta

e2) Relatrio de Anlise do Contrato
Sadas s1) Contrato
Tarefas - Criar/Atualizar arquivo "Contrato" (conforme GCf01) e preencher:

* os dados do cliente (obtidos da proposta comercial)
* os dados da empresa de desenvolvimento (obtidos da proposta tcnica)
* o objeto de contrato
* os aspectos tcnicos: prazo de desenvolvimento e data das entregas,
especificao quanto ao suporte, especificao quanto s condies de
instalao e uso do sistema
* os aspectos financeiros: preo, cronograma de pagamentos e
penalidades
* os aspectos legais: estabelecimento de garantias, definies de prazo do
contrato e de licenas de uso, definio das responsabilidades das partes
* o controle de alteraes: procedimentos de mudanas e limitao para
alterao de requisitos

Atividade N04. Analisar contrato
Responsveis Cliente
Descrio O cliente deve analisar o contrato; no caso de estar de acordo deve devolv-
lo assinado, caso contrrio, deve enviar as alteraes necessrias que
sero registradas como um Relatrio de Anlise do Contrato.
Recursos
Entradas e1) Contrato
Sadas s1) Relatrio de Anlise do Contrato
Tarefas - Obter o feedback do cliente a respeito do contrato enviado, referente s
questes no tratadas na proposta, como questes legais e controle de
alteraes
* Caso o cliente esteja de acordo, deve assinar o contrato

Atividade N05. Definir time do projeto
Descrio Definir quem sero as pessoas integrantes do time do projeto com base no
Plano de Habilidades e Conhecimento (do Plano de Projeto), no
Cronograma estabelecido e no calendrio de colaboradores (obtido pela
anlise da planilha "alocao de colaboradores" do Controle de Projetos).
Primavera)

e4) Contrato assinado
s2) Cronograma
Tarefas - Verificar no Calendrio de Alocao de Colaboradores (obtido pela anlise
da planilha "alocao de colaboradores" do Controle de Projetos) a
disponibilidade dos colaboradores, confrontando com o time sugerido no
Plano de Habilidades e Conhecimento do "Plano de Projeto"
* Reajustar o seqenciamento das atividades ou alocar algumas das
atividades para outro colaborador, caso haja acmulo de atividades para um
colaborador
* Definir o time do projeto e atualizar no Plano de Habilidades e
Conhecimento do "Plano de Projeto" e na planilha de alocao de
colaboradores do "Controle de Projetos", inserindo o status "formalizado"
para os colaboradores escolhidos
- Atualizar o Cronograma substituindo os papis pelos colaboradores do
time de projeto
- Definir a estratgia utilizada durante o desenvolvimento do projeto, tal
como reunies semanais com o cliente, e registrar no escopo do projeto do
"Plano de Projeto"

Atividade N06. Formalizar incio do projeto

Equipe de Vendas
Equipe de Qualidade
Equipe de Finanas
Equipe de Compras
Descrio Comunicar a todos os interessados, interna e externamente ao projeto, a
inicializao do mesmo.
Recursos
Entradas e1) Contrato

e2) Proposta Tcnica
e3) Pedido de Compra
Sadas s1) Documento de formalizao do projeto
s2) Pedido de Compra
Tarefas - Comunicar internamente a formalizao do projeto, uma vez que foi
iniciado na fase de Prospeco, disponibilizando aos colaboradores a
Proposta Tcnica
- Alterar o status do projeto (na planilha "Acompanhamento de Projetos" do
arquivo "Controle de Projetos") para "formalizado" e preencher a data de
formalizao
- Emitir a Nota Fiscal e registrar a emisso na aba "Notas Fiscais" do
arquivo "Controle de Projetos"
- Lanar as duplicatas e registrar o lanamento na aba "Notas Fiscais" do
arquivo "Controle de Projetos"
- Comunicar ao setor de faturamento os registros do contrato
- Alterar o status do "Pedido de Compra" para "liberado" com a data de
liberao, se for o caso, e acessar as atividades "Acq01. Selecionar
fornecedores e estabelecer acordo" e "Acq02. Aceitar o produto adquirido"
- Obter comprometimento com o plano
* Criar arquivo "Documento de Formalizao do Projeto" (conforme GCf01)
* Assegurar comprometimento dos colaboradores com o "Plano de Projeto"
por meio de uma reunio que deve ser documentada em forma de ata no
"Documento de Formalizao do Projeto", assinado por todos os
colaboradores e anexado na pasta fsica do projeto.

Atividade N07. Acompanhar o andamento do projeto
Descrio Essa atividade tem como objetivo o acompanhamento do projeto.
Recursos

e3) Relatrio de Acompanhamento do Projeto
s2) Relatrio de Acompanhamento do Projeto
Tarefas - Inserir a data de trmino da fase do projeto na planilha "Acompanhamento
de Projetos" do arquivo "Controle de Projetos", replicar a linha do projeto e
inserir a nova fase com sua data de incio
- Inserir na planilha "Acompanhamento de Projetos" do arquivo "Controle de
Projetos" a quantidade de horas trabalhadas de cada um dos colaboradores
nessa fase.
- Revisar a documentao quanto aos riscos no arquivo "Plano de Projeto"
no contexto atual do projeto
* Em casos de problemas, acionar o "Plano de Contingncia" (Apndice 1
do "Plano de Projeto")
* Criar/Atualizar arquivo "Relatrio de Acompanhamento do Projeto"
(conforme GCf01)
* Registrar informaes no arquivo "Relatrio de Acompanhamento do
Projeto" referentes ao acionamento do "Plano de Contingncia"

Atividade N08. Controlar custos despendidos na fase de negociao
Gerente de Projeto
Recursos

"Plano de Ao" a quantidade de atividades realizadas de fato.
referentes execuo de todas as atividades dessa fase.

Atividade N09. Conduzir reviso do milestone: Contrato

Gerente de Projeto
fase.
Recursos
Entradas e1) Plano de Garantia da Qualidade

e2) Produto de Trabalho: Contrato
e3) Relatrio sobre Garantia da Qualidade

FIGURA A3.23 VISO GRFICA FASE: ELABORAO

QUADRO A3.23.1 DETALHAMENTO DA ATIVIDADE E01

Atividade E01. Detalhar requisitos
Responsveis Engenheiro de Requisitos
Equipe de Desenvolvimento
Descrio Essa atividade tem o objetivo de detalhar os requisitos j obtidos, ao ponto
de ser mais til aos programadores.
Recursos - Ferramenta de Modelagem de Dados (ex: Dia, ArgoUML, ERWIN, Rational

Rose)
- Ferramenta de prototipao
e2) Projeto IHM
e3) Cronograma
Sadas s1) Documento de Requisitos
s2) Projeto IHM
s3) Modelo de Negcio
Tarefas No caso de j ter sido realizada a atividade "E02. Verificar e validar os
* Fazer as alteraes no "Documento de Requisitos", caso necessrio
* Fazer as alteraes no "Modelo de Negcio", caso necessrio
* Fazer as alteraes no "Projeto IHM", caso necessrio
* Descrever a soluo adotada no item 2 do "Relatrio de Anlise dos Requisitos"
Em outros casos:
- Para cada incremento a ser criado no ciclo de desenvolvimento, definido
no "Cronograma:
* Se necessrio, detalhar/atualizar o "Modelo de Negcio"
* Detalhar/Atualizar os requisitos funcionais do item 2.2 do "Documento de
Requisitos" e registrar no item 3.4 deste documento
* Elaborar/Atualizar o Modelo Conceitual e registr-lo no item 3.4 do "Documento
de Requisitos"
* Detalhar/Atualizar os requisitos de interface externa e outros requisitos no
funcionais (tais como requisitos de documentao, de manuteno) do captulo 2 do
Documento de Requisitos e registrar no captulo 3 deste documento
* Elaborar/Atualizar o Projeto IHM
- Caso o perfil dos usurios no tenha sido definido na fase de concepo, criar
Projeto IHM (conforme GCf01), obter perfil dos usurios e registrar no "Projeto IHM"
- A partir do perfil dos usurios, definir os princpios gerais do projeto (com base
em critrios ergonmicos)
- Definir/Atualizar o padro de telas no arquivo "Projeto IHM"
- Definir/Atualizar o mapa de navegao no arquivo "Projeto IHM"
- Criar/Atualizar a matriz de rastreabilidade entre requisitos do cliente e do
produto no Documento de Requisitos
- Criar/Atualizar a matriz de rastreabilidade entre requisitos funcionais e no
funcionais do produto no Documento de Requisitos

Atividade E02. Verificar e Validar os requisitos
Responsveis Equipe de Teste

Cliente
Descrio Essa atividade tem por objetivo a realizao da verificao dos requisitos e,
posteriormente, da validao dos mesmos junto ao cliente.
Recursos

e2) Checklist de Requisitos
e4) Projeto IHM
Sadas s1) Relatrio de Anlise dos Requisitos
Tarefas - Realizar peer review (uma das pessoas no deve ter participado do
desenvolvimento do Documento de requisitos)
* Analisar os requisitos a partir do "Documento de Requisitos", "Modelo de
Negcio" e "Projeto IHM" e, se for o caso, do "Relatrio de Anlise dos
Requisitos" para ver se h conflitos entre as solicitaes dos stakeholders,
documentando tais conflitos no "Relatrio de Anlise dos Requisitos"
(criar/atualizar "Relatrio de Anlise dos Requisitos", conforme GCf01)
* Para dar subsdio ao peer review, pode ser utilizado um checklist (vide
"Checklist de Requisitos")
- Realizar reunies com o cliente para validar os requisitos (averiguar se o
que est descrito est de acordo com as necessidades do cliente)
* Registrar eventuais conflitos no "Relatrio de Anlise dos Requisitos"

Atividade E03. Definir soluo de projeto

Descrio Essa atividade tem o objetivo de elaborar uma soluo de projeto com base
na arquitetura de software estabelecida.
Recursos - Ferramenta de Modelagem de Software (ex: ArgoUML, Dia, Rational Rose,

JUDE)
- Ferramenta de Modelagem de Dados (ex: ERWIN)
Entradas e1) Arquitetura do Software
e3) Cronograma
Sadas s1) Arquitetura do Software
s3) Modelo de Design
Tarefas - Confirmar a arquitetura do software projetada na fase de concepo
* Caso seja necessrio, podem ser realizadas modificaes na
"Arquitetura do Software"
- Para cada incremento a ser criado no ciclo de desenvolvimento, definido
no "Cronograma"
* Criar/Atualizar "Modelo de Design" (conforme GCf01)
- Elaborar o Modelo Lgico do Sistema com base no Documento de
Requisitos (T)
- Criar o modelo fsico de dados correspondente ao Modelo de Dados
(parte do modelo lgico do sistema)
- Criar/Atualizar a matriz de rastreabilidade entre requisitos do produto
do Documento de Requisitos e componentes do Modelo de Design e
registrar no "Documento de Requisitos"

Atividade E04. Detalhar o cronograma
Gerente de Projeto
Descrio Essa atividade tem como objetivo o detalhamento do cronograma, por parte
dos programadores. Assim, cada um deles ser responsvel por gerenciar
suas tarefas, respeitando o prazo a ele estabelecido no cronograma.
Recursos
Sadas s1) Controle de tarefas
Tarefas - Para cada incremento a ser criado no ciclo de desenvolvimento, definido
no "Cronograma"
* Definir/Atualizar as tarefas a serem realizadas para atender (s)
atividade(s) estabelecida(s) no "Cronograma"
* Cada programador deve criar/atualizar o arquivo "Controle de Tarefas"
(conforme GCf01), registrar suas tarefas em uma "Lista de Tarefas" e ser
responsvel por controlar suas tarefas diariamente

Atividade E05. Definir tcnicas e critrios para V&V
Equipe de Teste
Gerente de Projeto
Descrio Essa atividade tem o objetivo de definir quais as tcnicas e critrios de
verificao e validao sero utilizados para avaliar os componentes a
serem construdos.
Recursos
Entradas e1) Plano de Projeto
e2) Cronograma
e3) Biblioteca de Casos de Teste Padro
e5) Modelo de Design
e6) Arquitetura do Software
Sadas s1) Planilha de Teste
s3) Cronograma
QUADRO A3.23.5 DETALHAMENTO DA ATIVIDADE E05 (CONT.)

Tarefas - Considerar o tempo estimado no Cronograma (WBS) para elaborar os
casos de teste
- Planejar/Atualizar Teste de Unidade
* Definir os critrios de teste correspondentes s tcnicas de teste a serem
utilizados e registrar no item "Plano de Teste" do "Plano de Projeto". Por
exemplo: critrios particionamento de classes em equivalncia e anlise do
valor limite da categoria de tcnicas funcionais; critrios Todos-Arcos da
tcnica estrutural; critrio Anlise de Mutantes da categoria de tcnicas
baseadas em erros.
* Estabelecer os casos de teste a serem executados considerando cada
um dos critrios definidos, com base na Arquitetura do Software, Modelo de
Design e Documento de Requisitos. Para auxiliar nessa tarefa, pode-se
recorrer biblioteca de casos de teste padro da empresa (caso exista).
Criar/Atualizar arquivo "Planilha de Teste" (conforme GCf01) e registrar os
casos de teste a serem executados na planilha "Casos de Teste de
Unidade".
- Planejar/Atualizar Teste de Integrao
* Definir o ambiente para a integrao e teste. Esse ambiente pode incluir
o reuso de recursos organizacionais existentes, mas pode ser necessria a
aquisio de equipamentos (nesse caso, redirecionar para as atividades do
processo de apoio "Aquisio")
* Definir a estratgia de integrao (pode ser: top-down ou botton-up),
definir os critrios de teste a serem utilizados e e registr-los no item "Plano
de Teste" do "Plano de Projeto"
* Estabelecer os casos de teste, de acordo com a Arquitetura do Software,
Modelo de Design e Documento de Requisitos. Para auxiliar essa tarefa
pode-se recorrer biblioteca de casos de teste padro da empresa (caso
exista). Preencher na planilha "Casos de Teste de Integrao" no arquivo
"Planilha de Teste" a lista de casos de teste a serem executados.
- Detalhar o "Cronograma" estabelecendo o tempo de execuo dos casos
de testes
- Planejar/Atualizar Teste de Validao
* Definir o tempo mximo para fazer o teste de validao, com base no
Cronograma, e registrar no item "Plano de Teste" do "Plano de Projeto"
* Estabelecer os casos de teste advindos da empresa desenvolvedora e
do cliente, com base nos critrios de avaliao definidos no "Documento de
Requisitos". Preencher na planilha "Casos de teste de validao" no arquivo
"Planilha de Teste" a lista de casos de teste a serem executados.

Atividade E06. Monitorar e controlar o projeto
Descrio Essa atividade tem como objetivo o monitoramento e controle do projeto.

Primavera)

e2) Relatrio de Acompanhamento de Projeto
e4) Cronograma
Sadas s1) Relatrio de Acompanhamento de Projeto
s3) Cronograma
Tarefas - Em qualquer iterao e ciclo de desenvolvimento:
* Inserir a data de trmino da fase do projeto na planilha
"Acompanhamento de Projetos" do arquivo "Controle de Projetos", replicar a
linha do projeto e inserir a nova fase com sua data de incio
* Inserir na planilha "Acompanhamento de Projetos" do arquivo "Controle
de Projetos" a quantidade de horas trabalhadas de cada um dos
colaboradores nessa fase.
* Inserir no "Cronograma" a quantidade de horas trabalhadas de cada um
dos colaboradores nessa fase.
* Verificar no "Cronograma" o andamento das atividades executadas em
relao s atividades planejadas
- Identificar e gerenciar dependncias em relao s datas planejadas
- Identificar compromissos que no foram satisfeitos
- Identificar a ocorrncia de algum risco levantado no "Plano de
Projeto" e, nesse caso, executar o "Plano de Contingncia" documentado no
"Plano de Projeto"
- Criar/Atualizar o arquivo "Relatrio de Acompanhamento de Projeto"
(conforme GCf01) e registrar a reviso de andamento do projeto nesse
relatrio
* Planejar e executar aes corretivas, caso necessrio, e registr-las no
"Relatrio de Acompanhamento de Projeto"

Atividade E07. Monitorar e Controlar questes financeiras
Equipe de Finanas
Descrio Essa atividade tem como objetivo o monitoramento e controle de todas as
questes financeiras referentes ao projeto.
Recursos
e3) Fluxo de caixa
s2) Cobrana
s3) Fluxo de Caixa
Tarefas - Dar baixa nas duplicatas pagas, na aba "Duplicatas" do arquivo "Controle
de Projetos"
- Confrontar relatrio de duplicatas pagas com emitidas e cobrar os clientes
que esto com suas duplicatas vencidas
- Relatar equipe de finanas a respeito do cliente inadimplente
- Analisar "Relatrio de Viabilidade do Projeto"
* Inserir no "Fluxo de caixa" mensal os recebimentos
* Confrontar o "Relatrio de viabilidade do Projeto" com o "Fluxo de caixa"
mensal
* Tomar as decises cabveis
* Atualizar "Fluxo de caixa"

Atividade E08. Conduzir reviso do milestone: Arquitetura do Software

Gerente de Projeto
fase.
Recursos

e2) Produto de Trabalho: Arquitetura do Software
e3) Relatrio sobre Garantia de Qualidade
Sadas s1) Relatrio sobre Garantia de Qualidade

FIGURA A3.24 VISO GRFICA FASE: CONSTRUO

QUADRO A3.24.1 DETALHAMENTO DA ATIVIDADE CT01

Atividade Ct01. Codificar componentes
Descrio Essa atividade tem por objetivo a codificao das partes que compem o
projeto em uma determinada linguagem de programao.
Recursos Linguagem e Ambiente de Programao
Entradas e1) Arquitetura do Software

e2) Modelo de Design
e3) Projeto IHM
e4) Controle de Tarefas
e5) Arquivo de Cdigo
e6) Planilha de Teste
Sadas s1) Arquivo de Cdigo
s2) Controle de Tarefas
Tarefas - Para cada verso planejada no ciclo de desenvolvimento:
* Criar/Atualizar "Arquivo de Cdigo" (conforme GCf01), com base nos
artefatos: "Arquitetura do Software", "Modelo de Design", "Projeto IHM" e, se
for o caso de ajustar o cdigo, usar como subsdio os casos de teste
marcados na "Planilha de Teste"
* Realizar as tarefas de codificao, seguindo regras de padronizao de
codificao da empresa para que o cdigo fique auto-documentado.
* Registrar trabalho realizado e quantidade de tempo gasto no arquivo
"Controle de Tarefas" para informaes sobre o andamento de suas tarefas
a serem comunicadas ao gerente de projeto, quando solicitado.

Atividade Ct02. Realizar teste de unidade

Equipe de Teste
Descrio Essa atividade tem por objetivo executar os casos de teste de unidade
definidos no plano de teste.
Recursos - Ferramentas de Teste (ex: TestLink, Testitool, PHP Coverage, FunkLoad)

- Linguagem e Ambiente de Programao
s2) Arquivo de Cdigo
QUADRO A3.24.2 DETALHAMENTO DA ATIVIDADE CT02 (CONT.)

Tarefas - Realizar o Teste de Unidade planejado e registrado no "Plano de Projeto"
das unidades codificadas
* Executar os casos de teste de unidade definidos na planilha "Casos de
Teste de Unidade" do arquivo "Planilha de Teste"
* Registrar resultados obtidos na na planilha "Casos de Teste de
Unidade" do arquivo "Planilha de Teste"
* Quando necessrio, realizar novamente os casos de teste (teste de
regresso), ou ainda, definir novos casos de teste e registrar na planilha
"Casos de Teste de Unidade" do arquivo "Planilha de Teste" para testar as
alteraes realizadas no "Arquivo de Cdigo"

Atividade Ct03. Analisar os resultados de teste

Equipe de Teste
Descrio Essa atividade tem por objetivo analisar os resultados de teste.
Recursos
Entradas e1) Arquivo de Cdigo

Tarefas - Confrontar os resultados obtidos com os resultados esperados que se

encontram na "Planilha de Teste" e marcar na planilha quais casos de teste
detectaram problemas
- Fazer os ajustes necessrios no "Arquivo de Cdigo", acessando a
atividade "Ct01. Codificar componentes"

Atividade Ct04. Integrar e testar integrao entre componentes

Equipe de Teste
Descrio Essa atividade tem por objetivo integrar os componentes e executar os
casos de teste de integrao definidos no plano de teste.

s2) Arquivo de Cdigo
Tarefas - Realizar integrao dos componentes, de acordo com a estratgia definida
no "Plano de Projeto"
* Averiguar se os componentes esto prontos para serem integrados
(considerando no s os componentes de software, mas tambm de
hardware se for o caso)
- Realizar o Teste de Integrao, conforme os componentes/mdulos so
integrados
* Executar os casos de teste de integrao definidos na planilha "Casos de
Teste de Integrao" do arquivo "Planilha de Teste", verificando a
corretitude das interfaces que conectam os componentes
* Registrar resultados obtidos na planilha "Casos de Teste de Integrao"
do arquivo "Planilha de Teste"

Atividade Ct05. Monitorar e controlar o projeto

Primavera)

e4) Cronograma
s3) Cronograma
QUADRO A3.24.5 DETALHAMENTO DA ATIVIDADE CT05 (CONT.)

- Identificar a ocorrncia de algum risco levantado no "Plano de Projeto" e,
nesse caso, executar o "Plano de Contingncia" documentado no "Plano de Projeto"
(conforme GCf01) e registrar a reviso de andamento do projeto nesse relatrio

Atividade Ct06. Monitorar e Controlar questes financeiras
Equipe de Finanas
Recursos
e3) Fluxo de caixa
s2) Cobrana
s3) Fluxo de Caixa
de Projetos"
mensal

Atividade Ct07. Conduzir reviso do milestone: Capacidade Operacional
fase. determinado se o produto est pronto para ser distribudo em um
ambiente de teste beta.
Recursos

e2) Produto de Trabalho: Arquivo de Cdigo (Capacidade Operacional do
Produto)

FIGURA A3.25 VISO GRFICA FASE: TRANSIO

QUADRO A3.25.1 DETALHAMENTO DA ATIVIDADE T01

Atividade T01. Validar a verso do produto

Equipe de Teste
Descrio Essa atividade tem por objetivo executar os casos de teste de validao
definidos no plano de teste na verso do produto.
Recursos

Tarefas - Realizar o Teste de Validao da verso do produto, simulando o ambiente

do cliente
* Executar os casos de teste de validao definidos na planilha "Casos de
Teste de Validao" do arquivo "Planilha de Teste"
* Registrar resultados obtidos na planilha "Casos de Teste de Validao"
do arquivo "Planilha de Teste"

Atividade T02. Analisar e Ajustar a verso do produto
Equipe de Teste
Descrio Essa atividade tem por objetivo analisar os resultados de teste realizar as
modificaes necessrias na verso do produto validado.
Recursos Linguagem e Ambiente de Programao

Sadas s1) Arquivo de Cdigo
s2) Planilha de Teste
Tarefas - Confrontar os resultados obtidos com os resultados esperados que se
encontram na "Planilha de Teste"
- Confrontar os resultados obtidos em relao aos critrios de validao
definidos "Documento de Requisitos"
- Marcar na "Planilha de Teste" os critrios de validao que no foram
atendidos
- Fazer os ajustes necessrios no "Arquivo de Cdigo"
- Validar o "Arquivo de Cdigo" modificado, acessando a atividade "T01.
Validar a verso do produto"

Atividade T03. Realizar testes de regresso

Equipe de Teste
Descrio Essa atividade tem por objetivo executar novamente os casos de teste de
unidade e de integrao na verso ajustada do produto.

Tarefas - Realizar, novamente, o Teste de Unidade, o Teste de Integrao e o Teste

de Validao planejados e registrados no "Plano de Projeto" das unidades
codificadas anteriormente
* Executar os casos de teste de unidade e os casos de teste de integrao
definidos nas planilhas "Casos de Teste de Unidade", "Casos de Teste de
Integrao" e "Casos de Teste de Validao" do arquivo "Planilha de Teste"
* Registrar resultados obtidos nas respectivas planilhas
- Realizar os ajustes necessrios na verso do produto, se for o caso,
acessando a atividade "T02. Ajustar a verso do produto"

Atividade T04. Entregar/Instalar a verso do produto
Equipe de Suporte
Equipe de Vendas
Descrio Essa atividade tem por objetivo a entrega e instalao (se for o caso) da
verso do produto para uso no ambiente do cliente.
Recursos

e2) Manual do Usurio
Sadas s1) Verso do Produto
s2) Documento de Aceite
s3) Manual do Usurio
s4) Arquivo para Instalao
Tarefas - Para documentar um release, deve-se:
* registrar as verses especficas dos componentes de cdigo-fonte
usados para criar o cdigo executvel
* manter cpias dos cdigos-fonte, do cdigo-executvel, de todos os
arquivos de dados e de configurao
* registrar as verses do sistema operacional, as bibliotecas, os
compiladores e outras ferramentas usadas para construir o software
- Gerar a verso executvel do produto, a partir do "Arquivo de Cdigo"
- Programar a implantao
- Criar/atualizar o "Arquivo para Instalao" (conforme GCf01)
- Realizar programao de implantao
- Treinar o cliente
- Criar/Atualizar o "Manual do Usurio" (conforme GCf01)
- Criar/Atualizar arquivo "Documento de Aceite" (conforme GCf01) e coletar
assinatura para confirmar que a verso foi entregue ao cliente. Anexar
pasta fsica.
* Quando se tratar da verso final do sistema, o Manual do Usurio ser
entregue.

Atividade T05. Monitorar e controlar o projeto

Primavera)

e4) Cronograma
s3) Cronograma
- Identificar a ocorrncia de algum risco levantado no "Plano de
Projeto" e, nesse caso, executar o "Plano de Contingncia" documentado no
"Plano de Projeto"
(conforme GCf01) e registrar a reviso de andamento do projeto nesse
relatrio

Atividade T06. Monitorar e Controlar questes financeiras

Equipe de Finanas
Recursos

e3) Fluxo de caixa
s2) Cobrana
s3) Fluxo de Caixa
de Projetos"
mensal

Atividade T07. Conduzir reviso do milestone: Entrega do Produto

Gerente de Projeto
fase. decidido se os objetivos do projeto foram alcanados, e se deve ser
iniciado um outro ciclo de desenvolvimento (passagem pelas 4 fases; cada
passagem produz uma verso do software; tipicamente, os ciclos tem as
fases de concepo e elaborao mais curtas, uma vez que a definio e
arquitetura do produto so determinados nos ciclos anteriores; excees
ocorrem qdo necessria a redefinio do produto ou arquitetura).
Recursos

e2) Produto de Trabalho: Entrega do Produto

Apndice 4 Modelo ProcSoftVD (Templates) P g i n a | 213
Apndice 4 Modelo ProcSoftVD (Templates)
Os documentos A4.1 a A4.34, apresentados a seguir, so referentes aos
templates dos artefatos de entrada e sada utilizados/criados nas/pelas atividades do
modelo ProcSoftVD.
A4.1 - CHECKLIST
(Material elaborado pela Profa. Sandra Fabbri UFSCAR (Universidade Federal
de So Carlos.
Obtido por meio da URL: http://www2.dc.ufscar.br/~junia/Checklist.pdf em
30/09/2008)
Checklist uma tcnica usada durante revises tcnicas formais (FTR), atividade que
garante a qualidade do software. Seus objetivos so:
- Descobrir erros de funo, de lgica ou de implementao para qualquer
representao do software.
- Verificar que o software em questo atende aos requisitos especificados.
- Garantir que o software foi representado de acordo com padres pr-definidos.
- Garantir que o software seja desenvolvido de maneira uniforme.
- Desenvolver projetos mais gerenciveis.
O checklist ajuda o gerente a coordenar a reunio de FTR e ajuda cada revisor a focar
nas caractersticas importantes. Os checklists devem ser aplicados a documentos de
analise, projeto, codificao, e teste, focando os aspectos e defeitos comuns da fase
correspondente. Por exemplo, as questes no checklist para a fase de requisitos
devem apontar os problemas e defeitos que podem aparecer nos documentos de
especificao de requisitos e correlatos.
Entrada: um conjunto de requisitos do novo sistema

Sada: uma lista de defeitos que devem ser corrigidos no novo sistema
Para o documento de requisitos, devem ser aplicadas as seguintes categorias de
perguntas:
Questes Gerais:
1. Os objetivos do sistema foram definidos?
2. Os requisitos esto claros e sem ambigidades?
3. fornecida uma viso geral do sistema?
4. fornecida uma viso geral das formas de operao do sistema?
5. O software e hardware necessrios so especificados?
6. Se existem suposies que afetam a implementao, elas so especificadas?
7. Para cada funo, os requisitos foram especificados em termos de entrada,
processamento e sada?
8. Todas as funes, os dispositivos e as restries so mapeados nos requisitos e
vice-versa?
1. Omisso (O):
1. Funcionalidades:
1.1. As funes descritas so suficientes para atender os objetivos do sistema?
1.2. As entradas declaradas para cada funo so suficientes para executar essa
funo?
1.3. Os eventos indesejados foram considerados e as respostas necessrias a eles
so especificadas?
1.4. O estado inicial e estados especiais foram considerados? (por exemplo,
inicializao do sistema, trmino finalizao anormal, etc)
2. Desempenho:
2.1. O sistema pode ser testado, demonstrado, analisado ou inspecionado para
mostrar que satisfaz os requisitos?
2.2. Os tipos de dados, unidades, limites e resoluo foram especificados?
2.3. A freqncia e volume de entrada e sada foram especificados para cada funo
foram especificadas?
3. Interface:
3.1. As entradas e sadas para todas as interfaces so suficientes?
3.2. Foram especificados os requisitos de interface entre hardware, software pessoas
e procedimentos?
4. Ambiente:
4.1. Foram especificadas de forma apropriada as funcionalidades de interao entre
hardware, software com o sistema?
2. Fato incorreto (FI):
2.1. Todas as funes descritas so necessrias para atingir os objetivos do sistema?

2.2. Todas as entradas da funo, para cada funo, so necessrias para executar a
funo?
2.3. As entradas e sadas para todas as interfaces so necessrias?
2.4. As sadas produzidas por uma funo, para cada funo, so usadas por outra
funo ou transferidas para a interface externa?
3. Inconsistncia (I):
3.1. Os requisitos so consistentes entre si?

3.2. Os requisitos funcionais so consistentes com o sistema operacional?
4. Ambigidade (A):
4.1. Cada requisito definido de tal forma que seja discreto, sem ambigidade, e
testvel?
4.2. Todas as transies de modo so especificadas de forma determinstica?
5. Informaes estranhas (IE):
5.1. As funes especificadas so coerentes com o sistema e com os objetivos a

serem alcanados?
6. Miscelnea (M)
A4.2 ARQUITETURA DO SOFTWARE
ID documento: Data: / / Verso :

Responsvel pelo documento:
ID Projeto:
HISTRICO DE REVISES
Data de Descrio da(s) Mudana(s) Autor Verso do ID.

criao/ Ocorrida(s) Documento Solicitao
atualizao de
Mudana
1 Fatores Arquiteturais
<Aqui so colocadas as referncias relacionadas principalmente aos requisitos no
funcionais que influenciaro na escolha da arquitetura.>
2 Arquitetura Lgica
< A arquitetura lgica a organizao em larga escala das classes de software em
pacotes, subsistemas e, dependendo do estilo arquitetural, em camadas.
denominada arquitetura lgica porque no h deciso sobre como esses elementos
so implantados pelos diferentes processos do sistema operacional ou pelos
computadores fsicos em uma rede (decises essas posteriores, parte da arquitetura
de implantao).
Uma camada um agrupamento de granularidade muito grossa de classes, pacotes
ou subsistemas que tem responsabilidade coesiva sobre um tpico importante do
sistema.
Exemplo:
Mostra
dependncia
(acoplamento)
entre os
pacotes. A
seta aponta
para o pacote
dependente.
Fonte: LARMAN, C. Utilizando UML e Padres: Uma introduo anlise e ao projeto

orientados a objetos e ao desenvolvimento iterativo. Porto Alegre: Bookman, 2007.
>
3 Topologia do Sistema
< A topologia do sistema mostra a implantao de elementos de software arquitetura
do software e a comunicao (geralmente em uma rede) entre elementos fsicos.
A topologia do sistema pode ser representada por um diagrama de implantao da
UML.
O Modelo de Implantao opcional para sistemas de um nico processador ou
sistemas simples com pouca ou nenhuma distribuio de processamento.
obrigatrio para sistemas com configuraes complexas de rede ou de processador.
Um diagrama de implantao mostra a atribuio de artefatos concretos de software
(como arquivos executveis) a ns computacionais (algo com servios de
processamento).
Exemplo:
Fonte: RUP Modelo pertencente ferramenta CASE Rational Rose
Outro exemplo:
Fonte: Modelagem disponvel (csps_design_v1_0.mdl) na ferramenta Rational Rose
>
4 Decises Arquiteturais
<Descreve as decises quanto arquitetura e as razes tcnicas que motivaram a
tomada dessas decises.>
<
Referncia Bibliogrfica: CLEMENTS, P.; BACHMANN, F.; BASS, L.; GARLAN, D.;
IVERS, J.; LITTLE, R.; NORD, R.; STAFFORD, J. Documenting Software
Architectures. Views and Beyond. SEI Series in Software Engineering. Addison
Wesley, 2003.
A arquitetura de software um conjunto de decises significativas sobre a
organizao de um sistema, a seleo dos elementos estruturais e suas interfaces que
compem o sistema, junto ao seu comportamento especificado nas colaboraes
entre esses elementos, a composio desses elementos estruturais e
comportamentais em subsistemas mais abrangentes, e o estilo arquitetural que guia

essa organizao esses elementos e suas interfaces, suas colaboraes e sua
composio (Booch et al., 1999).
Um tipo de viso define os tipos de elementos e os tipos de relacionamentos
usados para descrever a arquitetura do sistema, a partir de determinada perspectiva.
Ao projetar um sistema, o arquiteto deve considerar trs perspectivas do
sistema:
1. Como o sistema estruturado como um conjunto de unidades de
implementao (tipo de viso mdulo);
2. Como o sistema estruturado como um conjunto de elementos que tem
comportamento e interaes em tempo de execuo (tipo de viso
componente-e-conector);
3. Como o sistema relacionado s outras estruturas, exceto software, no seu
ambiente (tipo de viso alocao).
Cada tipo de viso tem formas de ocorrer, denominadas estilos arquiteturais.
Um estilo arquitetural uma especializao de tipos de elementos e relao, com um
conjunto de restries sobre como eles podem ser usados. Dessa forma, esses estilos
refletem padres de interao, independente do sistema em questo.
Nem todo sistema construdo exclusivamente a partir de um nico estilo.
Normalmente, um sistema pode atender a vrios estilos combinados.
Um mdulo uma unidade de cdigo que implementa um conjunto de
responsabilidades. Um mdulo pode ser uma classe, uma coleo de classes, uma
camada ou alguma decomposio da unidade de cdigo. Todo mdulo tem uma
coleo de propriedades atribudas a ele. Essas propriedades expressam informaes
importantes e restries associadas ao mdulo. Exemplos de propriedades:
responsabilidades, visibilidade de informao e autor. Exemplos de relaes entre os
mdulos: parte de (is part of) ou herda de (inherits from).
Estilos arquiteturais do tipo de viso mdulo:
Decomposio: representa a decomposio do cdigo em sistemas,
subsistemas e assim por diante. Este estilo representa uma viso top-down
do sistema.
Uso: indica relacionamentos de dependncia funcional entre os mdulos.
Esse estilo depende da relao uses, que uma forma especial da relao
depends-on. Esse estilo mostra aos desenvolvedores quais outros mdulos
devem existir para uma determinada parte do sistema executar de forma
correta.
Generalizao: indica relacionamentos de especializao entre os mdulos,
como em uma hierarquia de classes. Esse estilo normalmente utilizado
para expressar design orientado a objetos.
Em camadas: organiza o cdigo em camadas disjuntas, de acordo com
regras predefinidas. Por exemplo, regras podem estipular que somente o
cdigo da prxima camada mais abaixo pode ser usado. Indica a relao
permisso-para-uso em uma parte restrita entre os mdulos.
Estilos Arquiteturais do tipo de viso componente-e-conector (C&C)

expressam comportamento em tempo real. Eles so descritos em termos de
componentes e conectores. Um componente uma das principais unidades de
processamento da execuo do sistema; um conector um mecanismo de interao
para os componentes. Objetos, processos ou colees de objetos podem ser
componentes. Conectores incluem pipes, repositrios e sockets. Middleware pode ser
visualizado como um conector entre os componentes que usam o middleware.
Componentes e conectores podem ser decompostos em outros componentes e
conectores. Mais genericamente, vises arquiteturais em tempo de execuo de
sistemas de objetos, tais como mostrado em diagramas de colaborao, so exemplos

desse estilo de C&C. Alguns estilos de componentes-e-conectores so:
Pipe-and-filter: aquele no qual o padro de interao caracterizado
pelas transformaes sucessivas de dados. Dados chegam em um filtro,
so transformados e passados pelo pipe (canal) para o prximo filtro no
pipeline (canalizao). Exemplos de sistemas desse tipo so sistemas de
processamento de sinal e pipes UNIX.
Shared-data: centraliza na reteno de dados persistentes. Vrios
elementos acessam os dados persistentes, os quais so retidos em pelo
menos um repositrio. Sistemas de base de dados e baseados em
conhecimento so exemplos de estilos de dados compartilhados.
Publish-subscribe: caracterizado pelos componentes que interagem por
eventos anunciados. Componentes podem subscrever para um conjunto
de eventos. Esse estilo comumente usado para dissociar produtores e
consumidores de mensagens.
Client-server: mostra componentes interagindo por meio de servios
solicitados de outros componentes. A essncia desse estilo que a
comunicao tipicamente emparelhada. Uma solicitao de servio de
um cliente emparelhada com a proviso daquele servio. Servidores
fornecem um conjunto de servios por meio de uma ou mais interfaces, e
clientes usam zero ou mais servios fornecidos pelos servidores no
sistema. Pode haver um servidor central ou vrios distribudos.
Peer-to-peer: caracterizado pela interao de pares de componentes
trocando servios. uma espcie de interao solicita/responde sem a
assimetria encontrada no estilo cliente-servidor. Exemplos de sistemas
peer-to-peer incluem arquiteturas que so baseadas em infra-estrutura de
objetos distribudos, tais como CORBA, COM+, Java RMI (remote method
invocation).
Communicating-processes: caracterizado pela interao de
componentes executados concorrentemente atravs de vrios
mecanismos de conexo. Exemplos desses mecanismos de conexo so:
sincronizao, passagem de mensagens, troca de dados, etc. Os
processos de comunicao so comuns na maioria dos grandes sistemas
e necessrio em todos os sistemas distribudos.
Os estilos do tipo de viso alocao descrevem o mapeamento das unidades

de software com os elementos do ambiente (o hardware, sistema de arquivos ou
equipe de desenvolvimento). So eles:
Implantao: mapeia os processos para os elementos de hardware: ns
de processamento, canais de comunicao, repositrios de memria e de
dados. Esse estilo, usado para descrever como os processos so
alocados para o hardware e o trfico de mensagens resultante, usado
para anlise de desempenho, segurana e confiabilidade e fornece uma
base para estimar o custo de implantao de um nico n.
Implementao: mapeia mdulos de um tipo de viso mdulos para uma
infra-estrutura de desenvolvimento. Elementos do estilo de implementao
so mdulos e entidades de configurao. Esse estilo usado para
descrever como mdulos so mapeados para entidades dentro do sistema
de gesto de configurao, tanto quanto gerenciar verses e coordenar o
desenvolvimento multi-equipes.
Designao de trabalho: mapeia mdulos de um tipo de viso mdulos
para equipes de desenvolvimento. Elementos desse estilo so mdulos e
equipes de desenvolvimento. O estilo usado para descrever quais
equipes so responsveis por quais elementos da WBS, tanto quanto

para informar cronograma e estimativas de oramento.
>
<
Referncia Bibliogrfica: SOMERVILLE, I. Engenharia de Software. 8 edio. So
Paulo: Addison Wesley, 2003.
A arquitetura afeta o desempenho, proteo, disponibilidade e facilidade de
manuteno de um sistema. O estilo e a estrutura escolhidos para uma aplicao
podem, portanto, depender dos requisitos no funcionais do sistema. Por exemplo:
Quanto ao desempenho: se o desempenho for um requisito crtico, a arquitetura
deve ser projetada para localizar operaes crticas dentro de alguns subsistemas,
com to pouca comunicao quanto possvel entre eles. Isso pode significar o uso
de componentes de alta granularidade em detrimento dos de baixa granularidade
para reduzir as comunicaes entre os componentes.
Quanto proteo: se a proteo for um requisito crtico, uma estrutura em
camadas para a arquitetura deve ser usada, com os itens mais crticos protegidos
por camadas mais internas e com alto nvel de validao de proteo aplicado a
essas camadas.
Quanto segurana: se a segurana for um requisito crtico, a arquitetura deve ser
projetada de modo que as operaes relacionadas segurana estejam todas
localizadas em um nico subsistema ou em um pequeno nmero de subsistemas.
Isso reduz os custos e os problemas de validao de segurana e torna possvel
fornecer esse servio a sistemas de proteo relacionados.
Quanto disponibilidade: se a disponibilidade for um requisito crtico, a arquitetura
deve ser projetada para incluir componentes redundantes e, assim que possvel,
substituir e atualizar componentes sem parar o sistema.
Quanto facilidade de manuteno: se a facilidade de manuteno for um
requisito crtico, a arquitetura de sistema deve ser projetada usando componentes
de baixa granularidade e autocontidos que possam ser prontamente mudados. Os
criadores de dados devem ser separados dos clientes, e estruturas de dados
compartilhadas devem ser evitadas.
A arquitetura de um sistema pode ser baseada em um modelo ou estilo de
arquitetura especfico. Entretanto, a arquitetura da maioria dos grandes sistemas no
est de acordo com um nico estilo. Partes diferentes do sistema podem ser
projetadas usando estilos diferentes de arquitetura. Por exemplo, um sistema pode ser
organizado com base em um repositrio de dados compartilhados, mas pode criar
camadas com base nisso para apresentar uma viso mais abstrata dos dados.
>
A4.3 CONTRATO
< Este contrato pode ser utilizado em casos de licena de software, incluindo o
desenvolvimento, implantao e treinamento do sistema em questo e a entrega da
documentao e programas fonte do sistema ao CONTRATANTE. Este template de
contrato uma adaptao de dois outros contratos: um cedido por Rogrio Marcus
Alessi (Secretrio Municipal de Tecnologia da Informao da Prefeitura Municipal de
Presidente Prudente, de 2004 a 2008) e outro disponibilizado na URL:
< http://www.ramosdainformatica.com.br/files/Clientes/modelo_contrato_desenvolvimento.pdf>
CONTRATO DE LICENA DE SOFTWARE
Pelo presente instrumento, de um lado <empresa>, inscrita no CNPJ sob

nmero xxxxxxx, sito <endereo, nr>, cidade de xxxxxxx, Estado de xxxxx, neste ato
representada pelo(a) Sr(a). xxxx, CPF xxxxxxxxx, doravante denominada
CONTRATANTE, e de outro Sr(a). xxxxxxx, sito <endereo, nr>, cidade de xxxxxxx,
Estado de xxxxx, CPF xxxxxxx, denominado CONTRATADO, tm entre si justo e
contratado o que segue:
1. Objeto
1.1 O presente contrato tem como objeto o desenvolvimento, implantao e
treinamento do <nome do sistema>, doravante denominado simplesmente
Sistema, por parte da CONTRATADA, para uso especfico da CONTRATANTE,
conforme proposta tcnica no Anexo 1, parte integrante deste instrumento.
2. Aspectos Tcnicos
2.1 O prazo para desenvolvimento do sistema obedecer ao cronograma no
Apndice 1, parte integrante deste instrumento.
2.2 O desenvolvimento e acompanhamento do sistema dar-se- conforme
estabelecido no cronograma citado no item 2.1, abrangendo reunies e
avaliaes dos usurios da CONTRATANTE para desenvolvimento do
Sistema.
2.3 <deixar claro sobre o suporte ao sistema, se est incluso no contrato ou no>
2.4 <deixar claro sobre as condies para instalao e uso do sistema>
3. Aspectos Financeiros
3.1 Pelo objeto proposto, obriga a CONTRATANTE a pagar CONTRATADA a
importncia de R$ xxxxxx (valor por extenso), de acordo com o cronograma de
pagamentos no Apndice 2, parte integrante deste instrumento.
3.2 Os custos adicionais com visitas, transporte e estadia, desde que previamente
autorizados, sero reembolsados da seguinte forma: xxxxxxxxxxx.
3.3 No ser cobrado da CONTRATANTE qualquer custo adicional referente a

correes e ajustes efetuados no Sistema, salvo se decorrentes de
implementaes adicionais especficas e devidamente aprovadas por escrito
pela CONTRATANTE, como: acrscimos de relatrios, mdulos ou
configuraes solicitadas pela CONTRATANTE CONTRATADA.
3.4 Qualquer uma das partes poder rescindir o presente instrumento, mediante
prvia comunicao outra parte, por escrito, com antecedncia mnima de xx
dias, nas seguintes condies: <especificar multa e condies de pagamento
dos servios at ento executados e outras condies, como por exemplo, se a
CONTRATADA poder ficar ou no com o Sistema>.
4. Aspectos Legais
4.1 O Sistema possui garantia vitalcia de funcionamento nas verses e condies
(ambiente hardware/software) originalmente implantadas.
4.2 A responsabilidade da CONTRATADA restringir-se- ao Sistema, no
respondendo por problemas relacionados ao ambiente, como redes, sistemas
operacionais e hardware.
4.3 A CONTRATADA no se responsabiliza por danos decorrentes do mau uso do
sistema, alimentao errnea e/ou falta de conferncia de dados gerados, bem
como a inexistncia de cpias de segurana dos dados atualizados.
4.4 O presente instrumento no dar azo constituio de qualquer vnculo
empregatcio ou responsabilidade por parte da CONTRATANTE com relao
aos empregados da CONTRATADA a seu servio, responsabilizando-se esta
ltima pelos direitos e deveres sociais e trabalhistas de seus empregados.
4.5 Pelo presente instrumento o CONTRATANTE receber os programas fontes
aps sua regular quitao, responsabilizando-se pelo uso e guarda, nos termos
da Lei 9.609/98.
5. Controle de Alteraes
5.1 <descrever os procedimentos de mudanas e a limitao para alterao dos
requisitos.>
E por estarem assim justas e contratadas, as partes assinam o presente

contrato em xx (nr de vias por extenso) vias de igual teor e forma na presena das
testemunhas, a seguir.
Cidade, dia de ms por extenso de ano.

_________________________ ________________________
CONTRATANTE CONTRATADA
Testemunhas:
1) Ass. _________________________
Nome:
RG:
2) Ass. _________________________
Nome:
RG:
ANEXO 1 - PROPOSTA TCNICA: XXXXXXXXX
APNDICE 1 CRONOGRAMA
<inserir aqui o cronograma, a partir da WBS>
APNDICE 2 CRONOGRAMA DE PAGAMENTOS

A4.4 - DOCUMENTO DE REQUISITOS

ID Projeto:
HISTRICO DE REVISES

atualizao de Mudana
1 INTRODUO
1.1 Objetivo
Este documento tem por objetivo apresentar os requisitos que o sistema deve atender
em diferentes nveis de detalhamento. Dessa forma, serve como acordo entre as partes
envolvidas cliente e analista/desenvolvedor.
1.2 Escopo
<
Identificar o(s) produto(s) de software a ser(em) produzido(s) pelo nome.
Explicar o qu o(s) produto(s) de software far(o) e, se necessrio, o qu no far(o).
Descrever a aplicao do software a ser especificado, incluindo benefcios relevantes,
objetivos e metas.
Ser consistente com as especificaes de mais alto nvel (tal como a especificao de
requisitos do sistema), se existirem.>
1.3 Definies, Siglas e Abreviaes

<Fornecer as definies de todos os termos, acrnimos e abreviaes necessrias para
interpretar de modo apropriado a ERS. >
1.4 Referncias
<
Fornecer uma lista completa de todos os documentos referenciados na ERS.
Identificar cada documento pelo ttulo, nmero do relatrio (se aplicvel), data e
organizao que publicou.
Especificar a(s) origem(s) das referncias, ou seja, onde e/ou com quem podem ser
obtidas.>
1.5 Viso Geral

O Captulo 2 fornece uma descrio geral do produto, tendo como pblico-alvo os
clientes. Dessa forma, esse captulo uma sntese dos requisitos que o sistema dever
atender para auxiliar ao negcio do cliente. So descritos: a perspectiva e funes do produto,
as caractersticas dos usurios e os limites, suposies e dependncias que influenciem a
eficcia e eficincia do sistema.
No Captulo 3, os requisitos descritos no captulo 2 so detalhados ao ponto de serem
teis para os analistas e programadores do sistema.
2 DESCRIO GERAL DO PRODUTO

<Tem por objetivo descrever fatores gerais do produto e seus requisitos, fornecendo um
contexto para esses requisitos os quais so definidos em detalhes no captulo 3 da ERS.>
2.1 Perspectiva do Produto

<Deve ser descrito de maneira resumida, de forma textual, sem detalhamento (1/2 pgina, no
mximo, pois trata-se de uma descrio geral), pois as interfaces mencionadas nessa seo
sero detalhadas na seo 3.1 (Requisitos de Interface Externa). Segundo o padro IEEE, se o
produto a ser desenvolvido for parte de um sistema maior a ERS dever identificar quais as
interfaces existentes entre esse sistema e o produto a ser desenvolvido.
Exemplo 1:
O sistema funcionar em um PC AT atualmente disponvel na Locadora Fulano de Tal. O
sistema ter interface com leitores de cdigos de barras para simplificar o processo de alugar e
devolver uma fita, e com impressoras do tipo tal para emitir os recibos para os clientes e para a
prpria locadora. Todas as informaes relativas aos clientes, tais como: x, y, z; e informaes
histricas das locaes sero armazenadas.
O texto pode incluir (no obrigatoriamente, pois depende do caso) informaes sobre:
-Interfaces do Sistema: Normalmente um software faz parte de um sistema (sistema

administrativo) maior existente dentro de uma empresa. A ERS deve listar as interfaces do
sistema para com o produto, identificando as funcionalidades do software que iro realizar
essas interfaces.
-Interfaces do Usurio: Caractersticas lgicas das interfaces entre o produto e seus usurios,
como por exemplos: formatos de telas, aspectos de otimizao da interface com o usurio do
sistema (por ex, mensagens curtas ou longas, definir que um usurio pode utilizar o sistema
aps x horas de treinamento), padro de relatrios ou menus de consulta, acesso por nveis de
usurios, mensagens, dentre outros.
-Interfaces de Hardware: se o produto interage com dispositivos de hardware, estes devem ser
especificados (por exemplo, impressoras, scanners, relgios de ponto, catracas eletrnicas ou
outros dispositivos eletrnicos com o qual o produto ir comunicar-se).
-Interfaces de Software: especificar o uso de outros softwares necessrios (banco de dados,

sistemas operacionais, software para capturar imagem, ou outros softwares aplicativos de
mesma natureza).
-Interfaces de Comunicao: especificar tipos de comunicao necessrios para o

funcionamento do produto. Por exemplo, o software que responsvel pelo gerenciamento da
catraca precisa comunicar-se com as mesmas por meio de um par-tranado. Como, ento,
dever ser implementada essa comunicao? Isso deve ser descrito aqui sem detalhes.
-Limites de Memria: especificar os limites mnimos de memria primria e secundria.
-Operaes: rotinas de inicializao (definir nveis de acesso; processamento; backup e

restaurao do sistema).
-Requisitos para adaptao de situao: especificar situaes em que o software deve ser
adaptado antes da instalao. Por exemplo: em um sistema que necessite a conexo com a
internet. Se no momento da instalao o computador no estiver conectado, o sistema
identifica e grava os dados em um arquivo temporrio e, quando restabelecer a conexo, os
dados so recuperados deste arquivo temporrio e a instalao pode concluda. Outro exemplo
refere-se s adaptaes necessrias para a instalao do software em outra verso do S.O.
>
2.2 Funes do Produto

< Nessa seo deve ser fornecido um resumo das principais funes que o software deve
realizar. Alm disso, pode ser inserido algum diagrama, tal como Diagrama de Casos de Uso,
para mostrar a fronteira do sistema e para fornecer uma viso geral do comportamento do
sistema (para que ele usado e por quem).
Por exemplo:
O Sistema de Locadora de Vdeo deve manter os dados dos clientes, dos DVDs
comprados de fornecedores registrados e das locaes e devolues realizadas por cada um
dos clientes. Deve, tambm, permitir que o cliente faa a reserva de filmes, deve manter dados
das contas a pagar e a receber e permitir a emisso do cupom fiscal.
Diagrama de Casos de Uso
<<communicate>>
<Use Case Name>

<Actor Name>
(from <Use Case Name>)
(f rom Actors)
>
2.3 Caractersticas do Usurio
<
Descrever o nvel educacional dos usurios do sistema, bem como a sua experincia e o
conhecimento sobre informtica para que seja diagnosticada a necessidade de treinamento
especfico. Deve fornecer as razes pelas quais certos requisitos so especificados.>
2.4 Limites, Suposies e Dependncias

<
Descrever itens que limitem as opes do desenvolvedor, tais como: Normas
regulamentadoras, Limitaes do hardware, consideraes de segurana, requisitos de
confiabilidade, Linguagem de programao.
Com relao s suposies e dependncias, descrever qualquer fator que afeta os requisitos
expressos na ERS. Por exemplo: A no aquisio do ponto eletrnico far com que o sistema
no tenha o seu total desempenho, pois a entrada de dados ser feita manualmente, inserindo
somente as excees do ponto dirio, ou seja, a falta dos funcionrios.>
2.5 Requisitos Adiados

<
Identificar os requisitos, que foram levantados, mas que por alguma razo sero adiados para
verses futuras do sistema.>
3 REQUISITOS ESPECFICOS
<Essa seo deve conter todos os requisitos do software com um nvel de detalhamento
suficiente para possibilitar aos projetistas/desenvolvedores projetarem um sistema que atenda
a esses requisitos.>
3.1 Requisitos de Interface Externa

<Detalhar o que foi descrito de forma sucinta na seo 2.3 (perspectiva do produto) com
relao s interfaces externas, sem repetir informao. Esses requisitos referem-se aos
requisitos no funcionais >
3.1.1 Interfaces do Sistema

<caso o software em questo tenha que ser integrado com algum j existente>
3.1.2 Interfaces do Usurio

<Deve ser descrito como o usurio vai interagir com o sistema, sem mostrar graficamente as
telas, pois existe uma seo especfica para isso. Descrever como ser o formato padro das
telas e relatrios, quais os procedimentos a serem adotados em caso de erros, para que
servem e como sero apresentadas as mensagens do sistema para o usurio (por exemplo,
no sero exibidas mensagens em caixas de dilogo, mas atravs de um label em um
determinado local da tela. As mensagens exibidas em caixas de dilogos sero somente para
erros do sistema que s podem ser resolvidas pelo desenvolvedor).>
3.1.3 Interfaces de Software

<descrever os detalhes dos softwares necessrios para o desenvolvimento e execuo do
software em questo. Isso inclui nome, mnemnico, especificao numrica, verso e fonte>
3.1.4 Interfaces de Hardware

<Com relao interface de hardware, por exemplo, a ERS dever detalhar como ser
realizada a interface em questo. Se for um relgio de ponto, por exemplo, como ser o layout
do arquivo que ser emitido pelo equipamento ao sistema. Por exemplo: O equipamento para a
leitura do ponto dos funcionrios ser da marca XXXX, modelo YYYY, etc. O relgio ponto gera
um arquivo com a extenso txt, o qual possui a seguinte estrutura em cada uma das linhas:
CDIGO_FUNCIONRIO: 4 caracteres, DATA: 10 caracteres, HORRIO: 5 caracteres
Ex.:
CODFUN DATA HORRIO
43219 05/09/2003 7:30
43219 05/09/2003 11:30
...
>
3.1.5 Interfaces de Comunicao
<Especificar os tipos de comunicao utilizados para integrao com outros perifricos e
tecnologias. Ex: par-tranado, protocolos de comunicao, etc>
3.2 Requisitos de Desempenho

<Especificar os requisitos numricos estticos e dinmicos sobre o software ou uma interao
humana com o software. Os requisitos numricos estticos podem incluir: o nmero de
terminais suportado, o nmero de usurios simultneos suportado, a quantidade e o tipo de
informao a ser manipulado. Os requisitos numricos dinmicos podem incluir, por exemplo, o
nmero de transaes e tarefas e a quantidade de dados a ser processado dentro de
determinado perodo de tempo e condies de pico de sobrecarga. Todos esses requisitos
devem ser declarados em termos mensurveis. Por ex: 95 % das transaes devem ser
processadas em menos de 1 segundo.>
3.3 Outros Requisitos

<Descrever aqui restries do projeto que podem ser impostas por conformidade a padres,
limitaes de hardware, e por outros requisitos no funcionais: manutenibilidade, portabilidade,
confiabilidade, requisitos ticos, requisitos de entrega, etc.
>
3.4 Funes
<
Sero descritas todas as funes do produto. Esses requisitos funcionais podem ser
representados por meio de texto estruturado em linguagem natural, mas tambm podem ser
representados por meio de casos de uso, dentre outras maneiras.
A seguir, sero apresentadas duas alternativas para documentar os requisitos.
Alternativa 1) As funes so descritas por meio de um texto estruturado em linguagem

natural e para cada funo so descritos os itens de entrada necessrios (dados/informao) e
os itens de sada gerados, alm das regras de negcio que iro influenciar as funes.
Essas funes podem ser classificadas em:
Funes Bsicas: referem-se s operaes CRUD (create, read, update, delete)

necessrias para a execuo das funes fundamentais. Esse conjunto de operaes
pode ser denominado Gerenciar dados de .....
Funes Fundamentais: referem-se s transaes de negcio (movimentaes), que
realmente agregam valor ao negcio;
Funes de Sada: referem-se s funes que geram informaes de sada relevantes
para atender s necessidades do cliente (por exemplo, relatrios com cruzamento de
informaes). Nesse caso, devem ser descritos no s os itens de entrada (filtros), mas
tambm os itens de sada (informaes) pertinentes.
Observaes:
1) importante que cada funo tenha um identificador, a fim de facilitar a rastreabilidade
desse requisito. Sugere-se que seja utilizado RF (requisito funcional) seguido de um
underline, uma letra indicando se funo bsica, fundamental ou sada externa (B, F,
S) e um nmero sequencial. Ex: RF_B1. e RF_B2. para funes bsicas, RF_F1.,
RF_F2. para funes fundamentais e RF_S1., RF_S2. para funes de sada externa).
2) no devem ser citados aqui os campos das possveis tabelas do sistema, tais como,
cdigos sequenciais criados para facilitar na implementao. Aqui devero ser citados
apenas os itens de informao relacionados s funes do sistema.
3) As funes de gerenciamento do usurio, backup e restaurao do sistema no sero
citadas aqui, uma vez que j foram descritas no item 2.3 Perspectiva do Produto.
EXEMPLO: Em um sistema de locadora de vdeo:
FUNES BSICAS
RF_B1. Gerenciar cliente: o usurio pode inserir, consultar, alterar e deletar os dados
pessoais do cliente (nome, endereo, cep, cidade, estado, CPF, data de nascimento, e-mail e
fone para contato).
RF_B2. Gerenciar vdeo: o usurio pode inserir, consultar, alterar e deletar os dados
relacionados aos vdeos (cdigo do vdeo, ttulo, gnero, quantidade, preo de locao ).
FUNES FUNDAMENTAIS
RF_F1. Efetuar Reserva: o cliente pode fazer a reserva de determinado vdeo. Para isso so
necessrios os seguintes itens de informao: dados pessoais do cliente, dados do vdeo, data
e hora da reserva. Caso o cliente ainda no esteja cadastrado no sistema, necessrio realizar
um cadastro mesmo que somente com os itens obrigatrios: nome, CPF e fone.
RF_F2. Efetuar Locao: o cliente pode locar um vdeo, caso este no esteja reservado. So
necessrios os itens de informao: dados pessoais do cliente, dados do vdeo, preo da
locao, data da locao e data para devoluo (o cliente pode devolver o vdeo sem
adicionais ao preo da locao em at 3 dias, aps a data da locao). O registro da locao
deve ser vinculado uma conta a receber.
RF_F3. Efetuar Devoluo: no ato da devoluo so necessrios os itens de informao:
dados do cliente, dados do vdeo e data de devoluo. Caso a data de devoluo tenha
ultrapassado os 3 dias aps a locao, deve ser calculada uma multa de 10% sobre o valor da
locao por dia de atraso.
RF_F4. Dar Baixa das contas a receber: o cliente pode optar por efetuar o pagamento no ato
da locao ou da devoluo. Sendo assim, deve ser registrada a data do pagamento e o valor
pago, e deve ser gerado um cupom fiscal contendo as informaes pertinentes locao e ao
pagamento.
RF_F5. Comprar vdeos por parte da locadora (incluindo contas a pagar): ....
RF_F6. Dar Baixa das contas a pagar: ....
FUNES DE SADA
RF_S1. Listagem dos Clientes que mais locaram em determinado perodo: o usurio entra
com o perodo e como sada tem-se uma lista contendo o nome, telefone de contato e e-mail
de todos os clientes que mais locaram.
RF_S2. Balancete do ms:...
RF_S3. Fila de espera referente reserva: ...
RF_S4. Listagem de Clientes inadimplentes: ...
Para complementar o entendimento dos requisitos, sugere-se elaborar o Modelo Conceitual,

ou tambm denominado Modelo de Domnio, um modelo que pode ser utilizado como
preliminar para a elaborao futura do modelo de dados do sistema. Esse tem por objetivo a
visualizao dos conceitos do domnio. Para a elaborao do modelo conceitual utiliza-se da
representao do diagrama de classes da UML, entretanto, so colocados somente o nome do
conceito, os seus atributos mais relevantes e as multiplicidades. importante ressaltar que um
conceito, no necessariamente, ser uma classe de implementao.
Alternativa 2) Elaborar uma Lista de Funcionalidades na qual sero descritas todas as funes
do sistema (requisitos funcionais), detalhadamente, inclusive as operaes CRUD (que no
sero consideradas CDU).
Na coluna Referncia deve ser colocado um identificador corresponde ao requisito funcional.
Exemplo: RF_1, RF_2. A coluna Categoria deve ser preenchida com Evidente (a funo deve
ser executada, e o usurio deve estar ciente da execuo. Ex.: Registrar Venda, Processar
Pagamento) ou Oculta (deve ser executada, mas de modo transparente para o usurio. Ex.:
Dar baixa na qtde de um produto no estoque)
Exemplo:
Referncia Funes Categoria
RF_B1 Gerenciar cliente Evidente
RF_F1 Efetuar Reserva Evidente
RF_F1.1 Verificar cadastro do cliente Oculta
RF_F1.2 Registrar reserva Oculta
A seguir, realizar as Especificaes dos Casos de Uso Essenciais (sem definir consideraes
tecnolgicas). Cada caso de uso (CDU) pode ser especificado usando um template (tal como o
definido no RUP e mostrado, a seguir).
Seo do CDU Comentrio

Nome do Caso de Uso Comear com um verbo.
Breve Descrio Descrio em alto nvel do CDU.
Fluxo Bsico Um caminho tpico, incondicional e otimista do cenrio de
sucesso.
Fluxos Alternativos Cenrios Alternativos de sucesso ou fracasso.
Requisitos Especiais Requisitos no funcionais relacionados.
Pr-Condies O que precisa ser verdade antes da realizao do CDU.
Ps-Condies O que precisa ser verdade quando da finalizao bem
sucedida.
Relacionamentos Os relacionamentos que envolvem os CDUs, tais como include
e extend.
Ainda, para os CDUs que possuem atividades concorrentes, pode-se elaborar um Diagrama de
Atividades.
Para complementar o entendimento dos requisitos, sugere-se elaborar o Modelo Conceitual,

ou tambm denominado Modelo de Domnio, um modelo que pode ser utilizado como
preliminar para a elaborao futura do modelo de dados do sistema. Esse tem por objetivo a
visualizao dos conceitos do domnio. Para a elaborao do modelo conceitual utiliza-se da
representao do diagrama de classes da UML, entretanto, so colocados somente o nome do
conceito, os seus atributos mais relevantes e as multiplicidades. importante ressaltar que um
conceito, no necessariamente, ser uma classe de implementao.
>
VOLATILIDADE DOS REQUISITOS

RQ Alta Mdia Baixa
MATRIZ DE RASTREABILIDADE - REQUISITOS CLIENTE X PRODUTO
RQC
RQ
MATRIZ DE RASTREABILIDADE - REQUISITOS FUNCIONAIS E NO FUNCIONAIS DO

PRODUTO
RQC
RQ
MATRIZ DE RASTREABILIDADE - REQUISITOS DO PRODUTO X COMPONENTES
Com
RQ
APNDICE 1 - LISTA DE REQUISITOS DO CLIENTE

<Aqui so descritos os requisitos do cliente, da forma como eles os expe. Muitas vezes, um
requisito de cliente transforma-se em N requisitos do sistema.
1. <requisito 1 do cliente>
2. <requisito 2 do cliente >
3. <requisito 3 do cliente>
4. ...
>
APNDICE 2 - COMPONENTES EMPREGADOS

<Aqui so identificados os componentes utilizados no projeto, inclusive os j existentes em
uma Biblioteca.
1. <componente 1>
2. <componente 2>
3. <componente 3>
4. ...
>
APNDICE 3 - PROTTIPOS
<Aqui so inseridos os prottipos, caso tenham sido construdos para auxiliar no levantamento
e anlise dos requisitos>
A4.5 - DOCUMENTO DE ACEITE

ID Projeto:
Nome Cargo / Instituio Aprovao Observaes Data Verso ID Comprovante assinado

Papel Avaliada
dd/ mm/ aaaa
Aprovado [ ]
Reprovado [ ]
Aprovado com
ressalvas [ ].
Nesse caso, data
limite:
dd/ mm/ aaaa
dd/ mm/ aaaa
Aprovado [ ]
Reprovado [ ]
Aprovado com
ressalvas [ ].
Nesse caso, data
limite:
dd/ mm/ aaaa
A4.6 MANUAL DO USURIO

HISTRICO DE REVISES

atualizao de
Mudana
<Essa estrutura de Manual de Usurio segue a sugesto utilizada na FIPP

Faculdade de Informtica de Presidente Prudente/UNOESTE pelos alunos que
desenvolvem sistemas durante o estgio supervisionado.>
1. Introduo
<descrever o objetivo do manual do usurio>
2. Descrio do Produto
<aqui devem ser inseridas as funes e perspectivas do produto: itens 2.1 e 2.2 do
Documento de Requisitos>
Perspectiva do Produto
Funes do Produto
3. Procedimentos
<Sugere-se que sejam inseridas as figuras mostrando os passos de cada um dos
procedimentos, a seguir.>
Instalao do Produto
Configurao do Produto
Inicializao do Produto
Encerramento do Produto
4. Como preencher campos das telas do produto

<Sugere-se que sejam inseridas as figuras mostrando as telas que so acionadas por
cada opo selecionada do sistema junto descrio de cada um dos campos da tela
que necessitam de uma explicao para ser melhor compreendido.>
5. Rotinas de Backup e Restaurao
6. Mensagens de Advertncia e Erro

< Para cada mensagem mostre o significado e a soluo, caso seja uma mensagem
de erro>
Mensagem:
Significado:
Soluo:
Mensagem:
Significado:
Soluo:
A4.7 MODELO DE NEGCIO
ID do documento: Data documento: / /

ID Projeto:
HISTRICO DE REVISES
atualizao de
Mudana
Vocabulrio do Negcio
< Nessa seo devem ser descritos os principais termos pertinentes ao negcio, a fim
de esclarecer a terminologia utilizada pelo cliente.>
Termo Descrio Sinnimo
Casos de Uso de Negcio

< Um caso de uso de negcio uma seqncia de aes realizada em um negcio
que produz um resultado de valor observvel para um ator do contexto do negcio.
Os processos de um negcio so definidos como vrios casos de uso de
negcio diferentes, cada um representa um fluxo de trabalho especfico no negcio.
Uma coleo de casos de uso de negcio fornece uma viso geral do negcio muito
til para informar aos funcionrios sobre as diferentes partes do negcio que esto
sendo realizadas e os resultados esperados. Um processo de negcio gera valor para
o negcio ou minimiza os custos para o negcio. A figura 1 mostra um exemplo de
caso de uso de negcio.
Figura 1 Caso de uso de negcio relacionado ao Check-In no Aeroporto

Fonte: <http://www.wthreex.com/rup/>
Em uma modelagem de negcios controlada por caso de uso so

desenvolvidas duas vises do negcio:
viso externa do negcio: o caso de uso de negcio define o qu
essencial realizar para que o negcio fornea os resultados desejados ao
ator. Define, tambm, qual interao o negcio deve ter com os atores
quando executado.
viso interna do negcio: a realizao de casos de uso de negcio define
como o trabalho deve ser organizado e realizado para alcanar os
resultados desejados. Uma realizao abrange os trabalhadores de
negcios, as entidades de negcios envolvidas na execuo de um caso de
uso de negcio e os relacionamentos entre eles.
Diagramas de atividades da UML e diagramas de workflow podem ser

utilizados para visualizar a descrio do processo de negcios, ou seja, as atividades
do negcio, o fluxo de informao entre elas e a origem e o destino das informaes.
Um diagrama de atividades, por exemplo, pode ser usado para ilustrar o fluxo
de trabalho de um caso de uso de negcio. Esse diagrama explora a ordem das
atividades que so realizadas para alcanar as metas do negcio. Dentre essas
atividades pode-se ter atividades manuais e/ou automatizadas. A figura 2 apresenta
um diagrama de atividades relacionado ao caso de uso de negcio Check-In
Individual do modelo de casos de uso de negcio Check-In no Aeroporto (figura 1).
Figura 2 Diagrama de atividades do caso de uso de negcio Check-In Individual

A figura 3 ilustra o fluxo de trabalho de um caso de uso de negcio que

representa um processo de vendas geral. Nesse exemplo, as raias representam
departamentos na organizao.
Referncia: RUP Rational Unified Process. Modelo integrado ferramenta CASE

Rational Software.
Figura 3 Digrama de Atividades do processo de negcio de vendas.

>
Regras do Negcio
< Regras de negcio (tambm chamadas de regras de domnio) descrevem

tipicamente requisitos ou polticas que transcendem um projeto de software elas so
necessrias no domnio ou no negcio e muitas aplicaes podem precisar respeit-
las. Um exemplo so as leis sobre impostos governamentais. Os detalhes das regras
de domnio podem ser registrados na especificao dos requisitos, mas como elas so
usualmente mais duradouras e aplicveis do que para um projeto de software, coloc-
las em um artefato central de regras de negcio (compartilhado por todos analistas da
empresa) leva ao melhor reso do esforo de anlise.
Exemplo:
Id Regra Regra Mutabilidade Fonte
Regra 1 Regras de desconto para compradores. Alta. Cada varejista Poltica de
Empregado: 20% usa regras diferentes. Varejo.
Cliente Preferencial: 10%
Idoso: 15%
Regra 2 Restituies de pagamento a crdito Baixa. Poltica da
podem somente ser pagas como crdito companhia de
conta de crdito do comprador, no em autorizao
dinheiro. de crdito.
Referncia: LARMAN, C. Utilizando UML e Padres: Uma introduo anlise e ao

projeto orientados a objetos e ao desenvolvimento iterativo. Porto Alegre: Bookman,
2007.
Para marcar quais das regras de negcio devem ser atendidas pelo software a
ser desenvolvido, sugere-se uma coluna na tabela anterior que define o(s) ID(s) do(s)
projeto(s) os quais as regras de negcio so utilizadas.
No exemplo, a seguir, a regra 1 utilizada tanto no projeto AAA quanto no
projeto BBB daquele cliente.
Id Regra Mutabilidade Fonte ID Projeto

Regra 1 Regras de desconto para Alta. Cada Poltica de AAA
compradores. varejista usa Varejo. BBB
Empregado: 20% regras
Cliente Preferencial: 10% diferentes.
Idoso: 15%
Uma regra de negcio define ou restringe um aspecto do negcio, a fim de afirmar a

estrutura do negcio ou influenciar o comportamento do negcio.
As regras de negcio definem como o negcio funciona, podem abranger suas
polticas, interesses, objetivos, compromissos ticos e sociais, obrigaes contratuais,
decises estratgicas, leis e regulamentaes, entre outros.
Regras de negcio, freqentemente, focam questes de controle de acesso,
podem, tambm, fazer parte dos clculos nos negcios e focam as polticas da
organizao. Por exemplo:
professores tm permisso de acessar e modificar as notas dos
estudantes das disciplinas as quais ele responsvel somente;
converso de uma nota de percentual (como 91%) para uma letra
significativa no contexto (como A);
a poltica da universidade reprovar no termo cursado caso o aluno
reprove em mais de duas disciplinas no mesmo semestre.
Professores assistentes s podem administrar grades de estudantes se
autorizados pelos professores efetivos.
>
A4.8 MODELO DE DESIGN

ID Projeto:
ID do Documento de Requisitos:
ID da Arquitetura do Software:
HISTRICO DE REVISES

atualizao de
Mudana
1 Modelo Lgico do Sistema

< Esse modelo tem como objetivo mostrar os elementos que iro compor o software e
os relacionamentos entre eles. Pode ser representado por:
Alternativa 1:
Diagrama de Classes: contm as classes do sistema que podem estar
organizadas em pacotes e subsistemas. Um pacote deve ser usado em casos
onde um conjunto de classes e/ou outros pacotes necessitam ser agrupados
para modelar os objetivos da organizao. O contedo do pacote pode ter
visibilidade pblica. Um subsistema deve ser usado em casos onde um
conjunto de classes e/ou outros pacotes necessitam ser encapsulados dentro
de um container e escondidos por meio de um conjunto de interfaces bem
definido. Por conveno, nenhum contedo dos subsistemas visvel, exceto
as interfaces. Isso permite facilidade na substituio e oferece maior grau de
encapsulamento em comparao aos pacotes.
Diagrama de Interao para cada caso de uso, a fim de definir quem so os
mtodos das classes.
Mapeamento OO-Relacional: como normalmente so usados bancos de
dados relacionais, necessrio o mapeamento das classes para tabelas.
Alternativa 2:
Diagrama Entidade-Relacionamento
Diagrama de Estrutura Modular
>
2 Modelo Fsico de Dados

< Representa todas as tabelas do banco de dados a serem criadas com a definio de
seus respectivos campos.>
A4.9 PEDIDO DE COMPRA

ID Projeto:
Status do Pedido de Compra

( ) Congelado Data: / /
( ) Liberado Data: / /
HISTRICO DE REVISES

atualizao de
Mudana
1. DESCRIO DOS REQUISITOS

<Aqui so descritos os requisitos validados esperados do(s) produto(s) a
ser(em) adquirido(s).>
2. DADOS DA SOLICITAO DE COMPRAS
Descrio Quantidade Data limite Justificativa

de entrega
A4.10 PLANO DE GARANTIA DA QUALIDADE

ID Projeto:
HISTRICO DE REVISES
atualizao de
Mudana
1. Critrios de qualidade do projeto

< Aqui so definidos os critrios de qualidade esperados do projeto desenvolvido. Esses
critrios podem incluir, alm dos critrios estabelecidos pela empresa desenvolvedora (tais
como: prazo de entrega, conformidade com os templates definidos no processo), os critrios de
aceitao do produto determinados pelo cliente durante a definio do escopo do projeto.
Alguns exemplos de critrios: usabilidade, confiabilidade, manutenibilidade, portabilidade,
eficincia>
2. Mtodos de garantia da qualidade do processo

< Aqui so definidos os mtodos que podem ser utilizados para garantia a qualidade do
processo definido. No modelo de processo genrico, elaborado nesse trabalho de pesquisa de
doutorado foi adotada a utilizao da anlise de conferncia do processo definido durante a
realizao de um projeto (averiguar se o processo est realmente sendo seguido). Essa anlise
de conferncia realizada a cada trmino de fase, junto reviso do milestone.>
3. Medidas/Mtricas
Objetivos de medio
Mtricas de produto
< Um exemplo de mtrica de produto : a atratividade da interface do software, ou seja, quo
atrativa a interface para o usurio? Pode ser utilizado um questionrio para a obteno dessa
medida.>
Mtricas de processo
< Um exemplo de mtrica de processo : a estabilidade da especificao funcional, ou seja,
qual estvel foi a especificao funcional durante o ciclo de desenvolvimento de software? Para
obter essa medida preciso contar o nmero de funes alteradas (adicionadas, modificados
ou excludas) durante o ciclo de desenvolvimento (A) e ento comparar com o nmero de
funes descritas no Documento de Requisitos (B).
Medida = 1 A/B => quanto mais prximo o resultado de 1, mais estvel a especificao .>
4. Estratgia de coleta, armazenamento e anlise das medidas

<No caso do Modelo de Processo Genrico, por exemplo, a medida tamanho do software
coletada para estimar o esforo e custo que pode ser despendido no projeto. A estratgia
adotada para coletar essa medida utilizando inicialmente a experincia dos especialistas que
trabalham na empresa e, com o passar do tempo, por meio de uma base de dados histrica
onde sero registradas medidas como tamanho do software, tempo utilizado para
desenvolvimento, recursos utilizados, capacidade do pessoal, entre outras medidas, para
conseguir estimar o esforo e custo de um novo projeto, a partir de projetos similares j
desenvolvidos pela empresa.>
Referncia Bibliogrfica:
SOMMERVILLE, I. Engenharia de Software. 8 ed. So Paulo: Pearson Addison
Wesley, 2007.
Segundo Sommerville (2007), Garantia de Qualidade o processo de definio

de como a qualidade de software pode ser atingida e como a organizao de
desenvolvimento sabe que o software possui o nvel de qualidade necessrio. O
processo de garantia de qualidade est, principalmente, relacionado definio e
seleo de padres que devem ser aplicados ao processo de desenvolvimento de
software ou ao produto de software.
Garantia da Qualidade de Software tem o objetivo de fornecer a garantia de
que processos e produtos de trabalho estejam em conformidade com planos e
provises pr-definidos.
Humphrey (1989) sugere uma estrutura geral para um plano de qualidade.

Essa estrutura inclui:
Apresentao do produto. Descrio do produto, o mercado pretendido e as
expectativas de qualidade para o produto.
Plano de produto. As datas crticas de liberao e as responsabilidades
para o produto junto com planos para servio de distribuio e de produto.
Descries de processo. Os processos de desenvolvimento e de servios
devem ser usados para o desenvolvimento e gerenciamento de produto.
Metas de qualidade. As metas e os planos de qualidade para o produto
incluindo identificao e justificativa de atributos crticos de qualidade de
produto.
Riscos e gerenciamento de riscos. Os riscos principais que poderiam afetar
a qualidade de produto e as aes para tratar esses riscos.
Em um plano de qualidade deve-se definir os atributos de qualidade mais
importantes para o software em desenvolvimento. Exemplos: segurana,
confiabilidade, adaptabilidade, portabilidade, facilidade de uso, facilidade de reuso,
eficincia.
As revises so mtodos de validao de qualidade de um processo ou

produto amplamente usados. Alguns tipos de reviso so apresentados, a seguir:
Inspees de programa: tem o objetivo de detectar erros detalhados nos
requisitos, projeto ou cdigo. Uma lista de verificao de possveis erros
deve guiar a reviso.
Revises de progresso: o objetivo fornecer informaes para a gerncia
sobre o progresso geral do projeto. Esta uma reviso de processo e de
produto e concentra-se em custos, planejamentos e prazos.
Revises de qualidade: o objetivo conduzir uma anlise tcnica dos
componentes de produto ou documentao para encontrar inconsistncias
entre especificao e projeto, cdigo ou documentao de componente e

assegurar que padres de qualidade definidos foram seguidos.
A medio de software se dedica a derivar um valor numrico para algum

atributo de um produto de software ou de um processo de software. Alguns exemplos
de medidas de produto: tamanho do software, nmero de defeitos. Alguns exemplos
de mtricas de processo: o esforo mdio e o tempo necessrio para reparar os
defeitos reportados, o esforo total em termos de pessoas-dia, custos de viagem e
recursos computacionais para um processo especfico. Comparando-se esses valores
uns com os outros e aos padres que se aplicam em uma organizao, voc pode ser
capaz de tirar concluses sobre a qualidade de software ou dos processos de software
(SOMMERVILLE, 2007). Por ex: uma organizao planeja introduzir uma nova
ferramenta de teste de software. Antes de introduzir a ferramenta, pode-se registrar o
nmero de defeitos do software descobertos em um dado tempo; depois da introduo
da ferramenta, pode-se concluir que ela fornece apoio til ao processo de validao de
software.
Existem duas maneiras nas quais as medies de software podem ser usadas:
Para fazer previses gerais sobre um sistema. Ao medir as caractersticas
dos componentes de sistema e, em seguida, agregar essas medies,
pode-se derivar uma estimativa geral de algum atributo de sistema, como o
nmero de defeitos no sistema.
Para identificar componentes anmolos. As medies podem identificar
componentes individuais cujas caractersticas desviem de alguma regra.
Por ex: possvel medir os componentes para descobrir os com maior
complexidade e, supondo que esses so provavelmente os que tero mais
erros, concentra-se sobre esses componentes durante o processo de
reviso.
Para escolher as medies a serem realizadas, pode-se utilizar a abordagem

GQM (Goal-Question-Metric) de Basili (BASILI & ROMBACH, 1988). Essa
abordagem conta com a identificao de:
1. Objetivos: definem o que a organizao est tentando obter. Exemplos: o
aumento da produtividade de programadores, reduo do tempo de
desenvolvimento de produto, incremento da confiabilidade do produto.
2. Questes: So refinamentos dos objetivos. Normalmente, um objetivo ter
um nmero de questes associadas que necessitam ser respondidas.
Exemplo: Como o tempo necessrio para finalizar os requisitos de produto
pode ser reduzido?
3. Mtricas: so as medies que necessitam ser coletadas para auxiliar a
responder s questes e confirmar se os aprimoramentos de processos
alcanaram o objetivo desejado. Exemplo de medio da questo anterior:
o nmero de comunicaes formais entre o cliente e o contratado para cada
mudana de requisitos.
Segundo a ISO/IEC 9126 (Software Engineering Product Quality) h trs

tipos de mtricas:
Mtricas internas: podem ser aplicadas em um produto de software no-
executvel durante os estgios de desenvolvimento, tais como: solicitao
de proposta, definio de requisitos, especificao de design ou cdigo-
fonte. Essas mtricas fornecem ao usurio a habilidade de medir a
qualidade das entregas intermedirias e, portanto, prediz a qualidade do
produto final. Assim, possvel identificar questes de qualidade e iniciar
aes corretivas to logo quanto possvel no ciclo de desenvolvimento de
software.
Mtricas externas: podem ser usadas para medir a qualidade do produto de

software por meio da medio do comportamento do sistema do qual faz
parte. As mtricas externas podem ser usadas durante os estgios de teste
do processo de ciclo de vida e durante alguns estgios de operao. A
medio realizada quando o software est sendo executado no ambiente
do sistema no qual se pretende operar.
Mtricas de qualidade em uso: medem se um produto atende s
necessidades dos usurios para alcanar objetivos especficos com
efetividade, produtividade, segurana e satisfao no contexto de uso
especificado. Isso pode ser alcanado no ambiente real onde o sistema
operar.
A4.11 PLANO DE GESTO DE CONFIGURAO

1. Introduo
1.1 Objetivo
Este documento define um plano de gerenciamento de configurao padro da
empresa. Este plano descreve os padres e procedimentos que devem ser usados
para o gerenciamento dos itens de configurao.
1.2 Siglas, abreviaes e definies

Devem ser definidos todos os termos, acrnimos e abreviaes necessrias para a
interpretao apropriada do Plano de Gesto de Configurao.
2. Definio dos itens de configurao

Devem ser selecionados pela Equipe de Qualidade da empresa os artefatos a
serem controlados como itens de configurao do sistema a ser desenvolvido.
Normalmente, o plano de projeto, documento de requisitos, programas (cdigo-
fonte), modelos de dados e casos de teste so mantidos como itens de configurao.
Entretanto, a equipe de qualidade tem a liberdade de definir quais outros artefatos,
desenvolvidos em meio ao processo de desenvolvimento de software, so importantes
serem colocados sob a gerncia de configurao para auxiliar em uma futura
manuteno do sistema (seja ela corretiva, evolutiva ou preditiva).
A seguir, so listados os itens de configurao que podero compor a baseline de
um projeto, organizados pelas fases do processo de venda e desenvolvimento de
software. Uma baseline serve como uma fotografia capaz de descrever um projeto em
um determinado instante de sua execuo.
Fase Prospeco Fase Concepo
o Roteiro de Prospeco o Modelo de Negcio
o Modelo de Negcio o Documento de Requisitos
o Plano de Ao o Plano de Projeto
o Projeto IHM
o Relatrio de Anlise dos Requisitos
o Arquitetura do Software
o Cronograma
o Relatrio de Viabilidade do Projeto
o Fluxo de Caixa
o Plano de Ao
Fase Negociao
o Proposta Tcnica Fase Elaborao
o Proposta Comercial o Documento de Requisitos
o Relatrio de Viabilidade do Projeto o Projeto IHM
o Cronograma o Modelo de Negcio
o Documento de Requisitos o Relatrio de Anlise dos Requisitos
o Contrato o Arquitetura do Software
o Plano de Projeto o Modelo de Design
o Cronograma o Planilha de Teste
o Documento de formalizao do o Plano de Projeto
projeto o Relatrio de Acompanhamento de
o Pedido de Compra Projeto
o Plano de Ao o Cronograma
o Relatrio de Acompanhamento de o Relatrio de Viabilidade do Projeto
Projeto
Fase Construo
o Arquivo de Cdigo
o Controle de Tarefas
o Planilha de Teste
o Relatrio de Acompanhamento de Projeto
o Cronograma
Fase Transio
o Planilha de Teste
o Verso do Produto
o Documento de Aceite
o Manual do Usurio
o Relatrio de Acompanhamento de Projeto
o Cronograma
3. Papis dos responsveis pelos procedimentos de gesto de configurao

A Equipe de Qualidade, responsvel por definir o Plano de Gesto de
Configurao para cada projeto a ser executado, pode ser composta pelos membros
responsveis em cada fase do processo de venda e desenvolvimento de software. Por
exemplo:
Equipe de Vendas: responsvel pelo controle dos itens de configurao da
fase Prospeco. Este papel consiste em criar novas verses de itens de
configurao, criar novas baselines e colocar estes itens de configurao na
ferramenta de controle de verses.
Gerente de Projeto: responsvel pela reviso, aprovao e autorizao de
mudana nos itens de configurao do processo de venda e desenvolvimento
de software. Este papel consiste em analisar a relevncia da mudana,
controlar o planejamento, a implementao e os testes das mudanas nos itens
de configurao, bem como a alterao de qualquer documento no projeto.
4. Estratgia de identificao dos itens de configurao

A estratgia de identificao dos itens de configurao importante para manter a
rastreabilidade de todas as informaes pertinentes aos itens de configurao.
Deve ser atribudo um nico nome para todos os artefatos sob controle de
configurao. Este nome pode refletir o tipo do item, uma parte do sistema ao qual ele
se aplica, o criador do item, etc.
interessante que se evidencie a relao entre os itens de configurao para
garantir que os artefatos relacionados possuam uma mesma raiz em seus nomes.
A identificao de um item de configurao pode ser realizada da seguinte
maneira:
Nome do Item de Configurao Abreviado + _ + ID do Projeto + _ + V(verso) + (numerao da verso)
Sendo que:
As letras iniciais do nome do item de configurao abreviado devem ser maisculas.

Os identificadores dos projetos (ID do Projeto) devem ser nicos na empresa, ou seja, nenhum projeto poder apresentar o mesmo
identificador. Sugere-se que o identificador seja composto pela sigla do projeto composta de 3 a 5 letras em maisculo.
A criao dos itens de configurao deve ocorrer no momento em que for iniciada uma atividade, de qualquer fase do processo de venda e
desenvolvimento de software, responsvel pelo seu desenvolvimento. Todos os itens de configurao devem ser criados na verso V0.1.
Todos os itens de configurao devem possuir um histrico composto pelos campos, a seguir.
- Data de criao/atualizao
- Descrio da mudana ocorrida
- Responsvel
- Verso do documento
- ID. da solicitao de mudana
- Data de incio da realizao da mudana
- Data de trmino da realizao da mudana
- Descrio da Mudana Ocorrida
5. Poltica de criao de baselines

Baseline uma linha de referncia composta por todos os itens de configurao de
um projeto. O objetivo de uma baseline servir de referncia para o gerenciamento de
mudanas de um projeto. Ela deve ser como uma fotografia capaz de descrever um
projeto em um determinado instante de sua execuo.
A criao de baselines pode ser realizada de acordo com os marcos do projeto
(milestones) ou de alguma outra forma definida pela gerncia. A baseline
armazenada em um repositrio de itens de configurao. E, a partir desse momento,
s pode ser alterado por meio de uma solicitao de alterao formal para controle de
mudana.
No modelo de processo genrico elaborado nessa pesquisa de doutorado, sugere-
se que quando realizada tanto uma mudana simples em um ou mais itens de
configurao quanto complexa deve ser criada uma nova baseline que incorpore os
itens de configurao modificados, autorizada pelo Gerente de Projeto.
A fim de se ter um controle de baselines a cada trmino de fase do modelo de
processo genrico, mesmo que no haja modificaes, para cada uma das fases do
modelo sugere-se a criao de baselines nos seguintes marcos:
Fase Prospeco
o Milestone: Solicitao de uma proposta pelo cliente
Fase Concepo
o Aps a atividade do ciclo de desenvolvimento: Cp14. Conduzir reviso do
milestone: Estudo de Viabilidade do Projeto
Fase Negociao
o Aps a atividade do ciclo de desenvolvimento: N09. Conduzir reviso do milestone:
Contrato
Fase Elaborao
o Aps a atividade do ciclo de desenvolvimento: E08. Conduzir reviso do milestone:
Fase Construo
o Aps a atividade do ciclo de desenvolvimento: Ct05. Conduzir reviso do
milestone: Capacidade Operacional
Fase Transio
o Aps a atividade do ciclo de desenvolvimento: T06. Conduzir reviso do milestone:
Entrega do Produto
A identificao da baseline pode ser constituda por:

Baseline + _ + ID do Projeto + _ + (numerao sequencial iniciada por 0001)
Sendo que:
o Os identificadores dos projetos (ID do Projeto) devem ser nicos na empresa, ou seja,
nenhum projeto poder apresentar o mesmo identificador. Sugere-se que o identificador seja
composto pela sigla do projeto composta de 3 a 5 letras em maisculo.
6. Polticas de gesto de configurao

Nesta seo so definidas as polticas de gerenciamento de configurao que
todos os membros da equipe do projeto devem adotar para o controle de mudanas e
gerenciamento das verses.
A seguir, mostrado um exemplo de polticas de gesto de configurao. Essas
polticas esto inseridas no modelo de processo genrico. Caso queira modific-las
preciso modificar as tarefas das atividades correspondentes no modelo.
Exemplo de polticas:
Os itens de configurao podero ser modificados perante as seguintes situaes:
Enquanto o item de configurao no tiver uma primeira verso finalizada,
determinada por um marco de projeto (milestone), ele ser modificado sem
alterao de verso.
Aps o trmino de uma verso do item de configurao, ele s poder ser

alterado para outra verso mediante uma solicitao de mudana e anlise da
mudana para detectar a relevncia e complexidade da mesma. Nesse caso,
pode haver duas situaes:
o Mudana simples: Deve ser realizada sem a necessidade de todo o
processo de anlise e planejamento da mudana. Devem ser realizados
testes depois de finalizada a implementao da mudana. A realizao de
uma mudana simples deve ser registrada no prprio histrico do item de
configurao que foi alterado.
o Mudana complexa: Caso uma mudana seja considerada complexa, deve-
se ento seguir todo o fluxo do processo de gesto de configurao:
GCf04. Analisar/Autorizar e Planejar mudana(s), CGf05. Implementar
mudana(s), CGf06. Validar e Liberar mudana(s). Uma mudana
complexa tambm deve ser registrada no histrico do item de configurao.
A identificao da solicitao de mudana pode ser constituda por:
Mudana + _ + ID do Projeto + _ + (numerao sequencial iniciada por 0001)
Sendo que:
o Os identificadores dos projetos (ID do Projeto) devem ser nicos na empresa, ou seja,
nenhum projeto poder apresentar o mesmo identificador. Sugere-se que o identificador
seja composto pela sigla do projeto composta de 3 a 5 letras em maisculo.
Quando realizada tanto uma mudana simples quanto uma complexa deve ser
criada uma nova baseline que incorpore os itens de configurao modificados, de
acordo com a poltica de criao de baselines descrita na seo 5.
Um release do sistema uma verso distribuda ao cliente. Cada release deve

incorporar novas funcionalidades ou ser planejado para uma plataforma diferente de
hardware. H, normalmente, muito mais verses de um sistema do que liberaes. As
verses so criadas no mbito da organizao, para desenvolvimentos ou testes
internos, e no so previstas para serem liberadas para os clientes.
Um release do sistema no somente um cdigo executvel do sistema. Ele pode
incluir: arquivos de configurao que definem como o release pode ser configurado
para instalaes especficas; arquivo de dados necessrio para a operao do sistema
com sucesso; um programa de instalao usado para auxiliar a instalao do sistema
no hardware-alvo; documentao eletrnica e em papel que descreve o sistema;
empacotamento e publicidade associada projetados para release.
Para documentar um release, deve-se:
o registrar as verses especficas dos componentes de cdigo-fonte usados
para criar o cdigo executvel;
o manter cpias dos cdigos-fonte, do cdigo-executvel, de todos os
arquivos de dados e de configurao;
o registrar as verses do sistema operacional, as bibliotecas, os compiladores
e outras ferramentas usadas para construir o software.
7. Ferramentas utilizadas
< aqui so descritas as ferramentas utilizadas para realizar o controle de
mudanas e verses dos artefatos do projeto>
8. Estrutura do Banco de Dados de Configurao

O banco de dados de configurao utilizado para registrar todas as informaes
relevantes sobre as configuraes de sistema e os itens de configurao. Assim, ele
auxilia a avaliao do impacto das mudanas de sistema e permite gerar relatrios
para a gerncia.
Referncia Bibliogrfica: SOMMERVILLE, I. Engenharia de Software. 8 ed. So

Paulo: Pearson Addison Wesley, 2007.
A4.12 PLANO DE MARKETING
Ttulo: Deve descrever o que o plano tem como objetivo

Data Inicial: Data de incio do plano
Data Final: Data final do plano
HISTRICO DE REVISES

atualizao de
Mudana
1. Contextualizao
< realizada a anlise SWOT - trata-se da avaliao global das foras, fraquezas,
oportunidades e ameaas (strengths, weaknesses, opportunities, threats). Em geral,
uma empresa tem que monitorar importantes foras macroambientais (econmico-
demogrficas, tecnolgicas, poltico-legais e socioculturais) e significativos agentes
microambientais (clientes, concorrentes, distribuidores, fornecedores) que afetam sua
capacidade de obter lucros. realizada uma anlise de mercado, considerando
oportunidades e ameaas. Alm disso, feita uma anlise dos pontos fortes e fracos
da sua empresa e so considerados, tambm, os concorrentes.
A lista, a seguir, sugere itens a serem considerados na anlise de
foras/fraquezas:
o Marketing: reputao da empresa, participao de mercado, satisfao
do cliente, reteno do cliente, qualidade do produto, qualidade de
servio, efetividade na determinao de preos, efetividade na
distribuio, efetividade de promoes, efetividade da fora de vendas,
efetividade das inovaes, cobertura geogrfica.
o Finanas: custo ou disponibilidade de capital, fluxo de caixa,
estabilidade financeira.
o Produo: instalaes, economias de escala, capacidade, fora de
trabalho capaz e dedicada, capacidade de produzir no prazo,
habilidades tcnicas de fabricao.
o Organizao: liderana visionria e capaz, funcionrios dedicados,
orientao empreendedora, flexibilidade ou boa capacidade de
resposta.
Exemplo da Anlise SWOT (foras, fraquezas, oportunidades e ameaas).
Potencialidades (Fatores Internos) Fragilidades (Fatores Internos)

1- Fcil Implantao 1- Produto pouco conhecido pelo mercado
2- Satisfao dos atuais clientes 2- Preo acima da capacidade de grande
parte do mercado
Oportunidades (Fatores Externos) Ameaas (Fatores Externos)
1- Baixa Concorrncia 1- Produto concorrente sem custo para
2- Existncia de recursos de rgos de clientes
fomento para aquisio do sistema
O produto deve ser contextualizado (aproximadamente um pargrafo) e pode

ser inserida a lista de atuais clientes atendidos e casos de sucesso. Alm disso,
importante definir o pblico-alvo desse produto.
So, tambm, definidos o preo do produto e as condies de fornecimento do
produto (no caso de ser algum produto j pronto da empresa, sem customizaes).
>
2. Objetivos
<Define as metas financeiras e de marketing do plano em relao ao volume de
vendas, participao do mercado e lucros e ndices de satisfao dos clientes.
Exemplos de objetivos quantitativos: aumentar vendas em 10%; aumentar participao
de mercado para 30%.
Exemplos de objetivos qualitativos: treinar equipe de vendas; implantar filosofia de
qualidade; melhorar o relacionamento com os fornecedores.>
3. Operacionalizao
3.1 Perfil de potenciais clientes

< Aqui deve ser descrito o perfil dos potenciais clientes.>
3.2 Estratgia para busca de potenciais clientes

<Aqui deve ser definido como buscar os potenciais clientes, conforme o perfil
descrito no item anterior.
Exemplo:
Etapa 1 E-mail marketing e/ou material marketing via correio
Etapa 2 Contato Telefnico
Etapa 3 Visita
Etapa 4 Proposta
Etapa 5 - Fechamento
>
4. Plano de Ao
< O que ser feito para atingir aos objetivos do plano? Como? Quando ser feito?
Quem far? Quanto custar?
Aqui dever ser definido um conjunto de etapas que coloque em prtica a estratgia
definida anteriormente, assim como cada uma dessas etapas dever ser realizada
(seqncia e ordem de prioridade). Quem ser o responsvel pela execuo e qual o
custo estimado. Para cada etapa desse plano dever ser definido um conjunto de
informaes que devero ser transmitidas aos potenciais clientes e outro conjunto de
respostas que a empresa espera para que a prxima etapa possa ser iniciada.
Exemplo: As seguintes etapas sero abordadas nas fases prospeco, concepo
e negociao:
Etapa 1 E-mail marketing
Etapa 2 Contato Telefnico
Etapa 3 Visita
Etapa 4 Proposta
Etapa 5 - Fechamento
Para cada etapa dever ser definida a forma de abordagem. Ex: etapa 1 email
marketing. Definir texto do email, layout e links. Definir o que esperado como
retorno dessa ao. Ex. telefonema, email de reposta manifestando interesse
ou click no link X. >
5. Atividades de inicializao e infra-estrutura

<Aqui devem ser definidas as atividades necessrias para que seja iniciada a
ao de vendas. Ex: Instalao de um novo ramal de telefone na sala Y.>
6. Equipe
<Aqui dever ser definida a equipe que ser responsvel pelas aes de
venda, percentual de alocao de cada recurso e horrio de trabalho.>
7. Metas de venda
< Aqui dever ser definida a meta de vendas geral e parcial por perodo e por
pessoa.>
8. Custos referentes ao de venda

< Aqui dever ser descrito o oramento relativo ao planejamento da ao de
venda em questo. Pessoal, telefone, infra-estrutura, viagens, comisses, eventos,
material de divulgao. Para que esse item seja feito com um mnimo de
confiabilidade necessrio que o item 3 deste documento (Plano de ao) tenha um
planejamento no s de como cada etapa dever ser realizada, mas tambm o
nmero de eventos por etapa por perodo. Ex: arquivo excell plano_de_acao.xls.>
9. Acompanhamento do Plano de Ao
<Aqui dever ser definida a forma de acompanhamento do plano. Isso dever
incluir periodicidade e itens para avaliao. Para que esse item seja realizado com
sucesso necessrio que o item 3 (Definir Plano de ao) tenha um planejamento no
s de como cada etapa dever ser realizada, mas tambm o nmero de eventos por
etapa e por perodo para que possa ser produzido uma planilha mostrando a
comparao entre o planejado e o realizado.Ex: guia Acompanhamento do template
Plano de Ao.xls.>
Referncias:
KOTLER, P. Administrao de Marketing. 10 ed. So Paulo: Pearson Prentice Hall,
2000.
LAS CASAS, A. L. Plano de marketing para micro e pequena empresa. So Paulo:
Atlas, 2001.
ROSA, C. A. Como elaborar um plano de negcio. Braslia: SEBRAE, 2007.
GOMES, I. M. Como elaborar um plano de marketing. Belo Horizonte: SEBRAE/MG,
2005.
CARVALHAIS, R. S.; PATTO, A. R. Como elaborar um plano de vendas. Belo
Horizonte: SEBRAE/MG, 2007.
O planejamento estratgico o processo gerencial de desenvolver e manter uma

direo estratgica que alinhe as metas e os recursos da organizao com suas
mutantes oportunidades de mercado (KOTLER, 2000).
Segundo Kotler (2000), o planejamento estratgico de negcios consiste de oito
etapas. So elas:
Misso do Negcio: cada unidade de negcio precisa definir sua misso
especfica dentro da misso corporativa.
Anlise SWOT: trata-se da avaliao global das foras, fraquezas, oportunidades
e ameaas (strengths, weaknesses, opportunities, threats). Em geral, uma unidade
de negcios tem que monitorar importantes foras macroambientais (econmico-
demogrficas, tecnolgicas, poltico-legais e socioculturais) e significativos agentes
microambientais (clientes, concorrentes, distribuidores, fornecedores) que afetam
sua capacidade de obter lucros. A unidade de negcios deve estabelecer um

sistema de inteligncia de marketing para acompanhar tendncias e mudanas
importantes. A administrao precisa identificar as oportunidades e ameaas
associadas a cada tendncia ou desenvolvimento. Um objetivo importante da
avaliao ambiental o reconhecimento de novas oportunidades de marketing.
Uma oportunidade de marketing existe quando a empresa pode lucrar ao atender
s necessidades dos consumidores de um determinado segmento. Cada unidade
de negcio, tambm precisa avaliar periodicamente suas foras e fraquezas
internas. Isso pode ser feito pela gerncia (ou consultor externo) que analisa as
competncias de marketing, financeiras, de fabricao e organizacionais. A lista, a
seguir, sugere itens a serem considerados na anlise de foras/fraquezas:
o Marketing: reputao da empresa, participao de mercado, satisfao
do cliente, reteno do cliente, qualidade do produto, qualidade de
servio, efetividade na determinao de preos, efetividade na
distribuio, efetividade de promoes, efetividade da fora de vendas,
efetividade das inovaes, cobertura geogrfica.
o Finanas: custo ou disponibilidade de capital, fluxo de caixa,
estabilidade financeira.
o Produo: instalaes, economias de escala, capacidade, fora de
trabalho capaz e dedicada, capacidade de produzir no prazo,
habilidades tcnicas de fabricao.
o Organizao: liderana visionria e capaz, funcionrios dedicados,
orientao empreendedora, flexibilidade ou boa capacidade de
resposta.
Formulao de metas: a empresa deve desenvolver metas especficas para o
perodo de planejamento. As metas indicam aquilo que uma unidade de negcios
deve alcanar. Essas metas so utilizadas para descrever objetivos em termos de
magnitude e prazo.
Formulao de estratgias: a estratgia o meio para atingir os fins (os objetivos
da empresa); refere-se a como devem ser alcanadas as metas. Exemplos de
estratgias: liderana total em custos (a empresa se esfora para conseguir os
menores custos de produo e de distribuio, de modo a poder oferecer preos
mais baixos do que os dos concorrentes e a obter uma grande participao de
mercado).
Formulao de programas: devem ser definidos planos de programas baseados
na estratgia definida.
Implementao: os programas devem ser executados.
Feedback e Controle: medida que se implementa a estratgia, deve-se realizar
o acompanhamento dos resultados e monitoramente dos novos acontecimentos
nos ambientes interno e externo.
O plano estratgico composto pelo plano de marketing, plano de produo,

plano financeiro e plano de recursos humanos (LAS CASAS, 2001). O plano de
marketing, por sua vez, composto pelo plano de vendas, plano de propaganda, plano
de novos produtos e plano de merchandising.
O processo de marketing consiste em analisar oportunidades de marketing,
pesquisando e selecionando mercados-alvo, delineando estratgias, planejando
programas e organizando, implementando e controlando o esforo de marketing.
Para cada nvel de produto (linha de produtos, marca) deve ser desenvolvido
um plano de marketing para atingir suas metas. Esse plano um dos produtos do
processo de marketing. Um Plano de Marketing contm:
Resumo executivo e sumrio: apresenta uma rpida viso geral do plano
proposto.
Situao atual de marketing: apresenta antecedentes relevantes sobre

vendas, custos, lucros, mercado, concorrentes, distribuio e
macroambiente.
Anlise de oportunidades e questes: identifica as principais
oportunidades/ameaas, foras/fraquezas e questes relacionadas linha
de produtos.
Objetivos: define as metas financeiras e de marketing do plano em relao
ao volume de vendas, participao do mercado e lucros.
Estratgia de marketing: apresenta a abordagem geral de marketing que
ser utilizada para alcanar os objetivos do plano. O gerente de produto, ao
desenvolver a estratgia de marketing, conversa com o pessoal de compras
e de fabricao, a fim de confirmas se so capazes de comprar material
suficiente e produzir unidades suficientes para atender aos nveis-alvo de
volume de vendas; tambm conversa com o gerente de vendas, para obter
apoio da fora de vendas, e com o gerente financeiro, para conseguir os
recursos necessrios para propaganda e promoo.
Programas de ao: apresenta os programas especiais de marketing
projetados para atingir aos objetivos do plano. O que ser feito? Quando
ser feito? Quem far? Quanto custar?
Demonstrativo de resultados projetados: projeta os resultados
financeiros esperados do plano. Os planos de ao permitem que o gerente
de produto desenvolva um oramento de apoio. Pelo lado da receita, esse
oramento mostra o volume esperado de vendas em unidades e seu preo
mdio. Pelo lado de despesas, mostra os custos de produo, de
distribuio e de marketing. Uma vez aprovado, o oramento a base para
desenvolver planos e programaes de suprimento de materiais, de
produo, de recrutamento de funcionrios e de operaes de marketing.
Controles: indica como o plano ser monitorado. As metas e oramentos
foram especificados detalhadamente para cada ms ou trimestre. A alta
administrao pode analisar os resultados a cada perodo. Algumas sees
de controle incluem planos de contingncia. Um plano de contingncia
descreve as atitudes que a gerncia tomaria em resposta a eventos
adversos especficos, como guerras de preo.
Um roteiro simplificado para um plano de marketing apresentado por Las

Casas (2001):
1. Anlise Ambiental
a. Ameaas e oportunidades: anlise do mercado como um todo.
Para cada evento, descrever ameaas, oportunidades e
sugestes.
b. Pontos fortes e fracos: realizada com o propsito de identificar quais
empresas concorrentes tm melhores condies de aproveitar as
oportunidades ou se defender de eventuais ameaas.
Os aspectos que podem ser analisados so: pessoal
(quantidade e qualificao), equipamentos (capacidade instalada,
tecnologia), finanas (recursos financeiros, possibilidade de obteno
de emprstimos), marketing (produto, preo, distribuio, propaganda,
equipe de vendas, promoo).
2. Objetivos:
a. Quantitativos
Exemplos: aumentar vendas em 10%; aumentar participao de
mercado para 30%.
b. Qualitativos:
Exemplos: treinar equipe de vendas; implantar filosofia de

qualidade; melhorar o relacionamento com os fornecedores.
3. Estratgia de Marketing
a. Pblico-alvo
Exemplo: segmento de homens, faixa etria de 25 a 35 anos,
renda entre R$ 1.500,00 e R$ 3.000,00.
b. Posicionamento
Exemplo: produto de boa qualidade e preo intermedirio.
c. Estratgia do mix: produto, preo, distribuio e promoo.
Exemplo: o produto a ser comercializado ser o relgio
Champion, com qualidade sua, modelo quartzo, linha esportiva,
plstico resistente, prova dgua e com pulseiras intercambiveis de
vrias cores. A marca Champion; o produto ter garantia de 4 anos;
seu preo de R$ 50,00; ser distribudo por varejistas, principalmente
relojoarias e lojas de departamentos. Quanto propaganda, ser
utilizado um outdoor no lanamento, filmes de 15 na TV e anncios
nas revistas. Quanto promoo de vendas: promoo junto aos
varejistas com uso de displays e cartazes; relaes pblicas: assessoria
de imprensa.
4. Plano de Ao: para cada atividade, descrever encarregado, perodo e

oramento.
Exemplo:
Atividades Encarregado Perodo Oramento
Promoo: uso de outdoor Jos Silva Jan a mar de 2008 (incluir valores
no lanamento estimados)
Filmes de 15 na TV: Jos Silva Jan a jul de 2008 (incluir valores
Globo e Bandeirantes estimados)
Anncios em revistas: Veja Maria Silva Mar de 2008 (incluir valores
e Exame estimados)
5. Projeo de vendas e lucros: para cada perodo, estabelecer vendas e

lucros e fazer observaes pertinentes.
A4.13 PLANO DE PROJETO

ID Projeto:
HISTRICO DE REVISES

atualizao de
Mudana
1. ESCOPO DO PROJETO
1.1 Cenrio
< Identificar as necessidades que motivaram o cliente a solicitar o projeto, definir os stakeholders e usurios do sistema (quem so
e quais as necessidades de cada um) e descrever as expectativas que o projeto visa atender >
1.2 Entregas do Projeto

<As entregas so desdobramentos do produto de projeto em resultados tangveis. Podem ser fsicas ou uma mudana de estado visvel. A
caracterstica fundamental das entregas a capacidade de serem medidas e avaliadas. Por ex: documento de requisitos, relatrio de teste,
etc.>
1.3 Premissas, Limitaes e Restries do Projeto
1.4 Critrios de aceitao do cliente

< Descrever como o projeto atender s expectativas do cliente e itens de sucesso para o cliente, tal como antecipao de prazos.>
1.5 Estratgias
1.6 Prazos Mximos
1.7 Custo e Preo-Meta
2. PLANO DE RECURSOS
<Aqui devem ser descritos todos os recursos (equipamentos fsicos, tais como hardware, impressora e outros perifricos) necessrios para o
desenvolvimento do software.>
3. PLANO DE HABILIDADES E CONHECIMENTO

<Aqui devem ser descritos todos os conhecimentos e habilidades necessrios para o desenvolvimento do software e na frente de cada um
deles, sugerir colaboradores que possam participar como integrantes do projeto>
4. RISCOS
Tabela de Riscos
Descrio Escala Probabi- Impacto Prioridade Aes % Risco
lidade do projeto
< Lista de possveis riscos: Horas extras; Rotatividade/perda de colaboradores; Necessidade de equipamentos; Falta de colaborao do
cliente; Falta de conhecimento do domnio>
5. PLANO DE TESTES
Referncia bibliogrfica: Introduo ao Teste de Software
5.1 Critrios de Teste de Unidade
5.2 Critrios de Teste de Integrao
5.3 Teste de Validao

Tempo mximo:
5.4 Ferramentas de Teste
5.5 Equipamentos Necessrios
APNDICE 1: PLANO DE CONTINGNCIA

<inserir aqui o plano de contingncia>
ANEXO 1: CRONOGRAMA
ID:
ANEXO 2: FLUXO DE CAIXA (PARA MONITORAMENTO)

ID:
ANEXO 3: RELATRIO DE VIABILIDADE DO PROJETO

ID:
ANEXO 4: DOCUMENTO DE REQUISITOS

ID:
ANEXO 5: PLANILHA DE TESTE

A4.14 PROJETO INTERFACE HOMEM-MQUINA

ID Projeto:
Documento de requisitos:
HISTRICO DE REVISES

atualizao de
Mudana
1 Perfil do Usurio
< Para cada tipo de usurio previsto, os projetistas devem conhecer seus atributos
pessoais (faixa etria, sexo, limitaes, motivao) e suas habilidades e competncias
(na tarefa, na organizao e com sistemas informatizados).
Tipo de Faixa Sexo Limitaes Motivao Habilidades Competncias

Usurio etria
>
2 Princpios Gerais para o Projeto

< Pesquisa e catalogao do conhecimento ergonmico disponvel para a concepo
da interface no tipo de contexto de uso (usurio, tarefa, equipamento e ambiente) no
qual o sistema est inserido. Podem ser utilizados como referncia para a pesquisa e
catalogao do conhecimento ergonmico, os critrios ergonmicos propostos por
Scapin & Bastien (1993). Esses critrios so apresentados no Apndice 1.>
3 Padro de Telas
<So definidas regras para a escolha de controles, para a definio do formato e
localizao das telas, para a terminologia empregada, para o uso de cores, tipos de
fontes, etc.
Deve-se construir o layout das telas com base nessas regras. Inclusive, pode-se
construir uma maquete informatizada (considerada um prottipo executvel com baixa
fidelidade) de uma parte da interface, de modo que seja possvel um dilogo com o
usurio, sem uma base de dados. No que se refere modelagem de websites, a
ferramenta Denim uma alternativa e pode ser obtida gratuitamente no site
http://dub.washington.edu/projects/denim/download. Na falta de uma ferramenta
especializada, sempre possvel usar um editor de apresentaes, como o
PowerPoint. >
4 Mapa de Navegao
<Para representar o mapa de navegao pode ser utilizado o diagrama de transio
de estados, no qual os espaos de interao so representados por retngulos, e as
transies so representadas por flechas conectando espaos.>
Referncia: CYBIS, W.; BETIOL, A. H.; FAUST, R. Ergonomia e Usabilidade:

Conhecimentos, Mtodos e Aplicaes. So Paulo: Novatec Editora, 2007.
Ciclo de engenharia de usabilidade

Este modelo, proposto por Mayhew (1999), tem a mesma estrutura do modelo
proposto pela norma ISO 13407. Entretanto, o modelo de Mayhew fornece mais
detalhes sobre o contedo das atividades a serem realizadas em cada fase do
processo de desenvolvimento.
1) Anlise de Requisitos: os resultados das atividades dessa fase so utilizados
para especificar o contexto de uso e a usabilidade pretendida para o sistema.
As atividades dessa fase so:
Anlise do perfil do usurio: para cada tipo de usurio previsto, os
projetistas devem conhecer seus atributos pessoais (faixa etria,
sexo, limitaes, motivao) e suas habilidades e competncias (na
tarefa, na organizao e com sistemas informatizados).
Anlise do contexto da tarefa: para cada tarefa a ser apoiada pelo
sistema, os projetistas devem conhecer os objetivos e resultados, a
estrutura, a durao, as dependncias, os custos, a carga mental, as
interrupes, os incidentes, etc.
Anlise das possibilidades e restries da plataforma: so
examinadas as possibilidades e restries em termos de
equipamentos, sistemas operacionais, ambientes de janelas, recursos
de rede, a possibilidade de oferecer recursos em termos de manuais,
suporte, treinamento, etc.
Anlise de princpios gerais para o projeto: atividade de pesquisa
e catalogao do conhecimento ergonmico disponvel para a
concepo da interface no tipo de contexto de uso (usurio, tarefa,
equipamento e ambiente) no qual o sistema est inserido. Podem ser
utilizados como referncia para a pesquisa e catalogao do
conhecimento ergonmico, os oito critrios ergonmicos propostos
por Scapin & Bastien (1993). Esses critrios so apresentados no
Apndice 1.
Especificao do contexto de uso: o projetista especifica que tipo
de usurio ir operar o sistema para realizar que tipo de tarefa e em
que condies ambientais (qual software, equipamento, ambiente

fsico e organizacional).
Especificao das exigncias para a usabilidade: so
especificadas as exigncias qualitativas para a interface e
quantitativas para a usabilidade.
i. As exigncias qualitativas referem-se s funes e
caractersticas da interface de modo a satisfazer o tipo de
usurio. Por exemplo, se a maioria so idosos, ento uma
funo de zoom deveria ser implementada e esses usurios
deveriam fazer parte da populao de testes do sistema.
ii. As exigncias quantitativas referem-se ao nvel de usabilidade
esperado para o sistema. Essa especificao realizada em
termos de valores mnimos admissveis para os fatores bsicos
de usabilidade: eficcia, eficincia e satisfao do usurio
principalmente. Exemplo:
Objetivos da Medidas de Medidas de Medidas de
usabilidade eficcia eficincia satisfao
% de objetivos Tempo para Escala de
Usabilidade global alcanados completar a tarefa satisfao
% de usurios Tarefas Freqncia de uso
completando a completadas por
tarefa com unidade de tempo
sucesso
Mdia da acurcia Custo monetrio Freqncia de
de tarefas de realizao da reclamaes
completadas tarefa
2) Projeto, Testes e Implementao: os sucessivos ciclos dessas fases

envolvem trs verses de uma mesma interface: modelo conceitual da
interface, padro de telas e projeto detalhado da interface.
Modelo Conceitual da Interface: esse modelo pode ser definido como
representaes abstratas de alternativas de projeto, nas quais so
especificadas as principais telas e componentes da interface, bem como a
navegao entre elas. Para representar o modelo conceitual pode-se usar
uma maquete (prottipo em papel). Para representar o mapa de navegao
pode ser utilizado o diagrama de transio de estados, no qual os espaos
de interao so representados por retngulos, e as transies so
representadas por flechas conectando espaos.
Padro de Telas: so definidas regras para a escolha de controles, para a
definio do formato e localizao das telas, para a terminologia
empregada, para o uso de cores, tipos de fontes, etc. Pode-se construir
uma maquete informatizada (considerada um prottipo executvel com
baixa fidelidade) de uma parte da interface, de modo que seja possvel um
dilogo com o usurio, sem uma base de dados. No que se refere
modelagem de websites, a ferramenta Denim uma alternativa e pode ser
obtida gratuitamente no site
http://dub.washington.edu/projects/denim/download. Na falta de uma
ferramenta especializada, sempre possvel usar um editor de
apresentaes, como o PowerPoint.
Projeto Detalhado da Interface: os aspectos definidos no modelo conceitual
e no padro de telas so integrados.
3) Instalao: depois que o usurio j est acostumado em utilizar o software, o
seu feedback valioso para: detectar e eliminar problemas e preparar um novo
release do produto; detectar oportunidades para melhoria de novas verses do

produto e elaborar requisitos para novos produtos similares. Para coletar esse
feedback so utilizados testes de usabilidade no local de trabalho dos usurios
ou mtodos de anlise, tais como observaes, entrevistas e questionrios.
As tcnicas de avaliao, a seguir apresentadas, tm como foco duas

qualidades: a ergonomia das interfaces e a usabilidade dos sistemas. A ergonomia
a qualidade da adaptao de um dispositivo a seu operador e tarefa que este
realiza. A usabilidade se revela quando usurios empregam o sistema para
alcanar seus objetivos em um determinado contexto de operao, sendo
caracterizada pelo nvel de eficcia, eficincia e satisfao alcanado pelo usurio
durante o seu uso (conforme ISO 9241:11). Algumas alternativas de questionrio
de satisfao podem ser encontradas em
http://www.usabilitynet.org/tools/r_questionnaire.htm, tais como: SUMI Software
Usability Measurement Inventory (5 fatores; 50 questes)
http://www.ucc.ie/hfrg/questionnaires/sumi/index.html; SUS System Usability
Scale (10 questes). Uma alternativa interessante a verso em portugus do
questionrio ISONORM, desenvolvida por Medeiros (1999),
http://teses.eps.ufsc.br/defesa/pdf/1073.pdf.
As inspees de ergonomia, por meio de listas de verificao, permitem que

profissionais, no necessariamente especialistas em ergonomia, identifiquem
problemas menores e repetitivos das interfaces. As normas ISO 9241, partes 10 a
17, fornecem listas de verificao de ergonomia bem-definidas, assim como as
listas de verificao fornecidas pelo site ErgoList
(http://www.labiutil.inf.ufsc.br/ergolist).
Os testes de usabilidade tm como foco de avaliao a qualidade das
interaes que se estabelecem entre usurios e o sistema. Um teste de
usabilidade envolve usurios reais ou representativos da populao-alvo do
sistema interagindo com ele para realizar tarefas especficas em um contexto de
operao real ou simulado.
APNDICE 1 - Critrios Ergonmicos segundo Scapin & Bastien (1993)

o Conduo: a interface deve aconselhar, orientar, informar e conduzir o usurio na
interao com o sistema. Essa qualidade pode ser analisada a partir de quatro
sub-critrios:
Convite: engloba os meios utilizados para levar o usurio a realizar
determinadas aes. Uma interface convidativa apresentar: ttulos claros
para as tarefas, janelas e caixas de dilogo; informaes claras sobre o
estado (disponvel, em foco selecionado, etc) dos componentes do sistema;
informaes sobre o preenchimento de um formulrio, sobre as entradas
esperadas; opes de ajuda claramente indicadas.
Agrupamento/Distino de itens: a rpida compreenso de uma tela pelo
usurio depende, dentre outros itens, do posicionamento, da ordenao e
da forma dos objetos (imagens, textos, comandos, etc) apresentados. Esse
critrio composto pelos seguintes sub-critrios: agrupamento/distino
por localizao (quando o usurio percebe rapidamente os grupamentos a
partir da localizao das informaes nas interfaces) e
agrupamento/distino por formato (quando o usurio percebe rapidamente
as similaridades ou diferenas entre as informaes, a partir da forma
grfica de componentes da interface, como tamanho, cor da figura e do
fundo, estilo dos caracteres, etc).
Legibilidade: diz respeito s caractersticas que possam dificultar ou facilitar

a leitura das informaes textuais. Deve ser considerada, principalmente,
quando os usurios so pessoas idosas ou com problemas de viso (baixa
viso). Em uma interface legvel: o texto longo que deve ser lido
rapidamente aparece em letras maisculas e minsculas naturalmente ao
invs de somente com maisculas; o texto apresentado em linhas com
comprimento adequado e com um contraste efetivo com o fundo; o texto
que deve ser lido por idosos ou pessoas com problemas de viso aparece
em letras claras sobre um fundo escuro. Para essas pessoas, o fundo
brilhante pode ofuscar completamente as letras escuras.
Feedback imediato: est a servio de todos, porm os mais novatos
precisaro mais dessa qualidade. Uma interface que fornece feedback de
qualidade: relata ao usurio o recebimento de todas as entradas por ele
efetuadas (as entradas confidenciais so relatadas de modo a no revelar o
seu contedo, por exemplo, com asteriscos); indica ao usurio que um
tratamento demorado est sendo realizado, bem como a sua concluso e o
seu resultado.
o Carga de trabalho: esse critrio se aplica, principalmente, a um contexto de
trabalho intenso e repetitivo, no qual os profissionais que operam o sistema
precisaro de interfaces econmicas sob o ponto de vista cognitivo e motor, ou
seja, que lhes economizem leitura e memorizao desnecessrias, assim como
deslocamentos inteis e repetio de entradas. Os sub-critrios desse so:
Brevidade: as qualidades inerentes a esse so a conciso e as aes
mnimas. Uma interface concisa apresenta ttulos (de telas, janelas e caixas
de dilogo), rtulos (de campos, de botes e de comandos) e
denominaes curtas; apresenta cdigos arbitrrios (nome de usurio,
senha) curtos; fornece valores default (para os campos de dados, lista,
check boxes) capazes de acelerar as entradas individuais e fornece o
preenchimento automtico de vrgulas, pontos decimais e zeros direita da
vrgula nos campos de dados. Uma interface gil no solicita aos usurios
dados que podem ser deduzidos pelo sistema; no fora o usurio a
percorrer em seqncia todas as pginas de um documento de modo a
alcanar a pgina especfica e no solicita o mesmo dado ao usurio
diversas vezes em uma mesma seqncia de dilogo.
Densidade informacional: critrio a servio principalmente de usurios
iniciantes, os quais podem encontrar dificuldades para filtrar a informao
de que necessitam em uma tela carregada. Uma interface minimalista
apresenta somente os itens que esto relacionados tarefa (o restante
deve ser removido da tela); no fora os usurios a transportar
mentalmente dados de uma tela a outra; no fora os usurios a realizar
procedimentos complicados, como a transformao da unidade de medida;
no coloca os usurios diante de tarefas cognitivas complexas, como as de
especificao de buscas avanadas.
o Controle explcito: aplica-se em particular s tarefas longas seqenciais e nas
quais os processamentos so demorados. Seus sub-critrios so:
Aes explcitas do usurio: refere-se ligao explcita que deve existir
entre uma ao do usurio e um processamento do sistema. A interface
explicitamente comandada sempre solicita uma ao explcita do usurio
de validao global em um formulrio para entrada de diversos dados ou
parmetros; separa as aes de seleo de uma opo e de ativao
dessa opo quando se referir a um tratamento demorado (exemplo: tela
de assistente para novas conexes do windows); no coloca o usurio

diante de comandos de dupla repercusso (por exemplo, salvar + fechar).
Controle do usurio: em realizao de aes longas seqenciais e de
tratamento demorado, os usurios devem estar no controle dos
acontecimentos. Cada possvel ao do usurio deve ser antecipada e as
opes apropriadas devem ser oferecidas. Em uma interface controlada
pelo usurio: a) o cursor no se desloca de um campo a outro em um
formulrio como efeito colateral das entradas dos usurios (validao
[enter]) ou do preenchimento completo de um dado de comprimento
controlado (campo senha, por exemplo); ele o faz como efeito do comando
explcito de tabulao ([tab]); b) o usurio encontra as opes para
comandar o avano, o recuo, a interrupo, a retomada ou a finalizao de
um dilogo seqencial (exemplo: tela de artigo publicado em peridico do
currculo lattes); c) o usurio encontra as opes para comandar a
interrupo, a retomada ou a finalizao de tratamentos demorados.
o Adaptabilidade: qualidade esperada em sistemas em que o pblico-alvo vasto e
variado. Para que todos tenham direito ao mesmo nvel de usabilidade, a interface
deve propor maneiras variadas de realizar uma tarefa, deixando ao usurio a
liberdade de escolher e dominar uma delas no curso de seu aprendizado. Deve
permitir que o usurio adapte as apresentaes e estilos de dilogo a suas
necessidades. Os sub-critrios so:
Flexibilidade: envolve duas qualidades diferenciadas a flexibilidade
estrutural e a personalizao. Uma interface estruturalmente flexvel
fornece aos usurios diferentes maneiras de realizar a entrada de dados
(por digitao, por seleo); diferentes caminhos para chegar a uma
funcionalidade freqentemente utilizada (cone na barra de ferramenta,
opo em um painel de menu, atalho de teclado) e diferentes opes de
formato de arquivos e de unidades para os dados (exemplo: telas de
configurao de cores do MS Office, nas quais o usurio pode selecionar
uma cor padronizada ou definir uma outra personalizada digitando seu valor
no sistema RGB ou clicando sobre um ponto na rea de cores). Uma
interface personalizvel oferece a possibilidade de o usurio personalizar
as telas, inserindo ou retirando cones, dados ou comandos (exemplo:
formatos de apresentao dos arquivos/diretrios pelo gerenciador de
arquivos Explorer); definir seqncias de aes automticas (macros);
alterar os valores default oferecidos pelo sistema.
Considerao da experincia do usurio: uma interface que considere a
experincia do usurio fornece aos especialistas atalhos que permitem
acesso rpido s funes do sistema e fornece aos usurios intermitentes
dilogos passo a passo.
o Gesto de erros: esse critrio se aplica a todas as situaes. A gesto de erros diz
respeito a todos os mecanismos que permitem evitar ou reduzir a ocorrncia de
erros que favoream sua correo. Seus sub-critrios so:
Proteo contra os erros: diz respeito aos mecanismos empregados para
detectar e prevenir os erros de entradas de dados ou de comandos, e
impedir que aes de conseqncias desastrosas e/ou no recuperveis
ocorram. Uma interface que protege a interao contra erros informa ao
usurio sobre o risco de perda de dados no-gravados ao final de uma
sesso de trabalho; no oferece um comando destrutivo como opo
default e detecta os erros j no momento da digitao de uma entrada
individual em vez de faz-lo apenas no momento da validao do formulrio
inteiro.
Qualidade das mensagens de erro: refere-se pertinncia, legibilidade e

exatido da informao dada ao usurio sobre a natureza do erro
cometido e sobre as aes a serem executadas para corrigi-lo. Uma boa
mensagem de erro indica ao usurio a razo ou a natureza do erro
cometido, o que ele fez de errado, o que deveria ter feito e o que deve fazer
para sair da situao de erro; orientada para a tarefa, emprega termos
especficos e breve; tem um tom neutro (nem reprovador e nem
humorstico).
Correo dos erros: diz respeito aos meios colocados disposio do
usurio com o objetivo de permitir a correo de seus erros. H facilidade
na correo de erros quando a interface fornece funes desfazer e
refazer; fornece a possibilidade de o usurio refazer apenas a parte errada
de uma entrada (indica o dado errado em um formulrio, mantendo todos
os outros intactos); fornece ligao direta entre o relatrio de erro e o local
onde ele se produz.
o Homogeneidade/consistncia: critrio que se aplica de forma geral, mas em
particular quando os usurios so novatos ou intermitentes. Este critrio refere-se
forma na qual as escolhas no projeto da interface (cdigos, denominaes,
formatos, procedimentos, etc) so conservadas idnticas em contextos idnticos e
diferentes para contextos diferentes. Em uma interface homognea os cdigos e
denominaes so definidos pelos mesmos critrios em contextos idnticos; a
distribuio, a apresentao e a denominao dos objetos nas telas so
padronizadas; a sintaxe dos procedimentos padronizada (utiliza os mesmos
meios para obter os mesmos resultados).
o Significado de cdigos e denominaes: critrio que se aplica de forma geral, mas
em particular quando os usurios so novatos ou intermitentes. Em uma interface
significativa os nomes de funes e objetos de interao so familiares para os
usurios; os cdigos so representativos do contedo que veiculam e so distintos
(por exemplo: M masculino / F feminino, em vez de 1 homens e 2
mulheres); as abreviaes so de imediata interpretao.
o Compatibilidade: diz respeito ao grau de similaridade entre diferentes sistemas que
so executados em um mesmo ambiente operacional (windows, mac, openlook).
Trata-se de um tipo de consistncia externa entre aplicativos de um mesmo
ambiente. Em uma interface compatvel a transferncia de informaes do
contexto da tarefa para o do sistema mais rpida e eficaz; os procedimentos e as
tarefas so organizados de maneira a respeitar expectativas ou costumes do
usurio; as tradues, as transposies, as interpretaes ou referncias
documentao so minimizadas (as telas so compatveis com os documentos em
papel, as denominaes de comandos so compatveis com o vocabulrio do
usurio, etc.); a informao apresentada de forma diretamente utilizvel.
Dentre algumas recomendaes ergonmicas para Interface Homem-

Computador (IHC), coletadas da ISO 9241 (Requisitos Ergonmicos para o trabalho
de escritrio informatizado), sero apresentadas algumas referentes a cores utilizadas
na interface. Os esteretipos naturais mais populares indicam os seguintes empregos
para as cores:
Vermelho: deve ser utilizada para perigo, alarme, ateno, alerta, calor e
comandos de interrupo;
Amarelo: para advertncias, teste e lentido.
Verde: para passagem livre, normalidade, vegetao e segurana.
Laranja: para valor-limite e radiao;
Azul: para frio, gua, cu e calma;

Cinza: para inatividade, neutralidade.
importante lembrar que deve ser evitada a codificao de significado por
meio de cores que no sejam vistas por pessoas que sofrem de daltonismo, uma
alterao gentica caracterizada pela falta de um tipo de clula perceptiva para as
cores vermelha e/ou verde e/ou azul. O tipo de daltonismo mais freqente impe
dificuldade para que os portadores faam a distino entre o verde e o vermelho.
Recomenda-se que sejam usadas poucas cores, sendo cores neutras, com o
mesmo brilho e que as cores brilhantes sejam usadas com cautela. Uma forma
interessante de usar as cores explorar as sensaes que estas causam sobre as
pessoas: o verde descansa, o vermelho atrai a ateno e pode causar irritao, o azul
d sono e o amarelo desperta.
Quanto s recomendaes sobre o emprego de fontes, aconselha-se no usar
serifa (caracterizada por uma terminao saliente nos caracteres) para vdeos de
baixa resoluo. Mas, serifas devem ser empregadas em textos longos, como forma
de facilitar o reconhecimento rpido dos caracteres. J nos ttulos e rtulos curtos,
deve-se empregas fontes sem serifa. No utilize fontes menores que 12 pontos para
telas e menores que 10 pontos para material impresso. Limite o uso de fontes
diferentes para textos em at dois tipos. Evite fontes muito grandes que gritem com o
usurio. Evite textos s com maisculas e no exagere com o sublinhado, o negrito e
o itlico. As fontes mais populares e indicadas a serem usadas so:
Arial: para ttulos e cabealhos de documentos;
Avant Garde: grandes ttulos;
Courrier: documentos impressos, cartas padronizadas, correspondncia;
Helvtica: relatrios, ttulos de captulos, de sees, cdigos de programas;
Letter gothic: texto que deve ser simples e claro;
Romano: correio padronizado;
Times: documentos diversos, de mltiplo uso, comentrios em programas;
Ultraback: etiquetas de embalagens.
A4.15 PROPOSTA COMERCIAL

ID Projeto: ID Proposta Tcnica:
HISTRICO DE REVISES

atualizao de
Mudana
1. DADOS DO CLIENTE
Razo Social:
CNPJ: Contato:
Endereo:
Telefones:
2. CRONOGRAMA DE ENTREGAS
<inserir aqui o cronograma de entregas, com base na WBS>
3. CONDIES DE PAGAMENTO
Preo:
Cronograma de pagamentos
4. VALIDADE DA PROPOSTA
Data:
A4.16 PROPOSTA TCNICA

ID Projeto:
HISTRICO DE REVISES

atualizao de
Mudana
1. DADOS DA EMPRESA DE DESENVOLVIMENTO

Razo Social:
CNPJ:
Endereo:
Telefones:
Contato:
2. ID DO DOCUMENTO DE REQUISITOS
A4.17 RELATRIO DE ACOMPANHAMENTO DO PROJETO

ID Projeto:
HISTRICO DE REVISES
atualizao de
Mudana
DADOS DO RELATRIO
Data da Entrega avaliada Resultado da avaliao Responsveis Aes Corretivas

avaliao
A4.18 RELATRIO DE ANLISE DO CONTRATO
ID documento: Data: / /
ID Contrato:
HISTRICO DE REVISES

atualizao de
Mudana
ALTERAES SOLICITADAS PELO CLIENTE
ALTERAES PROMOVIDAS NO CONTRATO

A4.19 RELATRIO DE ANLISE DA PROPOSTA
ID Proposta:
HISTRICO DE REVISES

atualizao de
Mudana
ALTERAES SOLICITADAS PELO CLIENTE
ALTERAES PROMOVIDAS NA PROPOSTA

A4.20 RELATRIO DE ANLISE DOS REQUISITOS
ID Projeto:
HISTRICO DE REVISES

atualizao de
Mudana
1. Conflitos relacionados ao Modelo de Negcio

<Inserir aqui os conflitos relacionados ao modelo de negcio (relacionado ao
processo de negcio, s regras de negcio) e a soluo adotada depois de
esclarecido o conflito junto ao cliente.>
2. Conflitos entre requisitos

<Inserir aqui o identificador dos requisitos conflitantes (a partir do Documento
de Requisitos), a descrio desses requisitos e a soluo adotada depois de
esclarecido o conflito junto ao cliente.>
ID. Requisitos conflitantes:

Descrio dos requisitos:
Soluo:

Soluo:

Soluo:
4.21 RELATRIO SOBRE GARANTIA DE QUALIDADE
ID Projeto:
HISTRICO DE REVISES

atualizao de
Mudana
Avaliaes
Data da Objetivo Responsveis No conformidades Sugestes de melhoria Data de comunicao
avaliao avaliado pela avaliao aos interessados
(produto ou
processo. No caso
de produto,
discriminar)
A4.22 RELATRIO DE VIABILIDADE DO PROJETO

ID Projeto:
HISTRICO DE REVISES

atualizao de
Mudana
<Apresentar a alternativa definida, considerando as viabilidades tcnica,

econmica e legal, destacando as vantagens/desvantagens da alternativa com
base na relao custo X benefcio.>
1 VIABILIDADE TCNICA E ECONMICA/FINANCEIRA
Tabela de Custos
COST DRIVER
Definio Valor Unitrio Qtde Total
TOTAL R$ -
ESTIMATIVAS DE AQUISIO
Data Data Previso
Produto Preo
Solicitao Recebimento
TOTAL EM
R$ -
AQUISIO
CUSTO OPERACIONAL GERAL DO PRODUTO

2 RELAO CUSTO X BENEFCIO
3 SUGESTO DE PREO
4 CRONOGRAMA DE RECEBIMENTOS
Data de Recebimento Valor
Apndice: Fluxo de caixa do projeto

ID:
Fonte: Wikipedia
http://pt.wikipedia.org/wiki/Fluxo_de_caixa
http://pt.wikipedia.org/wiki/Dre
A Demonstrao do Resultado do Exerccio (DRE) uma demonstrao

contbil dinmica que se destina a evidenciar a formao do resultado lquido em um
exerccio, atravs do confronto das receitas, custos e despesas, apuradas segundo o
princpio contbil do regime de competncia.
A DRE oferece uma sntese financeira dos resultados operacionais e no
operacionais de uma empresa em certo perodo. Embora sejam elaboradas
anualmente para fins de legais de divulgao, em geral so feitas mensalmente para
fins administrativos e trimestralmente para fins fiscais.
Receita a entrada monetria que ocorre em uma Entidade (Contabilidade) ou

patrimnio (Economia), em geral sob a forma de dinheiro ou de crditos
representativos de direitos.
Custos so medidas monetrias dos sacrifcios financeiros com os quais uma

organizao, uma pessoa ou um governo, tm de arcar a fim de atingir seus objetivos,
sendo considerados esses ditos objetivos, a utilizao de um produto ou servio
qualquer, utilizados na obteno de outros bens ou servios. Custos so medidas
monetrias resultantes da aplicao de bens e servios na produo de outros bens e
servios durante o processo de fabricao.
Despesa, para a Contabilidade, o gasto necessrio para a obteno de receita. As

Despesas so gastos que no se identificam com o processo de transformao ou
produo dos bens e produtos.
As despesas esto relacionadas aos valores gastos com a estrutura administrativa e

comercial da empresa. Ex: aluguel, salrios e encargos, pr-labore, telefone,
propaganda, impostos, comisses de vendedores etc. Elas ainda so classificadas em
fixas e variveis, sendo as fixas aquelas cujo valor a ser pago no depende do
volume, ou do valor das vendas, enquanto que as variveis so aquelas cujo valor a
ser pago est diretamente relacionado ao valor vendido.
Em Finanas, o fluxo de caixa (designado em ingls por "cash flow"), refere-se

ao montante de caixa recebido e gasto por uma empresa durante um perodo de
tempo definido, algumas vezes ligado a um projeto especfico.
Na Contabilidade, uma projeo de fluxo de caixa demonstra todos os
pagamentos (direito) e recebimentos esperados em um determinado perodo de
tempo. O controlador de fluxo de caixa necessita de uma viso geral sobre todas as
funes da empresa, como: pagamentos, recebimentos, compras de matria-prima,
compras de materiais secundrios, salrios e outros, por que necessrio prever o
que se poder gastar no futuro dependendo do que se consome hoje.
O fluxo de caixa uma tima ferramenta para auxiliar o administrador de
determinada empresa nas tomadas de decises. atravs deste "mapa" que os
custos fixos e variveis ficam evidentes, permitindo-se desta forma um controle efetivo
sobre determinadas questes empresariais.
A4.23 ROTEIRO DE PROSPECO

HISTRICO DE REVISES

atualizao de
Mudana
<Devem ser descritos os passos a serem seguidos para a prospeco do

cliente, de acordo com as abordagens definidas no item 4 (plano de ao) do
Plano de Marketing.>
A4.24 SISTEMA DE GESTO DE CONHECIMENTO
HISTRICO DE REVISES
atualizao de
Mudana
1. Infra-estrutura
< Aqui descrita a infra-estrutura para apoiar a realizao das atividades de gesto de
conhecimento. Por exemplo, a utilizao de alguma ferramenta>
2. Estratgia
< Aqui descrita a estratgia para captura, armazenamento, compartilhamento e
utilizao do conhecimento.>
3. Tipologia do conhecimento
< Aqui descrita a tipologia do conhecimento, a fim do conhecimento ser classificado
para facilitar a sua utilizao>
A4.25 BANCO DE DADOS DE CONFIGURAO
Este template composto por cinco planilhas: histrico de revises, itens de

configurao, controle de mudanas, planejamento de mudanas e baselines.
HISTRICO DE
REVISES DO
DOCUMENTO
Data de criao/ atualizao Descrio da(s) Mudana(s) Autor Verso do Documento ID. Solicitao de
Ocorrida(s) Mudana
Planilha Histrico de Revises
Id. Item Configurao DocReq_EMP

Responsvel Engenheiro de Requisitos (Pedro)
Data Criao/Atualizao 01/10/08
Verses do IC V0.1
Status da verso do IC em desenvolvimento
Id. solicitao de mudana Mudana_EMP_0001
Data de incio da realizao da mudana 5/10/2008
Data de trmino da realizao da mudana 6/10/2008
Descrio da Mudana Ocorrida Foram adicionados novos requisitos
Verificao/Validao
Comentrios
Id. Item Configurao PlanoProj_EMP

Responsvel
Data Criao/Atualizao
Verses do IC V0.1
Status da verso do IC em desenvolvimento baselined liberada
Id. solicitao de mudana
Data de incio da realizao da mudana
Data de trmino da realizao da mudana
Descrio da Mudana Ocorrida
Verificao/Validao
Comentrios
Planilha Itens de Configurao
Descrio da Tipo de Mudana Data da

Id. Solicitao de Origem (interna ou Data de Autorizao Quem autorizou/ Id. do
Mudana a ser (simples ou Solicitante autorizao/no
Mudana externa) solicitao (sim/no) no autorizou Contrato
realizada complexa) autorizao
Planilha Controle de Mudanas
Data Estimada Data Estimada do

Responsvel pelo ID dos itens de Custo para Alterao do
Id. Solicitao Esforo Total do Incio da Trmino da Colaboradores
planejamento da ID Cronograma configurao a efetivao da contrato? Comentrios
de Mudana estimado realizao da realizao da estimados
mudana serem afetados mudana ("sim"/"no")
mudana mudana
Planilha Planejamento de Mudanas

Identificador da Baseline Baseline_EMP_0001

Gerente de Projeto que autorizou Ana
Data de autorizao/criao 20/10/2008
Status liberada
DocReq_EMP_V0.1
PlanoProj_EMP_V0.1
Itens de configurao e verses
Identificador da Baseline
Gerente de Projeto que autorizou
Data de autorizao/criao
Status bloqueada
Itens de configurao e verses
Planilha Baselines
A4.26 CONTROLE DE PROJETOS
Este template composto por nove planilhas: histrico de revises, identificao de

projetos, acompanhamento de projetos, identificao de recursos, alocao de recursos,
identificao de colaboradores, alocao de colaboradores, notas fiscais e duplicatas.
HISTRICO DE
REVISES DO
DOCUMENTO
Ocorrida(s) Mudana
ID Projeto Descrio Pasta Fsica Pasta Lgica

projeto 1 sim sim
projeto 2
projeto 3
Planilha Identificao de Projetos
CONTROLE DE
PROJETOS
Data Ciclo de
ID Projeto Situao Data Inicializao Fase Data Incio da Fase Data Trmino da Fase
Formalizao Desenvolvimento
projeto 1 formalizado Elaborao It.01
CONTROLE DE
PROJETOS
Hs/Trabalho Hs/Trabalho Hs/Trabalho Hs/Trabalho

ID Projeto Recurso1 Recurso2 Recurso3 Recurso4 Recurso5 Colaborador1 Colaborador2 Colaborador3 Colaborador4
Colaborador1 Colaborador2 Colaborador3 Colaborador4
projeto 1 recurso2 recurso5 recurso2 recurso1 recurso6 colaborador4 colaborador3
CONTROLE DE
PROJETOS
Hs/Trabalho
ID Projeto Colaborador5 ID Contrato
Colaborador5
projeto 1
Planilha Acompanhamento de Projetos
Id. Recurso Descrio Tipo

recurso1 hardware
recurso2 hardware
recurso3 plataforma
recurso4
Planilha Identificao de Recursos
Previso de trmino
Recurso Data de Alocao Status Id. Projeto
da alocao
recurso1 reservado projeto 1
Planilha Alocao de Recursos

Id. Colaborador Descrio Categoria de Conhecimento Conhecimento Nvel

colaborador1 Design Junior
colaborador2 Requisitos elicitar requisitos Trainee
colaborador3
colaborador4
colaborador5
Planilha Identificao de Colaboradores
Previso de trmino
Colaborador Data de Alocao Status Id. Projeto
da alocao
colaborador1 alocado projeto 2
colaborador3
Planilha Alocao de Colaboradores
Cliente Data de emisso Valor Valor da Alquota Valor Total da Nota ID Projeto
nome do cliente/empresa3 R$ 5.000,00 R$ 5.000,00 projeto 1
Planilha Notas Fiscais
Nr da Duplicata Data de Vencimento Valor N da NF Status

1 10/10/2008 R$ 2.500,00 1 paga
2 10/11/2008 R$ 2.500,00 1 emitida
Planilha Duplicatas
A4.27 CONTROLE DE TAREFAS
Este template composto por duas planilhas: histrico de revises e lista de tarefas.
HISTRICO DE
REVISES DO
DOCUMENTO
Ocorrida(s) Mudana
ID Projeto:
Tempo mximo (de

acordo com o Qtde de
Tarefas Incio Trmino
estabelecido no hs/trabalhadas no dia
cronograma)
Tarefa1 16 hs 22/10/2008 4 hs
23/10/2008 8 hs
24/10/2008 4 hs 24/10/2008
Tarefa 2
Planilha Lista de Tarefas

A4.28 CRONOGRAMA
Este template composto por duas planilhas: histrico de revises e cronograma.
HISTRICO DE
REVISES DO
DOCUMENTO
Ocorrida(s) Mudana
Precedncia Durao (dias ou hs) Incio Trmino Recursos

Ciclo de Desenvolvimento 1
Fase 1 - Elaborao
Documento de Requisitos, Modelo de Negcio e Projeto IHM (entregas)
E01. Detalhar requisitos (pacote de trabalho)
* Detalhar/atualizar o "Modelo de Negcio"

* Detalhar/Atualizar os requisitos funcionais do captulo 2 do
Documento de Requisitos e registrar no captulo 3 deste documento
* Detalhar/Atualizar os requisitos de interface externa e outros
requisitos no funcionais (tais como requisitos de documentao, de
manuteno) do captulo 2 do Documento de Requisitos e registrar no
captulo 3 deste documento
* Elaborar o Projeto IHM

- Caso o perfil dos usurios no tenha sido definido na fase de
concepo, criar Projeto IHM (conforme GCf01), obter perfil dos usurios e
registrar no "Projeto IHM"
- A partir do perfil dos usurios, definir os princpios gerais do
projeto (com base em critrios ergonmicos)
- Definir/Atualizar o padro de telas no arquivo "Projeto IHM"
- Definir/Atualizar o mapa de navegao no arquivo "Projeto IHM"
* Criar/Atualizar a matriz de rastreabilidade entre requisitos do cliente

e do produto no Documento de Requisitos
* Criar/Atualizar a matriz de rastreabilidade entre requisitos funcionais

e no funcionais do produto no Documento de Requisitos
Documento de Requisitos, Relatrio de Anlise dos Requisitos

E02. Verificar e Validar os requisitos
Arquitetura do Software, Documento de Requisitos e Modelo de Design
E03. Definir soluo de projeto
Lista de Tarefas
E04. Detalhar o cronograma
Planilha de Teste, Plano de Projeto, Cronograma
E05. Definir tcnicas e critrios para V&V
E08. Conduzir reviso do milestone: Arquitetura do Software
Planilha Cronograma
A4.29 FLUXO DE CAIXA
Este template composto por dez planilhas: histrico de revises, investimentos,

despesas fixas, mo de obra, despesas variveis, impostos, receitas, DRE, projeo de fluxo
de caixa e demonstrativo de receita e despesas.
HISTRICO DE
REVISES DO
DOCUMENTO
Ocorrida(s) Mudana
Descrio Qtde Valor Unitrio Valor Total

Infra-estrutura necessria
Hardware
Software
Tempo necessrio para
desenvolvimento do
produto padro (se for o
caso)
Outros tipos de
investimento inicial
TOTAL R$ -
Planilha Investimentos
Descrio Ms 1 Ms 2 Ms 3 Ms 4 Ms 5 Ms 6 Ms 7 Ms 8 Ms 9 Ms 10 Ms 11 Ms 12
PRO-LABORE DOS SCIOS
gua, luz, telefone
Aluguel, condomnio, IPTU
Escritrio de Contabilidade
Limpeza
Tarifas Bancrias
Marketing & Publicidade
Internet
Treinamentos e Viagens
Manuteno e Conservao
Total R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ -
Planilha Despesas Fixas
ms 1 ms 2
Descrio Valor hr/trab Hs/trab Salrio % de Encargos Encargos Salrio+Encargos Qtde Total Qtde Total
Programador R$ - R$ - R$ - R$ - R$ -
Engenheiro de Requisitos R$ - R$ - R$ - R$ - R$ -
Arquiteto de Software R$ - R$ - R$ - R$ - R$ -
Especialista em Teste R$ - R$ - R$ - R$ - R$ -
Gerente de Projetos R$ - R$ - R$ - R$ - R$ -
TOTAL R$ - R$ -
Planilha Mo de obra
Descrio Ms 1 Ms 2 Ms 3 Ms 4 Ms 5 Ms 6 Ms 7 Ms 8 Ms 9 Ms 10 Ms 11 Ms 12
Horas consultoria terceirizada
Horas desenvolvimento terceirizado
Comisso
Total R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ - R$ -
Planilha Despesas Variveis
Descrio Alquota Incidncia

Impostos Federais receita
Impostos Estaduais receita
Impostos Municipais receita
Planilha Impostos
Descrio Ms 1 Ms 2 Ms 3 Ms 4 Ms 5 Ms 6
Montante do Valor relativo s horas de customizao (produto padro)
Montante do Valor relativo s horas de desenvolvimento do Produto padro
Montante do Valor relativo s horas de desenvolvimento (on-demand)
Planilha Receitas
DEMONSTRAO DE RESULTADO
Ms 1 Ms 2 Ms 3 Ms 4 Ms 5
Receita Bruta R$ - R$ - R$ - R$ - R$ -
Montante do Valor relativo s horas de
customizao (produto padro) R$ - R$ - R$ - R$ - R$ -
desenvolvimento do Produto padro R$ - R$ - R$ - R$ - R$ -
desenvolvimento (on-demand) R$ - R$ - R$ - R$ - R$ -
( - ) Impostos R$ - R$ - R$ - R$ - R$ -
( - ) Comisso R$ - R$ - R$ - R$ - R$ -
( - ) Demais Despesas Variveis R$ - R$ - R$ - R$ - R$ -
( = ) Receita Lquida R$ - R$ - R$ - R$ - R$ -
( - ) Investimento Inicial R$ -
( - ) Custo do trabalho de
customizao/desenvolvimento R$ - R$ - R$ - R$ - R$ -
( - ) Custo do desenvolvimento do produto
padro
( = ) Margem Contribuio R$ - R$ - R$ - R$ - R$ -
( - ) Despesas Fixas R$ - R$ - R$ - R$ - R$ -
( = ) Resultado Final R$ - R$ - R$ - R$ - R$ -
Planilha DRE
ID PROJETO
jan fev mar abr mai jun

Receitas
Montante do Valor relativo s
horas de customizao (produto
padro)
horas de desenvolvimento do
Produto padro
horas de desenvolvimento (on-
demand)
Faturamento R$ - R$ - R$ - R$ - R$ - R$ -
Despesas
Impostos
Comisso
Demais Despesas Variveis
Investimento Inicial
Custo do trabalho de
customizao/desenvolvimento
Custo do desenvolvimento do
produto padro
Despesas Fixas
Gasto Total R$ - R$ - R$ - R$ - R$ - R$ -
Saldo de Caixa R$ - R$ - R$ - R$ - R$ - R$ -
Planilha Projeo de Fluxo de Caixa
DEMONSTRATIVO DE RECEITAS E DESPESAS DO ANO DE 2008

Janeiro Fevereiro Maro
% Relao % Relao % Relao

(Receita X (Receita X (Receita X
Valor Despesa) Valor Despesa) Valor Despesa)
Receita
Venda de Software 5.000,00 2.300,00 3.000,00
Mensalidades 2.000,00 2.300,00 2.600,00
------------------ ---------------- ---------------
7.000,00 4.600,00 5.600,00
Despesas
PRO-LABORE DOS SCIOS 700,00 10,00 900,00 19,57 1.200,00 21,43
gua, luz, telefone 300,00 4,29 300,00 6,52 300,00 5,36
Aluguel, condomnio, IPTU 200,00 2,86 200,00 4,35 200,00 3,57
Escritrio de Contabilidade 30,00 0,43 30,00 0,65 30,00 0,54
Limpeza 20,00 0,29 20,00 0,43 20,00 0,36
Tarifas Bancrias 50,00 0,71 50,00 1,09 50,00 0,89
Marketing & Publicidade 30,00 0,43 30,00 0,65 30,00 0,54
Internet 50,00 0,71 50,00 1,09 50,00 0,89
Treinamentos e Viagens 60,00 0,86 60,00 1,30 60,00 1,07
Manuteno e Conservao 230,00 3,29 230,00 5,00 230,00 4,11
Folha de Pagemento 800,00 11,43 800,00 17,39 800,00 14,29
Investimentos 0,00 0,00 200,00 4,35 0,00 0,00
------------------ ---------------- ---------------
1.670,00 23,86 1.870,00 40,65 2.170,00 38,75
Lucro 5.330,00 2.730,00 3.430,00

Planilha Demonstrativo de Receitas e Despesas
A4.30 LIES APRENDIDAS E CONHECIMENTO
Este template composto por duas planilhas: lies aprendidas e conhecimento.
TIPO
Lies Aprendidas rea de conhecimento Elemento
Planilha Lies Aprendidas
TIPO
Conhecimento rea de conhecimento Elemento
Planilha Conhecimento
Exemplo de Tipologia
rea de conhecimento
Engenharia de Requisitos
Planejamento de Projeto
Monitoramento e Controle de Projeto
Medio
Design
Codificao
Testes
Revises Formais
Estimativas
Gesto de Requisitos
Elementos
Templates
Atividades
Tarefas
Recursos
A4.31 LISTA DE CONTATOS
Este template composto por trs planilhas: histrico de revises, lista de contatos e
controle de visitas.
HISTRICO DE
REVISES DO
DOCUMENTO
Ocorrida(s) Mudana
Gargalos e Atividades e Solues

Contato chave dentro
Contatos Validados Endereo Completo Telefones E-mails para contato necessidades da Utilizadas na Empresa
da empresa
empresa e nvel de satisfao
nome do cliente/empresa1
Planilha Lista de Contatos
Data de
Data de E- Data do Interesse Data de Envio
Data da Solicitao
Contatos Validados mail Contato por da Proposta Data de Fechamento
Visita pelo cliente da
marketing Telefnico proposta para o cliente
Proposta
nome do cliente/empresa 25/08/08 30/08/08 sim 05/09/08 05/09/08 07/09/08 cancelado - 20/09/2008
Planilha Controle de Visitas

A4.32 MEMRIA ORGANIZACIONAL
Este template composto pela planilha: memria organizacional.
TIPO
Conhecimento rea de conhecimento Elemento
Planilha Memria Organizacional
Exemplo de Tipologia
rea de conhecimento
Engenharia de Requisitos
Planejamento de Projeto
Monitoramento e Controle de Projeto
Medio
Design
Codificao
Testes
Revises Formais
Estimativas
Gesto de Requisitos
Elementos
Templates
Atividades
Tarefas
Recursos
A4.33 PLANILHA DE TESTE
Este template composto por quatro planilhas: histrico de revises, casos de teste de
unidade, casos de teste de integrao e casos de teste de validao.
HISTRICO DE
REVISES DO
DOCUMENTO
Ocorrida(s) Mudana
ID Projeto:
Critrio de Teste:
Casos de Teste Definidos Resultado Esperado Resultado Obtido
Critrio de Teste:
Testes de regresso
Planilha Casos de Teste de Unidade, de Teste de Integrao e de Teste de Validao

A4.34 PLANO DE AO
Este template composto por trs planilhas: histrico de revises, plano de ao e

acompanhamento.
HISTRICO DE
REVISES DO
DOCUMENTO
Ocorrida(s) Mudana
PLANO DE AO
Plano de Marketing Relacionado:
Planejamento de Atividades Jan Fev Mar Abr Mai Jun Total

Email marketing Ligaes estimadas com
0
Contato Telefnico sucesso 0
Visita 0
Proposta 0
Fechamento 0
Custos - Recursos Jan Fev Mar Abr Mai Jun Total

Email marketing R$ -
Contato Telefnico Ligaes estimadas com R$ -
sucesso
Visita R$ -
Proposta R$ -
Fechamento R$ -
Custo - Pessoas Jan Fev Mar Abr Mai Jun Total Hs Total R$
Nome1 0 R$ -
Nome2 0 R$ -
Nome3 0 R$ -
Nome4 0 R$ -
Total 0 0 0 0 0 0 0 R$ -
Valor
Pessoas
hr/trab
Nome1
Nome2
Nome3
Nome4
Total Geral R$ -
Planilha Plano de Ao
Jan Fev Mar Abr Mai Jun Total

Atividades
Plan Real Plan Real Plan Real Plan Real Plan Real Plan Real Plan Real % Real
Email marketing Ligaes0com sucesso 0 0 0 0 0 0 0
Contato Telefnico 0 0 0 0 0 0 0 0
Visita 0 0 0 0 0 0 0 0
Proposta 0 0 0 0 0 0 0 0
Fechamento 0 0 0 0 0 0 0 0
Jan Fev Mar Abr Mai Jun Total

Custos
Plan Real Plan Real Plan Real Plan Real Plan Real Plan Real Plan Real % Real
Email marketing Ligaes0com sucesso 0 0 0 0 0 0 0
Contato Telefnico 0 0 0 0 0 0 0 0
Visita 0 0 0 0 0 0 0 0
Proposta 0 0 0 0 0 0 0 0
Fechamento 0 0 0 0 0 0 0 0
Planilha Acompanhamento
Apndice 5 Modelo ProcSoftVD (Mapeamento) P g i n a | 293
Apndice 5 Modelo ProcSoftVD (Mapeamento com o

CMMI e ISO/IEC 15504)
O Quadro A5.1 apresenta uma legenda com os smbolos (e suas respectivas
descries), utilizados no mapeamento das atividades do Modelo ProcSoftVD com o
CMMI-DEV e ISO/IEC 15504-5 (Quadros A5.2 a A5.7).
QUADRO A5.1 LEGENDA DO MAPEAMENTO DAS ATIVIDADES

Fases
P - Prospeco
CP - Concepo
N - Negociao
E - Elaborao
Ct - Construo
T - Transio
reas de Conhecimento
ACQ - Aquisio
GqPP - Garantia de Qualidade de Produto e Processo
GCf - Gesto de Mudanas e Configurao
GCo - Gesto de Conhecimento
CMMI Capability Maturity Model Integration (DEV Development)
SP - Specific Practices (prticas especficas)
RD - Requeriments Development (Desenvolvimento de Requisitos)
REQM - Requeriments Management (Gesto de Requisitos)
PP - Project Planning (Planejamento de Projeto)
VER - Verification (Verificao)
VAL - Validation (Validao)
TS - Technical Solution (Soluo Tcnica)
MA - Measurement and Analysis (Medio e Anlise)
SAM - Supplier Agreement Management (Gesto de Acordo com o Fornecedor)
PMC - Project Monitoring and Control (Monitoramento e Controle de Projeto)
PPQA - Process and Product Quality Assurance< (Garantia da Qualidade de Produto e
Processo)
PI - Product Integration (Integrao do Produto)
CM - Configuration Management (Gesto de Configurao)
ISO/IEC 15504-5 - An exemplar Process Assessment Model
BP - Base Practices (Prticas-base)
ENG.1 - Requirements elicitation (Elicitao de Requisitos)
ENG.2 - System requirements analysis (Anlise de requisitos de sistema)
ENG.3 - System architectural design (Projeto arquitetural de sistema)
ENG.4 - Software requirements analysis (Anlise de requisitos de software)
ENG.5 - Software design (Projeto de Software)
ENG.7 - Software construction (Construo de Software)
ENG.8 - Software testing (Teste de Software)
ENG.9 - System integration (Integrao de sistema)
ENG.10 - System testing (Teste de Sistema)
QUADRO A5.1 LEGENDA DO MAPEAMENTO DAS ATIVIDADES (CONT.)

ENG.11 - Software installation (Instalao do Software)
SUP.2 - Verification (Verificao)
SUP.3 - Validation (Validao)
SUP.7 - Documentation (Documentao)
SUP.8 - Configuration management (Gesto de Configurao)
MAN.3 - Project management (Gesto de Projeto)
MAN.6 - Measurement (Medio)
ACQ.1 - Acquisition preparation (Preparao da Aquisio)
ACQ.2 - Supplier selection (Seleo do Fornecedor)
ACQ.3 - Contract agreement (Acordo)
ACQ.4 - Supplier monitoring (Monitoramento do Fornecedor)
ACQ.5 - Customer acceptance (Aceitao do Cliente)
RIN.3 - Knowledge management (Gesto de Conhecimento)
QUADRO A5.2 M APEAMENTO DAS ATIVIDADES DA FASE DE PROSPECO

P01. Buscar contatos
CMMI-DEV ISO/IEC 15504-5
- -
P02. Prospectar cliente
- -
P03. Visitar cliente
RD - SP 1.1 Elicit Needs ENG.1.BP1: Obtain customer requirements and requests.
Obtain and define customer requirements and requests
through direct and continuous solicitation of customer and
user input.
P04. Criar infra-estrutura do projeto
- -
P05. Controlar custos despendidos na fase de prospeco
- -
QUADRO A5.3 M APEAMENTO DAS ATIVIDADES DA FASE DE CONCEPO

Cp01. Entender o negcio e as necessidades do cliente
RD - SP 1.1 Elicit Needs ENG.1.BP1: Obtain customer requirements and requests.
RD - SP 1.2 Develop the Customer Obtain and define customer requirements and requests
Requirements through direct and continuous solicitation of customer and
user input.
Cp02. Definir escopo do projeto
PP - SP 1.1 Estimate the Scope of the MAN.3.BP1: Define the scope of work. Identify the
Project projects objectives, motivation and boundaries and define
PP - SP 1.3 Define Project Lifecycle (este the work to be undertaken by the project.
objetivo especfico atendido ao ser MAN.3.BP2: Define project life cycle. Define a life cycle
utilizado esse modelo de processo and strategy for the project, appropriate to its scope,
proposto neste trabalho de pesquisa, context, magnitude and complexity. (esta prtica base
como ciclo de vida do projeto) atendida ao ser utilizado esse modelo de processo
PP - SP 2.7 Establish the Project Plan proposto neste trabalho de pesquisa, como ciclo de vida
RD - SP 1.1 Elicit Needs do projeto)
RD - SP 1.2 Develop the Customer MAN.3.BP10: Establish project plan. Define and maintain
Requirements project master plan and other relevant plans to cover the
project scope and goals, resources, infrastructure,
interfaces and communication mechanisms.
ENG.1.BP1: Obtain customer requirements and requests.
Obtain and define customer requirements and requests
through direct and continuous solicitation of customer and
user input.
Cp03. Determinar requisitos do produto
RD - SP 2.1 Establish Product and ENG.2.BP1: Establish system requirements. Use the
Product Component Requirements stakeholder requirements as the basis for defining the
required functions and capabilities of the system and
document in a system requirements baseline.
ENG.4.BP1: Specify software requirements. Define and
prioritize functional and nonfunctional requirements of the
software elements of the system and their interfaces and
document them in a software requirements specification.
Analyze the software requirements for correctness,
completeness, consistency, feasibility and testability.
Identify any derived requirements.
QUADRO A5.3 M APEAMENTO DAS ATIVIDADES DA F ASE DE CONCEPO (CONT.)

Cp04. Verificar e Validar os requisitos
RD - SP 3.3 Analyze Requirements ENG.1.BP2: Understand customer expectations. Ensure
RD - SP 3.5 Validate Requirements that both supplier and customer understand each
VER - SP 2.1 Prepare for Peer Reviews requirement in the same way. Review with customers their
VER - SP 2.2 Conduct Peer Reviews requirements and requests to better understand their
VER - SP 2.3 Analyze Peer Review Data needs and expectations and to check the feasibility and
VER - SP 3.1 Perform Verification appropriateness of their requirements.
VER - SP 3.2 Analyze Verification Results ENG.1.BP3: Agree on requirements. Obtain agreement
VAL - SP 2.1 Perform Validation across teams on the customer requirements, obtaining the
VAL - SP 2.2 Analyze Validation Results appropriate sign-offs by representatives of all teams and
other parties contractually bound to work to these
requirements.
ENG.2.BP3: Analyze system requirements. Prioritize
requirements and analyze the prioritized requirements for
correctness, completeness, consistency, feasibility and
testability, identifying the necessary elements of the
system. Identify changes to the operating environment.
SUP.2.BP3: Conduct verification. Verify identified work
products according to specified strategy.
SUP.2.BP4: Determine actions for verification results.
Defects detected by the verification should be identified,
recorded and entered into the Problem resolution process
(SUP.9).
SUP.3.BP3: Perform validation activities. Conduct
validation activities using identified techniques, processes,
and test cases against requirements and quality standards.
SUP.3.BP4: Identify problems. Issues detected by the
validation process should be identified, recorded and
entered into the Problem resolution management process
(SUP.9).
Cp05. Estudar solues alternativas de arquitetura do software
RD - SP 2.2 Allocate Product Component ENG.3.BP1: Describe system architecture. Establish the
Requirements top-level system architecture that identifies elements of
RD - SP 2.3 Identify Interface hardware, software and manual-operations.
Requirements ENG.3.BP2: Allocate requirements. Allocate all system
TS - SP 1.1 Develop Alternative Solutions requirements to the elements of the top-level system
and Selection Criteria architecture.
TS - SP 1.2 Select Product Component ENG.3.BP3: Define interfaces. Develop and document the
Solutions internal and external interfaces of each system element.
TS - SP 2.4 Perform Make, Buy, or Reuse ENG.3.BP4: Verify system architecture. Ensure that the
Analyses system architecture meets all stakeholder and system
requirements.
ENG.3.BP5: Evaluate alternative system architectures.
Define evaluation criteria for architecture design. Evaluate
alternative system architectures according to the defined
criteria. Record the rationale for choosing the current
system architecture.
ENG.4.BP2: Determine operating environment impact.
Determine the interfaces between the software
requirements and other elements of the operating
environment, and the impact that the requirements will
have.
ENG.5.BP1: Describe software architecture. Transform the
software requirements into a software architecture design
that describes the top-level structure and identifies its
major software elements.
ENG.5.BP2: Define interfaces. Specify and document the
external and internal interfaces between the software
elements.

Cp06. Definir/Redefinir cronograma do projeto
PP - SP 2.1 Establish the Budget and MAN.3.BP5: Define project activities and tasks. Identify
Schedule project activities and tasks according to defined project
PP - SP 2.7 Establish the Project Plan lifecycle, and define dependencies between them.
MAN.3.BP7: Define project schedule. Allocate resources to
activities and determine the sequence and schedule of
performance of activities within the project.
MAN.3.BP10: Establish project plan. Define and maintain
project master plan and other relevant plans to cover the
Cp07. Determinar estimativas de esforo e tempo
PP - SP 1.2 Establish Estimates of Work MAN.3.BP4: Determine and maintain estimates for project
Product and Task Attributes attributes. Define and maintain baselines for project
PP - SP 1.4 Determine Estimates of Effort attributes.
and Cost NOTE 1: Project attributes may include 1) business and quality goals for the
project, 2) size and complexity of the project and 3) project effort, schedule
PP - SP 2.7 Establish the Project Plan and budget.
MA - SP 2.1 Collect Measurement Data NOTE 2: Project quality goals and risks should be considered when
MA - SP 2.2 Analyze Measurement Data estimating project attributes. See Quality management process (MAN.4)
MA - SP 2.3 Store Data and Results and Risk management process (MAN.5) for details.
MAN.6.BP5: Collect and store measurement data. Identify,
collect and store measurement data, including context
information necessary to verify, understand, or evaluate
the data.
MAN.6.BP6: Analyze measurement data. Analyze and
interpret measurement data, and develop information
products.
MAN.6.BP7: Use measurement information products for
decision-making. Make accurate and current measurement
information products accessible for any decision-making
processes for which it is relevant.
Cp08. Verificar a viabilidade tcnica e financeira do projeto
PP - SP 1.4 Determine Estimates of Effort MAN.3.BP4: Determine and maintain estimates for project
and Cost attributes. Define and maintain baselines for project
PP - SP 2.7 Establish the Project Plan attributes.
MA - SP 2.1 Collect Measurement Data NOTE 1: Project attributes may include 1) business and quality goals for the
project, 2) size and complexity of the project and 3) project effort, schedule
MA - SP 2.2 Analyze Measurement Data and budget.
MA - SP 2.3 Store Data and Results NOTE 2: Project quality goals and risks should be considered when
estimating project attributes. See Quality management process (MAN.4)
and Risk management process (MAN.5) for details.
the data.
products.

Cp09. Planejar os recursos do projeto
PP - SP 2.4 Plan for Project Resources MAN.3.BP10: Establish project plan. Define and maintain
PP - SP 2.6 Plan Stakeholder Involvement project master plan and other relevant plans to cover the
PP - SP 2.7 Establish the Project Plan project scope and goals, resources, infrastructure,
SAM - SP 1.1 Determine Acquisition Type interfaces and communication mechanisms.
ACQ.1.BP1: Establish the need. Establish a need to
acquire, develop, or enhance a system, software product
or service.
ACQ.1.BP2: Define the requirements. Identify the
customer/stakeholder requirements for a system and/or
software product or service.
ACQ.1.BP3: Review requirements. Analyze and validate
the defined requirements against the identified needs.
Validate the requirements to reduce risk of
misunderstanding by the potential suppliers
Cp10. Identificar conhecimentos e habilidades necessrias
PP - SP 2.5 Plan for Needed Knowledge MAN.3.BP6: Define needs for experience, knowledge and
and Skills skills. Identify the experience, knowledge and skill
PP - SP 2.6 Plan Stakeholder Involvement requirements of the project and apply them to the selection
PP - SP 2.7 Establish the Project Plan of individuals and teams.
Cp11. Identificar riscos inerentes ao projeto
RD - SP 3.4 Analyze Requirements to ENG.2.BP4: Evaluate and update system requirements.
Achieve Balance Evaluate the impact of proposed changes and new
PP - SP 2.2 Identify Project Risks requirements for cost, schedule, risk and technical impact,
PP - SP 2.7 Establish the Project Plan approve or reject changes and new requirements, and
MA - SP 2.1 Collect Measurement Data update the system requirements baseline.
MA - SP 2.2 Analyze Measurement Data ENG.4.BP5: Evaluate and update software requirements.
MA - SP 2.3 Store Data and Results Evaluate the requirements with the customer, evaluate the
impact of proposed changes for cost, schedule and
technical impact, approve or reject changes, and update
the software requirements specification.
the data.
products.
Cp12. Acompanhar o andamento do projeto
PMC - SP 1.1 Monitor Project Planning MAN.3.BP12: Monitor project attributes. Monitor project
Parameters scope, budget, cost, resources and other necessary
PMC - SP 1.2 Monitor Commitments attributes and document significant deviations of them
PMC - SP 1.3 Monitor Project Risks against the project baseline.
Cp13. Controlar custos despendidos na fase de concepo
attributes and document significant deviations of them
against the project baseline.

Cp14. Conduzir reviso do milestone: Estudo de Viabilidade do Projeto
PMC - SP 1.7 Conduct Milestone Reviews SUP.1.BP2: Define quality records. Quality records are
PP - SP 3.1 Review Plans That Affect the defined that demonstrate conformance of process and
Project work products to their quality requirements.
PPQA - SP 1.1 Objectively Evaluate SUP.1.BP3: Assure the quality of project process activities
Processes and project work products. Carry out a series of activities
PPQA - SP 1.2 Objectively Evaluate Work to provide assurance, with the required level of confidence,
Products and Services that the project processes have followed specified
PPQA - SP 2.1 Communicate and Ensure standards and that the work products meet the quality
Resolution of Noncompliance Issues requirements.
PPQA - SP 2.2 Establish Records SUP.1.BP4: Identify and record problems and non-
MA - SP 2.1 Collect Measurement Data conformances. Problems and nonconformances are
MA - SP 2.2 Analyze Measurement Data identified and recorded and then reported to appropriate
MA - SP 2.3 Store Data and Results stakeholders for information and action.
MA - SP 2.4 Communicate Results SUP.1.BP5: Act on non-conformances. Deviations or non-
conformance with agreed requirements or organizational
quality goals are analyzed and resolved.
the data.
products.
MAN.6.BP8: Communicate measurement results.
Disseminate measurement information products to all
parties who will be using them and collect feedback to
evaluate the appropriateness for intended use.
MAN.6.BP9: Evaluate and communicate information
products and measurement activities to process owners.
Evaluate information products and measurement activities
against the identified information needs and measurement
strategy, identify potential improvements in measurements,
and communicate any identified potential improvement to
the process owners.
QUADRO A5.4 M APEAMENTO DAS ATIVIDADES DA FASE DE NEGOCIAO

N01. Elaborar proposta
PP - SP 3.2 Reconcile Work and ENG.4.BP5: Evaluate and update software requirements.
Resource Levels Evaluate the requirements with the customer, evaluate the
impact of proposed changes for cost, schedule and
technical impact, approve or reject changes, and update
the software requirements specification.
MAN.3.BP3 Evaluate feasibility of the project. Evaluate the
feasibility of achieving the goals of the project with
available resources and constraints.
N02. Analisar proposta
- -
N03. Elaborar contrato
- -
QUADRO A5.4 M APEAMENTO DAS ATIVIDADES DA FASE DE NEGOCIAO (CONT.)

N04. Analisar contrato
- -
N05. Definir time do projeto
PP - SP 2.5 Plan for Needed Knowledge MAN.3.BP7: Define project schedule. Allocate resources to
and Skills activities and determine the sequence and schedule of
PP - SP 2.1 Establish the Budget and performance of activities within the project.
Schedule MAN.3.BP6: Define needs for experience, knowledge and
skills. Identify the experience, knowledge and skill
requirements of the project and apply them to the selection
of individuals and teams.
N06. Formalizar incio do projeto
PP - SP 3.3 Obtain Plan Commitment MAN.3.BP8: Identify and monitor project interfaces.
Identify and agree interfaces of the project with other
projects, organizational units and other affected parties
and monitor agreed commitments.
MAN.3.BP9: Allocate responsibilities. Identify the specific
individuals and groups contributing to, and impacted by,
the project, allocate them their specific responsibilities, and
ensure that the commitments are understood and
accepted, funded and achievable.
N07. Acompanhar o andamento do projeto
N08. Controlar custos despendidos na fase de negociao
attributes and document significant deviations of them
against the project baseline.
QUADRO A5.4 M APEAMENTO DAS ATIVIDADES DA FASE DE NEGOCIAO (CONT.)

N09. Conduzir reviso do milestone: Contrato
the data.
products.
the process owners.
QUADRO A5.5 M APEAMENTO DAS ATIVIDADES DA FASE DE ELABORAO

E01. Detalhar requisitos
RD - SP 2.1 Establish Product and ENG.4.BP1: Specify software requirements. Define and
Product Component Requirements prioritize functional and nonfunctional requirements of the
RD - SP 3.1 Establish Operational software elements of the system and their interfaces and
Concepts and Scenarios document them in a software requirements specification.
RD - SP 3.2 Establish a Definition of Analyze the software requirements for correctness,
Required Functionality completeness, consistency, feasibility and testability.
REQM - SP 1.4 Maintain Bidirectional Identify any derived requirements.
Traceability of Requirements
E02. Verificar e Validar os requisitos
RD - SP 3.3 Analyze Requirements ENG.1.BP2: Understand customer expectations. Ensure
RD - SP 3.5 Validate Requirements that both supplier and customer understand each
VER - SP 2.1 Prepare for Peer Reviews requirement in the same way. Review with customers their
VER - SP 2.2 Conduct Peer Reviews requirements and requests to better understand their
VER - SP 2.3 Analyze Peer Review Data needs and expectations and to check the feasibility and
VER - SP 3.1 Perform Verification appropriateness of their requirements.
VER - SP 3.2 Analyze Verification Results ENG.1.BP3: Agree on requirements. Obtain agreement
VAL - SP 2.1 Perform Validation across teams on the customer requirements, obtaining the
VAL - SP 2.2 Analyze Validation Results appropriate sign-offs by representatives of all teams and
other parties contractually bound to work to these
requirements.
ENG.2.BP3: Analyze system requirements. Prioritize
requirements and analyze the prioritized requirements for
correctness, completeness, consistency, feasibility and
testability, identifying the necessary elements of the
system. Identify changes to the operating environment.
SUP.2.BP4: Determine actions for verification results.
Defects detected by the verification should be identified,
recorded and entered into the Problem resolution process
(SUP.9).
(SUP.9).
QUADRO A5.5 M APEAMENTO DAS ATIVIDADES DA FASE DE ELABORAO (CONT.)

E03. Definir soluo de projeto
RD - SP 2.2 Allocate Product Component ENG.3.BP2: Allocate requirements. Allocate all system
Requirements requirements to the elements of the top-level system
RD - SP 2.3 Identify Interface architecture.
Requirements ENG.3.BP3: Define interfaces. Develop and document the
REQM - SP 1.4 Maintain Bidirectional internal and external interfaces of each system element.
Traceability of Requirements ENG.3.BP1: Describe system architecture. Establish the
TS - SP 2.1 Design the Product or top-level system architecture that identifies elements of
Product Component hardware, software and manual-operations.
TS - SP 2.2 Establish a Technical Data ENG.5.BP1: Describe software architecture. Transform the
Package software requirements into a software architecture design
TS - SP 2.3 Design Interfaces Using that describes the top-level structure and identifies its
Criteria major software elements.
ENG.4.BP2: Determine operating environment impact.
Determine the interfaces between the software
requirements and other elements of the operating
environment, and the impact that the requirements will
have.
ENG.5.BP2: Define interfaces. Specify and document the
external and internal interfaces between the software
elements.
ENG.5.BP3: Develop detailed design. Decompose the
software architectural design into a detailed design for
each software element describing all software units to be
produced and tested. Document software units and
interfaces in a software design document.
E04. Detalhar o cronograma
PP - SP 2.1 Establish the Budget and MAN.3.BP5: Define project activities and tasks. Identify
Schedule project activities and tasks according to defined project
lifecycle, and define dependencies between them.
MAN.3.BP7: Define project schedule. Allocate resources to
activities and determine the sequence and schedule of
performance of activities within the project.

E05. Definir tcnicas e critrios para V&V
PP - SP 2.7 Establish the Project Plan MAN.3.BP10: Establish project plan. Define and maintain
PI - SP 1.1 Determine Integration project master plan and other relevant plans to cover the
Sequence project scope and goals, resources, infrastructure,
PI - SP 1.2 Establish the Product interfaces and communication mechanisms.
Integration Environment ENG.4.BP3: Develop criteria for software testing. Use the
PI - SP 1.3 Establish Product Integration software requirements to define acceptance criteria for the
Procedures and Criteria software product tests. Software product tests should
VER - SP 1.1 Select Work Products for demonstrate compliance with the software requirements.
Verification ENG.6.BP1: Develop unit verification procedures. Develop
VER - SP 1.2 Establish the Verification and document procedures and criteria for verifying that
Environment each software unit satisfies its design requirements. The
VER - SP 1.3 Establish Verification verification procedure includes unit test cases, unit test
Procedures and Criteria data and code review.
VAL - SP 1.1 Select Products for ENG.7.BP1: Develop software integration strategy.
Validation Develop the strategy for integrating software units
VAL - SP 1.2 Establish the Validation considering the software requirements. Identify software
Environment items based on the software architecture and define a
VAL - SP 1.3 Establish Validation sequence or order for integrating and testing them.
Procedures and Criteria ENG.7.BP2: Develop tests for integrated software items.
Describe the tests to be run against each integrated
software item, including the verification of the interfaces,
indicating software requirements being checked, input data
and verification criteria.
ENG.7.BP6: Regression test integrated software items.

Develop a software regression test strategy for re-testing
the integrated software items. If changes are made to
software units, designs or requirements, carry out
regression testing according to this strategy.
ENG.8.BP1: Develop tests for integrated software product.
Describe the tests to be run against the integrated software
product, indicating software requirements being checked,
input data, and verification criteria. The set of tests should
demonstrate compliance with the software
requirements.
ENG.8.BP3: Regression test integrated software. Develop
a software regression test strategy for re-testing the
integrated software product. If changes are made to
software items, carry out regression testing according to
the strategy.
ENG.9.BP2: Develop tests for system elements. Describe
the tests to run against each system element, indicating
requirements being checked, input data, system elements
needed to perform the test, and verification criteria.
ENG.10.BP1: Develop tests for system. Describe the tests
to be run against the complete system, indicating system
requirements being checked, input data, and validation
criteria.
SUP.2.BP1: Develop verification strategy. Develop and
implement a verification strategy, including verification
activities with associated methods, techniques, and tool.
SUP.2.BP2: Develop criteria for verification. Develop the
criteria for verification of all required work products.
SUP.3.BP2: Develop validation criteria. Develop the
criteria for validation of all required work products.

E06. Monitorar e controlar o projeto
PMC - SP 1.4 Monitor Data Management MAN.3.BP13: Review progress of the project. Regularly
PMC - SP 1.5 Monitor Stakeholder report and review the status of the project performance
Involvement against the project plan.
PMC - SP 1.6 Conduct Progress Reviews MAN.3.BP14: Act to correct deviations. Take action when
PMC - SP 2.1 Analyze Issues project goals are not achieved, to correct deviations from
PMC - SP 2.2 Take Corrective Action the plan and to prevent recurrence of problems identified in
PMC - SP 2.3 Manage Corrective Action the project. Update project plans accordingly.
E07. Monitorar e Controlar questes financeiras
E08. Conduzir reviso do milestone: Arquitetura do Software
the data.
products.
the process owners.
QUADRO A5.6 M APEAMENTO DAS ATIVIDADES DA FASE DE CONSTRUO

Ct01. Codificar componentes
TS - SP 3.1 Implement the Design ENG.6.BP2: Develop software units. Develop and
document the executable representations of each software
unit. Update test requirements and user documentation.
Ct02. Realizar teste de unidade
VER - SP 3.1 Perform Verification ENG.6.BP4: Verify software units. Verify that each
MA - SP 2.1 Collect Measurement Data software unit satisfies its design requirements by executing
MA - SP 2.3 Store Data and Results the specified unit verification procedures and document the
results.
ENG.7.BP4: Test integrated software items. Test each
integrated software item on an operational platform or
suitable equivalent platform, against the verification
criteria, and record the results. Update user documentation
as necessary.
ENG.8.BP2: Test integrated software product. Test the
integrated software product against the verification criteria,
and record the results. Update user documentation as
necessary.
the strategy.
ENG.9.BP4: Test system elements. Test each system
element and ensure that it satisfies its requirements, and
document the results.
ENG.9.BP5: Regression test system elements. If changes
are made to system elements, carry out regression testing
as defined in the regression test strategy.
the data.
Ct03. Analisar os resultados de teste
VER - SP 3.2 Analyze Verification Results SUP.2.BP4: Determine actions for verification results.
MA - SP 2.2 Analyze Measurement Data Defects detected by the verification should be identified,
recorded and entered into the Problem resolution process.
products.
QUADRO A5.6 M APEAMENTO DAS ATIVIDADES DA FASE DE CONSTRUO (CONT.)

Ct04. Integrar e testar integrao entre componentes
PI - SP 1.1 Determine Integration ENG.6.BP4: Verify software units. Verify that each
Sequence software unit satisfies its design requirements by executing
PI - SP 2.1 Review Interface Descriptions the specified unit verification procedures and document the
for Completeness results.
PI - SP 2.2 Manage Interfaces ENG.7.BP1: Develop software integration strategy.
PI - SP 3.1 Confirm Readiness of Product Develop the strategy for integrating software units
Components for Integration considering the software requirements. Identify software
PI - SP 3.2 Assemble Product items based on the software architecture and define a
Components sequence or order for integrating and testing them.
PI - SP 3.3 Evaluate Assembled Product ENG.7.BP3: Integrate software item. Integrate the software
Components units according to the integration strategy to form a
VER - SP 3.1 Perform Verification software item.
MA - SP 2.1 Collect Measurement Data ENG.7.BP4: Test integrated software items. Test each
MA - SP 2.3 Store Data and Results integrated software item on na operational platform or
suitable equivalent platform, against the verification
criteria, and record the results. Update user documentation
as necessary.
ENG.8.BP2: Test integrated software product. Test the
integrated software product against the verification criteria,
and record the results. Update user documentation as
necessary.
the strategy.
ENG.9.BP3: Integrate system elements. Integrate system
elements according to the system integration strategy.
ENG.9.BP4: Test system elements. Test each system
element and ensure that it satisfies its requirements, and
document the results.
ENG.9.BP5: Regression test system elements. If changes
are made to system elements, carry out regression testing
as defined in the regression test strategy.
ENG.9.BP7: Build complete system of system elements.
Identify and integrate system elements to produce a
complete system ready for system testing according to the
system integration strategy.
ENG.10.BP2: Test integrated system. Test the integrated
system and ensure that it satisfies the system
requirements, and record the results.
ENG.10.BP3: Regression test integrated system. Develop
a system regression test strategy for re-testing the system.
If changes are made to system elements, carry out
regression testing as defined in the system regression test
strategy.
the data.
QUADRO A5.6 M APEAMENTO DAS ATIVIDADES DA FASE DE CONSTRUO (CONT.)

Ct05. Monitorar e controlar o projeto
Ct06. Monitorar e Controlar questes financeiras
Ct07. Conduzir reviso do milestone: Capacidade Operacional
the data.
products.
the process owners.
QUADRO A5.7 M APEAMENTO DAS ATIVIDADES DA FASE DE TRANSIO

T01. Validar a verso do produto
VAL - SP 2.1 Perform Validation ENG.8.BP2: Test integrated software product. Test the
MA - SP 2.1 Collect Measurement Data integrated software product against the verification criteria,
MA - SP 2.3 Store Data and Results and record the results. Update user documentation as
necessary
ENG.10.BP2: Test integrated system. Test the integrated
system and ensure that it satisfies the system
requirements, and record the results.
The results of validation activities are recorded.
the data.
T02. Analisar e Ajustar a verso do produto
VAL - SP 2.2 Analyze Validation Results ENG.11.BP3: Specify the requirements for adaptation.
MA - SP 2.2 Analyze Measurement Data Specify the requirements for adaptation of the system for
TS - SP 3.1 Implement the Design its intended environment.
products.
ENG.11.BP4: Adapt the system. Adapt the system to meet
the requirements for operation.
(SUP.9).
T03. Realizar testes de regresso
VER - SP 3.1 Perform Verification SUP.2.BP3: Conduct verification. Verify identified work
VAL - SP 2.1 Perform Validation products according to specified strategy.
MA - SP 2.1 Collect Measurement Data SUP.3.BP3: Perform validation activities. Conduct
MA - SP 2.3 Store Data and Results validation activities using identified techniques, processes,
The results of validation activities are recorded.
ENG.10.BP3: Regression test integrated system. Develop
a system regression test strategy for re-testing the system.
If changes are made to system elements, carry out
regression testing as defined in the system regression test
strategy.
the data.
QUADRO A5.7 M APEAMENTO DAS ATIVIDADES DA F ASE DE TRANSIO (CONT.)

T04. Entregar/Instalar a verso do produto
TS - SP 3.2 Develop Product Support SUP.7.BP5: Develop documents. Develop documents at
Documentation required process points according to established standards
PI - SP 3.4 Package and Deliver the and policy.
Product or Product Component ENG.11.BP5: Install software product. Install the software
product according to the software installation strategy.
Document the events and results.
ENG.11.BP6: Confirm product readiness. Assure that the
software product is ready for use in its intended
environment.
NOTE 2: Software installation process is linked to Product
acceptance support process (SPL.3).
ENG.11.BP1: Develop installation strategy. Develop a
software installation strategy to install the software product
in the target environment in agreement with the customer
and the operating organization.
NOTE 1: An important part of developing an installation
strategy is to develop a strategy to return to the last
working system version. In order to be able to re-install the
last working version, a complete backup of the system
should be made before starting the installation.
ENG.11.BP2: Establish installation criteria. Based on the
installation requirements, develop criteria for the
environment where the software will be installed.
T05. Monitorar e controlar o projeto
T06. Monitorar e Controlar questes financeiras
QUADRO A5.7 M APEAMENTO DAS ATIVIDADES DA F ASE DE TRANSIO (CONT.)

T07. Conduzir reviso do milestone: Entrega do Produto
the data.
products.
the process owners.
Apndice 6 Aplicao do ProcSoftVD Melhoria P g i n a | 312
Apndice 6 Aplicao do ProcSoftVD Melhoria

Ramo de atividade da empresa: Desenvolvimento de Sistemas de Informtica
Nicho: Comrcio Varejista, oficinas mecnicas.
Quadro de funcionrios: 3
Fase 1. Diagnstico do Processo de Software Atual e Definio do Perfil-Alvo
1.1 Descrio do Processo Atual

- efetuada uma anlise inicial, com uma entrevista e anotaes (em papel) do que o
sistema far.
- Durante uma semana (mais ou menos) feita uma anlise de todo o sistema, quais
ferramentas sero usadas, e fornecido ao cliente um prazo.
- Durante o processo de desenvolvimento, so efetuadas anotaes em papis e
planilhas eletrnicas.
- visto o que mais prioritrio e este incremento desenvolvido e entregue. O prprio
programador efetua os testes, tambm. Esses testes so relacionados
compartilhamento de recursos, carga de dados, impresses, e em relao ao software
sem utilizar critrios de teste (erros de codificao).
- efetuado um instalador para a verso, marcado em uma planilha o nmero da
verso e o que foi instalado ou no.
- Depois, realiza-se o prximo incremento e se refaz o processo novamente
- Nesse nterim, existem modificaes de outros sistemas.
- Um dos funcionrios responsvel pelo relacionamento com o cliente, verificando qual

ser a mudana e se est sendo atendida.
- O outro programador auxilia em testes e alteraes.
Quanto ao controle de pagamentos, existe uma planilha para controlar quem pagou o
qu em cada ms, pois o produto executvel disponibilizado para o cliente por
intermdio de mensalidades.
1.2 Objetivos Estratgicos do Negcio da Empresa
Objetivos Estratgicos:
Hoje os clientes da empresa so pequenas empresas e um dos objetivos
estratgicos buscar e atender clientes de porte mdio e grande, por meio do
desenvolvimento de um sistema ERP
Ter clientes de outras regies
Metas de melhoria:
Formalizar e padronizar o processo para desenvolvimento do software (necessria e
importante)
Melhorar a implantao no cliente, deixar explcito para o patrocinador, todas as
modificaes relevantes
Desenvolver uma ferramenta de BI (business intelligence) que seja integrada ao
sistema ERP para dar melhores resultados financeiros.
Ter meios de suporte on-line para o cliente
1.3 Definio dos Perfis-Alvo do Processo

Comercializao
Sintomas da no execuo do processo:
O cliente faz solicitaes de mudanas do sistema e pode cancelar a utilizao.
O cliente pode solicitar mais alteraes, alm do combinado verbalmente,
extrapolando prazos, etc
Benefcios:
O contrato pode estipular multas em casos de solicitaes de mudanas e
desistncia da utilizao do sistema, por ex, e isso traz segurana para a empresa
desenvolvedora.
Ter controle das modificaes solicitadas pelo cliente dentro um prazo estabelecido.
Modelagem de Negcio
Cada vez que tiver um novo funcionrio dentro da softwarehouse, algum ter que
ser interrompido para explicar o modelo de negcio.
Benefcios:
Auxiliar na viso geral dos stakeholders do que se trata o negcio do cliente.
Produo de Requisitos
Entendimento nico dos processos do sistema (fica na cabea de um participante
do projeto)
A no definio dos requisitos propicia at a inviabilidade do projeto, pois no
avaliado a sua dimenso.
Benefcios:
Melhor entendimento das lgicas dos processos
Viso macro de todo o sistema
A definio dos requisitos ajuda na melhora tambm do sistema no futuro, pois tem
se um alicerce de como realmente o sistema funciona
Projeto, Codificao & Integrao de Produto

A falta de parmetros de definio de codificao e integrao do produto propicia
uma instabilidade no projeto como um todo
Benefcios
A definio em design, do software, podem levar a uma melhor verificao se o
projeto como um todo est funcional ou no.
V&V
Podem surgir diversos erros, ainda mais, no cliente, proporcionando uma corrida pra
atender e resolver os erros do cliente
Benefcios
Maior credibilidade na verso que est no cliente
A falta de avaliao do processo (de forma imparcial) pode proporcionar comodismo
no projeto como um todo ou em partes
Benefcios
Apurao dos resultados, e possvel verificar se est adiantando mesmo fazer
todos os processos
Implantao
Dvidas e falta de credibilidade no ambiente do cliente
Benefcios
Um controle da implantao propicia maior facilidade da instalao com o cliente
Aquisio
Com as mudanas no software do cliente, uma falta de controle de aquisio, pode
gerar erros na instalao de uma verso. (terceirizao de parte do software)
Benefcios
Controlando a aquisio de verses, a softwarehouse tem a noo do que est
rodando, em termos de sistema no cliente.
Medio
A falta de medio pode levar a uma insatisfao do cliente, at porque no
avaliado como o cliente est se adaptando ao sistema
Benefcios
Consegue-se medir um retorno do prprio produto de como ele est, e h vrias
formas de se medir ele. Ex: em categorias, por ndice, etc
Gesto de Requisitos
pode-se gerar uma falta de atualizao entre requisitos e o software
Benefcios
identificando as inconsistncias pode evitar-se um desentendimento entre
documentao do que realmente o sistema (em relao a outras pessoas)
Gesto de Projetos
a falta de definio de um plano no projeto como um todo, pode propiciar a que o
projeto no chegue a lugar nenhum
Benefcios
a definio do projeto como um todo, gera a idia de comeo, meio e fim do todo

falta de parametrizao no sistema dos produtos usados,como um todo, em relao
a equipe de desenvolvimento
Benefcios
controle mais apurado de como desenvolver e uso do produto
cada um do desenvolvimento (programadores, analistas) faz e refazem funes,
procedimentos, etc, e se perde tempo no desenvolvimento e no projeto
Benefcios
acho que uma equipe em constante conversao, evita-se e tem-se idias de
inovaes no produto e resoluo de problemas nos clientes
Fase 2. Anlise Estratgica e Planejamento da Mudana
2.1 Priorizao das reas de Conhecimento
V&V
Medio
Gesto de Projetos Aquisio Modelagem de
alta Gesto de Requisitos Gesto de Mudanas e Negcio
Configurao Produo de
Requisitos
Importncia
Garantia da Qualidade Comercializao
mdia Implantao
Projeto, Codificao &

baixa Integrao
baixo mdio alto
Risco
Ciclos de Melhoria
Ciclo de Melhoria 1: Modelagem de Negcios; Produo de Requisitos

Ciclo de Melhoria 2: V&V
Ciclo de Melhoria 3: Aquisio; Gesto de Mudanas e Configurao
Ciclo de Melhoria 4: Medio
Ciclo de Melhoria 5: Gesto de Requisitos; Gesto de Projetos
Ciclo de Melhoria 6: Garantia da Qualidade; Implantao
Ciclo de Melhoria 7: Comercializao
Ciclo de Melhoria 8: Projeto, Codificao & Integrao; Gesto de Conhecimento
2.2 Plano de Ao
Foi definido um patrocinador na empresa, o escopo do projeto de mudana, a WBS,
cronograma e avaliados os riscos do projeto de mudana.
Fase 3. Definio das atividades da(s) rea(s) de conhecimento

Nessa fase foi realizada a definio das atividades das reas de conhecimento
Modelagem de Negcios e Produo de Requisitos, tendo como subsdio o Modelo
ProcSoftVD.
Fase 4. Implantao da(s) rea(s) de conhecimento

Nessa fase as reas de conhecimento Modelagem de Negcios e Produo de
Requisitos foram institucionalizadas e avaliadas.
Apndice 7 Questionrio de Avaliao P g i n a | 317
Apndice 7 Questionrio de Avaliao do ProcSoftVD
QUESTIONRIO
1. Identificao
1.2 Seu nome (opcional): .........................................................................................................................
1.2 E-mail pessoal para contato: ..............................................................................................................
1.3 Qual a sua formao acadmica?

R. ..............................................................................................................................................................
1.4 Funo que voc exerce na empresa onde trabalha:

a. ( ) Gerente/Supervisor
b. ( ) Gerente de Projetos
c. ( ) Analista de Sistemas
d. ( ) Programador
e. ( ) Outra. Qual ? ................................................................. Nesse caso, algum dia j exerceu a
funo de analista de sistema e/ou programador em alguma empresa? R: ............................................
2. Validao do Modelo ProcSoftVD
2.1 Apresentao do Modelo

Acesse o site http://www.numa.org.br/GProcSoftVD.
2.2 Validao das reas de Conhecimento

Para cada rea de conhecimento ser apresentada, a seguir, uma tabela com a sua
descrio e espera-se que voc defina os pontos fortes e fracos do modelo relacionado a essa rea
de conhecimento, aps sua validao.
DESCRIO DA REA DE CONHECIMENTO PONTOS PONTOS

FORTES FRACOS
Comercializao: essa rea de conhecimento foi criada
para abordar (1) atividades relacionadas prospeco de
potenciais clientes para a empresa (o que no coberto
pelo CMMI, nem pela ISO/IEC 15504-5); (2) atividades
relacionadas elaborao/submisso de propostas ao
cliente e negociao e aprovao de contrato sem
ambigidades que especifique as expectativas,
responsabilidades, entregas e compromissos de ambas as
partes cliente e fornecedor; (3) atividades relacionadas
viabilidade financeira do projeto e relacionadas ao
pagamento dos produtos/servios vendidos pela empresa.
As atividades do item (2) foram definidas com subsdio dos
processos Prospeco do Fornecedor e Acordado
Contratual da ISO/IEC 15504-5.
Modelagem de Negcio: o objetivo dessa rea de
conhecimento documentar os processos de negcio
usando casos de uso de negcio, a fim de assegurar um
entendimento comum entre todos os stakeholders
(envolvidos) sobre as necessidades existentes no processo
de negcio da organizao cliente. Essa rea de
conhecimento teve sua origem no Unified Process.
Produo de Requisitos: tem o objetivo de produzir e
analisar os requisitos do cliente, do produto e dos
componentes de produto. Essa rea de conhecimento teve
sua origem relacionada rea de processo
Desenvolvimento de Requisitos do CMMI-DEV e aos
processos Elicitao de Requisitos, Anlise de Requisitos
do Sistema e Anlise de Requisitos do Software da
ISO/IEC 15504-5.
Projeto, Codificao & Integrao de Produto: Engloba os
processos Projeto do Software, Integrao do Software e
Integrao do Sistema da 15504-5, o workflow
Implementao do UP e as reas de processo Soluo
Tcnica e Integrao de Produto do CMMI-DEV. Segundo
a 15504-5, o processo Projeto de Software tem o objetivo
de fornecer um design para o software que implementado
e pode ser verificado em confronto aos requisitos; o
processo Integrao de Software tem o objetivo de
combinar as unidades de software, produzindo itens de
software integrados, consistentes com o projeto de software,
os quais demonstram que os requisitos funcionais e no-
funcionais foram satisfeitos; e o processo Integrao do
Sistema tem como objetivo integrar os elementos do
sistema (incluindo os itens de software, itens de hardware,
operaes manuais e outros sistemas, se necessrio) para
produzir um sistema completo que satisfaa ao projeto do
sistema e s expectativas do cliente, expressadas em
requisitos do sistema. Segundo o modelo CMMI-DEV, a rea
de processo Soluo Tcnica tem como objetivo projetar,
desenvolver e implementar solues para os requisitos,
solues essas que envolvem produtos, componentes de
produtos e processos de ciclo de vida relacionados ao
produto; e a rea de processo Integrao do Produto tem o
objetivo de montar o produto, a partir dos componentes de
produto, assegurar que o produto ao ser integrado funcione
adequadamente, e entregar o produto.
V&V: Engloba as reas de processo (CMMI) e processos
(15504-5) Validao e Verificao e os processos Teste

de Software e Teste de Sistema da 15504-5. O objetivo da
rea de processo/processo Validao demonstrar que o
produto ou componente do produto atenda ao uso
pretendido quando colocado no ambiente destinado. J o
objetivo da rea de processo/processo Verificao
assegurar que produtos de trabalho (e servios, no caso do
CMMI) selecionados alcancem seus requisitos
especificados. Testes desempenham um papel
extremamente importante em V&V (Verificao e Validao).
Segundo o modelo 15504-5, o processo Teste pode ser
realizado tanto no software quanto no sistema. O processo
Teste de Software tem como objetivo confirmar que o
produto de software integrado atende aos requisitos
definidos. E, o processo Teste de Sistema tem o objetivo
de assegurar que a implementao de cada requisito de
sistema seja testada quanto sua conformidade e que o
sistema esteja pronto para entrega.
Implantao: o objetivo entregar o produto produzido para
os usurios finais, por meio das atividades de codificao,
teste, empacotamento e instalao do software. Essa rea
de conhecimento teve sua origem no UP e tambm est
Aquisio: essa rea de conhecimento tem o objetivo de
gerenciar a aquisio de produtos de fornecedores, sejam
equipamentos ou at mesmo componentes de software do
produto (no caso de terceirizao do servio). Exemplos de
produtos e componentes de produtos que podem ser
adquiridos pelo projeto: subsistemas (por exemplo, um
sistema navegacional de uma aeronave), software,
hardware, documentao (como manuais de instalao, de
operao e do usurio). A origem dessa rea de
conhecimento est relacionada ao grupo de processo
Aquisio da 15504-5 rea de processo denominada
Gesto de Acordo com Fornecedor do CMMI-DEV.
Medio: essa rea de conhecimento tem o objetivo de
coletar e analisar dados relacionados aos produtos
desenvolvidos e aos processos implementados dentro da
organizao por meio de projetos, a fim de dar um suporte
efetivo gesto dos processos e demonstrar objetivamente
a qualidade dos produtos. Sua origem est relacionada
rea de processo Anlise e Medio do CMMI-DEV e do
processo Medio da 15504-5.
Garantia da Qualidade de Produto e Processo: o objetivo
dessa rea de conhecimento fornecer a garantia de que
processos e produtos de trabalho estejam em conformidade
com planos e provises pr-definidos. Sua origem est
relacionada tanto ao CMMI quanto ISO/IEC 15504.
Gesto de Requisitos: o objetivo dessa rea de
conhecimento, que teve sua origem no CMMI-DEV,
gerenciar os requisitos dos produtos e componentes de
produtos dos projetos e identificar inconsistncias entre
esses requisitos e os planos e produtos de trabalho dos
projetos. Para isso, essa rea trata do rastreamento dos
requisitos em meio ao projeto e das mudanas desses
requisitos. As mudanas relacionadas aos requisitos utilizam
algumas das atividades definidas pela rea de conhecimento
Gesto de Mudanas e Configurao.
Gesto de Mudanas e Configurao: essa rea de
conhecimento engloba a rea de processo Gesto de
Configurao do CMMI-DEV e os processos Gesto de

Configurao e Gesto de Solicitao de Mudanas da
15504-5. O objetivo dessa rea de conhecimento
estabelecer e manter a integridade de produtos de trabalho
usando a identificao de configurao, controle de
configurao, prestao de contas (explicao) do status da
configurao e auditoria da configurao, alm de assegurar
que solicitaes de mudanas no projeto sejam gerenciadas,
rastreadas e controladas.
Gesto de Projetos: o objetivo dessa rea de processo
identificar, estabelecer, coordenar e monitorar as atividades,
tarefas e recursos necessrios para um projeto produzir um
produto e/ou servio, no contexto dos requisitos e restries
de projetos. Engloba tanto o processo Gesto de Projetos
da 15504-5 quanto s reas de processo Planejamento de
Projeto e Monitoramento e Controle de Projeto do CMMI.
Gesto de Conhecimento: tem como objetivo assegurar
que o conhecimento, informao e habilidades individuais
sejam coletadas, compartilhadas, reusadas e melhoradas
por toda a organizao. Sua origem est relacionada ao
processo Gesto de Conhecimento da ISO/IEC 15504.
2.3 Validao do Modelo como um todo

2.3.1 Por gentileza, abra o arquivo CMMI-v1-2.pdf. Aperte SHIFT+CTRL+N e digite 339. Voc foi
redirecionado para a rea de processo do CMMI Planejamento de Projeto. Nela voc encontra o
objetivo dessa rea, os objetivos especficos e para cada um deles as sub-prticas e produtos de
trabalho tpicos. Todas as outras reas de processo tm a mesma estrutura.
Para uma MPE, o que mais fcil: utilizar como modelo de referncia para criar o seu processo
padro o CMMI ou um outro modelo com mais detalhes de como podem ser realizadas as
atividades do processo, como o proposto nesse trabalho de pesquisa?
R: _______________________________________________________________________________
2.3.2 Por gentileza, abra o arquivo ISO-IEC_FDIS_15504-5.pdf. Aperte SHIFT+CTRL+N e digite 69.
Voc foi redirecionado para o processo Gesto de Projeto. Nele voc encontra o objetivo desse
processo, os resultados, as prticas-base e os produtos de trabalho tpicos. Todos os outros
processos tm a mesma estrutura.
Para uma MPE, o que mais fcil: utilizar como modelo de referncia para criar o seu processo
padro a norma ISO/IEC 15504-5 ou um outro modelo com mais detalhes de como podem ser
realizadas as atividades do processo, como o proposto nesse trabalho de pesquisa?
R: ______________________________________________________________________________
2.3.3 Voc enxerga o modelo proposto nesse trabalho de pesquisa como uma referncia, um guia
que poderia ser utilizado por uma MPE para, a partir dele, definir o seu processo padro (mesmo que
seja necessrio fazer alguns ajustes para adequar realidade da empresa)?
R: _______________________________________________________________________________
2.3.4 De forma geral, quais os comentrios voc faria a respeito do modelo proposto?
R: _______________________________________________________________________________
2.3.5 Acesse a planilha AvaliacaoQualidade.xls e preencha a coluna Qual nvel de atendimento de

cada sub-caracterstica? com as alternativas do combo-box (Alto, Mdio, Baixo e NA (no se
aplica). Por favor, envie a planilha preenchida junto a esse questionrio.
Apndice 8 Pontos Fortes e Fracos do ProcSoftVD P g i n a | 321
Apndice 8 Pontos Fortes e Fracos Transcritos das

Respostas do Questionrio entregue aos Profissionais
As respostas dos 6 (seis) profissionais que avaliaram o modelo quanto aos seus
pontos fortes e fracos esto transcritas, por rea de conhecimento, nos Quadros A8.1 a
A8.13.
QUADRO A8.1 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO PRODUO DE REQUISITOS

Quanto Pontos P1: O template documento de requisitos simplificado e fcil de ser colocado em
Produo de Fortes prtica; muito bom.
Requisitos P2: a) Documentao muito bem definida; b) Contempla Exemplos/Sugestes; c)
Completo.
P3: no comentou
P4: no comentou
P5: Tempo despendido em modelagem, anlise e produo de requisitos um
excelente investimento, e no um gasto.
P6: a) Vasto material de apoio para a elicitao dos requisitos para o software; b)
Bem detalhado.
Pontos P1: no comentou
Fracos P2: no comentou
P3: no comentou
P4: no comentou
P5: Muito material para ser lido, analisado, documentado e empreendido, para
autnomos e equipes pequenas.
P6: no comentou
QUADRO A8.2 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO MODELAGEM DE NEGCIOS

Quanto Pontos P1: As tarefas que incluem a modelagem de negcio esto claramente definidas.
Modelagem de Fortes P2: a) Completo e eficiente; b) Foco e preocupao com aspectos fundamentais
Negcios dessa rea de conhecimento; c) Clareza nas explicaes; d) Contempla
Exemplos/Sugestes.
P3: no comentou
P4: no comentou
P5: no comentou
P6: Roteiro bem definido, enfatizando a importncia da interao entre cliente e
desenvolvedor.
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.3 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO COMERCIALIZAO

Quanto Pontos P1: As atividades prospectar clientes, visitar clientes e criar infra-estrutura do projeto
Comercializao Fortes so pontos fortes do modelo.
P2: a) Fornece plenas condies para o gerenciamento do contato inicial com o
cliente, transmitindo eficincia e credibilidade perante o cliente; b) Aspecto formal
abrangido sem exageros; ideal!; c) Contempla Exemplos/Sugestes.
P3: no comentou
P4: Cobertura de uma atividade cuja organizao desenvolvedora deve se
preocupar.
P5: a) O modelo contempla a viabilidade do projeto para a empresa; b) Com o
auxlio do Marketing pode-se aumentar o desenvolvimento de produtos, aumentando-
se os lucros.
P6: a) Linguagem de fcil entendimento por parte da empresa envolvida; b) Roteiro
bem simplificado, a rea de conhecimento bem explicada e fcil de se seguir; c)
Elaborao do contrato de prestao de servio junto ao cliente ou de venda do
software bem explicado e de acordo com a legislao.
P3: no comentou
P4: preciso considerar dois papis claramente: cliente (consumidor de uma
soluo computacional) e fornecedor (produtor dessa soluo). A anlise da
viabilidade financeira uma atividade do cliente, no do fornecedor. Alis, o cliente j
tem parmetros para tal anlise, o que torna essa atividade sem uma utilidade para
ele. E para o fornecedor? Por que uma MPE deveria usar essa atividade?
P5: No ps-venda a equipe de vendas no acompanha o andamento do cliente,
sendo que necessrio um acompanhamento mtuo de suporte.
P6: no comentou
QUADRO A8.4 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO

PROJETO, CODIFICAO & INTEGRAO DE PRODUTO
Quanto ao Pontos P1: no comentou
Projeto, Fortes P2: no comentou
Codificao & P3: no comentou
Integrao de P4: no comentou
Produto P5: Um software deve ser bem projetado, desenvolvido e documentado de forma a
permitir uma fcil manuteno e evoluo do mesmo. Os custos de manuteno so
muito superiores ao custo de desenvolvimento do sistema. O modelo apresenta
atividades e templates para a realizao dessa rea de conhecimento que podem
auxiliar.
P6: a) Bem detalhado; b) Fornece subsdios para o incio da codificao por parte
dos responsveis pelo desenvolvimento do software.
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.5 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO AQUISIO

Quanto Pontos P1: no comentou
Aquisio Fortes P2: Clareza.
P3: no comentou
P4: Parece coerente
P5: Fazer cotaes e anlise de fornecedores importante para viabilizar o projeto.
P6: a) Auxilia o desenvolver no gerenciamento de aquisio de hardwares, por
exemplo, que estaro sendo usados para a implantao do software; b) Vasto material
de apoio; c) Bem detalhado.
P3: no comentou
P4: no comentou
P5: Sugiro inserir o Documento de requisitos do componente adquirido pelo
fornecedor, no caso de componente de software, como artefato do projeto que poder
ser modificado e, por isso, precisa ser colocado sob gerncia de requisitos tambm.
P6: no comentou
QUADRO A8.6 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO MEDIO

Medio Fortes P2: no comentou
P3: no comentou
P4: Parece coerente
P5: importantssimo avaliar os processos como forma de aprimoramento e
diminuio de redundncias nos processos.
P6: O modelo fornece subsdios para se ter dados relacionados a todos os projetos da
empresa; dados como tempo estimado e concretizado, valor cobrado, etc, que sero
utilizados para estimativas em projetos futuros.
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.7 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO IMPLANTAO

Implantao Fortes P2: a) Preocupao com a satisfao do cliente; b) Bem gerenciado.
P3: no comentou
P4: Parece coerente
P5: O modelo apresenta atividades relacionadas implantao dos releases do
produto ao cliente de forma completa.
P6: Cuida de todos os tpicos relacionados implantao e a entrega do material.
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.8 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO V&V

Quanto V&V Pontos P1: no comentou
Fortes P2: a) Muito bem distribudo e especificado nas fases; b) Presena marcante no
modelo proposto.
P3: no comentou
P4: no comentou
P5: Teste uma das tarefas mais importantes e que no deve ser negligenciada
durante o desenvolvimento, com apenas testes rpidos e sem critrios.
P6: Muito importante, porque nem sempre as empresas de software testam e validam
seus produtos antes de entregar para o cliente.
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.9 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO GARANTIA DA

QUALIDADE DE PRODUTO E PROCESSO
Garantia da Fortes P2: no comentou
Qualidade de P3: no comentou
Produto e P4: Parece coerente
Processo P5: A verificao de qualidade um processo apontado aqui em todas as etapas de
desenvolvimento.
P6: no comentou
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.10 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO GESTO DE CONHECIMENTO

Gesto de Fortes P2: Garantia de controle e disponibilidade do conhecimento.
Conhecimento P3: no comentou
P4: no comentou
P5: no comentou
P6: O modelo mostra uma forma de gerenciar o conhecimento de todos os
desenvolvedores da empresa, fazendo com que o conhecimento e experincia de um
desenvolvedor sejam disseminados para outros interessados.
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.11 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO GESTO DE REQUISITOS

Gesto de Fortes P2: Muito bem articulado e completo.
Requisitos P3: no comentou
P4: no comentou
P5: Importante para controlar qualquer tipo de requisito que possa influenciar na lgica
de processos.
P6: O gerenciamento de todos os requisitos muito importante e contemplado pelo
modelo.
P3: no comentou
P4: no comentou
P5: Sugiro inserir o Documento de requisitos do componente adquirido pelo
fornecedor, no caso de componente de software, como artefato do projeto que poder
ser modificado e, por isso, precisa ser colocado sob gerncia de requisitos tambm.
P6: no comentou
QUADRO A8.12 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO GESTO DE PROJETOS

Gesto de Fortes P2: Muito bem articulado e completo.
Projetos P3: no comentou
P4: no comentou
P5: importante entender o escopo do projeto e fazer o planejamento preliminar desse
escopo, a fim de ser ter uma viso macro em relao ao que se pretende atingir com o
produto resultante do projeto, quanto ser gasto, quanto demorar para ser produzido e
qual o retorno financeiro desse projeto. E, tambm, importante fazer o monitoramento
e controle desse projeto para que se possa tomar medidas reativas e at mesmo pr-
ativas. Esse modelo atende a esses requisitos.
P6: O Gerenciamento de Projetos muito importante e contemplado pelo modelo.
P3: no comentou
P4: no comentou
P5: no comentou
P6: no comentou
QUADRO A8.13 TRANSCRIO DAS RESPOSTAS REA DE CONHECIMENTO GESTO DE MUDANAS E CONFIGURAO
Gesto de Fortes P2: Completo e detalhado.
Mudanas e P3: no comentou
Configurao P4: no comentou
P5: Implementaes e mudanas em sistemas so processos constantes e, portanto,
necessrio um controle dessas modificaes.
P6: O gerenciamento das verses dos softwares desenvolvidos pela empresa muito
importante e o modelo fornece sugestes de como faz-lo.
P3: no comentou
P4: no comentou
P5: Acho importante um Controle para Help-Desk
P6: no comentou
Apndice 9 Respostas do Questionrio P g i n a | 327
Apndice 9 Respostas do Questionrio respondido pelos

Profissionais
Os Quadros A9.1 a A9.4 apresentam as respostas transcritas relacionadas a 4
(quatro) questes respondidas pelos 6 (seis) profissionais que avaliaram o modelo.
QUADRO A9.1 TRANSCRIO DA RESPOSTA PARA A QUESTO 1

Questo 1 Respostas
Para uma MPE, o P1: Um outro modelo com mais detalhes.
que mais fcil: P2: O melhor utilizar um modelo como o proposto neste trabalho, pois uma MPE no
utilizar como teria recursos financeiros, pessoas e tempo para criar um modelo com base no CMMI.
modelo de Alm disso, os detalhes e as orientaes de como e o que deve ser feito auxiliam muito.
referncia para Outro fator a clareza e a riqueza de detalhes que tornam a adoo do modelo um
criar o seu processo mais rpido e eficiente.
processo padro o P3: A utilizao do modelo apresentado nesse trabalho torna-se mais efetivo que o
CMMI ou um outro CMMI, uma vez que sugere os templates e documentos de apoio. A aplicao de
modelo com mais qualquer modelo que cita diretrizes gerais dificulta a aplicao, pois deixa sem
detalhes de como direcionamento o procedimento de aplicao.
podem ser P4: Acredito que para uma MPE seria mais fcil iniciar com um modelo simplificado, e
realizadas as no com um modelo com mais atividades. A estrutura organizacional geralmente
atividades do pequena para tantas atividades. Dessa forma, medida que a organizao cresce, tem
processo, como o condies de evoluir seu processo de desenvolvimento e comercializao.
proposto nesse P5: Na minha opinio, o modelo CMMI muito complexo, e acho que o modelo
trabalho de apresentando nesse trabalho poderia auxiliar mais (logicamente adaptado realidade da
pesquisa? empresa).
P6: mais fcil utilizar um modelo com mais detalhes porque cada atividade de cada
rea de conhecimento foi detalhada, fornecendo material suficiente para que cada
empresa utilize os modelos do jeito que lhe for mais til.

Questo 2 Respostas
Para uma MPE, o P1: Um outro modelo com mais detalhes.
que mais fcil: P2: Um outro modelo com mais detalhes.
utilizar como P3: Apesar da norma ISO/IEC 15504-5 ter mais detalhes com relao aos
modelo de procedimentos, ainda no contm os templates que podem ser o diferencial na hora de
referncia para uma aplicao real.
criar o seu P4: Acredito que para uma MPE seria mais fcil iniciar com um modelo simplificado, e
processo padro a no com um modelo com mais atividades. A estrutura organizacional geralmente
norma ISO/IEC pequena para tantas atividades. Dessa forma, medida que a organizao cresce, tem
15504-5 ou um condies de evoluir seu processo de desenvolvimento e comercializao.
outro modelo com P5: Na minha opinio, comparando o CMMI com a 15504-5, acredito que o ltimo
mais detalhes de muito mais fcil de ser compreendido e com possibilidade de ser usado at mesmo por
como podem ser uma MPE como subsdio para criar o seu processo padro. Entretanto, apesar de
realizadas as apresentar prticas base, resultados, produtos de trabalho tpicos e at mesmo
atividades do sugestes de itens a serem abordados nesses produtos de trabalho, a ISO 15504-5
processo, como o (assim como o CMMI) no fornece templates mais detalhados a respeito desses
proposto nesse produtos, o que facilitaria e muito o entendimento de como fazer para realizar as
trabalho de atividades em MPEs.
pesquisa? P6: Um outro modelo com mais detalhes, como o apresentado nesse trabalho.

Questo 3 Respostas
Voc enxerga o P1: Sim.

modelo proposto P2: Sim, pois o modelo aborda todos os aspectos relevantes do processo de
nesse trabalho de desenvolvimento de software para as MPEs, enfocando especificamente suas
pesquisa como caractersticas e necessidades (busca de clientes, agilidade, inexperincia na rea de
uma referncia, um Engenharia de Software, recursos limitados). extremamente vivel, pois alm de
guia que poderia descrever cada fase do modelo proposto com um vocabulrio de fcil entendimento,
ser utilizado por ainda indica/sugere formas para sua aplicao na empresa. Alm disso, possui
uma MPE para, a referncias e anexos contendo a fundamentao terica sobre cada assunto que pode
partir dele, definir o no ser trivial ao seu pblico-alvo.
seu processo P3: Sim. Acredito que as reas podem ser instanciadas isoladamente para melhoria de
padro (mesmo determinadas reas de um processo, especialmente, em empresas que j detm algum
que sejam procedimento organizado de concepo e construo de software. Entretanto, para MPE
necessrios alguns ainda acredito ser necessrio algumas simplificaes, pois o modelo est complexo e
ajustes para exige um grau de conhecimento tcnico e de recursos humanos que pode inviabilizar
adequar seu uso.
realidade da P4: Pelo que tenho visto, seria ideal. Mas a realidade outra. Ele seria til para
empresa)? conscientizar uma MPE sobre a necessidade e vantagens de se ter um processo
padro, e at mesmo considerar tarefas que podem no ser consideradas em tal
organizao (at por no ter sentido a necessidade delas).
P5: Sim. Alis, se encaixa muito no atual processo organizacional de minha empresa de
software, com apenas pequenos ajustes, para adaptao do modelo realidade da
empresa.
P6: Sim. Para a minha empresa que est iniciando suas atividades, onde eu serei
responsvel por todas as reas de conhecimento, o modelo ser de muito auxlio, pois
seguirei normas estabelecidas e estarei de acordo com o que o mercado consumidor na
rea de TI quer: softwares bem projetados e empresas de software com seus processos
de desenvolvimento bem definidos.

Questo 4 Respostas
De forma geral, P1: Este modelo um guia de referncia espetacular para uma MPE criar seus
quais os processos de software. um modelo genrico que serve para a empresa vender,
comentrios voc modelar e executar qualquer tipo de processo de software, sem a necessidade da
faria a respeito do contratao de consultores especializados neste tipo de trabalho por um tempo muito
modelo proposto? grande, o que seria invivel para uma MPE. O modelo proposto fcil de entender, pois
contm todas as atividades necessrias para a venda e desenvolvimento de software,
descritas de uma maneira simples e completa, com nfase s tarefas de cada atividade,
bem como suas entradas e sadas, quem deve execut-las e os recursos que podem ser
utilizados, tornando o processo auto-explicativo e possvel de ser conduzido por uma
MPE.
P2: Com eficincia e baixo custo, o modelo proporciona o gerenciamento de projetos,
auxilia na melhoria da qualidade dos produtos desenvolvidos. O detalhamento das fases
e as orientaes sobre o qu e como realizar as tarefas extremamente til e
relevante, uma vez que facilita o uso e adaptao ao modelo. Outro ponto relevante a
rea de conhecimento comercializao que foi inserida no modelo e que fundamental
para as empresas de desenvolvimento de software, pois envolve atividades de busca
por potenciais clientes, o que muitas vezes as empresas no dedicam o devido tempo.
Seria interessante que o modelo fosse testado/experimentado por alguma(s) empresa(s)
de desenvolvimento de software. Assim, vrias opinies e sugestes significativas
poderiam ser obtidas.
P3: Alguns exemplos esto em ingls e outros em portugus. Seria interessante definir
uma padronizao, idealmente, em portugus. Seria tambm interessante explicitar em
todas as tarefas das atividades, que possvel consultar/atualizar a base de
conhecimento da empresa.
P4: A organizao est um tanto confusa. No fica claro como os ciclos do RUP (que
baseado em modelo Espiral) ficariam nesse processo. Tambm no fica claro como uma
organizao utilizaria tal processo para o primeiro projeto. Por exemplo, considere uma
proposta de uma empresa a ser incubada em uma Incubadora Tecnolgica, que ainda
no tem cliente e no tem produto. Nesse caso, vrios artefatos utilizados como
subsdios ainda no existem. Como fica o processo? Para melhorar, facilitando seu uso
por uma MPE, o uso de um modelo o processo para apoiar a definio de um processo
deveria ser evolutivo, iniciando com atividades fundamentais, com vistas ao crescimento
e facilidade de evoluo do processo simplificado (inicial) para um processo mais
completo e maduro, conforme a organizao evolui (cresce).
P5: Achei muito interessante o modelo por se adequar realmente realidade de uma
MPE, uma vez que importante estudar tendncias que o mercado direciona.
P6: Muito bom - o modelo fornece s MPEs uma orientao de como podem realizar as
atividades de um processo de venda e desenvolvimento de software, possibilitando que
a empresa adapte o modelo s suas necessidades.

AndreaPadovanJubileu 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

AndreaPadovanJubileu PDF

Transféré par

Droits d'auteur :

Formats disponibles

Modelo de Gesto do Processo de

Andrea Padovan Jubileu

Tese apresentada Escola de Engenharia de So

Orientador: Professor Titular Henrique Rozenfeld

aos meus pais Geraldo e Matilde.

A Deus, por guiar os meus passos.

Ao Renato, meu grande amor e companheiro, grande incentivador desse trabalho.

Aos funcionrios e docentes do Departamento de Engenharia de Produo da EESC, em especial ao

JUBILEU, A. P. Modelo de Gesto do Processo de Venda e Desenvolvimento de

A maioria das micro e pequenas empresas (MPEs) de desenvolvimento de software

brasileiras so voltadas para o desenvolvimento de software on-demand. Normalmente,

essas MPEs tm dificuldades em formalizar um processo de software padro. O presente

trabalho de pesquisa tem por objetivo apresentar uma proposta de integrao de

modelos/normas de capacidade de processo com modelos de ciclo de vida de software, em

um contexto de gesto de processos de negcio. Como resultado, obteve-se o Modelo de

Gesto do Processo de Venda e Desenvolvimento de Software On-demand para MPEs

(ProcSoftVD - Gesto), composto pelo Mtodo de Melhoria de Processo de Software

(ProcSoftVD Melhoria) e pelo Modelo de Processo de Venda e Desenvolvimento de

Software On-demand para MPEs (ProcSoftVD). O Mtodo de Melhoria de Processo de

Software foi criado a partir de abordagens existentes e complementares, voltadas s MPEs.

O ProcSoftVD foi originado com base no framework Unified Process, possibilitando a

visualizao do processo em duas perspectivas fases e reas de conhecimento, e nos

modelos/normas de capacidade de processo CMMI-DEV e ISO/IEC 15504-5, elaborado em

um processo iterativo e evolutivo de pesquisa-ao com a participao de duas MPEs. Um

diferencial dessa proposta a considerao de atividades de comercializao do software

junto ao processo de desenvolvimento de software, o que auxilia na delimitao do escopo

do projeto de desenvolvimento de software para um acordo contratual. Outro diferencial o

detalhamento das atividades do processo por meio de tarefas, sugesto de papis

desempenhados pelos responsveis das atividades e disponibilizao de templates com

exemplos para cada um dos artefatos elaborados na execuo da atividade.

Palavras-chave: Modelo de Processo de Software, Qualidade de Processo de Software,

Melhoria de Processo de Software.

JUBILEU, A. P. Management Model of Selling and On-demand Software

the goal of this research is to propose an integration of capability processes

models/standards within software life cycle models, in a perspective of business process

demand Software Development Process, which embraces the Software Process

Development Process Model was created based on the models/standards of process

created during the activities.

Figura 2.1 Modelo de Processo de Software Clssico (Cascata) ...................................................... 26

LISTA DE FIGURAS/TABELAS/QUADROS ................................................................................................... 8

1.1. Contexto do Trabalho de Pesquisa

distribuidoras ou editoras de software de terceiros, no total de 488 empresas, 396 so

empresas que desenvolvem software on-demand (81,1%). Adotando-se o critrio aplicado

fora de trabalho efetiva - microempresas (de 1 a 9 pessoas), pequenas (de 10 a 49

empresas e 85,9% das pequenas empresas desenvolvem software on-demand,

confirmando-se a predominncia de micro e pequenas empresas (MPEs) no cenrio de

desenvolvimento de software on-demand no Brasil.

Em busca de melhorar tanto a qualidade de seus produtos de software quanto a

produtividade do desenvolvimento de software, cada vez mais as MPEs esto percebendo a

importncia da existncia de um processo1 de software2 formalizado na empresa e

investindo na melhoria do processo de software. Essa afirmao pautada nos resultados

Proceedings of the First International Research Workshop for Process Improvement in

Small Settings da SEI (Software Engineering Institute). No contexto brasileiro, comprova-se

um aumento do desempenho de processos de software o que auxilia na melhoria da

qualidade de produtos de software e no aumento das vantagens competitivas das empresas

brasileiras tanto no mercado nacional quanto internacional (ROCHA et al., 2005).

Um processo de software bem estabelecido, compreendido e controlado auxilia aos

desenvolvedores obter um produto final com qualidade (SOFTWARE ENGINEERING

Para o estabelecimento de um processo de desenvolvimento de software podem ser

Cascata, Incremental, Espiral e RAD (Rapid Application Development) (PRESSMAN, 2006;

SOMMERVILLE, 2007); um framework de processo, tal como o UP (Unified Process)

(JACOBSON et al., 1999); uma norma, como a ISO/IEC 12207 (INTERNATIONAL

ORGANIZATION FOR STANDARDIZATION, 2001), que define as atividades, objetivos e