Guia - Desenvolvimento de Software

GUIA DE IMPLEMENTAO
DESENVOLVIMENTO DE SOFTWARES PARA PEQUENAS ORGANIZAES

SRIE ABNT NBR ISO/IEC 29110
FICHA CATALOGRFICA

Documento elaborado no mbito do Convnio ABNT/SEBRAE, destinado s micro e pequenas empresas.

Copyright 2012. Associao Brasileira de Normas Tcnicas
Copyright 2012. Servio Brasileiro de Apoio s Micro e Pequenas Empresas
Conteudista tcnica: Gisele Villas Boas
A849g
Associao Brasileira de Normas Tcnicas
Guia de implementao: Desenvolvimento de softwares para pequenas
organizaes [recurso eletrnico] / Associao Brasileira de Normas Tcnicas, Servio
Brasileiro de Apoio s Micro e Pequenas Empresas. Rio de Janeiro: ABNT; SEBRAE, 2012.
69 p.: il.color.

Modo de acesso:
http://portalmpe.abnt.org.br/bibliotecadearquivos/.
ISBN 978-85-07-03956-3.
1. Engenharia de software. 2. Normalizao tcnica
I. Ttulo. II. Servio Brasileiro de Apoio s Micro e Pequenas Empresas

CDU:006:004.41(083)
SEBRAE

Roberto Simes
Presidente do Conselho Deliberativo Nacional

Luiz Eduardo Pereira Barretto Filho
Diretor-Presidente do Sebrae Nacional

Jos Cludio dos Santos
Diretor de Administrao e Finanas do Sebrae Nacional

Carlos Alberto dos Santos
Diretor Tcnico do Sebrae Nacional

Enio Duarte Pinto
Gerente da Unidade de Acesso Inovao e Tecnologia

Glucia Zoldan
Gerente Adjunta da Unidade de Acesso Inovao e Tecnologia

EQUIPE TCNICA

Maria de Lourdes da Silva
Analista tcnica
Gestora do Convnio ABNT/SEBRAE

Hulda Oliveira Giesbrecht
Analista Tcnica
Gestora da ao de desenvolvimento dos Guias de Implantao de
Normas
ABNT

Pedro Buzatto Costa
Presidente do Conselho Deliberativo

Walter Luiz Lapietra
Vice-Presidente do Conselho Deliberativo

Ricardo Rodrigues Fragoso
Diretor Geral

Carlos Santos Amorim Junior
Diretor de Relaes Externas

Eugenio Guilherme Tolstoy De Simone
Diretor Tcnico

Odilo Baptista Teixeira
Diretor Adjunto de Negcios

EQUIPE TCNICA

Janana da Silva Mendona
Gerente de Editorao e Acervo
Coordenao geral

Marcia Cristina de Oliveira
Gerente de Planejamento e Projetos
Apoio tcnico

Anderson Correia Soares
Assistente Tcnico da Gerncia de Editorao e Acervo
Apoio tcnico
4
S
U
M
R
I
O
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Introduo .......................................................................................................................... . 7
Objetivos ............................................................................................................................10
Parte I - Contexto de aplicao e estrutura da srie ISO/IEC 29110 .......................12
1. O contexto de aplicao da srie ISO/IEC 29110 ..............................................................12
1.1 A indstria de software ......................................................................................................12
1.2 A crise do software continua? ..........................................................................................13
1.3 A qualidade do produto pela qualidade do processo ............................................16
2. VSE (VERY SMALL ENTITIES) e a srie ISO/IEC 29110 ......................................................17
2.1 VSE (VERY SMALL ENTITIES) ..............................................................................................17
2.2 ISO/IEC 29110: uma srie de normas e guias para pequenas organizaes ..17
3. Grupo de perfil genrico ............................................................................................................1 8
3.1 Os perfis do grupo de perfil genrico .................................................................................1 9
3.2 Estrutura bsica da srie e seus perfs ................................................................................19
3.3 Os documentos da srie ..........................................................................................................20
3.3.1. Netcenters e pacotes de implementao (deployment packages - dp) ............23
Parte II - implementao do perfl bsico para melhorar o processo de
desenvolvimento de software .............................................................................24
4. Melhorando um processo de desenvolvimento de software .......................................24
5. Implementando o perfl bsico - ABNT NBR ISO/IEC 29110-4-1 .................................26
5.1 Os processos do perfl bsico ..........................................................................................27
5.2 Os requisitos da ABNT NBR ISO/IEC 29110 ...............................................................28
5.3 Os cuidados na hora de decidir melhorar os processos.........................................33
6. Metodologia para implementao do perfl bsico .........................................................36
6.1 FASE 1 DIAGNSTICO ....................................................................................................37
6.1.1 Identifcao das caractersticas iniciais ...................................................................37
6.1.2 Realizao do diagnstico inicial ................................................................................38
GUIA DE IMPLEMENTAO
|
DESENVOLVI MENTO DE SOFTWARES PARA PEQUENAS ORGANI ZAES
|
SUMRIO
SUMRIO
5
S
U
M
R
I
O
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
SUMRIO
GUI A DE I MPLEMENTAO
6.2 FASE 2 PREPARAO ......................................................................................................39
6.2.1 Planejamento do projeto de implementao .......................................................39
6.2.2 Identifcao e anlise de riscos .................................................................................40
6.2.3 Comprometimento e comunicao ..........................................................................41
6.2.4 Capacitao da equipe ..................................................................................................41
6.3 FASE 3 EXECUO ............................................................................................................43
6.3.1 Implementao de melhoria de processos ............................................................43
6.3.2 Desenvolvimento dos projetos: o processo produtivo ......................................49
a) planejando o projeto ............................................................................................................51
b) execuo do plano de projeto ..........................................................................................53
c) avaliao e controle de projeto .........................................................................................54
d) encerramento do projeto ....................................................................................................55
e) iniciao da implementao do software .....................................................................55
f ) anlise dos requisitos do software ...................................................................................56
g) projeto de arquitetura e detalhamento do software ................................................57
h) construo do software .......................................................................................................59
i) integrao e testes do software .........................................................................................60
j) entrega do produto ................................................................................................................61
6.3.3 Acompanhamento da aderncia dos projetos aos processos ...........................62
6.3.4 Identifcao das no conformidades e oportunidades de melhoria .............62
6.4 FASE 4 MELHORIA ............................................................................................................63
6.4.1 Realizao de auditorias (internas e externas) .......................................................63
6.4.2 Tratamento das no conformidades ..........................................................................63
ANEXOS
ANEXO A ........................................................................................................................................64
ANEXO B .........................................................................................................................................6 7
ANEXO C ........................................................................................................................................70
REFERNCIAS ....................................................................................................................................75
6
S
U
M
R
I
O
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
SUMRIO
SUMRIO
NDICE DE FIGURAS
Figura 1 - Evoluo do mercado 2004 - 2010 (total) .............................................................12
Figura 2 - Evoluo do mercado 2004 - 2010 (por setor) ....................................................13
Figura 3 - Camadas da Engenharia de Software ....................................................................14
Figura 4 - A evoluo do software ...............................................................................................15
Figura 5 - Relacionamento entre os elementos de perfl e os grupos de perfs .........18
Figura 6 - Estrutura da srie ISO/IEC 29110 ..............................................................................19
Figura 7 - Agrupamento dos documentos da srie, por aplicao .................................20
Figura 8 - Interao entre os processos do perfl bsico .....................................................27
Figura 9 - Elementos dos processos da ABNT NBR ISO/IEC 29110...................................28
Figura 10 - Lgica de implementao do perfl bsico da srie ISO/IEC 29110 ..........32
Figura 11 - Aplicao do ciclo PDCA na implementao de melhoria de processos 33
Figura 12 - Modelo para implementao de melhoria de processos .............................36
Figura 13 - Modelo cascata ............................................................................................................44
Figura 14 - Modelo de prototipagem (adaptado de Pressman, 2010) ...........................45
Figura 15 - Modelo incremental (adaptado de Pressman, 2010) .....................................46
Figura 16 - Processo unifcado (adaptado de Pressman, 2010) ........................................47
Figura 17 - Ciclo de processo baseado no mtodo SCRUM ...............................................47
Figura 18 Processo Extreme Programming (Adaptado de Pressman, 2010) ..............48
Figura 19 - Inter-relacionamentos no contexto de uma VSE .............................................50
Figura 20 - Elementos de um perfl internacional normalizado .......................................65
NDICE DE TABELAS
Tabela 1 - Grupos de perfs e perfs ............................................................................................18
Tabela 2 - Documentos normativos ............................................................................................21
Tabela 3 - Srie ISO/IEC 29110, suas partes, categorias e pblicos-alvo........................22
Tabela 4 - Requisitos obrigatrios do perfl bsico Processo PM..................................30
Tabela 5 - Requisitos obrigatrios do perfl bsico Processo SI ....................................31
Tabela 6 - Exemplo de contedo de um pacote de implementao ..............................69
7
DESENVOLVIMENTO DE SOFTWARES PARA PEQUENAS ORGANIZAES GUIA DE IMPLEMENTAO
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

INTRODUO
A histria tem indicado que modelos convencionais [de processos de
desenvolvimento de software] tm trazido certa dose de estrutura til
para o trabalho de engenharia de software e tm fornecido um roteiro
razoavelmente efetivo para as equipes de desenvolvimento. No entan-
to, o trabalho de engenharia de software e o produto que ele produz
permanecem no limite do caos.
Nogueira, J., Jones, C. e Luqi
Garantir a qualidade do que produzido sabidamente um fator crtico de sucesso
no negcio das pequenas empresas. Mais que isso, necessrio ter padres de qualidade
equiparveis aos padres internacionais. A srie ISO/IEC 29110 um instrumento que pode
propiciar s micro e pequenas empresas (MPE) desenvolvedoras de produtos e servios de
software ter um processo produtivo de maior qualidade e, com isso, aumentar a satisfao
dos seus clientes, sua competitividade e sua capacidade de acessar novos mercados.
Segundo pesquisa apresentada pelo Observatrio SOFTEX, das quase 70 mil empresas
que compem a Indstria Brasileira de Software e Servios de TI (IBSS), 97,3% so classif-
cadas como MPE com at 19 pessoas em sua fora de trabalho. Por outro lado, para o con-
texto de TI, alguns estudos e pesquisas, entre eles o relatrio apresentado em 2005 pela
Organization for Economic Co-operation and Development (OECD), indicam que a maioria
das Normas Internacionais e modelos de referncia no contempla as necessidades das
pequenas organizaes. Questionadas sobre o tema, as MPE relataram difculdades no
alinhamento entre as normas e seus objetivos de negcio e disseram, ainda, apesar de
reconhecerem a importncia do uso de normas, no enxergar justifcativa para aplicao
dessas em suas prticas empresariais. Para as pequenas empresas, que em sua maioria
convive com restries fnanceiras relevantes, alm da complexidade, outros fatores tam-
bm colaboram para a no adoo das normas, entre eles: falta de recursos (fnanceiros
e humanos), alto custo e longa durao para os projetos de implantao de melhoria de
processos baseados em normas e modelos.
Com o objetivo de dirimir estas difculdades e propiciar ao contexto especfco das micro
e pequenas empresas a possibilidade de serem reconhecidas como produtoras de software
de alta qualidade em seus domnios, tanto em seus mercados internos quanto no mercado
internacional, foi desenvolvida a srie de normas tcnicas ISO/IEC 29110, no mbito do ISO/
IEC JTC1 (Joint Technical Commitee 1 Comit conjunto da ISO e da IEC para a tecnologia
da informao). A ISO a Organizao Internacional de Normalizao (International Orga-
nization for Standardization) e a IEC a Comisso Eletrotcnica Internacional (International
Electrotechnical Commission), o organismo internacional para a rea eletroeletrnica. Estes
organismos internacionais de normalizao esto organizados em Comits Tcnicos e cons-
tituram alguns Comits conjuntos, sendo o JTC 1 um deles. Estes Comits Tcnicos so or-
ganizados em Subcomits, que tratam da normalizao de reas ou temas especfcos. Os
trabalhos tcnicos so desenvolvidos em Grupos de Trabalho, os WG (working groups), que
se subordinam aos Subcomits ou ao prprio Comit.
Um dos Subcomits do JTC 1 o SC7 Software and Systems Engineering (Subcomit de
Engenharia de Software e Sistemas), e no mbito do SC7 que est constitudo o WG 24, res-
GUIA DE IMPLEMENTAO
|
|
INTRODUO
8
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

ponsvel pelo desenvolvimento das normas de engenharia de software para micro e pequenas
organizaes. Desde a criao do WG 24, em 2005, era consenso e prioritrio que as normas e
guias produzidos pudessem ser usados por uma VSE (Very Small Entity) para, de fato, ajud-las
a evoluir seu processo produtivo como um ato de melhoria contnua que, por consequncia,
resultasse no aumento da garantia de qualidade de seus produtos e servios. Pretende-se, alis,
que as normas da srie ISO/IEC 29110 sejam utilizadas para certifcao de maneira a propiciar
ao mercado um instrumento concreto e confvel para promover o uso do software produzido
pelas VSE. O fato de se tratar de uma Norma Internacional pode, de fato, contribuir para facilitar
o acesso das MPE ao mercado, tanto no mbito nacional quanto no mbito internacional.
O WG24, que tem o Brasil como um dos pases participantes, tem em seu escopo:
i. desenvolver normas acessveis s VSE (Very Small Entities);
ii. prover documentao que exija um mnimo de adaptao;
iii. prover documentao harmonizada com as normas existentes, considerando:
processos padronizados, produtos de trabalho e entregveis, avaliao e qualidade,
modelagem e ferramentas.
Em uma de suas primeiras atividades, o WG24 realizou um levantamento com as VSE de
vrios pases, com o intuito de identifcar uma srie de caractersticas que afetam o contedo, a
natureza e a extenso de suas atividades. Esto entre elas:
dedicao principal no projeto (design) e/ou codifcao do software de pequeno porte;
falta de experincia signifcativa no desenvolvimento de grandes projetos e, por
consequncia, difculdades em atrair clientes entre as grandes empresas (ou mesmo que
os atraiam esto sempre na iminncia de perd-los);
muitas vezes, boa parte do pessoal envolvido com a implementao de software
relativamente inexperiente;
o foco dos projetos direcionado para a codifcao e falta disciplina nas tarefas de
desenvolvimento como um todo;
faltam ativos de processo;
acesso limitado a emprstimos e investimentos;
viso de curto prazo, cerca de seis meses, de modo que os benefcios de longo prazo da
adoo de um ciclo de vida slido e disciplinado acabam sendo relegados;
falta de credibilidade por no possuir credenciais (certifcaes, selos etc.) ou referncias
importantes de clientes anteriores;
imposio por parte do cliente do seu prprio processo de desenvolvimento.
Dadas as caractersticas anteriores, a pesquisa coletou dados sobre o problema de ado-
o de normas e apontou algumas importantes concluses. Entre elas:
as caractersticas das VSE recomendam o uso de ciclos de vida leves e bem focados na
sua atuao;
contextos especfcos de negcio requerem processos compatveis com eles;
a disponibilidade de recursos e infraestrutura signifcativamente diferente entre uma
GUIA DE IMPLEMENTAO
|
|
INTRODUO
9
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

VSE que possua, por exemplo, at 10 colaboradores em sua fora de trabalho e um
departamento de TI em uma organizao maior, com o mesmo nmero de colaboradores;
as VSE esto limitadas tanto em tempo disponvel como em recursos, o que as impede de
investir na adoo de normas que lhes tragam benefcios;
a obteno de um reconhecimento ou certifcao por avaliao formal feita por um
organismo acreditado um importante benefcio para as VSE.
Visando contemplar as caractersticas e concluses anteriores, foi iniciado, em 2006, o de-
senvolvimento da srie ISO/IEC 29110, tomando por base um subconjunto das normas ISO/
IEC relevantes para o contexto das pequenas empresas de TIC e para o desenvolvimento dos
perfs e guias de implementao que possibilitam a essas empresas a adoo de uma Norma
Internacional e a obteno de uma certifcao que possa traduzir para o mercado a qualidade
de seu processo produtivo.
A Comisso de Estudo da ABNT de Engenharia de Software e Sistemas - Perfs de Ciclo de
Vida para Micro-Organizaes (CE-21:007.24) espelha os trabalhos do WG24 no Brasil. Em feve-
reiro de 2012, a ABNT publicou trs partes da srie Engenharia de software Perfs de ciclo de
vida para micro-organizaes (VSE):
a Parte 2, ABNT NBR ISO/IEC 29110-2:2012, que estabelece a estrutura e taxonomia da
srie;
a Parte 4-1, ABNT NBR ISO/IEC 29110 4 1:2012, que apresenta as especifcaes de perfl
para o Grupo Perfl Genrico; e
a parte 5-1-2, ABNT ISO/IEC TR 29110-5-1-2:2012, um guia de engenharia e gesto para
projetos de desenvolvimento de software.
Cada uma dessas partes apresentada de forma mais detalhada na primeira parte deste
Guia. A parte 4-1 foco deste guia e foi desenvolvida para descrever os elementos mnimos
necessrios para que uma VSE desenvolvedora de software construa produtos e servios de
software mais confveis, previamente defnidos, com um menor nmero de erros, no menor
prazo possvel e dentro dos custos planejados. A parte 4-1, ABNT NBR ISO/IEC 29110 4-1:2012,
compe a srie ISO/IEC 29110.
GUIA DE IMPLEMENTAO
|
|
INTRODUO
10
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

