Você está na página 1de 154

Universidade Federal de Santa Catarina

Mara Bay de Souza

Modelo de Processo de Software: aplicao em uma


empresa jnior

Florianpolis, 2004

UNIVERSIDADE FEDERAL DE SANTA CATARINA


DEPARTAMENTO DE INFORMTICA E ESTATSTICA
CURSO DE CINCIAS DA COMPUTAO

TTULO: "Modelo de Processo de Software: aplicao em uma empresa jnior"


AUTORA: Mara Bay de Souza
ORIENTADORA: Christiane Gresse von Wangenheim
CO-ORIENTADOR: Aldo von Wangenheim
BANCA EXAMINADORA: Jos Eduardo De Lucca

Palavras-chave: modelo de processo, processo de software, empresa jnior

Florianpolis, 13 de Fevereiro de 2004

DEDICATRIA

Aos meus pais, que me


proporcionaram uma educao
incomparvel e sempre acreditaram no
meu potencial. Sem vocs eu no
poderia estar aqui.

AGRADECIMENTOS

minha famlia, pela compreenso, amor e carinho.

professora Christiane Gresse von Wangenheim, pelo apoio e pacincia, por todos
os valiosos comentrios e orientaes.

Aos professores Aldo von Wangenheim e Jos Eduardo De Lucca, por fazerem
parte da banca avaliadora.

A todos os membros e ex-membros do NPI pela cooperao na realizao deste


trabalho.

A todos aqueles que, assim como eu, acreditam no NPI e no seu sucesso.

RESUMO

Este trabalho consiste na elaborao de um modelo de processo de


desenvolvimento de software para a empresa jnior dos cursos de Cincias da
Computao e Sistemas de Informao da Universidade Federal de Santa Catarina.
Alm disso, o trabalho tambm engloba a atividade de anlise do processo de
desenvolvimento existente, bem como a atividade de produo de um plano de
avaliao (utilizando a metodologia GQM), a ser executado durante a aplicao do
modelo. Os prprios alunos dos cursos citados realizam as atividades tcnicas e

administrativas da empresa jnior. Por causa disso, o NPI (Ncleo de Projetos em


Informtica) possui algumas caractersticas de micro e pequenas empresas (como
inexperincia em gerncia e em desenvolvimento sistematizado de software) e
outras bem particulares (por exemplo, altssima rotatividade de diretores e
desenvolvedores), as quais levam ocorrncia de processos e produtos de baixa
qualidade. Baseando-se na literatura, acredita-se que a utilizao de um modelo de
processo de desenvolvimento ir contribuir para a melhoria da qualidade do
software desenvolvido no NPI, colaborando para a soluo dos problemas
detectados. O modelo apresentado neste trabalho foi desenvolvido com base no
processo existente no NPI e nos requisitos da empresa jnior para um processo
ideal. Ele abrange todas as fases de um projeto tpico de desenvolvimento de
software no NPI, contendo tanto atividades tcnicas como gerenciais. Comparandoo com alguns outros modelos desenvolvidos para outras empresas e com modelos
de avaliao do processo (p.ex. CMM, SPICE), conclumos que o modelo proposto
adequado ao NPI. O modelo ser aplicado na empresa jnior e ento melhorado,
como parte de um processo que ser realizado continuamente pelos prprios
membros da empresa.
Palavras-chave: modelo de processo, processo de software, empresa jnior.

ABSTRACT

This work consists of a design of a software development process model to be


used by the Junior Enterprise administrated by the Computer Science and
Information Systems students at the Federal University of Santa Catarina, Brazil. It
also includes an analysis of the current process and a development of an evaluation
plan (based on the GQM method), which will be executed while the model is in use.
The students of the referred courses are in charge of both the technical and the
administrative work at the Junior Enterprise. Because of that, NPI (Ncleo de
Projetos em Informtica, Information Technology Projects Center) has some aspects
of small companies (such as lack of experience in management and in systematic
software development) and others that are very particular of it's own (for instance,
high turnover of directors and developers). These aspects have a great influence on
the existence of low quality processes and products. Based on literature, we believe
the utilization of a software development process model will help improve the quality
of NPI's software and therefore, will contribute to the solution of some of the
problems described. The process model presented herein is based on the existing

process at NPI and the junior enterprise's requirements for an ideal development
process. It comprises all the phases of a typical NPI software project, containing both
technical and managerial kinds of activities. When comparing the resulting model
with other process models developed for other companies or with assessment
models (such as CMM, SPICE, etc), we can conclude that our model is adequate for
NPI. The process model will be used by the Junior Enterprise and then improved, as
part of a continuous process executed by NPI's members.
Key-words: process model, software process, junior enterprise

LISTA DE FIGURAS

Figura 1:

Organograma do NPI

23

Figura 2:

Extrato de um exemplo de esquema do banco de dados

33

Figura 3:

Exemplo de diagrama de casos de uso

33

Figura 4:

Extrato de um exemplo de modelo conceitual

34

Figura 5:

Exemplo de diagrama de seqncia, para um caso de uso

34

Figura 6:

Exemplo de diagrama de colaborao para uma operao de


sistema

35

Figura 7:

Extrato de um exemplo de diagrama de classes

35

Figura 8:

Exemplo de diagrama de Atividades

36

Figura 9:

Extrato de um exemplo de documento de acompanhamento do


desenvolvimento

43

Figura 10:

Modelo de ciclo de vida atual do NPI

45

Figura 11:

Modelo de ciclo de vida code-and-fix

56

Figura 12:

Modelo de ciclo de vida cascata

57

Figura 13:

Modelo de ciclo de vida em V

58

Figura 14:

Modelo de ciclo de vida desenvolvimento incremental

59

Figura 15:

Modelo de ciclo de vida em espiral

60

Figura 16:

reas-chave do CMM agrupadas por nvel

66

Figura 17:

Estrutura do CMM

67

Figura 18:

Exemplo de um perfil definido pelo SPICE

70

Figura 19:

reas de processo abordadas pelo PSP e o TSP

75

Figura 20:

Relao do PSP e do TSP com o CMM

75

Figura 21:

Modelo de Ciclo de Vida proposto

94

LISTA DE QUADROS

Quadro 1

Partes de um documento de requisitos

29

Quadro 2

Fase de anlise de requisitos do processo atual do NPI

31

Quadro 3

Fase de modelagem do sistema do processo atual do NPI

38

Quadro 4

Fase de implementao do processo atual do NPI

40

Quadro 5

Resumo do processo atual do NPI

46

Quadro 6

Comparao dos requisitos do NPI com outros modelos

85

Quadro 7:

Resumo das fases do modelo

96

Quadro 8:

Explicao das caractersticas de uma fase

97

Quadro 9:

Fase de Requisitos

98

Quadro 10:

Detalhamento da atividade 1 da fase de Requisitos

100

Quadro 11:

Exemplos de informaes sobre o paralelismo das atividades

101

Quadro 12:

Documentos-padro e seus cdigos

102

Quadro 13:

Modelo do cabealho-padro

103

Quadro 14:

Exemplo de cabealho preenchido

104

Quadro 15:

Um exemplo de documento padro

105

Quadro 16:

Comparao dos requisitos do NPI com os modelos do captulo


4 e o modelo desenvolvido

107

Quadro 17:

Abstraction Sheet para a meta Qualidade

114

Quadro 18:

Exemplos de perguntas do Plano GQM

115

Quadro 19:

Plano de Mensurao

117

Quadro 20:

Um dos roteiros para entrevista

118

10

SUMRIO

1Introduo

13

1.1 Objetivos

15

1.2 Justificativa

15

1.3 Metodologia

18

1.4 Organizao do Trabalho

19

2 Contextualizao

21

2.1 NPI - Ncleo de Projetos em Informtica

21

2.2 Os Problemas do NPI

24

2.3 O Processo Existente

27

2.3.1 A anlise de requisitos

28

2.3.2 A modelagem do sistema

32

2.3.3 A implementao

38

2.3.4 Aspectos de gerncia e qualidade do processo

40

2.3.5 Discusso

43

2.4 Anlise das Necessidades do NPI

46

3 Conceitos Fundamentais

49

3.1 O que um Processo de Software?

49

3.2 Modelo de Processo de Software

51

3.3 Qualidade do Processo

52

11

3.4 Modelos de Ciclo de Vida

55

3.4.1 Exemplos de modelos

56

3.4.2 Discusso

60

3.5 Conceitos Complementares

61

4 Estado da Arte e Prtica

64

4.1 Viso Geral de Modelos de Avaliao de Processo

64

4.1.1 CMM - Capability Maturity Model

65

4.1.2. SPICE - Software Process Improvement and Capability determination 68


4.1.3 ISO 9000-3

71

4.1.4 PSP e TSP

74

4.2 Questes Humanas na Modelagem de Processos

76

4.3 Relatos de Experincias

80

4.4 Discusso

84

5 O Modelo de Processo desenvolvido para o NPI

89

5.1 A elaborao do Modelo de Processo do NPI

92

5.2 O Contedo do MPDS-NPI

96

5.3 Discusso

106

6 Avaliao do Modelo

111

6.1 O Plano da Avaliao

111

6.2 Execuo da Avaliao

119

7 Concluso

120

7.1 Benefcios para o NPI

121

12

7.2 Trabalhos Futuros

122

7.3 Consideraes Finais

123

8 Bibliografia

124

Apndice A - Artigo

128

Apndice B - Plano da Avaliao

135

13

1 Introduo

Uma empresa jnior tem como um de seus objetivos principais, colocar o aluno
em contato com o mercado de trabalho e com o dia-a-dia da profisso. Ela existe
como uma empresa real, com produtos e clientes reais; porm, legalmente, ela deve
atuar como uma associao sem fins lucrativos (semelhante a uma organizao
no-governamental).
O Ncleo de Projetos em Informtica (NPI), a empresa jnior dos cursos de
Cincias da Computao e Sistemas de Informao da Universidade Federal de
Santa Catarina (UFSC), composto apenas por alunos dos cursos citados, que
atuam como diretores ou estagirios. Os diretores tm, entre outras, a
responsabilidade pelo bom funcionamento da empresa jnior e pela boa qualidade
do software por ela produzido.

Por ser formado por alunos de graduao, o NPI possui cargos com mandatos
de curta durao, e seus diretores e estagirios tm pouca experincia (terica e
prtica) de desenvolvimento sistemtico de software comercial. Alm disso, ao
adquirirem experincia de desenvolvimento, os alunos esto chegando ao fim de
seus mandatos na diretoria ou se formando - e levam com eles a experincia
adquirida, o que prejudica a qualidade e a produtividade da empresa jnior.
Uma soluo para esses problemas pode ser o desenvolvimento de um
modelo de processo de software para o NPI.

14

O desenvolvimento de um software pode ser feito utilizando-se vrias


metodologias, inclusive a de um processo ad-hoc. Como ser explicado mais
adiante, a qualidade de um software est fortemente associada com o nvel de
organizao do processo utilizado para desenvolv-lo.
O processo de software constitui-se de vrias tarefas, que podem ou no ser
executadas simultaneamente: desenvolvimento (anlise, projeto, implementao e
testes), manuteno, gerncia de configurao, entre outras.
Um modelo de processo de software pode ser concretizado, entre outras
formas, atravs de um manual. Nele, consta o que deve ser feito em cada fase do
processo citada anteriormente.
O trabalho aqui apresentado limita-se criao de um modelo de processo de
desenvolvimento de software, ou seja, o modelo servir apenas para a tarefa de
desenvolvimento - e no, por exemplo, para a de manuteno.
O modelo desenvolvido neste trabalho ser aplicado ao NPI e avaliado em
relao sua contribuio para a administrao dessa empresa jnior.

15

1.1 Objetivos

O objetivo principal deste trabalho desenvolver e aplicar um modelo de


processo de desenvolvimento de software ao NPI.
Entre os objetivos mais especficos do trabalho, destacam-se:
*

Estudar modelos de processo de software: suas caractersticas e como aplic-los.

Desenvolver um modelo de processo de desenvolvimento de software para o


NPI.

Aplicar o modelo no NPI em, pelo menos, um projeto.

Avaliar o modelo de processo de desenvolvimento de software no NPI


comparando a situao antes e depois da aplicao do modelo.

1.2 Justificativa

Como explicado anteriormente, o NPI formado apenas por alunos do


Departamento de Informtica e Estatstica (INE) da UFSC, que podem participar
como diretores ou como estagirios. Aos diretores cabe administrar a empresa,
entrar em contato com os clientes, e outras tarefas. Os estagirios, por sua vez,
desenvolvem os sistemas que a empresa comercializa. Para cada projeto, os
diretores devem selecionar alguns associados para atuarem como desenvolvedores
naquele projeto. Alm disso, de acordo com o estatuto do NPI

(NCLEO DE

16

PROJETOS EM INFORMTICA 1996), deve haver uma eleio para diretoria a


cada um ano. Dessa maneira, pode-se perceber que h uma alta rotatividade de
desenvolvedores e diretores nessa empresa jnior. Como nos dois cursos (Cincias
da Computao e Sistemas de Informao), a disciplina de Engenharia de Software
(ES) ministrada somente na 4 a ou 6a fase, a maioria dos desenvolvedores - e
eventualmente os diretores - no sabe como desenvolver sistematicamente um
sistema comercial e no tem experincia prtica na rea. Por causa dessa
inexperincia, os alunos tambm tm dificuldades de entender a necessidade do
uso de tcnicas de ES durante o desenvolvimento de um sistema. Alm disso, ao
adquirirem experincia no processo de desenvolvimento de software, geralmente os
alunos esto no final de seu mandato como diretores e esto se formando, ou seja,
a experincia no "permanece" no NPI.
Segundo KEHOE e JARVIS (1996) e PAULK et al. (1993), os produtos de uma
empresa que no possui um bom gerenciamento do seu processo de software
certamente sero de pior qualidade do que os de uma empresa que possui um
processo bem gerenciado e definido - onde qualidade vista como a capacidade de
produzir sistemas que vo ao encontro dos requisitos do cliente dentro dos prazos e
custos estabelecidos no incio do projeto. esse conceito de qualidade que os
certificados ISO e CMM asseguram quando so emitidos para uma empresa de
software. Portanto, pode-se perceber que os fatores citados anteriormente (alta
rotatividade, tanto dos desenvolvedores quanto da diretoria; inexperincia dos
mesmos; dificuldade dos desenvolvedores e diretores de entender a necessidade do
uso de tcnicas de ES no desenvolvimento de software; experincia de
desenvolvimento permanecer com

os alunos e no com a empresa jnior)

prejudicam a qualidade e a produtividade do NPI.

17

Ainda, um dos benefcios de se ter um modelo a seguir durante o processo de


produo de software que esse processo fica independente das pessoas que
esto produzindo o software, ou seja, segue-se um manual, com passos definidos, e
no as idias de uma ou outra pessoa. Assim, quando mudar o quadro de
funcionrios de uma empresa, ela pode continuar produzindo software de qualidade,
pois o manual permanece com a empresa. Essa afirmao leva a crer que um
manual de processo de software se encaixa perfeitamente na soluo dos
problemas do NPI.

Os modelos de avaliao do processo de software especificam as


caractersticas que um modelo de processo de software deve possuir para ser
considerado um modelo de qualidade. Os modelos de avaliao do processo de
software so muito mais conhecidos e divulgados do que os modelos de processo
de software em si, os quais geralmente no so publicados por possurem dados
confidenciais das empresas. Existem vrios modelos de avaliao do processo de
software propostos atualmente, mas a maioria deles (como CMM e ISO) voltada
para grandes empresas. H na literatura, uma carncia de modelos de avaliao do
processo de software para micro e pequenas empresas. Essa carncia ainda
maior para modelos de processo de software.
Alm disso, um modelo de processo de software depende das caractersticas
da empresa na qual ele ser utilizado, como por exemplo, nmero de funcionrios, o
tipo de software que desenvolvido, entre outras. Por isso, mesmo que existam
modelos de processo prontos, elaborados para outras empresas (como o proposto

18

por WEBER, 2002) ou para servir como exemplo, um modelo de processo de


software deve ser adaptado empresa na qual ele ser usado.
Assim, acredita-se que um modelo de processo de desenvolvimento de
software, elaborado especificamente para o NPI pode melhorar a sua qualidade e
produtividade.

1.3 Metodologia

Para a realizao deste trabalho, utiliza-se a seguinte metodologia.


feita uma pesquisa bibliogrfica sobre modelos de processo de software e
seu desenvolvimento e tambm so estudados alguns exemplos de modelos de
processo j existentes. Em paralelo, realizado um estudo do processo de
desenvolvimento de software do NPI, analisando como esto sendo desenvolvidos
os produtos atualmente e analisando os requisitos, necessidades e limitaes
existentes no NPI em relao a um modelo de processo. ento desenvolvido um
modelo para o NPI, com base no processo existente na empresa e nos padres de
qualidade e best practices, e adaptado especificamente ao NPI. Ainda, so previstas
as seguintes atividades: utilizao do modelo em no mnimo um projeto de software
no NPI; avaliao (durante o uso do modelo) em relao sua aplicabilidade e aos
seus custos e benefcios; e melhora do modelo com base nos resultados obtidos
nessa avaliao.

19

1.4 Organizao do Trabalho

O presente trabalho est organizado em sete captulos.


O captulo seguinte apresenta um estudo do processo de desenvolvimento de
software do NPI, analisando como esto sendo desenvolvidos os produtos
atualmente e analisando os requisitos, necessidades e limitaes existentes no NPI
em relao a um modelo de processo.
O captulo 3 apresenta conceitos bsicos utilizados no decorrer do trabalho. Os
conceitos so principalmente das reas de Engenharia de Software e Modelagem
de Processo. Alguns conceitos so utilizados uniformemente na literatura com o
mesmo nome, mas para outros, ainda no h um consenso (diferentes autores
atribuem nomes diferentes a conceitos semelhantes). O objetivo do captulo trs
esclarecer com que significados sero utilizados quais termos no presente trabalho.
No captulo 4 so apresentados alguns modelos de avaliao de processo e
alguns relatos de experincias de desenvolvimento de modelos de processo de
software.
O modelo de processo desenvolvido para o NPI apresentado brevemente no
quinto captulo. So explicadas suas caractersticas principais, uma sntese do seu
contudo e as etapas da sua elaborao . Tambm so apresentados vrios
exemplos que ilustram o seu contedo: uma das fases do modelo, um dos
documentos-padro, entre outros. Ao final do captulo, feita uma comparao do
modelo apresentado neste trabalho com os modelos discutidos no captulo 4, em
relao aos requisitos do NPI (descritos no captulo 2).

20

O sexto captulo contm uma breve descrio do plano de avaliao e de como


ele deve ser executado.
Finalmente, o trabalho concludo mostrando-se os benefcios do modelo para
o NPI e o que ainda necessrio para que o NPI possua um modelo de processo de
software completamente adaptado sua realidade e s suas necessidades.

21

2 Contextualizao

Neste captulo sero apresentadas mais informaes sobre o foco do trabalho,


o Ncleo de Projetos em Informtica - a empresa jnior dos cursos de Cincias da
Computao e Sistemas de Informao da UFSC. Adicionalmente, ser analisado o
processo de desenvolvimento de software existente nessa empresa jnior e suas
falhas. Finalmente, concluir-se- sobre as necessidades atuais do NPI em relao a
um processo de desenvolvimento de software.

2.1 NPI - Ncleo de Projetos em Informtica

O NPI foi fundado em 5 de Dezembro de 1996 por alunos do Curso de


Cincias da Computao da Universidade Federal de Santa Catarina. Seus
objetivos principais so "a motivao de um esprito empreendedor no aluno de
computao e a introduo do estudante no mercado de trabalho atravs de
prestaes de servios a instituies, micro e pequenas empresas."(NCLEO DE
PROJETOS EM INFORMTICA 2002).

22

Legalmente, uma empresa jnior funciona como uma associao sem fins
lucrativos, devendo vender seus produtos e servios a preo de custo. O estatuto e
o regimento interno da empresa governam seu funcionamento. Seus objetivos so
dar oportunidade aos alunos de por em prtica os conhecimentos tericos
adquiridos nas disciplinas do curso, incentivar o empreendedorismo nos estudantes,
coloc-los em contato com a realidade da profisso e valorizar (tanto no mercado
quanto no ambiente acadmico) os alunos, a empresa jnior e a universidade.

Conforme o seu estatuto (NCLEO DE PROJETOS EM INFORMTICA 1996),


o NPI formado por uma Diretoria Executiva e um Conselho de Administrao. O
organograma da Diretoria Executiva composto dos seguintes cargos (ilustrados na
Figura 1): Diretor Presidente, Diretor Administrativo-Financeiro e um Assessor
Administrativo-Financeiro, Diretor de Projetos e dois Assessores de Projetos, Diretor
de Recursos Humanos e um Assessor de Recursos Humanos e Diretor de Marketing
e um Assessor de Marketing. A diretoria deve ser composta por alunos associados e
o conselho pode ser formado por alunos associados, professores do departamento e
outras pessoas que possam contribuir para o NPI. feita uma eleio para esses
cargos, a cada um ano. Os associados que no fazem parte da diretoria nem do
conselho, podem participar como desenvolvedores nos projetos do NPI. Todos os
associados tm direito de votar na eleio.

23

Figura 1: Organograma do NPI


(NCLEO DE PROJETOS EM INFORMTICA 2002)
A diretoria deve administrar a empresa jnior, executando tarefas que dem
suporte realizao de projetos, como marketing, gesto financeira, de recursos
humanos e de projetos. O conselho deve examinar e aprovar as aes significativas
da diretoria, como oramentos, relatrios de atividades e demonstraes
financeiras.

O NPI uma empresa que vende software e servios de informtica. Seus


clientes so instituies dentro da prpria UFSC, empresas do mesmo e de outros
ramos e at mesmo pessoas fsicas.

Os projetos realizados pelo NPI foram principalmente nas reas de


Desenvolvimento de Software, Treinamento e Banco de Dados. Alm desses, o NPI

24

j realizou projetos nas reas de Redes de Computadores e Desenvolvimento para


Web. Atualmente, o NPI realiza projetos nas reas de Banco de Dados e
Desenvolvimento e Manuteno de Software.

O funcionamento do NPI, em relao realizao de um projeto, ocorre da


seguinte maneira: um cliente entra em contato com o NPI, solicitando um
desenvolvimento ou outro servio; o NPI avalia o pedido do cliente; se ele for de
interesse da empresa jnior, so ento selecionados associados para atuar no
projeto; a partir da, negociado um contrato com o cliente; quando chega-se a um
acordo,

contrato

fechado

d-se

incio

prestao

do

servio

(desenvolvimento, por exemplo).

2.2 Os Problemas do NPI

Atualmente, o NPI desenvolve sistemas com sucesso. Entretanto, existem


algumas deficincias graves no seu processo de desenvolvimento. Entre elas,
podese citar:

*Alta rotatividade de pessoal. Como explicado anteriormente, o NPI formado por


alunos dos cursos de graduao em Cincias da Computao e Sistemas de
Informao, cuja durao mdia de 4 anos; assim, os alunos raramente
permanecem mais do que dois anos envolvidos com o NPI.

25

*
Pouco conhecimento e experincia (principalmente prtica) de desenvolvimento
de software de acordo com os princpios da ES. Isso ocorre porque os alunos
s entram em contato com essa rea na metade do curso (a disciplina de
Engenharia de Software ministrada na 4 a fase para o curso de Sistemas de
Informao e na 6a fase para o curso de Cincias da Computao) e esse
contato essencialmente terico.

*Falta de comprometimento e de conscientizao da necessidade de utilizao de


tcnicas de ES em desenvolvimento de sistemas. Pelo mesmo motivo explicado
acima, h uma certa dificuldade dos alunos em entender a necessidade de
utilizao de tcnicas de ES quando eles passaram metade do curso
desenvolvendo software com sucesso sem o uso dessas tcnicas; alm disso,
mesmo quando os alunos se conscientizam dessa necessidade, existe a
dificuldade de manter o compromisso de produzir documentao e realizar outras
atividades de ES quando o desenvolvimento atrasa ou o cliente aguarda
ansiosamente um prottipo.

*Perda das experincias adquiridas em desenvolvimentos anteriores. Por causa da


falta de um processo definido e pela baixa produo de documentao, as
dificuldades, os resultados, os obstculos superados e outras informaes ficam
apenas na memria dos alunos que participaram do projeto; quando esses alunos
deixam o NPI, essa informao torna-se inalcanvel.

26

*
Falta de um processo definido para o desenvolvimento de software. Cada
desenvolvimento realizado de uma maneira diferente e sem etapas
claramente definidas.

*Definio precria de papis. Os papis determinam atividades a serem


realizadas durante o desenvolvimento (por exemplo, o testador deve testar o
software); mas como as etapas e atividades so mal definidas, os papis tambm
ficam mal definidos.

*Acmulo de funes para o Diretor de Projetos. Pela falta de gerenciamento dos


recursos humanos, h uma carncia de gerentes de projeto no NPI, assim, o
diretor de projetos acaba assumindo esse papel. Tambm, pela inexperincia dos
desenvolvedores na rea, o diretor de projetos acaba assumindo o papel de
analista de requisitos.

*M administrao de recursos humanos. Devido a um grande desconhecimento


e desinteresse dos alunos de Cincias da Computao e Sistemas de Informao
pelo NPI e a falta de experincia da diretoria em administrao de recursos
humanos, o corpo gerencial do NPI deficiente, isto , faltam pessoas para
trabalhar como gerentes de projeto, entre outros papis.

*Mal gerenciamento do desenvolvimento, conseqncia do acmulo de tarefas


para o Diretor de Projetos e da sua inexperincia em gerncia - um dos principais
problemas de toda a diretoria do NPI.

27

*
Escassez de recursos financeiros. Leva utilizao de ferramentas gratuitas
(que uma soluo bastante comum tambm em micro e pequenas
empresas).

*Ambiente de desenvolvimento heterogneo. Em conseqncia do problema


financeiro mencionado acima, o NPI no possui recursos computacionais
disponveis para os desenvolvedores. Por causa disso, eles so obrigados a
utilizar seus prprios computadores ou os computadores dos laboratrios de
informtica da universidade. Assim, no se pode prever em qual ambiente ser
realizado o processo de desenvolvimento do software. Neste caso - quando
existe um ambiente computacional heterogneo (i.e. com diferentes hardwares,
sistemas operacionais, e etc.) - recomendado o uso de ferramentas
multiplataforma.

2.3 O Processo Existente

NPI

no

possui

um

processo

claramente

definido

para

seu

desenvolvimento de software. Assim, para entender o processo existente, foi


