Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
por
MARLISE THERE DIAS
Dedico este trabalho a meu marido e meu filho, a minha famlia, aos amigos de verdade e a todos
aqueles a quem este trabalho possa ser til.
iii
Voc no sabe o quanto eu caminhei, pra chegar at aqui, percorri milhas e milhas antes de
dormir, eu no cochilei... (Toni Garrido)
iv
AGRADECIMENTOS
Agradeo a Deus que me permitiu a vida e a quem recorri nos momentos de desnimo.
Agradeo a toda minha famlia que sempre me apoiou. Em especial ao meu marido
Alexandre, meu Filho Pedro Henrique que se furtaram de minha presena nos momentos de estudo.
A meu pai e minha por me auxiliarem nos cuidados com meu filho e apoio para a finalizao da
dissertao. Agradeo tambm aos meus irmos e cunhadas pelo sempre apoio.
Agradeo ao professor Marcello Thiry pelo auxlio nas atividades iniciais para o ingresso ao
mestrado, durante o curso deste e tambm na presena da banca desta dissertao. Agradeo a
professora Christiane Gresse von Wangenheim, que com sua competncia e pacincia soube me
conduzir ao final deste trabalho. Agradeo aos professores Anita Maria da Rocha Fernandes,
Adhemar Maria do Valle Filho e Clenio Figueiredo Salviano pelas contribuies na banca. A todos
os professores do mestrado com os quais convivi durante estes 2 anos o meu muito obrigada.
Agradeo a todos os amigos que direta ou indiretamente contribuiriam para que eu chegasse
ao fim desta jornada especialmente a Lu que sempre me incentivou nas horas em que tive vontade
de desistir e pela ajuda durante as vrias fases da criao da dissertao; a Fe e Alessandro pela
compreenso no desempenho de atividades em comum; a Anita pelas conversas encorajadouras;
Maiara pelas trocas nos momentos de desespero; e as amigas J e Manu que mesmo distante sempre
me cobravam em forma de incentivo a defesa da dissertao. Amo todos vocs.
Agradeo tambm aos colegas Maiara, Richard, Jean, Gisele e Alecir que participaram da
avaliao do guia foco desta pesquisa, atividade crucial para a finalizao do trabalho. Ao Mauricio
Fiorese da empresa JExperts pela ateno em apresentar a ferramenta JExpChannel para este
trabalho. Tambm a professora e colega Elisa Coral pela colaborao na fase final desta dissertao.
Agradeo a UNIVALI por proporcionar este mestrado e tambm pela bolsa parcial recebida
para auxiliar nos custeios deste programa. Estendo aqui meus agradecimentos ao professor Cesar
Albenes Zeferino coordenador do mestrado pela ateno dispensada e a Maria de Lurdes Rodrigues
dos Santos secretria do programa de mestrado pelo carinho que sempre me atendeu.
Enfim, agradeo a todos que direta ou indiretamente contriburam para a realizao deste
trabalho.
RESUMO
vi
ABSTRACT
The estimate activity has different models/techniques to be executed and it is a required task in
adoption of software process improvement and project management guidelines. However, it can be
noticed that micro and small software companies have some difficulties to apply such estimate
models/techniques and also software process improvement models. Thus, this work presents the
development of a guide to estimate activity effort and duration and also project size to software
micro and small companies. The guide is aligned to process improvement models CMMI-DEV,
MPS.BR e ISO/IEC 15504 and to PMBOK as a reference to project management. The research is
characterized as being applied and descriptive, using collection of data to guide the creation of
bibliographic and documentary guide. For this, characteristics of Software MPEs were researched,
as well as theoretical aspects of software improvement models, PMBOK guide and main estimates
models/techniques. The assessment guide used the GQM method with Software Engineering
professionals. The guide presents theoretical aspects about project management, planning and
software estimates, process improvement models and PMBOK guide; It describes a generic process
to the estimate activities, detailing selected estimate models/techniques, templates and examples for
those. It also presents specific tools to the area and a conformity table comparing the guide and the
process improvement models cited and the project management guide.
The guide evaluation showed a first indication that it is viable its application in Software Micro and
Small Businesses for presenting relevant and adequate content about the theme.
vii
LISTA DE FIGURAS
viii
LISTA DE GRFICOS
Grfico 1 - Porte das empresas considerando a fora efetiva de trabalho ......................................... 93
Grfico 2 - Utilizao de estimativas por empresas de software ....................................................... 97
Grfico 3 Variao do esforo para aplicar o guia........................................................................ 142
Grfico 4 Indicativo percentual sugerido de base no PMBOK ..................................................... 149
Grfico 5 Comparativo do percentual de alinhamento aos modelos de melhoria de processo ..... 151
ix
LISTA DE QUADROS
LISTA DE TABELAS
xi
LISTA DE EQUAES
xii
xiii
SUMRIO
1
INTRODUO ........................................................................................................................ 16
xiv
xv
1 INTRODUO
De acordo com Drucker (1989), as empresas so impulsionadas a investir para se manterem
num mercado complexo e dinmico, independente de seu porte. Atualmente, com os investimentos
das organizaes em softwares que facilitem o desenvolvimento de suas atividades h uma
preocupao das empresas de software em atender bem aos clientes e para isso buscam uma
estrutura que lhes permita fornecer a estes, produtos de qualidade de acordo com suas necessidades
(MIT, 2002).
Neste contexto, encontram-se as micro e pequenas empresas de software (MPEs), que de
acordo com MCT (2002) esto em torno de 70% no Brasil, se utilizado o critrio de fora de
trabalho, ou seja, nmero de funcionrios para definir o porte destas. Conforme SEBRAE (2004)
empresas com at 9 funcionrios considera-se micro empresa e de 10 a 49 empregados pequena
empresa. Estas, perante o aumento de demanda de mercado, necessitam adotar estratgias que
possibilitem seu crescimento e desenvolvimento com qualidade (UEHARA, 2003). Isto implica no
fornecimento e produo de software ou servio com qualidade e produtividade.
No entanto, percebe-se em pesquisa do Standish Group (1994) que 31,1% dos projetos so
cancelados antes de serem finalizados e 52,7% ultrapassam o custo estimado; apenas 16,2 dos
projetos so concludos no tempo e com o oramento previsto. Uma pesquisa mais recente do
Standish Group (2004) afirma que 27% dos projetos so finalizados dentro do tempo e com o custo
previsto, que 40% dos projetos so cancelados antes de terminarem e que 50% dos projetos em
mdia custam 180% a mais do que foi estimado inicialmente. Pode-se perceber que houve uma
melhora no que se refere aos projetos com sucesso de 16% para 27%, porm este nmero ainda
preocupante visto que no equivale nem a metade dos projetos. Ainda em trabalho mais recente
Charette (2005) afirma que de 5% a 15% dos projetos na rea de Tecnologia da Informao so
abandonados antes ou logo aps o seu incio; outros sero modificados em funcionalidade e
oramento at o final, e poucos sero completados com sucesso.
Charette (2005) ressalta ainda que quando um projeto falha pode por em risco a
sobrevivncia da empresa. Nas MPEs este fator ainda mais relevante, pois iniciam suas atividades
com um capital baixo e trabalham sempre no limite. De acordo com o SEBRAE (2004) 49,4% das
MPEs de vrios setores no Brasil at 2002, tiveram um tempo mximo de vida de 2 anos e as
principais causas foram falta de capital de giro e problemas financeiros, o que confirma uma
possvel mortalidade da empresa no caso de um projeto com insucesso, considerando o
investimento inicial das MPEs. Outro fator de mortalidade ressaltado foi a forte concorrncia.
No contexto das MPEs de software, para manter-se no mercado e crescer, estas necessitam
de solues em engenharia de software efetivas (RICHARDSON e WANGENHEIM, 2007). No
entanto, de acordo com pesquisa realizada pelo MCT (2005), as MPEs em sua maioria dependem
demais de seus recursos humanos, pois se utilizam de um processo de desenvolvimento de software
informal. Em sua grande maioria acreditam que modelos de referencias e padres/normas
despenderiam recursos e tempo demais, sendo muito difceis de serem aplicadas (RICHARDSON e
WANGENHEIM, 2007). Desta forma, para que se mantenham competitivas no mercado uma
soluo s MPEs o investimento na melhoria de sua qualidade e produtividade, que pode ser
visualizada em seu produto final (WEBER; HAUCK; WANGENHEIM. 2005).
Tipicamente, o desenvolvimento de um software ou servio considerado um projeto, sendo
este um esforo temporrio para criao de um produto ou servio nico (PMI, 2004). No entanto,
torna-se necessrio o planejamento e acompanhamento deste projeto para que se obtenha o produto
esperado. Sendo assim, a adoo de um modelo de gerenciamento de projetos de software pode
possibilitar as MPEs qualidade e produtividade no processo de criao e obteno de um produto
final. De acordo com Jalote (2002), entre as causas mais comuns para o insucesso em projetos est a
falta de uma metodologia de gerncia de projeto, justificando a carncia das empresas de software
na adoo destas.
De acordo com PMI (2004), o gerenciamento de projetos a aplicao de conhecimento,
habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. O
objetivo do gerenciamento de projetos entregar ao cliente um produto/servio de qualidade que
est dentro do escopo, do tempo e do oramento determinados no planejamento do projeto (PMI,
2004).
Neste sentido, este projeto trata de uma das reas relacionadas ao gerenciamento de projetos,
considerada crucial para obteno de um desenvolvimento de software adequado, o planejamento.
Nesta atividade seus vrios processos e interaes definiro um plano para que o projeto possa ser
gerenciado (PMI, 2004). Wysocki e McGary (2003) afirmam que o planejamento de projeto
indispensvel, alm de apresentar a maneira como o trabalho deve ser desenvolvido, torna-se uma
17
1.1 MOTIVAO
Percebe-se conforme Standish Group (1994), que entre as principais caractersticas
apontadas de falhas em projetos de software est a superao do custo e do tempo. A primeira
apresenta 214% (em pequenas empresas) acima da estimativa inicial e a segunda em 239% (em
pequenas empresas). Estes dados confirmam que a aplicao das tcnicas existentes no est
trazendo o resultado esperado. Torna-se relevante verificar que este fato pode ocorrer pela falta de
18
adoo das tcnicas/modelos existentes e/ou por estes no serem direcionados as MPEs e por este
motivo no estarem sendo adotados.
Aliado a isto, as micro e pequenas empresas apresentam dificuldades na aplicao nos
modelos e normas de melhoria de processo de software existentes (PMI, 2007a). Um dos fatores o
fato de modelos como o CMMI-DEV (SEI, 2006) e a norma ISO/IEC 15504-5 (ISO/IEC Std.
15504, 2005), terem sido direcionados principalmente para grandes empresas. Outro ponto que
estes modelos no foram desenvolvidos com intuito de apresentar descries ou definies da
melhor forma de realizar estimativa e de quais tcnicas seriam interessantes dependendo da
organizao (SEI, 2006; ISO/IEC 15504-5, 2005; SOFTEX, 2007). Esta caracterstica tambm
observada no MPS.BR (SOFTEX, 2007), modelo brasileiro criado objetivando pequenas e mdias
empresas, mesmo apresentando um guia de implementao no tem como objeto o detalhamento
das atividades relacionadas a estimativa de software.. Desta forma, modelos e normas se tornam, na
viso das MPEs demorados, caros e difceis de serem implantados segundo Johnson e Brodman
(1997), no que se refere ao CMM para pequenas organizaes. A falta de modelos especficos para
este tipo de empresa pode levar a no adoo de uma metodologia para a gesto de seus projetos
(JOHNSON e BRODMAN, 1997).
Desta forma, este trabalho est direcionado para suportar o processo de estimativa de
projetos de software alinhando aos modelos para gerenciamento de projetos e a modelos e normas
de qualidade existentes.
Pergunta de pesquisa
Desta forma, esta pesquisa pretende responder a seguinte questo:
A utilizao de um guia de estimativas contribui, em termos de facilidade e eficincia, para
definio de um processo de estimativa de projetos (tamanho de software, durao e esforo de
durao) em MPEs de software, de forma a orientar na implementao desta atividade alinhada a
modelos de melhoria de processo de software?
19
Proposta de soluo
Este trabalho prope a criao de um guia para estimativas de parmetros de projeto,
envolvendo esforo e durao de atividades; e atributos de produtos de trabalho como tamanho,
aplicado s MPEs de Software.
Pretende-se com base nos mtodos e tcnicas de estimativas existentes apresentar opes
que estejam adequadas e alinhadas as caractersticas de uma MPE. Tambm ser considerado como
base para este trabalho o guia de gerncia de projetos PMBOK (PMI, 2004), alm de modelos e
normas de qualidade e produtividade de software como CMMI-DEV (SEI, 2006), a norma ISO/IEC
15504 (ISO/IEC Std. 15504, 2005) e o MPS.BR (SOFTEX, 2007).
Justificativa
Pretende-se atravs da existncia e utilizao de um guia para estimativas voltado para o
contexto de MPEs de software, facilitar a tarefa de realizar estimativas em MPEs, fazendo com que
estas tenham projetos mais viveis e por conseqncia tornando a execuo destes mais precisos.
Isto pode aumentar a competitividade e o sucesso das MPEs e conseqentemente ser uma possvel
contribuio para evitar a mortalidade to precoce de tantas empresas deste porte. Alm disso,
poder favorecer ao aumento de preciso no processo de estimar em micro e pequenas empresas de
software, reduzindo, por exemplo, o tempo/esforo que os responsveis necessitam para estimar.
Este guia servir como orientao aos consultores que realizam a implantao de programas
de melhoria de processo baseado em modelos ou normas de qualidade e produtividade de software
em MPEs, para a escolha de tcnicas de estimativas que possam ser utilizadas pela empresa e
permitam o alinhamento aos modelos. Cabe salientar, que a atividade de estimar um processo
dentre os vrios que devem estar adequados aos modelos e normas para a obteno de avaliao
pelas empresas, assim a utilizao do guia poder contribuir tambm na obteno de avaliaes
oficiais das MPEs no que se refere a padronizao do processo de estimar.
Outro fator que pode ser considerado em relao ao uso do guia que por estar alinhado a
modelos internacionalmente reconhecidos, ele pode contribuir indiretamente para a insero destas
empresas no mercado exterior. De acordo com SOFTEX (2005), em pesquisa realizada com 30
empresas com valores significativos de exportao, quatorze empresas brasileiras que exportavam
software eram de pequeno e mdio porte. Entre as barreiras citadas para exportao de software
20
encontra-se a falta de certificaes de qualidade e tcnicas. Alm disso, o relatrio cita como fatores
crticos para competitividade no exterior a qualidade de produtos, pontualidade, preo de venda e
custo de produo. Logo, percebe-se que a proposta apresentada pode tambm auxiliar as MPEs na
busca de um mercado fora do pas, pois os recursos e o tempo estimados fazem parte dos aspectos
apontados que comprometem a competitividade no mercado externo.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Estabelecer um guia para estimativa de esforo e durao de atividades e tamanho do
produto de trabalho para micro e pequenas empresas de software alinhado aos modelos de melhoria
de processo CMMI-DEV, ISO/IEC 15504 e MPS.BR e ao PMBOK como referncia a gerncia de
projetos.
OE3.
Analisar
modelos/tcnicas
existentes
para
estimativas
relacionadas
21
1.3 METODOLOGIA
Para melhor compreenso dos mtodos que foram utilizados nesta dissertao, este tpico
ser dividido em metodologia da pesquisa e metodologia da aplicao.
22
Os objetivos OE1, OE2, OE3 e OE4 vislumbram a descrio dos fenmenos em estudo, com
intuito de oportunizar aos pesquisados o conhecimento profundo e detalhado da realidade estudada,
possibilitando a comparao, levantamento e registro de caractersticas que abordam o PMBOK,
modelos de melhoria de qualidade de software e MPEs. Quanto pesquisa descritiva destaca-se o
pensamento de Oliveira (2001) em que sustenta que este tipo de estudo permite identificar diversas
formas dos fenmenos, bem como analisar as variveis de causa e efeito. Enfim, pode-se dizer que
o estudo descritivo fornece ao pesquisador a compreenso do comportamento de diversos
fenmenos.
Com base na descrio dos fenmenos so atendidos os objetivos OE5 e OE6, que esto
baseados no desenvolvimento do guia de estimativas. Estes por sua vez, reforam a caracterstica
aplicada deste estudo e se fundamentam em uma pesquisa bibliogrfica construda a partir dos
pensamentos de tericos a cerca do PMBOK, CMMI-DEV, ISO/IEC 15504-5 e MPS.BR. Destacase que, segundo Marconi e Lakatos (1999) a pesquisa bibliogrfica aborda o levantamento, a
seleo e a documentao de bibliografias j publicadas, sobre o assunto pesquisado, e tem como
objetivo proporcionar ao pesquisador contato direto com o material j escrito sobre o mesmo.
Em especial quanto s informaes sobre as caractersticas das MPEs, foram descritas por
meio de pesquisas disponveis no site do MCT (Ministrio da Cincia e Tecnologia) e outras
pesquisas relacionadas ao tema. No que diz respeito ao OE7, destaca-se que aborda conceitos e
resultados que norteiam as anlises deste estudo, pois pretende apresentar um cenrio de avaliao
da aplicao do guia.
23
fim de identificar a existncia ou no das caractersticas desejadas descritas nos requisitos. Por fim,
foi possvel realizar a anlise das ferramentas assim como uma comparao entre as funcionalidades
disponveis e as desejadas.
A seqncia lgica desta aplicao est ilustrada na figura 1.
24
que necessitam ser modificados e/ou adaptados que tornem o guia de estimativa contribuinte ao
processo de estimar da MPEs de softwares, alm de sua validao como um material de auxlio na
implantao de um processo de estimativa de software neste tipo de empresa.
25
2 FUNDAMENTAO TERICA
Neste tpico so apresentados os fundamentos tericos que norteiam o desenvolvimento
deste trabalho. abordado o tema gerncia de projeto, em especial a fase de planejamento que
possui entre suas atividades a de estimar que o foco deste projeto. Neste caso, as tcnicas e
modelos de estimativa so tambm apresentados.
Alm disso, os principais modelos de melhoria de processo de software que so foco deste
trabalho: CMMI-DEV (SEI, 2006), MPS.BR (SOFTEX, 2007) e ISO/IEC 15504-5 (ISO/IEC Std.
15504, 2005), so apresentados abordando conceitos, a rea de planejamento de projetos e como
cada um trata estimativas.
O PMBOK que a base para o guia que foi proposto tambm apresentado em especial
suas reas de processo que tratam de estimativas.
Iniciao: esta atividade define o incio de um projeto, com processos que facilitam a
autorizao formal desde o comeo. Esta atividade tambm realizada para incio de
fases do projeto visando sempre a verificao da viabilidade de continuao ou no do
projeto.
Execuo: esta fase possui processos que executam atividades com intuito de cumprir o
que foi determinado no plano de projeto.
Por ser foco de trabalho desta dissertao a atividade planejamento ligada a gerncia de
projetos ser melhor detalhada nas prximas sees.
2.2 PLANEJAMENTO
O planejamento de projeto a chave para uma boa gerncia de projetos (THOMSETT,
2002). De acordo com o autor um planejamento detalhado e preciso fornece informaes bases para
o projeto e define os negcios que so relevantes para a criao da soluo tcnica.
A fase de planejamento de projeto identifica as atividades, marcos e os documentos que
sero criados em determinado projeto. Cabe ressaltar que o plano deve ser desenvolvido para
27
alcanar os objetivos do projeto (SOMMERVILLE, 2003). Wysocki e McGary (2003) afirmam que
o plano de projeto indispensvel tanto para determinar como o trabalho deve ser realizado quanto
para auxiliar na tomada de deciso. O planejamento fornece informaes para que o gestor possa
escolher a melhor alternativa para determinado projeto.
O planejamento apresenta pelo menos trs vantagens (Wysocki e McGary, 2003):
Reduz a incerteza, pois a partir das sadas desejadas possibilita aplicar aes corretivas
necessrias a tempo.
Aumenta a compreenso, j que durante sua criao tem-se maior clareza dos objetivos e
metas do projeto.
28
Cada passo apresentado na figura 2 dividido em atividades (Quadro 1) que devem ser
realizadas para que o objeto da fase seja alcanado.
29
Passo
1
5
6
9
10
Atividades
IDENTIFICAO DO ESCOPO E OBJETIVOS DO PROJETO
1.1: Identificar os objetivos e medidas prticas para comprovar sua eficcia
1.2: Identificar todos os interessados (stakeholders) no projeto
1.3: Estabelecer mtodos de comunicao com todas as partes
IDENTIFICAR INFRA-ESTRUTURA DO PROJETO
2.1: Identificar a infra-estrutura do projeto
2.2: Identificar padres e procedimentos
2.3: Identificar a organizao da equipe de projeto
ANALISAR CARACTERSTICAS DO PROJETO
3.1: Analisar as caractersticas do projeto
3.2: Identificar riscos do projeto em alto nvel
3.3: Selecionar o ciclo de vida do projeto
3.4: Revisar estimativas de recurso
IDENTIFICAR AS ATIVIDADES E PRODUTOS DO PROJETO
4.1: Identificar e descrever produtos do projeto (deliverables)
4.2: Produzir uma rede de atividades
4.3: Introduzir validaes entre os estgios das atividades
ESTIMAR ESFORO PARA CADA ATIVIDADE
5.1: Estimar esforo
IDENTIFICAR RISCOS DAS ATIVIDADES
6.1: Identificar e quantificar as atividades de risco
6.2: Planejar reduo de risco e medidas de contingncia apropriadas
ALOCAR RECURSOS
7.1: Identificar e alocar recursos humanos
7.2: Estabelecer o cronograma
7.3: Estabelecer o oramento
REVISAR E PUBLICAR O PLANO
8.1: Revisar aspectos de qualidade do plano de projeto
8.2: Documentar planos e obter concordncia
EXECUTAR O PLANO
PLANEJAMENTO DE NIVEL BAIXO
30
Neste passo tambm devem ser definidos os stakeholders envolvidos no projeto, bem como,
seu grau de autoridade dentro do projeto. Alm disso, define-se tambm como se dar a
comunicao entre os envolvidos no projeto (HUGHES; COTTERELL, 1999).
A infra-estrutura do projeto considerada no passo 2, referindo-se aos recursos necessrios
a execuo do projeto considerando-se a existncia ou necessidade de aquisio de local e ambiente
de trabalho, hardware, software, servios, treinamentos, entre outros (HUGHES; COTTERELL,
1999).
O passo 3 refere-se a anlise de caractersticas dos projetos em que se torna relevante a
certificao de que os mtodos adequados sero utilizados para o alcance dos objetivos do projeto.
Destaca-se a seleo do ciclo de vida e as estimativas do projeto (vide seo 2.2.1). (HUGHES;
COTTERELL, 1999).
A identificao de produtos e atividades do projeto e ainda a descrio destes destacada no
passo 4 do quadro 1. Sugere-se que estas sejam definidas e documentadas de acordo com o ciclo de
vida selecionado com o intuito de alcana o objetivo do projeto (HUGHES; COTTERELL, 1999).
A documentao pode ser realizada por meio de workflow demonstrando aspectos relevantes como
se um determinado produto de trabalho precisa existir para que outro seja obtido.
Estimar esforo (vide 2.2.1) o passo 5 e implica em apontar o tempo que ser dedicado a
cada atividade para que sejam realizadas da forma adequada. Neste contexto, a tcnica/mtodo
escolhido depender de fatores relacionados a realidade da empresa desenvolvedora do projeto.
No passo 6 deve-se identificar riscos inerentes ao projeto com intuito de diminuir o nmero
de riscos, bem como planej-los e control-los durante a execuo do projeto para que no haja
possibilidades de perder o projeto.
A identificao e alocao de recursos humanos abordada no passo 7 a fim de realizar
proviso de quem executar qual tarefa. Com base nestes e em dados anteriores torna-se possvel
realizar o cronograma do projeto, assim como o oramento destinado a este.
No passo 8 h uma reviso e publicao do plano. No primeiro aspecto deve-se observar
atributos de qualidade por meio da definio de critrios para garantir o sucesso na execuo do
31
projeto. Com relao a publicao pressupe-se a documentao deste artefato a fim de que possa
obter o conhecimento e aval de todos os envolvidos no desenvolvimento.
Os passos 9 e 10 referem-se a execuo do plano e planejamento deste em nvel baixo. o
primeiro refere-se a por em prtica o planejamento criado, j o segundo diz respeito a elaborao
dos planos em um nvel maior de detalhamento.
Nesta pesquisa torna-se relevante considerar os passos 1, 3, 4, 5 e 7, por apresentarem
aspectos relativos ao foco deste estudo, as estimativas que so detalhadas no prximo tpico deste
captulo.
32
o fato de no ter conhecimento do que realmente uma estimativa. Este entre todos
o primeiro fator que quem participa do processo de estimar deve considerar o que
entende, compreende por estimativa. Saber que se deseja chegar o mais prximo
possvel da realidade e no estabelecer nmeros improvveis, apenas desejveis.
33
34
Observaes
empricas
Dados
Teoria
Variveis
chaves
Resultados
Atuais
Relacionamentos
Modelos /
Tcnicas
Previses
Projetos
De acordo com a ilustrao, figura 3, pode-se perceber que, o processo genrico para estimar
prev a obteno de dados por meio de observaes empricas e que por vezes apresentam algum
grau de subjetividade, referentes a estimativas sobre atributos especficos (FENTON E PFLEEGER;
1997).
Com base nos dados e nas teorias j existentes e estudadas as variveis chaves no processo
so produzidas. A partir desta anlise de dados e teoria, torna-se possvel criar ou aplicar modelos e
tcnicas de estimativa de software.
Em seguida, a aplicao de modelos gerados ou j existentes torna-se necessria tendo como
objeto a verificao de sua eficincia e preciso por meio da gerao de previses para projetos de
software.
Por fim, a anlise dos resultados obtidos por meio da aplicao de mtodos e tcnicas
realizada, com intuito de avaliar se o que foi obtido demonstra se os mtodos e tcnicas empregados
esto adequados ou necessitam que sejam realizados ajustes, os tornando funcionais e aplicveis.
Cabe destacar que esta abordagem definida por Fenton e Pfleeger (1997), diz que qualquer
estimativa
deve
permitir
utilizao
de
diferentes
mtodos
de
estimativa,
utilizar medidas, no estimativas, como entrada para os modelos e como apoio peridico realizar re-
35
Estimativa bottom-up
As estimativas so realizadas decompondo em detalhes o que se pretende estimar, no caso
projetos de software. Cada parte do projeto decomposta estimada e ao final faz-se a somatria
para que seja obtida a quantidade total estimada (PMI, 2004).
A EAP utilizada para as atividades referentes a esta tcnica, pois em projetos muito
grandes a diviso realizada em tpicos, subtpicos e assim por diante. Se necessrio at o estgio
em que foram encontrados componentes distintos que possam ser executados por algum recurso
humano EAP (HUGHES & COTTERELL, 1999).
A tcnica de estimativa bottom-up uma alternativa para casos em que a empresa no possui
dados histricos referentes a projetos de software anteriores e o estimador necessita fazer
suposies a respeito de caractersticas do sistema.
Estimativa top-down
De acordo com Fenton e Pfleeger (1997), nesta tcnica realiza-se a estimativa do projeto
como um todo e posteriormente cada parte, cada componente estimado considerando o que foi
estimado inicialmente.
A estimativa top-down envolve obter a estimativa de tamanho, definir o nvel de
produtividade do projeto considerando, por exemplo, projetos similares, obter a estimativa global
com base no tamanho e produtividade, realizar a estimativa de esforo das atividades do projeto e
por fim refinar estimativas considerando fatores especficos do projeto (JALOTE, 2002).
Cabe destacar que as estimativas top-down e bottom-up podem ter sua utilizao associada,
pois os gerentes de projetos podem adotar diferentes tcnicas para seus vrios estimadores e obter
36
diferentes estimativas. Como exemplo, parte do projeto pode ser estimado utilizando bottom-up e a
outra parte aplicando top-down (HUGHES & COTTERELL, 1999).
Estimativa paramtrica
Esta tcnica utiliza dados histricos em conjunto com outras variveis como, por exemplo,
linhas de cdigo para estimar. (PMI, 2004). Estes dados so trabalhados de forma estatstica,
obtendo-se informao quantitativa da estimativa.
Os modelos paramtricos utilizam frmulas que se assemelham e consideram a forma da
seguinte na Equao 1 (HUGHES & COTTERELL, 2006):
Esforo = T * P
Equao 1 - Forma modelos paramtricos
Fonte: HUGHES & COTTERELL (2006)
conceito. A idia desta tcnica a criao de estimativas para um novo projeto por meio de
comparao deste com projetos anteriores identificando diferenas e similaridades (MCCONNELL,
2006). Neste caso, o gerente de projeto pode realizar ajustes nos dados obtidos em casos anteriores
e aplicar no que est sendo o objeto atual de trabalho.
37
Distncia =
( parmetro _ atual
parmetro _ origemi )
i =1
Funcionalidades
Projeto antigo 1
Projeto antigo 2
Projeto novo
14000
16300
19600
Regras de negcio
11000
10500
16500
Como exemplo, imagine que o tamanho de determinados projetos antigos de uma empresa,
em linhas de cdigo, para as variveis na Tabela 1. Aplicando a Equao 2 tem-se que a distncia
entre o projeto 1 e o novo de 7849 e entre o projeto 2 e o novo de 6847. Neste sentido, o projeto
2 de acordo com os autores tem uma aproximao maior com o atual e deve ser utilizado para esta
tcnica.
Outro trabalho sugere passos para realizar estimativa por analogia (MCCONNELL, 2006):
1. Obter detalhes referentes ao parmetro a ser estimado observando projetos anteriores
semelhantes, preferencialmente com decomposio de atividades, usando, por exemplo,
38
uma EAP ou outra forma de decomposio. Para encontrar o(s) projeto(s) com maior
semelhana pode-se utilizar a Equao 2.
2. Realizar uma comparao considerando dados e parmetros a estimar do novo projeto
com os dados do projeto antigo abrangendo todas as partes.
3. Construir a nova estimativa do parmetro desejado do novo projeto com base nos dados
obtidos e analisados do projeto antigo selecionado por apresentar maior semelhana.
4. Checar a consistncia dos pressupostos por meio dos projetos (novo e antigo).
Utiliza-se de informaes histricas e opinio especializada. (FENTON e PFLEEGER,
1997; PMI, 2004). Nesta tcnica torna-se interessante a documentao de projetos, principalmente
relativo a estimativas anteriores, forando os estimadores a faz-la para que os dados registrados
possam ser utilizados em novas estimativas. (FENTON e PFLEEGER, 1997).
prximo possvel do desejado, sendo estas estimativas classificadas como a mais provvel (M), a
otimista (O) e a pessimista (P) conforme so descritas a seguir (PMI, 2004; HUGHES &
COTTERELL, 2006):
A estimativa mais provvel (M) prev expectativas realistas para a estimativa, ou seja,
espera-se que apresente os resultados em circunstncias normais.
O melhor caso possvel focado na estimativa otimista (O). Neste tipo, considera-se
condies favorveis e estima-se o menor tempo em que se pode realizar determinada
atividade.
Por fim, a estimativa pessimista (P) que visualiza o pior caso para a estimativa, ou seja,
considera todas as circunstncias e eventualidades que possam prejudicar o
desenvolvimento do projeto.
Assim, PERT combina as trs estimativas previstas utilizando uma frmula apresentada na
Equao 3 em que T a mdia para a estimativa do parmetro desejado.
39
T = (O + 4M + P)/6
Equao 3 - Frmula PERT
Fonte: HUGHES & COTTERELL ( 2006)
possvel para a tcnica PERT calcular o desvio padro que proporciona um nvel de
confiana para a estimativa encontrada. A probabilidade de estar dentro do esperado pode ser
calculada usando a frmula apresentada na Equao 3.
DesvPad = (P O)/6
Equao 4 - Frmula Desvio Padro
Fonte: HUGHES & COTTERELL ( 2006)
Quanto maior for o desvio padro obtido, significa que h um grande intervalo entre o
previsto nas estimativas Otimista e Pessimista. O que se deseja que o resultado do desvio padro
(DesvPad) seja pequeno, pois indica que as estimativas apontadas inicialmente estavam adequadas.
Opinio especializada
De acordo com pesquisas esta tcnica a mais comum e mais utilizada na prtica. As
pesquisas apontam que 72% dos projetos utilizam opinio especializada para estimar
(KITCHENHAM et al., 2002 apud MCCONNELL, 2006).
Os membros da equipe com conhecimento especializado e a partir de dados histricos
podem fornecer estimativa na rea desejada e especfica de seu conhecimento (PMI, 2004). Este
tipo de estimativa exige que se tenha um especialista disponvel. Neste caso, deve-se considerar que
no necessariamente uma pessoa que especialista em desenvolvimento de software ser um
especialista em estimativa, assim sugere-se que a pessoa mais indicada para estimar nesta tcnica
ser aquele que desenvolve a atividade que est sendo foco da criao de estimativa
(MCCONNELL, 2006; LAIRD e BRENNAN, 2006).
Neste sentido, o estimador especialista tem condies de realizar anlises mais precisas, pois
por seu conhecimento consegue prever em suas estimativas, os impactos que solicitaes de
40
Wideband delphi
Esta tcnica proposta por Boehm (1981) realizada em grupo e tem como pressuposto a
41
42
Baixa
Mdia
Alta
3
4
7
4
4
10
6
7
15
10
Baseado neste quadro pode-se calcular os pontos por funo no ajustados (unadjusted
function point count UFP), consistindo da frmula da Equao 5:
UFP = EI * PESO) + (EO * PESO) + ILF * PESO) + (EIF * PESO) + * PESO
(
(
EQ
Equao 5 - Clculo do ponto de funo no ajustado
Fonte: IFPUG (2000).
Na Equao 5, para composio da frmula deve-se para cada componente, separ-lo por
complexidade baseado nos pesos identificados na Quadro 2. Em seguida a quantidade de cada
componente de uma complexidade deve ser multiplicada por seu peso (Quadro 2), por fim realizase o somatrio para estes resultados obtidos.
Com base no UFP realizado um ajuste baseado na complexidade ou dificuldade de
implementao do sistema. Para isso torna-se necessrio o valor do fator de ajuste (value
adjustment factor - VAF). Para determinar o VFA tem-se um conjunto de 14 caractersticas de
sistema com perguntas relacionadas a estas que permitem determinar qual o grau de influncia de
cada caracterstica para o projeto em questo, como segue:
43
O processamento complexo?
Para tanto, utiliza-se de pesos que variam de 0 a 5, sendo classificados como se pode
visualizar na Quadro 3.
Peso
0
1
2
3
4
5
Grau de influncia
Insuficiente
Mnima
Moderada
Mdia
Alta
Essencial
44
O Grau Total de Influncia (total degree of influence - TDI) obtido quando se faz o
somatrio de todos os pesos relacionados s 14 caractersticas do sistema. Desta forma, possvel
obter o ponto por funo ajustado conforme Equao 6, em que 0.01 o Coeficiente por Grau de
Influncia calibrado pela indstria como 0,01 e 0.65 uma constantes emprica.
Desta forma, o VAF pode estar representando uma variao na converso da contagem dos
pontos de funo no ajustado em mais ou menos 35%.
Para finalizar este processo, obtm-se o ponto de funo ajustado (AFP) a partir da Equao
7.
45
SLOC/FP
Linguagem
Access
Ada
ASP
Mdia
35
154
69
Mediano
38
62
Baixo
15
104
32
Alto
47
205
127
Assembler
C
C++
C#
Clipper
COBOL
DBase III
DBase IV
Excel
FORTRAN
FoxPro
HTML
Informix
J2EE
Java
JavaScript
172
148
60
59
38
73
52
47
32
43
42
61
60
56
157
104
53
59
39
77
46
35
42
31
50
59
54
86
9
29
51
27
8
31
25
35
24
50
14
44
320
704
178
66
70
400
63
35
53
57
100
97
65
JCL
JSP
Lotus Notes
Mapper
Oracle
Perl
PL/1
PL/SQL
SAS
Smalltalk
SQL
VBScript
Visual Basic
VPF
Web Scripts
60
59
21
118
38
60
59
46
40
35
39
45
50
96
44
48
22
81
29
58
31
41
32
35
34
42
95
15
21
15
16
4
22
14
33
17
15
27
14
92
9
115
25
245
122
92
110
49
55
143
50
276
101
114
Nesse sentido para obter o tamanho do software utilizando a converso para SLOC
multiplica-se o nmero encontrado na tabela referente a linguagem de programao utilizada pelos
pontos de funo encontrados (AFP). No caso seria interessante utilizar valor mdio apontado no
Quadro 4 (QSM, 2005).
46
A estimativa de durao tambm possvel desde que se tenha o esforo (E), o tamanho da
equipe de trabalho (TE) e a quantidade de horas dirias trabalhadas (HT) por seus integrantes
conforme Equao 9.
Assim com a aplicao das equaes 8 e 9 finaliza-se o processo de obteno dos atributos
esforo e durao com base no tamanho do software obtidos em pontos por funo por meio da
tcnica de Anlise por pontos de funo (IFPUG, 2000).
Neste trabalho optou-se pelo uso da anlise por pontos de funo criada por Albrecht (1981)
e atualmente o desenvolvimento continua com IFPUG (2000). No entanto, torna-se relevante
salientar que existem outras verses desta tcnica desenvolvidas e adaptadas por outras entidades,
cita-se MARK II, NESMA, COSMIC-FFP.
O MARK II um mtodo de anlise quantitativa e medio de tamanho funcional,
considerando o conjunto de requisitos funcionais exigidos pelos usurios para aplicao de produto
de software. Este mtodo destina-se a cumprir com a norma ISO 14143 / 1, a norma internacional
para Medidas de Tamanho Funcional (UKSMA, 1998).
A aplicao deste mtodo independe do modelo de gerenciamento de projetos utilizado e
tambm do mtodo de desenvolvimento de projetos adotado. Por ser uma medida lgica torna-se
independente de como so executados. (UKSMA, 1998).
47
48
funcionais so representados por meio de casos de uso (use cases) quando do uso da UML1. Estes
podem ser definidos como sendo a forma com a qual o usurio utiliza o sistema, sendo compostos
de um conjunto de interaes seqenciais referente as relaes entre o sistema que est sendo
desenvolvido e seu exterior (RIBU, 2001).
O caso de uso deve descrever um comportamento do ponto de vista de um ator2, o que pode
ser muito complexo. Assim, na tentativa de captar a essncia do comportamento torna-se necessrio
exigir um modelo de sistema que possibilite vrios nveis de decomposio (SMITH, 1999).
Partindo do pressuposto que os casos de uso sejam bem selecionados e analisados e que
represem realmente o que o usurio deseja para seu sistema pode-se dizer que se torna conveniente
basear neles estimativas de tamanho e recursos, o que conseqentemente possibilitar estimar
esforo. (RIBU, 2001).
A anlise de pontos por caso de uso teve como inspirao a anlise por pontos de funo,
mas com o beneficio da anlise dos requisitos na forma de modelos de casos de uso (KARNER,
1993). O mtodo necessita que seja possvel para cada caso de uso seja contabilizar o nmero de
transaes, sendo estas consideradas qualquer evento que ocorra entre o ator e o sistema, podendo
ser realizado por completo ou no (BENTE ANDA et al, 2001). Considera-se que a anlise por
pontos de caso de uso tem basicamente quatro passos que sero descritos em detalhes a seguir.
1
2
49
Primeiramente h uma categorizao dos atores dos casos de uso em Simples (S), Mdio
(M) ou Complexo (C) e o clculo de um valor no ajustado dos atores. Os pesos para cada categoria
so respectivamente, 1, 2 e 3 (KARNER, 1993).
Um ator simples refere-se, por exemplo, a uma API (Application Programming Interface)
com outro sistema, possui uma interface bem definida sendo que suas reaes, as sadas do sistema
ou entrada recebidas por ele so bastante previsveis. Pode-se citar como exemplo, no caso de um
sistema de matrcula de uma universidade, a interface com o sistema financeiro que verifica se o
aluno est matriculado (KARNER, 1993; RIBU, 2001).
No que se refere a atores classificados como mdio, so assim considerados quando a
comunicao realizada com um sistema externo por meio de um protocolo como o TCP/IP ou
ainda representa um sistema de hardware, pois a interface de comunicao exigida padronizada
como no caso de protocolo. Cabe destacar que estes atores tm mais propenses a erro e so difceis
de serem controlados (KARNER, 1993; RIBU, 2001).
Atores so classificados como do tipo complexos quando representam pessoas que iro
interagir com o sistema, normalmente por uma interface grfica ou ainda uma pgina web. Por este
motivo diz-se que h maior complexidade neste tipo de ator, j que este pode executar qualquer
atividade, sendo totalmente imprevisveis. Como exemplo, pode-se citar o aluno ou responsvel da
secretaria no sistema de matrcula da universidade (KARNER, 1993; DAMODARAN, 2003; RIBU,
2001; BENTE ANDA et al, 2001 ).
Finalizando este passo calcula-se o total no ajustado do ator (unadjusted actor weights UAW), somando a quantidade classificada para cada categorizao e multiplicando estes totais por
seus respectivos pesos (KARNER, 1993; DAMODARAN, 2003; RIBU, 2001; BENTE ANDA et
al, 2001 ). A Equao 10 demonstra o clculo do UAW.
UAW =
A segunda etapa constitui-se em classificar tambm os casos de uso (USC) em Simples (S),
Mdio (M) ou Complexo (C). Esta categorizao depender do nmero de transies existentes para
50
cada caso de uso, considerando tambm os fluxos alternativos descritos neste. Os pesos para cada
categoria e nmero de transies para cada caso de uso so definidos no Quadro 5 (KARNER,
1993; DAMODARAN, 2003; RIBU, 2001; BENTE ANDA et al, 2001).
Categorias
Simples (S)
Mdio (M)
Complexo (C)
Nmero de transies
1.. 3
4..7
8..*
Pesos
5
10
15
Pode-se tambm realizar a classificao medindo a complexidade dos casos de uso baseado
na contagem das classes de anlise que identificam como um caso de uso implementado (RIBU,
2001). O Quadro 6 apresenta como ocorre a categorizao neste caso.
Categorias
Simples (S)
Mdio (M)
Complexo (C)
Nmero de transies
1.. 5
6..10
11..*
Pesos
5
10
15
Para completar deve-se calcular o total no ajustado de caso de uso (unadjusted use case
weights - UUCW) somando a quantidade de casos de uso em cada categorizao e multiplicando
por seu peso respectivo que pode ser obtido por meio das tabelas 3 e 4 dependendo do aspecto
considerado para a classificao. A Equao 11 representa o clculo do total no ajustado de caso
de uso (unadjusted use case weights - UUCW).
UUCW =
51
A prxima etapa a obteno valor ajustado de ponto de caso de uso (adjusted use case
points - UPC), realizado considerando fatores tcnicos como complexidade e fatores ambientais de
maneira a quantificar requisitos no funcionais, cita-se a usabilidade e motivao do programador.
(RIBU, 2001).
Cada fator tcnico associado a um peso que varia de 0 a 5 dependendo da influncia que
exerce sobre o projeto como um todo (KARNER, 1993): neste caso, o valor 0 significa que o fator
irrelevante no contexto do projeto; o valor 3 significa que o fator relevante com um grau de
influncia mdia; o valor 5 significa que o fator essencial para o sucesso do projeto.
Observe que o Quadro 7 apresenta os fatores tcnicos a serem considerados para encontrar o
valor ajustado de ponto de caso de uso.
FATOR
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13
DESCRIO
Sistema distribudo
Tempo de resposta (desempenho)
Eficincia do usurio final
Complexidade de processamento interno
Reusabilidade de cdigo
Facilidade para instalao
Usabilidade
Portabilidade
Facilidade para mudana
Concorrncia
Caractersticas de segurana
Conexo com outros sistemas
Necessidade para treinamento de usurio
PESO
2
2
1
1
1
0.5
0.5
2
1
1
1
1
1
Karner (1993)
52
TFactor =
FatorT * PesoT
n
Para encontrar o valor final do TCF deve-se multiplicar o TFactor por 0.1 e somar a 0.6
conforme apresentado na Equao 14. A constante 0.6 deriva da tcnica de FPA proposta por
Albrecht (1981) em que se tinha 0,65.
TCF = 0.6 + (0.01* TFactor)
Equao 14 - Clculo do TCF
Fonte: KARNER (1993)
Na seqncia deve-se calcular o Fator ambiental tendo como base a tabela que elenca os
fatores considerados, descries e pesos destes.
Fator
F1
F2
F3
F4
F5
F6
F7
F8
Descrio
A equipe familiar com o processo formal de desenvolvimento que ser utilizado
Experincia da equipe com o tipo de aplicao
Experincia da equipe com orientao a objetos
Capacidade de analise chefe
Motivao da equipe
Estabilidade dos requisitos
Trabalhadores em tempo parcial
Dificuldade com a linguagem de programao escolhida
Peso
1.5
0.5
1
0.5
1
2
1
2
Desta forma, cada um destes fatores deve ser classificado de acordo com seu grau de
influncia no projeto que pode variar entre 0, 3 ou 5 como a descrio apresentada no Quadro 9.
Fatores
F1 a F4
F5
F6
F7
F8
0
Nenhuma experincia
Nenhuma
Mudam constantemente
No haver
Fcil
3
Experincia mdia ou normal
Mdia ou normal
Mudam na mdia
Poucos Mdia
Mdia
5
Alta experincia
Alta
Praticamente no mudam
Pessoal Tcnico
Muito difcil
53
FatorF * PesoF
n
Com base nos clculos do TCF e EF possvel obter o valor total ajustado de pontos de caso
de uso (adjusted use case points - UPC) por meio da Equao 17.
UPC = UUCP*TCF*EF
Equao 17 - Clculo do FA
Fonte: KARNER (1993)
O UPC obtido por meio da multiplicao entre o Total no ajustado de pontos por caso de
uso (UUCP) pelo Fator de complexidade tcnica (TCF) e pelo Fator ambiental (EF).
Por fim a partir deste clculo pode-se obter o esforo necessrio a determinado projeto de
software, utilizando como representao de produtividade um fator de 20 pessoas/hora por ponto de
caso de uso, sendo o total de pessoa/horas necessrias ou requeridas para completar o projeto todo
(KARNER, 1993; DAMODARAN, 2003).
Schneider e Winters (1998 apud BENTE ANDA et al, 2001), afirmam que embora seja
sugerido o uso de 20 pessoas/hora por ponto de caso de uso experincias tem demonstrado que este
nmero tem variado entre 15 e 30 horas por ponto de caso de uso. Ainda sugerem que dependendo
dos fatores ambientais pode-se determinar pessoa/hora por pontos de caso de uso. Se o nmero de
fatores ambientais entre F1 e F6 (Quadro 9) for entre 3 e 4 o esforo de 28 pessoas/horas e se
54
Linhas de cdigo
A tcnica de mensurao por linhas de cdigo (LOC Lines of Code) uma das medidas
55
56
Sendo que NPO o nmero de pontos de objeto, usado para estimar o tamanho de
aplicaes baseadas programao de banco de dados. Esta estimativa se baseia no nmero de telas
exibidas, no nmero de relatrios produzidos e nmero de mdulos na linguagem de programao.
Neste caso, estas devem ser classificadas de acordo com a sua complexidade. As telas exibidas
classificam-se com simples (1 ponto), moderadamente complexas (2 pontos) e muito complexas (3
pontos). No caso dos relatrios, estes so classificados como simples (2 pontos), moderadamente
complexos (5 pontos) e muito complexos (8 pontos). E por ltimo, os mdulos devem contar 10
pontos cada um dos necessrios no sistema. (CENTER, 2004).
O percentual de reuso refere-se ao percentual de reuso que se espera para aquele projeto,
pelo COCOMO h uma calibrao de 2,94. Em casos em que a empresa tenha outros sistemas
semelhantes, o percentual de reuso mede o quanto o projeto ser copiado ou modificado a partir de
produtos j existentes. (CENTER, 2004).
PROD a produtividade que pode ser obtida pelo Quadro 10, dependendo de cada empresa.
Experincia e capacitao do Desenvolvedor
Muito baixa
Baixa
Nominal
Alta
Muito Alta
Muito baixa
4
Baixa
7
Nominal
13
Alta
25
Muito Alta
50
O nvel inicial do projeto h uma equao (19) considerada padro que adotada em que E
o esforo, A um coeficiente que de acordo com definio 2,5, o tamanho obtido por KSLOC,
57
B refere-se ao aumento do esforo medida que o projeto tambm aumenta (varia de 1,1 a 1,24) e
M refere-se a um conjunto de direcionadores de processos:
E = A * TB * M
Equao 19 - Frmula-padro para modelos algoritmos
Fonte: Somerville (2003); Hughes & Cotterell (1999)
Cabe destacar que estes direcionadores podem ser classificados em uma escala de 1 a 6
sendo 1 considerado muito baixo e 6 muito alto conforme percebe-se no quadro 11.
SIGLA
DESCRIO
RCPX
RUSE
PDIF
Confiabilidade e complexidade
do produto
Reuso requerido
Dificuldade de plataforma
PERS
PREX
SCED
FCIL
Capacitao pessoal
Experincia pessoal
Prazo
Recursos de suporte
MUITO
BAIXO
0,75
BAIXO
NORMAL
ALTO
1,09
MUITO
ALTO
1,13
EXTRA
ALTO
1,66
0,88
0,91
0,87
1
1
1,14
1,06
1,29
1,21
1,49
1,57
1,24
1,22
1,29
1,24
1,1
1,10
1,1
1,10
1
1
1
1
0,83
0,88
1
0,86
0,67
0,81
1
0,72
1
0,78
58
Para entender a equao cabe dizer que o nmero de linhas de cdigo-fonte geradas
automaticamente definido por ASLOC; o nvel de produtividade dada por ATPROD; e AT
cdigo total do sistema automaticamente gerado.
O clculo do prazo (TDEV) obtido pela Equao 22.
TDEV = C x (PMF)
Equao 22 - Frmula para estimar prazo
Fonte: Somerville (2003); Hughes & Cotterell (1999)
simplificada e rpida possvel devido as suas caractersticas. Considera alguns aspectos como
clculo somente do que for necessrio, a heurstica funciona to bem quanto algoritmo, confiana
na equipe e a transparncia com o cliente.
Alm disso, devem ocupar apenas 50% do tempo da equipe quando alocando
funcionalidades, considerando tempo para design, discusso, retrabalho, alimentao, entre outros.
Outra questo refere-se a eventuais folgas que devem ser preenchidas com a implementao de
funcionalidades previstas para prxima iterao.
59
Estimativas em mtodos geis trabalham com conceito de user stories que so pequenas
histrias contadas pelo usurio para identificao de requisitos de software. Com isto possvel
definir sem formalismos exagerados as necessidade do usurio (COHN, 2006).
Neste trabalho sero discutidas as tcnicas voltadas a modelos geis Planning Poker e
estimativa no planning game.
Planning Poker
Esta tcnica combina outras tcnicas como opinio especializada, analogia e desagregao
60
Como se pode observar na Figura 4, a forma de realizar esta tcnica simples e pode ser
divida nas fases que seguem (GRENNING, 2002; COHN, 2005).
1.
2.
3.
As cartas so viradas.
4.
Um ponto relevante est no fato de que sua utilizao tende a apresentar reutilizao das
cartas utilizadas para estimar em que consta o valor estimado para determinado parmetro em uma
atividade. Assim, a equipe de estimadores acaba por realizar mais rapidamente esta atividade para
casos de estrias familiares.
Compreende testadores, programadores, administradores de banco de dados, analista de sistemas, enfim todos os
integrantes da equipe do projeto.
61
62
63
no qual se pode discutir, escrever e aplicar o gerenciamento de projetos, podendo ser utilizado por
qualquer profissional da rea.
O PMBOK possui cinco reas de especializao em que se encontram PMI (2004):
64
65
aes corretivas; e o grupo de processos de encerramento que finaliza uma fase ou um projeto por
meio de um documento.
O grupo interesse deste projeto o grupo de processo de planejamento, que tem por objeto
planejar e gerenciar um projeto bem sucedido para a organizao baseado na interao dos
componentes do grupo (PMI, 2004). Neste, informaes relevantes so coletadas assim como
identificado, definido e amadurecido o escopo do projeto, o custo do projeto e so agendadas as
atividades do projeto que ocorrem dentro dele. A Figura 6 apresenta os componentes do grupo de
processo de planejamento.
66
67
como este ser definido, verificado e controlado e de que forma a EAP ser criada e definida.
O desenvolvimento do plano de gerenciamento do escopo do projeto e o detalhamento desse
escopo do projeto se iniciam pela anlise das informaes contidas no termo de abertura do projeto,
pela declarao do escopo preliminar do projeto, pela ltima verso aprovada do plano de
gerenciamento do projeto, pelas informaes histricas contidas nos ativos de processos
organizacionais e por quaisquer fatores ambientais relevantes para a empresa.
Como entradas necessrias para que seja possvel realizar o planejamento do escopo tem-se
fatores ambientais da empresa (por exemplo, cultura da organizao e infraestrutura), ativos de
processos organizacionais (so polticas, procedimentos e diretrizes formais e informais, pode-se
citar polticas organizacionais e informaes histricas), termo de abertura do projeto, declarao do
escopo preliminar do projeto e plano de gerenciamento do projeto.
Como ferramentas e tcnicas para obteno dos resultados pode-se citar Opinio
especializada, Modelos, formulrios, Normas (podem incluir modelos da EAP, modelos do plano de
gerenciamento do escopo e formulrios do controle de mudanas no escopo do projeto).
A sada esperada desta rea o plano de gerenciamento do escopo do projeto, que fornece
orientao sobre como o escopo do projeto ser definido, documentado, verificado, gerenciado e
controlado. Um plano de gerenciamento de escopo inclui um processo para preparar uma declarao
do escopo detalhada do projeto, com base na declarao do escopo preliminar do projeto; processo
que permite a criao da EAP e que determina como a EAP ser mantida e aprovada; processo que
especfica como sero obtidas a verificao e a aceitao formais das entregas do projeto; processo
para controlar como sero processadas as solicitaes de mudanas.
declarao do escopo detalhada como base para futuras decises do projeto. O desenvolvimento da
definio do escopo ocorre a partir das principais entregas, premissas e restries, que so
documentadas durante a iniciao do projeto, na declarao do escopo preliminar do projeto.
68
69
custos, monitorar e controlar o trabalho planejado contido nos componentes de nvel mais baixo da
EAP, denominados pacotes de trabalho.
As entradas necessrias a criao da EAP so ativos de processos organizacionais,
declarao do escopo do projeto, plano de gerenciamento do escopo do projeto e solicitaes de
mudana aprovadas.
Como ferramentas e tcnicas para a criao da EAP so apresentados: os modelos da
estrutura analtica do projeto (uma EAP de um projeto anterior pode ser usada como um modelo
para um novo projeto) e a decomposio.
As sadas destacadas so atualizaes, se houver, da declarao do escopo do projeto, a
estrutura analtica do projeto, dicionrio da EAP, linha de base do escopo, atualizaes, se houver,
do plano de gerenciamento do escopo do projeto, mudanas solicitadas
quantidade de recursos envolvidos no projeto, necessrios para realizar cada atividade constante no
cronograma. Envolve determinar os recursos que podem ser pessoas, equipamento e/ou material, a
quantidade destes e ainda define quando estaro disponveis.
Para o processo de estimativa de recursos de atividades o PMBOK (PMI, 2004) apresenta as
seguintes entradas: fatores ambientais da empresa, ativos de processos organizacionais (fornecem as
polticas da organizao executora relativas a pessoal e a aluguel ou compra de suprimentos e
equipamentos que so consideradas durante a estimativa de recursos da atividade), lista de
atividades (identifica as atividades do cronograma para os recursos estimados), atributos da
atividade, disponibilidade de recursos, plano de gerenciamento do projeto.
Quanto as Ferramentas e tcnicas utilizadas nas estimativas de recursos de atividades o PMI
(2004) descreve opinio especializada (vide Seo 2.2.1.2), anlise de alternativas (muitas
atividades do cronograma possuem mtodos alternativos de realizao, incluem o uso de vrios
nveis de capacidade ou habilidades de recursos, tipos ou tamanhos diferentes de mquinas,
ferramentas diferentes e decises de fazer ou comprar relativas ao recurso), dados publicados para
auxlio a estimativas (empresas publicam rotineiramente os valores de produo e os custos
70
71
72
2.4.1 CMMI
O CMMI um framework com objetivo de melhorar os processos de uma organizao de
acordo com a capacidade e maturidade destes (SEI, 2002). Alm disso, a melhoria da capacidade de
gerenciar o desenvolvimento, aquisio e manuteno de produtos e servios constituem-se em uma
atividade fim deste modelo (SEI, 2002).
O CMMI for Development (CMMI-DEV) um modelo de referncia para as atividades de
desenvolvimento e manuteno aplicadas a servios e produtos. Baseado em abordagens
comprovadas pela indstria de software, o CMMI-DEV pretende auxiliar as organizaes a terem
conhecimento sobre seu processo, permitindo que elas possam avaliar a capacidade das diferentes
reas de seus processos e, como conseqncia, identificar seu grau de maturidade. (SEI, 2006).
Desta forma, possvel que as organizaes possam estabelecer programas de melhoria que
indiquem as prioridades para as melhorias e um caminho para melhor-las. (SEI, 2002). No Brasil
at o ano de 2008 foram vinte e uma organizaes obtiveram qualificao CMMI-DEV destas onze
com nvel 2, 4 com nvel 3 e 6 nvel 5. (MCT, 2006).
Os componentes do CMMI-DEV relacionados com este projeto so (SEI, 2006):
reas de Processo: conjuntos de prticas relativos a uma determinada rea que quando
realizadas possibilitam atingir metas melhorando o contexto em que esto inseridas.
o Objetivos Especficos: so caractersticas nicas que descrevem o que se deseja de
terminada rea de processo, sendo que devem ser atingidas para assegurar na avaliao que a
rea do processo esta sendo satisfeita.
73
Prticas Especficas: so atividades que necessitam ser realizadas para que os objetivos
sejam atingidos.
Produtos de Trabalho Tpicos: componentes informativos que oferecem modelos de
sada referentes a uma prtica especfica ou genrica
Sub-prticas: descries detalhadas que facilitam a interpretao de prticas
especficas ou genricas.
o Objetivos Genricos: objetivos que aparecem em vrias reas de processo. Quando
satisfeitos sinal de que houve melhoria no planejamento e implementao daquela
determinada rea de processo.
Prticas Genricas: oferecem recursos que possibilitam a certeza de que os processos
associados a determinada rea de processo sero eficientes, repetveis e durveis.
Sub-prticas: descries detalhadas que facilitam a interpretao de prticas
especficas ou genricas.
Elaboraes de Prticas Genricas: apresentam como as informaes devem ser
aplicadas em determinada rea de processo.
Com intuito de melhor interpretar os componentes do CMMI-DEV estes so agrupados em
3 categorias: componentes requeridos que so essenciais para que uma determinada rea seja
satisfeita (os objetivos especficos e genricos); componentes esperados: descrevem as atividades
que uma organizao dever executar para atender a um componente exigido (prticas genricas e
especficas); e componentes informativos que tm como objetivo auxiliar no entendimento dos
objetivos prticos e genricos e o que deve ser realizado para que estas possam ser satisfeitas (Subprticas, produtos de trabalho tpicos, definies ampliadas de disciplinas, elaboraes de prticas
genricas, ttulos de metas e prticas, notas de metas e prticas e referncias). (SEI, 2006).
74
Legenda
75
De acordo com SEI (2006), na representao contnua pode-se optar por melhorar apenas
um processo, ou seja, usa-se nveis de capacidade para medir cada rea de processo
individualmente. Neste caso no h uma pr-definio de seqncia, sendo que so seis os nveis de
capacidade.
O Quadro 12 apresenta os nveis de maturidade e capacidade e seus respectivos nveis
almejados para a certificao pelas organizaes.
Nveis
0
Representao em Estgios
Nveis de maturidade
No h
Iniciado: processo utilizado no
definido e no h controle efetivo deste.
Gerenciado: processo definido,
planejado e executado conforme poltica
da empresa.
Definido: a organizao passa a ter
processos
bem
caracterizados,
compreendidos e adotados, descritos por
meio de normas, ferramentas e mtodos.
Gerenciado
quantitativamente:
objetivos quantitativos para qualidade e
desempenho. Tcnicas quantitativas e
estatsticas
so
utilizadas
como
ferramentas de mtrica.
Em Otimizao: melhoria continua dos
processos.
1
2
Representao Contnua
Nveis de capacidade
Incompleto: objetivos especficos do
processo no necessitam ser satisfeitos.
Executado: objetivos especficos da rea
de processo em questo so satisfeitos.
Gerenciado: processo planejado e
gerenciado
conforme
polticas
da
organizao.
Definido: processo definido e adequado
padronizaes definidas e institudas
pela organizao.
Gerenciado quantitativamente: processo
gerenciado usando estatstica ou outras
tcnicas
quantitativas.
Definem-se
objetivos quantitativos para qualidade e
desempenho.
Em otimizao: processo gerenciado
qualitativamente e estando em melhoria
contnua
76
Prtica especfica 1.1 Estimar o escopo do projeto: nesta h a definio de uma work
breakdown structure (Estrutura Analtica do Projeto - EAP). Os produtos de trabalho
que devem ser resultados desta prtica so descrio de tarefas, descrio de pacotes
de trabalho e a EAP.
Prtica especfica 1.3 Definir ciclo de vida de projeto: as fases de um ciclo de vida
de projeto devem ser definidas em consonncia com o escopo, estimativas de
77
Prtica especfica 2.4 Plano para recursos do projeto. Definem os recursos do projeto
como equipamentos, pessoas e materiais, bem como a quantidade destes para realizar
as atividades estimadas. Produtos de trabalho nesta prtica pacotes de trabalho da
EAP, dicionrio de tarefas da EAP, requisitos efetivos baseados em tamanho e
escopo de projeto, lista de equipamentos, definies e diagramas de processos, lista
de requisitos de administrao do programa.
78
Prtica genrica 2.1 Estabelecer uma poltica organizacional: esta prtica prev
estabelecer e manter uma poltica organizacional para planejamento e execuo do
processo de planejamento de projetos. Para tanto, esta deve estabelecer expectativas
organizacionais
para
estimar
os
parmetros
de
planejamento,
tornando
79
Prtica genrica 2.10 Revisar com o nvel mais alto da gerncia: rever as
atividades, status e resultados do processo de planejamento de projeto com o nvel de
gerncia e resolver problemas.
2.4.2 MPS.BR
MPS.BR v.1.2 (SOFTEX, 2007) um modelo de melhoria de software desenvolvido no
Brasil desde 2003 e que se baseia nas normas ISO/IEC 12207:1995/Amd 1:2002 e Amd
2:2004(IEEE/IEA, 1998), ISO/IEC 15504(ISO/IEC, 2005) e CMMI-DEV (SOFTEX, 2007). Este
programa tem como foco as micros, pequenas e mdias empresas que apresentam grande
dificuldades em seus processos atuais de desenvolvimento de software. Entretanto, o modelo pode
ser tambm utilizado por organizaes de outros portes e com caractersticas diferentes. (SOFTEX,
2007).
Com intuito de ser compatvel com padres e normas internacionais e que contenha
caractersticas relevantes da experincia dos modelos de melhoria de processos existentes, o
MPS.BR baseia-se em requisitos de processo j definidos que atendem aos princpios da Engenharia
de Software, bem como nas abordagens internacionais no que se refere a definio, avaliao e
melhoria de processo de software. Todos estes aspectos considerando que o foco deste programa
so as empresas brasileiras. (SOFTEX, 2007).
80
81
O MPS.BR trabalha com sete nveis de maturidade que procura combinar os processos e sua
capacidade. Estes nveis representam patamares de evoluo de processo, sendo compreendidos
como estgios de melhoria da organizao no que se refere ao processo de software. O Quadro 13
apresenta os nveis de maturidade do MPS.BR, sendo que seus processos so descritos em termos
de propsitos e resultados esperados. Cabe destacar que o progresso entre os nveis de maturidade
ocorre apenas quando todos os propsitos e os resultados esperados de determinado nvel so
alcanados.
Nvel
Maturidade
Atributos de Processo
Otimizao
Gerenciado quantitativamente
Definido
Largamente definido
Parcialmente definido
Gerenciado
Parcialmente gerenciado
AP 1.1 e AP 2.1
para o planejamento de projeto e define todo o trabalho necessrio para que se entregue
82
GPR 4. Define que at o nvel F o esforo e o custo para a execuo das tarefas e
dos produtos de trabalho so estimados com base em dados histricos ou
referncias tcnicas; a partir do nvel E o planejamento e as estimativas das
atividades do projeto so feitos baseados no repositrio de estimativas e no
conjunto de ativos de processo organizacional. Estimativas de esforo e custo so,
normalmente, baseadas nos resultados de anlises utilizando modelos e/ou dados
histricos aplicados ao tamanho, atividades e outros parmetros de planejamento. Cabe
salientar que os dados histricos incluem os dados de custo, esforo e tempo de projetos
83
84
Este tpico destinou-se ao estudo especfico das atividades do nvel G em que se encontram
o processo de Gerncia de Projetos (GPR), os processos de planejamento e monitorao de projetos.
Desta forma, so descritos os resultados esperados por este nvel referentes a atividade de estimar e
atributos de processo desejados. Os resultados esperados referentes ao processo gerenciado so
destacados para a proposta de gerenciamento da atividade de estimativa no guia desenvolvido.
85
86
Capacidade
Por este trabalho focar a rea de gerncia de projetos sero apresentadas as caractersticas do
grupo de processo MAN. 3 (Management Process Group) e do nvel 2 de capacidade desta norma.
O grupo de processo MAN. 3 tem como objetivo o gerenciamento de projetos que pretende
identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos necessrios ao
projeto para produo de produto ou servio de acordo com os requisitos e restries (ISO/IEC Std.
15504, 2003). Como resultados de processo (RP) deste grupo e relacionada a rea de planejamento
87
com o foco em estimativa tem-se: Definio do escopo do projeto e as tarefas e recursos necessrios
so dimensionados e estimados.
A norma ISO/IEC Std. 15504-5 (2003) destaca tambm Prticas Bases que devem ser
realizadas, sendo que aqui so apresentadas as que possuem referncia a estimativa de software.
Prtica Base 4: Determinar e manter estimativas para os atributos do projeto (RP 2 e 3).
Com relao aos nveis de capacidade a gerncia de projetos est associada ao nvel 2, sendo
este apresentado juntamente com seus atributos de processo (AP). No nvel 2 o processo
gerenciado considerando planejamento, monitorao e ajuste, alm de que seus produtos de trabalho
estabelecidos, controlado e mantidos. Quanto aos atributos de processos referentes ao nvel 2 ser
descrito o 2.1 referente a atividades de planejamento e ligados a estimativa.
O atributo de processo 2.1 refere-se a gerenciamento de desempenho que uma medida de
como o processo gerenciado. Tem-se como resultados deste AP:
88
Prtica genrica 2.1.1: identificao dos objetivos para a execuo do processo. Alm da
identificao de objetivo, o escopo do projeto definido restries ao projeto so
consideradas.
89
90
CMMI-DEV v. 1.2
MPS.BR v. 1.2
ISO/IEC 15504-5:2203-2006
escopo do projeto
o projeto definido;
1.2
de
de
manter
Prtica
especfica
Estabelecer
produtos
estimativas
de
trabalho
atributos de tarefas
Prtica
do
projeto
dimensionados
so
utilizando
estimativas
para
os
mtodos apropriados;
especfica
Determinar
trabalho
1.4
estimativa
de
esforo e custo
produtos
de
trabalho
so
especfica
Estabelecer
2.1
oramento
GPR
5.
oramento
Base
7:
Definir
estimativas desenvolvidas
Prtica
so estabelecidos e mantidos;
Os modelos apresentados destacam a definio de escopo como atividade inicial para no que
se refere ao processo de estimar. Alm disso, em todos tambm possvel observar a determinao
de estabelecimento de estimativas de produto de trabalho e atributos de trabalho, sugerindo o uso de
tcnicas adequadas.
Os modelos destacam a necessidade e importncia de estimar, alm do que deve ser
estimado. No entanto, no apresentam qualquer informao de quais ferramentas e tcnicas
existentes que auxiliam a realizao da atividade de estimar ou como estas devem ser aplicadas.
Pode-se perceber que estes modelos apresentam aspectos relevantes para a melhoria de processos de
software, mas no so suficientes como guias por no descreverem como tais atividades devem ser
executadas.
91
SETOR
Servios
Comrcio
Indstria
Taxa de expanso
deMPEs
28,4%
21,5%
12,9%
Participao relativa
28,1% 29,6%
56,4% 56,1%
15,4% 14,3%
Porte/Setor
Microempresas
Empresas de pequeno porte
Mdias
Grandes
Comrcio e Servios
At 9 empregados
De 10 a 49
De 50 a 99
100 ou mais
O Grfico 1 apresenta, de acordo com pesquisa do MCT (2005), o porte das empresas entre
os anos 1995 a 2004 considerando a fora de efetiva de trabalho.
Pode-se percebe pelo grfico o ndice maior de existncia de MPEs no contexto de porte das
empresas. O grfico tambm demonstra que h uma mdia na quantidade de empresas se observado
separadamente cada porte.
De acordo com dados do SEBRAE (2004) as MPEs representam 20% do PIB nacional,
considerando o nmero de empresas no pas so 99% destas, alm de possurem 56% da fora de
trabalho e cerca de 2% destas empresas no cenrio nacional realizam exportaes.
93
H uma informalidade considerada alta neste tipo de empresa sendo que em 2005 havia
10,3 milhes de micro negcios informais. Dados de pesquisa SEBRAE (2002) davam
conta de 4,9 milhes de micro e pequenas empresas formais. Acredita-se que esta
informalidade se deve a dificuldade em abrir e fechar um negcio devido a burocracia e
as taxas recorrentes disto, pois no h uma tributao adequada e diferenciada para
empresas destes portes.
Destaca-se tambm a alta Mortalidade destas empresas: so 49,4% com at dois anos de
vida; 56,4% com at trs anos de vida; e 59,9% com at quatro anos de existncia.
A baixa competitividade tambm observada nas MPEs em que faziam parte de apenas
2,4% das exportaes totais das empresas industriais em 2003.
94
Em pesquisa do PMI (2007a) foram pesquisadas 184 empresas sendo que 37% so MPEs.
Do total de empresas pesquisadas 32% so da rea de tecnologia da informao. A Tabela 3
apresenta dados da pesquisa referente a aspectos relacionados a gerncia de projetos como
planejamento, uso de metodologias e ferramentas, alm das dificuldades encontradas nesta rea.
Nos dados apresentados foram considerados aqueles relevantes para este trabalho e seus objetivos.
Tabela 3 - Dados pesquisa gerenciamento de projetos (GP)
Atividade
% Empresas
51,5%
43,5%
53,5%
39,5%
23,5%
22%
Aspectos da Metodologia de GP
Prazo
95%
Escopo
94%
Nenhum
57%
Entre 1 e 3
Softwares para GP
MS-Project (Stand Alone, sem integrao)
40%
16%
12%
93 %
EAP
66 %
75%
71%
71%
29%
95
Cabe ressaltar que mais da metade das empresas consideradas diz fazer uso de aspectos do
gerenciamento de projeto como planejamento e controle, possuem profissional certificado em PMI,
consideram na metodologia adotada prazo e escopo, porm percebe-se que ainda assim apresentam
entre seus mais freqentes problemas o atendimento ao prazo e aspectos relativos a incorrees nas
estimativas.
Neste sentido, percebe-se um contraponto uma vez que o percentual nos problemas
ocorridos com freqncia bem alto e assume-se que ao se adotar e aplicar corretamente
metodologias voltadas a gerncia de projetos a realidade deveria ser diferenciada.
No entanto, pode-se considerar que parte desta condio deve-se aos apenas 23,5% de MPEs
totais pesquisadas que adotam um modelo de maturidade em gerncia de projetos. Alm disso, de
acordo com a pesquisa (PMI, 2007) 25% das empresas no conhecem qualquer modelo de
maturidade.
Percebe-se tambm que as empresas utilizam softwares para gerenciamento de projeto e
entre as funcionalidades mais utilizadas esto as relacionadas a criao e controle de cronograma e
criao da EAP. No se encontrou entre as atividades realizadas por meio das ferramentas citadas
estimativas de projetos de software.
Em relao adoo dos modelos de melhoria de processo de software (CMMI, ISO/IEC
15504 e MPS.BR) a Tabela 4 apresenta dados obtidos na pesquisa MCT (2005), referentes a
utilizao de modelos de melhoria de processos de software a norma ISO/IEC 15504, CMMI,
MPS.BR pelas empresas de software.
Tabela 4 - Utilizao dos modelos de melhoria de processo em MPEs
Norma ISO/IEC
15504 (%)
CMMI
MPS.BR
Usa sistematicamente
0,65
2,5
2,3
Comea a usar
No usa
No conhece
Total
5,55
69,9
23,9
100
15,8
66,9
14,9
100
13,7
61,4
22,6
100
Percebe-se pelos dados apresentados na Tabela 4 que h uma fraca incidncia no uso efetivo
destes modelos pela empresas pesquisadas. Outro fator que merece destaque o percentual de
96
97
Cabe ressaltar que estas caractersticas justificam a criao do guia proposto neste trabalho,
corroborando para incentivo a prtica de realizar estimativas e adeso aos modelos de melhoria de
processo e as boas prticas.
98
para verificar a sua possvel contribuio para o desenvolvimento do guia proposto, bem como se
fez a anlise de acordo com os requisitos elencados para a realizao de um guia destes. A natureza
dos documentos apresentados contempla contedos mais abrangentes em gerncia de projetos,
inclusive metodologias geis, aplicaes com modelos de melhoria de processo e especficos como
estimativas de software.
A. Software Project Management (HUGHES & COTTERELL, 1999)
No livro Software Project Management (HUGHES & COTTERELL, 1999), os autores
apresentam em um mtodo e em linhas gerais uma introduo ao gerenciamento de projetos, uma
reviso de planejamento de projetos, a monitorao e controle de projetos e o gerenciamento de
pessoas e equipes.
Uma viso geral do planejamento de projetos apresentada, sugerindo um framework
(chamado Step Wise) com passos que devem ser realizados nesta fase. Alm disso, demonstra
tambm algumas tcnicas que podem ser utilizadas e como aplic-las. As etapas destacadas so:
selecionar o projeto, identificar objetivos e escopo de projetos, identificar infra-estrutura de projeto,
analisar as caractersticas do projeto, identificar atividades e produtos do projeto, estimar esforo
para cada atividade, identificar atividades de risco, alocar recursos, revisar o plano e por fim
executar o plano (vide figura 2).
No que se refere s estimativas dedicam um passo a estimativa de esforo e durao,
explicando o que so estas atividades. Alm disso, apresentam tcnicas de estimativa de esforo
(REQ. 02) como opinio de especialista e estimativa por analogia (vide Seo 2.2.1.1).
Apesar do roteiro apresentado, o documento no demonstra detalhadamente como realizar
tais atividades (REQ. 03) ou qualquer modelo/tcnica que possa ser usado no processo de estimar
(REQ. 02, 03).
O guia no considera as caractersticas especficas das MPEs (REQ 01, 04) e no est
alinhado a qualquer modelo de melhoria de processo de software (REQ 05) ou ao guia de
gerenciamento de projeto PMBOK (REQ 06).
100
Antes de seu incio deve ser elaborada uma anlise detalhada e precisa do que
necessrio para completar o projeto.
Uma estrutura de mudana deve ser planejada antes que o projeto seja executado, com
intuito de que ao ocorrem inevitveis pedidos de alterao seja fcil redefini-los.
101
102
103
Apresenta discusso a respeito de estimativa de esforo em que sugere trs fases: a criao
de uma lista de tarefas, a criao de dependncias entre estas e por fim determina o nmero de dias
necessrios para cada atividade considerando o nmero de horas de trabalho dirio. Para ilustrar o
sugerido, apresenta um exemplo e templates baseado em um escopo, identificando tarefas e o tempo
previsto para execuo de cada uma delas.
Cabe destacar que embora este trabalho demonstre, por meio do exemplo, como o modelo
deve ser aplicado contempla apenas estimativa de esforo (REQ 02, 03). Desta forma, no aborda
estimativas de tamanho de software e durao de desenvolvimento de software.
O material tambm no est direcionado a caractersticas das MPEs de software (REQ 01,
04), no referencia os modelos de melhoria de processo (REQ 05) ou possui alinhamento ao guia de
gerenciamento de projetos PMBOK (REQ 06).
F. Software measurement and estimation: a practical approach (LAIRD e BRENNAM, 2006)
Laird e Brennam (2006) apresentam uma abordagem prtica para medio e estimativa de
software. Em se tratando de medidas apresenta conceito e fundamentos e captulos destinados a
medidas de tamanho e complexidade, defeitos, confiabilidade de software, medidas financeira e
mtricas para gerenciamento.
Um captulo do livro dedicado a estimativa de esforo apresentando definio e discusso
sobre o tema, alm de modelos e metodologias utilizados para estimativas de software juntamente
com exemplos de aplicao (REQ 01, 02, 03, 07)
No entanto, no demonstra para quais tipos de empresas seria mais interessante cada modelo
e metodologia descrita. Tambm no relata se podem ser utilizados por organizao de qualquer
porte (REQ 01 e 04).
Esta abordagem tambm no contempla alinhamento aos modelos de melhoria de processo
de software e no est alinhado ao guia de gerenciamento de projetos PMBOK considerando o
contexto de desenvolvimento de Software (REQ 05, 06). Destaca-se tambm que o texto pressupe
maturidade no que se refere ao conhecimento na rea de gerncia de projetos.
104
105
106
107
108
est disponvel para uso sendo comercializado em empresa especializadas no estando a contento
do requisito REQ 09.
01
02
03
04
05
06
07
08
09
Guias
A
B
C
D
E
F
G
H
I
J
109
110
5 DESENVOLVIMENTO DO GUIA
Neste capitulo ser descrito o processo de desenvolvido, considerando os documentos
norteadores, assim como as pesquisas que fizeram parte de sua constituio. A estrutura do guia
ser apresentada, assim como uma explicao sobre os captulos que compem o guia de estimativa
de software. As demonstraes dos captulos 4, 5, 6, 7 e 9 so extraes do que consta no guia e o
captulo 8 apresenta um resumo das ferramentas selecionadas e destacadas no guia.
Cabe destacar que o guia estar na forma de relatrio tcnico do Programa de Mestrado em
Computao Aplicada, contido em CD e disponibilizado junto com a dissertao. Desta forma, cada
item apresentado neste captulo com relao ao guia pode ser encontrado em maior detalhamento no
referido relatrio.
5.1 DESCRIO
A dissertao contempla o desenvolvimento de um guia para micro e pequenas empresas de
software para a rea de planejamento de projetos, em especfico, estimativa de esforo e durao de
atividades, bem como tamanho. A estrutura do guia tem como referncia o PMBOK (PMI, 2004) e
est alinhada as propostas dos modelos de melhoria de qualidade CMMI-Dev (SEI, 2006), MPS.BR
v. 1.2 (SOFTEX, 2007) e ISO/IEC 15504, considerando as tcnicas de estimativas.
Cabe ressaltar, que no contexto deste trabalho um guia compreendido como um
documento estruturado que contm contedos incluindo tcnicas, templates, exemplos e
ferramentas voltados a determinado assunto que possam auxiliar na implantao de determinado
processo, neste caso, estimativa de software. Alm disso, o guia pretende a atender modelos de
melhoria de processo de software e estar em consonncia com documentos norteados da rea.
A Figura 10 ilustra como ocorreu o processo de desenvolvimento do guia de estimativa de
software proposto nesta dissertao.
Por ser o guia de gerenciamento de projeto mais utilizado na atualidade, este projeto est
baseado no modelo de planejamento de projeto, em especfico as atividades de estimativa
apresentadas no PMBOK (2004). O guia de estimativas foi implementado, apresentando uma
seqncia de passos baseado nas caractersticas das MPEs considerando qual tcnica seria mais
apropriada, e atendendo as expectativas dos modelos e da norma de qualidade e produtividade de
software. Para tanto, tornou-se necessrio a apresentao no guia de uma descrio das tcnicas de
estimativas consideradas, bem como sua adequao as MPEs de software.
As definies de relacionamento entre as MPEs de software, os modelos/tcnicas de
estimativa, o PMBOK e os mtodos de qualidade e produtividade de software foram realizadas com
base na literatura, relatrios de experincias e aplicaes de tais tcnicas e ferramentas em empresa
deste porte.
112
113
114
a apresentar contedo de embasamento para utilizao das atividades mais especificas do processo
de estimar.
No entanto, os captulos 4 a 9 possuem contedos que norteiam a aplicao do guia e por
este motivo sero apresentados em detalhes contemplando em vrios momentos cpias literais do
guia para demonstrao do que foi desenvolvido.
115
116
A atividade de gerenciamento do processo de estimar pressupe que toda esta atividade seja
gerenciada desde o planejamento ao monitorao e controle, durante todo o processo de estimar. O
intuito que se chegue ao objetivo desejado sem que problemas ocorram no decorrer do processo e
no sejam sanados e corrigidos.
As atividades consideradas ao gerenciamento do processo de estimar possuem como base o
CMMI-DEV com o objetivo genrico 2 e suas prticas genricas; o atributo de processo 2.1 do
MPS.BR e os referidos resultados esperados; e as prticas genricas do atributo de processo 2.1 da
ISO/IEC 15504. Sero consideradas as atividades de planejar, monitorar e controlar.
A atividade de PLANEJAR envolve a realizao de um planejamento do processo de
estimar, sendo crucial a definio dos objetivos pretendidos com a aplicao deste processo. O
planejamento prev um plano documentado apresentando de que forma a execuo do processo
definido deve ser realizado. Sero considerados no planejamento:
117
processo de estimar e ainda pode-se definir que tal reunio ser realizada por meio
eletrnico como email ou intranet.
A monitorao e controle devem ser realizados durante todo o processo de estimativa
objetivando realizar um acompanhamento do que foi planejado. Neste caso, cabe realizar a
observao nas atividades definidas e contidas no documento em que consta o planejamento cita-se
identificao e definio de recursos, definio de responsabilidades aos recursos selecionados,
alm de identificao de suas habilidades para realizao da tarefa de estimar, e ainda viabilizar a
comunicao durante a execuo do processo.
Alm disso, torna-se necessrio a realizao de um controle eficaz do que foi planejado e o
que est sendo executado para identificaes de desvios entre o plano e o que est sendo
desenvolvido pela equipe que participa do processo de estimativa. Havendo contradies medidas
corretivas devem ser aplicadas para que se chegue ao final do processo e o objetivo seja almejado.
No caso, de objetivos desenhados e no alcanados estes devem ser analisados e medidas
que tenham como intuito chegar ao desejado devem ser tomadas, algumas podem ser:
118
Analogia;
Opinio especializada;
PERT;
Wideband Delphi;
COCOMO II; e
Linhas de cdigo.
Por se tratar de um guia uma padronizao foi utilizada para a descrio/aplicao das
tcnicas destacadas como opo para disciplinar e orientar o usurio desta ferramenta.
Para cada um dos modelos/tcnicas apresentados destacam-se os seguintes itens: o que
referindo-se ao conceito do modelo/tcnica e suas caractersticas; parmetros estimados cujo
objeto a definio de qual(is) parmetro(s) podem ser estimados utilizando o modelo/tcnica em
questo considerando o objetivo deste estudo: tamanho, esforo e durao; utilizao em que se
descreve qual situao seria mais adequado utilizar aquele modelo/tcnica; e como utilizar item
que apresenta passo a passo como se deve aplicar o modelo/tcnica discutido.
Para ilustrar como o os modelos/tcnicas so descritos no guia, a tcnica de estimativa de
trs pontos ou PERT (Program evaluation and Review Technique) ser apresentada a seguir
conforme est no guia. Cabe destacar que se parte do pressuposto que o processo genrico para
119
120
T = (O + 4M + P)/6
Equao 24- Frmula PERT
DesvPad = (P O)/6
Equao 25 - Frmula desvio padro
i.
Quanto maior for o desvio padro obtido, significa que h um grande intervalo
entre o previsto nas estimativas Otimista e Pessimista. O que se deseja que o
resultado de DesvPad seja pequeno, pois indica que as estimativas apontadas
inicialmente estavam adequadas.
5.4 TEMPLATES
Baseado na descrio dos modelos/tcnicas descritos no guia sugere-se templates que tem
como intuito auxiliar no processo de estimativa de software e aplicao do guia. Neste sentido, para
cada modelo/tcnica individualmente sero apresentados templates mais adequados a sua aplicao.
Para a criao dos templates foram utilizados softwares aplicativos como processador de
texto e planilha eletrnica, bem como, far-se- uso de j existentes possveis de serem aplicados
junto ao guia produzido.
O template criado para a tcnica PERT apresentada anteriormente for criado em Microsoft
Excel (2007) utilizando frmulas da planilha para facilitar a realizao dos clculos que precisam
ser realizados na execuo da referida tcnica. A Figura 13 apresenta o template criado.
121
Parmetro
estimado
Atividades/Projeto
Responsvel
pela estimativa
Otimista (O)
Mais provvel
(M)
Desvio
Padro
T
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5.5 EXEMPLOS
O objetivo dos exemplos a comprovao e demonstrao de utilizao dos
modelos/tcnicas que compem o guia, bem como dos templates sugeridos. Este tpico no guia foi
criado considerando que a partir da descrio de um caso de um projeto de software a ser
desenvolvido as modelos/tcnicas so executadas de acordo com os passos descritos no captulo de
apresentao dos modelos/tcnicas e utilizando os templates do referido captulo.
Neste sentido, para criar os exemplos de aplicao dos modelos/tcnicas e templates
utilizou-se um caso fictcio elaborado pelo LQPS (LQPS, 2008).
O contexto uma pequena empresa de software com cinco anos de existncia e que possui
como produto um sistema de software customizvel para controle de emprstimos em vdeolocadora. A empresa percebeu que hoje tem srios problemas com o cumprimento dos prazos e
oramento previstos. O desafio estimar tamanho, esforo e durao, considerando a possibilidade
de cada tcnica, para um novo contrato que alm das funcionalidades bsicas j disponveis desejam
mais duas funcionalidades.
122
123
Parmetro estimado:
Durao
dias
Responsvel pela
estimativa:
Atividade/Projeto
Otimista
(O)
1
2
3
4
5
3
3
5
10
30
5
5
8
15
40
10
10
15
30
60
Parmetro estimado:
Durao
dias
Responsvel pela
estimativa:
Atividade/Projeto
Otimista
(O)
1
2
3
4
5
3
3
5
10
30
5
5
8
15
40
10
10
15
30
60
T
5,50
5,50
8,67
16,67
41,67
Passo 3 - Calcular o desvio padro atravs da frmula apresentada na equao 21. O desvio
padro utilizado para verificar o intervalo entre as estimativas (O, M e P). Deseja-se que este seja
pequeno, por indicar que as estimativas apontadas inicialmente estavam adequadas. Da mesma
forma, o clculo j consta no template apresentado e o resultado desta tarefa aparece medida que
as estimativas so digitadas (Figura 16).
124
Parmetro estimado:
Durao
dias
Responsvel pela
estimativa:
Atividade/Projeto
Otimista
(O)
1
2
3
4
5
3
3
5
10
30
5
5
8
15
40
10
10
15
30
60
Emanuela
Desvio
Padro
5,50
5,50
8,67
16,67
41,67
1,17
1,17
1,67
3,33
5,00
5.6 FERRAMENTAS
O objetivo deste tpico no guia de analisar ferramentas utilizadas para o gerenciamento de
projetos, em face das vrias atividades envolvidas nesta rea e da necessidade de armazenar dados e
informaes referentes aos diferentes projetos executados pela empresas de desenvolvimento de
software. Em especfico no que tange ao planejamento de projeto pretende-se verificar aspectos
relevantes a estimativa de esforo, durao e tamanho existentes nas ferramentas e que possam
contribuir a sua obteno.
Neste sentido, esta avaliao foi realizada considerando os modelos e tcnicas de
estimativas abordados no guia, nas caractersticas destacadas das MPEs de software, alm de
verificar as exigncias apresentadas nos modelos de melhoria de processo e no PMBOK.
Estas ferramentas foram analisadas para que sejam indicadas como tecnologia de apoio a
realizao das estimativas de esforo, durao e tamanho no guia. Assim, tornou-se necessrio
conhecer suas caractersticas e quais funcionalidades destas ferramentas podem colaborar com o
processo de estimativa desejado.
Para a anlise foram elencados requisitos com base nas caractersticas das MPEs e nas
atividades necessrias ao processo de estimar observados no guia PMBOK e nos modelos de
melhoria de processo.
REQ 01. Permitir o registro da definio de escopo do projeto: para realizao das estimativas
torna-se necessrio aos estimadores conhecerem dados do projeto.
125
REQ 02. Permite refinar escopo: o detalhamento do projeto importante para que as tarefas
possam ser estimadas. Por exemplo, por meio do uso de EAP.
REQ 03. Possuir tcnica para estimativas de tamanho: identificar se a ferramenta apresenta alguma
tcnica para esta atividade e qual seria esta e suas caractersticas.
REQ 04. Possuir tcnica para estimativas de esforo: identificar se a ferramenta apresenta alguma
tcnica para esta atividade e qual seria esta e suas caractersticas.
REQ 05. Possuir tcnica para estimativas de durao: identificar se a ferramenta apresenta alguma
tcnica para esta atividade e qual seria esta e suas caractersticas.
REQ 06. Permitir o registro das estimativas de tamanho: independente da ferramenta possuir uma
tcnica de estimativa, verificar se permite o armazenamento dos processos de estimativa
de tamanho realizados pelos estimadores.
REQ 07. Permitir o registro das estimativas de esforo: independente da ferramenta possuir uma
tcnica de estimativa, verificar se permite o armazenamento dos processos de estimativa
de esforo realizados pelos estimadores.
REQ 08. Permitir o registro das estimativas de durao: independente da ferramenta possuir uma
tcnica de estimativa, verificar se permite o armazenamento dos processos de estimativa
de durao realizados pelos estimadores.
REQ 09. Permitir a elaborao do cronograma do projeto: alm de identificar se ferramenta prov
esta atividade, verificar como faz isso, por exemplo, diagramas de rede.
REQ 010. Ser acessvel s MPEs de software: verificar se o acesso desta ferramenta possvel
financeiramente as MPEs.
REQ 011. Possuir visualizao grfica: apresentar os dados de uma forma que facilite a
visualizao e que facilite a utilizao da ferramenta.
REQ 012. Registro de dados histricos: permitir o armazenamento, a consulta, inclusive por meio
de relatrio de dados histricos referentes aos processos de estimativa de vrios projetos.
REQ 013. Aderncia ao PMBOK e/ou modelos de melhoria.
126
127
disponvel
para
download
no
site
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html.
Ferramenta Genrica
a) Microsoft Excel: uma planilha eletrnica que pode funcionar como um administrador de todos
os tipos de dados. Apresenta diversos recursos de clculos fazendo com que a maioria das
pessoas o utilize para criar planilhas de clculos nas mais diversas reas financeiras, estatsticas
e at operaes de matemtica bsica. A ferramenta no especfica para gerenciamento de
projetos ou estimativas de software, porm com esta foi possvel criar quase todos os templates
utilizados e abordados no guia, com exceo das cartas do planning poker e modelos para
criao de estrias. A verso avaliao foi a 2007.
Requisitos
Ferramentas
Microsoft Project
DotProject
JExpChannel
USC-COCOMO II
Cost Xpert
Microsoft Excel
01
02
03
04
05
06
07
08
09
10
11
128
12
13
14
Pode-se perceber de acordo com o Quadro 18 que nenhuma das ferramentas apresenta todas
as caractersticas elencadas nos requisitos que contemplam atividades relacionadas ao processo de
estimativa. De forma geral, as ferramentas voltadas ao gerenciamento de projetos no apresentam
recursos especficos referentes a estimativa, bem como, as ferramentas direcionadas a estimar no
apresentam funcionalidade que envolvam as atividades relacionadas a gerncia de projetos. J a
ferramenta genrica apresentada apresenta recursos que permitem adaptaes de forma a comportar
totalmente ou parcialmente cada um dos requisitos do guia.
Outra relao interessante de ser realizada entre as ferramentas e os modelos/tcnicas
abordados neste guia. O Quadro 19 apresenta este relacionamento para facilitar a seleo de
ferramentas pelas organizaes. Para representar a existncia de suporte ao modelo/tcnica na
ferramenta : totalmente () se a ferramenta tem a contemplao do modelo/tcnica na sua
concepo; parcialmente ( ) no caso de ser possvel realizar, mas no ter concepo do suporte ao
modelo/tcnica; No existncia de suporte aos modelos/tcnicas abordados no guia ( ).
Ferramentas
Modelos/tcnicas
Estimativa por analogia
Estimativa PERT
Opinio especializada
Linhas de cdigo
Wideband delphi
Anlise por pontos de
funo
Anlise por ponto de casos
de uso
COCOMO II
Planning poker
Tcnica do planning game
Microsoft
Project
DotProject
JExpChannel
USCCOCOMO
II
Cost
Xpert
Microsoft
Excel
129
PMBOK
Atendimento
Guia
130
131
CMMI-DEV 1.2
MPS-BR 1.2
ISO/IEC 15504-5:2006
Prtica
especfica
1.2
Estabelecer estimativas de
produtos de trabalho e
atributos de tarefas
GPR 2. As tarefas e os
produtos de trabalho do
projeto so dimensionados
utilizando
mtodos
apropriados;
Prtica
Base
4:
Determinar e manter
estimativas
para
os
atributos do projeto (RP 2
e 3).
Prtica
especfica
1.4
Determinar estimativa de
esforo e custo
Prtica
2.1
GPR 5. O oramento e o
Estabelecer o oramento e
cronograma do projeto,
incluindo
5)
base
pontos de controle, so
especfica
as
desenvolvidas
estimativas
marcos
e/ou
Atendimento
Guia
estabelecidos e mantidos;
132
133
Por meio desta anlise pode-se perceber que o guia atende a proposta de estar alinhado aos
modelos CMMI-DEV, MPS.BR e norma ISO/IEC 15504 no que se refere a atividade de estimativa
de software. As prticas relacionadas a norma e modelos citados, esto contempladas ao observar os
captulos apresentados no guia, o contedo disponvel e os resultados que se pode obter pela sua
aplicao.
134
6 AVALIAO DO GUIA
Neste captulo descreve-se o processo de avaliao do guia de estimativa de software
proposto neste trabalho. A avaliao aplicada tem por base o mtodo GQM, iniciando pelo
planejamento em que se definiu o que, como e quando a avaliao seria realizada, em seguida
houve a execuo do planejado com intuito de coletar dados, por meio de um questionrio aplicado
junto a especialistas em Engenharia de software que possuem conhecimento nas reas de gerncia
de projeto, estimativas de software e em modelos de melhoria de software. Por fim, realizou-se a
anlise dos dados identificando o alcance do objetivo definido para a avaliao.
Neste sentido, so detalhados a seguir o planejamento, a execuo e a anlise da avaliao
do guia de estimativas.
136
Objetivo
Pergunta Q01:
Pergunta Q02:
Pergunta Q03:
Pergunta Q04:
Pergunta Q05:
Pergunta Q06:
Pergunta Q07:
Pergunta Q08:
Pergunta Q09:
Pergunta Q10:
Pergunta Q11:
MEDIDAS
MQ1.1. Impresso subjetiva do
percentual de variao do esforo
com o uso do guia.
MQ2.1. Lista de atividades do
processo que no esto claras.
MQ2.2. Lista de atividades do
processo que o guia no apresenta
MQ3.1. Impresso subjetiva do
contedo de modelos/tcnicas de
estimativa apresentado no guia.
MQ4.1Lista
de
tcnicas
inadequadas
MQ4.2 Lista de tcnicas no
apresentadas e adequadas as MPEs.
MQ5.1. Lista de exemplos que no
esto a contento.
MQ6.1 Lista de templates que
devem ser revisados.
MQ7.1
Indicao
de
outras
ferramentas.
MQ8.1 Impresso subjetiva do
percentual de variao do tempo
com uso do guia comparando a no
utilizao.
MQ09.1 Quantidade de outras
fontes necessrias.
MQ09.2 Indicao de outras fontes.
MQ10.1. Percentual de no
atendimento do guia ao PMBOK.
MQ10.2 Lista de requisitos que no
so atendidos.
MQ11.1 Percentual de alinhamento
ao CMMI-DEV
MQ11.2.
Lista
de
prticas
especficas no atendidas.
MQ11.3 Percentual de alinhamento
ao MPS.BR.
MQ11.4 Lista de GPR- a sigla esta
introduzido antes? no atendidos.
MQ11.5 Percentual de alinhamento
a ISO/IEC 15504
MQ11.6 Lista de prticas base no
atendidas.
137
Com base nas perguntas da avaliao criadas para alcanar o objetivo proposto, juntamente
com as medidas indicadas, derivado o plano de coleta de dados em que se apresenta a medida
relacionada a forma como os dados referentes a esta sero coletados e quem ser responsvel por
fornecer os dados necessrios, como se pode observar no Quadro 23.
138
Medida
Como coletar?
Quem coleta?
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
MQ7.1
Indicao
ferramentas.
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
MQ10.1.
Percentual
atendimento ao guia.
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
MQ11.2.
Lista
de
especficas no atendidas.
Engenheiro de processo
Engenheiro de processo
MQ11.4 Lista
atendidos.
Engenheiro de processo
Engenheiro de processo
Engenheiro de processo
de
de
outras
de
no
prticas
GPR
no
139
Esta avaliao utilizou como tcnica de coleta de dados um questionrio aplicado junto a
profissionais no mbito do LQPS e UNIVALI, que fizeram ao menos curso e/ou prova de do nvel
introdutrio em MPS.BR e foram aprovados pela SOFTEX e apresentam diferente nveis de
experincia na rea, variando entre pouca e mdia, considerando o conhecimento em Engenharia de
Software.
Inicialmente, criou-se um questionrio (Apndice A) para identificar o perfil do pesquisado
para que ajudasse na anlise dos dados obtidos uma vez que a experincia e conhecimento dos
mesmos na rea influenciam nos dados coletados. Em seguida so apresentadas as perguntas
direcionadas a obteno das medidas desejadas e elencadas no GQM.
A interpretao dos dados foi realizada em sua maioria de forma qualitativa por meio de
anlise de contedo, em que dados obtidos em atividades individuais (questionrios e entrevistas)
so registrados, tabulados por categorias de anlise e posteriormente descritas no captulo da anlise
e descrio dos dados da pesquisa. (MINAYO, 1994). Buscou-se por meio desta anlise apresentar
resposta ao objetivo de medio que se refere ao atendimento aos requisitos elencados como
interessante de se ter em um guia deste tipo. Cada pergunta do questionrio derivada do GQM ser
analisada individualmente considerando o perfil dos respondentes.
6.2 EXECUO
A realizao desta pesquisa foi realizada com a primeira verso do guia finalizada (v. 1.1),
em que constavam todos os captulos finalizados com exceo do captulo de ferramentas em que a
Ferramenta Microsoft Excel ainda no havia sido descrita. Outro aspecto que no constava nesta
primeira verso refere-se a avaliao de conformidade do guia com o PMBOK e de alinhamento do
guia com os modelos de melhoria de processo (CMMI-DEV, MPS.BR e ISO/IEC 15504). Alm
disso, o guia no havia sido revisado por completo em toda sua estrutura e contedo, por exemplo,
na tcnica de anlise por pontos de funo outros grupos de pesquisa na rea ainda no haviam sido
apresentados.
Foram identificados, com base nas caractersticas desejadas os respondentes no mbito da
UNIVALI e LQPS e que tambm atuam profissionalmente na grande Florianpolis, sendo que a
amostra da pesquisa teve definidos seis participantes.
140
Por meio da aplicao do questionrio referente ao perfil dos pesquisados, pode-se perceber
que os entrevistados, na sua maioria, possuem formao acadmica voltada a rea do trabalho e
todos possuem ou cursam especializao em Engenharia de Software. Dos entrevistados trs atuam
na implantao ou consultoria de modelos de melhoria de software, sendo que o tempo varia entre 2
e 5 anos. Cabe destacar ainda que quatro destes possuem experincia na rea de estimativa de
software, sendo que o tempo varia de 2 a 10 anos.
A pesquisa foi realizada por meio do envio do questionrio aos participantes no incio do
ms de janeiro eletronicamente e sendo devolvido por estes da mesma forma no incio do ms de
fevereiro (06/01/2009 a 10/02/2009). Os respondentes receberam alm do questionrio, o guia de
estimativa de software e por meio da leitura deste foi possvel aos participantes informar os dados
solicitados para responder ao objetivo desta pesquisa.
Ressalta-se que todas as questes objetivas foram respondidas pelos participantes da
pesquisa. No que se refere aos questionamentos subjetivos percebeu-se que todos responderam ao
menos a questes com explicaes quando a resposta no era o percentual total ou a opo
TOTALMENTE. Apenas 1 dos participantes fez apenas 1 explicao, acredita-se por ser o menos
experiente dos respondentes da pesquisa. As respostas corroboraram para que fosse possvel obter
dados relevantes para o guia. As questes em que se solicitou indicao por parte do respondente
deixou a desejar apresentando poucas sugestes ao guia.
Durante o ms de aplicao foram trocadas informaes com os respondentes para saber se a
pesquisa transcorria de maneira adequada e nenhum dos participantes fez qualquer questionamento
ou apresentou dificuldades na realizao da avaliao. O questionrio de avaliao foi enviado a
seis participantes, sendo que apenas um deixou de respond-lo.
Embora no tenha sido possvel aplicar em uma empresa o guia e no se tenha obtido um
nmero maior de respondentes, foi possvel avaliar que os resultados iniciais obtidos pela avaliao
apresentam indcios da possibilidade da aplicao do guia em empresas com pretenses de
implantar modelos de melhoria de software.
141
Pergunta
Q01:
Por ser uma pergunta subjetiva houve uma variao considervel entre os percentuais
sugeridos pelos participantes conforme Grfico 3.
Cabe ressaltar que a variao de 51% a 75% foi considerada pelos pesquisados com
experincia menor na rea e que no atuam em implantao e/ou consultoria de modelos de
melhoria de software, apesar de conhecerem a atividade. Neste sentido, considera-se a variao
entre 01 a 50 % que contempla a opinio dos respondentes que possuem experincia como
consultores/implementadores de modelos de melhoria de software. Cabe destacar que um dos
respondentes escolheu a opo que afirma estar entre 1 e 25% o esforo necessrio para aplicar o
guia, sendo este considerado um resultado positivo, principalmente pelo respondente ter experincia
considervel na rea de estimativa de software e implantao de modelos de melhoria de processo
142
de software. Embora sejam opinies subjetivas torna-se relevante para que se tenha noo da
facilidade de aplicao do guia quanto a implantao de um processo de estimativa.
Percebe-se que pela subjetividade da questo os respondentes procuram deixar claro nas
justificativas das respostas a relevncia do guia. Na questo 01 salientam a contribuio do guia
pelos contedos disponveis voltados ao processo de estimar e destacam o mrito do guia por
permitir identificar os modelos mais adequados a sua necessidade.
Outra contribuio apresentada foi a necessidade da disponibilizao do guia em formato de
eletrnico, especificamente em pginas WEB. Na opinio do entrevistado facilitaria a sua
implantao, pela melhor possibilidade de navegao entre teoria, templates e exemplos.
Destaque tambm para a dependncia da experincia do projetista, que influencia na
implantao de um processo de estimar, impondo certa dificuldade na aplicao de um Guia, se
no houver a presena de um profissional experiente.
Considerando as explicaes e justificativas para os percentuais apontados, foi possvel
perceber que no houve resistncia ou contrariedade utilizao do guia. Pelo contrrio, as opinies
apontaram vantagens considerveis na sua utilizao, porm se desejou evidenciar que este
percentual de esforo depende da equipe de trabalho envolvida no processo.
Pergunta Q02:
143
Pode-se perceber que embora considerem parcial o entendimento por um leigo do processo
de estimar as justificativas apontadas demonstram que no tem relao com o contedo apresentado
no guia sobre o processo de estimar sugerido. Alm disso, no houve descrio de atividades ou
contedos no claros no guia ou falta de qualquer atividade no processo de estimar descrito no guia.
Pergunta Q03:
Pergunta Q04:
MQ4.1Lista
inadequadas
de
tcnicas
144
maioria dos modelos e tcnicas exigem registro histrico apurado. Isto requer um nvel de
maturidade mais alto das organizaes que no encontrado em MPEs de software no incio de um
programa de melhoria. Citou-se tambm que a adequao dos modelos dependeria do projeto que
estivesse sendo realizado.
Como tcnicas consideradas no adequadas s MPEs foi citado o modelo COCOMO II e
como tcnicas no apresentadas sugeriu-se comentar sobre a existncia de outros grupos que
estudam a anlise por ponto de funo como o Nesma.
Com relao aos modelos baseados em especialista cabe destacar que uma empresa que
inicia um processo de implantao de um modelo de melhoria, via de regra, necessita de
especialistas em sua equipe de trabalho.
Embora os modelos e tcnicas mais conhecidos e utilizados sejam apontados no guia e
dependam de alguns aspectos para serem aplicados se a empresa deseja implantar um processo de
estimativa de software, ser necessrio optar por uma das tcnicas apresentadas, visto que so as
mais aplicadas.
Pergunta Q05:
Com relao a pergunta de nmero 5, na obteno dos dados dos questionrios respondidos
percebeu-se que 4 dos participantes respondeu que os exemplos estavam TOTALMENTE a
contento. Apenas 1 dos respondentes considerou que os exemplos estavam apenas atendendo
PARCIALMENTE o seu objetivo.
Como sugesto foi indicado a justificativa de valores que fazem parte das tcnicas e
modelos e tambm um maior detalhamento na execuo destes.
Pelos nmeros obtidos pode-se perceber que a maioria dos respondentes considerou
adequados os exemplos apresentados no guia. Cabe destacar, que dentre os participantes com esta
opinio h uma variao na experincia o que relevante, pois tanto os mais experientes quanto
menos experientes puderam compreender o que foi apresentado. No entanto, as indicaes
apresentadas sobre melhorias sero consideradas.
145
Pergunta Q06:
Pergunta Q07:
MQ7.1
Indicao
ferramentas.
de
outras
[Totalmente]/[Parcialmente]/[No]
Para a questo de nmero 7 na coleta de dados pode-se identificar que 3 dos participantes
respondeu TOTALMENTE e 2 PARCIALMENTE e estes ltimos apresentaram justificativa
resposta escolhida.
146
Uma das justificativas apresentadas foi que o respondente conhecia quase todas as
ferramentas apresentadas e que embora auxiliem no processo torna-se necessrio que os usurios
conheam as tcnicas e tambm como aplic-las de forma consistente.
Alm disso, outra justificativa por um dos respondentes com mais experincia relata que
pelo que foi apresentado no guia por meio das avaliaes e tambm pela atividade prtica deste
participante na rea, percebe-se que o suporte das ferramentas em geral ao processo de estimativa
muito fraco.
Cabe destacar que conforme anlise apresentada sobre as ferramentas (seo 6.6) estas no
suportariam todo o processo de estimativa, no texto da seo 6.6 afirma-se nenhuma das
ferramentas apresenta todas as caractersticas elencadas nos requisitos que contemplam atividades
relacionadas ao processo de estimativa.
Pergunta Q08:
147
mais adequada(s) para cada caso, alem de que possvel a utilizao do guia como instrumento de
estudo e levantamento bibliogrfico.
Na opinio de outro participante pelos exemplos prticos e tambm por meio da leitura dos
templates, a tendncia a reduo do esforo necessrio ao aprendizado dos modelos e tcnicas, j
que no caso da no existncia do guia deveria ser empregado em pesquisas na internet, ou na
elaborao de material semelhante na organizao.
Pode-se identificar que subjetivamente a tendncia que a utilizao do guia possa diminuir
o tempo de processo de 50 a 100%, pois estas foram opinies de participantes com mais experincia
na implantao/consultoria de modelos de melhoria de software. No houve argumentos vindos
daqueles que consideraram um percentual mais baixo (26% a 50%).
Pergunta Q09:
MQ09.1 Quantidade
fontes necessrias.
de
outras
148
Pergunta Q10:
A pergunta Q10 tinha como objeto identificar se o guia est baseado no PMBOK, no que se
refere ao processo de estimativa, a idia no era que os engenheiros de processo formalmente
verificassem o embasamento ou no, mas que fosse possvel obter mais sugestes de melhoria para
o guia. A variao apresentada no grfico 10 deve-se a subjetividade da questo.
Pelo grfico de nmero quatro pode-se perceber que a base do guia no PBMOK varia de 50
a 100%. Interessante ressaltar que as duas opinies referentes a variao de 76 a 100% refere-se a
respondentes com maior experincia do que os respondentes de 51 a 75%.
Os participantes argumentaram a respeito desta questo apontando que cada processo no
PMBOK seria em iniciao, planejamento, execuo, controle e finalizao e este
desenvolvimento no fica claro no guia.
Outro comentrio destaca que o guia atende ao estabelecido na referncia PMBOK pela base
conceitual no texto. O PMBOK um guia genrico e aborda estimativa de um nvel mais
abrangente, j o guia de estimativas proposto est mais concentrado em software devido as suas
caractersticas especficas.
A proposta de basear o guia no PMBOK estava considerando apenas o processo de estimar
proposto no guia de referncia de gerncia de projetos referenciado. Neste sentido, descreveu-se de
que forma o PMBOK trata as estimativas contempladas e outros processos envolvidos como o
149
escopo. No prprio processo de estimativa sugerido pelo guia de estimativa utiliza-se a estrutura do
PMBOK, por ser este base para seu desenvolvimento.
Pergunta Q11:
prticas
150
Pode-se perceber que cada participante na sua avaliao selecionou o mesmo intervalo
percentual ao alinhamento para cada um dos modelos de melhoria de processo foco do guia de
estimativa de software proposto.
No entanto, foram realizados comentrios sobre o alinhamento do guia ao modelo CMMIDEV. Foi citado que para nveis de maturidade mais elevados torna-se necessria a utilizao de
estimativas estatsticas, pois as que no se utilizam de estatsticas no seriam totalmente aceitas
em uma avaliao oficial. O mesmo sendo considerado para os outros dois modelos MPS.BR e
ISO/IEC 15504-5.
De acordo com os dados coletados, pode-se verificar que de maneira geral h o alinhamento
com os modelos. Com relao ao comentado a respeito dos modelos referente a modelos/tcnicas
no estatsticas, no se torna um fator de no alinhamento j que h no guia modelos paramtricos e
modelos/tcnicas baseados em opinies especializadas e dados histricos.
Este tpico teve como intuito apresentar os resultados da pesquisa realizada para avaliao
do guia de estimativa de software a partir dos requisitos elencados para o guia no captulo 5 deste
trabalho. Com base neste foi criado um planejamento por meio do GQM para medio do guia de
software.
Alm disso, foi possvel tambm avaliar que o contedo constante no guia suficiente as
necessidades da implantao de um processo de estimativa de software. A mesma constatao podese ter para a estrutura do guia quanto a modelos e tcnicas descritos, exemplos e templates e ainda
as ferramentas apresentadas.
151
152
Outro fator que merece ser comentado como ameaa a viabilidade est no que concerne
ao perfil dos pesquisados. Como se pode observar nem todos possuam o mesmo tempo e
grau de experincia, alm de alguns no terem experincia na implantao de modelos de
melhoria de software (embora tenham prova nvel introdutrio do MPS.BR), o que pode
ter apresentado dados no to precisos, principalmente pela falta de experincia.
Como a pesquisa foi realizada com uma verso inicial do guia houve o risco na falta de
explicao de uma das ferramentas prejudicar na avaliao deste item. No entanto, podese perceber que os comentrios realizados no seriam diferentes, at porque os templates
do guia na sua maioria foram criados com a ferramenta em questo. De qualquer forma
deve-se considerar que algum dos respondentes poderia ter uma viso diferente no que se
refere s ferramentas. Outro ponto foi a no reviso por completo do guia o que incidiu
em alguns comentrios dos quais j se tinha conhecimento.
O fato de todos os pesquisados serem da mesma instituio pode ameaar o processo de
avaliao caso haja uma relao com prtica conhecida e aplicada pelos mesmos, alm do
fator de ser possvel o contato entre estes na realizao da avaliao. Pode-se considerar
tambm a relao dos participantes com a pesquisadora, devido ao contato no mbito da
instituio que pertencem, o que poderia mascarar dados, principalmente negativos sobre
o guia. Apesar de que se pode observar a variao entre resultados positivos e negativos
na avaliao.
Independente das ameaas apresentadas pesquisa em questo acredita-se que pelo objetivo
desejado com esta que seria avaliar o guia considerando os requisitos elencados este foi alcanado
de acordo com engenheiros de processo participantes da pesquisa. Alm disso, verificou-se a
viabilidade de sua aplicao em uma MPE e conseqentemente sua avaliao possibilitando alcance
de resultados com dados reais.
A avaliao possibilitou tambm a identificao de pontos que podem ser melhorados e
aperfeioados na verso do guia colocada disposio dos respondentes e participantes da pesquisa
realizada.
153
7 CONCLUSES
Neste trabalho, em atendimento ao seu objetivo principal, desenvolveu-se um guia de
estimativas de software contemplando os parmetros de tamanho, esforo e durao, com foco nas
MPEs. Alm disso, houve a preocupao em apresentar seu embasamento com guia PMBOK e
alinhamento aos modelos de melhoria de processo CMMI-DEV, MPS.BR e ISO/IEC 15504-5.
Em especial o guia se destina a MPEs de software (empresas com at 49 funcionrios) e por
este motivo caracterizou-se este tipo de empresa no contexto de desenvolvimento de software.
Percebeu-se que poucas adotam normas ou modelos de melhoria da qualidade, realizam pouco a
atividade de estimar e apresentam como um dos maiores problemas estimativas inadequadas.
O guia PMBOK, adotado como base para a criao do guia de estimativa, possibilitou o
desenvolvimento de um processo genrico para estimativa de software, considerando tanto a
estrutura do PMBOK quanto seus desgnios sobre a atividade de estimar. Buscou-se tambm a
definio dos parmetros de estimativas de recursos de atividades (esforo) e durao de atividades,
para o detalhamento no guia de estimativas desenvolvido.
No desenvolvimento do guia considerou-se os quesitos desejveis pelos modelos de
melhoria, e ao mesmo tempo o que estes no especificam como a definio da forma genrica do
processo de estimar e o detalhamento desta atividade e de modelos/tcnicas para realizar
estimativas.
Os principais modelos/tcnicas de estimativas foram selecionados e apresentados no guia
detalhadamente incluindo o conceito, quais parmetros estima (tamanho, esforo, durao), quando
devem ser utilizados e a descrio passo a passo de sua aplicao, alm de templates e os exemplos.
Para a consecuo deste trabalho foi necessrio tambm a anlise de 6 ferramentas, sendo 3
de gerncia de projetos, 2 especficas de estimativa e 1 genrica, em que se pode observar a falta
das funcionalidades para todos os requisitos desejveis desde aspectos de gerncia de projetos, aos
modelos e tcnicas de estimativas, sendo necessria utilizao destas ferramentas em conjunto.
Outro aspecto desejado a este trabalho o estabelecimento de diretrizes para nortear a
seleo do modelo/tcnica mais prximo da realidade da MPE que utilizar o guia. Acredita-se que
este foi iniciado com o item Utilizao no captulo 5 do guia (explicao de modelos/tcnicas) em
que so apresentadas algumas caractersticas necessrias empresa que deseja aplic-los.
Entretanto, torna-se necessrio aplicar o guia em uma empresa para efetivar estas consideraes e
instituir novas diretrizes para a seleo dos modelos e tcnicas disponveis.
O guia est em desenvolvimento contnuo e inicialmente contempla sua estrutura em
captulos constando a teoria relacionada a gerenciamento de projeto, ao processo de estimativa e
modelos e tcnicas de estimativas de software. Desenvolveu-se uma forma genrica de estimar
apresentando entradas, atividades e sadas para o processo de estimar. Alm disso, o guia ainda
contempla o passo a passo para executar os modelos/tcnicas; templates e exemplos de aplicao
para cada modelo/tcnica; ferramentas voltadas ao gerenciamento de projetos e estimativas de
software; e por fim o guia apresentar uma anlise de conformidade com os modelos de melhoria de
processo de software.
A avaliao do guia foi realizada com seis profissionais que possuem ao menos curso e/ou
prova do nvel introdutrio em MPS.BR e com especialidades em engenharia de software (apenas 1
no respondeu ao questionrio). Pretendeu-se com a pesquisa o atendimento dos requisitos
elencados como bsicos ao guia, cita-se aplicao do guia em MPEs, detalhamento dos
modelos/tcnicas selecionados, alinhamento com os modelos de melhoria de processo de software
(CMMI-DEV, MPS.BR, ISO/15504-5) e embasamento ao PMBOK. Os dados obtidos por meio da
avaliao num primeiro momento do indcios de que o objetivo do guia que seria sua utilizao
como apoio a implantao de um processo de estimativa em uma MPE de software, considerando
facilidade e eficincia, alm de servir como contedo orientador na implementao de modelos de
melhoria de processo de desenvolvimento de software.
Com relao aos requisitos elencados como desejveis para o guia pode-se dizer que todos
foram obtidos parcialmente. Os modelos e tcnicas sugeridos so descritos e sua aplicao
detalhada, sendo possvel a aplicao destes MPEs de software, contudo no houve aplicao deste
para que se possa confirmar a possibilidade. Na descrio de cada modelo/tcnica no guia so
apresentados critrios que definem que tipo de organizao poderia adotar tal tcnica, porm so
sugestes iniciais que devem ser desenvolvidas para que sejam mais especficas. O guia est
alinhado aos modelos de melhoria de processo de software (CMMI-DEV, MPS.BR, ISO/IEC
15504) no que se refere a estimativas (quadro 21). O desenvolvimento do guia se embasou no
PMBOK no contexto de estimativa (quadro 20). Os templates, exemplos e ferramentas referentes ao
155
processo de estimativas so apresentados no guia mas sua eficincia podero ser comprovadas por
meio de sua avaliao. Por fim o guia est escrito em Portugus e est livre para utilizao.
156
REFERNCIAS BIBLIOGRFICAS
ALBRECHT, Allan J. Function Points as a Measure of Productivity. Actas do 53rd meeting of
GUIDE International Corp. Dallas, 1981.
ALBRECHT, Allan J; GAFFNEY JR, John E. Software Function, source line of code, and
development effort prediction: a software science validation. IEEE Transactions on Software
Engineering. SE-9, 6, 639-648; 1983.
BASILI, Victor R.; CALDIERA G., ROMBACH H, D. Goal Question Metric Paradigm.
Encyclopedia of Software Engineering. vol.2. John Wiley, 1994.
BENTE ANDA, et al. Estimating Software Development Effort based on Use Cases: Experiences
from Industry. Fourth International Conference on the UML, 2001 Springer. 2001.
BFPUG Brazilian Function Point Users Group. Perguntas e Dvidas Freqentes. Disponvel
em < http://www.bfpug.com.br/>. Acessado em 01/07/2008.
BOEHM, Barry. Software Engineering Economics. Prentice-Hall, 1981.
BOEHM, Barry; MADACHY, Ray; SELBY, Richard. The COCOMO 2.0 software cost estimation
model. 1995. Disponvel em: http://sunset.usc.edu/research/COCOMOII/. Acessado em:
24/11/2007.
BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. The Unified Modeling Language for
Object-Oriented Development. Documentation Set Version 0.91Addendum UML Update. Rational
Software Corporation. 1996.
CENTER for Software Engineering, USC. Cocomo II Model Definition Manual. 2004.
Disponvel em: http://sunset.usc.edu/research/COCOMOII. Acessado em: 01/10/2008.
CHARETTE , Robert N. Why Software Fails. 2005. Disponvel em:
http://www.spectrum.ieee.org/sep05/1685/2. Acessado em 19/10/2007.
COHN, Mike. Agile Estimating and Planning. 2006.
COHN, Mike. Planning Poker in Detail. 2005. Disponvel em:
http://www.planningpoker.com/detail.html. acessado em 10/07/2008.
COSMIC (Common Software Measurement International Consortium). The COSMIC Functional
Size Measurement Method Version 3.0: - Method Overview. 2007. Disponvel em:
http://www.cosmicon.com/. Acessado em 10/02/2009.
DEMARCO, Tom. Controle de projetos de software: gerenciamento, avaliao, estimativa. Rio
de Janeiro: Campus, 1991.
DAMODARAM, Mel. Estimation using use case points. Computer Science Program, Universt of
Houston-Victory. 2003.
DRUCKER, Peter F. As novas realidades. So Paulo: Pioneira, 1989.
FENTON, Norma E.; PFLEEGER, Shari L. Software Metrics: a rigorous and practical approach.
Boston: PWS Publishing Company, 1997.
GIL, Antnio Carlos. Mtodos e tcnicas de pesquisa social. 4 ed. 207 p ISBN 85 224 1041 0,
(broch.),1994.
GRENNING, James W. Planning Poker or How to avoid analysis paralysis while release
planning. 2002. Disponvel em: https://segueuserfiles.middlebury.edu/xp/PlanningPoker-v1.pdf.
Acessado em 10/07/2008.
HALL, Earl , JOHNSON, Juliane. Integrated Project Management. Prentice Hall, 2002.
HARMAN, Mark. Project Estimation: How long is this going to take? EXE Magazine. 1998.
Disponvel em: http://www.dcs.kcl.ac.uk/staff/mark/exe11.html. Acessado em 26/10/2007.
HUGHES, Bob; COTTERELL, Mike. Software Project Management. 2 ed. New York: McGrawHill, 1999.
HUGHES, Bob; COTTERELL, Mike. Software Project Management. 4 ed. New York: McGrawHill, 2006.
IBGE Instituto Brasileiro de Geografia e Estatstica. As micro e pequenas empresas comerciais
e de servios no Brasil. Rio de Janeiro : IBGE, 2003.
IFPUG - International Function Point Users Group. Function Point Counting Practices Manual.
Release 4.1.1 Westerville: IFPUG, 2000.
IEEE/IEA. ISO/IEC 12207 standard for Information Technology: software life cycle processes.
1998.
ISO/IEC Std. 15504: Information Technology Process Assessment, Part 1 to Part 5. 2005.
International Organization for Standardization, 2003-2006.
JALOTE, Pankaj. Software project management in practice. Boston: Pearson Education, 2002.
JOHNSON, D.L.; BRODMAN, J.G. Tailoring the CMM for Small Businesses, Small
Organizations, and Small Projects. IEEE CS Press. 1997. Disponvel em
http://www2.umassd.edu/swpi/McGill/spn_no8.pdf. Acessado em 19/10/2007.
KANER, Gustav. Resource estimation for objectory projects. Objective systems SF AB. 1993.
KASSE, T. Practical Insight into the CMMI. Ed. Artech House. Massachussets, 2004.
KULPA, Margaret K.; JOHNSON, Kent A. Interpreting the CMMI: A Process Improvement
Approach. Auerbach Publications, 2003.
LAIRD, Linda M., BRENNAM, M. Carol. Software Measurement and Estimation - A. Practical
Approach. New York: John Wiley & Sons, 2006.
LQPS. Caso exemplo VENDESOFT. Working Paper, Laboratrio de Qualidade e Produtividade
de Software, UNIVALI, So Jose, 2008.
MARCONI, Maria de Andrade; LAKATOS, Eva Maria. Tcnicas de pesquisa: planejamento e
execuo de pesquisas, amostragens e tcnicas de pesquisas, elaborao, anlise e interpretao de
dados. So Paulo: Atlas, 1999.
MCCONNELL, Steve. Software estimation: demystifying the black art. Washington: Microsoft
Press, 2006.
MCT - Ministrio da Cincia e Tecnologia. Secretaria de Poltica de Informtica. Qualificao
CMM e CMMI no Brasil. 2006
MCT Ministrio de Cincia e Tecnologia (Brasil). Pesquisa sobre Qualidade e Produtividade
no Setor de Software. 2005. Disponvel em: http://www.mct.gov.br.
158
. 1 0 0 2 , g ni n r a e L n o s m o h T a ri e n oi P : ol u a P o S . s e s et
9
e seatressid ,saifargonom ,CCT ,IGT ,sasiuqsep ed sotejorp :9 .ed ziuL oivliS ,ARIEVILO
9
9
PARTHASARATHY, M. A. Practical Software Estimation: Function Point Methods for
Insourced and Outsourced Projects. Inforsys Press. 2007
159
160
APNDICES
Data:
Objetivo:
Avaliar o guia de estimativa de software em relao ao atendimento de requisitos estabelecidos
sob o ponto de vista de engenheiros de processo experientes no contexto de programas de
melhoria de processos de software em MPEs (Micro e pequenas empresas).
Esta pesquisa est sendo feito como parte da dissertao de mestrado Um guia para estimativas
de projetos de software em micro e pequenas empresas, do MCA (Mestrado em Computao
Aplicada) da UNIVALI.
Instrues:
O questionrio contempla questes com respostas fechadas, porm oportunizando a realizao de
comentrio em casos em que no h atendimento por completo de determinado questionamento.
Ressalta-se que tais consideraes so de grande valia para a melhoria continua do guia.
Perfil de avaliador:
As questes que sero apresentadas a seguir esto fora do escopo de avaliao do guia, porm
por estarem provendo uma identificao do perfil dos avaliadores estar auxiliando na
apresentao da avaliao e como contextualizao desta.
Qual? ________________________________
Sim
Outra: ____________________
Sistemas de Informao
Sim
Pergunta 01: Qual sua impresso subjetiva sobre o percentual de esforo necessrio para que o guia, em
sua forma atual, seja aplicado em uma MPE de software?
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Pergunta 02: Voc acredita que no contexto de uma MPE, como Engenheiro de processo, se necessitar
aplicar o guia utilizando-o como fonte para implantar um processo de estimar junto a colaboradores leigos,
estes compreenderiam o referido processo especificamente na fase de planejamento?
Totalmente
Parcialmente
No
Pergunta 03: Voc como Engenheiro de processo, acredita que o contedo referente aos modelos/tcnicas
de estimativas de software suficiente para a compreenso de um leigo?
Totalmente
Parcialmente
No
Pergunta 04: Voc considera que todos modelos/tcnicas de estimativas apresentados no guia so
adequados a MPEs de software?
Totalmente
Parcialmente
No
Pergunta 05: Em sua opinio, os exemplos de aplicao dos modelos/tcnicas apresentados no guia ajudam
na compreenso e utilizao destes modelos/tcnicas?
Totalmente
Parcialmente
No
163
Pergunta 06: Em sua opinio, os templates sugeridos no guia esto coerentes com os modelos/tcnicas
apresentados?
Totalmente
Parcialmente
No
Pergunta 07: Voc percebe que as ferramentas indicadas no guia podem indicar uma forma de suporte o
do processo de estimar?
Totalmente
Parcialmente
No
Parcialmente
No
Em qual percentual:
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Pergunta 09: Quantas fontes alm do guia voc acredita serem necessrias para estabelecimento de um
processo de estimar, considerando o alinhamento os modelos de melhoria de processo (CMMI-DEV,
MPS.BR, ISO/IEC 15504)? ________
Explique sua opinio:
Pergunta 10: Considerando o processo de estimar e suas atividades qual o percentual do guia que se baseia
no PMBOK.
nenhum
1% - 25%
Explique sua opinio:
26% - 50%
51% - 75%
164
76% - 100%
Pergunta 11: Em sua opinio qual o percentual de alinhamento ao CMMI-DEV, considerando o processo de
estimar e suas atividades contempladas neste modelo de melhoria de processo?
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Pergunta 12: Em sua opinio qual o percentual de alinhamento ao MPS.BR, considerando o processo de
estimar e suas atividades contempladas neste modelo de melhoria de processo?
nenhum
1% - 25%
26% - 50%
51% - 75%
76% - 100%
Pergunta 13: Em sua opinio qual o percentual de alinhamento ao ISO /IEC 15504, considerando o processo
de estimar e suas atividades contempladas neste modelo de melhoria de processo?
nenhum
1% - 25%
26% - 50%
51% - 75%
165
76% - 100%