OBJETIVOS
GUIA DE IMPLEMENTAO
|
|
OBJETIVOS
Este Guia tem dois objetivos especfcos. O primeiro apresentar um entendimento glo-
bal e consolidado quanto ao conjunto de documentos da srie ISO/IEC 29110 Engenharia
de Software Perfs de Ciclo de Vida para VSE (Very Small Entities). O segundo objetivo deste
Guia orientar as VSE ou pequenas entidades desenvolvedoras de software sobre como im-
plementar um projeto de melhoria dos processos de Gesto de Projetos e Implementao
de Software, atendendo aos requisitos descritos na ABNT NBR ISO/IEC 29110-4-1:2012. Deste
modo, este Guia no deve substituir nenhuma das partes da srie ISO/IEC 29110, mas sim ser
usado em conjunto com elas.
Para melhor alcanar os objetivos pretendidos, o corpo principal deste Guia foi divi-
dido em duas partes.
A primeira parte, Parte I - Contexto de aplicao e estrutura da srie ISO/IEC 29110,
apresenta a contextualizao da indstria de software, a defnio de alguns conceitos
que serviram de base para o desenvolvimento dos documentos da srie ISO/IEC 29110
e as caractersticas que indicam que uma organizao pode ser classifcada como uma
VSE. Ainda nesta parte so apresentadas a estrutura lgica da srie e a descrio sumria
de cada uma de suas partes.
A segunda parte deste Guia, Parte II Implementando o perfl bsico da srie
ISO/IEC 29110, prope um mtodo de implementao dos processos de Gesto de
projetos e implementao de software e apresenta algumas discusses entre o estado da
arte e a comunidade de prtica e suas inter-relaes com os processos preconizados na
ABNT NBR ISO/IEC 29110-4-1:2012 e seus requisitos mandatrios e opcionais.
Sabe-se que o processo de produo de software est sujeito aos impactos cau-
sados pela evoluo quase contnua das ferramentas e metodologias que apoiam
a sua execuo. Portanto, importante destacar que o mtodo de implementao
proposto neste Guia, assim como as orientaes prticas nele contidas, no tm a
pretenso de ser a nica ou a mais apropriada abordagem para atender aos requisi-
tos da ABNT NBR ISO/IEC 29110-4-1:2012.
Uma VSE, ao usar este Guia, deve faz-lo em conjunto com os outros documentos
da srie ISO/IEC 29110 e, principalmente, deve observar as informaes inerentes ao
seu prprio contexto. Peculiaridades contratuais com os clientes, critrios estratgicos
da organizao ou dos projetos, nveis de conhecimento da equipe, comprometimento
das partes interessadas e tecnologias disponveis so alguns exemplos de fatores que
devem ser considerados.
Espera-se que a aplicao deste Guia em conjunto com os documentos da srie
ISO/IEC 29110 possibilite que os gestores de pequenas empresas desenvolvedoras de
software respondam positivamente as seguintes perguntas:
Sei o que est sendo feito e por qu?
Posso garantir que cada membro da minha equipe tem o mesmo entendimento do
que est sendo feito?
Tenho controle sobre a integrao do que dois ou mais desenvolvedores produzem?
Posso desenvolver um produto dentro do prazo e do oramento estabelecidos?
Posso garantir que o software produzido, tecnicamente, faz o que deveria fazer?
11
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
OBJETIVOS
Posso garantir que o software produzido faz o que o cliente quer que ele faa?
Quando as mudanas ocorrem e sei que elas ocorrem estou preparado para
conhecer os seus impactos e para incorpor-las ao trabalho da forma adequada?
Sei o ponto exato em que o meu projeto de desenvolvimento encerrado e passa a ser
um projeto de manuteno de produto?
Estou pronto para um aumento de demanda de clientes e produtos?
Respostas positivas s perguntas anteriores podem aumentar a segurana do aten-
dimento aos requisitos dos clientes, a conformidade dos processos aos requisitos da nor-
ma e a construo mais rpida de produtos e servios cada vez melhores.
Deste modo, alm de proporcionar uma certifcao que pode ter reconhecimento
internacional e facilitar o acesso ao mercado externo, a adoo da srie ISO/IEC 29110
por uma VSE pode propiciar outros benefcios, como, por exemplo, o estabelecimento
de processos internos de gesto e implementao de software adequados ao seu con-
texto, aumento da confana e satisfao dos clientes, maior qualidade do produto ou
servio de software, aumento de patrocnio para a melhoria de processos e diminuio
dos riscos de desenvolvimento.
esperado, portanto, que a adoo da srie ISO/IEC 29110 favorea o crescimento
das MPE desenvolvedoras de produtos e servios de software, o fortalecimento econ-
mico da indstria de TIC e, por consequncia, do Pas.
12
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

1. O CONTEXTO DE APLICAO DA SRIE ISO/IEC 29110
1.1 A indstria de software
O fenmeno do avano tecnolgico ciclicamente revoluciona a humanidade e, nas
ltimas dcadas, tem-se acelerado e apresentado um crescimento vertiginoso. Com ele
vem a reboque o crescimento tambm signifcativo da indstria de software que, pra-
ticamente inexistente na dcada de 70, hoje movimenta um mercado mundial de U$
884,5 bilhes de dlares.
Mais de 8.500 empresas exploram atualmente o mercado de software no Brasil, que
assumiu, em 2011, a 10 posio mundial no ranking de software e servios, alcanando
um patamar de U$ 21,4 bilhes de dlares. Desse total de empresas atuantes no merca-
do brasileiro de software, 94% so classifcadas como micro e pequenas empresas (MPE).
A fgura 1 apresenta os indicadores de mercado e a evoluo do setor de software e
servio no pas que, excluindo-se o baixo resultado de 2009, vem refetindo taxas de
crescimento superiores a 20% ao ano.
Figura 1 - Evoluo do mercado 2004 - 2010 (total)
No subsetor especfico de software, o Brasil produziu, em 1990, cerca de U$ 230
milhes de dlares, ficando em sexto lugar no mercado mundial de computadores e
servios de informtica.
PARTE I - CONTEXTO DE APLICAO E ESTRUTURA DA SRIE ISO/IEC 29110
Na sociedade moderna, o papel da engenharia [de software] fornecer sistemas e
produtos que melhoram os aspectos da vida humana, tornando assim a vida mais
fcil, mais segura e mais agradvel.
Richard Farley e Mary Willshire
GUIA DE IMPLEMENTAO
|
|
PARTE I
13
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Daquela poca at os dias atuais, a produo de software tem estado cada dia mais
presente nos produtos e servios que consumimos. Nas transaes bancrias pessoais que
fazemos no nosso dia a dia, no uso dos sistemas administrativos implantados nas nossas
empresas, nos aparelhos mveis que usamos para simples comunicaes telefnicas ou
para acessar as redes sociais que nos ligam a amigos, quer estejam prximos quer estejam
do outro lado do mundo, e em outras tantas aes que realizamos, esto l presentes pro-
dutos e servios produzidos pela indstria de TIC.
A fgura 2 traz indicadores que apresentam a evoluo do mercado de software e ser-
vios de forma segmentada. Nela possvel observar que a participao especfca do
desenvolvimento e produo de software (programas de computador standard e sob en-
comenda) movimentou, em 2010, U$ 5,51 bilhes de dlares, alcanando um percentual
de 35% de participao no mercado nacional e enfatizando a tendncia de crescimento
apontada desde 2004.
A demanda por novos produtos e servios da indstria de TIC grande e tende a au-
mentar ainda mais. A expectativa que este crescimento exponencial continue por um
bom tempo, proporcionando quela indstria o surgimento de novos mercados relacio-
nados e novas empresas propondo-se a atend-los.
Figura 2 - Evoluo do mercado 2004 - 2010 (por setor)
1.2 A crise do software continua?
A evoluo tecnolgica provocou verdadeiras revolues no processo produtivo de
algumas indstrias, como, por exemplo, nas comunicaes e na medicina, entretanto, no
alcana resultados de to grande destaque quando se trata de uma das indstrias na qual
ela prpria protagonista: a indstria de software.
Nos idos dos anos 60, quando a frase the software crisis foi pronunciada pela primeira
vez, o processo de criao, construo e manuteno de software era considerado uma
arte. Problemas como baixa qualidade, requisitos no atendidos e estouro de prazo e custo
eram atribudos desestruturao de seus desenvolvedores, que no seguiam padres
nem regras de implementao. Os projetos de desenvolvimento de software apresenta-
vam, naquela ocasio, uma grande difculdade na sua gesto e manuteno. E isto acon-
tecia em uma poca em que a indstria de hardware corria a pleno vapor e demandava
Servios (U$ Bilhes)
Softwares (U$ Bilhes)
GUIA DE IMPLEMENTAO
|
|
PARTE I
14
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

sistemas cada vez mais complexos, seguros e efcientes. Chega-se ento concluso de
que as causas da crise do software estavam ligadas complexidade do seu processo de
desenvolvimento e relativa imaturidade da engenharia de software como profsso.
Este panorama marca o incio da Engenharia de Software, que nasceu como disciplina,
com a fnalidade de auxiliar a indstria para que a construo do software ocorresse de
forma mais adequada. Em 1982, o software j ultrapassava o hardware como chave para o
sucesso de muitos sistemas baseados em computador. Roger Pressman, puxando uma cor-
rente de outros grandes autores da rea, defne e apresenta conceitos que esclarecem por
que a criao, construo e manuteno de software deveriam deixar de ser considerados
arte e passar a ser enxergados como Cincia.
Friedrich Ludwig Bauer defniu Engenharia de Software como a criao e a utilizao de
slidos princpios de engenharia, a fm de obter software de maneira econmica, que seja
confvel e que trabalhe de forma efciente em mquinas reais. Teramos, em vez do artista
movido pela inspirao e talento, engenheiros orientados por mtodos e guias.
A Engenharia de Software apresentada por Pressman como uma tecnologia em ca-
madas. Na fgura 3 vemos que qualquer abordagem de engenharia deve ser apoiada em
um compromisso organizacional com a qualidade. A camada de processo o alicerce da
engenharia de software. ela que ir manter unidas as camadas de mtodos e ferramentas,
de modo a permitir um desenvolvimento de software racional.
Figura 3 - Camadas da engenharia de software (Adaptado de Roger Pressman, 6
a
edio)
Talvez um dos grandes desafos da Engenharia de Software seja, ainda, alinhar esta
expectativa de utilizao dos tais princpios slidos de engenharia, conforme dito por
Bauer, com as necessidades que emergem e exigem que o desenvolvimento de software
reinvente-se e renove-se em ciclos muito curtos para atender s demandas da evoluo
tecnolgica e, ao mesmo tempo, s necessidades de mercado.
A fgura 4 mostra a evoluo do software e destaca os principais aspectos em cada
uma de suas eras.
FOCO NA
QUALIDADE
FERRAMENTAS MTODOS
PROCESSOS
GUIA DE IMPLEMENTAO
|
|
PARTE I
15
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

PRIMEIROS ANOS
sistemas batch
distribuio
limitada
software
personalizado
A SEGUNDA ERA
sistemas
multiusurios
sistemas em
tempo real
banco de dados
software produto
A QUARTA ERA
sistemas desktop
poderosos
tecnologia
de orientao
a objetos
sistemas
especialistas
redes neurais
comunicao
intergalctica
A TERCEIRA ERA
sistemas
distribudos
incorporao de
inteligncia
hardware de
baixo custo
impacto do
consumidor
A QUINTA ERA
netbooks
Web 2.0
servios Web
computao em
nuvens
1950 1960 1970 1980 1990 2000 2010
Figura 4 - A evoluo do software
Atualmente falamos de internet, de computao em nuvem, de desenvolvimento dis-
tribudo e de engenharia de componentes, entre outras coisas. Alm disso, temos normas
que defnem diretrizes e requisitos sobre o que deve ser feito em centenas de especia-
lidades diferentes. Como as normas essencialmente no descrevem o como, para cum-
prir esta tarefa existem outras tantas dezenas de guias, padres, modelos de referncia,
metodologias e boas prticas que buscam entregar s empresas o caminho do sucesso
para a melhoria contnua e o alcance da alta maturidade no desenvolvimento de software.
Contudo, os bons resultados preconizados por esses instrumentos no so, ainda, uma
realidade relevante para a indstria brasileira de software. Passadas mais de cinco dcadas
da crise do software, continuamos com alguns dos mesmos problemas identifcados na-
quela poca. Entre eles esto:
Precariedade nas previses e planejamentos - os projetos de software atrasam e
sofrem problemas de custo por falta de planejamento e controle porque no se prev ade-
quadamente quanto tempo e esforo sero necessrios para produzi-los de maneira que
satisfaa as necessidades (requisitos) dos seus clientes.
Baixa qualidade de processos e produtos a falta de planejamento e de previsibili-
dade leva a prazos estourados e a produtos de software que por vezes no atendem s ne-
cessidades do cliente ou atendem s necessidades que no foram solicitadas originalmente.
Requisitos mal defnidos - os requisitos frequentemente no so especifcados e,
quando o so, ou no esto completos ou apresentam contradies. A garantia de quali-
dade neste cenrio uma tarefa de tentativa e sorte.
Alto custo para manuteno o que foi produzido no foi bem especifcado e tam-
pouco bem documentado; a manuteno corretiva - quando ocorrem erros ou falhas
difcil de ser identifcada. Normalmente isto acontece j em fase de implementao, onde
se tem que contabilizar no s o custo do retrabalho, como tambm o custo de todo o
esforo que foi gasto em vo. As manutenes evolutivas, embora sejam novas caracte-
rsticas adicionadas ao sistema, tambm podem ter o seu custo onerado quando se trata
de um produto de baixa qualidade, carente de especifcaes e documentaes. No
incomum manutenes tornarem-se inviveis devido s grandes difculdades e aos altos
custos de implementao.
GUIA DE IMPLEMENTAO
|
|
PARTE I
16
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Parte dos problemas apontados anteriormente pode ser atribuda, ainda, gesto de-
fciente ou inadequada dos projetos. Para se obter sucesso no desenvolvimento de softwa-
re, necessrio, alm de competncia da equipe tcnica, uma viso gerencial competente.
Em uma indstria cuja base formada por mais de 90% de MPE, vale destacar que pe-
quenas empresas de desenvolvimento no podem se dar ao direito de no ter qualidade.
Isto signifca dizer que elas no devem gastar os seus recursos - humanos, fnanceiros e
estratgicos - em retrabalho, erros e estimativas incorretas.
Muito mais importante do que adotar determinada norma, metodologia ou modelo
ter a conscincia de que preciso desenvolver produtos de software mais confveis,
previamente defnidos, com um menor nmero de erros, desenvolvidos no menor prazo
possvel e dentro dos custos planejados.
necessrio conhecer os pontos fracos e fortes do produto desenvolvido ou do ser-
vio prestado para que seja possvel identifcar esses pontos no processo de desenvolvi-
mento e trat-los adequadamente com aes que minimizem seus impactos negativos e
potencializem as chances de atender s metas estabelecidas para o projeto.
1.3 A qualidade do produto pela qualidade do processo
Diferentemente do que ocorre com a manufatura de produtos tangveis, onde nor-
malmente simples definir parmetros para testar e atestar a qualidade de um produ-
to, no desenvolvimento de software atestar a qualidade real de um produto ou servio
no uma tarefa to trivial. Por outro lado, ter qualidade nos produtos e servios de
software primordial para empresas que querem se tornar lucrativas e competitivas,
ou seja, necessrio que as empresas aumentem sua capacidade de produzir mais
rpido e a um custo menor.
Para as empresas de software, alcanar esta competitividade pela qualidade impli-
ca tanto na melhoria da qualidade dos seus produtos e servios correlatos, como na
dos seus processos de produo e distribuio. A qualidade de um produto de softwa-
re est fortemente relacionada com a qualidade do processo de produo seguido por
quem o desenvolve. Quando ainda no se tem um produto, o seu processo de desen-
volvimento dever conferir a capacidade de satisfazer as necessidades do cliente final.
Entendido que a qualidade do software produzido ponto preponderante para a
competitividade das empresas e que para assegurar-se tal qualidade deve-se garantir
a qualidade de seu processo de desenvolvimento, passou-se ento a criar e estabelecer
normas, padres, tcnicas organizacionais e modelos de referncia para implementa-
o de bons processos de desenvolvimento de software. Nesse contexto, as normas
internacionais na rea de engenharia de software indicam as boas prticas, mtodos
reconhecidamente eficazes e processos slidos, testados e confiveis.
Entretanto, essas normas e padres, em sua maioria, so desenvolvidos por e para
grandes empresas, colocando-se, assim, fora do alcance das pequenas organizaes,
que no dispem de meios para estudar e entender o contedo das normas, tam-
pouco de recursos para implement-las. Foi para tratar esse problema que, em 2005,
foi criado o WG24, Working Group nomeado Engenharia de Software Perfis de Ciclo
de Vida para Micro-Organizaes, que tem, entre outros objetivos, o de desenvolver
normas acessveis s VSE (Very Small Entities ou Micro-Organizaes), criando perfis e
provendo orientaes para o atendimento aos requisitos das normas de engenharia
de software da ISO.
GUIA DE IMPLEMENTAO
|
|
PARTE I
17
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

2. VSE (VERY SMALL ENTITIES) E A SRIE ISO/IEC 29110
Uma das caractersticas primordiais das normas e guias que compem a srie ISO/
IEC 29110, desenvolvidas no escopo do WG24, que eles destinam-se e devem ser aces-
sveis s pequenas organizaes que tm em seu processo produtivo atividades relacio-
nadas s reas de Engenharia de Software. Para identifcar essas pequenas organizaes
nesse contexto, criou-se a denominao VSE - very small entity.
2.1 VSE (very small entities)
Uma VSE defnida como uma entidade engajada em atividades de implementao
de software, independentemente da sua atividade-fm ou de sua forma jurdica.
Uma entidade (VSE) pode ser uma organizao (registrada ou no), um grupo, um
departamento ou mesmo um projeto dentro de uma organizao. Uma organizao
pode signifcar uma parceria independente ou organizao vinculada a uma terceira,
tendo at 25 pessoas envolvidas direta (gerentes, desenvolvedores, analistas, testado-
res) ou indiretamente (gestores administrativos, equipe de suporte, equipe comercial
etc.) com um projeto de implementao de software.
2.2 ISO/IEC 29110: Uma srie de normas e guias para pequenas organizaes
A srie ISO/IEC 29110 Engenharia de Software Perfs de Ciclo de Vida para Micro-
-Organizaes tem como pblico-alvo as micro-organizaes e as VSE (very small enti-
ties). Seu propsito maior fazer com que essas organizaes alcancem seus objetivos
de qualidade, sem, necessariamente, ter que demandar projetos de longo prazo e altos
investimentos para adoo das normas relevantes ao seu contexto.
Trata-se de um conjunto de perfs desenvolvidos para atender a uma demanda de
normalizao para o contexto das pequenas organizaes cujas atividades esto relacio-
nadas com a rea de engenharia de software.
Os processos de ciclo de vida descritos na ISO/IEC 29110, entretanto, no tm in-
teno de restringir ou desencorajar seu uso em organizaes maiores. Podem ser usa-
dos pelas VSE tanto ao adquirir e utilizar um sistema de software, quanto ao cri-lo e/
ou fornec-lo para uma terceira parte. Tais processos podem ser aplicados a qualquer
nvel na estrutura de um sistema de software e a qualquer estgio no ciclo de vida, e
no tm inteno de impedir ou desestimular o uso de processos adicionais que as VSE
considerem teis.
A estratgia de desenvolvimento de normas e guias para VSE compondo perfs est
detalhada no Anexo A deste Guia.
GUIA DE IMPLEMENTAO
|
|
PARTE I
18
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