efetuada a anlise de dois projetos em andamento (sendo que um estava em
concluso e o outro estava em seu incio) - foram realizadas entrevistas informais

28

*
com o diretor e os desenvolvedores dos dois projetos e foram examinados os
artefatos produzidos durante o desenvolvimento.

29

Aps a investigao, pode-se inferir que o processo do NPI constitui


basicamente de trs fases: anlise de requisitos, modelagem do sistema e
implementao.

O incio de um projeto no NPI ocorre quando o cliente faz um contato


(normalmente atravs de telefone ou e-mail), solicitando um desenvolvimento.

2.3.1 A anlise de requisitos

Depois do contato mencionado acima, realizada uma reunio com o cliente e


o NPI (representado pelo Diretor de Projetos e mais um ou dois diretores). Em
seguida, o diretor de projetos produz um documento de requisitos - cuja aprovao
faz parte da negociao do contrato com o cliente, realizada em reunies
subseqentes. Para a produo do documento de requisitos, o diretor de projetos
utiliza a seguinte metodologia: descrever o sistema existente em um documento e as
necessidades do cliente do em outro, juntar esses dois documentos e identificar os
mdulos do sistema. A partir desses trs documentos, gerar o documento de
requisitos. Ao final do processo, porm, esses trs documentos so descartados e s
mantido o documento de requisitos. No Quadro 1, so mostradas partes do
documento de requisitos do primeiro projeto.

1. Requisitos Gerais - Mdulos do Sistema


ID

Descrio

30

...
O sistema deve ter um mdulo de Cadastro de Tipo de Tarefa. Esse
tipo de tarefa uma descrio resumida de cada espcie de tarefa.
O sistema deve ter um mdulo de Cadastro de Tarefas. Nesse
R.1.6 cadastro, sero armazenados todas as atividades realizadas por
desenvolvedores do projeto.
...
R.1.5

2. Requisitos Gerais - Funes Gerais por Mdulo


ID

Descrio

R.2.1 Cada mdulo deve gerar relatrios.


Cada mdulo deve automaticamente importar dados do MS-Project, e
R.2.2 deve tambm atualizar o MS-Project toda vez que algum dado seja
criado ou alterado.
...
...
4. Requisitos - Cadastros
ID

Descrio

Cadastro de Clientes : Cadastra o Nome do Cliente, Cdigo,


R.4.1 Endereo, Cidade, Estado, CEP, Pas, Nome do Contato na Empresa,
Fone, Fax, E-mail, Site e Informaes Adicionais.
Cadastro de Projetos : Nome do Projeto, Cdigo, Tipo de Projeto
R.4.2
(FK)
...
5. Requisitos - Relatrios
ID

Descrio
Os tipos de Relatrios que o Sistema deve ter so: impresso da
tabela atual, imprimir atividades, tarefas, projetos feitos hoje, ontem, a
R.5.1
uma semana, a um ms, a um dia especfico, a uma semana ou a um
intervalo de tempo especfico.
...
Itens de cabealho e rodap - nmero de pg inas, data, horas,
R.5.3 nmero da pgina. A formatao (inclusive para o ttulo e para todo o
programa) deve ser configurvel (bold, itlico, centralizado, etc).
...
Quadro 1: Partes de um documento de requisitos

31

produzido tambm, um arquivo contendo as dvidas do diretor em relao


aos requisitos do sistema, as quais so sanadas na reunio seguinte com o cliente, e
ento o arquivo atualizado (coloca-se a resposta abaixo da dvida). Esse arquivo
s foi produzido para o segundo projeto.

Para a produo desses dois artefatos, utilizado como ferramenta o programa


Word. O diretor afirmou que esses artefatos deveriam ser produzidos por um gerente
do projeto ou desenvolvedor analista, mas devido falta de recursos humanos, o
Diretor de Projetos assumiu esses papis.

O Quadro 2, mostra o processo de anlise de requisitos em detalhes:

32

Objetivos

Descrever os requisitos do sistema.


Negociar com o cliente a proposta de projeto e o contrato.
Selecionar desenvolvedores para atuar no projeto.

Atividades tcnicas

2 - Gerente do projeto faz reunio com o cliente para


levantar requisitos.
3a - Gerente do projeto elabora o documento de
requisitos (1.1) e a proposta de projeto (1.2) e negocia-os
com o cliente, tambm elabora o arquivo de dvidas (1.4)
e esclarece-as com o cliente.
1 - Diretor de projetos define gerente do projeto
(normalmente o prprio diretor de projetos o gerente).
3b - Gerente do projeto e diretor de RH selecionam
desenvolvedores.
3c - Gerente do projeto elabora um plano de
desenvolvimento, contendo o cronograma (1.5) do
desenvolvimento.
4 - Diretor administrativo-financeiro elabora os contratos
(1.3) e providencia a nota fiscal.
Diretor de projetos supervisiona o gerente do projeto.
Gerente do projeto atualiza continuamente o seu
documento de acompanhamento do trabalho (1.6) e o dos
desenvolvedores (1.7).
Gerente do projeto
Diretor de projetos
Diretor de RH
Diretor administrativo-financeiro
- Identificar requisitos:
* descrever o sistema existente e as
necessidades do cliente em
documentos separados ("Descrio
dos Sistemas da Empresa" e
"Descrio de Necessidades do
Cliente")
* juntar tudo e a partir disso encontrar
os mdulos do sistema
* formalizar esses trs documentos
num documento de requisitos (1.1)
numerando-os
MS-Word
MS-Excel
MS-Project
1.1 - documento de requisitos
1.2 - proposta de projeto
1.3 - contratos (NPI-Cliente e NPI-Desenvolvedores)
1.4 - arquivo de dvidas

Atividades
administrativas

Papis

Tcnicas/metodologias

Ferramentas

Artefatos produzidos

33

1.5 - cronograma

Critrios de entrada
Critrios de sada

1.6 - documento de acompanhamento do trabalho do


gerente
1.7 - documento de acompanhamento do trabalho dos
desenvolvedores
Contato (telefone ou e-mail) de um possvel cliente com o
NPI.
Documento de requisitos (1.1) informalmente aprovado
pelo cliente.

Quadro 2: Fase de anlise de requisitos do processo atual do NPI

2.3.2 A modelagem do sistema

Durante a fase de modelagem, a anlise do sistema e o projeto do sistema so


feitos em paralelo, sem distino entre essas etapas, e sem um procedimento
definido. Essa fase tambm realizada somente pelo diretor de projetos. A
documentao feita utilizando-se a notao da Unified Modeling Language (UML,
ou Linguagem de Modelagem Unificada) e a modelagem Entidade-Relacionamento.
O nico critrio para o incio dessa etapa, a especificao de requisitos
informalmente aprovada pelo cliente. A partir dela, so gerados artefatos como
esquema do banco de dados (Figura 2), diagrama de casos de uso (Figura 3),
diagramas de atividades - um para cada caso de uso - (Figura 8), diagrama de
classes (Figura 7), diagramas de seqncia para cada caso de uso (Figura 5),
diagramas de colaborao para cada operao do sistema (Figura 6) e modelo
conceitual (Figura 4). Esses artefatos no so gerados em uma seqncia definida,

34

porm,

so

aperfeioados

continuamente,

mesmo

depois

do

inicio

implementao.

Figura 2: Extrato de um exemplo de esquema do banco de dados

Figura 3: Exemplo de diagrama de casos de uso

da

35

Figura 4: Extrato de um exemplo de modelo conceitual

Figura 5: Exemplo de diagrama de seqncia, para um caso de uso

36

Figura 6: Exemplo de diagrama de colaborao para uma operao de sistema

Figura 7: Extrato de um exemplo de diagrama de classes

37

Figura 8: Exemplo de diagrama de Atividades

Para a produo do esquema do banco de dados, utilizada a ferramenta


ERWin e para os diagramas UML, a ferramenta Rational Rose.

Para o primeiro projeto, no foi utilizada nenhuma metodologia. Apenas


visualizou-se um projeto de alto nvel da arquitetura do sistema, que no ficou
documentado; e foi produzido o esquema do banco de dados. A partir desses
artefatos e do documento de requisitos foi implementado o sistema. Essa estratgia
foi satisfatria porque o sistema desenvolvido era de baixa complexidade.

38

No

segundo

projeto,

foi

utilizada

apenas

seguinte

metodologia

(documentada), para os casos de uso: fazer um esboo da interface com o usurio, e


a partir dela, identificar os casos de uso. Nesse projeto, foram produzidos todos os
artefatos citados e mostrados anteriormente nas figuras, para o primeiro caso de
uso. Ao longo dessa produo, decidiu-se no utilizar a orientao a objetos pura e
nem realizar a produo desses artefatos para os outros casos de uso, por falta de
tempo e de recursos humanos. Assim, foram mantidos somente o diagrama dos
casos de uso e o diagrama de atividades daquele caso de uso; os outros diagramas
foram desconsiderados (mas no removidos, do arquivo do projeto no Rational
Rose). A partir de ento, foram somente produzidos diagramas de atividade para os
outros casos de uso.

O Quadro 3, mostra um resumo do processo de modelagem do sistema.

Objetivos
Atividades tcnicas

Atividades
administrativas
Papis
Tcnicas/metodologias
Ferramentas

Realizar a anlise do sistema e o projeto do sistema.


Gerente do projeto elabora o esquema do banco de
dados (2.1).
Gerente do projeto identifica casos de uso, faz o
diagrama de casos de uso (2.2) e os diagramas de
atividade de cada caso de uso (2.3).
Gerente atualiza continuamente o documento de
acompanhamento do seu trabalho (1.6).
Diretor de projetos supervisiona o gerente do projeto.
Gerente do projeto Diretor
de projetos
Identificar casos de uso: fazer esboo da interface
com usurio e a partir dela levantar os casos de uso.
UML
Rational Rose ERWin

39

Artefatos produzidos

Critrios de entrada
Critrios de sada

2.1 - esquema do banco de dados


2.2 - diagrama de casos de uso
2.3 - diagramas de atividade para cada caso de uso
2.4 - diagrama de classes
2.5 - diagramas de seqncia para cada caso de uso 2.6
- diagramas de colaborao para cada operao do
sistema
2.7 - modelo conceitual
Documento de requisitos (1.1) informalmente aprovado
pelo cliente.
Esquema do banco de dados (2.1) pronto.

Quadro 3: Fase de modelagem do sistema do processo atual do NPI

2.3.3 A implementao

Na fase de implementao, o sistema produzido em estgios incrementais e


evolucionrios. Em cada estgio implementado um (ou parte de um) mdulo. O
critrio de incio dessa fase o esquema do banco de dados e o diagrama de
atividades do caso de uso atual (esse, utilizado somente no segundo projeto). O
sistema baseado nos casos de uso e no modelo do banco de dados. Por exemplo,
para um determinado caso de uso, h uma interface com o usurio, que tambm
interage com o banco de dados. Os mdulos so implementados em ordem
crescente de dependncia, ou seja, os mdulos que so menos dependentes dos
outros so implementados primeiro. Nessa fase, os desenvolvedores produzem o
cdigo e o diretor de projetos verifica seu trabalho. Os desenvolvedores tentaram
seguir um padro de comentrios mas desistiram por falta de tempo e cobrana do
diretor. Os nicos padres existentes so de indentao e nome de variveis. Nos
dois projetos, foi utilizada a linguagem de programao Object Pascal, presente na

40

ferramenta Borland Delphi, e para o banco de dados, foi utilizado o PostgreeSQL


(principalmente por ser uma ferramenta gratuita). Tambm foi explicado, que a
utilizao de um banco de dados entidade-relacionamento, apesar do sistema ser
parcialmente orientado a objetos, se deve por que esse era o nico tipo de banco de
dados com o qual o diretor estava familiarizado.

No fim de cada estgio, so feitos testes informais, realizados pelos prprios


desenvolvedores. Os desenvolvedores e o diretor afirmaram que no so planejados
nem preparados testes formais, por falta de experincia deles na rea,
desconhecimento de metodologias de teste e pouca abordagem na literatura sobre o
assunto.

Ao final dessa fase, tem-se o cdigo executvel e as tabelas do banco de


dados completas.
No Quadro 4, est o resumo da fase de implementao do processo atual do
NPI.

Objetivos
Atividades tcnicas

Atividades
administrativas

Papis
Tcnicas/metodologi
as

Escrever o cdigo, baseado no esquema do banco de


dados e dos diagramas de atividades dos casos de uso.
1
- Desenvolvedores escrevem o cdigo.
2
- Desenvolvedores realizam testes informais sobre o
cdigo.
Gerente do projeto supervisiona os desenvolvedores.
Diretor de projetos supervisiona o gerente do projeto.
Desenvolvedores e gerente atualizam os seus documentos
de acompanhamento do trabalho (1.6 e 1.7).
Gerente do projeto Desenvolvedor
Implementar os mdulos em ordem crescente de
dependncia.
Seguir um padro de indentao e de nome de
variveis.

41

Ferramentas
Artefatos produzidos
Critrios de entrada

Critrios de sada

PostgreeSQL Borland
Delphi
3.1 - cdigo
3.2 - tabelas do banco de dados
Esquema do banco de dados (2.1) pronto.
Diagrama de atividades (2.3) do caso de uso atual
(opcional) Terminado.
Cdigo executvel (3.1).
Banco de dados com as tabelas (3.2).

Quadro 4: Fase de implementao do processo atual do NPI

2.3.4 Aspectos de gerncia e qualidade do processo

Em paralelo com a analise de requisitos, so elaborados os contratos legais


(do NPI com o cliente e do NPI com os desenvolvedores), um cronograma e a
Proposta de Projeto. Para o primeiro projeto ainda no havia sido elaborado um
contrato com os desenvolvedores e o cronograma, depois de elaborado, no foi
atualizado. No segundo projeto, o desenvolvimento havia iniciado antes do
cronograma e dos contratos estarem prontos.

A Proposta de Projeto um documento que, juntamente com o contrato,


negociado com o cliente. H no NPI arquivos padro de contrato e de Proposta de
Projeto (entre outros documentos) que so alterados conforme as necessidades de
cada projeto. A Proposta de Projeto possui os seguintes itens:
*

Breve descrio dos objetivos do software.

Modo como ser realizado o acompanhamento do desenvolvimento pelo cliente


(normalmente com relatrios quinzenais e prottipos mensais).

42

Prazo de entrega do produto.

Servios includos no contrato (normalmente desenvolvimento, implantao,


documentao para o usurio e treinamento).

Garantia do software (normalmente de trs meses).

Vigncia da Proposta de Projeto (normalmente de trinta dias).

Cronograma financeiro - o pagamento normalmente dividido em parcelas com um valor adicional opcional para o cdigo fonte.

Anexos opcionais (documento de requisitos e glossrio).

Ainda em relao gerncia do processo, para o primeiro projeto, havia sido


feito um plano de desenvolvimento, contendo o cronograma. Nesse plano, o
desenvolvimento era dividido em trs ciclos, com atividades e prazos bem definidos
para cada um. Mas, por inexperincia do diretor, as estimativas de tempo foram mal
formuladas (no se sabia quanto tempo iria levar cada etapa do trabalho e elas
acabaram levando mais tempo do que o previsto) e ento o plano foi abandonado. A
partir da, foram feitos apenas acompanhamentos semanais do diretor, verificando o
resultado do trabalho dos desenvolvedores.

Por causa disso, os desenvolvedores estavam trabalhando horas a mais do que


o cobrado para tentar terminar o software com apenas uma semana de atraso.

Apesar dos fatos explicados, os desenvolvedores e o diretor afirmaram que o


cliente estava ficando satisfeito com os prottipos que vinham sendo apresentados.
Essa afirmao foi aceita como verdadeira, pois o cliente estava negociando com o
NPI, o desenvolvimento de mais dois softwares.

43

Para o segundo projeto, no foi feito um plano de desenvolvimento.

Em paralelo com as fases de anlise de requisitos e modelagem do sistema


feita a seleo dos desenvolvedores que iro trabalhar no projeto. Essa etapa
realizada, normalmente, pelo diretor de projetos e o diretor de recursos humanos em
conjunto. So feitas entrevistas com os associados do NPI interessados no projeto, e
em seguida, os dois diretores decidem quais dos associados sero escolhidos.

Em relao ao segundo projeto, foi produzido (e estava sendo atualizado) um


documento (Figura 9) com o acompanhamento do trabalho do gerente (que no
segundo projeto tambm estava atuando como desenvolvedor), contendo o horrio
de incio e fim de cada perodo de trabalho e o que foi produzido naquele perodo.
Porm, no estava sendo produzido um documento equivalente para acompanhar o
trabalho do outro desenvolvedor, por inexperincia do desenvolvedor, e falta de
cobrana do diretor. Para o primeiro projeto, foram produzidos documentos de
acompanhamento semelhantes ao explicado para os dois desenvolvedores e para o
gerente, mas esses documentos no foram atualizados at o fim do projeto por falta
de tempo.

44

Figura 9: Extrato de um exemplo de documento de acompanhamento do


desenvolvimento
Tambm em aspectos de qualidade, os desenvolvedores afirmaram que o
cdigo desenvolvido possui pouca reusabilidade.

2.3.5 Discusso

Com base nessa anlise, conclui-se que no existe no NPI um processo


padro de desenvolvimento de software. Apesar disso, uma das concluses a que se
pode chegar que o processo realizado na fase de anlise de requisitos eficiente e
adequado ao contexto do NPI, com exceo da transio entre as fases, que um
pouco nebulosa - pois a fase de modelagem iniciada antes que sejam completados
todos os produtos necessrios para finalizar a fase de anlise de requisitos.
Entretanto, a fase de modelagem bastante aleatria. Os documentos produzidos

45

nem sempre so aproveitados, os que so aproveitados no so suficientes para


traduzir o projeto em cdigo, a produo dos documentos desordenada, e
novamente, a transio entre essa fase e a prxima, um pouco nebulosa (pois, s
vezes, as duas fases ocorrem em paralelo). Alm disso, a arquitetura do sistema
probe qualquer tentativa de reusabilidade. Porm, importante ressaltar que toda
essa aleatoriedade conseqncia de um esforo por parte do diretor de projetos de
melhorar o processo de desenvolvimento atravs de um mtodo informal de
"tentativa e erro". A implementao bastante eficiente, porm inconsistente com a
modelagem (pois os diagramas de atividades no se traduzem diretamente em
cdigo). Apesar disso, tambm se nota um esforo por parte dos desenvolvedores de
adotar algum tipo de sistematizao do processo, como por exemplo padres de
indentao e de nomes de variveis. A fase de testes a mais carente em termos de
metodologia, pois no h um planejamento dos testes e nem o correspondente
cumprimento desses planos de uma maneira sistematizada. So realizados apenas
testes informais, o que considerado ineficaz pela literatura (SILVA, 2002). Porm,
tambm deve ser ressaltado que h um interesse dos desenvolvedores e
principalmente do diretor, em seguir uma metodologia de testes.
O ciclo de vida do software desenvolvido no NPI, no um processo com a
separao clara das atividades de cada fase. Porm, em geral, pode ser identificada
a seguinte seqncia de fases: anlise de requisitos; modelagem do sistema;
implementao e testes informais do primeiro mdulo; implementao e testes
informais do segundo mdulo; e assim por diante, at o ltimo mdulo; entrega para
o cliente. Assim, pode-se dizer que o modelo de ciclo de vida atual do NPI uma
mistura de cascata com iteratividade na implementao e teste de mdulos. A Figura
10, ilustra essa concluso:

46

Figura 10: Modelo de ciclo de vida atual do NPI

Em

relao

documentao

produzida

durante

processo

de

desenvolvimento, tambm se pde perceber que no h nenhuma sistematizao


quanto ao uso de ferramentas independentes de plataforma. Em termos de
administrao, constata-se que h uma falha geral em todas as fases nos processos
de gerncia de configurao, controle de documentos e superviso administrativa.
Isso conseqncia de uma grande falta de experincia em exerccio de cargos
administrativos, o que constatado tanto na diretoria de projetos como nas outras
diretorias do NPI.

O Quadro 5, resume o processo existente no NPI, em termos da qualificao


dos documentos produzidos.

Fase
Anlise de
Requisitos

Modelagem

Documentos Produzidos
* Documento Formal de Requisitos
* Arquivo de Dvidas
* Esquema do Banco de Dados
* Diagrama de Casos de Uso
* Diagramas de Atividades
* Diagrama de Classes
* Diagramas de Seqncia
* Diagramas de Colaborao

P1
A, C
N
A, C
N
N
N
N
N

P2
A, C
A, C
A, C
A, C
A
U
U
U

47

Implementao

Gerncia do
Processo

Legenda:
P1
P2
C
I
A
D
N
U

* Modelo Conceitual

* Cdigo
* Contratos Legais (NPI-Cliente e
NPI-Desenvolvedores)
* Proposta de Projeto
* Plano do Desenvolvimento
* Cronograma
* Acompanhamento do trabalho dos
desenvolvedores e do gerente

C
I

A
I

A, C
U
U
D, C

A, C
N
U
A, I

Produzido no Primeiro Projeto


Produzido no Segundo Projeto
Completo
Incompleto
Atualizado
Desatualizado
No foi produzido nesse projeto
Produzido, porm no utilizado em fases posteriores
Quadro 5: Resumo do processo atual do NPI

2.4 Anlise das Necessidades do NPI

A partir dos dados coletados nas entrevistas e da inspeo dos documentos


dos projetos enviado-nos pelo diretor, pde-se perceber a realidade do processo de
desenvolvimento do NPI. Atravs da anlise dessa realidade, conclui-se sobre as
necessidades do NPI em relao a um processo de desenvolvimento de software.

Os requisitos do NPI para um modelo de processo de desenvolvimento do


software so:

48

* Possuir um modelo de processo para cada fase citada anteriormente (anlise de


requisitos, modelagem, implementao e testes), integrado a atividades de
gerncia administrativa e a processos de gerncia de configurao e controle de
documentos.

* Definir um roteiro de como realizar essas fases e oferecer documentos padro (com
partes que possam ser alteradas ou preenchidas, diferentemente em cada projeto)
para os documentos a serem produzidos.

* Ser voltado a pessoas sem grande experincia e conhecimento na rea de


Engenharia de Software, e necessitar que elas passem por pouco tempo de
treinamento (por exemplo, 10 horas) para entender como realizar o processo.

* Ser baseado no processo existente, melhorando-o nos seus pontos mais fracos.

* Ser adequado ao contexto do NPI (escassez de pessoal e de tempo, oramentos


pequenos, e outras caractersticas especficas de uma empresa jnior). Deve
incluir apenas a produo de documentos que sero aproveitados em outras
fases, e no a produo de documentos que depois no sero utilizados.

* Facilitar e auxiliar o trabalho colaborativo, por intermdio ou no de computador.


* Possuir um meio, sistematizado e baseado em indicadores, para continuamente
melhorar o prprio modelo. Ou seja, o modelo deve estabelecer uma metodologia
para a sua alterao; e essa alterao deve ser baseada em dados reais e
mensurveis, observados no processo de desenvolvimento de software do NPI.

49

50

3 Conceitos Fundamentais

Neste captulo, sero definidos os termos, no contexto de modelagem de


processo, que sero utilizados a partir de agora neste trabalho. Alguns desses
termos so conceitos da rea da Engenharia de Software. Outros, entretanto, so
substantivos com significados genricos e semelhantes (tais como tarefa, atividade e
fase) - comumente encontrados na literatura, mas com significados diferentes para
cada autor - aos quais sero atribudos um significado nico e especfico, o qual ser
utilizado na continuidade deste trabalho. Ressalta-se, mais uma vez, que so do
interesse deste trabalho apenas os conceitos relacionados com a rea de
Modelagem de Processo de Software, uma sub-rea da Engenharia de Software.

3.1 O que um Processo de Software?

Um processo uma seqncia de atividades ou acontecimentos, ordenados


ou no, que levam a um resultado. Mas o que um processo de software?
Partindo da definio anterior, um processo de software o conjunto de atividades
realizadas para atingir o objetivo principal de desenvolver um software (e, tambm

51

partindo da definio anterior, essas atividades podem ser realizadas de uma


maneira aleatria ou de uma maneira sistematizada).
Segundo

LARMAN

(2000,

p.

40),

"um

processo

[sistematizado]

de

desenvolvimento de software um mtodo para organizar as atividades relacionadas


com a criao, entrega e manuteno de sistemas de software." O SEI fornece uma
definio ainda mais completa:
Um processo de software pode ser definido como
um

conjunto

de

atividades,

mtodos,

prticas

transformaes que as pessoas utilizam para desenvolver


e manter software e seus produtos associados (por
exemplo, planos de projeto, documentos de projeto do
sistema, cdigo, casos de teste e manuais do usurio).
(PAULK et al., 1993, p.3, traduo livre)

Essas duas citaes do uma amostra da falta de consenso que existe na


literatura em relao definio do que um "processo de software". Pois, o que foi
definido por "processo de software" chamado por alguns autores de "processo de
engenharia de software" (KEHOE e JARVIS, 1996) ou "processo de desenvolvimento
de software" (LARMAN, 2000).
Neste trabalho, diferenciar-se- o conceito de processo de software do
conceito de processo de desenvolvimento de software. Assim, para o este estudo,
um processo de desenvolvimento de software aborda apenas os aspectos relativos
ao desenvolvimento (anlise de requisitos e de sistema, projeto de sistema,
implementao e testes) e um processo de software aborda, alm dos aspectos
relativos

ao

desenvolvimento,

subcontratao, entre outros.

tambm

os

aspectos

de

manuteno,

de

52

3.2 Modelo de Processo de Software

Um modelo de processo de software define o que deve ser realizado em


cada fase do desenvolvimento e d as instrues de como realizar essas atividades.
Um modelo serve como um guia, um roteiro para a execuo de um processo de
desenvolvimento. KELLNER et al. (1998) chamam o modelo de guia do processo.
"Um guia do processo um documento de consulta para um certo processo,
orientando os participantes do processo na sua conduo" (Idem, op.cit., p.1,
traduo livre).
Esse guia pode tomar a forma de um software, utilizado para acompanhar o
desenvolvimento, ou seja, uma ferramenta CASE (Computer-Aided Software
Engineering, ou Engenharia de Software Auxiliada por Computador), ou ento de um
manual impresso, a ser lido e consultado durante o desenvolvimento de um software.
KEHOE e JARVIS (1996) chamam esse manual impresso de Software Process
Handbook (ou SPH). KELLNER et al. (1998) tambm mencionam essas duas opes
chamando o manual impresso de paper-based process guide e o manual em meio
eletrnico de EPG (Electronic Process Guide). Pode-se perceber mais uma falta de
consenso na literatura, desta vez quanto definio de um nome padro para o que
foi definido como modelo de processo de software.

