Beruflich Dokumente
Kultur Dokumente
FORTALEZA - CEAR
2010
TARCIANE DE CASTRO ANDRADE
FORTALEZA - CEAR
2010
A533p Andrade, Tarciane de Castro
ProMePE Processo de Medio Simplificado
baseado em Padres para Micro e Pequenas Empresas /
Tarciane de Castro Andrade. - Fortaleza, 2010.
217p. ; il.
Orientador: Prof. Dr. Jerffeson Teixeira de Souza.
Dissertao (Mestrado Acadmico em Cincia da
Computao) Universidade Estadual do Cear;
Centro de Cincias e Tecnologia.
1. Processo de Medio 2. Estimativa 3. Micro e
Pequena Empresa. I. Universidade Estadual do Cear,
Centro de Cincias e Tecnologia.
TARCIANE DE CASTRO ANDRADE CDD: 001.6
PRoMePE: PROCESSO DE MEDIO SIMPLIFICADO BASEADO EM
PADRES PARA MICRO E PEQUENAS EMPRESAS
Aprovada em 11/03/2010.
BANCA EXAMINADORA
________________________________________________
Prof. Dr. Jerffeson Teixeira de Souza (Orientador)
Universidade Estadual do Cear UECE
________________________________________________
Profa. Dr. Mariela Ins Corts
Universidade Estadual do Cear UECE
________________________________________________
Prof. Dr. Srgio Castelo Branco Soares
Universidade Federal de Pernambuco UFPE
Aos meus pais Jesus e Andrade, aos meus irmos
Rossana e Cssio e ao meu marido Rodrigo
AGRADECIMENTOS
Antes de tudo agradeo a Deus por me prover sade, pacincia, fora e todas as
condies para que eu chegasse at aqui, em especial, por me permitir a finalizao
deste trabalho.
Gostaria de agradecer tambm a meu marido, por estar sempre ao meu lado,
principalmente nos momentos de maior dificuldade, sempre me motivando e me
ajudando, pela pacincia nos momentos estressantes pelos quais passamos.
Agradeo minha famlia pela compreenso e apoio, em especial aos meus pais,
por tudo que fizeram por mim para que eu pudesse ser quem eu sou. Agradeo tambm
a meus irmos, Rossana e Cssio, pela ajuda, motivao e inspirao que sempre me
proporcionaram. No poderia deixar de agradecer aos meus queridos sobrinhos Sofia e
Joo que me deram inmeros momentos de alegria.
Eclesistico, 1:1
RESUMO
Para produzir software de forma competitiva preciso focar na qualidade. Para isto,
dados quantitativos que descrevam a realidade dos produtos e do processo precisam ser
obtidos e devidamente analisados atravs de um processo de medio. A realizao das
estimativas de software est inserida como um primeiro passo no processo de medio.
Com a estimativa pode-se confrontar o planejado com o realizado e formar base
histrica para os prximos projetos. A maioria das Micro e Pequenas Empresas de
Software (MPES) no trabalham com estimativas ou processo de medio devido
principalmente limitao de recursos e imaturidade nos processos. Nesse contexto o
presente trabalho prope um processo de medio simplificado para MPES, baseado em
padres, para auxiliar no controle de seus processos e produtos e, assim, produzir
software de forma controlada, com maior qualidade e tornando-as mais competitivas.
1 INTRODUO................................................................................................................ 18
1 INTRODUO
estimativas, entre outros. A partir dos dados estimados possvel controlar o realizado,
comparar e manter as medies em uma base histrica e servir de insumo em futuros
projetos.
Ao elaborar uma estimativa para o desenvolvimento de um projeto de software
desejvel que haja um conhecimento sobre tcnicas de estimativas, uma viso global do
escopo do projeto a ser gerenciado e um histrico de estimativas de outros projetos
semelhantes o que capacita o gerente a quantificar, administrar e planejar mais
efetivamente o projeto a ser produzido. Planejar o projeto somente baseando-se no
feeling ou em experincias anteriores gera, na maioria das vezes, estouro de prazos e
elevado custo de desenvolvimento.
Dessa maneira, a medio de software auxilia no monitoramento do processo de
desenvolvimento do software, desde a estimativa at a medio do realizado,
proporcionando uma avaliao contnua desse processo e possibilitando alteraes caso
seja identificado algum desvio (ROCHA; MALDONARO; WEBER, 2001). Atravs da
medio, o processo de produo de software pode ser monitorado, proporcionando
uma avaliao constante do processo e dos produtos e a possibilidade de ajustes em
funo de tendncias detectadas.
Existem muitos trabalhos importantes na rea de estimativa (ALBRECHT,
1979) (SYMONS, 1991) (KARNER, 1993) (IFPUG, 1999) (BOEHM, 2000) e na rea
de medio que auxiliam na definio e implantao de medidas e de um processo de
medio (SEI, 2006) (SOFTEX, 2009a) (BASILE; CALDIERA; ROMBACH, 1994)
(DOD, 2003). Um deles, o modelo de processo de medio, Practical Software and
Systems Measurement (PSM) (DOD, 2003), um modelo internacionalmente conhecido
e tem como objetivo guiar a definio de processos de medio. O PSM serviu de base
para a construo de um padro internacional de medio, ISO/IEC 15939 (ISO/IEC
15939, 2007), e para definio da rea de processo de medio do CMMI (SEI, 2006).
O PSM e demais modelos e tcnicas de medio foram desenvolvidos na forma de
processos genricos, para atender s mais diversas organizaes.
As Micro e Pequenas Empresas de Software (MPES), em especial, tem sentido
dificuldade em utilizar essas abordagens (ANACLETO; WANGENHEIM; HAMMES,
2002) (GAVA et al., 2006) (LEY; GARCIA; PIATTINI, 2008). Como as MPES
representam cerca de 77% das empresas de software nacional (MCT, 2005) e diante da
relevncia de um processo de medio na melhoria do processo e do produto, observou-
20
1.1 Motivao
acordo com a Tabela 1.2 uma minoria das MPES utiliza programas de medio como
forma de verificar o andamento dos projetos e auxiliar nas tomadas de decises.
Tabela 1.1 Porcentagem de mtricas primitivas utilizadas para medir a produtividade dos
processos de software (MCT, 2005)
Categorias Total Micro Pequena Mdia Grande
Linhas de
10,3% 7,5% 10,3% 11,9% 14,6%
cdigo (LOC)
Pontos por
funo
18,2% 10,6% 21,4% 14,3% 28,1%
(Function
Point)
Outras
6,7% 3,7% 5,5% 11,9% 11,5%
Mtricas
No utiliza 70% 81,4% 66,9% 69% 55,2%
Tabela 1.2 Porcentagem de empresas que utilizam prticas de engenharia de software (MCT,
2005)
Categorias Total Micro Pequena Mdia Grande
Auditorias 22,6% 7,8% 22,1% 39% 39,4%
Levantamento de
Requisitos 18,1% 12,4% 17,1% 22% 27,7%
qualidade
Medies
17,4% 6,5% 17,9% 26,8% 30,9%
(Mtricas)
Testes 54,9% 53,6% 61,4% 48,8% 51,1%
No adota tais
11,6% 18,3% 7,1% 7,3% 8,5%
prticas
Este trabalho est organizado em nove captulos, incluindo esta introduo, alm de um
conjunto de apndices descritos resumidamente a seguir:
O Captulo 2 apresenta a fundamentao terica em relao a estimativa e
medio, com seus principais conceitos.
O Captulo 3 apresenta a fundamentao terica em relao aos padres de
software e o seu objetivo de reusabilidade.
O Captulo 4 discorre sobre alguns trabalhos relacionados na rea de estimativa
e medio.
O Captulo 5 exibe um conjuntos de requisitos para a definio de um processo
de medio para MPES e mostra como os trabalhos relacionados no Captulo 4 atendem
a esses requisitos.
O Captulo 6 apresenta uma linguagem de padres de estimativa documentada a
partir de boas prticas de clculo de estimativa encontradas na literatura.
25
2 ESTIMATIVA E MEDIO
2.1 Introduo
2.2 Estimativas
Contagem
1. Determinar 5. Determinar Contagem
Tipo de Contagem de Pontos de Funo No
Ajustados
3. Contar
Funes do Tipo
Dado
2. Identificar Escopo 7. Calcular o nmero
da Contagem e de Pontos de Funo
Fronteira da 4. Contar Ajustados
Aplicao Funes doTipo
Transao
6. Determinar Valor
do Fator de Ajuste
A fronteira da aplicao indica o limite entre o software que est sendo medido e
o usurio. Define o que externo aplicao e pode ser considerada como a interface
conceitual entre a aplicao interna e o mundo externo do usurio. A fronteira atua
como uma 'membrana' pela qual os dados processados por transaes passam para
dentro e para fora da aplicao.
3. Contar as Funes do Tipo Dados: as funes de dados consistem de Arquivos
Lgicos Internos (ALI) e Arquivos de Interface Externa (AIE). Um ALI um grupo
lgico de dados de controle sob o ponto de vista do usurio e a manuteno feita
internamente pela aplicao. O ALI uma entidade lgica persistente, mantida
dentro da fronteira da aplicao. Um AIE um grupo lgico de dados referenciado
na aplicao cuja responsabilidade pela manuteno de outra aplicao, ou seja,
no mantido pela aplicao que est sendo contada e portanto so armazenados
fora da fronteira da aplicao. Um AIE de uma aplicao sempre ser contado como
um ALI na aplicao de origem. A Figura 2.2 ilustra o processo de contagem de
funes do tipo dado.
A complexidade dos ALI identificada atravs do nmero de itens de dados e
dos registros lgicos. Item de dados representa um segmento de um registro do ALI e
so identificados pelo usurio. So os campos da tabela, por exemplo, e deve-se
29
Identificar ALI
Determinar Complexidade
e Contribuio
3. Contar
Funes do Tipo
Dado
Identificar AIE
Determinar Complexidade
e Contribuio
Cada uma das caractersticas possui um nvel de influncia sobre a aplicao que
varia de 0 a 5: 0 nenhuma influncia, 1 influncia mnima, 2 influncia moderada,
3 influncia mdia, 4 influncia significativa, 5 grande influncia. Aps a
atribuio do nvel de influncia de cada caracterstica, deve-se som-los para obter o
Nvel de Influncia da aplicao e aplicar a seguinte frmula:
Contagem
4. Clculo
1. Classificao dos
dos Atores Fatores
Tcnicos
3. Clculo dos 6. Clculo dos
Pontos de Pontos de
Casos de Uso Casos de Uso
2. Classificao no Ajustados
dos
Casos de Uso 5. Clculo
dos Fatores
Ambientais
Os pesos dos casos de uso so calculados da mesma forma dos atores. O peso
total dos casos de uso do sistema, Unadjusted Use Case Weight (UUCW), calculado
pela soma dos produtos de cada tipo de caso de uso por seu respectivo peso.
3. Clculo dos Pontos de Casos de Uso no Ajustados: o peso total dos atores (UAW)
adicionado ao peso total dos casos de uso (UUCW) para obteno dos pontos de
casos de uso no ajustados, Unajusted Use Case Points (UUCP). Logo,
UUCP = UAW + UUCW;
4. Clculo dos Fatores Tcnicos: um fator que mede o nvel tcnico do sistema e
influi diretamente no clculo da estimativa de tamanho. O objetivo determinar o
34
Fatores Ambientais, Environment Factor (EF), calculado pela soma dos produtos
de cada peso por seu respectivo valor na escala de 0 a 5, Tabela 2.8.
O Fator de Complexidade Ambiental obtido atravs da frmula:
ECF = 1,4 + (-0,03*EF).
6. Clculo dos Pontos de Casos de Uso: o tamanho total do projeto do software, Use
Case Points (UCP), obtido atravs do produto entre os Pontos de Casos de Uso
no Ajustados (UUCP), Fatores de Complexidade Tcnicas (TCF) e Fatores de
Complexidade Ambientais (ECF), de acordo com a frmula:
UCP = UUCP*TCF*ECF
O valor obtido dessa multiplicao representa a estimativa de tamanho do projeto
em Pontos de Casos de Uso.
Figura 2.4 PSM como referncia a demais modelos e padres (DOD, 2003)
seus projetos, para que estes atinjam as metas pr-estabelecidas de prazo, custo e
qualidade.
Em linhas gerais, o PSM um modelo para a estruturao de mensurao em um
projeto de software. O PSM foi criado com a inteno de ser utilizado por:
Gerentes Tcnicos e de Projeto: com a finalidade de obter melhor entendimento do
uso da medio para o gerenciamento dos seus projetos. Os gerentes definem as
medidas especficas para atender as necessidades dos seus projetos;
Equipe Tcnica do Projeto: com a inteno de ajudar a implementar medies em
um ambiente de projeto;
Alta Gerncia ou Empresrios: para atender os requisitos associados com a
implementao da mensurao em suas organizaes.
O PSM utiliza da abordagem de medio top-down, ou seja, as atividades de
medio, para obterem sucesso, devem possuir duas caractersticas:
Alinhamento direto das atividades de coleta e anlise dos dados com as
necessidades de informao dos responsveis pela tomada de decises nos projetos.
O PSM usa das necessidades e objetivos da organizao para direcionar os
requisitos da medio;
A existncia de um processo de medio estruturado e bem documentado
(BORGES; PAULA, 2003).
Fundamentado nessas caractersticas, o PSM define dois modelos: o modelo de
informao e o modelo de processo de medio. O modelo de informao determina
como as medidas utilizadas devem ser especificadas para atender s necessidades de
informao. O modelo de processo especifica como o processo de medio deve ser
conduzido.
O modelo de informao determina como mapear as necessidades de informao
nos atributos dos produtos ou processos que se deseja medir. A construo de uma
medio deve descrever como os atributos devem ser combinados para formar os
critrios de deciso, base para a tomada de decises. Para isso, o modelo de informao
orienta a criao de trs nveis de medidas:
Medidas base: medidas obtidas diretamente da observao das entidades do produto
ou processo que est sendo medido;
Medidas derivadas: valores obtidos a partir da aplicao de algoritmos ou funes
matemticas que combinam duas ou mais medidas;
39
Processos Tcnicos e
Gerenciais Analisar Resultados
Objetivos
Analisar Resultados e
Aes de Avaliar Executar Medies
Melhoria Medio
Escopo do PSM
O presente captulo apresentou uma breve reviso terica relativa aos principais
conceitos de estimativa e medio de software.
Algumas das tcnicas de estimativa apresentadas mostram a preocupao dos
pesquisadores na elaborao de estimativas mais precisas e que tentem retratar o
tamanho do sistema naquele momento. As estimativas de software tm papel importante
no processo de medio uma vez que de posse delas algumas medidas podem ser
obtidas, principalmente medidas mais simples, de apoio gerencial e que podem ser
utilizadas mais facilmente pela MPES.
De maneira geral, as abordagens apresentadas ressaltam a importncia da rea de
medio para o processo de desenvolvimento de software, em especial, a realizao de
atividades de planejamento, coleta e anlise dos dados para que os resultados sejam
efetivos.
Para as MPES, escopo desse trabalho, a implementao de um processo de
medio requer maiores cuidados, principalmente devido limitao de recursos.
Portanto, o reuso de algumas informaes pode tornar o processo de medio menos
oneroso para tais empresas.
No captulo seguinte apresentada a fundamentao terica de padres de
software como um meio de reuso de informaes.
42
3 PADRES DE SOFTWARE
3.1 Introduo
Ou ainda como:
1
Gang of Four: nome do grupo formato pelos quatros autores do livro
45
Diferentes autores adotam diferentes estilos para formalizar seus padres. Alguns
preferem ser mais textuais e menos estruturados, enquanto outros preferem o contrrio.
No existe um formato adequado para todas as ocasies, mas os formatos j existentes
podem e devem ser usados como base.
Entre os formatos de padres mais conhecidos e utilizados por pesquisadores da
rea, esto: o formato alexandriano, o formato dos padres do GoF, o formato dos
padres do POSA, o formato dos anti-padres e o formato cannico. Aqui, apenas o
formato cannico ser descrito por ser o formato escolhido para documentar os padres
detalhados, posteriormente, no Captulo 6.
Apesar de cada formato ter sido criado para atender padres de reas
especficas, diferentes formatos podem, a princpio, ser utilizados na documentao de
qualquer padro. Cabe ento, a cada autor utilizar o formato que mais se adqe ao seu
propsito, ou ainda, definir o seu prprio formato. No entanto, segundo (MESZAROS;
DOBLE, 1996), a documentao dos elementos nome, contexto, problema,
foras e soluo so obrigatrios para a documentao de um padro, mesmo que
no estejam explicitamente visveis.
O formato cannico assim chamado por ser uma forma de compor padres, ou
seja, estrutur-los em sees, onde cada seo composta por um cabealho e um texto
contendo a sua descrio. Ao contrrio do formato Alexandriano, o formato Cannico
possui sees explicitamente delimitadas.
Para documentar no formato Cannico, o autor deve estruturar o padro com as
seguintes sees:
Nome: palavra ou frase que nomeie o padro. O nome do padro deve ser
significativo no sentido de refletir de forma sucinta a sua essncia;
Problema: descreve o problema que o padro resolve diante de um certo
contexto;
Contexto: circunstncias iniciais dentro das quais o problema emerge e para as
quais a soluo desejvel. uma situao que ocorre antes da aplicao do
padro;
Foras: descrio dos aspectos relevantes para o problema e que influenciam na
escolha de uma soluo para esse problema;
Soluo: instrues de como solucionar o problema;
51
Padro de software uma importante na rea da computao por ser um meio de reuso
de informaes. O muito que j foi produzido em termos de padres pouco diante de
todo conhecimento acumulado em dcadas de desenvolvimento de sistemas
computacionais. Nesse sentido, o presente captulo trouxe a importncia e o
reconhecimento dos padres na comunidade de software de todo o mundo.
O captulo seguinte detalha os trabalhos relacionados com processo de medio
em geral e em especial para MPES.
52
4 TRABALHOS RELACIONADOS
4.1 Introduo
comunicao (outras pessoas devem ser capazes de saber o que foi medido) e
repetibilidade (outras pessoas devem ser capazes de realizar as mesmas medies e
obter os mesmo resultados). As medidas foram agrupadas em um modelo conceitual que
apresenta as entidades envolvidas e os relacionamentos existentes entre elas. A ltima
atividade a incorporao do modelo de medio ao processo Praxis (PADUA, 2009).
5.1 Introduo
Diante dos requisitos descritos para processo de medio para MPES e os requisitos
gerais para implantao de processos importante realizar uma verificao junto
literatura sobre quais processos de medio existentes atendem ao conjunto de
requisitos levantados. Para realizar tal verificao foi considerado o conjunto de
trabalhos relacionados, contexto MPES, descritos no Captulo 4.
A Tabela 5.1 descreve o atendimento dos trabalhos relacionados, contexto MPES,
aos requisitos. Para realizao da avaliao dos trabalhos relacionados em relao aos
requisitos foi considerado as informaes contidas exclusivamente nos trabalhos
referenciados. Para avali-los foi utilizada a seguinte classificao: atende, no
atende e indefinido. A classificao atende foi extrada da avaliao de acordo
com a presena explcita do requisito no trabalho relacionado, a classificao no
atende foi avaliada em virtude da ausncia do requisito no trabalho e, atravs da
classificao indefinido no foi possvel afirmar que o trabalhado relacionado atende
ou no ao requisito em virtude da ausncia de maiores informaes.
6.1 Introduo
2. Estimativa do
Esforo Total
3. Obteno da Jornada de
Trabalho 6. Obteno da Hora
8. Aprovao das
Estimativas
Legenda:
2
Em alguns padres, por no existir variaes da soluo, esta seo no foi apresentada.
3
Em alguns padres, por no se encaixar no Running Example, esta seo no foi referenciada.
71
Esse captulo est organizado da seguinte forma: a Seo 6.2 descreve uma
aplicao exemplo para demonstrar a aplicabilidade e o passo a passo da linguagem de
72
padres, a Seo 6.3 detalha os padres documentados nesse captulo e a Seo 6.4
descreve as consideraes finais.
6.3 Os Padres
Contexto:
As MPES de desenvolvimento de software, representada pelos seus gerentes de
projeto, tm dificuldade em estimar o tamanho dos projetos na fase de planejamento,
com escopo geral definido, devido ao custo exigido pelo grande nmero de tcnicas
existentes.
Problema:
Como elaborar estimativas do tamanho total do projeto de forma significativa,
simples e a um custo satisfatrio?
Foras:
1) O gerente de projeto, baseado em experincias anteriores prprias, pode
simplesmente, estimar o tamanho do software sem realizar nenhum clculo,
porm tal estimativa pode acarretar um valor totalmente fora da realidade do
projeto, podendo causar prejuzo financeiro empresa;
2) O gerente de projeto pode optar por estimar o tamanho do software de
acordo com a quantidade de linhas de cdigo por funcionalidade, porm tal
tcnica depende da linguagem de programao utilizada, tornando-a instvel;
3) Estimativas de alto nvel em fases iniciais do projeto podem ser imprecisas,
porm estimativas detalhadas demais podem despender tempo e custo s
MPES;
4) Estimativas baseadas na anlise do projeto quanto s suas funcionalidades e
quantificao delas em relao complexidade podem ser simples e a um
custo satisfatrio s MPES;
5) Dados histricos de estimativas podem ajudar na preciso, uma vez que
auxiliam na contabilizao das funcionalidades;
6) Especialistas externos e o uso de componentes prontos do mercado facilitam
a elaborao de estimativas de forma rpida e precisa, porm as MPES no
possuem recursos financeiros para investir em tal soluo.
74
Soluo:
Para estimar o tamanho do projeto necessrio contabilizar as
funcionalidades. A contabilizao realizada atravs do clculo do nmero de
transaes por caso de uso.
4
No caso de projeto com Notao UML, deve-se construir o diagrama de caso de uso, e a partir dele,
identificar as transaes;
75
15
FNA = Qi Pi
i =1
10
FTNF = 0.65 + Ni 0.01
i =1
Variantes
Ao clculo dos Fatores Tcnicos No-Funcionais FTNF pode ser acrescido
pesos de importncia a cada uma das caractersticas. Assim sendo, ao somatrio do
clculo da frmula estaria incluso o peso de cada uma delas. Os pesos podem variar de
0.5 a 2, de acordo com o grau de complexidade que cada caracterstica trar ao sistema.
Com isso, a frmula do clculo do FTNF seria (MONTEIRO, 2005) (IFPUG, 1999)
(KARNER, 1993):
10
FTNF = 0.65 + 0.01 Ni Pi
i =1
77
Exemplo:
Considere o Sistema de Matrcula descrito na Seo 6.2.
Passo 1. Clculo dos Fatores No-Ajustveis (FNA):
5
Pesos referentes e calibrados de acordo com a tcnica de Pontos de Funo [IFPUG, 1995].
79
Mdia - 10 0
Complexa 4 15 60
FNA 221
Racional:
Os gerentes de projeto das MPES necessitam estimar o tamanho do software de
forma precisa, rpida e simples. Os principais problemas enfrentados por estas empresas
so referentes diversidade de tcnicas existentes, complexidade oferecida por elas,
aliada reduzida quantidade de recursos humanos e financeiros.
O uso de componentes ou softwares disponveis no mercado torna o processo de
estimar rpido e preciso de acordo com a tcnica empregada, no entanto, as MPES no
podem realizar tal investimento.
Dados histricos de estimativas podem ajudar na preciso, caso sejam
consolidadas e avaliadas previamente, mas por si s no funcionam satisfatoriamente.
Ento, estimar o tamanho do software baseado na diviso das funcionalidades
em transaes e na atribuio de complexidades a cada transao torna a estimativa
precisa, rpida e simples uma vez que atende tanto a software estruturados como
orientados a objetos, alm de torn-los independentes de plataforma e linguagem de
desenvolvimento, fazendo o processo apto s MPES.
81
Usos Conhecidos:
A tcnica de medir o tamanho do software por Anlise de Ponto por Funo
(Function Point Analysis FPA) (IFPUG, 1999) derivada a partir de mtricas diretas,
onde o projeto deve ser inteiramente decomposto em funcionalidades de acordo as
interfaces com o usurio, entradas, sada e consultas, atribuindo-se pesos a cada uma
dessas funcionalidades.
O MKII Function Point Analysis (SYMONS, 1991) uma variao da FPA onde
estende a lista dos fatores tcnicos no-funcionais.
O Cosmic Full Function Point - FPP (ABRAN, 2000) outra variao da FPA
onde pode ser ajustada a projetos orientados a objetos. A FPP no leva em considerao
para efeito de tamanho os fatores tcnicos no-funcionais e nem os de qualidade que so
medidos separadamente.
O Use Case Point UCP (KARNER, 1993) uma tcnica de estimativa de
tamanho para software orientado a objetos, onde foi desenvolvida a tcnica de
diagramao para o conceito de caso de uso. O UCP foi criado baseado na FPA onde
explora o modelo e a criao de casos de uso, substitui algumas caractersticas tcnicas
proposta pela FPA, cria os fatores ambientais, como experincia da equipe, e prope
uma estimativa de produtividade.
O Ponto de Caso de Uso Tcnicos TUCP (MONTEIRO, 2005) uma extenso
do UCP como forma de torna a estimativa mais precisa para casos de uso mais
complexos.
Padres Relacionados:
A partir dos dados estimados do tamanho do software pode-se obter a
Estimativa do Esforo Total do desenvolvimento. Com o padro Obteno de Dados
Histricos possvel obter informaes sobre medies anteriores e auxiliar na
classificao das funcionalidades e caractersticas do software a ser desenvolvido.
Contexto:
Os gerentes de projetos das MPES de software tm dificuldade em estimar o
esforo, em horas de trabalho, necessrio para desenvolver o projeto.
82
Problema:
Como elaborar estimativas de esforo para o desenvolvimento do software?
Foras:
1) Para maior preciso das estimativas de esforo, o gerente de projeto pode
realizar a estimativa por fase do projeto de acordo com cada funcionalidade,
e logo aps obter a estimativa de esforo total do software, porm exige um
nvel de detalhamento maior, despendendo tempo e custo s MPES;
2) Estimativas de esforo podem ser obtidas atravs de relatos de experincia
dos especialistas da empresa, porm tais relatos podem remeter a dados
discrepantes e fora da realidade, podendo causar prejuzos financeiros
empresa, risco que as MPES no podem se submeter;
3) A MPES, em virtude do seu porte e condies salariais baixas comparadas s
grandes empresas, possui elevada rotatividade de pessoal, o que prejudica a
elaborao de estimativas precisas de esforo;
4) O cliente do projeto pode exigir um valor limite de esforo para a construo
do software, induzindo o gerente a elaborar estimativas de esforo prximas
a esse valor e fora da realidade da empresa;
5) O clculo de estimativas mais elaboradas ao considerar o tamanho do
software, alm de outros fatores, como por exemplo, o nvel de
desenvolvimento exigido, coeso da equipe e maturidade do processo
tornam a estimativa mais precisa, porm necessitam de tempo para serem
planejadas e calculadas;
6) O clculo de estimativas de esforo baseadas no tamanho total do software e
de acordo com as funcionalidades do software torna a estimativa mais
precisa. Dados histricos de estimativas podem reforar a preciso do
clculo do esforo, alm de fornecer dados como a Produtividade da Equipe;
Soluo:
1) Obtenha a Produtividade (PROD) da equipe atravs do padro Obteno de
Dados Histricos;
2) Obtenha atravs de Estimativa do Tamanho Total (ETT) a estimativa do
tamanho total do software a ser desenvolvido;
83
PROD = Produtividade,
ETT = Estimativa do Tamanho Total
Variantes:
O Esforo Total do software pode ser obtido com maior preciso ao considerar o
nvel de Experincia da Equipe (EE) nas tecnologias e processos envolvidos.
Classifique a equipe quanto sua experincia de acordo com as caractersticas da
Tabela 6.6. Cada caracterstica deve ser avaliada com notas: 0 no atende, 3 atende
parcialmente, 5 atende completamente;
Capacidade de Anlise N3
Experincia com a Orientao a Objetos N4
Exemplo:
Considere, por exemplo, que a produtividade mdia da equipe da empresa XYZ
de 10hs/ETT.
Logo,
ESF = 10 236.47 2364 horas
Suponha agora, que a Experincia da Equipe seja 11. Logo,
FA = 1 .4 ( 0 .03 x11) = 1 .07
84
Racional:
Simplesmente estimar o esforo necessrio para o projeto atravs de relatos de
experincia individuais dos membros da empresa, no to preciso quanto a obteno
de valores reais baseados em clculos previamente definidos.
Outra abordagem a obteno de estimativas por fase do projeto, para
posteriormente estimar o todo. Abordagens destes tipos tendem a possuir maior grau de
preciso, porm necessitam de dedicao e tempo para planejamento das fases do
projeto, itens que as MPES no possuem.
Estimar o esforo total para desenvolvimento do software baseado no clculo
prvio do seu tamanho total e na produtividade mdia da equipe uma boa soluo em
virtude da sua simplicidade, porm em projetos maiores convm considerar tambm o
nvel de experincia da equipe nas tecnologias exigidas.
85
Usos Conhecidos:
A tcnica de Anlise de Ponto por Funo calcula o esforo a partir do produto
entre o tamanho do projeto e a a utilizao da taxa de entrega.
A tcnica Construtive Cost Model - COCOMO II (BOEHM, 2000) calcula
esforo, prazo, tamanho de equipe e custo necessrio para o desenvolvimento do
software, desde que se tenha a dimenso do mesmo, ou seja, seu tamanho. Nesta
tcnica, alm dos fatores considerados para o clculo do esforo so considerados
outros fatores de escala.
As tcnicas UCP (MONTEIRO, 2005) (KARNER, 1993) e TUCP calculam o
esforo a partir dos dados citados na soluo, levando em considerao os fatores
ambientais que so calculados a partir de vrios itens com atribuies de pesos.
Padres Relacionados:
O padro Estimativa do Tamanho Total e Obteno de Dados Histricos
servem como entrada desse padro ao calcular o tamanho do software e a produtividade
da equipe, respectivamente. Com o valor em horas do esforo total do projeto, o gerente
pode obter as demais estimativas de prazo e custo com os padres: Estimativa do Prazo
Total e Estimativa do Custo Total.
Contexto:
No planejamento do projeto, o gerente necessita de todas as informaes
referentes aos profissionais da rea para calcular as estimativas de prazo total do
projeto, entre elas, o valor da jornada de trabalho dos empregados.
Problema:
Como obter o valor da jornada de trabalho dos funcionrios da empresa para
estimar de forma mais precisa o prazo do projeto?
Foras:
1) Cada profissional tem horrio e jornada de trabalho diferenciada, o que
dificulta este tipo de levantamento;
86
Soluo:
1) Caso exista o departamento de recursos humanos verifique a jornada de
trabalho diria, em horas, dos profissionais;
2) Se houver divergncia na jornada de trabalho dos profissionais, realize uma
mdia para obter o valor da jornada geral.
Exemplo:
O gerente de projeto do Sistema de Matrcula verificou junto ao setor de
recursos humanos da empresa XYZ que todos os profissionais possuem a mesma
jornada de trabalho de 8 horas por dia. Logo,
VlrJTRAB = 8 horas/dia
Contexto Resultante:
Vantagens:
o O gerente do projeto, de posse do valor da Jornada de Trabalho dos
profissionais da empresa, poder estimar e decidir quanto ao prazo
total de concluso do projeto. Sendo assim, o gerente pode negociar
melhor com o cliente.
87
Racional:
O departamento de recursos humanos responsvel por controlar desde a
contratao dos empregados, at salrio e freqncia. este departamento que possui
relatrios sobre a jornada de trabalho de cada profissional. Nem todas as MPES
possuem tal setor em virtude da quantidade reduzida de profissionais, cabendo ento ao
gerente realizar o levantamento por si s.
Usos Conhecidos:
Em geral todos os gerentes de projetos que necessitam realizar estimativas
obtm o valor da jornada de trabalho dos empregados da empresa.
Uma instituio financeira atualmente em todo o Brasil obtm o valor da jornada
de trabalho de todos os profissionais da rea de TI como forma de estimar os projetos de
software. Tal instituio utiliza a tcnica de TUCP (MONTEIRO, 2005) para estimar os
softwares em todos seus projetos.
Padres Relacionados:
Com a informao da jornada de trabalho, o gerente de projeto poder dar
continuidade s demais medies como: Obteno de Recursos Humanos Disponveis,
Estimativa do Prazo Total e Estimativa do Custo Total.
Contexto:
No planejamento do projeto, os gerentes de projetos das MPES precisam ter
visibilidade de todos os seus recursos humanos para devida alocao no projeto.
Problema:
Como obter a quantidade de recursos humanos disponveis da empresa para
serem alocados no projeto?
Foras:
88
Soluo:
1) Faa um levantamento, por e-mail, de todos os profissionais da empresa para
saber a alocao de cada um;
2) Verifique atravs do padro Obteno do Valor da Jornada de Trabalho a
quantidade de horas trabalhadas diariamente;
3) Verifique a quantidade de recursos humanos completamente disponveis e
contabilize-os;
4) Verifique aqueles recursos que esto parcialmente alocados, e contabilize-os
atravs de horas/dia disponveis. Realize regra de trs simples para calcular a
porcentagem de tempo disponvel em relao ao todo.
5) Some e obtenha a Quantidade de Recursos Disponveis (QtdRD);
6) Realize mapeamento inicial dos recursos disponveis com respectivos papis
necessrios no projeto;
Exemplo:
A empresa XYZ possui 15 funcionrios, entre gerentes, analistas, projetistas e
desenvolvedores. Entre eles, apenas 3 (trs) esto completamente disponveis (um
analista de sistemas e dois programadores) para serem alocados ao projeto de Matrcula
dos Alunos na Universidade. O gerente de projeto possui apenas 6 horas livre por dia.
Suponha ainda, que nenhum dos recursos est disponvel para realizao de horas-extras
e que o valor da jornada de trabalho de 8horas/dia. Logo, fazendo uma regra de trs
simples, temos que o gerente de projeto contabiliza apenas 75% do tempo.
Ento:
QtdRD = 3 + 0.75 = 3.75 pessoas
Contexto Resultante:
Vantagens
o O gerente de projeto, de posse da quantidade de recursos disponveis
e da jornada de trabalho poder calcular o prazo total de execuo do
projeto;
o O gerente de projeto poder distribuir os recursos disponveis no
projeto de acordo a disponibilidade de cada um..
Desvantagens
o Nas MPES, devido ao reduzido quadro de empregados, cada um
deles exerce mais de um papel, logo, tal levantamento no trivial.
Cabe ao gerente de projeto encontrar a melhor forma de quantificar a
disponibilidade de cada um.
Racional:
Realizar o levantamento da quantidade de recursos disponveis via e-mail uma
soluo prtica e com tempo de resposta satisfatrio, o que facilita ao gerente o
levantamento dos recursos disponveis, uma vez que nas MPES o quadro de
funcionrios reduzido.
Ao analisar criteriosamente a distribuio e alocao dos recursos nos projetos
atuais da empresa e contabiliz-los, o gerente de projeto poder planejar melhor a
utilizao de tais recursos no novo projeto.
90
Usos Conhecidos:
O Rational Unified Process RUP (KRUCHTEN, 2003), na disciplina Gerncia
de Projeto, possui o artefato chamado de Plano de Projeto, onde o gerente de projeto
tem a misso de verificar os recursos disponveis da empresa para alocao no projeto.
O Capability Maturity Model Integrated - CMMI (SEI, 2006) na rea de
processo de Planejamento de Projeto possui uma prtica especfica chamada de Plan for
Project Resources onde alm do planejamento e obteno dos recursos humanos
disponveis para o projeto, verifica a disponibilidade de recursos de hardware e
software.
O PMBOK (PMI, 2009) voltado para a gerncia de projetos, entre as diversas
reas de conhecimento est a rea de Gerncia do Custo do Projeto que inclui o
processo de Planejamento de Recursos para determinar quais recursos (pessoas,
equipamentos, materiais) e em que quantidade devem ser usados para executar as
atividades do projeto.
O MPS.BR (SOFTEX, 2009a), no nvel G, possui o processo de Gerncia de
Projetos, onde entre tantas atividades encontra-se a de planejamento de recursos
humanos.
Padres Relacionados:
Para obter os recursos da empresa e observar a alocao e disponibilidade de
cada um, necessrio a Obteno do Valor da Jornada de Trabalho. A quantidade de
recursos disponveis para o projeto auxilia na Estimativa do Prazo Total.
Contexto:
O gerente de projeto, na fase de planejamento de projeto, de posse do esforo em
horas total do projeto, da quantidade de recursos disponveis ao projeto e do valor da
jornada de trabalho dos profissionais, necessita quantificar ao cliente o prazo necessrio
para desenvolver o sistema solicitado, como forma de firmar um acordo e fechar o
contrato.
91
Problema:
Como elaborar estimativas de prazo do desenvolvimento do software na fase
inicial do projeto?
Foras:
1) O cliente do projeto pode exigir um valor limite de prazo para entrega do
produto, induzindo o gerente a elaborar estimativas de prazo prximas a esse
valor, fora da realidade da empresa e sem nenhum embasamento;
2) Estimativas de prazo podem ser obtidas atravs de relatos de experincia dos
especialistas da empresa, porm tal valor pode ser subestimado ou
sobreestimado, podendo causar, respectivamente, prejuzos financeiros
empresa ou insatisfao ao cliente;
3) O gerente pode obter o prazo total do projeto baseado em dados
quantitativos de medio, como o esforo total e a quantidade de recursos
disponveis, o que causa maior preciso estimativa;
4) O gerente de projeto pode estimar o prazo total atravs de tcnicas
elaboradas que levam em considerao vrios fatores de ponderao, porm
a utilizao de tais tcnicas despende tempo que os gerentes de MPES no
possuem;
5) As MPES no possuem segurana ao estimar o prazo de um projeto, porm
se este for decomposto e contabilizado em escopos menores para
posteriormente estimar o prazo total, este ser mais facilmente contabilizado,
entretanto, tal decomposio exige tempo que estas empresas no possuem;
Soluo:
1) Obtenha atravs de Estimativa do Esforo Total o esforo total, em horas,
necessrio para o desenvolvimento do projeto;
2) Atravs de Obteno dos Recursos Humanos Disponveis, obtenha a
quantidade de recursos disponveis para o projeto;
3) Atravs de Obteno do Valor da Jornada de Trabalho, obtenha o valor da
jornada de trabalho dos funcionrios da empresa;
4) Calcule a Estimativa de Prazo Total do Software (EPRZ):
92
ESF
EPRZ = , onde:
(QtdRD VlrJTRAB )
ESF = Esforo Total do Projeto
QtdRD = Quantidade de Recursos Humanos Disponveis
VlrJTRAB = Valor da Jornada de Trabalho
Exemplo:
A empresa XYZ, para desenvolver o projeto Sistema de Matrcula, necessitar
de um prazo de aproximadamente:
2530
EPRZ = 84 dias teis
3.75 8
Contexto Resultante:
Vantagens:
o A empresa obter o valor do prazo total de desenvolvimento do
projeto em dias a partir de dados objetivos e racionais, podendo
assim, negociar mais facilmente com o cliente.
Desvantagens:
o O clculo do prazo depende do calculo da jornada de trabalho e dos
recursos disponveis. Esses dois ltimos so complicados nas MPES
em virtude do reduzido quadro de profissionais e da alocao deles
em outros projetos.
Racional:
Simplesmente estimar o tempo necessrio para o desenvolvimento do projeto
atravs de relatos de experincia individuais dos membros da empresa, no to preciso
quanto a obteno de valores reais baseados em clculos previamente definidos.
As obtenes do prazo do projeto atravs de tcnicas mais elaboradas e da
decomposio do projeto tornam a estimativa com maior grau de preciso, porm a
execuo de tais estimativas necessita de tempo, preparo e custo.
Estimar o prazo baseado em dados previamente calculados, como o esforo,
quantidade de recursos disponveis e jornada de trabalho, torna a estimativa precisa o
93
suficiente e simples, possibilitando com que as MPES sejam objetivas no clculo das
estimativas.
Usos Conhecidos:
A tcnica Anlise de Ponto por Funo calcula a estimativa de prazo atravs da
razo entre esforo e recursos.
A tcnica do COCOMO II (BOEHM, 2000) obtm o prazo total do projeto a
partir do esforo e equipe mdia necessria para o desenvolvimento.
J o UCP (KARNER, 1993) e TUCP (MONTEIRO, 2005) calculam o prazo
total do projeto a partir dos valores do esforo, quantidade de recursos e horas de
trabalho dirio de cada profissional. No caso do TUCP as jornadas de trabalho dos
profissionais so consideradas informaes pr-definidas.
Padres Relacionados:
Os seguintes padres so necessrios para o clculo do valor do prazo total do
projeto: Estimativa do Esforo Total, Obteno dos Recursos Humanos Disponveis e
Obteno do Valor da Jornada de Trabalho. O gerente de projeto aps ter mensurado
o projeto quanto a prazo, dever aprov-lo junto ao cliente atravs do padro Aprovao
das Estimativas.
Contexto:
O gerente de projeto, ao planejar o desenvolvimento do sistema, necessita obter
informaes do valor da hora de trabalho dos funcionrios da empresa, como forma de
mensurar o custo total de execuo do projeto.
Problema:
Como obter o valor da hora de trabalho dos funcionrios da empresa?
94
Foras:
1) O gerente de projeto pode obter o valor da hora de trabalho baseado no
mercado e no em valores internos da empresa, podendo posteriormente ter
um impacto significativo no custo do software;
2) O gerente de projeto pode obter o valor da hora de trabalho de acordo com
dados de projetos anteriores, porm tais valores podem estar desatualizados;
3) O gerente de projeto pode calcular o valor da hora de acordo com o maior
salrio ou ainda com a mdia geral de todos os salrios dos funcionrios. No
entanto, tal forma de calcular pode gerar um valor elevado, com impacto
direto no custo do software;
4) Os salrios dos funcionrios variam de acordo com o cargo,
conseqentemente, o valor da hora de trabalho tambm. O gerente pode,
ento, calcular o valor da hora de trabalho de acordo com o papel de cada
um;
5) Os funcionrios das MPES geralmente assumem mais de um papel no
processo de desenvolvimento, o que pode influenciar na obteno do valor
da hora de trabalho em cada projeto.
Soluo:
1) Para cada papel necessrio no processo de desenvolvimento do projeto,
calcule o valor da hora de trabalho:
Salrio
VlrHORA( Papel) = , onde:
VlrJTRAB 30
VlrJTRAB = Valor da Jornada de Trabalho
Exemplo:
Para o Sistema de Matrcula sero alocados 4 profissionais. Trs deles alocados
plenamente no projeto e um deles alocado parcialmente (6 horas por dia). Supondo que
a alocao no projeto esteja distribuda da seguinte forma: 1 gerente de projeto (6 horas
por dia), 1 analista, 2 desenvolvedores. Supondo ainda que estes funcionrios possuam
os respectivos salrios: R$3.500,00, R$2.600,00, R$ 2000,00. Logo,
95
3.500,00
VlrHORA(Gerente) = R$19.50
6 30
2.600,00
VlrHORA( Analista) = R$10.90
8 30
2.000,00
VlrHORA( Desenvolvedor) = R$8.40
8 30
Contexto Resultante:
Vantagens
o Nas MPES, na maioria das vezes, cada profissional exerce mais de um
papel, logo o clculo poder ser realizado de acordo com a quantidade de
horas trabalhadas em cada papel;
o Com os valores acima, o gerente do projeto poder calcular o valor
gasto, em reais, de cada um dos profissionais para execuo do projeto.
Podendo negociar os valores com o cliente.
Desvantagens
o Para cada cargo ou variao salarial da empresa, o gerente de projeto ter
que calcular o valor da hora do profissional. Para contornar isso, o
gerente poder considerar a maior variao salarial dentro de
determinado cargo, por exemplo.
Racional:
Obter o valor da jornada de trabalho de profissionais de informtica no mercado
um risco ao projeto. Cada empresa brasileira possui porte e salrios diferenciados, nas
MPES esses valores so mais discrepantes, necessitando, portanto, clculos reais de
acordo com sua realidade. Os salrios de quaisquer profissionais variam constantemente
e o valor da hora de trabalho necessita ser recalculado periodicamente.
A opo de calcular individualmente o valor da hora de trabalho de cada papel
do profissional no projeto torna a estimativa mais precisa do que, por exemplo, pegar
uma mdia geral do valor.
Usos Conhecidos:
De acordo com o Artigo 64 da Lei Trabalhista CLT o valor da hora de trabalho
de um trabalhador obtido a partir do salrio e da jornada de trabalho dividido por 30
dias.
96
Padres Relacionados:
O valor da hora de trabalho de cada profissional dado de entrada para o clculo
da Estimativa do Custo Total.
Contexto:
O gerente do projeto necessita na fase de planejamento, obter o custo, ou seja, a
despesa do projeto para a empresa como forma de negociar com o cliente o valor do
desenvolvimento do mesmo.
Problema:
Como elaborar estimativas de custo do desenvolvimento do software?
Foras:
1) Estimar o custo de desenvolvimento ao levar em considerao apenas o valor
do salrio mais elevado da empresa e do esforo total de desenvolvimento do
software pode acarretar no superfaturamento do software;
2) O gerente de projeto, baseado em experincias anteriores, pode estimar o
custo do desenvolvimento do software. No entanto, tal estimativa pode
superfaturar ou subfaturar o valor do software;
3) O gerente de projeto pode levar em considerao a necessidade financeira da
MPES e assim estimar o valor do custo do software, porm tal estimativa
pode prejudicar a negociao com o cliente;
97
Soluo:
1) Obtenha a Estimativa do Esforo Total;
2) Obtenha, em porcentagem, o esforo necessrio para cada papel no projeto.
Para isso, verifique dados histricos anteriores em Obteno de Dados
Histricos;
3) Com a Obteno do Valor da Hora, o valor da hora de trabalho de cada
papel do projeto obtido;
4) Calcule o custo total do desenvolvimento do projeto, da seguinte forma:
Exemplo:
Supondo que as fases do desenvolvimento do Software estejam divdiidas em:
Requisitos, Anlise, Projeto, Codificao e Teste. Supondo ainda que 15% do esforo
total ser gasto com o Gerente de Projeto, 35% do esforo total ser gasto nas fases de
98
Contexto Resultante:
Vantagens
o A empresa ter o valor do custo total de desenvolvimento do projeto
baseado em valores objetivos, calculados a partir de dados concretos
do custo do software, podendo assim, acrescentar custos adicionais e
negociar com o cliente.
Desvantagens
o O custo calculado do software pode ser maior do que o esperado pelo
cliente. Cabe ao gerente efetuar as devidas negociaes e assumir os
riscos;
Racional:
Estimar o custo do software baseado em experincias anteriores ou de acordo
com a presso do cliente pode gerar um risco financeiro alto as MPES que geralmente
no possuem recursos financeiros extras para sustentar a empresa. Portanto, o ideal
estimar o custo baseado em valores reais do tamanho e esforo do software.
A porcentagem gasta em cada fase do desenvolvimento do software varia de
empresa pra empresa. Cada empresa deve guardar estas informaes em dados
histricos para avaliao dos projetos subseqentes. O resultado do custo total do
software depende consideravelmente da porcentagem de contribuio de cada
profissional ao longo do projeto e conseqentemente do valor da hora de trabalho de
cada um. Estimar o software baseado em tais valores torna a estimativa simples e
precisa. Superfaturar um pouco o custo do software melhor do que a situao
contrria, principalmente para as MPES.
99
Usos Conhecidos:
As tcnicas UCP (KARNER, 1993) e sua variao TUCP (MESZAROS;
DOBLE, 1996) e COCOMO II (BOEHM, 2000) utilizam esta forma de clculo do custo
do software por fase de desenvolvimento.
Padres Relacionados:
A partir da Estimativa do Esforo Total, Obteno do Valor da Hora e
Obteno de Dados Histricos o gerente estima o tempo gasto por fase do projeto para
calcular o custo. Posteriormente, o gerente necessita a Aprovao das Estimativas por
parte do cliente.
Contexto:
O gerente de projeto calculou todas as estimativas do software quanto a prazo e
custo do projeto. O gerente necessita da aprovao do cliente.
Problema:
Como aprovar as estimativas?
Foras:
1) O gerente de projeto pode optar por aprovar as estimativas junto ao cliente
sem despender tempo, podendo realizar a negociao atravs de trocas de e-
mails ou contato telefnico. No entanto, tal forma de aprovao pode gerar
ao cliente m impresso e desleixe por parte da empresa;
2) O gerente de projeto pode tentar aprovar as estimativas com o cliente atravs
de reunies, o qu pode transmitir maior grau de segurana, organizao e
ateno ao cliente, deixando-o mais confiante;
3) O gerente pode tentar aprovar as estimativas com o cliente ao explicar
minuciosamente como obteve os valores de prazo e custo do software.
Assim, pode aumentar a segurana do cliente em relao a essas estimativas,
tornando mais fcil a sua aprovao;
100
Soluo:
1) Marque reunio com o cliente;
2) Apresente os valores de prazo e custo do desenvolvimento ao cliente;
3) Apresente ao cliente as informaes de como foram calculados os valores
apresentados;
4) Transmita segurana ao cliente, que o clculo dos valores justo e de acordo
com as funcionalidades e complexidades exigidas por ele;
5) O cliente aceita os valores e assina o contrato.
Variantes:
Na reunio, aps a apresentao dos valores por parte do gerente e tentativa de
convencer o cliente:
1) O cliente no aceita os valores;
2) O gerente marca outra reunio com o cliente para apresentao de novos
valores;
3) O gerente refaz os clculos na tentativa de atender a expectativa do cliente;
4) O gerente apresenta os novos valores ao cliente;
5) O cliente aceita os valores e assina o contrato;
6) O cliente pode ainda no aceitar os valores e cancelar o projeto com a
empresa.
Contexto Resultante:
Vantagens
101
Usos Conhecidos:
Uma instituio financeira utiliza o processo de aprovao de estimativas atravs
de reunies com cliente. O gerente de projeto apresenta ao cliente as estimativas e
ocorrem as devidas negociaes. No caso dessa instituio, o cliente a prpria
instituio, ou seja, desenvolvimento interno de software. Para todos os sistemas
produzidos em tal instituio utilizado o TUCP (MONTEIRO, 2005) para o clculo
das estimativas e posteriormente efetuada a aprovao das mesmas.
Padres Relacionados:
Os padres de Estimativa do Custo Total, Estimativa do Prazo Total so
essenciais para a negociao com o cliente. Uma vez aprovados os valores, cabe ao
102
Contexto:
No decorrer do processo de desenvolvimento do software necessrio coletar
informaes reais sobre o andamento do projeto. O Gerente de Projeto deve definir as
medies;
Problema:
Quais as medies que auxiliam no processo de estimar o software? Como
coletar medidas reais do tamanho do software, do esforo, do prazo e do custo?
Foras:
1) Realizar medies em um ambiente sem cultura de medies pode provocar
resistncias;
2) Para definio das medies a serem realizadas necessrio planejamento
por parte do gerente de projeto. O planejamento e definio de tais mtricas
so realizados apenas uma vez no processo de desenvolvimento e atende a
todos os projetos da empresa;
3) A organizao precisa estar disposta a encarar as medies como um
investimento em longo prazo, visto que para disponibilizar a realidade da
organizao com base em mtricas, necessrio tempo;
4) Para realizar as medies, o gerente de projeto pode obter pessoalmente as
informaes com os membros do projeto. No entanto, tal coleta por parte do
gerente faz com ele deixe de executar atividades prprias do seu papel;
5) A compra de uma ferramenta que automatize o processo de coleta e obteno
de medidas reais e que possa ser integrada com as ferramentas de anlise e
desenvolvimento dos projetos torna o processo rpido e simples. No entanto,
as MPES no possuem recursos financeiros para tal investimento;
103
Soluo:
1) Defina o qu ser medido, por exemplo:
a. Para cada funcionalidade do projeto, classifique-a como transao de
entrada de dados (TED), de sada de dados (TSD), consulta (TCD), sada
de dados externa (TEX) e de persistncia de dados (TPD);
b. Para cada funcionalidade do projeto, classifique-a como baixa, mdia ou
alta e realize a medio;
c. Esforo em horas gasto por fase/total do projeto;
d. Quantidade de horas e/ou dias total gasto por papel (contabilize tambm
em relao ao todo); Quantidade de horas e/ou dias total gasto por fase
(contabilize tambm em relao ao todo); Quantidade de horas e/ou dias
total do projeto;
e. Tamanho Total Real do software no final do projeto (verifique mudanas
de requisitos);
f. Produtividade da Equipe = Esforo Total Real/Tamanho Total Real;
g. Custo real do projeto total;
2) Defina o plano de mtricas, com as informaes: o que ser medido, como,
por quem e quando.
3) Construa documentos a serem preenchidos pelos profissionais aptos do
projeto, onde cada documento contm informaes sobre os dados que sero
medidos;
4) Disponibilize base de dados para guardar as medies;
5) Defina marcos no projeto para coletar as medies;
6) Cada membro do projeto responsvel por preencher documento sobre as
suas correspondentes medies;
7) O gerente de projeto de posse das medies deve alimentar base de dados
para posterior Obteno de Dados Histricos.
Contexto Resultante:
Vantagens
104
o A empresa ter base de dados com dados histricos reais por projeto,
podendo melhorar as estimativas em projetos futuros;
o A medio ajuda na avaliao objetiva dos dados. No se pode
melhorar o que no medido;
o O gerente de posse dos indicadores extrados das medies pode, por
exemplo: avaliar o status do projeto, controlar os riscos, ajustar as
atividades e avaliar a capacidade da equipe de controlar a qualidade
do produto de trabalho.
Desvantagens
o Todo trabalho de medio poder ser colocado em risco se no for
garantido a obteno de dados confiveis.
Racional:
Apesar da resistncia das pessoas para realizar as medies, a definio de
medidas simples no tomam tempo dos membros do projeto. Com o decorrer do tempo,
esse tipo de atividade se torna habitual, o essencial insistir na importncia da medio
para o futuro da empresa.
Usos Conhecidos:
O CMMI (SEI, 2006) na rea de processo Medio e Anlise utiliza a coleta de
dados no decorrer do processo de desenvolvimento.
O MPS.BR (SOFTEX, 2009a) no processo de Medio possui a atividade de
coletar dados e armazenamento dos dados e resultados.
Em (VASQUEZ, 2003) utilizado a atividade de Aprovar Estimativas no
processo de estimativa de um projeto de software.
Padres Relacionados:
Com a concentrao de tais informaes em uma base de dados compartilhada
pelos gerentes, os mesmos podem consult-las, Obteno de Dados Histricos, para
melhorar a preciso das estimativas em projetos futuros.
105
Contexto:
Na fase de planejamento de projeto, o gerente necessita estimar o tamanho do
software, o esforo, o prazo e o custo para o seu desenvolvimento. Os membros dos
projetos realizam a coleta de medies de dados reais dos projetos envolvidos e
armazenam tais dados. Dados histricos de projetos anteriores devem ser capazes de
melhorar a preciso das estimativas.
Problema:
Como obter dados histricos com o intuito de melhorar a preciso das
estimativas?
Foras:
1) O gerente de projeto pode obter dados histricos atravs da sua prpria
experincia em projetos anteriores, dados estes puramente intuitivos,
podendo comprometer as estimativas;
2) O gerente de projeto pode obter dados histricos de outras empresas ou do
mercado de forma geral, dados estes que no esto de acordo com a
realidade da empresa;
3) O gerente de projeto pode obter dados histricos a partir de uma base de
dados consolidada na empresa que guarde essas informaes.
Soluo:
1) Realize consultas na base de dados;
a. Ao estimar o tamanho total do software, Estimativa do Tamanho Total,
verifique em projetos anteriores como as funcionalidades foram
classificadas quanto complexidade e transaes;
b. Ao estimar o esforo total do software, Estimativa do Esforo Total,
verifique a mdia da produtividade da equipe em projetos anteriores;
c. Ao estimar o custo total do software, Estimativa do Custo Total,
verifique a porcentagem de esforo gasto para cada papel do projeto em
relao ao todo;
106
Contexto Resultante:
Vantagens
o A empresa ter dados consolidados de acordo com seu prprio perfil.
o Com base em dados de projetos anteriores, o gerente de projeto poder
calcular as estimativas com maior preciso.
Desvantagens
o Possibilidade de dbia interpretao dos dados histricos, prejudicando o
clculo das estimativas. Para tanto, a base dos dados histricos necessita
estar consolidada e claramente interpretada.
Racional:
Simplesmente consultar a base de dados no suficiente para melhorar a
preciso das estimativas. necessrio, alm disso, fazer uma anlise criteriosa dos
dados que so realmente relevantes e podem ser considerados no clculo das
estimativas.
Usos Conhecidos:
O CMMI (SEI, 2006), na rea de processo Medio e Anlise, obtm dados
histricos dos resultados provenientes de base de dados e possibilita a anlise dos
dados.
O MPS.BR (SOFTEX, 2009a) no processo de Medio possui a atividade de
anlise dos dados e resultados. As informaes produzidas so usadas para apoiar
decises e para fornecer uma base objetiva para comunicao aos interessados;
Em (VASQUEZ, 2003) utilizado a atividade de Obter Dados Histricos no
processo de estimativa de um projeto de software.
Padres Relacionados:
Os dados histricos so obtidos a partir da coleta prvia de medidas reais, Coleta de
Medidas Reais. Obtenha dados histricos de projetos anteriores para auxiliar na
classificao das funcionalidades da Estimativa do Tamanho do Software. Na
Estimativa de Esforo Total os dados histricos auxiliam na obteno da produtividade
mdia da equipe. Na Estimativa do Custo Total os dados histricos auxiliam na
porcentagem de esforo por atividade.
107
Este captulo tem por principal objetivo auxiliar os gerentes e lderes de projeto das
MPES a mensurar valores de estimativa de software na fase de planejamento de projeto
de forma padronizada. Alm de prover um processo simples de melhoria da qualidade
ao sugerir a coleta de medidas reais no decorrer do desenvolvimento do software para
apoiar em futuras estimativas e decises estratgicas da empresa.
O Captulo 7 descreve um processo formal de medio simplificado para MPES
baseado nos padres documentados nesse captulo.
108
7.1 Introduo
Processo de
Medio
1...*
Etapas
1
1*
1*
Papel
Atividade
1
1* Artefato
1*
1
Tarefa
0*
Guias,
Padres e
Ferramentas
A Figura 7.2 ilustra de forma geral o processo ProMePE com suas atividades.
Para a implatano do ProMePE necessrio estabelecer, primeiramente, o
compromisso organizacional que trata de garantir o envolvimento de todos da
organizao na implantao do processo.
Aps o acordo de todos da organizao em relao ao processo de medio,
surge a primeira atividade do ProMePE, denominada de Planejar Medio, onde feita
6
O PSMSE foi modelado utilizando a ferramenta de modelagem de processo EPF Composer (ECLIPSE,
2007).
110
a escolha das medidas a serem coletadas de acordo com a identificao das necessidades
informao do projeto, como essas medida sero coletadas, por quem e em qual
momento dentro do processo.
Logo aps, a atividade Aplicar Estimativas ocorre. O objetivo desta atividade a
realizao das estimativas iniciais do projeto. De posse dos requisitos do projeto, o
gerente de projeto estima tamanho, prazo e custo do projeto. As estimativas esto de
acordo com as solues dos padres descritas no Captulo 6.
Etapas
As etapas para execuo da tarefa so:
Identificar e priorizar as necessidades de informaes para auxiliar a
organizao na definio das medidas;
Selecionar e especificar as medidas base e medidas derivadas baseadas nas
necessidades de informao do projeto;
Determinar a freqncia de coleta e anlise dos dados, os responsveis por
cada um e as ferramentas utilizadas;
Determinar os mecanismos de divulgao dos dados, quando necessrios.
Papel
O gerente de projeto o papel principal e nico nessa tarefa. Ele o responsvel
pela definio de quais as medidas que o projeto utilizar dependendo dos seus
objetivos e restries, ou seja, da lista de necessidades do projeto.
Artefato(s) de Sada
Plano de Medio do Projeto: o gerente de projeto desenvolve o plano de
medio com, entre outras informaes, a lista de necessidades do projeto, o
planejamento das medidas que sero coletadas e analisadas (medidas base,
medidas derivadas e indicadores), freqncia da coleta, ferramentas
utilizadas, alocao das pessoas responsveis pela coleta e anlise dos dados
durante o ciclo do projeto.
Guia de Orientao
Plano de Medio de Referncia: plano geral que contm um conjunto de
lista de necessidades e medidas pr-selecionadas para servir de base para a
construo do plano de medio especfico do projeto. O ProMePE prov
este plano de medio para ser instanciado pelos projetos das MPES. O
objetivo ajudar as MPES na construo do plano de medio e possibilitar
sua instanciao (incluso, remoo e adaptao das listas de necessidade e
medidas). Outro objetivo do plano de medio de referncia possibilitar o
reuso de suas informaes dentro da empresa. O plano de medio de
referncia tambm contm outras informaes, tais como os pesos para
contagem da estimativa de esforo e a porcentagem de esforo por papel, por
exemplo. A Tabela 7.2 apresenta a parte do Plano de Medio de Referncia
relacionada lista de necessidades de informao com as possveis medidas
114
Tabela 7.2 Mapeamento entre necessidade de informao e medidas base presente no Plano
de Medio de Referncia, ProMePE
7
Para classificar as transaes pode-se considerar a complexidade relativa de acordo com a experincia
da equipe no desenvolvimento de determinada transao.
117
Qi = Quantidade de Transaes
Pi = Peso de cada grupo de transaes de acordo com sua
complexidade
Calcular os Fatores Tcnicos No-Funcionais (FTNF).
Os Fatores Tcnicos No-Funcionais so obtidos a partir dos
requisitos no funcionais do sistema. Logo, para obter tais fatores:
a. Classificar o projeto quanto s caractersticas abaixo, de
acordo com a 0. Cada caracterstica deve ser avaliada com notas: 0
no requerida, 3 requerida parcialmente, 5 requerida
completamente (MONTEIRO, 2005) (IFPUG, 1999). Presente no
Plano de Medio de Referncia, seo medidas derivadas,
conforme Tabela 7.4.
b. Calcular os Fatores Tcnicos No- Funcionais de acordo
com a frmula:
10
FTNF = 0.65 + Ni 0.01 , onde,
i =1
Ni = Nota de cada caracterstica
118
PROD = Produtividade,
ETT = Estimativa do Tamanho Total
Papel
O gerente de projeto o responsvel por calcular o esforo total em horas de
trabalho para execuo do projeto.
Artefato(s) de Entrada
Plano de Medio do Projeto: plano que contm as necessidades de
informao, as medidas base, medidas derivadas e indicadores a serem
utilizadas no projeto. Entre as possveis medidas est o tamanho do projeto,
o esforo e uma breve descrio de como calcul-las, por exemplo;
120
8
Esta frmula foi alterada em relao ao que est descrito no padro Estimar Esforo.
121
Artefato(s) de Entrada
Plano de Medio do Projeto: plano que contm a lista de medidas
especficas para o projeto e o momento que as medidas devem ser coletadas.
O gerente deve consultar o plano para saber informaes sobre o clculo do
prazo do projeto, por exemplo;
Quantidade de Recursos Humanos Disponveis (QtdRD): quantidade de
profissionais disponveis para trabalhar no projeto. a contabilizao do
tamanho da equipe. O gerente de projeto deve verificar quais os recursos que
esto disponveis o tempo todo (full time) e quais os que esto parcialmente
alocados (part time) e contabilizar atravs da quantidade horas/dia
disponveis;
Carga Horria de Trabalho por Dia (VlrJTRAB): verificar junto equipe ou
ao setor de recursos humanos qual a jornada de trabalho dos profissionais, ou
seja, quantas horas por dia eles trabalham ou esto alocados no projeto;
Estimativa de Esforo: estimativa do esforo, em horas, para execuo do
projeto.
Artefato(s) de Sada
Estimativa de Prazo: estimativa, em dias, para execuo do projeto. Prazo
estimado para concluso de todo o projeto.
n
CUSTO = ESFxP ( Papel ) xVlrHORA ( Papel ) , onde:
i =1
Tabela 7.5 Percentual de esforo por papel, presente no plano de medio de referncia, aba
medidas derivadas, ProMePE, adaptado de (PADUA, 2009).
Papel Percentual de Esforo
Gerente de Projeto 10 15%
Analista de Sistemas 15 20 %
Projetista/Arquiteto 15 20%
Desenvolvedor 25 30 %
Testador 10 15%
123
A atividade Aplicar e Analisar Medidas composta por duas tarefas: Executar Medio
e Analisar Medio, Figura 7.5.
A tarefa Avaliar Medio, nica que compe a corrente atividade, Figura 7.6, tem por
objetivo, entre outros, avaliar as medidas, indicadores e resultados das anlises ao final
do projeto.
9
Os indicadores sero calibrados ao final de cada projeto.
126
Etapas
A seguir esto descritas as etapas para execuo da tarefa:
Determinar a eficcia dos produtos medidos, ou seja, avaliar o processo de
medio em relao performance (processo oneroso), concordncia e
maturidade;
127
anlise para os principais interessados (equipe e alta gerncia, por exemplo). O Plano
de Medio tambm prev o planejamento dos mecanismos de divulgao dos
resultados.
RDef.7 Avaliao do Programa de Medio
O ProMePE suporta a tarefa Avaliar Processo de Medio onde realizado uma
anlise crtica do programa de medio do projeto com as lies aprendidas
Sim
provenientes da execuo do processo. Alm disso, as medidas podem ser calibradas
para servir de base histrica para os prximos projetos.
Categoria: Requisitos para Implantao de Processo para MPES
RImpl.1 Custo Compatvel
O ProMePE foi projetado com tarefas e artefatos que podem ser executados sem que a
empresa invista em ferramentas caras ou em treinamentos. O custo para implantar o
ProMePE diz respeito ao esforo necessrio para gerenciamento das medidas, por
Parcial parte do gerente, custo esse que est embutido dentro da implantao de qualquer
processo, ou seja, a empresa possui um maior esforo para ter um processo definido,
mas, em compensao, ganha os benefcios do desenvolvimento de software de forma
controlada e minizando os riscos.
RImpl.2 Rpida Implantao e Entendimento
O ProMePE tenta ser auto-explicativo, mostrando claramente como as tarefas devem
ser executadas e como as medidas devem ser calculadas e portanto pretende-se que o
Parcial
esforo necessrio para implant-lo e execut-lo seja compatvel com a realidade das
MPES.
RImpl.3 Alto Grau de Flexibilidade
O ProMePE prope uma sequncia de atividades e tarefas que precisam ser
executadas para implantao de um processo de medio dentro da empresa. Algumas
tarefas, como as de estimativas, por exemplo, podem no ser executadas, porm isso
Parcial pode acarretar prejuzo em relao ao reuso das informaes contidas no Plano de
Medio de Referncia e em relao comparao do planejado com o efetivamente
realizado. A flexidade do ProMePE no est nas atividades, mas sim no conjunto de
medidas que podem ser definidas de acordo com o perfil de cada empresa.
RImpl.4 Quantidade de Documentao Compatvel
O ProMePE prope um conjunto mnimo de artefatos cujo papel principal para
execuo o gerente de projeto. Por possibilitar o reuso do Plano de Medio e do
Documento de Coleta e Anlise dos Dados, o ProMePE foi construdo com o intuito
Sim de minimizar a quantidade de documentos. Um fato que deve ser levado em
considerao que dependendo da quantidade de medidas definidas no Plano de
Medio, os documentos podem se tornar mais complexos e consequentemente mais
onerosos para a empresa.
RImpl.5 Voltado para os Objetivos de Negcio
Sim O ProMePE foi construdo utilizando da abordagem top-down, onde a definio das
130
De acordo com a anlise do ProMePE frente aos requisitos pode-se observar que
o ProMePE atende de forma integral maioria dos requisitos e de forma parcial a uma
minoria.
A seguir, Tabela 7.7, sero descritas como foi realizado o mapeamento entre o Modelo
de Processo de Medio do PSM e o Processo de Medio, ProMePE, aqui proposto,
para cada uma das atividades consideradas no Modelo de Processo de Medio do PSM.
O objetivo desse mapeamento mostrar que o processo aqui proposto, o
ProMePE, adere integralmente ao Modelo de Processo de Medio PSM.
Pr-Condies
Estabelecer o Compromisso Organizacional
Planejamento de Recursos
Atividade Tarefa Artefato de Entrada Artefato de Sada
Planejar Desenvolver Plano de
Plano de Medio
Medio Medio
Outline de Caso de Uso
Estimativa de
Estimar Tamanho Plano de Medio
Tamanho
Requisitos No-Funcionais
Estimativa de Tamanho
Estimativa de
Estimar Esforo Produtividade
Esforo
Plano de Medio
Estimativa de Esforo
Aplicar
Quantidade de Recursos
Estimativa Estimativa de
Estimar Prazo Humanos
Prazo
Carga Horria de Trabalho
Plano de Medio
Estimativa de Esforo
Valor da Jornada de Estimativa de
Estimar Custo
Trabalho Custo
Plano de Medio
Plano de Medio
Estimativa de Tamanho Documento de
Executar Medio Estimativa de Esforo Coleta e Anlise de
Aplicar e
Estimativa de Prazo Dados
Analisar
Medidas Estimativa de Custo
Documento de
Documento de Coleta e
Analisar Medio Coleta e Anlise de
Anlise de Dados
Dados
Plano de Medio
Plano de Medio
Plano de Medio de
Avaliar Processo de Referncia
Avaliar Medio Referncia
de Medio Relatrio de
Documento de Coleta e
Avaliao
Anlise de Dados
Figura 7.7 Viso Geral do ProMePE
8.1 Introduo
Resultado da Entrevista
3 3
0 0
Dentre os cinco projetos do GREat, com parceria com empresas, em apenas um foi
possvel a aplicao do ProMePE, devido principalmente confidencialidade das
informaes dos demais projetos. O projeto escolhido est em desenvolvimento h mais
de trs anos e atualmente se encontra na fase de testes e implantao, com prazo para
concluso no final de fevereiro de 2010. O fato de o projeto estar em fase de concluso,
no inviabiliza a sua utilizao nesse estudo de caso. Isso se d pelo fato de que o
137
10
O consultor para a implantao do processo foi a autora deste trabalho.
138
Tabela 8.2 Apresentao parcial da seo Medidas Base do Plano de Medio do Projeto
Necessidade de Informao Medidas Base Unidade de Medio
Datas do inicio do planejamento dias
Datas do fim do planejamento dias
Quantas tarefas esto atrasadas?
Datas do inicio real dias
Datas do fim real dias
Produtividade da Equipe (PROD) horas/tamanho
Tabela 8.6 Apresentao parcial da seo Procedimento Anlise dos Dados do Plano de
Medio do Projeto
3. Porcentagem de
Semanalmente Todas Gerente de Projeto MS Project/Excel
Concluso das Tarefas
FF= 690
Tabela 8.7 Apresentao Parcial da Classificao das Transaes por Caso de Uso, presente
na Planilha de Coleta e Anlise dos Dados
TED TSD TCD TEX TPD
Caso de
Complexidade Complexidade Complexidade Complexidade Complexidade Tamanho
Uso
BaixaMdiaAltaBaixaMdiaAltaBaixaMdiaAltaBaixaMdiaAltaBaixaMdiaAlta
UC1 1 2,67
UC2 4 1 20,47
UC3 4 1 20,47
UC4 3 1 1 1 20,47
UC5 3 1 1 16,91
UC6 3 1 1 19,58
UC7 3 2 1 24,03
UC8 3 1 1 16,91
UC9 2 1 11,57
UC10 1 1 3 1 28,48
0 5 3 5 0 3 5 0 3 0 24
+,)
Caracterstica Peso
Processamento Distribudo 0
Desempenho 5
Eficincia do Usurio 3
Processamento Complexo 5
Reusabilidade 0
Facilidade de Instalao 3
Usabilidade 5
Portabilidade 0
Facilidade de Manuteno 3
Concorrncia 0
Tabela 8.10 Apresentao Parcial de estimativa de esforo por caso de uso e disciplina,
planilha de Anlise e Coleta de Dados, seo Esforo
=>13 -1._=323.@A32
#
+,)
<
=>13DEFGHIGE -1_=323._=323.@A32
+,)
=>13HJIK -1_2-L_-L.@A32
+,)
Tabela 8.16 Apresentao parcial da quantidade de defeitos encontrados no projeto por caso
de teste, seo defeitos da planilha de coleta e anlise dos dados
Porcentagem de
Defeito por
Casos de Testes Qtd. de Defeitos Tamanho de UC
CT1 26 0%
CT2 8 4%
CT3 0 0%
CT4 3 1%
CT5 1 0%
CT6 13 11%
CT7 2 0%
CT8 2 0%
CT9 5 22%
Porcentagem de Tarefas
39% Pendentes (%)
61% Porcentagem de Tarefas
Concludas (%)
350
Planejado
300
250 Esforo Mensal
200 Executado do Projeto
150 Critrio de Deciso
100 +20%
50 Critrio de Deciso -20%
0
out nov dez
Figura 8.4 Esforo do projeto no perodo: realizado x planejado, seo Esforo da Planilha
de Coleta e Anlise dos Dados
10%
0%
Contrato 1 Contrato 2 Contrato 3 Varincia
-10%
-20%
-30%
Figura 8.5 Varincia de Esforo entre o realizado e o previsto no contrato, seo Esforo,
Planilha de Coleta e Anlise dos Dados
153
10000
Esforo (horas)
8000
2000
0
Contrato 1 Contrato 2 Contrato 3
Figura 8.6 Esforo Previsto no Contrato x Realizado, seo Esforo, Planilha de Coleta e
Anlise dos Dados
Como resultado da anlise das medidas derivadas de custo (estimativa de custo
total previsto no contrato e custo real do projeto) ilustrado na Figura 8.7, nota-se que
o custo gasto na realizao do projeto foi maior que o custo pago pela empresa
contratante em todos os contratos. Apesar dos grficos anteriores, de esforo, apontarem
que o esforo realizado foi menor do que o previsto nos contratos, o valor pago pelos
contratos foi baixo comparado com o valor pago para os profissionais. Isso se deve
principalmente pelo enorme retrabalho que a equipe teve com as mudanas de requisitos
solicitadas pelo contratante, constatado e detalhado posteriormente.
Se esse controle tivesse sido realizado durante todo o perodo de execuo do
projeto, tanto o gerente de projeto como a alta gerncia poderiam ter tomado alguma
deciso em relao viabilidade de continuidade do projeto a partir do contrato 1
154
quando claramente percebe-se o seu prejuzo financeiro, mais do que os 20% previsto
como critrio de deciso.
Previsto Realizado
Critrio de Deciso +20% Critrio de Deciso -20%
Figura 8.7 Custo do Projeto por Contrato, seo custo da Planilha de Coleta e Anlise dos
Dados
A Figura 8.8 exibe a comparao entre o valor pago pela contratante (todos os
trs contratos) e o custo real do projeto para o GREat, o que corresponde a um prejuzo
financeiro de aproximadamente 72 mil reais.
Custos do Projeto
R$ 263.205,00
R$ 191.542,77
Custo Pago pela Contratante Custo Real do Projeto (RH) Prejuzo (RH)
(RH)
R$ 71.662,23
Figura 8.8 Comparao Custo Total do Projeto, seo custo da Planilha de Coleta e
Anlise dos Dados
155
5000
4000
3000
Esforo Estimado
2000 Acumulado
1000
Figura 8.9 Esforo estimado acumulado para mudana de requisitos, seo estabilidade de
requisitos, Planilha de Coleta e Anlise de Dados
Para o controle dos defeitos, Figura 8.10, o gerente de projeto verificou que para
alguns casos de uso a taxa de defeito foi elevada quando comparado com o tamanho de
cada caso de uso (medida derivada porcentagem de defeito por caso de uso). A taxa
de defeito por caso de uso poder ser utilizada tambm em projetos futuros para anlise
e acompanhamento da quantidade de defeitos encontrados. Essa medida servir para
acompanhar o trabalho dos desenvolvedores responsveis pelo desenvolvimento de cada
caso de uso. A quantidade de defeitos encontrados por caso de uso pode ser um indcio
156
da m qualidade do cdigo produzido, o que pode ter como causa inmeros fatores que
precisam ser analisados, como por exemplo, elevada presso para o desenvolvimento do
caso de uso e inexperincia do desenvolvedor.
25%
20%
15%
10%
5%
0%
CT1 CT2 CT3 CT4 CT5 CT6 CT7 CT8 CT9
Figura 8.10 Taxa de Defeito por Tamanho de UC, seo defeitos da Planilha de Coleta e
Anlise de Dados
A anlise dos dados mostrou que o projeto enfrentou problemas durante sua
execuo, o que ocasionou um elevado prejuzo final para o GREat. Os demais
grficos que possibilitam a anlise das outras medidas derivadas no citadas aqui
esto disponveis no APNDICE C.
Medio de Referncia para ser instanciado para os projetos, este plano foi largamente
modificado para atender lista de necessidades do projeto e para tanto, despendeu cerca
de uma semana para ser ajustado.
Outro ponto que merece destaque foi a ausncia de algumas informaes para as
medidas, discutidas ao longo da aplicao do processo, que tambm despendeu tempo
do gerente de projeto e do consultor. A coleta de algumas medidas retroativas
mostraram apenas estimativas, que podem no ser efetivas, podendo levar a uma anlise
errnea dos dados. Mesmo com essas dificuldades, as medidas serviram de guia para o
gerente e alta gerncia, j que anteriormente eles no possuam essas informaes.
Apesar das dificuldades enfrentadas, o gerente, equipe e alta gerncia acharam
que o processo de medio trouxe benefcios para a empresa. Atravs dele foi possvel
acompanhar mais de perto o andamento do projeto e tomar decises baseadas em dados
reais. Com o clculo de estimativas mais precisas, o grupo ter uma menor
probabilidade de atrasos em seus cronogramas e consequentemente poder gerenciar
melhor suas finanas. Se tivesse tido, desde o incio, um acompanhamento mais
profundo do projeto atravs do uso de medio, muitas aes poderiam ter sido
evitadas, como a elevada mudana de requisitos e o elevado custo do projeto para a
empresa.
A comunidade de software vem, nos ltimos anos, tentando introduzir nas MPES a
melhoria do processo de software de forma a torn-las mais produtivas e competitivas
no mercado e um dos passos importantes para essa melhoria contnua a medio.
Medir o software significa, alm de obter informaes quantitativas, analis-las e tomar
as iniciativas apropriadas para corrigir possveis desvios durante a execuo do projeto.
Alm disso, medir o software significa obter dados histricos dos projetos para auxiliar
na constante melhoria do processo de desenvolvimento e na tomada de decises futuras.
A estimativa a base para a medio e juntamente com a coleta de dados reais
permite o controle quantitativo do que est sendo produzido. Ao medir o projeto
possvel acompanhar de forma mais efetiva o seu andamento e assim, minimizar os
riscos de insucesso e tomar as decises necessrias para mitigar possveis riscos antes
que esses se tornem crticos.
A medio um importante processo de apoio para o controle do
desenvolvimento do software e, por isso, existem algumas abordagens que auxiliam na
definio de um processo de medio, seja atravs de modelos de processos com boas
prticas de medio ou atravs de tcnicas que auxiliam na definio das medidas de
acordo com os objetivos de negcio das empresas.
A grande parte dessas abordagens so voltadas para atender grandes
organizaes, entretanto, elas representam a minoria das empresas de desenvolvimento.
As MPES, por outro lado, constituem cerca de 77% das empresas de desenvolvimento
de software do Brasil e, portanto, merecem ateno em todas as reas que compem o
ciclo de vida do software, em especial, as reas de estimativa e medio.
Existem atualmente inmeras tcnicas para estimar software. Algumas delas so
simples demais, baseadas na experincia do gerente ou da equipe, e outras mais
robustas, baseadas de forma mais objetiva na quantidade e qualidade dos requisitos,
porm, quando aplicadas para MPES podem despender custo de aprendizado e de
aplicao.
Para construir a base desse trabalho, inicialmente, foi realizado um estudo dos
trabalhos relacionados na rea de estimativa e de medio de software. Com o estudo,
observou-se que muitos trabalhos possuam caractersticas similares e com isso foi
definido um conjunto de requisitos para definio e implantao de processo de
161
medio nas MPES. Cada um dos requisitos foi comparado com os trabalhos
relacionados com a finalidade de realizar uma anlise crtica deles frente aos requisitos.
Com isso, observou-se que os trabalhos relacionados no atendiam, por completo, ao
conjunto de requisitos especificados.
Em muitas abordagens utilizadas na literatura, costuma-se separar a elaborao
de estimativas da definio do processo de medio. Entende-se que estimar uma
forma de medir, ento, devido a carncia de utilizao nas MPES tanto de estimativas
quanto de medies em conjunto com a definio de medidas simples que comparam o
planejado com o realizado, surgiu a necessidade de propor um processo para medio
que atendesse desde o clculo das estimativas at a coleta de medidas reais.
Para propor o processo de medio alguns itens foram analisados: o conjunto de
requisitos especificados e a similaridade entre os processos e tcnicas de estimativas.
Como forma de padronizar e possibilitar o reuso de infomaes com foco nas MPES,
foi documentado um conjunto de padres de estimativas. A linguagem de padres de
estimativa traz uma forma de estimar software orientado a requisitos, independente de
plataforma de desenvolvimento e voltado a atender as MPES.
A partir dos padres foi, ento, definido o processo simplificado de medio de
software para as MPES, ProMePE, que fornece pontos essenciais para o incio do
processo de medio nesse nicho de mercado. O ProMePE foi construdo seguindo as
boas prticas de medio definidas no PSM e atende de forma geral ao conjunto de
requisitos especificados.
Portanto, este trabalho de dissertao apresenta as seguintes contribuies
principais:
Levantamento e documentao de um conjunto de requisitos para a construo e
implantao de um processo de medio de software especfico para Micro e
Pequenas Empresas;
Documentao de boas prticas de estimativa de software na forma de uma
linguagem de padres;
Construo de um processo de medio de software simplificado para Micro e
Pequenas Empresas com aderncia ao PSM.
Com isso, espera-se contribuir com pesquisas relacionadas rea de melhoria de
processo de software para MPES, ao propor um processo de medio simplificado e
com o objetivo de facilitar a implantao de atividades de estimativa e medio e
permitir o amadurecimento de empresas desse tipo.
162
REFERNCIAS BIBLIOGRFICAS
ALUR, D.; CRUPI, J.; MALKS, D. Core J2EE Patterns: Best Practices
and Design Strategies. [S.l.]: Prentice Hall, 2003.
IFPUG. Function Point Counting Practices Manual. 4.1. ed. [S.l.]: [s.n.],
1999.
Seo Descrio
Histrico de Revises Histrico de alteraes do plano
Lista das Necessidades de Informao Objetivos da medio de acordo com o perfil do projeto
Descrio das Medidas Base Medidas simples, com uma funo
Descrio das Medidas Derivadas Medidas derivadas das medidas base, mais de uma funo
Referncias
<Coloque aqui as referncias utilizadas>
172
Histrico de Revises
Qual a estimativa de custo total de projeto Porcentagem de Esforo por Papel (P) %
comparado com o realizado? Valor da Hora de Trabalho por Papel (VlrHORA) reais
Quantidade de Recursos humanos no projeto (QtdRD) 1. Estimativa de Prazo Total (EPRZ) 1. EPRZ = (ESF)/SOMA(QtdRDxVlrJTRAB)
Tabela 1 - Fatores Tcnicos Funcionais (FF) Tabela 2 - Fatores Tcnicos No-Funcionais (FTNF)
1. Qtd Defeito por Requisito Mensalmente Todas Equipe e Gerente de Projeto Excel
2. Qtd Requisitos Corrigidos no perodo Mensalmente Todas Equipe e Gerente de Projeto Excel
1. % Requisitos em Crescimento
Qual a estimativa de esforo por caso de uso para Estimativa de Tamanho por Caso de Uso (ETT_CASO_USO) inteiro
cada disciplina comparado com o realizado? Porcentagem de Esforo por disciplina (P_ESF) %
Qual a estimativa de esforo comparado com o Esforo planejado no perodo horas
realizado no perodo? Esforo realizado no perodo horas
Qual a estimativa de prazo total do projeto
Esforo total previsto nos contratos (ESF_CONTRATO) horas
comparado com o realizado?
Esforo estimado total (ESF) horas
Quantidade de Recursos humanos no projeto (QtdRD) inteiro
Qual a estimativa de prazo total do projeto Carga horria diria de cada recurso (VlrJTRAB) horas/dia
comparado com o realizado?
Quantidade total de horas realizadas pela equipe (ESF_REAL) horas
187
Porcentagem de Esforo por disciplina 5. Estimativa de Esforo de cada caso 5. ESF_DISP = PRODxETT_CASO_USOxP_ESF. Utilizar porcentagem por disciplina
(P_ESF) de uso por disciplina (ESF_DISP) presente na Tabela 5
189
Quantidade de requisitos modificados 1. % Requisitos Modificados 2. (Qtd Requisitos Modificados/Qtd Total de Requisitos Aprovados)x100
Quantidade total de defeitos 1. Qtd Defeito por caso de uso 1. Soma da quantidade de defeitos por caso de uso
Gerente de Projeto 4%
Projetista 0%
Arquiteto 0%
Desenvolvedor 49%
Testador 0,00%
6. Quant. de horas previstas no contrato 1 vez No incio do projeto Gerente de Projeto Excel
1. Qtd Defeito por caso de uso Mensalmente Todas Equipe e Gerente de Projeto Excel
Incio do Projeto
5. Estimativa de Esforo de
ou quando
cada caso de uso por disciplina Todas Gerente de Projeto Excel No possui
houver mudana
(ESF_DISP)
de requisitos
194
1. Estimativa de Esforo
Total do Projeto (ESF)
Divulgao da Planilha de Anlise dos
Todos os membros do projeto Mensalmente Gerente de Projeto
2. Total de Horas Dados. Seo Esforo
Trabalhadas durante o
projeto no perodo
APNDICE C ProMePE: Planilha de Coleta e Anlise dos Dados do Projeto (Estudo de Caso)
Progresso do Cronograma no Perodo
25
Qtd de Tarefa
20
Critrio de Deciso -15%
15 Critrio de Deciso +15%
0
out nov dez
198
Tamanho Funcional
Passo 1
Separar o projeto por funcionalidades e determinar a quantidadade de transaes por complexidade
TED TSD TCD TEX TPD Tamanho
Caso de Uso Complexidade Complexidade Complexidade Complexidade Complexidade
Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta
UC1 1 2,67
UC2 4 1 20,47
UC3 4 1 20,47
UC4 3 1 1 1 20,47
UC5 3 1 1 16,91
UC6 3 1 1 19,58
UC7 3 2 1 24,03
UC8 3 1 1 16,91
UC9 2 1 11,57
UC10 1 1 3 1 28,48
UC11 3 1 1 1 21,36
UC12 3 1 1 16,91
UC13 3 4 7 1 66,75
UC14 4 1 1 1 23,14
UC15 1 1 1 11,57
UC16 4 1 1 19,58
UC17 3 1 1 1 21,36
UC18 3 1 1 1 21,36
UC19 3 1 1 1 24,92
UC20 1 1 1 1 17,8
UC21 3 2 1 1 25,81
UC22 1 1 1 3 27,59
UC23 3 1 4 28,48
199
Passo 1 - Continuao
Separar o projeto por funcionalidades e determinar a quantidadade de transaes por complexidade
TED TSD TCD TEX TPD Tamanho
Caso de Uso Complexidade Complexidade Complexidade Complexidade Complexidade
Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta Baixa Mdia Alta
UC24 3 1 8 56,96
UC25 1 1 1 8,9
UC26 1 1 2 14,24
UC27 2 1 1 11,57
UC28 2 1 2 14,24
Passo 2
Calcular o valor das Funcionalidade (FF)
Grupos de Transaes Complexidade Peso Quantidade Valor
Baixa 3 53 159
TED Mdia 4 20 80
Alta 6 4 24
Baixa 4 7 28
TSD Mdia 5 13 65
Alta 7 3 21
Baixa 3 18 54
TCD Mdia 4 8 32
Alta 6 11 66
Baixa 5 0 0
TEX Mdia 7 0 0
Alta 10 0 0
Baixa 7 23 161
TPD Mdia 10 0 0
Alta 15 0 0
FF = 690
200
Passo 3
Calcular os Fatores Tcnicos No- Funcionais (FTNF)
Caracterstica Nota
Processamento Distribudo 0
Desempenho 5
Eficincia do Usurio 3
Processamento Complexo 5
Reusabilidade 0
Facilidade de Instalao 3
Usabilidade 5
Portabilidade 0
Facilidade de Manuteno 3
Concorrncia 0
FTNF = 0,89
ETT = 614,1
201
Esforo do Projeto
Ano 2009
Esforo no Perodo
out nov dez
Esforo Mensal Planejado 320 320 320
Esforo Mensal Planejado Acumulado 320 640 960
Esforo Mensal Executado do Projeto 220 233 280
Esforo Mensal Executado Acumulado 220 453 733
Esforo Mensal Previsto no Contrato 160 160 160
Critrio de Deciso +20% 384 384 384
Critrio de Deciso -20% 256 256 256
203
Esforo em Horas
300
250 Esforo Mensal
Executado do Projeto
200
150 Critrio de Deciso +20%
100
50 Critrio de Deciso -20%
0
out nov dez
204
Papel Qtd. nov/07 dez/07 jan/08 fev/08 mar/08 abr/08 mai/08 jun/08 jul/08 ago/08 set/08 out/08 Total
Coordenador 1 8 8 8 8 8 8 8 8 8 8 8 8 96
Gerente de Projeto 1 160 160 160 160 160 160 160 160 160 160 160 160 1920
Desenvolvedor 3 160 160 160 160 160 160 160 160 160 160 160 160 5760
Esforo Total Previsto no Contrato 2 no Perodo (horas) 7776
Papel Qtd. mar/09 abr/09 mai/09 jun/09 jul/09 ago/09 set/09 out/09 nov/09 dez/09 jan/10 Total
Coordenador 1 8 8 8 8 8 8 8 8 8 8 8 88
Gerente de Projeto 1 160 160 160 160 160 160 160 160 160 160 160 1760
Desenvolvedor 2 160 160 160 160 160 160 160 160 160 160 160 3520
Esforo Total Previsto no Contrato 3 no Perodo (horas) 5368
Papel Qtd. nov/06 dez/06 jan/07 fev/07 mar/07 abr/07 mai/07 jun/07 jul/07 ago/07 set/07 out/07
Coordenador 1 8 8 8 8 8 4 4 4 4 4 4 4
Gerente de Projeto 0 0 0 0 0 0 0 0 0 0 0 0 0
Desenvolvedor 2 160 160 160 160 160 80 80 80 80 80 80 80
Analista 1 160 160 160 160 160 80 80 80 80 80 80 80
Esforo Total Realizado no Perodo do Contrato 1 (horas)
Papel Qtd. nov/07 dez/07 jan/08 fev/08 mar/08 abr/08 mai/08 jun/08 jul/08 ago/08 set/08 out/08
Coordenador 1 8 8 8 8 8 8 8 8 8 8 8 8
Gerente de Projeto 0 0 0 0 0 0 0 0 0 0 0 0 0
Desenvolvedor 2 120 120 120 120 120 120 120 120 120 120 120 120
Analista 2 160 160 160 160 160 160 160 160 160 160 160 160
Esforo Total Realizado no Perodo do Contrato 2 (horas)
Papel Qtd. mar/09 abr/09 mai/09 jun/09 jul/09 ago/09 set/09 Total
Coordenador 1 4 4 4 4 4 4 4 28
Gerente de Projeto 1 40 40 40 40 40 40 40 280
Analista/Desenvolvedor 2 160 160 160 160 160 160 160 2240
Desenvolvedor 2 80 80 80 80 80 80 80 1120
Esforo Total Realizado no Perodo do Contrato 3 (horas) 3668
206
8000
5%
6000 Previsto no Contrato 0%
Realizado -5% Contrato 1 Contrato 2 Contrato 3 Varincia
4000
-10%
2000 -15%
-20%
0
-25%
Contrato 1 Contrato 2 Contrato 3
-30%
207
Custo do Projeto
Custos Valores
Estimativa de Custo (RH) R$ 276.135,00
Custo Pago pela Contratante (RH) R$ 191.542,77
Custo Real do Projeto (RH) R$ 263.205,00
Prejuzo (RH) R$ 71.662,23
208
Esforo Estimado
Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo
Caso % para Mudana -
para Mudana - para Mudana - para Mudana - para Mudana - Total para Estimado
de Uso Mudana Gerencia de
Requisitos Anlise e Projeto Implementao Testes Mudana Acumulado
Projeto
UC1 0% 0 0 0 0 0 0 0
UC2 50% 40,94 40,94 71,645 30,705 20,47 205 205
UC3 50% 40,94 40,94 71,645 30,705 20,47 205 409
UC4 80% 65,504 65,504 114,632 49,128 32,752 328 737
UC5 0% 0 0 0 0 0 0 737
UC6 30% 23,496 23,496 41,118 17,622 11,748 117 854
UC7 100% 96,12 96,12 168,21 72,09 48,06 481 1335
UC8 0% 0 0 0 0 0 0 1335
UC9 10% 4,628 4,628 8,099 3,471 2,314 23 1358
UC10 80% 91,136 91,136 159,488 68,352 45,568 456 1814
UC11 80% 68,352 68,352 119,616 51,264 34,176 342 2156
UC12 20% 13,528 13,528 23,674 10,146 6,764 68 2223
UC13 80% 213,6 213,6 373,8 160,2 106,8 1068 3291
UC14 50% 46,28 46,28 80,99 34,71 23,14 231 3523
UC15 0% 0 0 0 0 0 0 3523
UC16 0% 0 0 0 0 0 0 3523
UC17 50% 42,72 42,72 74,76 32,04 21,36 214 3736
UC18 0% 0 0 0 0 0 0 3736
UC19 0% 0 0 0 0 0 0 3736
UC20 20% 14,24 14,24 24,92 10,68 7,12 71 3807
UC21 0% 0 0 0 0 0 0 3807
UC22 0% 0 0 0 0 0 0 3807
UC23 0% 0 0 0 0 0 0 3807
210
Esforo Estimado
Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo Estimado Esforo
Caso % para Mudana -
para Mudana - para Mudana - para Mudana - para Mudana - Total para Estimado
de Uso Mudana Gerencia de
Requisitos Anlise e Projeto Implementao Testes Mudana Acumulado
Projeto
Defeitos do Projeto
- Critrio de Deciso do Progresso do Cronograma de apenas 15% foi baixo para esse tipo de
projeto;
- Utilizar o processo desde o incio de um projeto ajuda a consolidar as medidas e facilita na
posterior anlise dos dados, sem ambiguidade;
- Como a alta gerncia queria realizar medies relativas aos contratos, o processo ficou
oneroso devido busca constante de informaes retroativas;