3. GRUPO DE PERFIL GENRICO
Primeiro grupo de perfl defnido, o grupo de perfl genrico tem por objetivo atender
s organizaes desenvolvedoras de software e, conforme demonstra a tabela 1, com-
posto por quatro perfs internacionais normalizados, os perfs VSE: perfl de entrada, perfl
bsico, perfl intermedirio e perfl avanado, onde esto distribudos os elementos que
permeiam o ciclo de vida de desenvolvimento de software.
Tabela 1 - Grupos de perfs e perfs
O grupo de perfl genrico aplicado ao contexto de desenvolvimento de software
no crtico e no integrado a outros sistemas, e foi selecionado como primeiro grupo de
perfl a ser desenvolvido na srie ISO/IEC 29110, visto o reconhecimento de que esse con-
texto abrange a maior parte das VSE desenvolvedoras de software.
A fgura 5 demonstra o relacionamento entre os elementos de um perfl internacional
normalizado, onde podem ser destacados os perfs VSE do grupo de perfl genrico.
Figura 5 - Relacionamento entre os elementos de perfil e os grupos de perfis
GRUPO DE PERFIS PERFIS
Genrico
(desenvolvimento de software)
Entrada
Bsico
Intermedirio
Avanado
ISO 12207
Perfl de entrada Perfl de entrada
Perfl bsico Perfl bsico
Perfl intermedirio Perfl intermedirio
Perfl avanado Perfl avanado
ISO 15289 ISO 15288 ISO 9001
Perfs VSE
Grupo de perfl genrico
(desenvolvimento de
software genrico}
Grupo de perfl SE
(desenvolvimento de software e
sistemas integrado)
Perfs VSE
GUIA DE IMPLEMENTAO
|
|
PARTE I
19
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

A fgura 5 apresenta tambm a estrutura do grupo de perfl SE System Engineering. O
grupo de perfl SE ainda est em desenvolvimento pela ISO (WG24), e o seu propsito aten-
der ao contexto das VSE que desenvolvem software que sero integrados em sistemas outros
ou que tero interfaces com hardware, como o caso dos softwares chamados embarcados.
3.1 Os perfs do grupo de perfl genrico
O grupo de perfl genrico possui quarto perfs: entrada, bsico, intermedirio e avanado.
O desenvolvimento dos perfs de entrada, intermedirio e avanado est em discusso
no foro do JTC1/SC7 da ISO/IEC, por isso estes no sero contemplados neste Guia.
O primeiro perfil internacional normalizado desenvolvido e j publicado (em ingls,
portugus e espanhol), perfil bsico do grupo de perfil genrico, contempla todo ciclo
de vida para o desenvolvimento e manuteno do tipo mais comum de software. Est
definido na parte 4-1 da srie, ABNT NBR ISO/IEC 29110-4-1:2012, e tem na parte 5-1-2,
ABNT ISO/IEC TR 29110 5 1 2:2012 um guia de apoio implantao. Suas principais nor-
mas de base so a ISO/IEC 12207, adotada no Brasil como ABNT NBR ISO/IEC 12207:2009,
Engenharia de sistemas e software Processos de ciclo de vida de software, e a ISO/IEC
15289:2006, Systems and software engineering Content of systems and software life cycle
process information products (Documentation). Alm destas, em alguns pontos, a srie
busca tambm o alinhamento com a ABNT NBR ISO 9001.
A implementao do perfl bsico do grupo de perfl genrico ser tratada na Parte II
deste Guia Implementando o perfl bsico para melhorar o processo de desenvolvimento
de software.
3.2 Estrutura bsica da srie e seus perfs
Alm da viso de organizao por grupos de perfs e perfs, a estrutura da srie ISO/IEC
29110 pode ser observada, ainda, pela composio de seus mltiplos documentos com dife-
rentes fnalidades e pblicos-alvo.
A fgura 6 apresenta a estrutura bsica da srie e indica o perfl bsico (grupo de perfl
genrico) j publicado e a organizao de seus documentos.
Figura 6 - Estrutura da srie ISO/IEC 29110
29110-1 Overview (TR 29110-1)
29110-1 Perfs (Profles)
29110-1 Guias
Frameworks e taxonomia (ISP 29110-2)
Especifcao dos perfs VSE (ISP 29110-4)
BASIC PROFILE
ISP 29110-4-1
Especif. p/ grupo x
Especif. p/ grupo m
Especif. para grupo n
Guia de avaliao (TR 29110-3)
Guia de gesto e engenharia (29110-5)
BASIC PROFILE
ISP 29110-5-1
Especif. p/ grupo x
Especif. p/ grupo m
Guia para grupo n
GUIA DE IMPLEMENTAO
|
|
PARTE I
20
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

3.3 Os documentos da srie
Os documentos que compem a srie ISO/IEC 29110 so agrupados em trs diferentes
categorias: viso geral, perfs e guias.
Os documentos categorizados so tambm organizados por partes.
O documento que apresenta a viso geral a parte 1 da srie, um Relatrio Tcnico (TR
Technical Report) introdutrio para o conjunto dos outros documentos.
Os documentos categorizados como perfs, partes 2 e parte 4 da srie, so perfs interna-
cionais normalizados (ISP Internacional Standardized Profles) e estabelecem as especifca-
es tcnicas necessrias para o agrupamento dos vrios elementos de um perfl.
Os documentos categorizados como perfs so, ainda, agrupados segundo caractersti-
cas especfcas e formam os grupos de perfs (profles group).
Os guias, partes 3 e parte 5 da srie, so tambm Relatrios Tcnicos e neles so estabe-
lecidas diretrizes e orientaes aos seus usurios.
Os documentos categorizados como guias e perfs podem conter subpartes dedicadas a
grupos especfcos de VSE, segundo suas caractersticas.
Os documentos da srie ISO/IEC 29110, considerando sua aplicao, podem ainda ser
divididos em dois grupos:
documentos gerais, aplicveis a todos os grupos de perfs, e
documentos especfcos, aqueles desenvolvidos especifcamente para atender a um
perfl especfco.
Portanto, entre os documentos atualmente publicados, as partes 1, 2 e 3 so aplicveis
a todos os grupos de perfs a serem desenvolvidos, enquanto as partes 4 e 5 so aplicveis
apenas ao Grupo de Perfl Genrico (desenvolvimento de software).
A fgura 7 apresenta a estrutura dos documentos da srie ISO/IEC 29110, segundo sua aplicao.
Figura 7 - Agrupamento dos documentos da srie, por aplicao
TR Technical Report
ISP International Standard Profle
GUIA DE IMPLEMENTAO
|
|
PARTE I
Documentos gerais (aplicveis a todos os
grupos de perfs)
Parte 1 - Resumo
(Technical Report)
Parte 2 - Estrutura
(framework) e
taxonomia de
perfs (Norma)
Parte 3 - Guia
de avaliao
(Technical Report)
Parte 4-1-x
Especifcaes
(Norma)
ISO 29110
Conjunto de documentos
Documentos para o
primeiro grupo de perfil
(especfico para um perfil)
Parte 5-1-x
Guia gerencial
e engenharia
(Technical Report)
21
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Tabela 2 - Documentos normativos
Para melhor entendimento da srie e da aplicao aos documentos
apresentados, a tabela 2 apresenta alguns dos principais conceitos e
defnies relacionados.
CONCEITOS E DEFINIES: DOCUMENTOS NORMATIVOS
NORMA INTERNACIONAL
(IS International Standard)
Documento, estabelecido por consenso e aprovado
por um organismo reconhecido, que fornece, para uso
comum e repetitivo, regras, diretrizes ou caractersticas
para atividades ou seus resultados, visando a obteno
do grau timo de ordem em um dado contexto.
[Diretiva ABNT, Parte 2]
RELATRIO TCNICO
(TR Technical Report)
Documento publicado pela ISO ou IEC contendo dados
coletados de um tipo diferente daquele normalmente
publicado como uma Norma Internacional ou Especifca-
o Tcnica.
[Diretiva ABNT, Parte 2]
NORMA-BASE
(Base Standard)
Norma aprovada ou Recomendao do Setor de Norma-
lizao das Telecomunicaes da Unio Internacional de
Telecomunicaes (ITU-T).
[ISO/IEC TR 10000-1]
PERFIL INTERNACIONAL NORMALIZADO
(ISP International Standard Profle)
Norma harmonizada, internacionalmente acordada, que
descreve um ou mais perfs.
PERFIL
(Profle)
Conjunto de uma ou mais normas-base e/ou perfs e,
quando aplicvel, a identifcao de classes escolhidas,
subconjuntos conformes, opes e parmetros destas
normas-base ou perfs normalizados necessrios para
realizar uma funo particular.
GUIA DE IMPLEMENTAO
|
|
PARTE I
22
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Na tabela 3 consta uma viso consolidada da srie, a partir da classifcao de suas
cinco partes. Cada parte pode ser observada quanto sua categoria, sua forma e pblico
ao qual se destina.
A tabela apresenta, ainda, um breve contexto para o entendimento da aplicao de cada
uma dessas partes.
CATEGORIA FORMA PBLICO-ALVO E RESUMO
Ttulo: 29110-1 - Viso geral
Viso geral Relatrio Tcnico
direcionado tanto ao pblico em geral, interessado nestes do-
cumentos, como mais especifcamente s VSE usurias da srie
apresenta todos os principais conceitos necessrios para
compreender e utilizar a srie ISO/IEC 29110, incluindo as ca-
ractersticas e requisitos de uma VSE; esclarece as razes para
defnio de perfs especfcos, documentos, normas e guias;
traz conceitos de processo, ciclo de vida e normalizao
esta parte ainda no foi publicada em portugus
29110-2 - Estrutura e taxonomia
Perfl
Perfl internacional
normalizado
direcionado aos produtores de normas, ferramentas e meto-
dologias. No se destina s VSE
apresenta os conceitos de perfs normalizados de Engenharia
de Software para micro-organizaes e especifca os termos co-
muns ao conjunto de documentos de perfs para VSE. Tambm
estabelece a lgica que fundamenta a defnio e a aplicao
de perfs de Normas Internacionais e especifca os elementos
comuns a todos os perfs para VSE, bem como a taxonomia dos
perfs da ISO/IEC 29110
por taxonomia entende-se o esquema de classifcao para
referncia no ambgua a perfs ou grupos de perfs
29110-3 Guia de avaliao
Guia Relatrio Tcnico
defne as diretrizes de avaliao de processo e avaliao dos re-
quisitos estabelecidos na parte 4, ABNT NBR ISO/IEC 29110-4-1
A parte 3 dirigida a pessoas com relao direta com processos
de avaliao, como avaliadores e patrocinadores. Pode interes-
sar tambm s VSE que queiram assegurar que foram alcana-
dos os requisitos para realizar uma avaliao
esta parte ainda no foi publicada em portugus
29110-4 - Especifcao de perfs
Perfl
Perfl Internacional
Normalizado
contm um conjunto de subpartes, cada uma delas enfocando
um determinado Grupo de Perfs. Um Grupo de Perfs abrange as
VSE com caractersticas muito semelhantes, e cada perfl dentro do
grupo contempla uma caracterstica especfca
Ttulo: 29110-1 - Viso geral
Guia Relatrio Tcnico
dirigido especifcamente s VSE e tem o objetivo de orientar o
uso da norma e guiar a implementao de cada perfl de cada
Grupo de Perfs. Portanto, conter tantas subpartes quantos
forem os perfs defnidos na parte 4
GUIA DE IMPLEMENTAO
|
|
PARTE I
Tabela 3 - Srie ISO/IEC 29110, suas partes, categorias e pblicos-alvo
23
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

3.3.1. NetCenters e pacotes de implementao (deployment packages - DP)
As anlises dos estudos e pesquisas preliminares realizados pelos pases participan-
tes do grupo de trabalho da ISO apontaram que, para o contexto dos ciclos de vida rela-
cionados engenharia de software, alm do conjunto de normas e guias, so necessrios
outros instrumentos que apoiem a realizao eficiente das atividades dos processos rela-
cionados. Neste sentido, decidiu-se pelo desenvolvimento dos instrumentos necessrios
para facilitar a implementao e execuo dos processos da srie ISO/IEC 29110. Defini-
dos como pacotes de implementao (deployment packages), esses instrumentos so um
importante recurso para beneficiar as VSE na adoo da ABNT NBR ISO/IEC 29110 Ciclo
de vida para micro-organizaes (VSE).
Um DP (deployment packages) , portanto, um conjunto de artefatos ou uma ferra-
menta desenvolvida para facilitar a implementao de um conjunto de prticas, de um
determinado perfil, em uma VSE.
Um DP no um processo, tampouco um requisito normativo. Pode ser caracteriza-
do por uma descrio mais detalhada de atividades, tarefas, papis, produtos, modelos,
checklist ou ferramentas que podem ser usados como elementos de apoio para a execu-
o de um processo aderente srie ISO/IEC 29110. Tais elementos no s facilitaro a
compreenso da norma como podem acelerar a implementao, mediante sua adoo
integral ou adaptada.
Os pacotes de implementao so desenvolvidos e distribudos pelos Network Cen-
ters, que so redes de colaborao criadas pelos pases participantes do desenvolvimen-
to da srie ISO/IEC 29110.
O Anexo B apresenta as informaes detalhadas sobre a criao e os objetivos dos
Network Centers e dos pacotes de implementao j desenvolvidos.
GUIA DE IMPLEMENTAO
|
|
PARTE I
24
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

4. MELHORANDO UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
A adoo das normas e guias do perfl bsico Grupo de perfl genrico da srie
ISO/IEC 29110 deve servir para guiar uma iniciativa de melhoria dos processos de desen-
volvimento de software de uma VSE.
O desenvolvimento de software um servio que engloba as atividades de identifca-
o das necessidades do cliente, o projeto (design) de uma soluo que as atenda, a cons-
truo de um sistema de programas implementando o projeto (design) e sua instalao
para uso do cliente.
PARTE II - IMPLEMENTAO DO PERFIL BSICO PARA MELHORAR O
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Desde que o software, como todo capital, conhecimento incorporado, e como esse
conhecimento est inicialmente disperso, tcito, latente e incompleto na sua totalida-
de, o desenvolvimento de software um processo de aprendizado social. O processo
um dilogo no qual o conhecimento, que deve se transformar em software, reunido
e incorporado ao software. O processo fornece interao entre usurios e projetistas,
entre usurios e ferramentas em desenvolvimento e entre projetistas e ferramentas em
desenvolvimento [tecnologia]. um processo iterativo no qual a prpria ferramenta
serve como meio de comunicao, com cada nova rodada de dilogo, explicitando
mais conhecimento til do pessoal envolvido.
Howard Baetjer Jr. (1998), em PRESSMAN,
Roger S., Engenharia de Software (2010)
Na primeira parte deste Guia foram apresentados alguns aspectos da Indstria de
Software e a insero das pequenas empresas nesse contexto. Foram tambm apresen-
tados os conceitos gerais da srie ISO/IEC 29110, sua estrutura e seus principais docu-
mentos. Essas informaes tiveram um carter introdutrio, visando melhorar o enten-
dimento do campo de aplicao da Norma, seu uso, seus benefcios e relacionamentos
com o processo produtivo das empresas desenvolvedoras de software.
A segunda parte, entretanto, destina-se s discusses relacionadas com a imple-
mentao do perfl bsico da srie e tem como foco a ABNT NBR ISO/IEC 29110-4-1, parte
do grupo de perfl genrico. Nela esto defnidos os processos de gesto de projetos e
implementao de software, que abrangem as principais atividades executadas por uma
empresa durante o ciclo de vida de desenvolvimento de software.
MELHORIA DE PROCESSO
Aes tomadas para mudar os processos de uma organizao, de tal
modo que, mais efetivamente e/ou efcientemente, eles alcancem os
objetivos de negcio da organizao.
[ABNT NBR ISO/IEC 15504-1]
GUIA DE IMPLEMENTAO
|
|
PARTE II
25
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Pode haver casos em que apenas partes do extenso conjunto de atividades sejam realizadas.
Um processo uma organizao lgica de pessoas, materiais, energia, equipamentos,
informaes e procedimentos em atividades de trabalho orientadas a produzir um determi-
nado resultado fnal como, por exemplo, um produto de software.
Considera-se que a sequncia de atividades ou acontecimentos de um processo pode ou
no ser ordenada. Assim, partindo desta premissa, um processo de software um conjunto
de atividades realizadas para atingir o objetivo principal de desenvolver ou manter um sof-
tware, de forma sistematizada ou de forma aleatria.
Um processo de software difere da engenharia de software. Enquanto o processo defne
a abordagem que adotada quando o software elaborado, a engenharia inclui tecnologias
que constituem o processo, como, por exemplo, mtodos, tcnicas e ferramentas.
Alguns autores entendem que a defnio processo de desenvolvimento software aborda
aspectos relacionados s atividades de desenvolvimento propriamente ditas, ou seja, anlise
de requisitos e de sistemas, projeto (design), implementao e testes, e no incorpora as ati-
vidades relacionadas gesto dos projetos de desenvolvimento.
Neste guia, seguindo a viso incorporada da ABNT NBR ISO/IEC 29110-4-1, que defne
os processos de gesto de projetos e implementao de software, seguiremos a defnio de
processos de software entendendo nela todo ciclo de desenvolvimento de software gesto
e implementao.
Os conceitos de processos so importantes para dar base ao ciclo de vida de desenvolvi-
mento de software que ser adotado pela organizao.
PROCESSO
o conjunto de atividades inter-relacionadas ou interativas que
transforma entradas em sadas.
[ABNT NBR ISO 9000]
PROCESSO DE SOFTWARE
um arcabouo para as tarefas que so necessrias para construir
software de alta qualidade.
[Roger Pressman, 2010]
GUIA DE IMPLEMENTAO
|
|
PARTE II
26
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