53

Como explicado inicialmente, o presente trabalho prope-se a desenvolver um


guia impresso.
Um modelo de processo pode ser muito ou pouco flexvel, por exemplo, ele
pode permitir a escolha de um modelo de ciclo de vida diferente em cada
desenvolvimento ou determinar que todos os desenvolvimentos iro usar o mesmo
modelo de ciclo de vida. Alm disso, ele pode ser bastante detalhista ou mais
altonvel: pode definir sub-atividades dentro de cada atividade ou pode apenas dar
uma definio geral do que deve ser realizado em cada fase do desenvolvimento.
Com tantas possibilidades, fcil perceber que um modelo deve ser adequado
realidade de uma empresa ou de um tipo de empresas, por exemplo, um modelo
para grandes empresas deve ser diferente de um modelo para pequenas empresas.
Apesar disso, so muito recentes os estudos de modelos de processo de software
para micro e pequenas empresas (os quais sero abordados no captulo 4).

3.3 Qualidade do Processo

Segundo ROCHA (2002), um software de qualidade aquele que atende s


necessidades de seu usurio. Tecnicamente falando, essas necessidades se
traduzem em requisitos do sistema. Assim, um software de qualidade aquele que
atende aos requisitos especificados inicialmente no seu planejamento.
Como j explicado anteriormente, "a qualidade de um produto de software
fortemente dependente da qualidade do processo pelo qual ele construdo e
mantido" (Idem, op. cit., p.9, grifo nosso). Ou seja, a utilizao de um processo

54

metdico e sistematizado tem muito mais chances de produzir um software de


qualidade do que a utilizao de um processo catico e desordenado. Por "processo
metdico e sistematizado", entende-se por "um processo cujas etapas so
detalhadas de tal forma que engenheiros podem consistente e repetidamente
utilizlo" (WEBER, 2002, p.25). Ou seja, para cada fase do ciclo de vida so
descritas as atividades a serem realizadas e os responsveis por cada uma delas, os
documentos a serem produzidos e seus contedos, as condies de entrada e de
sada, as ferramentas e metodologias a serem utilizadas, entre outros.
"A implantao de um Programa de Qualidade comea pela definio e
implantao de um processo de software [de qualidade]" (ROCHA, 2002, p.12). De
acordo com ULRIKE, HAMANN e VERLAGE (1997), a tarefa de implantao (ou
melhora da qualidade) de um processo de software engloba duas atividades
principais: a elaborao de um modelo de processo descritivo e depois, de um
modelo de processo prescritivo. "Um modelo descritivo retrata como um processo
executado em um ambiente em particular; um modelo prescritivo retrata como um
processo deveria ser executado" (Idem, op. cit., p.2, traduo livre). Essa abordagem
utilizada no presente trabalho: o captulo 2 apresenta o modelo descritivo do
processo do NPI e o captulo 5 apresenta o modelo prescritivo.

Existem diversos modelos para a avaliao e melhora do processo de software.


A parte 9 do relatrio Software Process Assessment (SPICE PROJECT
ORGANISATION, 1995) apresenta vrias definies relacionadas avaliao (ou
certificao) e melhora de processo. "[...] avaliao do processo: Uma avaliao
disciplinada dos processos de software de uma organizao comparando-os a um
modelo de processo [...]" (Idem, op. cit., p.9, traduo livre). Outra definio

55

interessante presente no relatrio a definio de determinao da capacidade do


processo:
[...] avaliao e anlise sistemticas de processos
de

software

selecionados

em

uma

organizao

comparando-os a uma capacidade alvo, realizada com o


objetivo de identificar os pontos fortes e fracos e os riscos
associados na mudana dos processos para que eles
atendam

um

certo

requisito

especificado

(SPICE

PROJECT ORGANISATION, 1995, p.9, traduo livre).

O conceito de melhora do processo tambm definido de maneira bastante


precisa. "[...] melhora do processo: Ao tomada para mudar os processos de uma
organizao para que eles satisfaam as necessidades da organizao e atinjam os
seus objetivos de negcio mais eficientemente" (Idem, op. cit., loc.cit., traduo livre).
De acordo com ROCHA (2002), a avaliao - ou certificao - do processo pode
ser feita tanto pela prpria empresa desenvolvedora quanto por terceiros (i.e.
auditores independentes). "Um guia de processo pode tambm abranger as
atividades de planejamento da execuo do processo e de certificao" (KELLNER
et al.,1998, p.5, traduo livre).
Os principais modelos de avaliao do processo so CMM, SPICE (ou ISO/IEC
15504) e ISO 9000-3, sendo que o SPICE tambm um modelo de melhora do
processo. Alm deles, tambm existem outros dois modelos (que facilitam a
implementao do CMM) os quais considera-se importante mencionar, so eles: PSP
(um modelo de mtricas individuais de trabalho) e TSP (um modelo de gerncia do
processo de software). Todos esses modelos sero discutidos mais detalhadamente
no captulo 4.

56

Como explicado no captulo 4, a literatura da rea de Processo de Software


se concentra principalmente nos modelos de avaliao do processo descritos acima.
Muito se diz sobre "o que um processo de qualidade" e "como avaliar um
processo" mas raramente se comenta sobre "como elaborar um modelo de
processo". Entende-se que a explicao para esse fato, que geralmente a
modelagem de processos feita por empresas de consultoria, que no iriam revelar
sua "metodologia de desenvolvimento de modelos de processo" pois ela a base do
seu negcio (seria como o fabricante da Coca-Cola revelar a sua frmula). Outra
explicao pode ser simplesmente por que a rea de modelagem de processo de
software ainda muito nova, e existe pouca pesquisa sobre o assunto.

3.4 Modelos de Ciclo de Vida

Outro conceito relacionado com processo de software o conceito de modelo


de ciclo de vida. O modelo de ciclo de vida de um software determina as fases
pelas quais o desenvolvimento de um software deve passar e, principalmente, a
ordem e o nmero de repeties dessas fases. Enquanto o ciclo de vida trata apenas
da ordenao das fases tcnicas do desenvolvimento, um processo abrange
aspectos gerenciais e mais detalhados, como, definio de papis, ferramentas e
mtricas. Apesar disso, o processo de desenvolvimento de um software est
intimamente ligado com o modelo de ciclo de vida adotado para desenvolv-lo. No
pode haver um modelo de processo definido sem um ciclo de vida definido.

57

A seguir, sero explicados brevemente alguns modelos de ciclo de vida. Os


exemplos escolhidos so os mais citados na literatura consultada, e alm disso,
percebeu-se que a partir deles so derivados muitos outros - o que leva a concluir
que esses modelos so os fundamentais.

3.4.1 Exemplos de modelos

Code-and-Fix: Esse tipo de ciclo de vida se caracteriza por duas fases:


produo de cdigo (code) e conserto do cdigo quando so detectados erros (fix).
Essa seqncia repetida at que se esteja satisfeito com o cdigo resultante.
Apesar de ser considerada uma tcnica um tanto primitiva, ainda muito utilizada. A
Figura 11, mostra como a produo do software por meio desse modelo uma
atividade "nebulosa".

Figura 11: Modelo de ciclo de vida code-and-fix


(McCONNELL apud WEBER, 2002, p.30)
Cascata: As fases (normalmente: anlise, projeto, implementao e testes) so
executadas em seqncia, sendo que uma s inicia aps a outra haver sido

58

completamente terminada. Alm disso, uma vez terminada a fase, os resultados dela
no so mais alterados (por exemplo, durante a fase de projeto no h a
possibilidade de alterao dos requisitos, documentados na fase da anlise) . Por
esse motivo, o mtodo cascata no muito utilizado. Na prtica, ele combinado
com um ou mais modelos para resolver o problema. A Figura 12 ilustra a seqncia
de fases como explicado:

Figura 12: Modelo de ciclo de vida cascata

Modelo em V: semelhante ao cascata, diferenciando-se apenas em relao


aos testes. Durante as fases de anlise e projeto so planejados os testes e durante
a fase de implementao eles so preparados. Na fase de testes, eles so apenas
executados. Esse modelo melhor do que o cascata porque leva a procedimentos
de teste mais criteriosos e tende a diminuir a quantidade de erros no identificados
(SILVA, 2002). Na Figura 13, pode-se observar a seqncia das fases e como os

59

testes so projetados, produzidos e executados. Ela tambm permite entender o


motivo do nome do modelo.

Figura 13: Modelo de ciclo de vida em V


(baseada em SILVA, 2002)

Desenvolvimento Incremental: Esse modelo considerado um dos melhores,


pois resolve o principal defeito do cascata: permite que os documentos de uma fase
sejam melhorados (ou incrementados) mesmo aps essa fase haver sido
completada. Isso ocorre porque o desenvolvimento baseado em ciclos. Um ciclo
constitui uma seqncia das fases de anlise, projeto, implementao e testes. Os
requisitos podem ser divididos grupos, e cada grupo implementado em um ciclo.
Assim, muda-se de uma fase para a prxima, mesmo sem ela haver sido
completamente terminada. Alm disso, o desenvolvimento incremental permite que,
por exemplo, ao encontrar um requisito do sistema durante a fase de projeto (o que
bastante comum), pode-se incluir esse requisito no documento de requisitos, na fase
de anlise do prximo ciclo.

60

Figura 14: Modelo de ciclo de vida desenvolvimento incremental


(baseada em SILVA 2002)

Espiral: Segundo WEBER (2002, p.37), o modelo espiral, " um modelo


orientado a riscos que reparte o projeto em mini-projetos. Cada mini-projeto resolve
um ou mais riscos maiores at que os riscos maiores sejam resolvidos." Ao final da
espiral, os grandes riscos esto eliminados, e pode-se continuar o desenvolvimento
com outro modelo de ciclo de vida. Entretanto, esse modelo necessita de um
gerenciamento de riscos um tanto complexo, sendo recomendado apenas para
equipes mais experientes. A Figura 15, ilustra mais detalhadamente esse modelo.

61

Figura 15: Modelo de ciclo de vida em espiral


(BOEHM apud WEBER, 2002, p.38)

3.4.2 Discusso

Entende-se que um novo modelo de ciclo de vida para o NPI no pode ser
baseado no code-and-fix, pois, alm desse modelo ser considerado ineficiente, isso
seria um retrocesso no seu desenvolvimento de software. O modelo espiral tambm
inapropriado por que a anlise de riscos exige equipes experientes nessa rea, o
que certamente no o caso do NPI. O principal defeito, anteriormente comentado,
dos modelos cascata e em V o fato deles no possibilitarem a reviso dos artefatos
j criados. Pode-se dizer que devido aos projetos que o NPI realiza (sistemas
pequenos e mdios sob encomenda) e sua equipe (pequena e com pouca

62

experincia), a mudana - principalmente dos requisitos - durante o desenvolvimento


bastante comum. Assim, a utilizao do modelo cascata ou em V, sozinho (i.e. sem
combinaes) no adequada para o NPI. Essa necessidade de revisar e reelaborar
os artefatos do desenvolvimento no exclusiva do NPI, muitas empresas tambm
possuem essa necessidade, e por isso que o modelo de desenvolvimento
incremental (e suas variaes) hoje o mais aceito pela comunidade. Assim,
acredita-se que um modelo de ciclo de vida para o NPI deve ser baseado
principalmente no modelo de desenvolvimento incremental combinado com outro(s)
modelo(s). A discusso do modelo de ciclo de vida escolhido para o NPI ser
abordada no captulo 5.

3.5 Conceitos Complementares

Outro conceito, j bastante utilizado neste trabalho, e que tambm no possui


uma definio padro na literatura, o conceito de fase. Neste trabalho, quando se
fala em fase, est se referindo a uma das principais partes do desenvolvimento de
um software, como por exemplo: Anlise de Requisitos, Anlise do Sistema, Projeto
do Sistema, Implementao, Testes.
Quando mencionado o termo atividade - outra palavra que tambm no
possui uma definio padro na literatura, e muitas vezes se confunde com fase est se referindo a uma tarefa a ser executada em uma determinada fase. Por
exemplo, na fase de anlise de requisitos, deve-se realizar a atividade "elaborar o
documento de requisitos".

63

O termo papel tem uma definio bastante precisa na literatura, a qual ser
adotada tambm para este trabalho. Papis so "descries de um conjunto de
obrigaes e permisses relacionadas execuo de atividades" (KELLNER et al.,
1998, p.9, traduo livre). Simplificando, um papel uma responsabilidade assumida
por uma ou mais pessoas. Alguns exemplos de papis so: gerente de projeto,
desenvolvedor, testador, analista de requisitos e diretor de projetos. A definio de
papis durante o planejamento do desenvolvimento importante para que se tenha
explicitamente determinado quem vai fazer o qu.
O conceito de artefato tambm no possui uma definio padro, mas ele
usado de maneira relativamente consistente por todos os autores. Artefatos so
"descries dos produtos criados ou modificados durante a execuo do processo
[...]" (Idem, op. cit., loc. cit., traduo livre). Para este trabalho, o termo artefato
representa o resultado de uma das fases do desenvolvimento. A palavra documento
algumas vezes utilizada como sinnimo de artefato, o qual ser tambm
considerado no presente trabalho. Classifica-se o artefato, ou documento, em dois
tipos: tcnico (por exemplo: diagramas de atividades, documento de requisitos e
cdigo-fonte) e gerencial (produtos administrativos, como: documento de aceitao
do software pelo cliente, contrato com o cliente, planilha de acompanhamento do
trabalho dos desenvolvedores e plano do desenvolvimento). Alm disso, os artefatos
podem ser compostos de outros artefatos (inclusive de tipos diferentes). Por
exemplo, o plano do desenvolvimento - que um artefato gerencial - pode conter o
cronograma - que tambm um artefato gerencial - e mais o documento de
requisitos e o diagrama de casos de uso - ambos artefatos tcnicos.
A palavra ferramenta tambm utilizada de maneira uniforme na literatura.
Uma ferramenta um recurso utilizado para a produo de um artefato. Pode ser um

64

recurso computacional (como MS Word, Borland Delphi e Rational Rose) ou no


(como lpis e papel).

65

4 Estado da Arte e Prtica

Neste captulo, sero apresentadas as idias e teorias mais aceitas atualmente


na rea de modelagem de processos. E tambm, sero analisados relatos de
experincias que de alguma forma esto ligadas ao presente trabalho.

4.1 Viso Geral de Modelos de Avaliao de Processo

Como explicado anteriormente, sero agora apresentados os principais


modelos de avaliao de processo aceitos pela comunidade de engenharia de
software (CMM, SPICE e ISO 9000-3) e outros dois modelos (um de mtricas
individuais de trabalho e outro de gerncia do processo de software) no to citados
na

literatura

mas

respectivamente).

que

considera-se

importante

mencionar

(PSP

TSP

66

4.1.1 CMM - Capability Maturity Model

um Modelo para analisar a Maturidade de uma empresa em termos da


Capacidade do seu processo de software (PAULK et al., 1993). Esse modelo foi
desenvolvido no incio dos anos 90 pelo SEI (Instituto de Engenharia de Software da
Universidade Carnegie Mellon, Estados Unidos), como um projeto para o
Departamento de Defesa (DoD) americano, que era um grande comprador de
software sob encomenda, e freqentemente recebia produtos de m qualidade. Em
pouco tempo, esse modelo passou a ser uma utilizado como referncia no mundo
todo para medir a qualidade do processo de software em uma empresa.
Como explicado anteriormente, um dos princpios do CMM o de que um
processo de qualidade tende a gerar um resultado (software) de qualidade. O CMM
classifica o processo em cinco nveis de maturidade: (1) inicial, (2) repetvel, (3)
definido, (4) gerenciado e (5) otimizado. Esses nveis so como "fases ou estgios
atravs dos quais as empresas desenvolvedoras de software evoluem quando elas
definem, implementam, medem, controlam e melhoram seus processos de software"
(REZENDE, 1999, p.146). Cada nvel de maturidade, exceto o primeiro, possui uma
srie de reas-chave do processo, ou Key Process Areas (KPAs). "Cada rea-chave
do processo identifica uma srie de atividades relacionadas que, quando realizadas
em conjunto, atingem um grupo de objetivos considerados importantes para melhorar
a capacidade do processo" (PAULK et al., 1993, p.30). Essas atividades so

67

chamadas de Key Practices, ou prticas-chave. Assim, para uma empresa atingir


determinado nvel de maturidade, ela deve realizar todas as prticas-chave de todas
as reas-chave daquele nvel. A Figura 16 apresenta as reas-chave de cada nvel e
a Figura 17 resume a estrutura de KPAs e prticas-chave explicadas acima.

Figura 16: reas-chave do CMM agrupadas por nvel


(PAULK et al., 1993, p.31)

68

Figura 17: Estrutura do CMM


(PAULK et al., 1993, p. 29)
Desde 1993, a rea de processo de software evoluiu bastante (inclusive graas
aplicao do CMM em uma grande quantidade de empresas) e foram surgindo
muitas crticas a respeito desse modelo (como, ser ideal para grandes empresas
mas no para empresas pequenas, ser muito rgido em relao transio entre os
nveis, e outras). Por causa disso, o SEI foi melhorando e aprimorando o CMM
inicial, chegando ao atual CMMI (CMMI PRODUCT TEAM, 2002), que alm de haver
flexibilizado essa transio entre os nveis atravs da criao de um modelo
contnuo (o CMM antigo - que continua sendo aceito - foi rebatizado de modelo em
estgios), tambm expandiu a abrangncia do CMM para outras reas relacionadas
direta ou indiretamente com o desenvolvimento de software (como engenharia de

69

sistemas, gerenciamento de recursos humanos e outros), criando toda uma famlia


de CMMs. O modelo contnuo permite que uma empresa possua nveis de
capacidade (muito semelhantes aos nveis de maturidade do modelo em estgios)
diferentes em cada rea-chave do processo. Uma conseqncia muito importante, e
estrategicamente planejada pelo SEI, da existncia do modelo contnuo que ele
permite ao CMMI ser compatvel com o SPICE.

4.1.2. SPICE - Software Process Improvement and Capability dEtermination

Essa

norma

foi

publicada

pela

ISO

(International

Organization

for

Standardization) e a IEC (International Engineering Consortium) em 1998, e foi


revisada recentemente (em Junho de 2002) (INTERNATIONAL ORGANIZATION
FOR STANDARDIZATION, 2003). Tambm conhecida pelo seu nmero: ISO
15504. O SPICE um modelo para melhoria (Improvement) do Processo de
Software e dEterminao da Capacidade desse processo de produzir software de
qualidade (perceba que o conceito de capacidade o mesmo do CMM).
A parte 2 do relatrio Software Process Assessment (SPICE PROJECT
ORGANISATION, 1995) apresenta um modelo de referncia que "define, em alto
nvel, as atividades que so essenciais para uma boa engenharia do software [...]"
(Idem, op. cit., p.10, traduo livre).

70

O SPICE inclui um modelo de referncia, que


serve como base para o processo de avaliao. Este
modelo um conjunto padronizado de processos
fundamentais, que orientam para uma boa engenharia de
software (REZENDE, 1999, p. 162).

O modelo de referncia do SPICE especifica categorias de processo, que


so sub-processos realizados dentro do processo de software.
Este

modelo

categorias

de

dividido

em

processo:

cinco

grandes

Cliente-Fornecedor,

Engenharia, Suporte, Gerncia e Empresa. Cada uma


destas categorias detalhada em processos mais
especficos e descrito em detalhes pela norma (Idem,
op.cit., loc.cit.).

Alm das categorias de processos, o SPICE define tambm seis nveis de


capacitao para cada processo, que podem ser: no realizado, realizado
informalmente,

planejado

acompanhado,

bem

definido,

quantitativamente

controlado e continuamente melhorado. "O resultado de uma avaliao, portanto,


retrata um perfil da instituio em forma de matriz, onde os processos esto nas
linhas e os nveis nas colunas" (Idem, op. cit., loc. cit.). A Figura 18 ilustra essa
matriz.

71

Figura 18: Exemplo de um perfil definido pelo SPICE


Para a melhora do processo, o SPICE utiliza a seguinte abordagem: com a
capacidade do processo existente determinada atravs de uma matriz, so
analisados os seus pontos fortes e fracos; na mesma matriz, so traadas as
capacidades desejadas para o processo (como se elas representassem um outro

72

processo existente); comparando os dois processos, pode-se ter uma idia do que
deve ser melhorado.
Fazendo uma analogia, os nveis de capacidade do CMM correspondem aos
nveis de maturidade do SPICE e as KPAs do CMM podem ser agrupadas em
conjuntos correspondentes s categorias de processos do SPICE.
Essa norma uma tentativa da ISO de estabelecer um padro para medio da
qualidade do processo de software de uma empresa. Para facilitar a padronizao, a
parte

do

relatrio

Software

Process

Assessment

(SPICE

PROJECT

ORGANISATION, 1995) contm tabelas de mapeamento das normas ISO12207 e


ISO9001 (nos anexos E e F, respectivamente) para os processos e categorias de
processos do SPICE.

4.1.3 ISO 9000-3

uma norma anterior ao SPICE, pois foi publicada em 1997. Faz parte do
padro para gerenciamento da qualidade e garantia de qualidade, o ISO 9000. A
parte 3 do ISO 9000 (por isso o 9000-3) um guia para a aplicao da ISO 9001
para o desenvolvimento, fornecimento, instalao e manuteno de software para
computador (a ISO 9001, publicada em 1994, uma norma genrica para garantia
de qualidade no projeto, desenvolvimento, produo, instalao e fornecimento de
servios) (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, 2003).
Por ser um guia, o ISO 9000-3 apenas explica o que deve ser feito para haver
um processo de software de qualidade na empresa. No livro "ISO 9000-3: a tool for

73

software product and process improvement" (KEHOE e JARVIS, 1996), os autores


do algumas indicaes do que fazer para concretizar as orientaes do ISO 90003. Segundo eles, a norma se concentra em trs temas principais:
(1) Responsabilidades da gerncia tanto do lado do fornecedor quanto do
comprador.
"A gerncia do fornecedor responsvel pela [...] institucionalizao e o uso de
um processo de engenharia" (Idem, op.cit., p.20, traduo livre). A gerncia
deve definir uma Poltica de Qualidade, um documento de alto nvel que
garanta o foco da organizao no desenvolvimento de um produto de
qualidade. As responsabilidades do comprador consistem em garantir que os
requisitos foram claramente definidos, autorizar as mudanas desses requisitos
e preparar e executar os testes de aceitao.
(2) O processo de desenvolvimento.
um processo de engenharia constitudo de vrias
fases, com entradas e sadas definidas para essas fases
[...], existem papis e responsabilidades definidas para os
engenheiros que implementaro o processo e existem
meios para testar os produtos e subprodutos desse
processo de engenharia (KEHOE e JARVIS, 1996, p.20,
traduo livre).

A necessidade de haver um processo de engenharia uma conseqncia da


Poltica de Qualidade. Alm disso, o processo de engenharia deve ser
gerenciado por planos que identificam cronograma, recursos e mecanismos de
reviso e auditoria.

74

(3) As atividades de apoio.


existem atividades que apiam os processos de
desenvolvimento, testes e documentao da engenharia.
Elas so: gerncia de configurao [...], controle de
documentos, medio da qualidade do produto e do
processo e treinamento. Planos para a implementao
dessas atividades devem ser desenvolvidos e recursos
devem ser alocados para que esses planos possam ser
executados (Idem, op. cit., loc. cit., traduo livre).

O documento que implementa a Poltica de Qualidade chamado pela norma


de Manual de Qualidade ou Processo de Qualidade, porm, como uma das crticas
feitas pelos autores (Idem, op.cit., p. 21) norma o uso excessivo da palavra
qualidade, eles recomendam que esse "manual de qualidade" seja chamado de
Manual do Processo de Software (ou Software Process Handbook, SPH).
Os autores ainda recomendam, que para cada projeto de desenvolvimento e
manuteno deve haver um SDP (Software Development Plan, ou Plano do
Desenvolvimento de Software), identificando recursos, cronogramas e uma
abordagem especfica para implementar o processo de engenharia descrito no SPH.
Alm disso, o SDP deve "incluir ou referenciar planos subordinados (como o plano
de gerncia de configurao, os planos de testes, o plano de controle de
documentos, entre outros)" (KEHOE e JARVIS, 1996, p.22, traduo livre).
Um dos pontos mais importantes da norma, o de que a gerncia a principal
responsvel pela adoo de um processo de qualidade, dela que deve partir o
maior comprometimento com essa poltica de qualidade.

75

4.1.4 PSP e TSP

PSP a abreviao de Personal Software Process, enquanto TSP a


abreviao para Team Software Process (SOFTWARE ENGINEERING INSTITUTE,
2003). Esses dois modelos foram tambm desenvolvidos pelo SEI. Aps o
desenvolvimento do CMM, muitos especialistas do SEI perceberam que as pessoas
que iam adotar o CMM em uma empresa no sabiam como faz-lo, pois o modelo
no explica em detalhes o que fazer para mudar o processo existente. Para resolver
esse problema, foram criados o PSP e o TSP.
O PSP um modelo que detalha as tarefas de cada desenvolvedor em termos
de medio e melhoria do seu Processo Pessoal de produo de Software, ou seja,
ele enfoca tarefas como contagem de horas trabalhadas, estimativa de tempo para
produo de um mdulo ou componente, entre outras. J o TSP, um modelo voltado
ao Processo de Software da equipe (Team) de desenvolvimento, explica o que os
lderes de uma equipe de desenvolvimento ou manuteno devem fazer para
conseguir um bom processo de software. Ele enfoca mais a parte de coordenao e
motivao da equipe de desenvolvimento e explica como a equipe pode ser
autodirigida.
Os dois modelos auxiliam na introduo de uma disciplina de desenvolvimento
de software, ou seja, na criao de bons hbitos de engenharia de software no diaadia do trabalho dos desenvolvedores e seus chefes. Cabe tambm ressaltar que os
dois modelos so complementares, e que o TSP s pode ser utilizado aps a

76

implantao do PSP. A implantao desses dois modelos requer um treinamento


grande de todos os envolvidos no processo de software em uma empresa, e por
isso, ela normalmente conduzida por um especialista do SEI ou um especialista
autorizado.
A Figura 19 ilustra as principais reas de processo que o PSP e o TSP
abordam, e a Figura 20 mostra a relao dos dois modelos com o CMM.

Figura 19: reas de processo abordadas pelo PSP e o TSP


(SOFTWARE ENGINEERING INSTITUTE, 2003)

Figura 20: Relao do PSP e do TSP com o CMM

77

(SOFTWARE ENGINEERING INSTITUTE, 2003)


O site referente ao TSP e PSP (SOFTWARE ENGINEERING INSTITUTE,
2003) tambm mostra que os resultados da aplicao dos dois modelos reduzem
significativamente a ocorrncia de defeitos, o tempo de durao dos testes, os
desvios

das

estimativas

do

cronograma

do

esforo

empregado

no

desenvolvimento, entre outros. Sendo os dois modelos, preparatrios para a


aplicao do CMM, pode-se perceber que (assim como o CMM) eles so voltados
para grandes empresas, pois exigem dedicao de grande parte do tempo de
desenvolvimento medio e controle do processo, o que proibitivo em empresas
muito pequenas, como o caso do NPI.

4.2 Questes Humanas na Modelagem de Processos

A seguir, so destacadas algumas idias sobre modelagem de processo, que


so recorrentes na literatura. Essas idias esto relacionadas principalmente a
fatores humanos que influem, ou que devem ser levados em conta, na modelagem
de processos. essencial considerar esses fatores, pois o sucesso de um modelo
de processo depende tanto das suas caractersticas tcnicas como das pessoas que
iro segu-lo - afinal, para que serve um bom modelo se ele no utilizado? Existem
muitos motivos para que as pessoas sigam ou no um modelo, por exemplo, elas
podem no gostar da aparncia do modelo, achar que ele muito complicado e no
querer mudar o processo existente. Assim, so destacadas algumas questes

78

humanas na modelagem de processo, as quais percebeu-se que so consideradas


importantes pela literatura.

Os modelos citados anteriormente apenas do diretrizes do que fazer para se


ter um processo de qualidade. Nenhum deles contm uma "frmula mgica" que ir
transformar uma empresa desordenada em uma empresa metdica. Por isso, os
modelos devem ser sempre adaptados realidade e s necessidades da empresa.
"Focalize nos requisitos essenciais e personalize o seu processo para o tamanho da
sua organizao e a urgncia da aplicao" (KEHOE e JARVIS, 1996, p. 25,
traduo livre). "Um processo de engenharia de software deve ser personalizado de
acordo com os cronogramas, oramentos, metas de qualidade, e os pontos fortes e
fracos inerentes em uma organizao" (Idem, op. cit., p.13, traduo livre). Alm
disso, o modelo deve ser aplicado na empresa aos poucos, ou seja, no se deve
tentar mudar o processo de uma empresa "da noite para o dia". Uma maneira de
fazer isso aplicar o modelo em um ou dois projetos, e ir progressivamente
adotando-o nos outros projetos.
No esprito da personalizao, deve-se tomar cuidado para no criar um
modelo muito difcil de ser seguido, pois o objetivo da adoo de um modelo de
processo de desenvolvimento deve ser sempre o de melhorar o processo da
empresa, e no de pior-lo. Por exemplo, ao adotar, em uma micro-empresa, um
modelo que demanda um extenso e complexo sistema de qualidade, isso certamente
ir atrapalhar o processo mais do que ajudar, pois os poucos funcionrios da
empresa gastaro muito tempo preenchendo formulrios e escrevendo relatrios
comparado com o tempo em que estaro efetivamente produzindo o software.
Depois de alguns projetos, eles iro ficar desmotivados e o modelo ser

79

progressivamente abandonado, prejudicando assim, a qualidade do software da


empresa - o que era o objetivo inicial do modelo!

A mudana do processo de desenvolvimento requer principalmente uma


mudana na maneira de pensar de todos os funcionrios (desde a alta gerncia at
os programadores), isso bastante enfatizado por vrios autores (como, REZENDE,
1999 e KEHOE e JARVIS, 1996). WEINBERG (1993), explica que essa mudana
implica em uma alterao no padro cultural de pensamento das pessoas. Esse
um dos principais desafios da rea de modelagem de processos.

Ainda em aspectos humanos, ROCHA (2002, p.12) afirma que "o processo de
software deve estar documentado, ser compreendido e seguido". Ou seja, de nada
adianta um bom manual de processo de software, se ele no seguido. Nesse
sentido, KEHOE e JARVIS (1996) apontam para a importncia da gerncia em
comprometer-se com a qualidade do processo e ULRIKE, HAMANN e VERLAGE,
(1997) explicam que um dos fatores que contribuem para o seguimento do modelo
a sua compreensibilidade: "Devido ao fato dos modelos serem utilizados por
humanos e no por mquinas, eles devem ser elaborados levando-se em conta
fatores como compreensibilidade e legibilidade, e devem apresentar a informao de
uma maneira atraente" (Idem, op. cit., p.13, traduo livre).
Os autores tambm enfatizam a questo da aceitao e confiana (dos
envolvidos no processo) nas pessoas que iro elaborar o modelo (tanto o descritivo
quanto o prescritivo). Uma das maneiras de ganhar confiana permitir e estimular a
participao de todos os envolvidos no processo (desde a alta gerncia at os
desenvolvedores) nas atividades de elaborao do modelo.

80

muito

importante

envolver

todos

os

desenvolvedores desde o incio [...] quando se faz a


modelagem do processo da empresa. Se todas as
pessoas

envolvidas

no

processo

participam

da

modelagem desde o princpio, eles sentem que as suas


necessidades esto sendo levadas em conta, o que
aumenta a sua aceitao. (ULRIKE, HAMANN e
VERLAGE, 1997, p.7, traduo livre)

Alm disso, explicado que a elaborao do modelo deve ser abordada como
uma tarefa construtiva e no uma tarefa prescritiva. Pois dessa maneira, os
desenvolvedores sentiro que verdadeiramente fizeram parte do processo de
elaborao e que o modelo pertence a eles.
muito importante que os desenvolvedores se
vejam como os donos dos modelos, apesar do grupo de
processo [i.e., as pessoas que esto elaborando o
processo] ser quem gerencia os modelos. [...] As pessoas
sabem reconhecer quando um modelo apresentado em
uma certa situao apropriado ou no. (Idem, op.cit.,
p.12, traduo livre, grifo nosso)

Ainda, os autores comentam que um modelo de processo no deve ser


tomado como algo rgido e imutvel - devido sua natureza no-determinstica - e
que as pessoas ficam mais satisfeitas com um processo que lhes d liberdade para
flexibiliz-lo em certos pontos.
Os

modelos

de

processo,

mesmo

quando

elaborados atravs de mtodos rigorosos, no devem ser


usados rigorosamente. Os processos de desenvolvimento
de software so estocsticos e no determinsticos e os

81

desenvolvedores so pessoas inteligentes e criativas, que


precisam de liberdade para interpretaes pessoais.
(ULRIKE, HAMANN e VERLAGE, 1997, p.13, traduo
livre)

Portanto, aps essa anlise, pode-se perceber que importante considerar as


influncias humanas na realizao da modelagem de um processo. Alguns requisitos
do NPI, apresentados no captulo 2, lidam com questes dessa rea (por exemplo, o
terceiro requisito, apresentado na pgina 47) e o restante deste trabalho, como
poder ser visto nos captulos a seguir, tambm considera alguns fatores humanos;
assim, entende-se que esses fatores esto sendo levados em conta.

4.3 Relatos de Experincias

Nesta seo, so apresentados alguns relatos de experincias de modelagem


de processos de desenvolvimento de software. Conforme explicado em captulos
anteriores, o NPI tem caractersticas parecidas com as de Micro e Pequenas
Empresas (MPEs), assim, foi dada nfase na pesquisa por relatos de experincias
nesse tipo de empresa. Entretanto, como tambm j foi citado anteriormente, h uma
grande carncia na literatura em relao a MPEs.

O trabalho apresentado por WEBER (2002) relata a experincia do


desenvolvimento de um modelo de processo de software para uma micro-empresa
incubada no Centro GeNESS (Centro de Gerao de Novos Empreendimentos em

82

Software e Servios), localizado na Universidade Federal de Santa Catarina, em


Florianpolis.
O modelo foi desenvolvido levando-se em conta as caractersticas da empresa
(composta por trs scios-desenvolvedores) e do tipo de software que ela produzia
(sistemas sob encomenda do tipo cliente-servidor para executar no ambiente WEB).
Ele possibilita a escolha entre trs tipos de modelos de ciclo de vida (ou adaptaes
deles) para cada projeto. O escopo total do modelo apenas o processo tcnico do
desenvolvimento de software: anlise de requisitos, projeto, implementao e testes.
O trabalho apresenta extratos do modelo, referentes a duas fases do processo:
levantamento de requisitos e anlise de requisitos. Cada fase possui um texto
introdutrio citando os objetivos, critrios de entrada e sada, descrio das
atividades, produtos de sada, papis envolvidos, mtodos e tcnicas utilizadas,
ferramentas utilizadas e mtricas importantes. Aps o texto, apresentado um
modelo dos documentos daquela fase.
Na publicao do trabalho, o modelo ainda no havia sido utilizado em sua
totalidade, mas a concluso do autor que o modelo o contribuiu significativamente
para melhorar o processo da empresa.

Em seu artigo, LIMA (2002) relata a experincia de utilizao de algumas


tcnicas e metodologias, consideradas atualmente como sendo estado da arte, por
uma empresa de sistemas e automao localizada em Belo Horizonte. A empresa
no pequena, mas o artigo foi escolhido por relatar a utilizao de alguns dos
modelos de avaliao citados na primeira seo deste captulo.

83

Utilizou-se "[...] o RUP [(Rational Unified Process)] como modelo de processo


de desenvolvimento de software [e] o CMM como modelo para melhoria do processo
[...]", ao mesmo tempo em que se tentava atender s diretrizes de qualidade da ISO
9001 (a empresa j utilizava o RUP em alguns projetos e j havia obtido certificao
ISO 9001 anteriormente). Para isso, foram implantadas algumas KPAs do nvel 2 do
CMM, foi definido e implantado um Processo Corporativo para Desenvolvimento de
Software (contendo diretrizes para sua adaptao a projetos com caractersticas
especficas), foi implantado um banco de mtricas de projetos, e foi realizado um
retreinamento da equipe tcnica e gerencial. Alem disso, criou-se um Grupo de
Garantia da Qualidade e um Grupo de Processos Engenharia de Software.
Para a implantao do novo processo, foi feita uma avaliao da situao atual
da empresa, um planejamento da implantao do processo (em nveis organizacional
e de projeto), a implantao em si, e finalmente, o acompanhamento e a avaliao
dos resultados. A implantao teve as seguintes etapas: desenvolvimento de guias
(ou manuais), treinamento e utilizao em um projeto piloto.
Com isso, a empresa obteve um novo certificado ISO 9001; melhorou o seu
controle de requisitos, de riscos, de mudanas e de qualidade; e o planejamento dos
projetos pde ser mais detalhado e realista.

O artigo apresentado por TAVARES, PAIM e CARVALHO (2002), apesar de


relatar a experincia de modelagem de processo em uma grande empresa,
interessante pois algumas de suas lies aprendidas so vlidas para organizaes
de todos os tamanhos. Os autores descrevem a estratgia da empresa para atingir o
nvel 2 do CMM, e as dificuldades e solues encontradas durante esse processo. A
estratgia descrita consiste em primeiro, conscientizar os membros da empresa de

84

que um processo disciplinado importante, depois treinar e implantar o processo, e


por ltimo, validar esse processo atravs da garantia da qualidade. Algumas das
concluses dos autores que podem ser aproveitadas para organizaes de todos os
tamanhos so:
*

considerar e aproveitar a infra-estrutura j existente de hardware e software;

no se deve implantar cada rea-chave separadamente, por que h uma forte


dependncia entre elas;

combater a tendncia dos desenvolvedores de ir diretamente para a fase de projeto


atravs do fortalecimento dos processos de requisitos;

a participao dos lderes de equipe e o apoio dos altos gerentes na implantao do


processo garantem o seu rumo na direo certa;

meios de documentao dos resultados, como sites de publicao, melhoram a


comunicao entre as equipes;

o envolvimento e aceitao do processo por parte do cliente melhora a aceitao do


processo por parte das equipes da empresa;

os profissionais da empresa capacitados em instituies acadmicas por meio de


especializaes ou ps-graduaes voltadas rea de qualidade de software tm
muito a contribuir para a empresa.
Outras concluses, porm, no so aplicveis a micro e pequenas empresas,
por exemplo: " imprescindvel a alocao de recursos para formao de grupos de
engenharia de software (SEPG) e de garantia de qualidade (GQS) [...]".
Uma concluso interessante dos autores, resumida uma frase, merece ser
destacada: "quando o processo trabalha para as pessoas, as pessoas trabalham
para o processo" (TAVARES, PAIM e CARVALHO, 2002).

85

Infelizmente, como j foi explicado na introduo deste trabalho, nenhum dos


artigos publicou o modelo de processo em si. Assim, no foi possvel uma avaliao
mais profunda dos modelos citados. Foi necessrio basear-se apenas nos dados
apresentados pelos autores dos artigos.

4.4 Discusso

Nesta seo so analisados os modelos de avaliao de processo e os relatos


de experincias apresentados, em relao expectativa de modelo para o NPI.
O Quadro 6 resume os modelos e experincias citados na seo anterior,
comparando-os com os requisitos do NPI para um modelo de processo, os quais
foram listados no captulo 2.

86

Requisitos do NPI para um E1 E2 E3 CMM


processo:
1 - Possuir um modelo de

processo para cada fase,

integrado a atividades de
gerncia administrativa e a
processos de gerncia de
configurao e controle de
documentos.
2- Definir um roteiro de
como realizar essas fases e

oferecer documentos padro


para os documentos a
serem produzidos.
3 - Ser voltado a pessoas

sem grande experincia e


conhecimento na rea de
Engenharia de Software, e
necessitar que elas passem
por pouco tempo de
treinamento para entender
como realizar o processo.
4 - Ser baseado no processo

existente, melhorando-o nos


seus pontos mais fracos.
5 - Ser adequado ao
contexto do NPI (escassez

de pessoal e de tempo,
oramentos pequenos, e
outras caractersticas
especficas de uma empresa
jnior).
6 - Facilitar e auxiliar o
trabalho colaborativo, por
?
intermdio ou no de
computador.
7 - Possuir um meio,
sistematizado e baseado
em
indicadores,
para
continuamente melhorar o
prprio modelo.

SPICE

ISO
9000-3

TSP

PSP

87

Legenda:
E1
E2
E3

Primeira experincia relatada (WEBER 2002)


Segunda experincia relatada (LIMA, 2002)
Terceira experincia relatada (TAVARES, PAIM e CARVALHO, 2002)
Atende ao requisito
Atende parcialmente ao requisito
No atende ao requisito
Dado no disponvel
Quadro 6: Comparao dos requisitos do NPI com outros modelos

Como pode ser visto no Quadro 6, nenhum dos modelos de avaliao nem os
modelos apresentados nos relatos de experincia atendem a todos os requisitos do
NPI para um modelo de processo de desenvolvimento de software.
Comparando os modelos, percebe-se que os relatados por WEBER (2002) e
LIMA (2002) so os que atendem o maior nmero de requisitos do NPI. Porm, os
dois requisitos principais do NPI (4 e 5) no so cumpridos por nenhum desses dois
modelos - nem pelos outros.
Tambm possvel perceber, que no fcil encontrar um modelo que seja
voltado a pessoas com pouca experincia e com pouco tempo para receber
treinamento.
Alm disso, a maioria dos modelos separa as atividades administrativas e
gerenciais das atividades de desenvolvimento, isso possvel em empresas com
recursos humanos suficientes para constituir equipes separadas de desenvolvimento
e de gerncia; mas em micro e pequenas empresas (que so as que mais se
assemelham com o NPI), devido ao nmero reduzido de funcionrios, as pessoas
que trabalham na gerncia so as mesmas que realizam as atividades de
desenvolvimento; assim, mais uma vez percebe-se por que os modelos
apresentados no Quadro 6 no so completamente adequados ao NPI.

88

Os modelos de avaliao no oferecem documentos padro nem definem um


roteiro de como realizar as fases do desenvolvimento, justamente por que eles so
modelos de avaliao e no de "realizao". J os modelos apresentados nas trs
experincias citadas, so modelos que sero utilizados para a realizao de um
processo e no somente para a sua avaliao - por isso, eles precisam definir
documentos padro e roteiros de como realizar as fases do desenvolvimento.
Portanto, esperado que os modelos de avaliao no satisfaam o requisito 2. O
TSP e o PSP definem um roteiro de como realizar as fases do desenvolvimento,
porm, o PSP no define documentos padres e para o TSP essa informao no
estava disponvel. Alm disso, o TSP e o PSP so modelos inviveis por que
requerem a presena de um especialista da SEI e muito tempo de treinamento.
Da mesma maneira, os modelos de avaliao, devido sua natureza, no
contm nenhuma metodologia para auxiliar o trabalho em grupo. Os relatos de
experincias no apresentam os modelos de uma maneira suficientemente
aprofundada para que se possa concluir sobre a sua influncia no trabalho em grupo.
O TSP, como o prprio nome j diz, foi criado para melhorar o trabalho em equipe,
portanto, natural que ele atenda completamente o requisito 6 do NPI. E o PSP,
tambm j explicado no seu nome, no se prope a facilitar o trabalho em equipe
mas sim o trabalho individual de um desenvolvedor.
A maioria dos modelos de avaliao considera importante que o processo de
desenvolvimento possua algum mecanismo (de preferncia baseado em dados
estatsticos) para que ele possa ser continuamente melhorado. Um exemplo o
CMM, onde as KPAs do nvel 5 so dedicadas mudana do processo. Porm, os
modelos de avaliao no dizem exatamente como fazer essas mudanas - e
nesse ponto que eles no atendem ao requisito 7 do NPI.

89

Assim, conclui-se que no h nenhum modelo que satisfaa completamente


todos os requisitos do NPI, e sim alguns modelos que satisfazem alguns requisitos e
outros modelos que satisfazem outros requisitos. Por esse motivo que se deve
elaborar um modelo de processo unicamente para o NPI e no simplesmente adotar
um modelo j existente.

90

5 O Modelo de Processo desenvolvido para o NPI

Neste captulo apresentado o modelo de processo desenvolvido para o NPI, o


qual o principal objetivo, e ao mesmo tempo resultado, deste trabalho. O modelo foi
desenvolvido especificamente para o NPI, a partir das anlises do processo existente
(presentes no captulo 2). Ele abrange todas as fases de um projeto tpico de
desenvolvimento de software do NPI (desde o primeiro contato com o cliente at a
entrega da verso final do software). Alm disso, ele contm documentos-padro,
que auxiliam e agilizam a realizao do processo. A sua produo foi baseada
inicialmente no modelo de ciclo de vida existente; a partir dele, foi concebido um
novo modelo de ciclo de vida, e ento, foi definido o contedo das fases. Tambm
foram realizadas algumas avaliaes informais de uma verso incompleta do
modelo, pelos membros do NPI, durante a sua produo. Terminada a elaborao de
todas as fases, o modelo foi apresentado informalmente aos diretores da empresa
jnior. Ele agora faz parte dos documentos do NPI (na forma de um manual
impresso) e referenciado pelo nome de "Manual do Processo de Desenvolvimento
de Software do NPI" (ou MPDS-NPI). O MPDS-NPI satisfaz a maioria dos requisitos
do NPI para um processo, e comparando-o com os modelos estudados no captulo 4,
ele satisfaz um nmero maior de requisitos do que os aqueles modelos.
O MPDS-NPI foi elaborado a partir do processo de desenvolvimento existente,
deduzido atravs da anlise de documentos produzidos em dois projetos e da
realizao de entrevistas com os membros da empresa jnior. A primeira verso do

91

modelo de ciclo de vida do MPDS-NPI foi baseada no modelo de ciclo de vida