5. IMPLEMENTANDO O PERFIL BSICO - ABNT NBR ISO/IEC 29110-4-1
O perfl bsico do grupo de perfl genrico tem por objetivo guiar uma VSE desen-
volvedora de software no desenvolvimento e/ou manuteno de seus produtos, bem
como no gerenciamento de seus projetos.
Trata-se de uma Norma Internacional publicada e adotada como Norma Brasilei-
ra, ABNT NBR ISO/IEC 29110-4-1, defnida como um Perfl VSE que, por tratar de ciclo de
vida de software, basicamente dos processos de gesto de projetos e implementao de
software, tem como suas principais normas de base a ISO/IEC 12207, ABNT NBR ISO/IEC
12207:2009, Engenharia de sistemas e software Processos de ciclo de vida de software, e a
ISO/IEC 15289:2006, Systems and software engineering Content of systems and software life
cycle process information products (Documentation). Alm destas, em alguns pontos, a srie
busca tambm conformidade com a ABNT NBR ISO 9001.
O subconjunto de processos e resultados das normas de base que compem o Perfl
Bsico, conforme visto na Parte I deste Guia, adequado quelas VSE descritas atravs de
caractersticas, necessidades e competncias desejveis e que so classifcadas em quatro
categorias: fnanas e recursos; interface com o cliente; processos de negcios internos; e
aprendizado e crescimento.
Alguns aspectos devem ser observados para a implementao adequada do perfl bsico:
Aplicabilidade do perfl bsico: o perfl bsico descreve o desenvolvimento de softwa-
re de uma nica aplicao por uma equipe de projeto nico, sem riscos especiais ou fatores
situacionais.
O objetivo do projeto pode ser cumprir um contrato externo ou interno e, no caso
de projetos internos, no h necessidade desse contrato entre a equipe do projeto e seu
cliente ser explcito.
Entradas para o perfl bsico: a fm de se benefciar do uso do perfl bsico, a VSE deve
atender as seguintes condies de entrada:
ter um contrato para o projeto ou um acordo com a declarao de escopo
ter avaliado a viabilidade do projeto antes do seu incio
possuir recursos humanos designados e treinados
ter designado o gerente de projeto
ter disponveis os recursos materiais, servios e infraestruturas necessrias
GRUPO DE PERFIL GENRICO
O grupo de perfl genrico destinado s empresas que desenvol-
vem software no crticos e que no necessitam de integrao formal
com outros sistemas.
Entende-se aqui como no crticos os softwares cuja falha no possa
causar impactos relacionados segurana ou grandes prejuzos f-
nanceiros, ambientais ou sociais.
(adaptao ISO/IEC 29110, IEEE 610,12)
GUIA DE IMPLEMENTAO
|
|
PARTE II
27
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Alm da ABNT NBR ISO/IEC 29110-4-1, que contm os requisitos para uma implemen-
tao mais efcaz do perfl bsico, importante tomar como base tambm a ABNT NBR ISO/
IEC 29110-5-1 que, apesar de no possuir contedo normativo, traz diretrizes, orientaes e
detalhamentos que visam auxiliar o alcance dos requisitos defnidos na parte 4.
5.1 Os processos do perfl bsico
O perfl bsico defne-se com dois processos: gerncia de projetos (PM Project Manage-
ment) e implementao do software (SI Software Implementation).
No perfl bsico esperado que, para iniciar o ciclo de vida de desenvolvimento de um pro-
jeto de software, a organizao tenha como entrada uma declarao de trabalho defnida. Ao f-
nal do seu ciclo o projeto ter como sada o software confgurado para ser entregue ao cliente.
O diagrama representado na fgura 8 ilustra a interao entre os dois processos descritos na
ABNT NBR ISO/IEC 29110-4-1.
Figura 8 - Interao entre os processos do perfl bsico
A descrio de processos da ABNT NBR ISO/IEC 29110-4-1 obedece seguinte estrutura e
as seguintes notaes so usadas para identifcar os elementos dos processos:
Processo identifcado por seu nome e por uma sigla de duas letras (exemplo: Gerncia
de Projetos, PM);
Objetivo do processo identifcado por uma sigla composta pelas letras de identifcao
do processo, seguida por um ponto, pela letra O e uma numerao sequencial (exemplo:
PM.O1);
Atividade as atividades do processo so identifcadas pela sigla do processo, ponto e
uma numerao sequencial (exemplo: PM.1);
Tarefa as tarefas das atividades so identifcadas pela sigla da atividade qual pertence,
um ponto e uma numerao sequencial (exemplo: PM.1.1);
Entradas das atividades so identifcadas pelo respectivo nome (exemplo: Declarao
de Trabalho);
Sadas das atividades so identifcadas pelo respectivo nome (exemplo: Plano de
Projeto).
A fgura 9 mostra o relacionamento e o fuxo de interao entre os elementos dos processos.
DECLARAO DE
TRABALHO GERNCIA DE
PROJETOS
IMPLEMENTAO
DE SOFTWARE CONFIGURAO DE
SOFTWARE
GUIA DE IMPLEMENTAO
|
|
PARTE II
28
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Figura 9 - Elementos dos processos da ABNT NBR ISO/IEC 29110
Cada processo do perfl bsico Grupo de perfl genrico possui um nico propsito:
a) Gerncia de projetos (PM Project Management), que tem como propsito
estabelecer e manter sistematicamente as tarefas de implementao, visando os
objetivos de qualidade esperada, tempo e custo; e
b) Implementao do software (SI Software Implementation), que tem como
propsito realizar sistematicamente as atividades de anlise, projeto, construo,
integrao e testes, para um novo software ou uma modifcao, de acordo com os
requisitos especifcados.
Como se v na fgura anterior, para cada um desses propsitos estabelecido um conjun-
to de objetivos especfcos. So esses os objetivos do processo.
Para alcanar os objetivos do processo so defnidas atividades obrigatrias, que rece-
bem produtos de entrada e geram produtos de sada.
Os produtos de entrada so gerados por atividades que podem ser intrnsecas ou extrn-
secas ao processo e so, portanto, opcionais.
Os produtos de sada so gerados pelas atividades realizadas ou pelas tarefas detalhadas
de cada uma delas. O perfl bsico defne como obrigatrio um conjunto mnimo de produtos
de sada.
H ainda produtos internos que servem de apoio realizao das atividades e que so,
tambm, opcionais.
As atividades defnidas como obrigatrias para cada processo so descritas no nvel de
macroatividades e devem ser executadas por meio de um conjunto de tarefas mais detalha-
das. Entretanto, as tarefas descritas no perfl bsico so opcionais. Isto signifca dizer que a
VSE deve avaliar a adequao do conjunto de tarefas sugerido, podendo optar por segui-las
em sua totalidade, em parte ou, ainda, decidir por compor um novo conjunto de tarefas que
alcance os resultados esperados pelas atividades obrigatrias.
5.2 Os requisitos da ABNT NBR ISO/IEC 29110
Como j descrito no item anterior, a ABNT NBR ISO/IEC 29110-4-1:2012, parte 4 do perfl
bsico, foi desenvolvida considerando dois tipos de requisitos normativos:
GUIA DE IMPLEMENTAO
|
|
PARTE II
29
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

a) Requisitos mandatrios
Como o prprio nome diz, so elementos obrigatrios e devem, necessariamente, ser
implementados para que se obtenha um completo atendimento norma em questo.
So requisitos mandatrios:
os objetivos dos processos;
as atividades descritas; e
os produtos de sada gerados pela realizao das atividades.
b) Requisitos mandatrios
So representados por um conjunto de elementos por meio dos quais possvel se chegar
aos elementos mandatrios. So requisitos opcionais os produtos de entrada para cada
atividade e as tarefas detalhadas para cada atividade descrita.
As tabelas 4 e 5 demonstram um resumo dos elementos que esto descritos como requi-
sitos mandatrios na ABNT NBR ISO/IEC 29110-4-1.
Os produtos de entrada esto presentes nas tabelas mesmo sendo defnidos anterior-
mente como requisitos opcionais. Isto ocorre para que se tenha viso mais apurada do fuxo
que deve ser percorrido para o alcance dos objetivos dos processos e porque os produtos de
entrada mencionados como opcionais tornam-se obrigatrios como sadas das atividades.
PROJETO
Esforo com datas de incio e fm identifcadas, empreendido para criar
um produto ou servio de acordo com recursos e requisitos especifcados.
[ABNT NBR ISO/IEC 12207:2009]
ATIVIDADE
Conjunto coeso de tarefas de um processo.
TAREFA
Requisito, recomendao ou ao permissvel que visa contribuir
para a consecuo de um ou mais resultados de um processo.
GUIA DE IMPLEMENTAO
|
|
PARTE II
30
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

O PROPSITO DO PROCESSO PM estabelecer e manter sistematicamente as tarefas de imple-
mentao, visando os objetivos de qualidade esperada, tempo e custo
Objetivos do processo
Produtos
de entrada
Atividades
Produtos
de sada
PM.O1 O plano de projeto para a execuo do
projeto desenvolvido de acordo com a declara-
o de trabalho e revisto e aceito pelo cliente. As
tarefas e os recursos necessrios para completar o
trabalho so dimensionados e estimados.
PM.O2 O progresso do projeto monitorado con-
tra o plano de projeto e registrado no registro de
status de progresso. Aes corretivas para corrigir
os problemas e desvios do plano so tomadas
quando as metas do projeto no forem alcana-
das. O encerramento do projeto formalizado
para obter o aceite do cliente, documentado no
registro de aceitao.
PM.O3 As solicitaes de mudana so tratadas
atravs de sua recepo e anlise. Alteraes nos
requisitos de software so avaliadas quanto ao cus-
to, cronograma e impacto tcnico.
PM.O4 So mantidas reunies de reviso com a
equipe de trabalho e os clientes. As decises so
registradas e monitoradas.
PM.O5 Os riscos so identifcados inicialmente e
durante a conduo do projeto.
PM.O6 Uma estratgia de controle de verso do
software desenvolvida. Itens de confgurao
de software so identifcados, defnidos e coloca-
dos em baseline. As modifcaes e liberaes dos
itens so controladas e disponibilizadas ao cliente
e equipe de trabalho. O armazenamento, manu-
seio e entrega dos itens so controlados.
PM.O7 A garantia de qualidade de software rea-
lizada para assegurar que produtos e processos de
trabalho cumprem o plano de projeto e a especif-
cao de requisitos.
Declarao
de trabalho
Confgurao
de software
Solicitaes
de mudana
Planejamento
do projeto
Plano do
projeto
Registro de
aceitao
Repositrio
de projeto
Registro de
reunio
Confgurao
do software
Execuo
do plano de
projeto
Controle e
avaliao do
projeto
Encerramento
do projeto
Tabela 4 - Viso consolidada dos requisitos obrigatrios do perfl bsico Processo PM
GUIA DE IMPLEMENTAO
|
|
PARTE II
31
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Tabela 5 - Viso consolidada dos requisitos obrigatrios do perfl bsico Processo SI
PROPSITO DO PROCESSO SI
Realizar sistematicamente as atividades de anlise, projeto, construo, integrao e testes,
para um novo software ou uma modifcao, de acordo com os requisitos especifcados
Objetivos do processo
Produtos
de entrada
Atividades
Produtos
de sada
SI.O1. Tarefas das atividades so realizadas em
cumprimento do plano de projeto.
SI.O2. Requisitos de software so defnidos, anali-
sados quanto correo e testabilidade, aprova-
dos pelo cliente, colocados em baseline e comu-
nicados.
SI.O3. Um projeto de arquitetura e detalha-mento
desenvolvido e colocado em baseline. Ele descre-
ve os itens de software e suas interfaces internas e
externas. So estabelecidas consistncia e rastrea-
bilidade aos requisitos de software.
SI.O4. Os componentes de software defnidos pelo
projeto so produzidos. Testes unitrios so de-
fnidos e realizados para verifcar a consistncia
com os requisitos e com o projeto. estabelecida
rastreabilidade para os requisitos e para o projeto.
SI.O5. Software produzido fazendo a integrao
dos componentes de software e verifcado usan-
do casos de teste e procedimentos de teste. Os
resultados so registrados no relatrio de teste. Os
defeitos so corrigidos e so estabelecidas consis-
tncia e rastreabilidade ao projeto do software.
SI.O6. Uma confgurao de software que atende
especifcao de requisitos conforme acordado
com o cliente, a qual inclui documentaes do
usurio, de operao e de manuteno, integra-
da, colocada em baseline e armazenada no repo-
sitrio do projeto. Necessidades de alteraes na
confgurao do software so detectadas e as de-
vidas Solicitaes de mudana so iniciadas.
SI.O7. Tarefas de verifcao e validao de todos
os produtos de trabalho necessrios so realizadas
usando critrios defnidos para assegurar a consis-
tncia entre produtos de sada e entrada em cada
atividade. Defeitos so identifcados e corrigidos.
Registros so armazena-dos em resultados de ve-
rifcao/validao.
Plano de
projeto
Especifcao
de requisitos
Projeto do
software
Registro de
rastreabilidade
Componentes
do software
Documenta-
o do usurio
do software
Casos de teste
e procedimen-
tos de teste
Confgurao
do software
Iniciao
da imple-
metao do
software
Solicitao de
mudana
Especifcao
de requisitos
Documenta-
o do usurio
do software
Resultados de
validao
Resultados de
verifcao
Projeto do
software
Casos de teste
e procedimen-
tos de teste
Registro de
rastreabilidade
Confgurao
do software
Componentes
do software
Guia de opera-
o do produto
Software
Casos de teste
e procedimen-
tos de teste
Relatrio de
teste
Documenta-
o de manu-
teno
Anlise dos
requisitos do
software
Projeto de
arquitetura
e detalha-
mento do
software
Construo
do software
Integrao
e testes do
software
GUIA DE IMPLEMENTAO
|
|
PARTE II
32
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

A fgura 10 representa a lgica de implementao do perfl bsico e apresenta a relao
entre o desenvolvimento de software e a ABNT NBR ISO/IEC 29110-4-1.
Figura 10 - Lgica de implementao do perfl bsico da srie ISO/IEC 29110
Na implementao do perfl bsico, as seguintes consideraes so essenciais:
a) alcanar os objetivos dos processos;
b) gerar os documentos obrigatrios;
c) executar todas as atividades dos processos, tambm obrigatrias.
O QUE IMPORTANTE? CONSIDERE!
A base para um bom processo
de desenvolvimento de software
deve observar o que j realiza-
do na organizao
Na implementao do perfil bsico, assim como de qual-
quer modelo de processos, deve-se partir do processo em
uso na organizao e incluir nele os elementos necess-
rios para que se alcance a aderncia ao que preconiza-
do na norma. Mesmo no tendo um processo documen-
tado, a organizao seguramente possui algum, por mais
informal que seja. importante respeitar esse processo,
pois nele que esto inseridos o conhecimento e as boas
prticas seguidas pelas pessoas da equipe. Quando em
uma tentativa de implementar um processo ideal e com-
pletamente novo, desconsidera-se a forma de fazer da
organizao, h o risco de maior resistncia s mudanas
e menor colaborao com o que h de ser feito.
Desconsiderar o contexto de trabalho da organizao um
dos fatores que pode levar ao insucesso da real instituciona-
lizao de um processo, por melhor que ele seja.
Uma boa implementao do Perfil Bsico ser aquela
compreendida por todos os envolvidos como a represen-
tao do conjunto de atividades que, de fato, realiza-
da pela organizao para a produo ou manuteno de
um produto de software. tambm aquela onde, neste
conjunto de atividades, encontram se pontos de controle
para tornar o processo produtivo cada vez melhor.
GUIA DE IMPLEMENTAO
|
|
PARTE II
33
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Em uma viso simplifcada, pode-se dizer que no desenvolvimento de software h duas
classes principais de processos: (i) gerenciais ou organizacionais e (ii) tcnicos, diretamente
empenhados no desenvolvimento.
importante destacar que quanto mais ajustada for a integrao entre eles, maior ser
a efcincia do desenvolvimento de software. Frequentemente esta integrao relegada na
defnio dos processos da organizao, sendo tratadas separadamente as duas classes, in-
clusive porque elas dizem respeito a grupos de interesses separados e s vezes isolados.
O mtodo mais difundido para realizar projetos de melhoria de processos o PDCA
Plan, Do, Check, Act, proposto por E. Deming. O PDCA consiste na realizao de ciclos nos