existente (vide Figura 10, pgina 45). A partir desse novo modelo de ciclo de vida,
foram detalhadas as fases e suas atividades. Durante esse refinamento, o modelo de
ciclo de vida foi sendo alterado para se adequar ao paralelismo das fases. Tambm
durante esse processo, foram realizadas avaliaes informais (de uma verso
preliminar do modelo de processo) pelos membros do NPI, igualmente contribuindo
para a produo do modelo. Algumas fases no puderam ser baseadas no processo
existente, pois elas eram raramente executadas. Nesse caso, foram buscadas
metodologias na literatura, as quais foram adaptadas ao contexto do NPI. A parte de
gerncia e organizao da informao (um dos pontos fracos do processo existente)
bastante sistematizada no MPDS-NPI. Alm disso, o modelo de processo
desenvolvido tambm considera questes humanas (algumas delas, mencionadas
na seo 4.2 do captulo 4), como conscientizao da utilidade do modelo e imagem
passada ao cliente. As caractersticas do modelo e a sua elaborao, so temas que
sero aprofundados na seo 5.1 deste captulo.
Em relao ao contedo, o modelo de processo elaborado abrange todas as
fases de um projeto tpico de desenvolvimento de software do NPI - desde o contato
inicial do cliente at a entrega do software. Inicialmente, o MPDS-NPI apresenta um
texto introdutrio, seguido do modelo de ciclo de vida, e de um quadro-resumo de
cada uma das fases: Proposta, Contrato, Requisitos, Projeto, Implementao, Testes
e Entrega. Em seguida, cada fase detalhada em dois nveis de refinamento: no
primeiro, apresentado um quadro com todas as caractersticas da fase (Objetivos,
Atividades, Papis e Responsabilidades, Critrios de Entrada e de Sada, entre
outros); no segundo, essas Atividades - que so a parte mais importante da fase so explicadas em detalhe (por exemplo, com instrues de como preencher os

92

documentos, de quais ferramentas utilizar e de como aplicar as metodologias


sugeridas). Em ambos os nveis de refinamento, as atividades so sempre seguidas
ou precedidas de informaes sobre o seu paralelismo com atividades de outras
fases (por exemplo "em paralelo a esta atividade, os Analistas tambm realizam a
atividade 1 da fase de Testes"). Tambm fazem parte do MPDS-NPI, os documentospadro, que so documentos a serem preenchidos durante o desenvolvimento.
nesses

documentos que so registradas as informaes tanto tcnicas como

gerenciais do processo de desenvolvimento que est sendo executado (como por


exemplo, os diagramas de UML, o esquema do banco de dados, o cronograma do
projeto e o contrato com o cliente). Cada um desses documentos tem um nome e um
cdigo nicos, que os identificam, e pelos quais eles so referenciados em todo o
texto do modelo. O contedo do MPDS-NPI descrito com mais detalhes na seo
5.2 deste captulo.
O modelo desenvolvido atende maioria dos requisitos do NPI para um
processo (descritos na seo 2.4 do captulo 2, pgina 46): abrange todas as fases
de desenvolvimento de software no NPI, possui um roteiro, voltado a pessoas com
pouca experincia e tempo disponvel para treinamento, baseado no processo
existente e melhora os seus pontos mais fracos, relativamente adequado ao
contexto do NPI, auxilia um pouco o trabalho colaborativo e possui um meio para ser
modificado. E tambm, em relao aos requisitos do NPI para um modelo de
processo, o MPDS-NPI atende a um nmero maior de requisitos do que os modelos
apresentados no captulo 4. Na seo 5.3 deste captulo, essa comparao mais
bem explicada: apresentado o Quadro 9 (que a resume) seguido de uma
explicao detalhada de como o MPDS-NPI atende a cada requisito e de como ele
satisfaz certos requisitos que os outros modelos no satisfazem.

93

5.1 A elaborao do Modelo de Processo do NPI

Nesta seo, dada uma breve explicao das caractersticas e da elaborao


do modelo de processo desenvolvido para o NPI, o MPDS-NPI. Resumidamente, o
modelo foi elaborado de acordo com os seguintes passos: analisar o processo
existente; conceber um modelo de ciclo de vida a partir do modelo de ciclo de vida
existente; para cada fase, definir suas atividades (e outras caractersticas explicadas
mais adiante, como critrios de entrada e de sada, etc); e ento, descrever
detalhadamente as instrues de como realizar essas atividades. Uma das principais
caractersticas do MPDS-NPI a definio de polticas para a organizao de
documentos e para a gerncia de pessoas. Essas e outras caractersticas sero
apresentadas mais adiante. No prximo pargrafo, a explicao dos passos
seguidos na produo do modelo aprofundada.
Para a elaborao do modelo, foi inicialmente feito um estudo das
caractersticas da empresa jnior (formada somente por alunos) e de seus principais
problemas (alta rotatividade de pessoal e inexperincia deles em gerncia de
projetos e administrao de empresas). Em seguida, foi realizada uma anlise do
processo existente no NPI. Para isso, foram feitas entrevistas com os membros do
NPI envolvidos no processo de desenvolvimento da empresa jnior, e tambm foram
analisados os documentos produzidos durante dois projetos, que estavam em
finalizao no perodo da elaborao deste trabalho. A partir dessa anlise,
chegouse a um modelo de ciclo de vida, apresentado na Figura 10 (pgina 45) e

94

tambm se concluiu sobre as necessidades do NPI para um processo de


desenvolvimento de software. Esse estudo apresentado em detalhes no captulo 2.
O modelo (MPDS-NPI) foi elaborado procurando-se atender aos requisitos do
NPI para um processo (levantados no captulo 2), principalmente o de "ser baseado
no processo existente, melhorando-o nos pontos mais fracos" (vide pgina 47).
Ento, inicialmente, foi concebido um modelo de ciclo de vida baseado no
modelo de ciclo de vida existente. A partir desse novo modelo foram sendo
detalhadas as fases (e suas atividades), uma de cada vez. Mas durante essa
elaborao, percebeu-se um certo paralelismo entre algumas atividades de
determinadas fases (por exemplo, enquanto estava sendo desenvolvido o projeto
das classes da aplicao, poderia tambm ser realizado o projeto dos casos de
teste). Isso implicava em uma mudana do modelo de ciclo de vida para que ele
fosse ajustado a esse paralelismo (de acordo com o exemplo anterior, havia um
paralelismo entre uma atividade de projeto e uma atividade de teste). Assim, a cada
nova fase elaborada, o modelo de ciclo de vida era alterado. Portanto, o modelo de
ciclo de vida foi evoluindo ao longo dessa elaborao. Na Figura 21, apresentado o
modelo de ciclo de vida em sua concepo final.

95

Figura 21: Modelo de Ciclo de Vida proposto


Alm disso, durante a modelagem, foram feitas avaliaes informais de uma
verso preliminar do modelo de processo, pelos prprios membros do NPI. Durante
essa avaliao surgiram conceitos como, por exemplo, as trs opes de tipos de
arquitetura em camadas - esse conceito est presente na fase de Projeto.
Ainda em relao ao processo existente, a fase de Entrega foi baseada no
contrato padro do NPI, que especifica um perodo de testes de aceitao.
Porm, certas fases no puderam ser baseadas no processo existente. Elas
eram muito raramente realizadas, ou ento realizadas de uma maneira muito
informal. Ou seja, o processo existente apresentava falhas nessas fases ou
atividades. Isso foi detectado principalmente nas fases de Testes e de Gerncia.
Para alguns desses casos, foi necessrio buscar na literatura metodologias que se
adequassem ao contexto do NPI (ou ento adapt-las), para serem utilizadas no
processo. Entre as metodologias pesquisadas, destacam-se: o padro de projeto de
testes de casos de uso definido por BINDER (1999); o framework de testes sugerido

96

por BECK (1999); e a metodologia de desenvolvimento explicada em LARMAN


(2000).
Durante a elaborao do MPDS-NPI, tambm foi dada bastante ateno
gerncia e organizao da informao: foi definido o Documento de Padres, um
documento especial contendo os padres de codificao a serem utilizados na
implementao e as ferramentas a serem utilizadas para cada funo (ferramenta
CASE, processador de texto, etc); foi definido um cabealho padro para todos os
documentos do processo; foram definidas polticas para o controle de verses, de
alteraes e de armazenamento dos documentos. Ainda para a fase de Gerncia,
tambm foram definidas polticas de acompanhamento e superviso do trabalho e de
acompanhamento do cronograma. Estas atividades eram bastante ausentes no
processo existente, o que foi claramente constatado durante a anlise dos
documentos, dos dois projetos em andamento no perodo da elaborao deste
trabalho.
Finalmente, o modelo de processo desenvolvido contm ainda, em algumas
partes, consideraes sobre fatores humanos em projetos de software, como por
exemplo: sugestes do que dizer e de como se comportar diante do cliente; nfase
na responsabilidade do Diretor de Projetos, de conscientizar os Estagirios de que o
MPDS-NPI no uma imposio burocrtica e sim um guia para a realizao de um
projeto de software bem-sucedido; conselhos sobre como selecionar o Gerente do
projeto; entre outros. Alguns conceitos apresentados na seo 4.2 do captulo 4
tambm foram incorporados ao modelo, de uma maneira mais sutil. Portanto,
afirmase com convico que o modelo tambm possui uma nfase - mesmo que
pequena - em relaes humanas.

97

5.2 O Contedo do MPDS-NPI

O modelo de processo desenvolvido para o NPI abrange todas as fases de um


projeto tpico de desenvolvimento de software na empresa jnior (desde o primeiro
contato do cliente at a entrega da verso final do software), incluindo no s as
atividades tcnicas, como tambm as gerenciais. As atividades tcnicas esto
concentradas nas seguintes fases: Requisitos, Projeto, Implementao e Testes; e as
atividades gerenciais so abordadas nas fases de Proposta, Contrato, Entrega e principalmente - Gerncia. O Quadro 7 descreve de maneira sucinta os objetivos de
cada uma dessas fases.

Fase
Proposta
Contrato
Requisitos
Projeto
Implementao
Testes
Entrega
Gerncia

Objetivo
Realizar uma proposta de projeto para o cliente,
contendo estimativas de tempo e custo.
Negociar a proposta com o cliente.
Assinar o contrato com a Empresa cliente. Assinar
o contrato com os Estagirios.
Fazer a anlise mais detalhada dos requisitos.
Fazer o projeto do sistema de modo que ele possa
ser mapeado diretamente em cdigo.
A partir do projeto, escrever o cdigo.
Preparar os requisitos para o projeto dos casos de
teste.
Projetar e executar os casos testes
Entregar o software ao cliente.
Gerenciar o desenvolvimento do software.
Quadro 7: Resumo das fases do modelo

Esse quadro apresentado na introduo do MPDS-NPI, juntamente com a


Figura 21 (o modelo de ciclo de vida) e algumas outras explicaes. Aps a
introduo, para cada fase, so apresentados dois nveis de refinamento: o primeiro

98

um quadro com as caractersticas da fase e o segundo uma descrio detalhada


de cada atividade daquela fase.
O quadro das caractersticas da fase possui os seguintes itens: Nome,
Objetivos, Atividades, Entradas, Sadas, Papis e Responsabilidades, Critrios de
Entrada, Critrios de Sada. Cada uma dessas caractersticas explicada no Quadro
8, cuja estrutura o modelo do quadro das caractersticas.

Nome

Nome da fase.

Objetivos

Objetivos gerais (e resumidos) da fase.

Atividades

Enumerao das atividades da fase e o seu paralelismo


com outras atividades de outras fases.

Entradas

Documentos (produzidos em outras fases) que so


necessrios para que se possam iniciar as atividades
desta fase.

Sadas

Documentos produzidos na fase.

Papis e
Responsabilidades

Listagem dos papis que participam da fase e suas


responsabilidades (i.e. as atividades que eles iro
realizar).

Critrios de Entrada

Condies que devem ser atendidas para que se possa


iniciar a fase (por exemplo, documentos que devem estar
completos, ou informaes que devem estar presentes em
determinados documentos, etc).

Critrios de Sada

Condies necessrias para que se possa considerar a


fase como terminada (muitas vezes, so simplesmente os
critrios de entrada da fase seguinte).

Quadro 8: Explicao das caractersticas de uma fase

99

Para ilustrar ainda melhor essa forma de modelagem das fases, apresentado
o quadro das caractersticas da fase de Requisitos, no Quadro 9.

Nome

Requisitos

Objetivos

Fazer a anlise mais detalhada dos requisitos.

Atividades

(em paralelo a esta fase, o Gerente do Projeto realiza as


atividades 6, 7, 8, 9, 10 e 11 da fase de Gerncia; e o
Diretor de Projetos realiza as atividades 12 e 13 dessa
mesma fase)
1
- Os Analistas fazem a reunio de anlise dos
requisitos com o cliente.
(em paralelo a esta atividade, os Analistas tambm
realizam a atividade 1 da fase de Testes)
2
- Os Analistas levantam os Casos de Uso (DT002) a partir das anotaes da reunio da atividade 1 e
do DT-001. E ao mesmo tempo, levantam as operaes
do sistema e (opcionalmente) elaboram o modelo
conceitual (parte do DT-003).
2.1 - Levantar os Casos de Uso.
2.2 - Levantar as Operaes de Sistema.
2.3 - Elaborar o Modelo Conceitual. (opcional)
(em paralelo a esta atividade, os Projetistas realizam a
atividade 1 da fase de Projeto)
3
- Os Analistas priorizam os casos de uso e
dividem o sistema em incrementos.
4
- Os Analistas fazem a reviso dos requisitos
levantados, com o cliente. Nesta ocasio eles tambm
resolvem as dvidas do Documento de Dvidas
(DG006).

100

Entradas

- Documento de Requisitos (DT-001).


- Documento de Pr-Planejamento do Projeto (DG-002).

Sadas

- Casos de Uso, DT-002 (contendo: casos de uso


essenciais, sua priorizao e alocao para os
incrementos e operaes do sistema).
(opcional) - Diagramas da Anlise, DT-003 (contendo o
diagrama dos casos de uso, o modelo conceitual e os
diagramas de seqncia).

Papis e
Responsabilidades

- Analista:
*
analisar os requisitos com o cliente;
*
documentar os requisitos (atravs de casos de uso
essenciais, modelo conceitual (opcional) e operaes do
sistema);
*
apresentar e explicar os requisitos ao cliente para a
sua aprovao.

Critrios de Entrada

- Contrato NPI-Empresa (DG-004) e Contrato


NPIEstagiarios (DG-005) assinados.

Critrios de Sada

- DT-002 e DT-003 (caso se opte por produzir algum(ns) de


seus diagramas) completos e aprovados pelo cliente.

Quadro 9: Fase de Requisitos


Alm do quadro das caractersticas (exemplificado no Quadro 9), a modelagem
de uma fase inclui tambm a descrio detalhada de todas as suas atividades.
Nessa descrio constam informaes como: o que deve ser realizado, qual
ferramenta deve ser utilizada, quais tcnicas ou metodologias devem ser adotadas,
quais documentos sero produzidos, se esses documentos estaro prontos nesta
atividade ou s sero completados em outra atividade posterior, exemplos de como
preencher os documentos, entre outras.

101

A ttulo de exemplo, apresentado no Quadro 10, o detalhamento da atividade


1 da fase de Requisitos.

1 - Os Analistas fazem a reunio de anlise dos requisitos com o cliente.


importante explicar ao cliente que essa reunio tem como objetivo o NPI entender
o que o cliente quer que o sistema faa, e que esse entendimento depende de quo
bem os requisitos so analisados.
Essa reunio deve ser realizada com os futuros usurios do sistema, ou seja, os
atuais usurios do sistema existente.
Nesta atividade deve-se estudar o sistema (informatizado ou no) existente, tendo
como objetivo descobrir os casos de uso, utilizando as seguintes tcnicas
(SOUZA e SILVA, 2003):
ler os documentos utilizados (caso sejam relevantes) e colet-los ou tirar cpias
(caso isso seja possvel);
observar o ambiente de trabalho (i.e. as atividades realizadas pelos usurios); realizar algumas entrevistas informais.
Durante as entrevistas e as observaes, devem ser realizadas anotaes por
melhor que seja a memria.
Para sistemas pequenos, uma reunio de trs horas deve ser suficiente. Para
sistemas mdios, podem ser necessrias at uma ou duas reunies a mais.
Deve ser informado ao cliente, que aps a formalizao dos requisitos, ser feita
uma nova reunio para que ele aprove os requisitos, em forma de Casos de Uso e
Interfaces Grficas com o Usurio, ou GUIs (Graphical User Interfaces).
Quadro 10: Detalhamento da atividade 1 da fase de Requisitos
Ainda sobre as atividades de cada fase, em ambos os nveis de refinamento
(tanto no quadro de caractersticas como na explicao detalhada), constam
informaes sobre o paralelismo ou seqncia das atividades: antes de uma
atividade, explicado se existe outra atividade com a qual ela deve ser
paralelamente executada ou se existe uma outra atividade que deve ser executada
antes dela; aps uma atividade, explicado se deve ser realizada alguma atividade
de outra fase depois dela. O Quadro 11 mostra essas trs situaes.

102

....
(em paralelo a esta atividade, os Projetistas realizam a atividade 1 da fase de
Projeto)
3 - Os Analistas priorizam os casos de uso e dividem o sistema em
incrementos.
....
1 - Os Programadores preparam o instalador do software e elaboram o Manual
de Instalao.
(aps essa atividade, o Gerente do Projeto realiza a atividade 15 da fase de
Gerncia)
....
(realizada aps a atividade 6 da fase de Entrega)
17 - O Gerente do Projeto e os outros Estagirios elaboram o Documento de
Fim de Projeto (DG-013).
...
Quadro 11: Exemplos de informaes sobre o paralelismo das atividades
Aps a apresentao das fases nos dois nveis de detalhamento, o MPDS-NPI
apresenta ainda, uma lista de sugestes de melhorias a serem feitas no modelo e
tambm algumas referncias bibliogrficas, tanto das metodologias utilizadas no
modelo como de leituras que podem auxiliar a sua compreenso.
Alm do texto do modelo - cuja parte principal a descrio das fases
(caracterizada pelo quadro das caractersticas e pelo detalhamento das atividades) o MPDS-NPI tambm inclui os documentos-padro, que so documentos a serem
preenchidos durante as atividades. Eles so listados como entradas e sadas de
cada fase, por exemplo, na fase de Requisitos, as sadas so os Casos de Uso
(DT002) e os Diagramas da Anlise (DT-003). Nos documentos-padro, constam as
informaes (tanto tcnicas como gerenciais) resultantes do processo, por exemplo,
a listagem das seqncias dos casos de uso, os diagramas de projeto, o esquema
do banco de dados, o cronograma do projeto, a linguagem de programao
escolhida para aquele projeto, entre outras. Todos os documentos-padro possuem
um nome e um cdigo nicos, pelos quais eles so referenciados em todo o texto do

103

modelo (o cdigo do documento Diagramas da Anlise, por exemplo, DT-003). DT


significa que o documento um Documento Tcnico e DG um Documento Gerencial,
o nmero que segue essa sigla foi dado na ordem em que os documentos foram
sendo criados. Essas siglas foram utilizadas de acordo com a definio do conceito
de documento estabelecida no captulo 3 (pgina 62). O Quadro 12 mostra todos os
nomes dos documentos-padro e seus respectivos cdigos.
Cdigo
DG-001
DG-002
DG-003
DG-004
DG-005
DG-006
DG-007
DG-008
DG-009
DG-010
DG-011
DG-012
DG-013
DG-014
DG-015
DT-001
DT-002
DT-003
DT-004
DT-005
DT-006
DT-007
DT-008
-

Nome
Ficha de Pr-Projeto
Documento de Pr-Planejamento do Projeto
Proposta de Projeto
Contrato NPI-Empresa
Contrato NPI-Estagirios
Documento de Dvidas
Documento de Aceitao
Formulrio de Erros
Documento de Padres
Documento de Acompanhamento do Trabalho
Relatrio de Progresso do Trabalho
Documento de Alterao da Data de Entrega
Documento de Fim do Projeto
Documento de Mudanas do Modelo
Plano do Projeto
Documento de Requisitos
Casos de Uso
Diagramas da Anlise
Diagramas de Projeto
Esquema do Banco de Dados
Script do Banco de Dados
Decises de Projeto
Documento de Testes
Cdigo-fonte do programa
Cdigo-fonte dos casos de testes
Sistema de Ajuda
Manual de Instalao
Software executvel
Quadro 12: Documentos-padro e seus cdigos

Todos esses documentos padro possuem instrues no modelo de como eles


devem ser preenchidos. Alm disso, o modelo tambm define em qual atividade a

104

primeira verso do documento est pronta, para cada documento. Desse modo, a
numerao das verses pode ser feita de maneira precisa e sistematizada.
Os documentos tambm possuem um cabealho padro, para facilitar a sua
identificao. Esse cabealho contm nmero e nome do projeto, nome do cliente,
verso do documento, fase e nmero do incremento onde ele foi produzido e a data
em que ele foi produzido. Algumas partes desse cabealho so as mesmas para
todo o projeto, mas outras so diferentes para cada documento. O Quadro 13 mostra
o modelo do cabealho-padro, com as explicaes de como preench-lo. Esse
modelo de cabealho (seguido de algumas explicaes) est presente no MPDS-NPI
na sua parte introdutria.
Cdigo do Documento - Nome do Documento
Nmero do Projeto:
No formato XXX/AAAA. Para cada projeto que se iniciar
na fase Proposta - mesmo que depois ele no seja
realizado - dar um nmero em seqncia (isso permitir
uma estimativa de "projetos realizados" / "projetos
propostos"). A cada ano deve-se reiniciar a contagem.
Projetos diferentes para um mesmo cliente devem ter
numerao diferente.
Nome do Projeto:
Escolher um nome para o projeto. Caso se decida mudar
o nome do projeto, deve-se lembrar de mudar esse
campo em todos os artefatos.
Cliente:
Colocar aqui o nome do cliente.
Verso:
Numerar as verses em seqncia: 1, 2, 3, etc. (mais
informaes na atividade 4 da fase de Gerncia)
Fase e nmero do
A fase, e se for aplicvel, tambm o nmero do
incremento:
incremento ao qual o documento pertence.
Data:
Data em que foi terminada a produo ou modificao do
documento. Ao mudar a verso, deve-se mudar a data
tambm.
Quadro 13: Modelo do cabealho-padro
Para exemplificar o preenchimento de um cabealho, o Quadro 14 mostra um
exemplo de cabealho para a Proposta de Projeto. Esse exemplo tambm est
presente no texto introdutrio do MPDS-NPI.

105

Nmero do Projeto:
Nome do Projeto:
Cliente:
Verso:
Fase e nmero do
incremento:
Data:

DG-003 - Proposta de Projeto


002/2003 (2o projeto de 2003)
Projeto Nortia II
Nortia Consultores
4
Proposta
30 / 05 / 2003
Quadro 14: Exemplo de cabealho preenchido

Cada documento possui um contedo diferente, de acordo com o seu


propsito. A maioria dos documentos possui quadros a serem preenchidos ou
perguntas a serem respondidas. Isso permite um preenchimento rpido do
documento e um melhor esclarecimento das informaes que nele devem constar.
Para tornar um pouco mais claro o contedo e a forma dos documentos, exibido
como exemplo o Documento de Requisitos no Quadro 15.

106

NCLEO DE PROJETOS EM INFORMTICA

Documento de Requisitos

DT-001 - Documento de Requisitos


Nmero do Projeto:
___/20__
Nome do Projeto:
Cliente:
Verso:
Fase e nmero do incremento:
Proposta
Data:
__ / __ / 20__

1. Requisitos
ID
R.1
O sistema deve ...
R.2
O sistema deve ...
...
R.n
O sistema deve ...
2.Glossrio (opcional )
Palavra
ononono
...

Descrio

Significado
onononononono
...

Quadro 15: Um exemplo de documento padro


Alguns documentos, possuem instrues de como eles devem ser preenchidos
e exemplos de como preench-los (para outros documentos, todas as instrues de
como preenche-los esto presentes no prprio texto do MPDS-NPI). No exemplo do

107

Quadro 15, o "(opcional)" em cinza uma instruo que indica que o Documento de
Requisitos no precisa necessariamente possuir um glossrio.
Pelo fato de que o modelo (MPDS-NPI) na ntegra muito extenso, ele no
ser apresentado aqui. Porm, ele est disponvel como um anexo deste trabalho
em meio digital (disquete) e tambm no NPI (NCLEO DE PROJETOS EM
INFORMTICA, 2003).

5.3 Discusso

Aps a apresentao do modelo (suas caractersticas e seu contedo), bem


como os mtodos utilizados para a sua elaborao, pode-se inferir sobre os seus
benefcios para o NPI.
O modelo possui muitas qualidades que foram caracterizadas como
importantes para o NPI (por exemplo, ter sido produzido especialmente para essa
empresa jnior, ser voltado a pessoas com pouca experincia, entre outras). Por
possuir todas essas caractersticas (que os modelos avaliados no captulo 4 no
possuem), pode-se concluir que o modelo adequado ao NPI.
Entre as principais vantagens do MPDS-NPI em relao aos outros modelos
estudados no captulo 4, pode-se citar:
*
*

abrange tanto atividades tcnicas como gerenciais;


possui um roteiro de como realizar cada uma das fases do processo de
desenvolvimento;

voltado a pessoas com pouca experincia e tempo disponvel para treinamento;

108

baseado no processo existente e melhora os seus pontos mais fracos; * mais


adequado ao contexto do NPI.
Comparando o modelo desenvolvido com as necessidades do NPI (os

requisitos listados no final do captulo 2) e os modelos de avaliao e modelos


apresentados nos relatos de experincias (ambos citados no captulo 4), pode-se
concluir que o MPDS-NPI atente maioria dos requisitos e ainda, que ele atende a
um nmero maior de requisitos do que os modelos estudados no captulo 4.
O Quadro 16 apresenta essa comparao com um pouco mais de detalhes (as
caractersticas do modelo desenvolvido esto destacadas em vermelho). E, em
seguida, ele discutido minuciosamente.

Requisitos do NPI
para um processo:
1 - Atividades tcnicas
e gerenciais
2- Existncia de um
roteiro e
documentospadro
3 - Pouca
necessidade de
experincia
4 - Baseado no
processo existente
5 - Adequado ao
contexto do NPI
6 - Facilitar o trabalho
colaborativo
7 - Sistematicamente
modificvel
Legenda:
E1
E2
E3
MPDS-NPI

E1

E2

E3

CMM

SPICE

ISO
9000-3

TSP

PSP MPDSNPI

Primeira experincia relatada (WEBER 2002)


Segunda experincia relatada (LIMA, 2002)
Terceira experincia relatada (TAVARES, PAIM e CARVALHO, 2002)
O modelo desenvolvido neste trabalho
Atende ao requisito
Atende parcialmente ao requisito
No atende ao requisito

109

Dado no disponvel

Quadro 16: Comparao dos requisitos do NPI com os modelos do captulo 4 e o


modelo desenvolvido
Observando o Quadro 16, pode-se perceber que a maioria dos requisitos
planejada inicialmente para o modelo foi cumprida.
A fase de Gerncia possui atividades de gerncia administrativa, gerncia de
configurao e processos de controle de documentos. Essas atividades no so
muito complexas, elas so o mnimo necessrio para que se possa considerar que
existe uma gerncia administrativa, de configurao e de documentos.
Como j foi explicado, o modelo define uma srie de documentos-padro que
devem ser preenchidos ao longo do desenvolvimento.
O modelo voltado para os alunos dos cursos de Cincias da Computao e
Sistemas de Informao da UFSC, a nica exigncia do modelo que os alunos j
tenham cursado a disciplina de Engenharia de Software e/ou Anlise e Projeto de
Sistemas. Portanto, o modelo claramente voltado para pessoas com pouco
conhecimento e experincia em desenvolvimento sistematizado de software.
Tambm, como j foi explicado anteriormente, o modelo foi inteiramente
baseado no processo existente e melhorou-o nos seus pontos mais fracos.
O modelo adequado ao contexto do NPI, dentro do possvel. Acredita-se que
esse requisito poder ser ainda melhor atendido em verses posteriores do modelo.
Quanto ao trabalho colaborativo, o modelo um facilitador no sentido de que
ele define uma poltica de alterao de documentos j existentes e armazenamento
dos documentos recm produzidos (o Gerente do Projeto centraliza essas
atividades). Porm, ao mesmo tempo, o modelo no to facilitador quanto

110

desejado pelos membros do NPI, pois tudo depende do Gerente e da sua


disponibilidade para enviar e receber os documentos.
Para a modificao do modelo, no h uma metodologia ou poltica baseada
em indicadores como foi idealizada. H apenas uma poltica um tanto simples, mas
que j bem melhor do que no haver poltica nenhuma: as modificaes no modelo
devem ser justificadas por escrito e devem ser armazenadas juntamente com a
verso anterior do modelo.
Assim, pode-se concluir que o modelo desenvolvido bastante satisfatrio em
relao aos requisitos que haviam sido propostos inicialmente.

Em comparao aos modelos citados no captulo 4, os requisitos 4 e 5, que no


foram atendidos por nenhum dos modelos, so bem atendidos pelo modelo
desenvolvido.
Outra caracterstica exclusiva do modelo produzido que ele voltado a
pessoas com pouca experincia em desenvolvimento sistematizado de software.
Como explicado no captulo anterior, nenhum dos modelos analisados satisfazia a
esse requisito.
O modelo apresentado neste trabalho, apesar de tambm separar as atividades
administrativas das atividades de desenvolvimento, adequado ao contexto do NPI
porque essas duas atividades so realizadas por pessoas da mesma equipe,
pessoas que esto trabalhando juntas diariamente (e no pessoas de departamentos
diferentes, que se encontram somente em reunies mensais, ou no mximo,
semanais).
Em relao aos requisitos 6 e 7, um dos objetivos futuros do modelo de
processo desenvolvido adaptar ao contexto do NPI algumas das caractersticas

111

presentes nos modelos de avaliao (em termos do requisito 7) e no TSP (em termos
do requisito 6), de uma maneira semelhante explicada no pargrafo acima.
Assim, aps apresentao e discusso de todos os benefcios que o modelo
produzido neste trabalho traz para a empresa jnior, conclui-se que ele adequado
ao NPI.

112

6 Avaliao do Modelo

Com o objetivo de avaliar a aplicabilidade do modelo e os seus pontos fortes e


fracos no NPI, apresentado o plano para a avaliao do modelo.
Esse plano ser executado em paralelo utilizao do modelo pelo NPI em um
projeto piloto. Como no decorrer deste trabalho, no se iniciou nenhum novo projeto
na empresa jnior, a execuo do plano de avaliao no foi possvel.
Por esse motivo, o presente captulo apresentar principalmente o plano de
avaliao, e abordar brevemente a sua execuo.

6.1 O Plano da Avaliao

O plano da avaliao foi realizado com base na metodologia GQM (Goal


Question Metric - Meta Pergunta Medida). Essa metodologia, como o prprio nome j
diz, orientada a metas, e serve para mensurao tanto de produtos como de
processos de software. "Esta abordagem segue a definio de medidas relevantes
top-down via metas, perguntas e modelos e a anlise e interpretao bottom-up dos
dados coletados [...]."(ANACLETO, 2001, p.18)

113

Ela define um modelo de processo, isto , uma srie de passos a serem


seguidos, para a realizao das medies e da avaliao dos resultados, so eles
(WANGENHEIM, 1999):
*

estudo prvio da organizao (incluindo a elaborao de um modelo de


processo descritivo, caso seja necessrio);

identificao das Metas GQM (ou seja, os objetivos do estudo);

desenvolvimento do Plano GQM (descrevendo a meta GQM em detalhes);

desenvolvimento do Plano de Mensurao (contendo informaes como:

quem ir realizar as medies, quando elas sero realizadas, etc);


*

coleta de dados;

anlise e interpretao dos dados (incluindo reunies de feedback);

e captura de experincias (por exemplo, definio de padres para a


organizao).
O objetivo geral da avaliao medir a contribuio do MPDS-NPI para um

processo de desenvolvimento de software mais produtivo e de melhor qualidade. A


partir desse objetivo e da descrio do processo existente no NPI (apresentado no
captulo 2), foram definidas as metas GQM: qualidade, durao e gerncia dos
projetos.
Essas metas foram ento refinadas num documento que o GQM chama de
Abstraction Sheet (folha de abstrao), que consiste em um quadro com as
seguintes informaes: fatores de qualidade (o qu ser medido), fatores de variao
(elementos que influenciam nos fatores de qualidade), hiptese de linha base antes e
depois (como o processo estava antes da aplicao do MPDS-NPI e como se supe
que ele estar aps a sua aplicao) e impacto na hiptese de linhabase (como os
fatores de variao exercem a sua influncia). Alm disso, na parte superior do

114

quadro, deve estar presente a identificao da meta GQM, a qual inclui: o objeto
(sendo avaliado), o objetivo (da avaliao), o enfoque da qualidade (i.e. as metas), o
ponto de vista (ou seja, quem utilizar os dados coletados) e o contexto (em qual
empresa e/ou projeto est sendo feita a avaliao).
Foram elaboradas duas abstraction sheets, uma para as metas Qualidade e
Durao (pois ambas esto relacionadas) e outra para a meta Gerncia. Para cada
item da primeira abstraction sheet, foram separados os dados que pertencem meta
Qualidade e os que pertencem meta Durao. O Quadro 17 apresenta um extrato
dessa primeira abstraction sheet (para tornar o exemplo mais claro, foram mostrados
somente os dados da meta Qualidade). As duas abstraction sheets produzidas
encontram-se completas no Apndice B.

115

Objeto

Objetivo

Enfoque da
Qualidade
Qualidade e
Durao

Modelo de
Avaliar
Processo
Fatores de Qualidade
Qualidade:
- Consistncia entre requisitos e projeto
- Consistncia entre projeto e implementao
- Sistematizao da produo dos documentos
...

Ponto de Vista

Contexto

Pesquisador

NPI

Fatores de Variao
Qualidade:
Comprometimento e conscientizao da equipe
de desenvolvimento da necessidade de
utilizao de tcnicas de engenharia de software
Experincia da equipe em desenvolvimento de
software
...

Hiptese de Linha-Base
Antes
Qualidade:
O nvel de
consistncia entre os
requisitos e o projeto
Baixo.
O nvel de
consistncia entre o
projeto e a
implementao Baixo.
- No h uma ordem
para a produo dos
documentos.

Depois (Hiptese)
Qualidade:
O nvel de consistncia
entre os requisitos e o
projeto Alto.
O nvel de consistncia
entre o projeto e a
implementao Alto. H um modelo de
processo que determina
a ordem de produo
dos documentos e essa
ordem seguida.

...

...

Impacto na Hiptese de Linha-Base


Qualidade:
experincia em desenvolvimento de software:
consistncia entre requisitos e projeto
consistncia entre projeto e implementao
comprometimento e conscientizao da
necessidade de utilizar tcnicas de engenharia
de software consistncia entre requisitos e
projeto consistncia entre projeto e
implementao produo sistematizada de
documentos
...

Quadro 17: Abstraction Sheet para a meta Qualidade

O plano GQM, resumido nas abstraction sheets, foi ento detalhado em forma
de perguntas. Essas perguntas tambm so definidas no processo GQM. A
apresentao do plano GQM em forma de perguntas auxilia a sua compreenso. As
perguntas mostram diretamente como sero medidos: os fatores de qualidade, os
fatores de variao, e a influncia dos fatores de variao nos fatores de qualidade.
Para ilustrar essa explicao, no Quadro 18 so apresentadas algumas das
perguntas GQM para as metas Qualidade e Durao.

116

Definio das Variaes


Q1) A experincia da equipe em desenvolvimento de software tem um impacto na consistncia entre
os requisitos e o projeto?
Hiptese: quanto mais experincia a equipe possui em desenvolvimento de software, maior ser a
consistncia entre os requisitos e o projeto.
Q1.1) Qual a experincia da equipe em desenvolvimento de software?
Modelo: a experincia da equipe deve ser a mdia aritmtica das experincias de todos os
membros da equipe.
M1.1 experincia da equipe [ordinal:
"Grande (trabalhou na rea mais de 4 anos)";
"Mdia (trabalhou na rea entre 2 e 4 anos)";
"Pequena (trabalhou na rea menos de 2 anos)"].
Hipteses Antes e Depois: a equipe possui uma experincia Mdia.
Q2) A experincia da equipe em desenvolvimento de software tem um impacto na consistncia entre
o projeto e a implementao?
Hiptese: quanto mais experincia a equipe possui em desenvolvimento de software, maior ser a
consistncia entre o projeto e a implementao.
...
Definio da Qualidade
...
Q10) Qual o grau de sistematizao da produo dos documentos?
Modelo: esse grau pode ser medido pela existncia ou no de um processo sistematizado para a
produo e por sua utilizao ou no.
M10.1 existncia de um processo sistematizado [ordinal:
"Existe um modelo de processo";
"Existe uma ordem documentada
informalmente"; "Existe uma ordem nodocumentada"; "No existe uma ordem"].
Hiptese Antes: no existe uma ordem para a produo dos documentos.
Hiptese Depois: h um modelo de processo que determina a ordem de produo dos documentos.
M10.2 utilizao da ordem [ordinal: seguida; no seguida].
Hiptese Antes: como no existe ordem, ela no seguida.
Hiptese Depois: a ordem seguida.

...
Quadro 18: Exemplos de perguntas do Plano GQM

As perguntas dividem-se em dois tipos: definio das variaes (que so as


perguntas sobre os fatores de variao) e definio da qualidade (que so as
perguntas sobre os fatores de qualidade).

117

Para a definio das variaes, a primeira pergunta (Qn) busca confirmar (ou
negar) o impacto na hiptese de linha-base definido na abstraction sheet - esse
impacto repetido abaixo da pergunta (em "Hiptese:"). Assim, a pergunta Q1 busca
confirmar a hiptese de que a experincia da equipe influencia na consistncia entre
os requisitos e o projeto. Para tornar a medio mais precisa, as sub-perguntas
(Qn.m) quantificam o fator de variao (seguindo o exemplo, a sub-pergunta Q1.1
quantifica a experincia da equipe). Na definio da qualidade, a primeira pergunta
(Qn) j quantifica o fator de qualidade.
O "Modelo:" define como o fator de variao (ou de qualidade) deve ser
calculado (ainda para o exemplo de Q1.1, o "Modelo:" define que a experincia da
equipe deve ser calculada realizando-se a mdia aritmtica da experincia de cada
membro da equipe). Finalmente, tem-se a medida (Mn.m) do fator de variao (ou de
qualidade), que pode ser do tipo ordinal, racional, inteiro, intervalo, entre outros (mais
informaes em WANGENHEIM, 1999, p.16), e cujos valores possveis so
colocados aps o ":". Como o plano GQM desenvolvido avaliar um processo, o tipo
da maioria das medidas ordinal. Para cada medida, tambm so repetidas as
hipteses antes e depois - definidas na parte "Hiptese de Linha-Base" da
abstraction sheet. Para a definio da qualidade, todas as perguntas derivam uma ou
mais medidas, enquanto que, para a definio das variaes, algumas perguntas
podem no derivar medida nenhuma.
A partir das medidas definidas nesse plano GQM, foi elaborado o Plano de
Mensurao. Ele contm informaes sobre quando coletar as medidas, quem ir
colet-las e como elas sero coletadas. Em relao informao de "como coletar",
o plano de mensurao tambm inclui roteiros para as entrevistas, nas quais os

118

dados sero coletados. O plano de mensurao desenvolvido apresentado no


Quadro 19.

Nmero

Medidas
Associadas
M1.1, M3.1,
M3.2

Descrio

Tempo

Papel

Instrumento

relao da equipe
com a ES

Pesquisador

Entrevista com a
Equipe de
Desenvolvimento

M6.1, M7.1

relao da equipe
com estimativas

Pesquisador

Entrevista com os
Diretores

Inspeo dos
Documentos

aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

M11.1, M11.2

consistncia entre
requisitos, projeto e
implementao
sistematizao da
produo dos
documentos
atraso do projeto

Pesquisador

M8.1, M9.1,
M9.2, M9.3,
M9.4
M10.1, M10.2

aps a
atividade 5
da fase de
Contrato
aps a
atividade 4
da fase de
Proposta
aps o fim
do projeto

Pesquisador

M12.1

M15.1

Inspeo dos
Documentos
Entrevista com o
Gerente
Entrevista com os
Diretores

M17.1, M17.2,
M17.3

aps o fim
do projeto
aps o fim
do projeto
aps a
atividade 4
da fase de
Proposta
aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

M18.1, M18.2,
M18.3

aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

10

M19.1, M19.2

aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

dedicao do
gerente ao projeto
durao estimada
do projeto

nvel de controle
das verses dos
documentos
nvel de
planejamento e
controle do
cronograma
nvel do
acompanhamento
do trabalho

Pesquisador
Pesquisador

Quadro 19: Plano de Mensurao

Para cada grupo de medidas associadas, foi planejado um instrumento de


coleta de dados. A maioria dos instrumentos planejados, so entrevistas, mas h
tambm uma inspeo de documentos, que, sendo realizada pelo pesquisador, o
modo mais vivel de coletar esses dados. Para cada tipo de entrevista, foi definido

119

um roteiro de como realiz-la. Para exemplificar, um desses roteiros apresentado


no Quadro 20.

Roteiro para a entrevista com a Equipe de Desenvolvimento (Gerente e os outros Estagirios)


Essas perguntas devem ser realizadas a todos os Estagirios ao mesmo tempo. Eles devem entrar
em consenso (dentro do possvel) e escolher uma das respostas.
1 - (M1.1) Qual a experincia de vocs em desenvolvimento de software? (fazer uma mdia aritmtica
das experincias de cada Estagirio)
a) Grande (j trabalharam na rea por mais de 4 anos)
b) Mdia (j trabalharam na rea entre 2 e 4 anos)
c) Pequena (j trabalharam na rea por menos de 2 anos)
2 - (M3.1) Qual a importncia que vocs vem na utilizao de tcnicas de ES para
o desenvolvimento de software no NPI? a) importante
b) no importante
3 - (M3.2) Vocs continuariam utilizando a tcnica mesmo diante de acontecimentos crticos
(como atraso no cronograma) ? a) sim
b) no

Quadro 20: Um dos roteiros para entrevista


Facilitando ainda mais a coleta, o nmero de cada medida associada com a
pergunta da entrevista, est entre parnteses antes da pergunta.
Tambm foi definido um roteiro para a inspeo dos documentos, com questes
a serem respondidas durante a inspeo.
Devido extenso do plano de avaliao (desde as abstraction sheets at os
roteiros das entrevistas), ele no apresentado integralmente nesta seo. Mas,
para melhorar a sua compreenso, ele encontra-se completo no Apndice B.

120

6.2 Execuo da Avaliao

Durante o perodo de elaborao deste trabalho, no foi possvel a aplicao


do modelo no NPI, pois no surgiram novos projetos (e se um projeto, no h como
utilizar o modelo). Porm, com o plano de avaliao completamente definido, esse
estudo da avaliao do modelo previsto para ser realizado no futuro (quando se
iniciar um novo projeto na empresa jnior).

121

7 Concluso

O principal resultado deste trabalho, um modelo de processo de


desenvolvimento de software para o NPI. Tambm so importantes o plano de
avaliao do modelo e o levantamento do processo existente.
Para obteno desses resultados, inicialmente foi realizada uma pesquisa
bibliogrfica, voltada para a rea de modelagem de processo, e tambm, foi
analisado o processo de desenvolvimento de software existente no NPI - essa
anlise foi o primeiro resultado deste trabalho. A partir disso, foi elaborado o modelo
de processo de desenvolvimento do NPI - que foi o segundo, e mais importante,
resultado obtido neste trabalho. Em seguida, foi tambm elaborado um plano de
avaliao desse modelo - o terceiro resultado -, que s no foi executado por que
no se iniciaram projetos no NPI nesse perodo.
Entretanto, mesmo no tendo a oportunidade de avaliar o modelo desenvolvido
num projeto piloto no NPI - no decorrer deste trabalho - analisando (em teoria) os
requisitos do NPI em relao ao modelo desenvolvido, pode-se observar que:
*

o modelo desenvolvido possui descries detalhadas de como realizar um projeto caracterstica declarada nos primeiros dois requisitos (pgina 47 do captulo 2).

ele define polticas e documentos que auxiliam a comunicao, coordenao e


organizao das atividades e dos resultados das fases - exigncia dos dois primeiros
e dos dois ltimos requisitos (pginas 47 e 48);

122

ele voltado para as necessidades (por exemplo, utilizao de software grtis) e


caractersticas (como desenvolvedores e gerentes pouco experientes) especficas do
NPI - solicitaes do terceiro, quarto e quinto requisitos (pginas 47 e 48).
O captulo 5 apresenta com mais detalhes essa comparao dos requisitos do
NPI para o processo com o modelo desenvolvido.
Assim, pode-se concluir que, dentro do possvel, os resultados do trabalho
satisfazem os seus objetivos iniciais.

7.1 Benefcios para o NPI

A maior vantagem deste trabalho que o NPI agora conta com um modelo de
processo, ou seja, um guia de como proceder nos projetos de desenvolvimento de
software. Isso pode ser de grande valia, pois (como j foi explicado anteriormente) a
empresa jnior possui uma rotatividade altssima de funcionrios, e agora, os novos
diretores, gerentes e desenvolvedores no estaro sem rumo quando forem realizar
o seu primeiro projeto de desenvolvimento de software no NPI.
Portanto, se o modelo for seguido corretamente, espera-se que o NPI:
*

tenha um processo (e como conseqncia, um software) de maior qualidade;

tenha uma viso clara e definida do seu processo de desenvolvimento;

tenha um maior controle e planejamento gerencial de seus projetos;

desperte em seus membros a conscientizao e o comprometimento com as


tcnicas de Engenharia de Software;

123

consiga preservar as experincias adquiridas nos projetos para serem utilizadas por
futuras gestes;
Assim, pode-se perceber que o modelo resultante deste trabalho tem grande
potencial para contribuir para a melhoria das condies do desenvolvimento do
software no NPI.

7.2 Trabalhos Futuros

Como trabalhos futuros, inicialmente, aponta-se a utilizao do modelo em


paralelo com a execuo do plano de avaliao. Com base nos resultados dessa
avaliao, recomenda-se a melhora do modelo, principalmente as fases de Testes e
de Gerncia, que contm atividades que at agora raramente foram realizadas no
NPI (e que tambm so muito pouco enfatizadas atualmente nas disciplinas da rea
nos cursos de Cincias da Computao e Sistemas de Informao da UFSC) - e por
isso, foi necessrio buscar na literatura metodologias de como efetu-las -, as quais
precisam ser utilizadas, avaliadas e melhor adaptadas ao seu contexto.
Outras possibilidades de futuros trabalhos incluem o desenvolvimento de uma
ferramenta de software para a tornar mais prtica a utilizao do modelo e para
facilitar a sua alterao. Adicionalmente, tambm importante a elaborao de um
modelo de processo de manuteno de software para o NPI.

124

7.3 Consideraes Finais

Este trabalho foi a primeira iniciativa para sistematizar o processo de


desenvolvimento de software no NPI. Assim, o modelo que foi elaborado est apenas
em sua primeira verso. Dessa forma, no se espera que ele seja totalmente perfeito
e adaptado ao NPI. Ele deve evoluir ao longo da sua utilizao cotidiana. O modelo
deve ser aplicado em um ou mais projetos para que se possa avaliar os seus pontos
fortes e fracos, e ento ele deve ser melhorado; em seguida, esse novo modelo deve
ser aplicado em mais alguns projetos, e ento, novamente ele deve ser avaliado e
melhorado. Considerando uma melhoria contnua, esse ciclo nunca terminar (e o
modelo nunca estar totalmente pronto), pois uma organizao - e portanto, o NPI est sempre mudando. O presente trabalho, assim, o primeiro passo em uma longa
caminhada.

8 Bibliografia

ANACLETO, Alessandra. Modelo de Mensurao para Gerncia de Projetos em


Microempresas de Software. 2001. Trabalho de Concluso de Curso (Bacharelado
em Cincias da Computao) - Universidade Federal de Santa Catarina,
Florianpolis, 2001.

125

BECK, Kent. Simple Smalltalk Testing: With Patterns. 1999. Disponvel em:
<http://xprogramming.com/testfram.htm>. Acesso em: 16 out. 2003.
BINDER, Robert V. Extended Use Case Test Design Patterns. 1999. Disponvel
em: <www.rbsc.com/docs/TestPatternXUC.pdf>. Acesso em: 14 out. 2003.
DENGER, Christian; MORA, Maricel Medina. Test case derived from Requirement
Specifications. abr. 2003. IESE-Report 033.03/E. Disponvel em:
<http://www.iese.fhg.de/Publications/Iese_reports_1/>. Acesso em: 14 out. 2003.

CMMI PRODUCT TEAM. Capability Maturity Model Integration for Software


Engineering, Version 1.1, Continuous Representation. ago 2002. CMU/SEI-2002TR-028.
Disponvel
em:
<http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr028.pdf>. Acesso em: 15
jun 2003.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO - International
Organization for Standardization. Disponvel em: <http://www.iso.org>. Acesso em:
13 jun. 2003.
KEHOE, Raymond; JARVIS Alka. ISO 9000-3: a tool for software product and
process improvement. Nova York: Springer, 1996.
KELLNER, Marc I. et al. Process Guides: effective guidance for process
participantes. ago. 1998. IESE-Report 012.98/E. Disponvel em:
<http://www.iese.fhg.de/Publications/Iese_reports/>. Acesso em: 28 jun. 2003.
LARMAN, Craig. Utilizando UML e Padres: uma introduo analise e ao projeto
orientados a objetos. Traduo de Luiz Augusto Meirelles Salgado. Porto Alegre:
Bookman, 2000.
LIMA, Rodrigo Duran. Gerncia de Projetos de Software com RUP, CMM e ISO 9001.
In: CONGRESSO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE, 13.,
2002, Curitiba. Anais... Curitiba: CITS, 2002. p.107-115.

NCLEO DE PROJETOS EM INFORMTICA. Estatuto. Florianpolis, 1996.


Universidade Federal de Santa Catarina.

126

NCLEO DE PROJETOS EM INFORMTICA. NPI - Ncleo de Projetos em


Informtica. 2002. Universidade Federal de Santa Catarina. Disponvel em:
<http://www.npi.inf.ufsc.br>. Acesso em: 21 mar. 2003.
NCLEO DE PROJETOS EM INFORMTICA. Manual do Processo de
Desenvolvimento de Software do NPI. Florianpolis, 2003. Universidade Federal
de Santa Catarina.
PAULK, Mark C. et al. Capability Maturity Model for Software, Version 1.1. fev.
1993. CMU/SEI-93-TR- 024. Disponvel em:
<http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf>. Acesso em: 10
dez. 2002.
PRESSMAN, Roger S. Engenharia de Software. 5.ed. Rio de Janeiro: McGraw-Hill,
2002.
REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informaes.
Rio de Janeiro: Brasport, 1999.
ROCHA, Ana Regina. Qualidade de Software: processo e produto. In: ENCONTRO
DA QUALIDADE E PRODUTIVIDADE EM SOFTWARE, 2002, Petrpolis. Disponvel
em
<http://www.mct.gov.br/Temas/info/Dsi/PBQP/Reuniao
Petropolis/Palestra
COPPE.pdf>. Acesso em: 29 jun. 2003.
SAVI, Rafael. Desenvolvimento de um Sistema para Planejamento de Projetos
de Software em Micro e Pequenas Empresas. 2002. Trabalho de Concluso de
Curso (Bacharelado em Cincias da Computao) - Universidade Federal de Santa
Catarina, Florianpolis, 2002.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN S. Sistema de Banco
de Dados. 3. ed. So Paulo: Makron Books, 1999.
SILVA, Ricardo Pereira e. Apostila de Engenharia de Software - Semestre 2002.2.
598 transparncias. Florianpolis, 2002.
SOFTWARE ENGINEERING INSTITUTE. Building High Performance Teams
Using TSP and PSP. 2003. Carnegie Mellon University. Disponvel em:
<http://www.sei.cmu.edu/tsp/>. Acesso em: 16 jun 2003.

127

SOUZA, Mara Bay de; SILVA, Rodrigo Grumiche. Engenharia de Requisitos. 2003.
Trabalho escrito como requisito parcial para aprovao na disciplina Engenharia de
Software, Universidade Federal de Santa Catarina, Florianpolis, 2003.
SPICE PROJECT ORGANISATION. Software Process Assessment. jun. 1995.
Technical Report Type 2. Disponvel em:
<http://www.sqi.gu.edu.au/spice/suite/download.html>. Acesso em: 29 jun. 2003.

SUN
MICROSYSTEMS. Code Conventions for the Java Programming
Language. 1999. Disponvel em: <http://java.sun.com/docs/codeconv/>. Acesso em:
22 set. 2003.
SUTTON JR., Stanley M. The role of process in a software start-up. IEEE Software,
p. 33-39, jul./ago. 2002.
TAVARES, Helena Cristina; PAIM, Fbio Rilston Silva; CARVALHO, Ana Elizabete.
Implantando CMM Nvel 2: A Estratgia SERPRO. In: SIMPSIO BRASILEIRO DE
QUALIDADE DE SOFTWARE, 1., 2002, Gramado. Anais... 1 CD-ROM.
ULRIKE, Becker; HAMANN, Dirk; VERLAGE, Martin. Descriptive Modeling of
Software Process. dez. 1997. IESE-Resport 045.97/E. Disponvel em:
<http://www.iese.fhg.de/Publications/Iese_reports/>. Acesso em: 28 jun. 2003.

WANGENHEIM, Christiane Gresse won. Melhoramento de Software Baseado em


Mensurao: Como Aplicar GQM na Prtica? Florianpolis: GeNESS, 1999.
Relatrio Tcnico GeNESS 001.99P.

WEBER, Srgio. Um estudo de caso em uma micro empresa de software para o


desenvolvimento de um modelo de processo de software. 2002. Trabalho de
Concluso de Curso (Bacharelado em Cincias da Computao) - Universidade
Federal de Santa Catarina, Florianpolis, 2002.
WEINBERG, Gerald M. Software com Qualidade: pensando e idealizando
sistemas. Traduo de Flvio Deney Steffen. Reviso Tcnica: Silvio Carmo Palmeri.
So Paulo: Makron Books, 1993.
WQS WORKSHOP DE QUALIDADE DE SOFTWARE, 1994, Curitiba. Anais do VIII
Simpsio Brasileiro de Engenharia de Software. Curitiba, 1994.
128

128

Apndice A - Artigo

129

Modelo de Processo de Software: aplicao em uma


empresa jnior
Mara Bay de Souza
maira@inf.ufsc.br, Universidade Federal de Santa Catarina

Resumo
O NPI (Ncleo de Projetos em Informtica - a empresa jnior de Cincias da Computao e Sistemas
de Informao da UFSC) possui algumas caractersticas de micro e pequenas empresas e outras bem
particulares, as quais levam ocorrncia de processos e produtos de baixa qualidade. Baseando-se
na literatura, acredita-se que a utilizao de um modelo de processo de desenvolvimento de software
ir contribuir para a melhoria da qualidade do software desenvolvido no NPI, colaborando para a
soluo dos problemas detectados. O modelo apresentado neste trabalho foi produzido com base no
processo existente no NPI e nos requisitos dessa empresa jnior para um processo ideal. Ele abrange
todas as fases de um projeto tpico de desenvolvimento de software no NPI, contendo tanto atividades
tcnicas como gerenciais. O modelo ser aplicado na empresa jnior e ento melhorado, como parte
de um processo que ser realizado continuamente pelos prprios membros da empresa jnior.

1 Introduo
Este artigo relata o estudo realizado em 2003 como trabalho de concluso de curso da aluna
Mara Bay de Souza do curso de Cincias da Computao da Universidade Federal de Santa
Catarina. O trabalho completo encontra-se em SOUZA (2004).
1.1 Empresa Jnior
Uma empresa jnior tem como um dos seus objetivos principais realizar a integrao entre os
estudantes e o mercado de trabalho. Ela funciona como empresa normal, mas legalmente uma
organizao sem fins lucrativos, devendo vender seus produtos a preo de custo. Ela deve ser
totalmente comandada por estudantes, tanto na parte administrativa quanto na parte operacional. O
NPI (Ncleo de Projetos em Informtica) a empresa jnior composta pelos alunos dos cursos de
Cincias da Computao e Sistemas de Informao da Universidade Federal de Santa Catarina. Os
alunos podem atuar no NPI como Estagirios ou como Diretores. Os Diretores realizam todas as
tarefas administrativas da empresa, como contabilidade, marketing, gerncia de recursos humanos, e
coordenao de projetos. Os Estagirios realizam as atividades operacionais da empresa jnior, como
desenvolvimento de software.

130

2 Os Problemas do NPI
O NPI realiza projetos de todos os tipos na rea da informtica, mas a sua principal atividade
o desenvolvimento de software comercial sob encomenda. Assim, o incio de um projeto tpico do NPI
consiste nas seguintes etapas: um cliente entra em contato com a empresa jnior solicitando um
produto; os Diretores selecionam Estagirios para realizar o desenvolvimento; assina-se um contrato
entre o NPI e o cliente, e um contrato entre o NPI e os Estagirios; inicia-se o desenvolvimento.
Portanto, a cada projeto so selecionados Estagirios diferentes, eles no fazem parte do quadro
permanente da empresa jnior. Os Diretores, por sua vez, devem permanecer nos seus cargos pelo
perodo de um ano. Essas regras (definidas no estatuto da empresa jnior, NCLEO DE PROJETOS
EM INFORMTICA, 1996), implicam em uma altssima rotatividade de desenvolvedores e de
Diretores. Essa uma caracterstica bastante peculiar do NPI (ou melhor, das empresas juniores de
um modo geral).
Alm dessa dificuldade, o NPI tambm apresenta mais dois problemas que so relevantes. Por
ser uma empresa jnior formada por alunos, os Diretores e desenvolvedores possuem muito pouca
experincia em desenvolvimento sistematizado de software (principalmente por que a disciplina de
Engenharia de Software s ministrada na metade do curso); alm disso, os Diretores (por serem
alunos de informtica) tambm tm pouqussima experincia em administrao de empresas. Essas
caractersticas tambm esto bastante presentes em micro e pequenas empresas.
Um outro fator agravante que, quando os alunos adquirem experincia nessas reas
(administrao de empresas e desenvolvimento sistematizado de software), eles geralmente esto se
formando e portanto, saindo do NPI. Assim, a experincia adquirida durante os projetos de
desenvolvimento no permanece na empresa jnior.

3 O Processo Existente
O NPI no possui um processo claramente definido para o seu desenvolvimento de software.
Assim, para entender o processo existente, foi efetuada a anlise de dois projetos em andamento.
Foram realizadas entrevistas informais com o Diretor de Projetos e os desenvolvedores dos dois
projetos, e foram examinados os artefatos produzidos durante o desenvolvimento.
Aps a investigao, concluiu-se que o processo do NPI constitui basicamente de trs fases:
anlise de requisitos, modelagem do sistema e implementao.
Na anlise de requisitos, o Diretor de Projetos se rene com o cliente, levanta os requisitos,
formaliza-os e divide-os em mdulos. Na fase de modelagem do sistema, so feitos a anlise e o
projeto do sistema, em paralelo, sem uma distino clara entre essas duas atividades. Aps essas
duas fases, realizado um "incremento" para cada mdulo, contendo a fase de implementao e a
realizao de testes informais. Aps essas trs fases o software entregue ao cliente.
O processo facilitado por alguns documentos-padro que j existiam na empresa, como a
Proposta de Projeto e o Contrato de Prestao de Servios de Desenvolvimento de Software. Esses
documentos possuem um contedo genrico, que pode ser adaptado a cada projeto.
Em todas as fases houve um acmulo de papis, principalmente para o Diretor de Projetos, que
atuou como gerente dos dois projetos. Alm disso, em ambos os projetos, foram iniciados muitos
documentos de gerncia do projeto (como cronograma, documento de acompanhamento do trabalho,
etc) - e tambm alguns de anlise e projeto de sistemas - mas eles foram abandonados no meio do
projeto por falta de tempo para termin-los. Um problema muito grave detectado que o
desenvolvimento do segundo projeto j havia iniciado e ainda no havia sido assinado um contrato
com o cliente.
Assim, o processo de desenvolvimento do NPI bastante aleatrio e nebuloso. Porm, deve ser
destacado que h um esforo (tanto do Diretor de Projetos como dos desenvolvedores) de
sistematiz-lo de alguma forma.