Figura 11 - Aplicao do ciclo PDCA na implementao de melhoria de processos
5.3 Os cuidados na hora de decidir melhorar os processos
Uma estratgia organizacional bem defnida e consistente deve considerar que os pro-
cessos produtivos da organizao devem estar sujeitos a um ciclo de melhoria contnua.
No poderia ser diferente, pois os processos, assim como as organizaes, so vivos e esto
constantemente em mutao. Estruturas organizacionais mudam, condies ambientais e
demandas mudam, e essas mudanas podem impor adequao e ajuste dos processos s no-
vas situaes. A infuncia de fatores internos ou externos, positivos ou negativos, tambm
atua sobre os processos da organizao e pode, adicionalmente, provocar mudanas rele-
vantes execuo de um processo produtivo, no caso de desenvolvimento de software. Nas
organizaes que no promovem a evoluo do seu processo, por mais bem-sucedida que
tenha sido a sua implementao original, provvel que ocorra, com o tempo, uma degrada-
o at o ponto de sua inadequao, quando a tendncia de que aquilo que fora prescrito
j no seja mais o que est sendo executado.
Implemente as melhorias no proces-
so (considerando os requisitos estabe-
lecidos)
Acompanhe o uso dos proces-
sos nos projetos
Realize auditorias internas
e externas
Identifque no conformidades e
oportunidades de melhorias
Defna objetivos
Identifque caractersticas, riscos e
recursos para o projeto de im-
plementao de melhorias
Corrija as no
conformidades
Aplique as melhorias identifcadas
Plan
Act
Do
Check
GUIA DE IMPLEMENTAO
|
|
PARTE II
34
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Outro motivo para equvocos na hora de melhorar processos quanto defnio dos
objetivos e metas dos projetos de melhoria. Especialmente nos projetos de melhoria de pro-
cesso baseados em normas certifcveis, como o caso da ISO/IEC 29110, onde um dos resul-
tados esperados a obteno de uma certifcao reconhecida pelo mercado. Deve-se tomar
o cuidado de conduzir o projeto de melhoria pautado em objetivos que representem, de fato,
as necessidades de negcio da organizao. A implementao dos requisitos preconizados
na norma, buscando alcanar metas reais de melhoria, atrelada adoo das boas prticas
difundidas na organizao, certamente, levar a um melhor desempenho do processo. Um
processo produtivo de ciclo de vida de desenvolvimento de software implementado e insti-
tucionalizado desta forma ter como natural a obteno de suas credenciais de certifcao.
Nunca demais destacar que os processos implementados e institucionalizados em uma
organizao devem representar a essncia da forma como ela trabalha.
As iniciativas de implementao de melhoria de processos devem ser conduzidas como
um projeto formal dentro da organizao, seguindo os conceitos de gesto de projetos, agre-
gando agilidade e facilidade na organizao e controle deles. Isto signifca dizer que estas
iniciativas devem ser devidamente planejadas e monitoradas at a sua concluso de suas
aes, observando-se variantes como aos recursos, riscos, comprometimento e estratgias.
Estabelecer objetivos
claros e diretos
Para melhorar um processo necessrio estabelecer um
objetivo a ser alcanado e alterar um ou mais componen-
tes do processo-alvo, ou a forma como eles interagem, e
avaliar o desempenho resultante, tendo em vista aquele
objetivo.
Divulgar a todos os benefcios e
vantagens da implementao de
melhorias
Apresentar os benefcios e as vantagens reais da imple-
mentao de melhoria de processos pode ajudar a des-
pertar o interesse dos envolvidos.
O esforo de conscientizar a alta gerncia dos reais bene-
fcios e vantagens que podem ser obtidos pela melhoria
dos processos pode ajudar no direcionamento da imple-
mentao para a busca real de melhoria contnua.
Documentao: a primeira reco-
mendao para uma boa iniciati-
va de melhoria de processos
Todas as organizaes que desenvolvem um produto ou
servio tm processos, ou ento no produziriam resul-
tados. Nas pequenas organizaes, geralmente, os pro-
cessos no esto documentados nem formalizados, ou
esto de forma muito superficial e sem rigor. comum,
por exemplo, que os profissionais sigam seus processos
pessoais fazendo com que diferentes projetos cumpram
diferentes processos. Tal ambiente dificulta a implemen-
tao de melhorias.
GUIA DE IMPLEMENTAO
|
|
PARTE II
35
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Avalie
Para uma avaliao objetiva preciso ter medidas de de-
sempenho antes e depois da alterao. Na prtica, entre-
tanto, diante da falta de medidas, a avaliao acaba sen-
do subjetiva em muitos casos. Pequenas organizaes
tm dificuldade para definir medidas adequadas e no
dispem de tempo para coletar amostras representativas.
Um dos aspectos que deve ser considerado ao se avaliar
uma melhoria de processo que logo aps uma alterao
geralmente ocorre uma resposta positiva, a qual, porm,
pode no se sustentar ao longo do tempo.
Busque o ponto de equilbrio
entre a formalizao e a prati-
cidade
Processos, diretrizes, atividades, tarefas, produtos de
trabalho so alguns dos elementos que devem ser for-
malizados dentro da organizao. Isto significa dizer que
todos devem ter o conhecimento necessrio para us-los
quando necessrio.
No necessrio, entretanto, e em uma VSE, por suas ca-
ractersticas de flexibilidade, torna-se quase proibitivo,
que todas as formalizaes sejam obrigatrias.
Diretrizes, por exemplo, podem servir como orientaes
para aplicao dos processos ou como detalhamento de
determinadas atividades.
Quanto mais formalizada for a base de conhecimento
de apoio execuo do processo produtivo, maiores as
chances desse conhecimento institucionalizar-se como
um ativo da organizao, entretanto deve-se atentar para
a consistncia das informaes e, mais ainda, para no
permitir que a formalizao se transforme em um ato bu-
rocrtico, vazio e sem propsito.
GUIA DE IMPLEMENTAO
|
|
PARTE II
36
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

6. METODOLOGIA PARA IMPLEMENTAO DO PERFIL BSICO
Como j visto, uma das formas indicadas para se defnir um processo de desenvol-
vimento de software aderente ISO/IEC 29110, ou para se adequar um processo j def-
nido norma, por meio da conduo de um projeto de implementao de melhorias.
Adicionalmente, um projeto desse tipo, assim como qualquer outro, deve ser conduzido
observando-se as boas prticas da gesto de projetos e o seguimento de uma metodo-
logia de gesto.
Quando o projeto de melhoria conduzido seguindo metodologias de gesto, au-
mentam as chances de sua evoluo ser acompanhada de forma mais precisa e de seus
marcos e metas serem alcanados conforme esperado.
A conduo dos projetos de implementao de melhorias deve estar orientada por
estratgias organizacionais defnidas. Portanto, no basta apenas o planejamento das
aes, importante, ainda, que a deciso de melhorar os processos e as aes a serem
tomadas durante o projeto de implementao estejam alinhadas com as estratgias e os
objetivos de negcio do contexto que se pretende melhorar.
A fgura 12 apresenta uma metodologia para conduzir um projeto de implementa-
o de melhoria de processos de software e tem por objetivo organizar de uma forma
lgica as etapas que devem ser cumpridas.
Figura 12 - Modelo para implementao de melhoria de processos
A metodologia est apresentada em quatro fases distintas: diagnstico, preparao,
execuo e melhoria.
GUIA DE IMPLEMENTAO
|
|
PARTE II
37
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Propositadamente, no fuxo apresentado no h uma indicao de fm do processo. Isto
acontece porque a melhoria de processos de uma organizao deve ser observada como
um ato contnuo, onde a cada ciclo busca-se identifcar os pontos negativos que devem ser
eliminados, aqueles que devem ser melhorados e outros que devem ser reforados como
pontos fortes.
Nos itens a seguir apresentado um conjunto de tabelas onde, para cada fase da me-
todologia descrita, so discutidos alguns aspectos relevantes que devem ser observados
durante a conduo de um projeto de implementao de melhoria de processos.
Vale destacar que os aspectos apresentados consideram a conformidade com a ABNT
NBR ISO/IEC 29110-4-1 e com a aplicao da metodologia de implementao sugerida na
fgura 12.
As tabelas esto distribudas por fase de execuo. Cada fase est estruturada com base
nas macroatividades da metodologia apresentada, onde, para cada uma delas, so sugeri-
dos aes e pontos importantes que devem ser observados, quando for o caso.
6.1 FASE 1 Diagnstico
6.1.1 Identifcao das caractersticas iniciais
A identifcao das caractersticas iniciais deve preocupar-se com quem vai defnir, o
que ser feito e onde ser feito. Nesta etapa o envolvimento de algum da alta gerncia
fundamental. Um projeto de melhoria de processos tende a alterar de alguma forma o modo
como as pessoas trabalham, sendo de suma importncia que fque claro que a sua execuo
uma deciso organizacional e tem o apoio e a vontade da alta direo.
Deve-se, tambm, envolver quem ir assumir o papel de gestor do projeto. No obri-
gatrio que o gestor tenha conhecimento de todas as reas que sero discutidas, entretanto
AO OBSERVE
Identifcar os envolvidos preliminares
Nesta etapa necessrio garantir o envolvimento
de pessoas com autonomia para tomar deciso e
com credibilidade perante a equipe.
O processo tende a assumir a autonomia e a cre-
dibilidade daqueles que o defnem, portanto um
processo que tenha sido defnido por algum com
baixa autonomia e/ou baixa credibilidade sofrer
maior resistncia para sua adoo.
Identifcar as caractersticas
organizacionais
Identifque os aspectos relacionados ao tamanho
da entidade, criticidade dos projetos, peculiarida-
des de clientes etc.
Identifcar o escopo inicial
Defna o escopo desejado onde sero implemen-
tadas as melhorias de processos. Salvo situaes
especiais, no recomendado iniciar projetos de
melhoria em um escopo muito grande ou muito
complexo.
GUIA DE IMPLEMENTAO
|
|
PARTE II
38
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

fundamental que ele saiba identifcar as pessoas relevantes ao longo do projeto de imple-
mentao de melhorias e que tenha autonomia para envolv-las nos momentos necessrios.
Identifcados os envolvidos iniciais do projeto, deve-se defnir o escopo que as melhorias
iro alcanar. Por tratar-se de uma norma voltada para o contexto especfco de pequenas
organizaes (as VSE very small entities), o escopo de trabalho, na maioria das vezes, ser o
da organizao desenvolvedora de software como um todo. Entretanto, pode haver o caso
de, em uma organizao de maior porte, ter-se contextos variveis como, por exemplo, pro-
jetos de diferentes complexidades, equipes com grandes variaes de capacitao, clientes
com criticidades mais elevadas etc. Nestes casos, recomendvel que as melhorias sejam im-
plementadas em ciclos, defnindo-se como escopo inicial o de menor complexidade, menor
criticidade e maior nvel de capacitao.
Deve-se atentar, contudo, para que o escopo defnido tenha relevncia para a organiza-
o; caso contrrio, pode no ser dada a devida importncia para as aes de melhoria.
6.1.2 Realizao do diagnstico inicial
Ter o compromisso da
alta gerncia
Quando a alta gerncia est comprometida com o proje-
to de implementao, o envolvimento das outras partes
interessadas mais eficaz.
Os gestores do projeto de imple-
mentao devem ter poder real
de deciso
Quando os gestores dos projetos de implementao tm
poder real de deciso, ou seja, pertencem alta gerncia
ou tm a autoridade designada por esta, h mais chances
de que sejam tomadas decises efetivas, de modo que os
problemas ou desvios que possam ocorrer venham a ser
solucionados.
AO OBSERVE
Analisar as descries de processos da or-
ganizao, se houver
Nem sempre os processos esto descritos de uma
forma convencional, portanto, necessrio identi-
fcar padres isolados ou processos informais que
estejam sendo seguidos.
recomendado que se observe in loco como as
pessoas de fato realizam suas atividades.
Analisar modelos de documentos e ferra-
mentas usados para apoiar as atividades da
organizao
Identifcar os modelos de documentos usados pelas
equipes ou mesmo pelas pessoas individualmente.
Deve-se observar a operao e as sadas das ferra-
mentas de apoio.
Realizar entrevistas com alta gerncia, ges-
tores e profssionais indicados
As entrevistas com os envolvidos devem ser rea-
lizadas durante ou aps as anlises dos processos,
modelos e ferramentas.
GUIA DE IMPLEMENTAO
|
|
PARTE II
39
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

AO OBSERVE
Registrar os dados coletados
As observaes devem ser registradas de modo a
facilitar a identifcao das lacunas para a adern-
cia norma.
Analisar as lacunas existentes entre
a execuo das atividades do ciclo de
vida de desenvolvimento de software
em relao aos requisitos estabelecidos na
ISO/IEC 29110-4-1
Checklists de orientao podem facilitar a anlise
das lacunas existentes na execuo das atividades
do ciclo de vida de desenvolvimento de software
em relao aos requisitos estabelecidos na ISO/
IEC 29110-4-1.
recomendado que se defnam nveis de critici-
dade e precedncia das lacunas identifcadas, a fm
de facilitar a priorizao das aes seguintes.
Apresentao para entendimento geral das
lacunas observadas
A apresentao dos resultados deve deixar claro o
trabalho que deve ser realizado, para que se alcan-
ce aderncia norma.
6.2 FASE 2 Preparao
6.2.1 Planejamento do projeto de implementao
AO OBSERVE
Elaborar o plano de implementao com
base nas informaes obtidas na fase de
diagnstico
Quando h o apoio de uma consultoria externa
experiente no planejamento do projeto de melho-
ria, provvel ter um plano mais efcaz.
Identifcar os recursos humanos que
sero envolvidos ao longo do projeto
A defnio clara dos papis e das responsabi-
lidades de cada um dos envolvidos permite que
possveis confitos ao longo do projeto possam ser
minimizados ou evitados.
O uso de uma equipe de consultoria externa
formada por pessoas com conhecimento terico e
experincia de mercado pode trazer novos pontos
de vista e maturidade ao projeto, bem como maior
agilidade no alcance das metas defnidas.
Identifcar recursos materiais
necessrios ao projeto
A adoo de ferramentas pode ser indutora de
acelerao na implementao do processo
A integrao das ferramentas de apoio execu-
o dos processos pode reduzir a quantidade de
erros introduzidos por falha humana.
Elaborar um cronograma macro, identif-
cando os principais pontos de controle
O estabelecimento detalhado das atividades que
sero realizadas, com seus respectivos prazos, e
das responsabilidades de cada uma das partes
um indcio de que o projeto alcanar as metas
estabelecidas.
Estimar esforo e prazo para realizar
as atividades do projeto
Estabelecer estimativas realistas de esforo e
prazo para realizar as atividades do projeto ajuda
a manter as expectativas quanto aos resultados
esperados.
As estimativas devem considerar o conhecimento
e a capacidade de dedicao dos envolvidos.
GUIA DE IMPLEMENTAO
|
|
PARTE II
40
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

PAPIS RELEVANTES EM UM PROJETO DE IMPLEMENTAO
ADERENTE ISO/IEC 29110
COORDENADOR DO PROJETO
Aquele que ser responsvel por explorar a possibilidade de conduzir o
projeto de implementao junto gerncia da VSE.
Deve ser o responsvel tambm por planejar e conduzir projetos-piloto,
se for o caso, para a validao da implementao.
Este papel pode ser exercido por pessoa externa organizao.
GERNCIA DA VSE
Uma pessoa, dentro da VSE, com autoridade para aprovar e alocar
os recursos internos necessrios para a conduo do projeto.
Deve ter total conhecimento dos benefcios que a adoo da nor-
ma pode proporcionar e estar comprometido com o alcance das
metas esperadas.
EQUIPE DE ENVOLVIDOS
Envolvidos sob a autoridade da gerncia da VSE, que devero ser trei-
nados para participar do projeto.
6.2.2 Identifcao e anlise de riscos
AO OBSERVE
Identifcar os riscos inerentes ao contexto
da organizao
Subestimar os riscos pode diminuir os benefcios
que podem ser alcanados em um projeto de im-
plementao de melhoria de processos.
A observao de aspectos relacionados capa-
citao dos envolvidos, autonomia dos gestores
do projeto e imposio do ritmo de introduo
das mudanas pode auxiliar na identifcao de
possveis riscos.
Analisar os riscos considerando a aplicao
de planos de contingncia e mitigao
Defnir um plano de mitigao e contingncia
para os riscos identifcados maximiza as chances
de sucesso do projeto.
GUIA DE IMPLEMENTAO
|
|
PARTE II
41
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

6.2.3 Comprometimento e comunicao
6.2.4 Capacitao da equipe
AO OBSERVE
Formalizar o comprometimento das partes
interessadas, em especial da alta gerncia
A presena, a visibilidade e a demonstrao de
apoio do patrocinador so um indcio de que o
projeto de melhoria alcanar as metas estabe-
lecidas.
Garantir a boa comunicao, estabelecendo
meios de comunicao viveis e disponveis
para todos os envolvidos
A criao de mecanismos que facilitem a publica-
o e a troca de informaes e experincias livre-
mente, como, por exemplo, wiki ou intranet, pode
incentivar a comunicao.
Quando h na organizao uma boa comunica-
o entre a alta gerncia e os colaboradores, pode
haver aumento do envolvimento e da motivao
da equipe.
Estimular todos os envolvidos a participar da
construo e da melhoria dos processos da orga-
nizao aumenta o comprometimento para que o
processo retrate o dia a dia real da organizao.
Apresentar os benefcios reais que podem
ser esperados como resultado do projeto
de implementao
Quando os membros da organizao esto
conscientes quanto aos benefcios obtidos com a
implantao dos processos, h maior facilidade na
gerncia do programa de melhoria.
AO OBSERVE
Capacitar os envolvidos na ABNT NBR ISO/
IEC 29110-4-1 e nos outros documentos da
srie ISO/IEC 29110 relacionados ao perfl
bsico
Capacitar os envolvidos, quando necess-
rio, nos conceitos relacionados ao contexto
de implementao
Capacitar os envolvidos, quando necess-
rio, nas boas prticas de gesto e engenha-
ria de software
Quanto maior a capacitao profssional dos
membros da organizao, menor a resistncia
s mudanas decorrentes da implementao e da
melhoria dos processos.
GUIA DE IMPLEMENTAO
|
|
PARTE II
42
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

PAPEL X COMPETNCIAS MNIMAS ESPERADAS
ANALISTA
Conhecimento e experincia em levantamento, especifcao e anlise
de requisitos.
Conhecimento em projeto de interfaces de usurio.
Conhecimento de tcnicas de reviso.
Experincia em desenvolvimento e manuteno de software.
PROJETISTA/ARQUITETO
Conhecimento e experincia em projeto de arquitetura de com-
ponentes de software.
Conhecimento e experincia em planejamento e execuo de
testes de integrao.
PROGRAMADOR/DESENVOLVEDOR
Conhecimento e/ou experincia em programao, teste unitrio e
integrao.
EQUIPE DE TRABALHO
Conhecimento e experincia de acordo com suas funes no proje-
to (lder tcnico, analista, projetista/arquiteto, programador/desen-
volvedor).
Conhecimento das normas utilizadas pelo cliente e/ou pela VSE.
GUIA DE IMPLEMENTAO
|
|
PARTE II
43
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

6.3 FASE 3 Execuo
6.3.1 Implementao de melhoria de processos
Como j dito, a implementao de melhoria nos processos de desenvolvimento de uma
organizao deve ser realizada o mais prximo possvel da realidade das atividades executa-
das por ela. Haver, assim, uma reduo no impacto da mudana cultural para os envolvidos.
O processo de uma organizao direciona a equipe de desenvolvimento por um conjun-
to de macroatividades que so organizadas em um fuxo de processo ciclo de vida que
pode ser linear, incremental ou evolutivo.
Os ciclos de vida em geral so baseados em modelos prescritivos de processo que for-
necem efetivamente um roteiro reconhecidamente til para o trabalho de engenharia de
software. Entretanto, importante ter em mente que modelos de processos no so perfeitos
e que devem ser adaptados para acomodar a natureza especfca de cada projeto e as carac-
tersticas da equipe de desenvolvimento e do ambiente onde sero desenvolvidos.
AO OBSERVE
Identifcar o processo atual da organizao
Descrever, mesmo que em alto nvel, o processo
atual da organizao auxilia o estabelecimento das
aes de melhoria que devem ser realizadas. Auxi-
lia tambm a alinhar os vrios processos paralelos
que podem existir na organizao.
Ajustar o processo de acordo com as neces-
sidades identifcadas na fase de diagnsti-
co e com os requisitos da ABNT NBR ISO/IEC
29110-4-1
As aes que devem ser tomadas para tornar o
processo da organizao aderente norma devem
ser priorizadas de acordo com os critrios defnidos
e a ordem de precedncia indicados na fase de
diagnstico.
Se necessrio, considere realizar as melhorias em
ciclos, avaliando e coletando as lies aprendidas
ao fnal de cada um desses ciclos.
Capacitar a equipe no uso do
processo ajustado
Garantir que a equipe est capacitada para reali-
zar as atividades defnidas no processo aumenta a
efccia dos resultados.
Ferramentas de apoio ao processo devem tam-
bm ser objeto de capacitao.
A falta de capacitao para o uso de ferramentas
pode diminuir drasticamente a efcincia ou, ainda,
levar a erros na execuo do processo.
CICLO DE VIDA
Evoluo de um sistema, produto, servio, projeto ou outra entidade, feita
por mos humanas, desde a concepo at o descarte.
GUIA DE IMPLEMENTAO
|
|
PARTE II
44
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Vrios modelos de processos foram escritos no intuito de ordenar as atividades do desen-
volvimento de software, porm, independentemente do modelo de processo selecionado, a
engenharia de software tem tomado por base o modelo genrico que considera bsicas as
atividades de comunicao, planejamento, modelagem, construo e implantao. Entretan-
to, em cada modelo a nfase dada a essas atividades difere e o fuxo de trabalho proposto
para cada atividade tambm abordado de forma diferente.
A seguir, esto destacados os principais ciclos de vida ou modelos prescritivos usados
pela engenharia de software.
Modelo cascata No modelo cascata, tambm conhecido como ciclo de vida clssi-
co, as atividades so executadas sistemtica e sequencialmente, havendo a possibilidade de
ajustes naquelas que estariam completas em caso de necessidade por alterao de requisitos,
questes tcnicas, concretizao de riscos etc.
A fgura 13 apresenta a sequncia das macroatividades do modelo cascata.
Figura 13 - Modelo cascata
No modelo cascata o desenvolvimento se inicia com a especifcao dos requisitos pelo
cliente e progride ao longo do planejamento, modelagem, construo e implantao, quan-
do, por fm, chega manuteno progressiva do software acabado.
MODELOS PRESCRITIVOS DE PROCESSO DE SOFTWARE
Modelos prescritivos de processos defnem um conjunto distinto de ativi-
dades, aes, tarefas, marcos e produtos de trabalho que so necessrios
para fazer engenharia de software com alta qualidade.
[PRESSMAN, Roger S. Sexta Edio, 2010]
GUIA DE IMPLEMENTAO
|
|
PARTE II
45
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Modelo evolutivo ou evolucionrio apresenta modelos iterativos, que foram pro-
postos para acompanhar situaes onde os requisitos do negcio e do produto mudam com
frequncia, medida que o desenvolvimento acontece e difculta o caminho sequencial e
direto para que se chegue ao produto fnal. Neste caso, o desenvolvimento acontece por
sucessivos refnamentos, cada um deles produzindo uma verso melhor devido ao feedback
da anterior. A partir de uma especifcao inicial, que contm partes incertas, produz-se uma
verso com o que estiver melhor defnido e em seguida refna-se e completa-se, produzindo
novas verses sempre aperfeioadas, at que o sistema esteja concludo. Poderamos ver isto
como uma evoluo de prottipos.
Uma das formas de aplicao de modelos evolutivos a prototipagem. O desenvolvi-
mento de prottipos funciona como um mecanismo para auxiliar a identifcao dos requisi-
tos do software. A fgura 14 apresenta um modelo baseado em prototipagem.
Figura 14 - Modelo de prototipagem (adaptado de Pressman, 2010)
O modelo cascata o mais
antigo modelo de ciclo de vida
da engenharia de software.
No entanto, a sua eficcia vem
sendo questionada nas ltimas
duas dcadas em alguns pontos.
Projetos reais raramente seguem o fluxo sequencial pro-
posto pelo modelo.
A exigncia de que sejam explicitamente definidos to-
dos os requisitos no incio do projeto nem sempre sim-
ples de ser atendida.
A verso executvel do software pretendido s estar
disponvel ao final. Erros no percebidos facilmente tor-
nam-se desastrosos.
GUIA DE IMPLEMENTAO
|
|
PARTE II
46
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Modelo incremental ou iterativo apresenta modelos que propem o desenvolvi-
mento de um software de certo porte em iteraes, sendo cada uma dessas iteraes algo
como uma minicascata, contendo atividades sequenciais de anlise, projeto, construo e
implementao, de modo a produzir uma parte operacional do sistema. O conhecimento
adquirido em cada iterao minimiza os possveis erros nas iteraes futuras e faz com que o
desenvolvimento se acelere constantemente. Mas, frequentemente, torna-se necessrio vol-
tar atrs e realizar ajustes no que j foi concludo.
A figura 15 apresenta um exemplo de fluxo baseado no modelo incremental de
desenvolvimento.
Figura 15 - Modelo incremental (adaptado de Pressman, 2010)
Processo unifcado ou UP (unifed process) modelo que, em sua concepo, teve a
expectativa de basear-se nas melhores caractersticas dos modelos de processo de software
convencionais. Tem tambm caractersticas que visam a implementao dos melhores princ-
pios de desenvolvimento gil.
O UP sugere um fuxo de processo iterativo incremental, de modo que se busque a sensa-
o evolucionria, defendida como essencial nas correntes que discutem o desenvolvimento
moderno de software.
A proposta do UP decompor o total do trabalho em iteraes incrementais, de tal forma
a possibilitar a concluso de partes que demonstrem concretamente a evoluo do desenvol-
vimento e a superposio das partes para acelerar o processo. Enquanto uma iterao ainda
est em andamento, a seguinte pode comear. Geralmente, dentro de cada iterao, o desen-
volvimento se d em cascata. Este modelo tem quatro fases de desenvolvimento:
P Concepo: estudar a viabilidade do projeto, propor a arquitetura, estimar recursos,
custos, prazos e elaborar um plano preliminar;
P Elaborao: analisar riscos, detalhar requisitos, detalhar a arquitetura e refnar o
planejamento;
GUIA DE IMPLEMENTAO
|
|
PARTE II
47
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

P Construo: desenvolver o sistema at ter uma verso operacional;
P Transio: resolver pendncias, corrigir defeitos e ter o sistema pronto para uso.
A fgura 16 mostra as fases de desenvolvimento do processo unifcado e a relao dessas
com as macroatividades genricas dos fuxos de processo.
Figura 16 - Processo unifcado (adaptado de Pressman, 2010)
Mtodos geis No se trata exatamente de um modelo de processo, mas sim de um
grupo de propostas que nasceu a partir do Manifesto gil, um elenco de princpios que visa
dar foco na ateno s necessidades do cliente, construo rpida e eliminao de ativida-
des perifricas que no agreguem diretamente valor ao produto em si.
Atualmente, o SCRUM o mtodo mais disseminado, embora a maioria das organizaes
que dizem adot-lo faam vrias adaptaes. A fgura 17 apresenta o ciclo proposto pelo
mtodo SCRUM (SCRUM um processo de desenvolvimento iterativo e incremental para ge-
renciamento de projetos e desenvolvimento gil de software).
Figura 17 - Ciclo de processo baseado no mtodo SCRUM
GUIA DE IMPLEMENTAO
|
|
PARTE II
48
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Outro modelo representativo dos mtodos geis o XP Extreme Programming, que se pro-
pe a alcanar qualidade com rapidez e fexibilidade no desenvolvimento, reduzindo os custos.
O XP usa uma abordagem orientada a objetos como seu paradigma de desenvolvimen-
to. A fgura 18 ilustra o processo XP e mostra algumas das ideias principais e tarefas que so
associadas a cada atividade de arcabouo. O XP sugere um nmero de tcnicas inovadoras
e potentes que permitem que equipes geis criem frequentemente verses de software que
possuem caractersticas e funcionalidades descritas e priorizadas pelo cliente.
Figura 18 Processo Extreme Programming (Adaptado de Pressman, 2010)
Adaptar o ciclo de vida reali-
dade da organizao, conside-
rando suas caractersticas e as
caractersticas dos seus projetos
O processo produtivo de uma VSE que produza software no
crtico baseado no perfil bsico da srie ISO/IEC 29110
pode ser orientado por quaisquer ciclos de vida de de-
senvolvimento de software, portanto a ordem das ativi-
dades pode ser alterada de acordo com a necessidade da
VSE e da prescrio do ciclo de vida escolhido.
GUIA DE IMPLEMENTAO
|
|
PARTE II
49
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

6.3.2 Desenvolvimento dos projetos: o processo produtivo
Uma VSE possui caractersticas, necessidades e competncias especfcas ao seu contex-
to. O processo produtivo [de desenvolvimento de software] de uma VSE desenvolvedora de
software que tome por base a ABNT NBR ISO/IEC 29110-4-1, perfl bsico, tem defnidas as
atividades que sero realizadas e os produtos de trabalho que sero gerados como resulta-
do dessas atividades na conduo do desenvolvimento de um projeto. Como j vimos, deve
tambm embasar todo ciclo de vida do desenvolvimento de software que contribui para o
alcance dos seus objetivos, gerando o produto de software esperado.
O processo produtivo executado em ciclos de melhoria contnua deve, ainda, contribuir
para o aprimoramento das competncias sugeridas da organizao.
Uma VSE deve envolver cada membro da equipe para a execuo das atividades do pro-
jeto. Um mesmo membro da equipe pode exercer mais de um papel ao longo do ciclo de vida
de desenvolvimento de software, entretanto importante garantir sua capacitao para tal.
Segundo a ABNT NBR ISO/IEC 29110-4-1, estas caractersticas e competncias sugeridas
podem ser agrupadas em quatro categorias distintas: fnanas e recursos; interface com o
cliente; processos de negcios internos; e aprendizado e crescimento.
As categorias que agrupam as caractersticas, necessidades e competncias sugeridas
que defnem uma VSE, assim como o relacionamento desses aspectos com os requisitos da
ABNT NBR ISO/IEC 29110-4-1, esto detalhados no Anexo C deste Guia.
A fgura 19 apresenta o contexto de uma VSE e seus inter-relacionamentos durante a
execuo das atividades do ciclo de desenvolvimento de software baseado em processos.
AO OBSERVE
Usar os processos ajustados
nos projetos da organizao
Aps o desenvolvimento de um processo que
caracterize o(s) ciclo(s) de vida adaptados para a
organizao, os projetos devem ser realizados com
base no que foi defnido.
Os processos da organizao devem ser de conhe-
cimento de todos, e importante que os envolvidos
nas atividades sejam capacitados para realiz-las da
forma adequada e mais efciente possvel.
GUIA DE IMPLEMENTAO
|
|
PARTE II
50
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

Figura 19 - Inter-relacionamentos no contexto de uma VSE
O uso do perfil bsico da srie ISO/IEC 29110 no desenvolvimento de projetos
de software
O perfl bsico grupo de perfl genrico da srie ISO/IEC 29110 defne como requisitos
obrigatrios o alcance de objetivos especfcos dos processos de gesto de projetos e de
implementao de software, a realizao de atividades relacionadas desses processos e a ge-
rao de produtos de trabalho resultados dessas atividades.
A fgura 19 mostra o relacionamento entre esses elementos no contexto de uma VSE.
Nos itens a seguir, alinhados com as macroatividades descritas nos processos de gesto
de projetos e de implementao de software, so apresentadas prticas para a implementa-
o dos requisitos da norma, bem como o relacionamento dessas prticas com os elementos
normativos obrigatrios.
GUIA DE IMPLEMENTAO
|
|
PARTE II
51
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

a) Planejando o projeto
ENTRADAS
Adaptar o ciclo de vida realidade da organizao, considerando suas caractersticas e as
caractersticas dos seus projetos
IMPLEMENTANDO
Reunir-se com o cliente e outros interessados para revisar a declarao de trabalho e combinar
como sero feitas as entregas do produto (como, o que, quando, onde etc.).
Identificar as tarefas a serem realizadas para produzir o que deve ser entregue, estimando
os recursos humanos e materiais necessrios, treinamento, ferramentas e prazos, criando o
cronograma do projeto.
Organizar a equipe do projeto.
Fazer uma anlise de riscos.
Definir o controle dos documentos e outros artefatos do projeto, onde sero armazenados,
como ser o versionamento, como e quando sero geradas baselines e as responsabilidades por
tudo isso, criando o repositrio do projeto.
Revisar e verificar o plano do projeto, obter aprovao dos interessados, obter o aceite do
cliente nas partes que o afetam.
RELACIONAMENTO COM A NORMA
Objetivos de processos
PM.O1. O plano de projeto desenvolvido de acordo com a declarao de trabalho e validado
com o cliente. As tarefas e os recursos necessrios para concluir os trabalhos so dimensiona-
dos e estimados.
PM.O5. Riscos so identificados inicialmente e durante a conduo do projeto.
PM.O6. uma estratgia de controle de verso de software desenvolvida. itens de configurao
de software so identificados, definidos e colocados em baseline. As modificaes e liberaes
dos itens so controladas e disponibilizadas ao cliente e equipe de trabalho, incluindo o arma-
zenamento, manuseio e entrega dos itens.
PM.O7. Garantia de qualidade de software realizada para assegurar que os produtos e processos
de trabalho cumpram o plano de projeto e a especificao de requisitos.
Produtos de sada
Plano de projeto
Registro de reunio
Repositrio do projeto
GUIA DE IMPLEMENTAO
|
|
PARTE II
52
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

REPOSITRIO
Coleo de todos os artefatos relativos ao software pertencentes a um
sistema ou localizao/formato onde tal coleo est armazenada.
[ISO/IEC/IEEE 24765]
BASELINE
Especifcao ou produto que foi formalmente revisto e acordado, servin-
do como base para o desenvolvimento futuro, e que s pode ser alterado
mediante de procedimentos formais de controle de mudana
ESTABELECENDO BASELINE PARA O PROJETO
Ao longo do ciclo de vida do desenvolvimento torna-se necessrio
registrar o resultado de atividades e guardar produtos intermedirios
importantes, de modo a prover uma referncia slida que seja a base
para o trabalho seguinte. A ideia congelar um conjunto de docu-
mentos e produtos que se tornam a verso de referncia para consul-
tas e uso nas atividades que se seguem e por parte dos profssionais que as utilizam. A
esse conjunto d-se o nome de baseline.
Conforme a metodologia e o modelo adotado, a quantidade de baseline e a sua compo-
sio variam bastante. Porm, alguns documentos e produtos so obviamente candi-
datos a um controle que garanta sua segurana e confabilidade para a continuidade, o
sucesso e a qualidade do desenvolvimento de software. A lista a seguir uma sugesto
de documentos que devem ser colocados em baseline:
Documento que registra os requisitos do usurio
Documento que registra as funcionalidades que implementam os requisitos
Projeto e modelagem do produto a ser desenvolvido
Produtos intermedirios da construo
Resultado do teste fnal do produto
Confgurao do produto pronto para uso
Muitos outros produtos podem ser eleitos para controle formal, dependendo do tipo de
produto de software em desenvolvimento, do seu porte, sua complexidade, tamanho da
equipe, acordo com o cliente etc.
Atas de reunies importantes, logs de arquivos e operaes executadas, resulta-
dos de auditorias de qualidade, comprometimentos com clientes, aceites, renego-
ciaes, comprometimentos da equipe, anlises de riscos, evoluo fsica do proje-
to, dos custos e dos prazos, lies aprendidas, defeitos encontrados, solues efica-
zes so alguns dos exemplos de artefatos que cabe organizao avaliar e decidir
o nvel de controle para eles.
GUIA DE IMPLEMENTAO
|
|
PARTE II
53
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

b) Execuo do plano de projeto
ENTRADAS
Solicitao de mudana
Plano de projeto
Estratgia de controle de verso
IMPLEMENTANDO
Monitorar a execuo do projeto e registrar o realizado no registro de status de progresso.
Conduzir reunies de reviso com a equipe de trabalho, identificar problemas, rever status dos
riscos, registrar as decises e monitor-las at a sua concluso.
Conduzir reunies de reviso com o cliente, registrar as decises e monitor-las at a sua
concluso.
Solicitao de mudana iniciada pelo cliente ou pela equipe de trabalho, que afete o cliente,
precisa ser negociada para alcanar a aceitao de ambas as partes.
Se necessrio, atualizar o plano do projeto segundo o novo acordo com o cliente.
Fazer backups de acordo com a estratgia de controle de verso.
Fazer a recuperao do repositrio do projeto usando o backup do repositrio do projeto, se
necessrio.
PM.O2. O progresso do projeto monitorado contra o plano do projeto e registrado no registro
de status de progresso. So feitas correes para remediar os problemas e desvios do plano
quando as metas do projeto no forem alcanadas. O encerramento do projeto realizado para
obter a aceitao do cliente, documentada no registro de aceitao.
PM.O3. As solicitaes de mudana so tratadas atravs de sua recepo e anlise. Mudanas
nos requisitos de software so avaliadas quanto ao custo, prazo e impacto tcnico.
PM.O4. So mantidas reunies de avaliao com a equipe de trabalho e o cliente. Acordos so
registrados e monitorados.
PM.O5. Riscos so identificados inicialmente e durante a conduo do projeto.
PM.O7. Garantia de qualidade de software realizada para assegurar que os produtos e processos
de trabalho cumpram o plano de projeto e a especificao de requisitos.
Produtos de sada
Registro de status de progresso
Plano de projeto
Solicitao de mudana
Backup de repositrio do projeto
Registro de reunio
GUIA DE IMPLEMENTAO
|
|
PARTE II
54
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

c) Avaliao e controle de projeto
ENTRADAS
Registro de status de progresso
Plano de projeto
IMPLEMENTANDO
Avaliar o progresso do projeto com respeito ao plano do projeto, comparando:
- tarefas realizadas versus planejadas;
- resultados realizados versus objetivos do projeto estabelecidos;
- alocao de recursos realizada versus planejada;
- custo real versus estimativas do oramento;
- momento real versus cronograma planejado;
- riscos reais versus identificados previamente.
Estabelecer aes para corrigir desvios ou problemas e riscos identifcados, no que tange reali-
zao do plano, conforme necessrio, document-las no Registro de Correo e monitor-las at
a sua concluso.
Identificar mudanas nos requisitos e/ou no plano de projeto para enfrentar desvios signifcati-
vos, riscos potenciais ou problemas relacionados com a realizao do plano, document-las em
solicitao de mudana e monitor-las at a concluso.
Produtos de sada
Registro de status do progresso
Registro de correo
Solicitao de mudana
GUIA DE IMPLEMENTAO
|
|
PARTE II
55
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