131

4 A Abordagem Proposta para a Soluo do Problema


Para auxiliar na resoluo dos problemas do NPI explicados anteriormente, foi escolhida a
abordagem da rea de modelagem de processo (de desenvolvimento de software).
4.1 O Processo e a sua Qualidade
O desenvolvimento de um software pode ser feito utilizando-se vrias metodologias, inclusive a
de um processo ad-hoc. uma idia bastante aceita na literatura de que a qualidade de um software
est fortemente associada com o nvel de organizao do processo utilizado para desenvolv-lo. "A
qualidade de um produto de software fortemente dependente da qualidade do processo pelo qual
ele construdo e mantido" (ROCHA, 2002, p.9, grifo nosso). Ou seja, a utilizao de um processo
metdico e sistematizado tem muito mais chances de produzir um software de qualidade do que a
utilizao de um processo catico e desordenado.
O conceito de qualidade do processo tambm consenso na literatura, sendo definido como a
capacidade de produzir sistemas que vo ao encontro dos requisitos do cliente dentro dos prazos e
custos estabelecidos no incio do projeto ( esse conceito de qualidade que os certificados ISO e CMM
- apresentados mais adiante - asseguram quando so emitidos para uma empresa de software).
Portanto, segundo a abordagem de modelagem de processo, pode-se concluir que os fatores
citados anteriormente (alta rotatividade, tanto dos desenvolvedores quanto da diretoria; inexperincia
dos mesmos; experincia de desenvolvimento permanecer com os alunos e no com a empresa
jnior) prejudicam a qualidade e a produtividade do NPI. E por isso, tambm segundo essa mesma
abordagem, a soluo para os problemas do NPI pode ser a melhora da qualidade do seu processo de
desenvolvimento de software, atravs da elaborao de um modelo de processo de software
prescritivo.
4.2 Modelo de Processo de Software, sua Avaliao e Melhoria
Um modelo de processo de software define o que deve ser realizado em cada fase do
desenvolvimento e d as instrues de como realizar essas atividades. Ele serve como um guia, um
roteiro para a execuo de um processo de desenvolvimento.
De acordo com ULRIKE, HAMANN e VERLAGE (1997), a tarefa de implantao (ou melhora da
qualidade) de um processo de software engloba duas atividades principais: a elaborao de um
modelo de processo descritivo e depois, de um modelo de processo prescritivo. "Um modelo
descritivo retrata como um processo executado em um ambiente em particular; um modelo
prescritivo retrata como um processo deveria ser executado" (Idem, op. cit., p.2, traduo livre). Essa
abordagem utilizada neste artigo: a seo 2 apresenta o modelo descritivo do processo do NPI e a
seo 5 apresenta o modelo prescritivo.
Existem diversos modelos para avaliao e melhoria do processo de software. Os principais e
mais conhecidos so o CMM e o SPICE (ISO15504). Uma diferena fundamental entre modelos de
processo e modelos de avaliao, que os modelos de avaliao apenas definem o que deve ser
realizado durante o processo de desenvolvimento para ele possa ser considerado um processo de
qualidade, enquanto os modelos de processo contm instrues de como realizar as tarefas que o
tornaro um processo de desenvolvimento de qualidade. Tanto o CMM (CMMI PRODUCT TEAM,
2002) quanto o SPICE (REZENDE, 1999, p. 162-165 e SPICE PROJECT ORGANISATION, 1995)
definem nveis de capacidade (ou seja, de qualidade), que podem ter valores diferentes para cada

132

uma das partes do processo. Por exemplo, a empresa pode ser nvel 5 em gerncia de configurao, e
nvel 3 em suporte ps-venda. Assim, continuando com o exemplo, eles apenas definem o que
caracteriza um processo de gerncia de configurao nvel 5, mas no explicam como realizar esse
processo.
4.3 A Literatura da rea
Os modelos de avaliao so bastante divulgados e conhecidos, ao contrrio de modelos de
processo, que so raramente divulgados. Entende-se que a explicao para esse fato, que
geralmente a modelagem de processos feita por empresas de consultoria, que no iriam revelar sua
"metodologia de desenvolvimento de modelos de processo" pois ela a base do seu negcio (seria
como o fabricante da Coca-Cola revelar a sua frmula).
Para a realizao do trabalho descrito neste artigo, foi realizada uma pesquisa bibliogrfica de
relatos de experincias de modelagem de processo, mas novamente, nenhum deles apresentava o
modelo desenvolvido em detalhes. Alm disso, os relatos de experincias em micro e pequenas
empresas tambm so muito escassos, de modo que, nos trs estudos cuja pesquisa foi aprofundada,
apenas WEBER (2002) tratava desse tipo de empresa. Os outros dois estudos (LIMA, 2002 e
TAVARES, PAIM e CARVALHO, 2002) tratam de uma empresa mdia e de uma empresa grande.
Algumas concluses dos autores, entretanto, se aplicam a organizaes de qualquer tamanho, como
por exemplo, combater a tendncia dos desenvolvedores de ir diretamente para a fase de projeto
atravs do fortalecimento dos processos de requisitos.

5 O Modelo de Processo Proposto


A partir da anlise do processo de desenvolvimento existente no NPI, foram definidos os seus
requisitos para um processo de desenvolvimento de software ideal.
O modelo de processo proposto foi elaborado a partir do processo existente e desses requisitos.
Inicialmente foi elaborado o modelo de ciclo de vida (baseado no existente) e ento foram sendo
definidas as fases e suas atividades. Para cada fase foram definidas suas caractersticas (como
atividades, critrios de entrada, critrios de sada, papis e responsabilidades, objetivos, etc), as quais
foram colocadas em um quadro (chamado de quadro das caractersticas). Aps a elaborao desse
quadro, foram listadas as atividades seguidas sempre de uma explicao detalhada de como realizlas. Em adio a esses dados, o modelo inclui tambm uma srie de documentospadro, que devem
ser preenchidos ou alterados de acordo com as informaes de cada projeto.
Alm da explicao do modelo de ciclo de vida e da definio das fases, o modelo de processo
desenvolvido tambm apresenta explicaes introdutrias de como utiliz-lo, como mud-lo, como
preencher os documentos, entre outras.
O Quadro 1 apresenta as fases do modelo de processo desenvolvido e os seus objetivos.
Fase
Proposta
Contrato
Requisitos
Projeto
Implementao
Testes
Entrega
Gerncia

Objetivo
Realizar uma proposta de projeto para o cliente, contendo
estimativas de tempo e custo.
Negociar a proposta com o cliente.
Assinar o contrato com a Empresa cliente. Assinar
o contrato com os Estagirios.
Fazer a anlise mais detalhada dos requisitos.
Fazer o projeto do sistema de modo que ele possa ser mapeado
diretamente em cdigo.
A partir do projeto, escrever o cdigo.
Preparar os requisitos para o projeto dos casos de teste.
Projetar e executar os casos testes
Entregar o software ao cliente.
Gerenciar o desenvolvimento do software.
Quadro 1: Resumo das fases do modelo

133

Como pode ser visto, o modelo de processo produzido inclui tanto atividades tcnicas como
gerenciais, abrangendo todas as fases de um processo tpico de desenvolvimento de software do NPI
(desde o primeiro contato do cliente at a entrega da verso final do software).
A fase de Gerncia (assim como a fase de Testes) recebeu uma ateno especial, pois suas
atividades eram bastante ausentes no NPI. Foram definidas vrias polticas para as atividades
gerenciais, como controle do cronograma, controle de verses, acompanhamento do trabalho, entre
outras. Para a fase de Testes, foi adotada uma adaptao da metodologia proposta por BINDER
(1999).
Alm disso, o modelo tambm aborda algumas questes humanas que so importantes de se
considerar na sua utilizao (por exemplo, nfase no fato de que o modelo deve ser visto como um
guia e no como uma imposio burocrtica da diretoria).

6 A avaliao
Com o objetivo de avaliar a aplicabilidade do modelo e os seus pontos fortes e fracos no NPI,
apresentado (em linhas gerais) o plano para a avaliao do modelo. Esse plano ser executado em
paralelo utilizao do modelo pelo NPI em um projeto piloto. Como no decorrer do trabalho descrito
neste artigo, no se iniciou nenhum novo projeto na empresa jnior, a execuo do plano de avaliao
no foi possvel.
O plano de avaliao foi elaborado segundo a metodologia GQM (Goal Question Metric), que
possui uma srie de passos e documentos bem definidos que devem ser elaborados durante a
produo do plano e a sua execuo.
Inicialmente, deve-se definir as metas da avaliao, ou seja, quais aspectos do processo sero
avaliados. Para o plano de avaliao apresentado, definiram-se as seguintes metas: qualidade,
durao e gerncia dos projetos. Ento, foram elaboradas as abstraction sheets, que so tabelas onde
constam resumidamente os elementos de cada meta a serem avaliados, os fatores que influenciam a
sua variao, as hipteses dos valores desses elementos, entre outros. Para a meta qualidade foram
definidos os seguintes elementos: consistncia entre requisitos e projeto, consistncia entre projeto e
implementao e grau de sistematizao da produo dos documentos. Em seguida, foram
elaboradas perguntas que derivam das abstraction sheets e que apresentam claramente o qu ser
avaliado e quais sero os critrios dessa avaliao (seguindo com o exemplo, foi definida a pergunta
"Qual o nvel de consistncia entre requisitos e projeto?" e as opes de respostas "Alto, Mdio,
Baixo" seguidas de uma explicao precisa do que Alto, Mdio e Baixo). A partir dessas definies
desenvolveu-se o plano de mensurao, que apresenta instrues de quando coletar os dados, qual
instrumento utilizar para a coleta, quem deve coletar os dados, e como eles se relacionam com as
metas e as perguntas. Os instrumentos de coleta so essencialmente roteiros para entrevistas com os
membros do NPI e tambm um roteiro para inspeo de documentos. Alm disso, foram criados
tabelas e grficos com lacunas para serem preenchidas aps a execuo da avaliao. O plano de
avaliao completo encontra-se como anexo no trabalho de SOUZA (2004).

7 Concluso
Os trs principais resultados do trabalho aqui relatado so: a anlise do processo existente no
NPI, o modelo de processo de desenvolvimento de software do NPI - que o resultado mais
importante - e o plano de avaliao.
Os principais benefcios do modelo de processo elaborado para o NPI, se ele for seguido
corretamente, podero ser: melhoria da qualidade do processo e do software desenvolvido, fruio de
uma viso clara e definida do seu processo de desenvolvimento, aumento do controle e do
planejamento gerencial dos seus projetos, preservao das experincias adquiridas nos projetos para
serem utilizadas por futuras gestes. Alm disso, comparando o modelo de processo proposto com os
outros trs modelos pesquisados e com os modelos de avaliao, percebemos que o modelo proposto

134

atende a um nmero maior de requisitos e que ele atende maioria dos requisitos do NPI (enquanto
os outros satisfazem apenas trs ou quatro requisitos). Essa comparao apresentada em mais
detalhes por SOUZA (2004). Assim, pode-se concluir que o modelo adequado ao NPI.
No decorrer da realizao do trabalho apresentado neste artigo, no foram iniciados novos
projetos de desenvolvimento de software no NPI, de modo que no foi possvel executar o plano de
avaliao elaborado (entretanto, o plano est totalmente disponvel para ser utilizado assim que se
iniciar um novo projeto). A utilizao do modelo em paralelo com a execuo da avaliao, seguida da
melhoria do modelo com base na avaliao, um processo que ser realizado continuamente pelos
prprios membros do NPI. Portanto, o modelo proposto apenas a primeira verso do modelo de
processo de desenvolvimento de software do NPI, que ainda ser melhorado muitas vezes at que
esteja completamente adequado a essa empresa jnior.

8 Bibliografia
BINDER, Robert V. Extended Use Case Test Design Patterns. 1999. Disponvel em:
<www.rbsc.com/docs/TestPatternXUC.pdf>. Acesso em: 14 out. 2003.
CMMI PRODUCT TEAM. Capability Maturity Model Integration for Software Engineering, Version
1.1, Continuous Representation. ago 2002. CMU/SEI-2002-TR-028. Disponvel em:
<http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr028.pdf>. Acesso em: 15 jun 2003.
LIMA, Rodrigo Duran. Gerncia de Projetos de Software com RUP, CMM e ISO 9001. In:
CONGRESSO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE, 13., 2002, Curitiba. Anais...
Curitiba: CITS, 2002. p.107-115.
NCLEO DE PROJETOS EM INFORMTICA. Estatuto. Florianpolis, 1996. Universidade Federal de
Santa Catarina.
NCLEO DE PROJETOS EM INFORMTICA. NPI - Ncleo de Projetos em Informtica. 2002.
Universidade Federal de Santa Catarina. Disponvel em: <http://www.npi.inf.ufsc.br>. Acesso em: 21
mar. 2003.
NCLEO DE PROJETOS EM INFORMTICA. Manual do Processo de Desenvolvimento de
Software do NPI. Florianpolis, 2003. Universidade Federal de Santa Catarina.
REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informaes. Rio de Janeiro:
Brasport, 1999.
ROCHA, Ana Regina. Qualidade de Software: processo e produto. In: ENCONTRO DA QUALIDADE
E
PRODUTIVIDADE
EM
SOFTWARE, 2002, Petrpolis.
Disponvel
em
<http://www.mct.gov.br/Temas/info/Dsi/PBQP/Reuniao Petropolis/Palestra COPPE.pdf>. Acesso em:
29 jun. 2003.
SOUZA, Mara Bay de. Modelo de Processo de Software: aplicao em uma empresa jnior. 2004.
Trabalho de Concluso de Curso (Bacharelado em Cincias da Computao) - Universidade Federal
de Santa Catarina, Florianpolis, 2004.

135

SPICE PROJECT ORGANISATION. Software Process Assessment. jun. 1995. Technical Report
Type 2. Disponvel em: <http://www.sqi.gu.edu.au/spice/suite/download.html>. Acesso em: 29 jun.
2003.
TAVARES, Helena Cristina; PAIM, Fbio Rilston Silva; CARVALHO, Ana Elizabete. Implantando CMM
Nvel 2: A Estratgia SERPRO. In: SIMPSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 1.,
2002, Gramado. Anais... 1 CD-ROM.
ULRIKE, Becker; HAMANN, Dirk; VERLAGE, Martin. Descriptive Modeling of Software Process.
dez. 1997. IESE-Resport 045.97/E. Disponvel em:
<http://www.iese.fhg.de/Publications/Iese_reports/>. Acesso em: 28 jun. 2003.
WANGENHEIM, Christiane Gresse won. Melhoramento de Software Baseado em Mensurao:
Como Aplicar GQM na Prtica? Florianpolis: GeNESS, 1999. Relatrio Tcnico GeNESS 001.99P.
WEBER, Srgio. Um estudo de caso em uma micro empresa de software para o
desenvolvimento de um modelo de processo de software. 2002. Trabalho de Concluso de Curso
(Bacharelado em Cincias da Computao) - Universidade Federal de Santa Catarina, Florianpolis,
2002.

135

Apndice B - Plano da Avaliao

136

NCLEO DE PROJETOS EM INFORMTICA

PLANO DE AVALIAO DO MPDS-NPI


(VERSO 1.0)
SUMRIO

1 - Plano GQM

138

1.1 - Abstraction Sheets


1.1.1 - Qualidade e Durao
1.1.2 - Gerncia

139

138
138

137

1.2 - Perguntas GQM Resumidas


1.2.1 - Qualidade e Durao

140

1.2.1.1 - Definio das Variaes

140

1.2.1.2 - Definio da Qualidade

140

1.2.2 - Gerncia

140

1.2.2.1 - Definio das Variaes

140

1.2.2.2 - Definio da Qualidade

141

1.3 - Perguntas GQM em Detalhes


1.3.1 - Qualidade e Durao

142

1.3.1.1 - Definio das Variaes

142

1.3.1.2 - Definio da Qualidade

143

1.3.2 - Gerncia

140

142

145

1.3.2.1 - Definio das Variaes

145

1.3.2.2 - Definio da Qualidade

145

2 - Plano de Mensurao
2.1 - Quadro do Plano

147

147

2.2 - Instrumentos para Coleta de Dados

148

2.2.1 - Roteiro para Entrevista com a Equipe de


Desenvolvimento

148

2.2.2 - Roteiro para Entrevista com os Diretores

149

2.2.3 - Roteiro para Entrevista com o Gerente

150

2.2.4 - Roteiro para Inspeo dos Documentos

151

3 - Preparao para a Anlise e a Interpretao


3.1 - Representao em Tabela
3.1.1 - Qualidade e Durao
3.1.1.1 - Qualidade
3.1.1.2 - Durao
3.1.2 - Gerncia

153
154

152

152
152

152

138

3.2 - Representao em Grficos

155

1 - Plano GQM
O plano GQM composto de duas partes: as Abstraction Sheets e as Perguntas GQM. As perguntas
so apresentadas em detalhes e tambm de forma resumida, para facilitar uma leitura rpida do
plano.

1.1 - Abstraction Sheets


As Abstraction Sheets resumem as metas do plano de avaliao.
A primeira parte da Abstraction Sheet (Objeto, Objetivos, etc) est bem explicada em WANGENHEIM
(1999, p.11).
Fatores de Qualidade so os fatores que sero avaliados pra cada meta. Os Fatores de Variao so
fatores que influenciam nos fatores de qualidade. Em Impacto na Hiptese de Linha-Base so
colocadas as hipteses de como os fatores da variao iro influenciar os fatores de qualidade. A
Hiptese de Linha-Base apresenta a medida do fator de qualidade que se supe que existia Antes da
aplicao do MPDS-NPI e que se supe que ir existir Depois que o MPDS-NPI for aplicado.

1.1.1 - Qualidade e Durao


Objeto

Objetivo

Enfoque da
Qualidade
Qualidade e
Durao

Modelo de
Avaliar
Processo
Fatores de Qualidade
Qualidade:
- Consistncia entre requisitos e projeto
- Consistncia entre projeto e implementao
- Sistematizao da produo dos documentos
Durao:
- Atraso no Projeto

Hiptese de Linha-Base
Antes
Depois (Hiptese)

Ponto de Vista

Contexto

Pesquisador

NPI

Fatores de Variao
Qualidade:
Comprometimento e conscientizao da equipe
de desenvolvimento da necessidade de
utilizao de tcnicas de engenharia de
software
Experincia da equipe em desenvolvimento de
software
Durao:
Experincia da equipe em fazer estimativas Quantidade de informao sobre a durao de
projetos anteriores semelhantes
Impacto na Hiptese de Linha-Base
Qualidade:

139

Qualidade:
O nvel de
consistncia entre os
requisitos e o projeto
Baixo.
O nvel de
consistncia entre o
projeto e a
implementao Baixo.
- No h uma ordem
para a produo dos
documentos.
Durao:
O atraso no
projeto de 5 meses.

Qualidade:
O nvel de
consistncia entre os
requisitos e o projeto
Alto.
O nvel de
consistncia entre o
projeto e a
implementao Alto. H um modelo de
processo que determina
a ordem de produo
dos documentos e essa
ordem seguida.
Durao:
O atraso no
projeto de 1 ms ou
menos.

experincia em desenvolvimento de software:


consistncia entre requisitos e projeto
consistncia entre projeto e implementao
comprometimento e conscientizao da
necessidade de utilizar tcnicas de engenharia
de software consistncia entre requisitos e
projeto consistncia entre projeto e
implementao produo sistematizada de
documentos
Durao:
experincia da equipe em fazer
estimativas erro nas estimativas (e portanto
o atraso)
informao sobre a durao de projetos
anteriores semelhantes erro nas estimativas
(e portanto o atraso)

1.1.2 - Gerncia
Objeto

Objetivo

Enfoque da
Qualidade
Gerncia

Modelo de
Avaliar
Processo
Fatores de Qualidade
- Controle de verses
- Planejamento e controle do cronograma
- Acompanhamento e superviso do trabalho
Hiptese de Linha-Base
Antes
Depois (Hiptese)
No h nenhuma
H uma poltica
documentada para o
poltica para o controle
controle de verses dos
de verses dos
documentos e ela
documentos.
seguida.
Existe um cronograma
Existe
um cronograma,
mas ele no seguido. ele

re-elaborado
O acompanhamento do
trabalho Insatisfatrio, quando ocorrem
atrasos, e seguido
e
abandonado no meio do durante todo o projeto. O acompanhamento do
projeto.
trabalho
Satisfatrio, e seguido
durante todo o projeto.

Ponto de Vista

Contexto

Pesquisador

NPI

Fatores de Variao
- Tempo disponvel do gerente para o projeto
- Tamanho do Projeto
Impacto na Hiptese de Linha-Base
tempo disponvel do gerente para o
projeto controle de verses planejamento e
controle do cronograma acompanhamento e
superviso do trabalho
tamanho do projeto necessidade de
controle das verses necessidade de
planejamento e controle do cronograma

1.2 - Perguntas GQM Resumidas


As perguntas GQM apresentam-se primeiro em forma resumida. Essa forma apresenta apenas
as perguntas e as sub-perguntas derivadas delas.

140

1.2.1 - Qualidade e Durao


As perguntas sobre Qualidade e Durao foram agrupadas em um item s, pois elas esto na mesma
Abstraction Sheet.

1.2.1.1 - Definio das Variaes


Q1) A experincia da equipe em desenvolvimento de software tem um impacto na consistncia entre
os requisitos e o projeto?
Q1.1) Qual a experincia da equipe em desenvolvimento de software?
Q2) A experincia da equipe em desenvolvimento de software tem um impacto na consistncia entre o
projeto e a implementao?
Q3) O nvel de comprometimento e conscientizao da equipe em relao necessidade da utilizao
de tcnicas de engenharia de software tem um impacto na sistematizao da produo dos
documentos?
Q3.1) Qual o nvel de comprometimento e conscientizao da equipe em relao
necessidade da utilizao de tcnicas de engenharia de software?
Q4) O nvel de comprometimento e conscientizao da equipe em relao necessidade da utilizao
de tcnicas de engenharia de software tem um impacto na consistncia entre os requisitos e o
projeto?
Q5) O nvel de comprometimento e conscientizao da equipe em relao necessidade da utilizao
de tcnicas de engenharia de software tem um impacto na consistncia entre o projeto e a
implementao?
Q6) A experincia da equipe em fazer estimativas influencia a preciso das estimativas? Q6.1)
Qual a experincia da equipe em fazer estimativas?
Q7) A quantidade de informao sobre a durao de projetos anteriores semelhantes influencia a
preciso das estimativas (e portanto, no atraso do projeto)?
Q7.1) Qual a quantidade de informao sobre a durao de projetos anteriores semelhantes?

1.2.1.2 - Definio da Qualidade


Q8) Qual o nvel de consistncia entre os requisitos e o projeto?
Q9) Qual o nvel de consistncia entre o projeto e a implementao?
Q10) Qual o grau de sistematizao da produo dos documentos?
Q11) Qual o atraso do projeto?

1.2.2 - Gerncia

141

1.2.2.1 - Definio das Variaes


Q12) O tempo disponvel do Gerente para o projeto tem um impacto na qualidade do controle de
verses?
Q12.1) Qual o tempo disponvel do gerente para o projeto?
Q13) O tempo disponvel do Gerente para o projeto tem um impacto na qualidade do planejamento e
controle do cronograma?
Q14) O tempo disponvel do Gerente para o projeto tem um impacto na qualidade do
acompanhamento e superviso do trabalho?
Q.15) O tamanho do projeto altera a necessidade de controle de verses? Q15.1)
Qual o tamanho do projeto?
Q16) O tamanho do projeto altera a necessidade de planejamento e controle de cronograma?

1.2.2.2 - Definio da Qualidade


Q17) Qual o nvel de qualidade do controle das verses dos documentos?
Q18) Qual o nvel de qualidade do controle do cronograma?
Q19) Qual o nvel de qualidade do acompanhamento do trabalho?

142

1.3 - Perguntas GQM em Detalhes


Nesta parte, as perguntas GQM esto detalhadas, contendo:
* Hiptese (o contedo de Impacto na Hiptese de Linha-Base da Abstraction Sheet), *
Modelo (como calcular a medida),
* MX.X (nmero da medida, seguido do seu nome e dos valores que ela pode assumir), *
Hiptese Antes (contedo da Hiptese de Linha-Base Antes da Abstraction Sheet) e
* Hiptese Depois (contedo da Hiptese de Linha-Base Depois da Abstraction Sheet).

1.3.1 - Qualidade e Durao


Novamente, as perguntas sobre Qualidade e Durao foram agrupadas em um item s, pois elas
esto na mesma Abstraction Sheet.

1.3.1.1 - Definio das Variaes