d) Encerramento do projeto
e) Iniciao da implementao do software
ENTRADAS
Plano de projeto
Configurao do software
IMPLEMENTANDO
Formalizar a concluso do projeto de acordo com as instrues de entrega estabelecidas no pla-
no de projeto, fornecendo apoio para a aceitao e recebendo o registro de aceitao assinado.
Atualizar o repositrio do projeto
Produtos de sada
Registro de aceitao
Repositrio do projeto
ENTRADAS
Plano de projeto
IMPLEMENTANDO
Reunir-se com a equipe do projeto e discutir o plano do projeto para alcanar um entendimento
comum e comprometimento com as tarefas.
Organizar o ambiente de trabalho em termos de local, equipamentos, software, ferramentas,
arquivos, senhas, acessos, autorizaes etc.
SI.O1. As tarefas das atividades so realizadas segundo o plano de projeto corrente.
Produtos de sada
GUIA DE IMPLEMENTAO
|
|
PARTE II
56
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

f) Anlise dos requisitos do software
ENTRADAS
Plano de projeto
IMPLEMENTANDO
Identificar e consultar fontes de informao (cliente, usurios, sistemas anteriores, documentos
etc.), procurando obter todos os requisitos e analisando questes de escopo e viabilidade.
Documentar ou atualizar a especificao de requisitos.
Verificar os requisitos quanto consistncia com o produto definido na declarao de trabalho,
assegurando que estejam claros, sem ambiguidades e completos, registrando os resultados e
corrigindo o que for preciso.
Obter aprovao da especificao de requisitos.
Validar a especificao de requisitos, obter aprovao do usurio e gerar uma baseline na
configurao do software.
Se for o caso, preparar uma verso preliminar da documentao do usurio ou atualizar o
manual existente.
SI.O2. Requisitos de software so definidos, analisados quanto correo e testabilidade,
aprovados pelo cliente, colocados em baseline e comunicados.
SI.O6. Uma configurao de software, que atende especificao de requisitos, conforme
acordado com o cliente, que inclui a documentao do usurio, de operao e de manuteno
integrada, colocada em baseline e armazenada no repositrio do projeto. Necessidades de
alteraes configurao do software so detectadas e as correspondentes solicitaes de
mudana so iniciadas.
SI.O7. Tarefas de verificao e validao de todos os produtos de trabalho necessrios so
realizadas usando critrios definidos para assegurar a consistncia entre produtos de sada e
entrada em cada atividade. Defeitos so identificados e corrigidos; registros so armazenados
em resultados de verificao/validao.
Produtos de sada
Solicitao de mudana
Especificao de Requisitos
Resultados de validao
Resultados de verificao
Documentao do usurio do software
GUIA DE IMPLEMENTAO
|
|
PARTE II
57
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

g) Projeto de arquitetura e detalhamento do software
ENTRADAS
Plano de projeto
Especificao de requisitos
IMPLEMENTANDO
Documentar ou atualizar o projeto do software.
Verificar e obter aprovao do projeto do software.
Criar ou atualizar os casos de teste e procedimentos de teste para o teste de integrao,
baseados na especificao de requisitos e no projeto de software.
Verificar e obter aprovao dos casos de teste e procedimentos de teste.
A partir da especificao de requisitos, gerar o projeto de arquitetura do produto,
seus componentes e interfaces internas e externas, cuidando para que sua aparncia e
comportamento estejam afinados com as expectativas do cliente.
Gerar ou atualizar o registro de rastreabilidade
Verificar o projeto do software e o registro de rastreabilidade, registrando o resultado e
ajustando o que for preciso
Definir os casos de teste e os procedimentos de teste, fazer sua verificao e incorpor-los ao
registro de rastreabilidade e ao repositrio do projeto.
SI.O3. Projeto de arquitetura e detalhamento do software elaborado e colocado em baseline.
Ele descreve os itens de software e suas interfaces internas e externas. So estabelecidas
consistncia e rastreabilidade aos requisitos de software.
acordado com o cliente, que inclui a documentao do usurio, de operao e de manuteno,
Produtos de sada
Solicitao de mudana
Projeto do software
Casos de teste e procedimentos de teste
Registro de rastreabilidade
GUIA DE IMPLEMENTAO
|
|
PARTE II
58
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

COMPONENTE DE SOFTWARE
Sistema ou elemento de software, como mdulo, unidade, dado
ou documento.
[IEEE Std 1061]
ARQUITETURA E INTERFACES
Arquiteturas e interfaces devem ser detalhadas no nvel e na dimenso
adequados ao contexto do projeto. Por exemplo, projetos de manu-
teno podem considerar a atualizao da arquitetura e das interfaces
do produto a ser mantido e, neste caso, pode no ser necessrio que se
defna nova arquitetura ou novas interfaces para o projeto especfco.
RASTREABILIDADE
Um registro de rastreabilidade um produto de trabalho que:
identifca requisitos a serem rastreados;
identifca um mapeamento do requisito a produtos de trabalho do
ciclo de vida;
prov o elo de requisitos para a decomposio de produto de tra-
balho (isto , requisito, projeto, cdigo, teste, entregveis etc.);
prov mapeamento bidirecional de requisitos a produtos de traba-
lho associados atravs de todas as fases do ciclo de vida.
O nvel e a dimenso do que deve ser rastreado devem ser considera-
dos de acordo com o contexto do projeto.
importante que a rastreabilidade gerada suporte, em casos de
mudana e manuteno, que seja identifcado o que deve ser al-
terado e qual o impacto em termos tcnicos, de custo e de esforo
que ir ocasionar.
Ferramentas de apoio podem tornar a captura e a manuteno da ras-
treabilidade muito mais efcaz e til.
Nos casos dos projetos de manuteno evolutiva ou corretiva, deve-se
considerar a rastreabilidade dos requisitos que esto sendo alterados
versus aquela do produto a ser mantido.
Atividades de captura e manuteno de rastreabilidade em projetos
de manuteno podem auxiliar na construo da documentao de
legados no documentados.
GUIA DE IMPLEMENTAO
|
|
PARTE II
59
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

h) Construo do software
ENTRADAS
Plano de projeto
Projeto do software
IMPLEMENTANDO
Construir ou atualizar os componentes de software com base na parte detalhada do projeto de
software e definir ou atualizar os casos de teste de unidade.
Construir os componentes de software com base na parte detalhada do projeto de software,
executar testes unitrios e atualizar o registro de rastreabilidade.
Projetar ou atualizar os casos de teste unitrios e aplic-los para verifcar os componentes de software.
Gerar uma baseline da configurao do software, incorporando os componentes e o registro de
rastreabilidade.
Corrigir os defeitos encontrados at alcanar sucesso no teste unitrio (chegando ao critrio de sada).
Atualizar o registro de rastreabilidade, incorporando os componentes de software construdos
ou modificados.
SI.O4. Componentes de software definidos no projeto so desenvolvidos. Testes unitrios so
definidos e realizados para verificar a consistncia com os requisitos e o projeto. Rastreabilidades
para os requisitos e para o projeto so estabelecidas.
acordado com o cliente, que inclui a documentao do usurio, de operao e de manuteno,
Produtos de sada
Componentes do software
RELATRIO
Item de informao que descreve os resultados de atividades,
como investigaes, avaliaes e testes.
[ISO/IEC 15289:2006]
GUIA DE IMPLEMENTAO
|
|
PARTE II
60
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

i) Integrao e testes do software
ENTRADAS
Componentes do software
Plano de projeto
Casos de teste e procedimentos de teste
IMPLEMENTANDO
Construir ou atualizar os componentes de software com base na parte detalhada do projeto de
software e definir ou atualizar os casos de teste de unidade.
Integrar os componentes do software, executando os casos de teste segundo os procedimentos
de teste e documentando os resultados no relatrio de teste.
Atualizar o registro de rastreabilidade.
Gerar o guia de operao, verific-lo e obter aprovao.
Atualizar, verificar e obter aprovao da documentao do usurio.
Gerar uma baseline incorporando casos de teste e procedimentos de teste, registro de
rastreabilidade, relatrio de teste, guia de operao do produto e documentao do usurio do
software configurao de software.
Projetar ou atualizar os casos de teste unitrios e aplic-los para verifcar os componentes de software.
Corrigir os defeitos encontrados at alcanar sucesso no teste unitrio (chegando ao critrio de sada).
Atualizar o registro de rastreabilidade, incorporando os componentes de software construdos
ou modificados.
SI.O5. Software produzido fazendo a integrao de componentes de software e verifcado atravs de
casos de teste e procedimentos de teste. Os resultados so registrados no relatrio de teste. Defeitos
so corrigidos, e so estabelecidas a consistncia e a rastreabilidade ao projeto de software.
SI.O6. Uma confgurao de software, que atende especifcao de requisitos, conforme acordado
com o cliente, que inclui a documentao do usurio, de operao e de manuteno, integrada,
colocada em baseline e armazenada no repositrio do projeto. Necessidades de alteraes confgu-
rao do software so detectadas e as correspondentes solicitaes de mudana so iniciadas.
SI.O7. Tarefas de verifcao e validao de todos os produtos de trabalho necessrios so realizadas usando
critrios defnidos para assegurar a consistncia entre produtos de sada e entrada em cada atividade.
Defeitos so identifca-dos e corrigidos; registros so armazenados em resultados de verifcao/validao.
Produtos de sada
Componentes do software Guia de operao do produto
Software Configurao do software
Registro de rastreabilidade Resultados de verificao
Casos de teste e procedimentos de teste relatrio de teste
GUIA DE IMPLEMENTAO
|
|
PARTE II
61
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

j) Entrega do produto
ENTRADAS
Plano de projeto
IMPLEMENTANDO
Atribuir tarefas relativas ao seu papel aos membros da equipe de trabalho, de acordo com o
plano de projeto corrente.
Elaborar, verifcar e obter aprovao para a documentao de manuteno, incorporando-a
confgurao do software.
Realizar a entrega do produto ao cliente, de acordo com as condies estabelecidas (no incio do
planejamento) em instrues de entrega e obter o aceite formal do cliente.
Obter entendimento da configurao do software.
Elaborar a documentao de manuteno ou atualizar a existente.
Verificar a consistncia da documentao de manuteno com a configurao do software. Os
resultados encontrados so documentados em resultados da verificao, e correes so feitas
at que o documento seja aprovado pelo lder de projeto.
Incorporar documentao de manuteno como baseline na configurao de software.
Realizar a entrega de acordo com as instrues de entrega.
SI.O6. Uma confgurao de software, que atende especifcao de requisitos, conforme acordado
com o cliente, que inclui a documentao do usurio, de operao e de manuteno, integrada,
colocada em baseline e armazenada no repositrio do projeto. Necessidades de alteraes confgu-
rao do software so detectadas e as correspondentes solicitaes de mudana so iniciadas.
SI.O7. Tarefas de verifcao e validao de todos os produtos de trabalho necessrios so realizadas
usando critrios defnidos para assegurar a consistncia entre produtos de sada e entrada em cada
atividade. Defeitos so identifcados e corrigidos; registros so armazenados em resultados de
verifcao/validao.
Produtos de sada
Documentao de manuteno
GUIA DE IMPLEMENTAO
|
|
PARTE II
62
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

6.3.3 Acompanhamento da aderncia dos projetos aos processos
AO OBSERVE
Realizar avaliaes de aderncia nos
pontos de controle defnidos
importante que nos pontos de controle defni-
dos no processo os desvios observados sejam re-
gistrados de modo a permitir que aes adequadas
sejam tomadas.
Quando no h monitorao frequente, h mais
chances de que a motivao e o empenho da alta
gerncia diminuam ao longo do projeto.
6.3.4 Identifcao das no conformidades e oportunidades de melhoria
AO OBSERVE
Identifcar as no conformidades ocorridas na
execuo do processo de desenvolvimento
Identifcar as oportunidades de melhoria
que podem ser implementadas no processo
de desenvolvimento
A ocorrncia de problemas, desvios e inconsis-
tncias, chamados de no conformidades, deve ser
identifcada.
Em momentos iniciais, quando o processo ainda
no est totalmente institucionalizado, comum a
ocorrncia de problemas, desvios e no conformi-
dades.
A defnio de critrios auxilia a identifcao de
no conformidades.
O ideal que as revises para identifcao de
no conformidades, assim como quaisquer outras
revises, sejam realizadas por algum diferente da-
quele que realizou a atividade ou o artefato objeto
da reviso.
recomendado que produtos que sero objeto
de reviso sejam avaliados antes da sua entrega ao
prximo usurio.
GUIA DE IMPLEMENTAO
|
|
PARTE II
63
D
E
S
E
N
V
O
L
V
I
M
E
N
T
O

D
E

S
O
F
T
W
A
R
E
S

P
A
R
A

P
E
Q
U
E
N
A
S

O
R
G
A
N
I
Z
A
E
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