Q1) A experincia da equipe em desenvolvimento de software tem um impacto na consistncia entre
os requisitos e o projeto?
Hiptese: quanto mais experincia a equipe possui em desenvolvimento de software, maior ser a
consistncia entre os requisitos e o projeto.
Q1.1) Qual a experincia da equipe em desenvolvimento de software?
Modelo: a experincia da equipe deve ser a mdia aritmtica das experincias de todos os
membros da equipe.
M1.1 experincia da equipe [ordinal:
"Grande (trabalhou na rea mais de 4 anos)"; "Mdia
(trabalhou na rea entre 2 e 4 anos)";
"Pequena (trabalhou na rea menos de 2 anos)"].
Hipteses Antes e Depois: a equipe possui uma experincia Mdia.
Q2) A experincia da equipe em desenvolvimento de software tem um impacto na consistncia entre o
projeto e a implementao?
Hiptese: quanto mais experincia a equipe possui em desenvolvimento de software, maior ser a
consistncia entre o projeto e a implementao.
Q3) O nvel de comprometimento e conscientizao da equipe em relao necessidade da utilizao
de tcnicas de engenharia de software tem um impacto na sistematizao da produo dos
documentos?
Hiptese: quanto mais comprometida e conscientizada em relao necessidade de utilizao de
tcnicas de engenharia de software a equipe est, mais sistematizada ser a produo dos
documentos.
Q3.1) Qual o nvel de comprometimento e conscientizao da equipe em relao
necessidade da utilizao de tcnicas de engenharia de software?
Modelo: o nvel de comprometimento e conscientizao da equipe em relao necessidade
da utilizao de tcnicas de ES, pode ser medido atravs da importncia que a equipe atribui
utilizao de tcnicas de ES e do questionamento se a equipe continuaria utilizando essas
tcnicas mesmo diante de acontecimentos crticos como atraso no cronograma.
M3.1 valor de importncia atribudo ES [ordinal: importante; no importante].
Hipteses Antes e Depois: a equipe acha que importante utilizar tcnicas de ES.

143

M3.2 continuaria utilizando a tcnica mesmo diante de acontecimentos crticos (como atraso
no cronograma) [ordinal: sim; no].
Hiptese Antes: a equipe abandonaria a ES diante de acontecimentos crticos.
Hiptese Depois: a equipe continuaria utilizando a ES mesmo diante de acontecimentos
crticos.
Q4) O nvel de comprometimento e conscientizao da equipe em relao necessidade da utilizao
de tcnicas de engenharia de software tem um impacto na consistncia entre os requisitos e o
projeto?
Hiptese: quanto mais comprometida e conscientizada em relao necessidade de utilizao de
tcnicas de engenharia de software a equipe est, maior ser a consistncia entre os requisitos e o
projeto.
Q5) O nvel de comprometimento e conscientizao da equipe em relao necessidade da utilizao
de tcnicas de engenharia de software tem um impacto na consistncia entre o projeto e a
implementao?
Hiptese: quanto mais comprometida e conscientizada em relao necessidade de utilizao de
tcnicas de engenharia de software a equipe est, maior ser a consistncia entre o projeto e a
implementao.
Q6) A experincia da equipe em fazer estimativas influencia a preciso das estimativas? Hiptese:
quanto mais experincia a equipe tem em fazer estimativas, mais precisas so as suas
estimativas.
Q6.1) Qual a experincia da equipe em fazer estimativas?
Modelo: a experincia da equipe em fazer estimativas pode ser medida pelo nmero de
projetos para os quais a equipe j fez estimativas. Deve ser feita uma mdia aritmtica do
nmero de projetos feitos por cada membro da equipe. M6.1 experincia da equipe em
fazer estimativas [ordinal:
"Grande (j realizou estimativas para mais de 6 projetos)"; "Mdia
(j realizou estimativas para 3, 4 ou 5 projetos)";
"Pequena (j realizou estimativas para 2 ou menos projetos)"].
Hiptese Antes: a equipe possui experincia Pequena. Hiptese
Depois: a equipe possui experincia Mdia.
Q7) A quantidade de informao sobre a durao de projetos anteriores semelhantes influencia a
preciso das estimativas (e portanto, no atraso do projeto)?
Hiptese: quanto mais informao sobre a durao de projetos anteriores semelhantes, melhor ser a
estimativa realizada pela equipe.
Q7.1) Qual a quantidade de informao sobre a durao de projetos anteriores semelhantes?
Modelo: pode ser medida pela existncia ou no de informaes sobre a durao real e a
durao planejada dos projetos anteriores semelhantes. M7.1 informao sobre projetos
anteriores semelhantes [ordinal:
"Existe informao sobre a durao real e planejada"; "Existe
informao apenas sobre a durao planejada"; "No existe
informao sobre a durao"].
Hiptese Antes: no existe informao sobre a durao de projetos anteriores semelhantes.
Hiptese Depois: existe informao sobre a durao real e planejada de projetos anteriores
semelhantes.

1.3.1.2 - Definio da Qualidade


Q8) Qual o nvel de consistncia entre os requisitos e o projeto?

144

Modelo: o nvel de consistncia entre os requisitos e o projeto pode ser medido comparando-se as
operaes de sistema e os diagramas de colaborao.
M8.1 nvel de consistncia entre as operaes de sistema e os diagramas de colaborao [ordinal:
"Alto (para cada operao de sistema de cada caso de uso, existe um diagrama de colaborao)"
"Mdio (para 70% a 99% das operaes de sistema, existe um diagrama de colaborao
correspondente a cada operao)"
"Baixo (para menos de 70% das operaes de sistema, existe um diagrama de colaborao
correspondente a cada operao)"].
Hiptese Antes: o nvel de consistncia entre as operaes de sistema e os diagramas de
colaborao Baixo.
Hiptese Depois: o nvel de consistncia entre as operaes de sistema e os diagramas de
colaborao Alto.
Q9) Qual o nvel de consistncia entre o projeto e a implementao?
Modelo: esse nvel pode ser medido comparando-se o diagrama de classes com as classes
implementadas.
M9.1 nvel de consistncia entre as classes do projeto e do cdigo [ordinal:
"Alto (todas as classes projetadas foram implementadas)";
"Mdio (de 70% a 99% das classes que aparecem no diagrama de classes foram implementadas)";
"Baixo (menos de 70% das classes projetadas foram implementadas)"].
Hiptese Antes: o nvel de consistncia entre as classes do projeto e do cdigo Baixo.
Hiptese Depois: o nvel de consistncia entre as classes do projeto e do cdigo Alto.
M9.2 nvel de consistncia entre os nomes das classes do projeto e do cdigo [ordinal:
"Alto (os nomes das classes implementadas e projetadas so iguais)";
"Mdio (70% a 99% dos nomes das classes implementadas so iguais aos nomes das classes
projetadas)";
"Baixo (menos de 70% dos nomes das classes implementadas so iguais aos nomes projetados para
elas no diagrama de classes)"].
Hiptese Antes: o nvel de consistncia entre os nomes das classes do projeto e do cdigo Baixo.
Hiptese Depois: o nvel de consistncia entre os nomes das classes do projeto e do cdigo Alto.
M9.3 nvel de consistncia entre os atributos e mtodos das classes do projeto e do cdigo [ordinal:
"Alto (todos os atributos e mtodos de todas as classes que aparecem no diagrama de classes foram
implementados em suas devidas classes)";
"Mdio" (70% a 99% dos atributos e mtodos que aparecem no diagrama de classes foram
implementados)";
"Baixo (menos de 70% dos atributos e mtodos que foram projetados esto implementados)"].
Hiptese Antes: a consistncia entre os atributos e mtodos das classes do projeto e do cdigo
Baixa.
Hiptese Depois: a consistncia entre os atributos e mtodos das classes do projeto e do cdigo
Alta.
M9.4 nvel de consistncia entre os nomes dos atributos e mtodos das classes do projeto e do cdigo
[ordinal:
"Alto (todos os atributos e mtodos possuem o mesmo nome na implementao e no projeto)";
"Mdio (70% a 90% dos atributos e mtodos implementados possuem o mesmo nome projetado)";
"Baixo (menos de 70% dos atributos e mtodos possuem o mesmo nome na implementao e no
projeto)"].
Hiptese Antes: o nvel consistncia entre os nomes dos atributos e mtodos das classes do projeto e
do cdigo Baixo.
Hiptese Depois: o nvel de consistncia entre os nomes dos atributos e mtodos das classes do
projeto e do cdigo Alto.
Q10) Qual o grau de sistematizao da produo dos documentos?
Modelo: esse grau pode ser medido pela existncia ou no de um processo sistematizado para a
produo e por sua utilizao ou no.
M10.1 existncia de um processo sistematizado [ordinal:
"Existe um modelo de processo";

145

"Existe uma ordem documentada informalmente";


"Existe uma ordem no-documentada"; "No
existe uma ordem"].
Hiptese Antes: no existe uma ordem para a produo dos documentos.
Hiptese Depois: h um modelo de processo que determina a ordem de produo dos documentos.
M10.2 utilizao da ordem [ordinal: seguida; no seguida].
Hiptese Antes: como no existe ordem, ela no seguida.
Hiptese Depois: a ordem seguida.
Q11) Qual o atraso do projeto?
Modelo: atraso = data prevista para o fim do projeto - data real do fim do projeto
M11.1 data prevista [intervalo: data]
M11.2 data real [intervalo: data]
Hiptese Antes: o atraso de 5 meses.
Hiptese Depois: o atraso de 1 ms ou menos.

1.3.2 - Gerncia
1.3.2.1 - Definio das Variaes
Q12) O tempo disponvel do Gerente para o projeto tem um impacto na qualidade do controle de
verses?
Hiptese: quanto mais tempo disponvel para o projeto o Gerente tem, melhor o controle de verses.
Q12.1) Qual o tempo disponvel do gerente para o projeto?
Modelo: esse tempo pode ser medido pelo nmero de horas que o gerente se dedica ao
projeto por semana.
M12.1 dedicao do gerente [racional: inteiro (horas/semana)].
Hiptese Antes: 5 horas/semana.
Hiptese Depois: 10 horas por semana.
Q13) O tempo disponvel do Gerente para o projeto tem um impacto na qualidade do planejamento e
controle do cronograma?
Hiptese: quanto mais tempo disponvel para o projeto o Gerente tem, melhor a qualidade do
planejamento e do controle do cronograma, realizados por ele.
Q14) O tempo disponvel do Gerente para o projeto tem um impacto na qualidade do
acompanhamento e superviso do trabalho?
Hiptese: quanto mais tempo disponvel para o projeto o Gerente tem, melhor a qualidade do
acompanhamento e da superviso do trabalho, realizados por ele.
Q.15) O tamanho do projeto altera a necessidade de controle de verses?
Hiptese: quanto maior o projeto, mais crtico se torna o controle de verses.
Q15.1) Qual o tamanho do projeto?
Modelo: o tamanho de um projeto pode ser medido pelo tempo que foi estimado que ele ir
durar.
M15.1 tamanho do projeto [ordinal:
"Grande (durao planejada maior do que 8 meses)";
"Mdio (durao planejada entre 4 e 8 meses)";
"Pequeno (durao planejada menor ou igual a 4 meses)"].
Hiptese Antes: Pequeno.
Hiptese Depois: Mdio.

146

Q16) O tamanho do projeto altera a necessidade de planejamento e controle de cronograma?


Hiptese: quanto maior o projeto, mais crticos so o planejamento e o controle do cronograma.

1.3.2.2 - Definio da Qualidade


Q17) Qual o nvel de qualidade do controle das verses dos documentos?
Modelo: esse nvel pode ser medido atravs da constatao da existncia ou no de uma poltica para
o controle das verses, da verificao se essa poltica documentada ou no e da verificao se a
poltica seguida ou no.
M17.1 existncia de uma poltica para o controle de verses [ordinal: existe; no existe].
Hiptese Antes: no existe uma poltica para o controle de verses.
Hiptese Depois: existe uma poltica para o controle de verses.
M17.2 documentao ou no da poltica [ordinal:
"A poltica est documentada";
"A poltica existe como uma cultura ou modelo mental no-documentado"].
Hiptese Antes: como no existe poltica, consideramos a segunda opo.
Hiptese Depois: a poltica est documentada.
M17.3 utilizao da poltica [ordinal:
"A poltica seguida sempre";
"A poltica no seguida"].
Hiptese Antes: a poltica no seguida, pois no h poltica. Hiptese
Depois: a poltica seguida.
Q18) Qual o nvel de qualidade do controle do cronograma?
Modelo: esse nvel pode ser medido pela constatao da existncia ou no de um cronograma; pela
verificao se ele seguido ou no durante todo o projeto e pela verificao se o cronograma
reelaborado quando ocorrem atrasos.
M18.1 existncia do cronograma [ordinal: existe; no existe].
Hipteses Antes e Depois: existe um cronograma.
M18.2 utilizao do cronograma [ordinal:
"O cronograma seguido em todo o projeto"; "O
cronograma abandonado aps a re-elaborao";
"O cronograma nunca seguido"].
Hiptese Antes: o cronograma nunca seguido.
Hiptese Depois: o cronograma seguido em todo o projeto.
M18.3 O cronograma re-elaborado quando ocorrem atrasos [ordinal: sim; no].
Hiptese Antes: o cronograma no re-elaborado quando ocorrem atrasos. Hiptese
Depois: o cronograma re-elaborado quando ocorrem atrasos.
Q19) Qual o nvel de qualidade do acompanhamento do trabalho?
Modelo: esse nvel pode ser medido pela maneira como ele feito e tambm pelo seguimento ou no
dessa maneira de acompanhamento at o fim do projeto.
M19.1 maneira de acompanhar o trabalho [ordinal:
"Satisfatria (so registradas as horas trabalhadas e as atividades realizadas nessas horas)";
"Mdia (so realizadas comunicaes informais do estado do desenvolvimento)"; "Insatisfatria
(nenhum acompanhamento realizado)"].
Hiptese Antes: a maneira de acompanhar o trabalho Insatisfatria.
Hiptese Depois: a maneira de acompanhar o trabalho Satisfatria.
M19.2 seguimento do acompanhamento [ordinal:
"O acompanhamento do trabalho realizado durante todo o projeto"; "O
acompanhamento do trabalho abandonado no meio do projeto"].
Hiptese Antes: o acompanhamento do trabalho abandonado no meio do projeto.
Hiptese Depois: o acompanhamento do trabalho realizado durante todo o projeto.

147

2 - Plano de Mensurao
O Plano de Mensurao inclui um quadro que resume o plano e os instrumentos para coleta de dados.

2.1 - Quadro do Plano


*
*
*
*
*
*

O quadro composto dos seguintes itens:


Nmero (o nmero da coleta),
Medidas Associadas (as medidas que sero coletadas),
Descrio (do assunto que tratam as medidas),
Tempo (em que parte do processo ser realizada a coleta),
Papel (quem ir realizar a coleta) e
Instrumento (nome do instrumento que ir guiar a coleta).

Nmero

Medidas
Associadas
M1.1, M3.1,
M3.2

Descrio

Tempo

Papel

Instrumento

relao da equipe
com a ES

Pesquisador

Entrevista com a
Equipe de
Desenvolvimento

M6.1, M7.1

relao da equipe
com estimativas

Pesquisador

Entrevista com os
Diretores

Inspeo dos
Documentos

aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

M11.1, M11.2

consistncia entre
requisitos, projeto e
implementao
sistematizao da
produo dos
documentos
atraso do projeto

Pesquisador

M8.1, M9.1,
M9.2, M9.3,
M9.4
M10.1, M10.2

aps a
atividade 5
da fase de
Contrato
aps a
atividade 4
da fase de
Proposta
aps o fim
do projeto

Pesquisador

M12.1

M15.1

Inspeo dos
Documentos
Entrevista com o
Gerente
Entrevista com os
Diretores

M17.1, M17.2,
M17.3

aps o fim
do projeto
aps o fim
do projeto
aps a
atividade 4
da fase de
Proposta
aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

M18.1, M18.2,
M18.3

aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

10

M19.1, M19.2

aps o fim
do projeto

Pesquisador

Entrevista com o
Gerente

dedicao do
gerente ao projeto
durao estimada
do projeto

nvel de controle
das verses dos
documentos
nvel de
planejamento e
controle do
cronograma
nvel do
acompanhamento
do trabalho

2.2 - Instrumentos para Coleta de Dados

Pesquisador
Pesquisador

148

Os instrumentos para coleta de dados incluem trs entrevistas e uma inspeo de documentos. A
seguir so apresentados os roteiros para realizao de cada uma dessas coletas.

2.2.1 - Roteiro para Entrevista com a Equipe de Desenvolvimento


Por Equipe de Desenvolvimento entende-se o Gerente e os outros Estagirios.
Essas perguntas devem ser realizadas a toda Equipe ao mesmo tempo. Eles devem entrar em
consenso (dentro do possvel) e escolher uma das respostas.
1 - (M1.1) Qual a experincia de vocs em desenvolvimento de software? (fazer uma mdia aritmtica
das experincias de cada Estagirio)
a) Grande (j trabalharam na rea por mais de 4 anos)
b) Mdia (j trabalharam na rea entre 2 e 4 anos)
c) Pequena (j trabalharam na rea por menos de 2 anos)
2 - (M3.1) Qual a importncia que vocs vem na utilizao de tcnicas de ES para o
desenvolvimento de software no NPI? a) importante
b) no importante
3 - (M3.2) Vocs continuariam utilizando a tcnica mesmo diante de acontecimentos crticos (como
atraso no cronograma) ? a) sim
b) no

2.2.2 - Roteiro para Entrevista com os Diretores


Essas perguntas devem ser realizadas a todos os Diretores ao mesmo tempo. Eles devem entrar em
consenso (dentro do possvel) e escolher uma das respostas.
1 (M6.1) - Qual a experincia de vocs em fazer estimativas de durao de projetos? (fazer uma
mdia aritmtica das experincias de cada Diretor)
a) Grande (j realizaram estimativas para mais de 6 projetos)
b) Mdia (j realizaram estimativas para 3, 4 ou 5 projetos)
c) Pequena (j realizaram estimativas para 2 ou menos projetos)
2 - (M7.1) Qual a quantidade de informao que vocs possuem sobre a durao de projetos
anteriores semelhantes?
a) Existe informao sobre a durao real e planejada de projetos anteriores semelhantes.
b) Existe informao apenas sobre a durao planejada de projetos anteriores semelhantes.
b) No existe informao sobre a durao de projetos anteriores.
3 - (M15.1) Qual foi o tamanho que vocs estimaram para o projeto? a)
Grande (durao planejada maior do que 8 meses)
b) Mdio (durao planejada entre 4 e 8 meses)
c) Pequeno (durao planejada menor ou igual a 4 meses)

149

2.2.3 - Roteiro para Entrevista com o Gerente


1 - (M10.1) Existe um processo sistematizado para a produo dos documentos? X)
sim, e ele faz parte de um modelo de processo.
b) sim, existe uma ordem para a produo dos documentos mas ela no est documentada. c)
no. (pular a questo a seguir)
2 - (M10.2) Esse processo foi seguido durante todo o projeto? a)
sim.
b) no.
3 - (M12.1) Qual foi a sua dedicao para o projeto? ___ horas/semana aproximadamente.
4 - (M17.1) Existe uma poltica para o controle das verses dos documentos? X) sim.
b) no. (pular as prximas 2 questes)
5 - (M17.2) Essa poltica est documentada de alguma maneira? X)
sim.
b) no.
6 - (M17.3) Essa poltica foi seguida durante todo o projeto? a)
sim.
b) no.
7 - (M18.1) Foi feito um cronograma para o projeto? a)
sim.
b) no. (pular as prximas 2 questes)
8 - (M18.2) Esse cronograma foi seguido durante todo o projeto? a)
sim, foi seguido durante todo o projeto.
b) no, ele foi abandonado aps a re-elaborao.
c) no, o cronograma nunca foi seguido.
9 - Ocorreram atrasos no cronograma? a)
sim.
b) no. (pular a questo a seguir)
9 - (M18.3) Quando ocorreram atrasos, o cronograma foi re-elaborado? a)
sim.
b) no.
10 - (M19.1) Qual foi a qualidade do acompanhamento do trabalho?
a) Satisfatria (foram registradas as horas trabalhadas e as atividades realizadas nessas horas)
b) Mdia (foram realizadas comunicaes informais do estado do desenvolvimento)
c) Insatisfatria (nenhum acompanhamento realizado)
11 - (M19.2) A maneira de realizar o acompanhamento do trabalho foi seguida durante todo o projeto?
a) sim, o acompanhamento do trabalho realizado durante todo o projeto.

150

b) no, o acompanhamento do trabalho abandonado no meio do projeto.

2.2.4 - Roteiro para Inspeo dos Documentos


Pea ao Gerente do Projeto os documentos do projeto (de preferncia, o ltimo backup), e procure os
seguintes documentos: "Documento de Pr-Planejamento do Projeto (DG-002)", "Documento de Fim
do Projeto (DG-013)", "Casos de Uso (DT-002)", "Diagramas de Projeto (DT-004)" e o Cdigo-fonte.
1 - (M8.1) Qual o nvel de consistncia entre as operaes de sistema e os diagramas de
colaborao? (observar e comparar as operaes de sistema registradas no DT-002 com os
diagramas de colaborao presentes no DT-004)
a) Alto (para cada operao de sistema de cada caso de uso, existe um diagrama de colaborao)
b) Mdio (para 70% a 99% das operaes de sistema, existe um diagrama de colaborao
correspondente a cada operao)
c) Baixo (para menos de 70% das operaes de sistema, existe um diagrama de colaborao
correspondente a cada operao)
2 - (M9.1) Qual o nvel de consistncia entre as classes do projeto e do cdigo? (observar e comparar
as classes do diagrama de classes, presentes no DT-004, com as classes implementadas no
cdigofonte)
a) Alto (todas as classes projetadas foram implementadas)
b) Mdio (de 70% a 99% das classes que aparecem no diagrama de classes foram implementadas)
c) Baixo (menos de 70% das classes projetadas foram implementadas)
3 - (M9.2) Qual o nvel de consistncia entre os nomes das classes do projeto e do cdigo? (idem 2) a)
Alto (os nomes das classes implementadas e projetadas so iguais)
b) Mdio (70% a 99% dos nomes das classes implementadas so iguais aos nomes das classes
projetadas)
c) Baixo (menos de 70% dos nomes das classes implementadas so iguais aos nomes projetados para
elas no diagrama de classes)
4 - (M9.3) Qual o nvel de consistncia entre os atributos e mtodos das classes do projeto e do
cdigo? (idem 2)
a) Alto (todos os atributos e mtodos de todas as classes que aparecem no diagrama de classes foram
implementados em suas devidas classes)
b) Mdio (70% a 99% dos atributos e mtodos que aparecem no diagrama de classes foram
implementados)
c) Baixo (menos de 70% dos atributos e mtodos que foram projetados esto implementados)
5 - (M9.4) Qual o nvel de consistncia entre os nomes dos atributos e mtodos das classes do projeto
e do cdigo? (idem 2)
a) Alto (todos os atributos e mtodos possuem o mesmo nome na implementao e no projeto)
b) Mdio (70% a 90% dos atributos e mtodos implementados possuem o mesmo nome projetado)
c) Baixo (menos de 70% dos atributos e mtodos possuem o mesmo nome na implementao e no
projeto)
6 - (M11.1) Qual era a data prevista para o final do projeto? (copiar do DG-002) __/__/20__
7 - (M11.2) Qual foi a data real do final do projeto? (copiar do DG-013) __/__/20__

151

3 - Preparao para a Anlise e a Interpretao


Nesta seo so apresentados recursos (tabelas e grficos) para facilitar a comparao entre os dados coletados e as hipteses, facilitando assim a
Anlise e Interpretao da Avaliao.

3.1 - Representao em Tabela


Os fatores de qualidade e de variao foram agrupados na mesma tabela para possibilitar a visualizao de todas as medidas relacionadas a uma mesma
meta em uma s tabela.

3.1.1 - Qualidade e Durao


As metas Qualidade e Durao foram colocadas em tabelas separadas para simplificar o seu entendimento.

3.1.1.1 - Qualidade

Medida
Hiptese
Antes

Qual a
experincia da
equipe em
desenvolvimento
de software?

Importncia
atribuda
pela equipe
s tcnicas
de ES.

Continuaria
utilizando
essas
tcnicas
mesmo em
perodos
crticos?

Nvel de
consistncia
entre
requisitos e
projeto.

Nvel de
consistncia
entre as
classes do
projeto e do
cdigo.

Nvel de
consistncia
entre os
nomes das
classes do
projeto e do
cdigo.

Nvel de
consistncia
entre os
atributos e
mtodos das
classes do
projeto e do
cdigo.

M1.1
Mdia

M3.1

importante

M3.2
No

M8.1
Baixo

M9.1
Baixo

M9.2
Baixo

M9.3
Baixo

Nvel de
consistncia
entre os
nomes dos
atributos e
mtodos das
classes do
projeto e do
cdigo.
M9.4
Baixo

Qual o grau de
sistematizao
da produo
dos
documentos?

Esse
processo
foi
seguido
durante
todo o
Projeto?

M10.1
No h
nenhuma
ordem

M10.2
No

152
Hiptese
Depois

Mdia

importante

Sim

Alto

Alto

Alto

Alto

Alto

Existe um
modelo de
processo.

Sim

Projeto
Piloto 1
Projeto
Piloto 2

3.1.1.2 - Durao
Qual a experincia da equipe em
fazer estimativas de durao de
projetos?

Qual a quantidade de informao que Qual foi o atraso do Projeto?


a equipe possui sobre a durao de
projetos anteriores semelhantes?

Medida
Hiptese Antes

M6.1
Pequena

Hiptese Depois

Mdia

M7.1
No h nenhuma informao sobre a
durao de projetos anteriores.
Existe informao sobre a durao
real e planejada de projetos
anteriores.

Projeto Piloto 1
Projeto Piloto 2

M.11.1 e M11.2
5 meses
1 ms

153

3.1.2 - Gerncia
Qual foi a
dedicao do
Gerente para
o projeto? (em
horas/semana)

Medida M12.1
Hiptese 5
Antes
Hiptese 10
Depois
Projeto
Piloto 1
Projeto
Piloto 2

Qual foi
o
tamanho
que a
equipe
estimou
para o
projeto?

Existe uma
poltica para
o controle
das verses
dos
documentos?

Essa poltica
est
documentada
de alguma
maneira?

Essa
poltica
foi
seguida
durante
todo o
projeto?

Foi feito um
cronograma
para o
projeto?

Esse
cronograma
foi seguido
durante
todo o
projeto?

Quando
ocorreram
atrasos, o
cronograma
foi
reelaborado?

Qual foi a
qualidade do
acompanhamento
do trabalho?

A maneira de
realizar o
acompanhamento
do trabalho foi
seguida durante
todo o projeto?

M15.1
M17.1
Pequeno No

17.2
-

17.3
-

18.1
Sim

18.2
No

18.3
No

19.1
Insatisfatria

19.2
No

Mdio

Sim

Sim

Sim

Sim

Sim

Satisfatria

Sim

Sim

155

3.2 - Representao em Grficos


A representao em grficos encontra-se no arquivo anexo "graficos-avaliacao.xls".
Para cada meta h uma planilha, contendo os grficos e as tabelas a partir do qual eles foram
construdos.
Cada medida foi separada em um grfico e sua correspondente tabela.
Desse modo, aps a coleta deve-se apenas preencher as tabelas do arquivo que o grfico ser
atualizado automaticamente.