6.4 FASE 4 Melhoria
6.4.1 Realizao de auditorias (internas e externas)
AO OBSERVE
Realizar auditorias internas
Auditorias internas, quando realizadas com inde-
pendncia, ou seja, por pessoa diferente daquelas
que executam o processo, aumentam a confana
da equipe no trabalho que est sendo realizado.
A realizao da auditoria interna deve considerar
a aderncia dos processo seguidos pelos projetos
desenvolvidos aos requisitos preconizados na
ABNT NBR ISO/IEC 29110-4-1.
Realizar auditorias externas
A realizao de auditorias externas garante uma
viso independente e auxilia na identifcao de
problemas que nem sempre so percebidos pelas
pessoas da organizao.
A realizao de auditorias externas por organis-
mos ofciais permite organizao a obteno de
uma credencial que pode ser reconhecida pelo
mercado como atestado de qualidade de seus
produtos.
6.4.2 Tratamento das no conformidades
AO OBSERVE
Realizar aes para solucionar as no con-
formidades identifcadas nas auditorias
Realizar aes para implementar as opor-
tunidades de melhorias identifcadas nas
auditorias
Para as no conformidades e oportunidades de
melhoria identifcadas nas auditorias, internas ou
externas, devem ser tomadas aes.
recomendado que as aes sejam planejadas
de modo que possam ser gerenciadas, garantindo,
assim, a sua concluso.
GUIA DE IMPLEMENTAO
|
|
PARTE II
64
ANEXO A
ANEXOS
1. A ESTRATGIA DE DESENVOLVER NORMAS E GUIAS PARA AS VSE COMPONDO PERFIS
Tendo em vista as caractersticas e necessidades identifcadas nas fases de levantamento
e estudos, e que delineavam o que vinha a ser uma VSE, uma importante premissa para
o desenvolvimento da srie ISO/IEC 29110 era que sua estrutura deveria ser fexvel o
bastante para atender a essas caractersticas e necessidades.
Havia, entretanto, o consenso de que o contedo tcnico a ser usado como base para
compor a srie pretendida j estava disponvel e poderia ser encontrado entre centenas
de documentos publicados, normas, guias e modelos, muitos deles tratando conceitos,
defnies e metodologias similares em nveis de abstrao e detalhamentos diferentes.
A deciso sensata foi, portanto, que no havia necessidade de se criarem novas defni-
es e conceitos para aquilo que j estava consolidado nas normas e guias publicados,
mas apenas de visitar esses documentos com a viso de se fazer um recorte possvel de
ser aplicado ao contexto de uma VSE.
1.1 PERFIL INTERNACIONAL NORMALIZADO
Visando ento atender s premissas de fexibilidade e adequao ao contexto, a estrat-
gia de desenvolvimento das normas e guias da srie ISO/IEC 29110 contempla:
P primeiro, a seleo, entre os documentos relevantes publicados, daqueles que
podem ser considerados normas de base e referncias normativas para o contexto
observado;
P segundo, a identifcao nessas normas de base daquilo que, de fato, se aplica
ao contexto de uma pequena organizao. As normas e guias usadas servem de
base, ento, para que se faa um recorte das partes que so aplicveis ao contexto
pretendido.
composio dessas partes recortadas de normas e guias de base d-se o nome de perfl
internacional normalizado.
A fgura 20 exemplifca a criao de perfs a partir da composio de partes selecionadas
de normas de base.
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
PARTE II
65
ANEXO A
GUI A DE I MPLEMENTAO
Figura 20 - Elementos de um perfl internacional normalizado
Um perfl internacional normalizado , ento, uma combinao de uma ou mais normas
de base para cumprir uma funo em particular.
1.2 GRUPO DE PERFIL
Um perfl internacional normalizado um elemento que pertence a um grupo dirigido
a um determinado tipo de contexto e deve respeitar as caractersticas que levaram sua
criao. Entretanto, entre as caractersticas gerais que o defnem, pode haver uma diver-
sidade de detalhes, fazendo com que, para um mesmo contexto, haja necessidade de se
desenvolver mais de um perfl. Estes perfs devem, necessariamente, relacionar-se entre
si de tal forma que seja permitida uma viso mais refnada e detalhada das caractersticas
do contexto geral.
Esta coleo de perfs relacionados entre si pela composio dos seus processos (ativi-
dades, tarefas etc.) denominada grupo de perfs (PG - Profle Group). Cabe ressaltar que
nada impede, naturalmente, que um grupo de perfs possua apenas um perfl.
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
PARTE II
66
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
ANEXOS
1.3 PERFIS INTERNACIONAIS NORMALIZADOS PARA VSE
No caso da srie ISO/IEC 29110, os perfs internacionais normalizados so agrupados
para atender a contextos especfcos dos ciclos de vida das VSE e, embora a caracterstica
central das entidades contempladas pela ISO/IEC 29110 seja o tamanho, outros aspectos
podem afetar a preparao e a seleo de perfs, como modelo de negcio (comercial,
contratao, desenvolvimento in-house etc.); fatores situacionais (como criticidade, in-
certeza ambiental etc.) ou nveis de risco. Entretanto, criar um perfl para cada possvel
combinao de valores dessas dimenses seria extremamente complexo.
Os perfs VSE contemplam as VSE que so descritas atravs de caractersticas, necessida-
des e competncias desejveis, classifcadas em quatro categorias: fnanas e recursos;
interface com o cliente; processos de negcios internos; e aprendizado e crescimento.
Portanto, os perfs VSE esto agrupados de tal modo que sejam aplicveis a mais de uma
categoria, como, por exemplo, para categoria de desenvolvimento de software genricos,
que composta por quatro perfs internacionais normalizados, os perfs VSE: perfl de
entrada, perfl bsico, perfl intermedirio e perfl avanado, onde esto distribudos os
elementos que permeiam o ciclo de vida de desenvolvimento de software.
Os perfs VSE contidos na ISO/IEC 29110 permitem um ajuste fno da norma s caracters-
ticas de diferentes grupos de VSEs e novos grupos de perfs podero ser acrescentados,
se cabvel, para atender ao interesse de comunidades que identifquem demandas em
reas especfcas como, por exemplo, desenvolvimento de software para rea mdica,
gesto de servios, entre outros.
Em suma, os perfs de ciclo de vida tm o propsito primordial de possibilitar a criao
de uma norma bem ajustada s caractersticas de cada tipo de VSE, que assim encontrar
facilidade para entend-la e adot-la.
A fexibilidade prevista da srie ISO/IEC 29110 pode permitir s organizaes o acompa-
nhamento dos avanos do mercado e as variaes das necessidades de seus clientes sem
desviar-se do atendimento aos requisitos preconizados nos perfs defnidos.
No caso do grupo de perfl genrico, por exemplo, os perfs so desenvolvidos de modo
a contemplar tanto as empresas que seguem ciclos de desenvolvimento tradicionais
quanto aquelas que desejam usufruir de suas capacidades adaptativas em seus ciclos de
vida, por exemplo, usando diferentes metodologias, tcnicas e ambientes de desenvol-
vimento. Aqui se pode incluir o uso de metodologias geis e o desenvolvimento de sof-
tware usando cloud computing. Deste modo, podero ser tambm desenvolvidos outros
documentos e guias, visando auxiliar a aplicao dos grupos de perfl nessas situaes
mais especfcas.
ANEXO A
67
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
ANEXO
ANEXO B
1. NETWORK CENTER
Criado em 2008, o Global Network of VSE (Very Small Entities) Support Centers j conta
com a participao da Blgica, Canad, Finlndia, Frana, Irlanda, Colmbia, Peru, Luxem-
burgo e Tailndia. A RIOSOFT, coordenadora do NetCenter no Brasil, estrategicamente
estendeu o acordo a diversas entidades representativas do setor de software e servios
de TIC e outros interessados, incorporando-os como parceiros, de modo que suas aes
possam alcanar abrangncia nacional. A lista de parceiros crescente e pode ser acessa-
da pelo site http://netcenter4vse.org.br/.
Nos planos do network center brasileiro esto aes de apoio adoo de normas tc-
nicas, entre elas as normas da srie ABNT NBR ISO/IEC 29110 e ABNT NBR ISO/IEC 20000,
visando melhoria do processo produtivo de desenvolvimento de produtos e servios de
software e preparao das empresas para o mercado internacional.
1.1 OBJETIVOS
Os objetivos globais do NetCenter so:
P ajudar a acelerar o desenvolvimento de normas ISO para as VSE;
P acelerar a implementao das normas para as VSE;
P acelerar o desenvolvimento e aplicao de pacotes de implementao.
No Brasil, alm desses, h objetivos especfcos que visam a capacitao das empresas
nas reas de conhecimento de TI, de gesto e de normalizao. H tambm aes que
buscam parceria com grandes parceiros da indstria, a fm de fortalecer a cadeia produ-
tiva do setor.
Como primeiro resultado dessas parcerias, pode-se citar o projeto do NetCenter Brasil
com a Microsoft, pelo qual foi desenvolvido um framework para o desenvolvimento de
processos aderente ao perfl bsico da ISO/IEC 29110. O process template est disponvel
gratuitamente no link http://iso29110.codeplex.com/ .
2. PACOTES DE IMPLEMENTAO
Para facilitar a implementao de um perfl em uma VSE, um grupo de pacotes de imple-
mentao encontra-se disponvel.
Um pacote de implementao um conjunto de artefatos desenvolvidos para facilitar
a implementao de um grupo de prticas de um framework selecionado, em uma VSE.
No entanto, um pacote de implementao no um modelo de referncia de processo
completo. Pacotes de implementao no tm a inteno de impedir ou desencorajar a
utilizao de diretrizes adicionais que as VSE considerem teis.
Um pacote de implementao no um modelo de referncia de processo completo.
Os pacotes de implementao no tm inteno de prescindir ou desencorajar o uso de
guias adicionais que a VSE considerar teis.
Implementando e executando um pacote de implementao, uma VSE pode ver seu es-
tgio concreto para alcanar ou demonstrar cobertura da Parte 5.
68
Os pacotes de implementao so projetados de modo que uma VSE possa executar seu
contedo sem ter que implementar simultaneamente o framework completo.
Os elementos de um pacote de implementao tpico so:
P descrio tcnica;
P relaes com a ISO/IEC 29110;
P defnies-chave;
P descrio detalhada dos processos (atividades, tarefas, papis e produtos);
P template, checklist, exemplo;
P referncias e mapeamento a normas e modelos;
P lista de ferramentas.
O mapeamento apresentado apenas a ttulo de informao, para mostrar que um pa-
cote de implementao tem ligaes explcitas com a Parte 5, Normas como a ABNT NBR
ISO/IEC 12207, ou modelos como o CMMI desenvolvido pelo Software Engineering Institu-
te. Pacotes de implementao so desenvolvidos de forma que a VSE possa implementar
seu contedo sem ter que implementar o framework completo, concomitantemente. A
tabela 6 ilustra o contedo de um pacote de implementao.
ITEM DESCRIO
1
Descrio tcnica
Propsito deste documento
Por que este tpico importante?
2 Defnies
3 Relaes com a ISO/IEC 29110
4 Viso geral dos processos, atividades, tarefas, papis e produtos
5
Descrio de processos, atividades, tarefas, passos, papis e produtos
Descrio do papel
Descrio do produto
Descrio do artefato
6 Template(s)
7 Examplo(s)
8 Checklist(s)
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
ANEXOS
ANEXO B
69
ITEM DESCRIO
9 Ferramentas(s)
10
Referncias a outras normas e modelos (por exemplo, ABNT NBR ISO 9001, ISO/IEC
12207, CMMI)
11 Referncias
12 Formulrio de autoavaliao
Tabela 6 - Exemplo de contedo de um pacote de implementao
Para o perfl bsico para VSE, um grupo de pacote de implementao relacionado s
reas abaixo est disponvel, gratuitamente, na internet, no link http://profs.etsmtl.ca/cla-
porte/English/VSE/.
P anlise de requisitos;
P arquitetura e design detalhado;
P construo de unidade de teste;
P integrao e teste;
P verifcao e validao;
P controle de verso;
P gerenciamento de projeto;
P entrega de produto;
P autoavaliao.
H, ainda, pacotes de implementao baseados em ferramentas relacionados s se-
guintes atividades:
controle de verso;
controle de verso com CVS;
controle de verso com SVN;
gerncia de projeto;
gerncia de projeto com GForge;
issue tracking com GForge.
Os pacotes de implementao discutidos neste anexo esto disponveis em ingls e
francs, entretanto vrias aes esto sendo realizadas para o desenvolvimento e dispo-
nibilizao para as VSE de artefatos e ferramentas de apoio implementao da srie ISO/
IEC 29110.
As informaes sobre os prximos pacotes de implementao disponveis podem ser
obtidas no site do NetCenter brasileiro: http://netcenter4vse.org.br/
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
ANEXO
ANEXO B
70
As tabelas a seguir nominam as caractersticas de uma VSE. Dessas caractersticas derivam
necessidades e competncias sugeridas para que se chegue implementao adequa-
da do perfl bsico. Apresentam, ainda, o relacionamento com objetivos dos processos
e produtos de trabalho descritos na norma (requisitos normativos). Essa caracterizao
feita considerando quatro categorias diferentes: fnanas e recursos; interface com o
cliente; processos de negcios internos; e aprendizado e crescimento.
CATEGORIA 1: FINANAS E RECURSOS
ANEXO C
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

CARACTERSTICAS
NECESSIDADES E COMPETNCIAS
SUGERIDAS
pequeno nmero de desenvolvedores
fuxo de caixa de curto prazo em cada proje-
to pode ser fundamental para a VSE
projetos de pequeno oramento que duram
poucos meses e envolvem poucas pessoas
para desenvolver produtos de pequeno porte
dependem da concluso do projeto com su-
cesso dentro do cronograma e do oramento
preferem fazer projetos separados para reali-
zar a manuteno corretiva ps-entrega
recursos internos escassos para realizar geren-
ciamento, suporte e processos organizacionais,
como gerncia de risco, treinamento, gesto da
qualidade, melhoria de processos e reutilizao
Executar os projetos dentro do oramento e
entregar o produto no prazo
Manter estreita comunicao com o cliente
para gerenciar riscos
PM.O1. O plano de projeto para a execuo do projeto desenvolvido de acordo com a
declarao de trabalho e vali-dado com o cliente. As tarefas e os recursos necessrios para
concluir o trabalho so dimensionados e estimados.
PM.O2. O progresso do projeto monitorado contra o plano de projeto e registrado no re-
gistro de status de progresso. Correes para remediar problemas e desvios do plano so
adotadas quando as metas do projeto no forem alcanadas. O encerramento adequado do
projeto realizado para obter a aceitao do cliente documentada no registro de aceitao.
..............
SI.O1. Tarefas das atividades so realizadas atravs do cumprimento do plano de projeto corrente.
Produtos de trabalho
Declarao do trabalho
Relatrio do status de progresso
Plano de projeto
Registro de correo
Registro de aceitao
GUIA DE IMPLEMENTAO
|
|
ANEXOS
71
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

CATEGORIA 2: INTERFACE COM O CLIENTE
CARACTERSTICAS
SUGERIDAS
geralmente tm um cliente por projeto de
cada vez
a satisfao do cliente depende de:
- cumprimento de requisitos especficos
que podem mudar durante o projeto
- informao atualizada durante o desen-
volvimento do produto
- entrega no prazo
- baixo nvel de defeitos encontrados ps-
-entrega
- estreita comunicao e respostas rpidas
a qualquer mudana
geralmente o cliente no defne requisitos
quantitativos de qualidade
uma VSE normalmente no responsvel pela
gesto do sistema, integrao de software, insta-
lao e operao.
Cumprir os requisitos do cliente
Gerenciar a mudana dos requisitos do cliente
durante o projeto
Manter uma estreita comunicao e informa-
o atualizada ao cliente, em tempo til, du-
rante o desenvolvimento do produto
Entregar o produto com baixo nvel de defeitos
PM.O3. As solicitaes de mudana so tratadas atravs de sua recepo e anlise. Mudan-
as nos requisitos de software so avaliadas quanto ao custo, prazo e impacto tcnico.
PM.O4. Conduzir reunies de reviso com a equipe de trabalho e o cliente. Decises so
registradas e acompanhadas.
PM.O7. Garantia de qualidade de software realizada para garantir que produtos e proces-
sos de trabalho cumprem o plano de projeto e a especificao de requisitos.
..............
SI.O2. Requisitos de software so defnidos, analisados quanto correo e testabilidade, aprova-
dos pelo cliente, colocado em baseline e comunicados.
SI.O7. So realizadas tarefas de verifcao e validao de todos os produtos de trabalho reque-
ridos usando critrios defnidos para assegurar a consistncia entre produtos de sada e entrada
em cada atividade. Defeitos so identifcados e corrigidos, os registros so armazenados em re-
sultados de verifcao/validao.

Especificao de requisitos
Resultados de verificao e resultados de validao
Solicitao de mudana
Registro de reunio
Resultados de verificao e resultados de validao
GUIA DE IMPLEMENTAO
|
|
ANEXO
72
CATEGORIA 3: PROCESSOS DE NEGCIO INTERNOS
CARACTERSTICAS
SUGERIDAS
o processo principal desenvolver, sob contrato, sis-
temas de software customizados, escritos na empresa
o produto de software elaborado de forma progressiva
e tem que ser consistente com os requisitos do cliente
os produtos so desenvolvidos ou mantidos por meio
de projetos com um nico canal de comunicao en-
tre o grupo de implementao e o cliente
o nmero de desenvolvedores na organizao pe-
queno; portanto, a maior parte da comunicao, to-
mada de deciso e resoluo de problemas pode ser
realizada prontamente, face a face
a VSE superfcial na gesto de projetos e focada em
atividades de implementao de software
os processos gerncia de infraestrutura, gerncia de
portflio de projetos e gerncia de recursos humanos
so realizados por meio de mecanismos informais,
face a face
os produtos gerados pelos projetos so itens de sof-
tware que podem ter mais de uma verso e tm de ser
salvos e controlados
Controle de verso e armazenamento
dos produtos gerados durante o projeto
Elaborao progressiva do produto de
software, alcanando consistncia com
os requisitos do cliente
PM.O6. estabelecida uma estratgia de controle de ver-so do software. Itens de configu-
rao de software so identificados, definidos e colocados em baseline. As modificaes e
liberaes dos itens so controladas e disponibilizadas ao cliente e equipe de trabalho,
incluindo o armazenamento, manuseio e entrega dos itens.
..............
SI.O3. Um projeto de arquitetura e detalhamento desenvolvido e colocado em baseline. Ele
descreve os itens de SW e suas interfaces internas e externas. estabelecida consistncia e rastre-
abilidade aos requisitos de software.
SI.O4. Componentes de SW defnidos para projeto so produzidos. Testes unitrios so defnidos
e realizados para verifcar a consistncia com os requisitos e o projeto. estabelecida rastreabili-
dade para os requisitos e o projeto.
SI.O5. Software produzido fazendo a integrao dos componentes de SW e verifcado usando
casos e procedimentos de teste. Os resultados so registrados no relatrio de teste. Os defeitos
so corrigidos e estabelecida consistncia e rastreabilidade ao projeto do software.
SI.O6. Uma confgurao de SW, que atende especifcao de requisitos conforme acordado
com o cliente, a qual inclui documentaes do usurio, de operao e de manuteno integra-
da, colocada em baseline e armazenada no repositrio do projeto. Necessidades de alteraes na
confgurao do software so detectadas e as devidas solicitaes de mudana so iniciadas.

Repositrio do projeto Backup do repositrio do projeto
Componentes de software Relatrio de teste
Documentao de manuteno Guia de operao do produto
Software Configurao do software
Projeto do software Documentao de usurio
Casos de teste Procedimentos de teste
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
ANEXOS
73
CATEGORIA 4: APRENDIZAGEM E CRESCIMENTO
CARACTERSTICAS
SUGERIDAS
conscincia da importncia das normas
falta de recursos humanos para engajar na normalizao
falta de informao sobre as normas
falta de conhecimento sobre melhoria de processo
de software e avaliao de processos
Orientaes, fexveis e fceis de usar por
novatos, para adotar prticas de Normas
focadas em processos para apoiar suas
necessidades nos projetos de desenvol-
vimento de software
No h objetivos de processos obrigatrios relaciona-dos

No h produtos de trabalho obrigatrios relacionados
Outros elementos da srie
O guia de gesto e engenharia Projeto ABNT NBR ISO/IEC 29110-5 auxilia a implementao do
perfl bsico e pode auxiliar o aprendizado da VSE.
Trata-se de um documento til para o desenvolvimento de software e o gerenciamento de
projetos, que traz a descrio dos processos nos quais se integram propsitos, objetivos,
resultados, atividades, tarefas, produtos e papis dentro de fuxos de trabalho explcitos.
A
N
E
X
O
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
ANEXO
74
REFERNCIAS
ABNT NBR ISO/IEC 29110-2:2012, Engenharia de software Perfis de ciclo de vida para
micro-organizaes (VSEs) Parte 2: Estrutura e taxonomia
ABNT NBR ISO/IEC 29110-4-1:2012, Engenharia de software Perfis de ciclo de vida para
micro-organizaes (VSEs) Parte 4-1: Especificaes de perfil: Grupo Perfil Genrico
ABNT ISO/IEC TR 29110-5-1-2:2012, Engenharia de software Perfis de ciclo de vida para
micro-organizaes (VSEs) Parte 5-1-2: Guia de engenharia e gesto: Grupo perfil ge-
nrico: Perfil bsico
FUGGETTA, A. Software process: a roadmap. In: ICSE - Future of Software - Software
Engineering Track, pp. 25-34. 2000.
GEM. GEM Global Entrepreneurship Monitor, London Business School & Babson Col-
lege, EUA. 2006.
Global Network of VSE (Very Small Entities) Support Centres. cole de technologie su-
prieure. http://profs.etsmtl.ca/claporte/English/VSE/.
ISO/IEC12207, 2008, Systems and software engineering Software life cycle processes.
R
E
F
E
R
N
C
I
A
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
REFERNCIAS
75
NORMALI ZAO
R
E
F
E
R
N
C
I
A
S
G
U
I
A

D
E

I
M
P
L
E
M
E
N
T
A
O

GUIA DE IMPLEMENTAO
|
|
REFERNCIAS
ISO/IEC TR 29110-1, Software engineering - Lifecycle profiles for very small entities
(VSE) - Part 1: Overview. Geneva: International Organization for Standardization (ISO),
2011.
ISO/IEC TR 29110-3, Software engineering - Lifecycle profiles for very small entities
(VSEs) - Part 3: Assessment Guide. Geneva: International Organization for Standardization
(ISO), 2011.
Observatrio SOFTEX. Relatrio Anual do Observatrio Softex IBSS Indstria Bra-
sileira de Software e Servios. http://www.softex.br/observatoriosoftex/_home/default.
asp. 2011
OECD - Organization for Economic Co-operation and Development. SME and Entrepre-
neurship Outlook [Relatrio]. 2005.
PRESSMAN, Roger S. Engenharia de Software. Sexta Edio. Porto Alegre: MCGrawHill,
2010.
STAPLES, M., NIAZI, M., JEFFERY, R., et al. An exploratory study of why organizations do
not adopt CMMI, Journal of Systems and Software, v. 80, n. 6, pp. 883-895, 2007

Guia - Desenvolvimento de Software

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Guia - Desenvolvimento de Software

Încărcat de

Drepturi de autor:

Formate disponibile

GUIA DE IMPLEMENTAO

DESENVOLVIMENTO DE SOFTWARES PARA PEQUENAS ORGANIZAES

S-ar putea să vă placă și