\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2012-05-15 (revised: 15 May 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-05-15}
\title{}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Dr.EVERTON CASTELAfO  TETILA}

             \author[2]{MAURO DE MESQUITA  SPANOLA}

             \affil[1]{  UFGD}

\renewcommand\Authands{ and }

\date{\small \em Received: 9 April 2012 Accepted: 30 April 2012 Published: 15 May 2012}

\maketitle


\begin{abstract}
        


The competition between organizations that develop software is increasing with the growth of the market in technology of the information, as consequence the organizations has concerned more and more with the improvement of the quality of itts products of software, with the effective costs and with the fulfillment of terms of its projects. To obtain these characteristics, the software development trials require a more effective management, with a well definite project plan based in accurate estimative. In that way, this work proposes through bibliographical hoist and field research, create a software estimative trial to support the management of projects during the cycle of development. This trial consists the use case points metric as a tool of estimative, in the estimative management trials proposed by the pmbok and in the estimative of development activities proposed by the rup. The results of the action research demonstrate that, in average, the software estimative trial with use case points is 4.3% more precise than the traditional estimative metrics (function points and use case points) without estimative formal trial.

\end{abstract}


\keywords{metrics of software; Use Case Points; PMBOK; RUP.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 \par
Processo De Estimativa De Software Com a Métrica Use Case Points, Pmbok E Rup Everton Castelão Tetila (UFGD) ? , Fábio Iaione (UFGD) ? , Ivanir Costa (USP) ? , Juliana Queiroz Da Silva Tetila (UEMS) ? , Mauro De Mesquita Spínola (USP) ¥ Resumo -A competição entre organizações que desenvolvem software vem aumentando com o crescimento do mercado de TI, como conseqüência as organizações têm se preocupado cada vez mais com a melhoria da qualidade dos produtos de software, com os custos efetivos e com o cumprimento dos prazos de seus projetos. Para obter estas características, os processos de desenvolvimento de softwares vêem exigindo um gerenciamento mais efetivo, com um plano de projeto bem definido, baseado em estimativas mais precisas. Nesse sentido, este trabalho propõe, por meio de levantamento bibliográfico e pesquisa de campo, criar um processo de estimativa de software para apoiar a gerência de projetos durante o ciclo de desenvolvimento. Este processo consiste no uso da métrica Use Case Points como ferramenta de estimativa, nos processos de gestão de estimativas do PMBOK e nas atividades de estimativas do RUP. Os resultados da pesquisa demonstraram que, em média, o processo de estimativa de software com Use Case Points é 4,3\% mais preciso que as métricas de estimativas tradicionais (Function Points e Use Case Points) sem processo formal de estimativas.\par
Palavras-chaves : métricas de software; Use Case Points; PMBOK; RUP.\par
Abstract -The competition between organizations that develop software is increasing with the growth of the market in technology of the information, as consequence the organizations has concerned more and more with the improvement of the quality of itts products of software, with the effective costs and with the fulfillment of terms of its projects.\par
To obtain these characteristics, the software development trials require a more effective management, with a well definite project plan based in accurate estimative. In that way, this work proposes through bibliographical hoist and field research, create a software estimative trial to support the management of projects during the cycle of development. This trial consists the use case points metric as a tool of estimative, in the estimative management trials proposed by the pmbok and in the estimative of development activities proposed by the rup. The results of the action research demonstrate that, in average, the software estimative trial with use case points is 4.3\% more precise than the traditional estimative metrics (function points and use case points) without estimative formal trial.\par
I. 
\section[{INTRODUÇÃO}]{INTRODUÇÃO}\par
onforme pesquisa da Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), o setor de TI encerrou 2009 com crescimento de 9,3\% e uma receita anual aproximada de R\$ 52,8 bilhões. Para 2010, a entidade que desenvolve pesquisas para o Ministério da Ciência e Tecnologia, estima um movimento de R\$ 57,7 bilhões e uma repetição do nível de crescimento, acima de 9\% (SOFTEX, 2009).\par
Em conseqüência desta realidade, as organizações que desenvolvem software têm buscado desenvolver sistemas dentro do prazo e do orçamento previstos e com um nível de qualidade adequada. Todas estas características dependem de um gerenciamento de projeto eficiente e eficaz. Nesse gerenciamento, é essencial a adoção de guias e de um plano de projeto que englobe os requisitos de qualidade do produto exigidos pelo cliente e que seja baseado em estimativas precisas de tamanho, esforço, prazos e custos  {\ref (PMBOK, 2008)}.\par
O tamanho do software é um indicador da quantidade de trabalho a ser executado no desenvolvimento de um projeto. Esta dimensão constitui a base para a derivação das estimativas de esforço, custos e prazos necessários para a definição do plano de desenvolvimento do software \hyperref[b2]{(CMMI, 2007)} A precisão de estimativas de tamanho, no entanto, é dependente de informações que nem sempre estão disponíveis no início dos projetos (exemplo: número de linhas de código, número de operadores e operandos, número de pontos de função). Essas informações são essenciais para realizar as estimativas, pois elas que vão auxiliar a discussão de contratos ou a determinação da viabilidade do projeto, em termos de análise de prazos, custos e recursos.\par
Uma outra questão refere-se à falta de padrões quando se aplicam as estimativas. Não se tem conhecimento na literatura sobre a existência de um modelo, guia ou processo que auxilie o trabalho de executar estimativas e avalie o seu percentual de erro em relação aos resultados obtidos e que oriente a melhoria das estimativas ao longo do tempo.\par
Nesse sentido, o presente trabalho define um Processo de Estimativa de Software, baseado na métrica Use Case Points, que auxilie o gerente a administrar o ciclo de desenvolvimento do projeto. Isto permite subsidiar o planejamento, comparar e avaliar estimativas, controlar o projeto com mais segurança e providenciar ações de ajustes no plano e no cronograma. Dessa forma, esperam-se reduzir os problemas de gestão, tais como: altos custos, atrasos no cronograma, insatisfação do cliente, dificuldades de medição do andamento do projeto e quebras de contratos. 
\section[{II.}]{II.} 
\section[{METODOLOGIA}]{METODOLOGIA}\par
Conforme \hyperref[b6]{Marconi (2007)}, a presente pesquisa caracteriza-se quanto à sua natureza como científico original, pois é uma pesquisa realizada pela primeira vez que vem contribuir com novas conquistas e descobertas para a evolução do conhecimento científico.\par
Um Processo de Estimativa de Software foi proposto para a pesquisa de excelência. Dez etapas foram sugeridas para a composição deste processo. As etapas foram definidas com base nos processos de gestão de estimativas do PMBOK, nas atividades de estimativas do RUP, e na métrica Use Case Points, utilizada como ferramenta do processo. Para tal, foi investigada a relação existente entre os guias e a métrica e identificadas as ações gerenciais a serem tomadas pelo gerente de projeto durante o Processo de Estimativa de Software.\par
Quanto aos objetivos, segundo Gil (2010), uma pesquisa pode ser classificada em: exploratória, descritiva ou explicativa.\par
A pesquisa exploratória, aplicada neste trabalho, envolve o levantamento bibliográfico, o que proporciona maior familiaridade com o problema, a fim de torná-lo mais explícito. "O levantamento bibliográfico é desenvolvido com base em material já elaborado, constituído principalmente de livros e artigos científicos" (GIL, 2010). Esta pesquisa é a base para a obtenção dos conhecimentos científicos e técnicos para desenvolver o Processo de Estimativa de Software. \hyperref[b6]{Marconi (2007)} informa que uma pesquisa quanto ao objeto pode ser classificada em: bibliográfica, de laboratório e de campo. Uma pesquisa de campo foi realizada com duas instituições de software brasileiras, uma pública e outra privada, para mostrar os conceitos, experimentar as ações do processo e relatar a experiência. Os participantes do estudo desta pesquisa são: os gerentes de projetos das instituições e os autores deste trabalho. Os dados coletados (exemplo: número de funções) foram calculados utilizando-se planilhas eletrônicas para estimar os custos dos projetos de software. Os resultados foram analisados com base na experiência pessoal dos participantes do estudo. As instituições, no entanto, não autorizaram a divulgação de seus nomes, nem de seus projetos, por participarem de concorrências em licitações públicas. 
\section[{III.}]{III.} 
\section[{MÉTRICAS DE SOFTWARE}]{MÉTRICAS DE SOFTWARE}\par
Com a necessidade de medidas que informem a eficiência do desenvolvimento de software, diversas métricas ou métodos de medição foram propostos a fim de minimizar os fracassos dos projetos obtidos, principalmente em relação às falhas no cronograma e orçamento previstos. A seção 3.1 apresenta uma das principais métricas de estimativa de tamanho de software existentes no mercado. 
\section[{a) Use Case Points -UCP}]{a) Use Case Points -UCP}\par
Os Use Case Points (UCP), ou Pontos de Casos de Uso (PCU), foram propostos em 1993, por Gustav Karner, com base nos Function Points (FP), Mark II, e no Modelo de Casos de Uso para determinar estimativas de tamanho de softwares orientado a objetos. Os UCP visam estabelecer uma medida de "tamanho" do software, em PCU, através da quantificação e complexidade das funcionalidades desempenhadas pelo software. Baseia-se na visão do usuário e tem como proposta ser utilizado logo no início do ciclo de desenvolvimento, na fase de definição dos requisitos, com base no modelo de casos de uso.\par
Nesta métrica, KARNER (1993) substitui alguns fatores técnicos propostos pelos FP, cria os fatores ambientais, propõe uma estimativa de produtividade de 20 homens/hora por PCU e explora a medição da funcionalidade do sistema baseado no modelo de casos de uso.\par
A contagem dos UCP se dá sobre dois elementos básicos de um sistema modelado: atores e casos de uso. Cada um desses elementos terá um peso na complexidade do sistema, de acordo com o seu nível de influência. O valor total desses pesos determina o valor total dos PCU não-ajustados. No entanto, esse valor deve ser ajustado em relação aos fatores de complexidade técnica e ambiental que refletem funções que afetam a aplicação de maneira geral.\par
Os fatores de complexidade técnica variam numa escala de 0 a 5, de acordo com o grau de dificuldade do sistema a ser construído: desempenho da aplicação, portabilidade e facilidade de manutenção, são alguns exemplos. Os fatores de complexidade ambiental indicam a eficiência do projeto, numa escala de 0 a 5, e estão relacionados ao nível de experiência dos profissionais e às condições ambientais e de trabalho, como a capacidade do líder de projeto, a motivação da equipe e a experiência com a aplicação de desenvolvimento.\par
Após determinar os fatores de complexidade técnica e ambiental, esses fatores devem ser multiplicados pelos PCU não-ajustados. Dessa forma, são determinados os PCU ajustados do sistema que determinarão as estimativas de esforço, prazo e custos do projeto. Uma vantagem evidente da métrica UCP sobre os FP é que ela utiliza um documento essencial em metodologias dirigidas por casos de uso. Neste sentido, destaca-se o RUP, que usa a UML como linguagem padrão para a elaboração da modelagem de softwares orientado a objetos.\par
Dessa forma, é possível calcular prontamente mudanças nas estimativas do sistema a cada pequena alteração de requisitos, refazendo-se apenas alguns cálculos. Os FP, ao contrário, exigem que novos documentos para o cálculo das estimativas sejam adicionados ao sistema a cada pequena mudança no orçamento, prazo ou requisitos, sendo, dessa forma, pouco flexível às mudanças. Além disso, "os UCP contribuem para a diminuição de algumas dificuldades impostas pelo mercado em relação à resistência de adoção de métricas de estimativa, porque é um método simples, fácil de usar e rápido  {\ref de}  O modelo de transformação é o método utilizado para representar a produção de bens e ou serviços. Qualquer operação produz bens e ou serviços e isto ocorre através do processo de transformação.\par
Pode-se descrever toda e qualquer operação através do sistema entrada-transformação-saída. A produção envolve vários recursos chamados de input, ou entrada, que são usados para transformar ou serem transformados em algo que são os outputs, ou saída, de bens e serviços.\par
O Processo de Estimativa de Software é representado graficamente pelo modelo de transformação, conforme ilustra a Figura 2. Contudo, antes de determinar o orçamento do projeto é necessário estimar os recursos (pessoas, equipamentos ou material) utilizados para a realização das atividades. Além disso, uma previsão das variações que possam ocorrer no decorrer do projeto, como uma previsão para a inflação do período, deve ter sido realizada. Somado esses itens, é possível determinar a estimativa do custo global do projeto.\par
Em relação às restrições (exemplo: o custo não pode exceder R\$ 100.000,00) e prioridades (exemplo: a urgência de um produto) que estão sujeitos a maioria dos projetos, uma variedade de cenários de estimativas podem ser criados à medida que a relação entre tamanho da equipe e prazo é não-linear. Dessa forma, o tamanho da equipe ou o cronograma podem ser ajustados de acordo com restrições e prioridades préestabelecidas. Com a variedade de cenários de estimativas possíveis, o gerente de projeto deve selecionar o cenário que melhor se adapta às necessidades do projeto.\par
No final do projeto, os dados obtidos (exemplo: o tamanho da aplicação em PCU, o esforço de desenvolvimento, os defeitos encontrados) devem ser registrados em uma base de dados mantida pela organização. Estes dados serão úteis para compará-los com outras medidas obtidas de projetos anteriores. Com isso, índices de produtividade, como homens/hora por PCU, R\$ por PCU; e de qualidade, como defeitos por PCU, erros por PCU, podem ser avaliados e tendências podem ser geradas.\par
Por fim, é preciso verificar se as estimativas realizadas no início do projeto estão dentro de um percentual de erro aceitável. Para isto, o gerente deve comparar as estimativas realizadas no início do projeto com os resultados obtidos no final do projeto (output). "Um percentual de erro inferior a 10\% (dez por cento) é aceitável para essa relação" \hyperref[b14]{(TETILA et al., 2006)}. Caso o percentual de erro seja maior que 10\% (em valor absoluto), avaliações devem ser tomadas para que estimativas com maior precisão possam ser realizadas nos próximos projetos. Consistência do Índice de Produtividade, padronização dos PCU, distribuição de atividades e conversão de PCU em prazo, são os principais itens de avaliação.\par
V. 
\section[{PESQUISA DE CAMPO}]{PESQUISA DE CAMPO}\par
Esta seção apresenta a pesquisa de campo realizada com duas conceituadas instituições brasileiras, uma pública e outra privada.\par
Na instituição privada, um projeto de software foi estimado em dezembro de 2004 por Ivanir Costa. Já na instituição pública, dois outros projetos foram estimados por Everton Castelão Tetila -um em fevereiro de 2006 e outro em setembro de 2006.\par
Três formas de aplicação de métricas de estimativas foram utilizadas para estimar o custo de cada projeto de software. Primeiro, cada projeto foi estimado utilizando a métrica Function Points. Logo após, cada projeto foi estimado utilizando a métrica Use Case Points. Finalmente, cada projeto foi estimado utilizando o Processo de Estimativa de Software. As estimativas de cada uma das métricas utilizadas foram comparadas com os resultados obtidos nos finais dos projetos. Assim, o percentual de erro entre a estimativa inicial e resultado obtido foi estabelecido. Os erros calculados para cada uma das métricas utilizadas foram comparados entre si. Isto permitiu compreender melhor o comportamento de cada projeto e avaliar o desempenho das métricas utilizadas. 
\section[{a) Análise e interpretação}]{a) Análise e interpretação}\par
No Projeto 1, realizado pela Instituição privada, os erros de custos obtidos pelas métricas tradicionais (FP e UCP) foram de -9,91\% e -4,47\%, respectivamente. Portanto, são aceitáveis para a relação entre estimativas iniciais e resultados obtidos "um percentual de erro inferior a 10\% (dez por cento) é aceitável para essa relação" \hyperref[b14]{(TETILA et al., 2006)}. Todavia, o erro calculado pode ser expressivo quando se trata de um projeto de grande porte. Isto porque as estimativas realizadas pelas métricas FP e UCP foram inferiores ao custo final do projeto em R\$ 36.828,00 e R\$ 16.630,00, respectivamente.\par
O erro obtido pelo Processo de Estimativa de Software foi de -1,69\%. Isto, em termos de custo, representa R\$ 6.178,00. Porém, o percentual de erro poderia ser ainda menor, já que ocorreram faltas de membros da equipe que não estavam previstas no planejamento do projeto. Fato que desencadeou um esforço de desenvolvimento ligeiramente acima do esperado.\par
É razoável supor que o Processo de Estimativa de Software obteve menor erro que as métricas tradicionais (FP e UCP) porque este considera uma possível variação que as estimativas podem sofrer ao longo do projeto (exemplo: inflação), ao contrário das métricas tradicionais que estimam apenas o custo do software em si. A inflação no período do desenvolvimento do Projeto foi de 2,94\% (5,7\% ao ano). Veja a Tabela 1. No Projeto 2, realizado pela Instituição pública, os erros de custos obtidos pelas métricas tradicionais (FP e UCP) foram de -1,35\% e -5,48\%, respectivamente. O erro de custo obtido pelo Processo de Estimativa de Software foi de -2,59\%. Portanto, os percentuais de erros das três métricas utilizadas foram inferiores ao limite máximo de 10\% (em valor absoluto), aconselhável em \hyperref[b14]{(TETILA et al., 2006)}.\par
O esforço previsto pelas métricas UCP e Processo de Estimativa de Software, estiveram ligeiramente abaixo da realidade nesse projeto, o que acarretou estimativas menos precisas que a métrica FP. Isto ocorreu porque o Índice de Produtividade (IP) da equipe foi um pouco superior ao IP de 20 homens/hora por PCU proposto por \hyperref[b5]{Karner (KARNER, 1993)}.\par
Contudo, o erro de custo obtido pelo Processo de Estimativa de Software foi menor que o erro de custo obtido pela métrica UCP. Dois fatores foram determinantes para isso: (1) o Processo de Estimativa de Software considera a variação das estimativas ao longo do projeto: a inflação no período foi de 2,4\%; (2) o Processo de Estimativa de Software prevê o custo dos recursos alocados: ocorreu treinamento em J2EE (Java 2 Enterprise Edition) durante a realização do projeto.\par
Finalmente, no Projeto 3, realizado pela Instituição pública, os erros de custos obtidos pelas métricas UCP e Processo de Estimativa de Software foram de -3,24\% e 2,45\%, respectivamente. Limites esses também dentro da margem de erro aceitável de 10\% (em valor absoluto).\par
Por outro lado, o erro de custo obtido pela métrica FP foi de -14,22\%, ou seja, superior ao tolerado pela margem de erro. Neste caso, quatro itens devem ser avaliados para que estimativas com maior precisão possam ser realizadas nos próximos projetos. Os itens de avaliação são: consistência do IP, padronização dos PCU, distribuição de atividades, e conversão de PCU em prazo (veja a Figura 2).\par
Em relação ao erro de custo obtido pela métrica FP, três fatores foram determinantes para que esse erro fosse maior que o recomendado: (1) o esforço estimado ficou bem abaixo da realidade: o IP da equipe foi superior ao IP utilizado na métrica; (2) a métrica FP não considera a variação das estimativas ao longo do projeto: durante o desenvolvimento do projeto houve reajustes salariais de três membros da equipe. Além disso, a estimativa de custo deveria ser reajustada em relação à inflação do período, que foi de 2,1\%; (3) a métrica FP não prevê o custo dos recursos alocados: para a realização do projeto, foi necessária a aquisição da ferramenta Rational Functional Tester. 
\section[{b) Discussão dos resultados}]{b) Discussão dos resultados}\par
Três formas de aplicação de métricas foram utilizadas para estimar o custo de cada projeto de software. Isto permitiu comparar o desempenho do Processo de Estimativa de Software com o desempenho das métricas tradicionais (FP e UCP). Esta seção discute os resultados analisados na seção anterior  {\ref (5.1)}.\par
No Projeto 1, realizado pela Instituição privada, presume-se que o Processo de Estimativa de Software obteve menor percentual de erro que as métricas tradicionais (FP e UCP) porque este considerou a inflação do período ao longo do desenvolvimento do projeto, ao contrário das métricas FP e UCP.\par
O índice de inflação mede, entre outras coisas, a variação geral dos preços e do custo de vida. No período de desenvolvimento do Projeto 1 a inflação foi de 2,94\% (5,7\% ao ano). Esse índice foi importante para calcular a variação dos preços dos bens consumidos (exemplos: aluguel, energia, telefone, salário) ao longo do projeto.\par
Já no Projeto 2, realizado pela Instituição Pública, o percentual de erro da métrica FP foi menor que o percentual de erro do Processo de Estimativa de Software. Isto porque o esforço estimado pela métrica FP foi mais preciso que o esforço estimado pelo Processo de Estimativa de Software (o IP estava mais consistente). Todavia, o percentual de erro do Processo de Estimativa de Software foi menor que o percentual de erro da métrica UCP, à medida que o primeiro considerou tanto a inflação do período (3,5\% ao ano) quanto o treinamento (J2EE) que ocorreram ao longo do projeto.\par
Finalmente, no Projeto 3, realizado da Instituição Pública, é lícito supor que o Processo de Estimativa de Software obteve menor erro que as métricas tradicionais (FP e UCP) porque este considerou, além da inflação do período (3,1\%), o reajuste salarial de membros da equipe que ocorreram no decorrer do projeto.\par
Na ocasião, ocorreu o reajuste salarial de três membros da equipe devido ao plano de cargos e carreira da instituição. Um dos membros da equipe obteve o reajuste salarial de 25\% por ter completado um ano de trabalho. Os outros dois membros da equipe obtiveram os reajustes de 12,5\% por terem completado três anos trabalhados. Os reajustes, no entanto, não ocorreram no mesmo mês para cada membro da equipe. Situação em que o salário de cada membro foi calculado separadamente. Em média, os salários dos três membros obtiveram um reajuste de 20,83\%, ao longo de 4,7 meses do projeto.\par
Em relação aos projetos pesquisados, é possível concluir que o erro médio obtido pelo Processo de Estimativa de Software é de 2,24\%. Logo, a sua precisão média é de 97.76\%. Pode-se afirmar com 95\% de confiança que o erro percentual médio do Processo de Estimativa de Software está entre o intervalo [1,04\%; 3,45\%]. Veja a Tabela 2. O Processo de Estimativa de Software com UCP é 4,3\% mais preciso que as métricas de estimativas tradicionais (FP e UCP) sem processo formal de estimativas. Admitese, porém, que o considerável índice de precisão das estimativas obtido pelo Processo de Estimativa de Software pode ter sido influenciado pelas informações obtidas pelos gerentes de projetos.\par
O Processo de Estimativa de Software foi o único a ser realizado após a conclusão dos projetos. Isto permitiu calcular com exatidão todos os recursos consumidos (exemplos: treinamento, aquisição de ferramenta, reajuste salarial) ao longo do projeto. A situação ideal, no entanto, seria realizar as estimativas nas fases iniciais dos projetos. Nessa situação, certamente tais recursos não seriam previstos com exatidão, ou ainda, poderiam ter sido negligenciados na fase de planejamento do projeto, o que diminuiria, em certo ponto, a precisão das estimativas realizadas pelo Processo de Estimativa de Software. 
\section[{VI.}]{VI.} 
\section[{CONCLUSÕES E PERSPECTIVAS FUTURAS}]{CONCLUSÕES E PERSPECTIVAS FUTURAS}\par
Este trabalho apresentou um Processo de Estimativa de Software para padronizar o trabalho de executar estimativas. O Processo de Estimativa de Software foi definido com base nos guias PMBOK, RUP e na métrica UCP. A partir do cruzamento dos guias com a métrica UCP, verificou-se que ambos são capazes de se relacionar, podendo ser usados de forma combinada.\par
Uma pesquisa de campo foi realizada com três projetos de software de duas instituições brasileiras, uma pública e outra privada. Isto foi fundamental para comparar o desempenho do Processo de Estimativa de Software com o desempenho das métricas tradicionais (FP e UCP). Os resultados da pesquisa de campo demonstram que, em média, o Processo de Estimativa de Software com UCP é 4,3\% mais preciso que as métricas de estimativas tradicionais (FP e UCP) sem processo formal de estimativas.\par
Em relação aos resultados obtidos nos projetos, três elementos foram determinantes para o aumento da precisão nas estimativas: (1) a Previsão das Variações de Estimativas, que foi fundamental para calcular a variação geral dos preços ao longo do projeto; (2) a Estimativa dos Recursos: que conseguiu prever os preços dos recursos alocados para a realização das atividades; (3) o Índice de Produtividade (IP), que, quando consistente, garantiu que a estimativa de esforço fosse mais precisa, contribuindo para o menor percentual de erro nas medições.\par
Como trabalhos futuros, este trabalho visa adaptar ações da gestão de estimativas ao Processo de Estimativa de Software apresentado. Para isto, será necessário mapear os processos de gestão propostos pelo PMBOK: Controlar o cronograma e Controlar os custos, para as atividades de gestão de estimativas propostas pelo RUP. Além disso, um método de avaliação e melhoria de estimativas para descobrir nãoconformidades nos processos utilizados pela organização seria útil ao processo.\begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Figura 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Tabela 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{figure4}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.3131578947368421\textwidth}P{0.14045287637698897\textwidth}P{0.05123929008567932\textwidth}P{0.06346389228886169\textwidth}P{0.16828335373317013\textwidth}P{0.04083537331701346\textwidth}P{0.04941860465116279\textwidth}P{0.014305385556915545\textwidth}P{0.008843329253365973\textwidth}}
\multicolumn{2}{l}{6. Gerenciamento do}\tabcellsep \tabcellsep 6.1 Definir atividade\tabcellsep \tabcellsep IV.\tabcellsep PROCESSO DE ESTIMATIVA DE 6.6 Controlar o\\
\multicolumn{2}{l}{tempo do projeto}\tabcellsep \tabcellsep 6.2 Seqüenciar as\tabcellsep \tabcellsep \tabcellsep SOFTWARE cronograma\\
\tabcellsep \multicolumn{6}{l}{atividades 6.3 Estimar os recur-a) Introdução Esta seção e a seção seguinte descrevem as etapas necessárias para definir o Processo de Estimativa de Software proposto por este trabalho. Dessa forma, para alcançar este objetivo, são necessários os seguintes passos : sos da atividade ? Estimativa de duração da atividade ? Planejar Fases e Iterações 6.4 Estimar a dura-? Desenvolver Plano de Iteração ção da atividade 6.5 Desenvolver o ? Estimativa de custos ? Planejar Fases e Iterações}\\
Quadro 2 :\tabcellsep \tabcellsep \tabcellsep Cronograma\tabcellsep \multicolumn{3}{l}{? Mapear a relação entre os processos de gestão de}\\
\multicolumn{2}{l}{7. Gerenciamento dos custos do projeto}\tabcellsep \tabcellsep 7.1 Estimar os cus-orçamentação 7.2 Desenvolver a tos\tabcellsep \multicolumn{3}{l}{estimativas do PMBOK, as atividades de 7.3 Controlar os estimativas do RUP e a métrica UCP. Estimativa de Software. pelo gerente de projeto durante o Processo de ? Identificar as ações gerenciais a serem tomadas custos}\\
\multicolumn{2}{l}{8. Gerenciamento da}\tabcellsep \tabcellsep \multicolumn{2}{l}{8.1 Planejar a quali-}\tabcellsep \multicolumn{2}{l}{A partir do Processo de Estimativa de Software, 8.2 Realizar a 8.3 Realizar o}\\
\multicolumn{2}{l}{qualidade do projeto}\tabcellsep \tabcellsep dade\tabcellsep \multicolumn{3}{l}{o gerente terá informações suficientes sobre as garantia da qua-controle da}\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \multicolumn{3}{l}{estimativas de tempo e custos do projeto, lidade qualidade}\\
\multicolumn{7}{l}{se aplicar" 9.1 Planejar os re-(DAMODARAN \& WASHINGTON, 2002). 9. Gerenciamento dos recursos huma-nos cursos humanos do projeto 10. Gerenciamento 10.1 Planejar as co-possibilitando o rastreamento do cronograma e do 9.2 Contratar ou 9.4 Gerenciar a orçamento previstos. Dessa forma, conhecendo a mobilizar a equi-equipe do pro-situação do projeto, o gerente poderá tomar decisões pe do projeto jeto de ajustes no Plano de Desenvolvimento do Software, 9.3 Desenvolver com base nos indicadores do andamento do projeto. a equipe do pro-b) Mapeamento dos Processos de Gestão de jeto Estimativas do PMBOK com as Atividades de 10.2 Distribuir as 10.3 Desenvol-Estimativas do RUP das comunicações municações informações ver o relatório Esta seção apresenta o mapeamento dos processos de gestão de estimativas do PMBOK com as do projeto de}\\
\multicolumn{4}{l}{Para estimar o tamanho do software, em PCU,}\tabcellsep \multicolumn{3}{l}{atividades de estimativas do RUP. desempenho}\\
\multicolumn{4}{l}{Karner definiu os processos de contagem, disponível}\tabcellsep \tabcellsep \tabcellsep No PMBOK, os processos de gestão de 10.4 Gerenciar\\
\multicolumn{2}{l}{em (KARNER, 1993).}\tabcellsep \tabcellsep \tabcellsep \multicolumn{3}{l}{estimativas estão concentrados nas áreas de as partes inte-}\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \multicolumn{3}{l}{conhecimento: Gerenciamento do tempo do projeto e}\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \multicolumn{3}{l}{Gerenciamento dos custos do projeto. Nos grupos de}\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \multicolumn{3}{l}{processos: Planejamento e Controle, conforme}\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \multicolumn{2}{l}{destacados no Quadro 1.}\\
\multicolumn{2}{l}{GRUPOS DE}\tabcellsep INICIAÇÃO\tabcellsep PLANEJAMENTO\tabcellsep \tabcellsep \multicolumn{2}{l}{EXECUÇÃO}\tabcellsep CONTROLE\tabcellsep ENCERRAMENTO\\
\multicolumn{2}{l}{PROCESSOS}\tabcellsep Disciplinas\tabcellsep \tabcellsep \tabcellsep \\
ÁREAS DE\tabcellsep \multicolumn{2}{l}{Modelagem de Negócios}\tabcellsep \tabcellsep \tabcellsep \\
\multicolumn{2}{l}{CONHECIMENTO}\tabcellsep Requisitos\tabcellsep \tabcellsep \tabcellsep \\
\multicolumn{2}{l}{4. Gerenciamento da}\tabcellsep 4.1 Desenvolver o Análise e Design\tabcellsep 4.3 Desenvolver o\tabcellsep \tabcellsep \multicolumn{2}{l}{4.4 Orientar e}\tabcellsep 4.5 Monitorar e\tabcellsep 4.7 Encerrar o projeto\\
\multicolumn{2}{l}{integração do projeto}\tabcellsep termo de aber-tura do projeto Implementação\tabcellsep plano de gerencia-mento do projeto\tabcellsep \tabcellsep \multicolumn{2}{l}{gerenciar a exe-cução do Projeto}\tabcellsep controlar o tra-balho do proje -\\
\tabcellsep \tabcellsep 4.2 Desenvolver a Teste\tabcellsep \tabcellsep \tabcellsep \tabcellsep to\\
\tabcellsep \tabcellsep declaração do Implantação\tabcellsep \tabcellsep \tabcellsep \tabcellsep 4.6 Controlar\\
\tabcellsep \tabcellsep escopo preliminar Gerenciamento de\tabcellsep \tabcellsep \tabcellsep \tabcellsep mudanças e in -\\
\tabcellsep \multicolumn{2}{l}{do projeto Configuração e Mudança}\tabcellsep \tabcellsep \tabcellsep \tabcellsep tegração\\
\multicolumn{3}{l}{5. Gerenciamento do Gerenciamento de Projeto}\tabcellsep 5.1 Planejar o esco-\tabcellsep \tabcellsep \tabcellsep 5.4 Verificar o\\
\multicolumn{2}{l}{escopo do projeto}\tabcellsep Ambiente\tabcellsep po\tabcellsep \tabcellsep \tabcellsep escopo\\
\tabcellsep \tabcellsep \tabcellsep 5.2 Definir o escopo\tabcellsep \tabcellsep \tabcellsep 5.5 Controlar o\\
\tabcellsep \tabcellsep \tabcellsep 5.3 Criar EAP\tabcellsep \tabcellsep \tabcellsep escopo\end{longtable} \par
  {\small\itshape [Note: ressadas Quadro 1 : Mapeamento dos processos de gestão de estimativas do PMBOK. Fonte: PMBOK (2008). Já no RUP, as atividades de estimativas estão concentradas na disciplina Gerenciamento de Projeto, conforme destacada na Figura 1. Figura 1 : Mapeamento das atividades de estimativas do RUP. Fonte: RUP (2008).PMBOK]} 
\caption{\label{tab_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{P{0.04033898305084746\textwidth}P{0.01440677966101695\textwidth}P{0.0835593220338983\textwidth}P{0.11813559322033898\textwidth}P{0.1123728813559322\textwidth}P{0.23627118644067796\textwidth}P{0.1123728813559322\textwidth}P{0.06338983050847458\textwidth}P{0.06915254237288135\textwidth}}
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \multicolumn{2}{l}{Intervalo de confiança para a}\tabcellsep \tabcellsep \\
9\tabcellsep N\tabcellsep Média\tabcellsep Desvio Padrão\tabcellsep Erro Padrão\tabcellsep média de 95\% Limite\tabcellsep Limite\tabcellsep Mínimo\tabcellsep Máximo\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep superior\tabcellsep superior\tabcellsep \tabcellsep \\
FP\tabcellsep 3\tabcellsep 8,4933\tabcellsep 6,55091\tabcellsep 3,78217\tabcellsep -7,7800\tabcellsep 24,7667\tabcellsep 1,35\tabcellsep 14,22\\
UCP\tabcellsep 3\tabcellsep 4,3967\tabcellsep 1,12180\tabcellsep 0,64767\tabcellsep 1,6100\tabcellsep 7,1834\tabcellsep 3,24\tabcellsep 5,48\\
PES\tabcellsep 3\tabcellsep 2,2433\tabcellsep 0,48429\tabcellsep 0,27960\tabcellsep 1,0403\tabcellsep 3,4464\tabcellsep 1,69\tabcellsep 2,59\\
Total\tabcellsep 9\tabcellsep 5,0444\tabcellsep 4,31997\tabcellsep 1,43999\tabcellsep 1,7238\tabcellsep 8,3651\tabcellsep 1,35\tabcellsep 14,22\end{longtable} \par
 
\caption{\label{tab_2}Tabela 2 :}\end{figure}
 			\footnote{© 2012 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XII Issue VI Version I} 			\footnote{© 2012 Global Journals Inc. (US)} 			\footnote{March} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Pmbok et al.]{b7}\label{b7} 	 		\textit{A guide to the project management body of knowledge (PMBOK Guide)},  		 			Pmbok 		,  		 			Project 		,  		 			Body 		,  		 			Knowledge 		.  		Newtown. 4.  	 
\bibitem[Gil ()]{b4}\label{b4} 	 		‘Como elaborar projetos de pesquisa? 5’.  		 			A C Gil 		.  	 	 		\textit{São Paulo: Atlas},  				2010. 200 p.  	 
\bibitem[Sommerville ()]{b12}\label{b12} 	 		\textit{Engenharia de software},  		 			I Sommerville 		.  		2007. São Paulo: Addison-Wesley. 8.  	 
\bibitem[Pressman ()]{b8}\label{b8} 	 		\textit{Engenharia de software. 6},  		 			R S Pressman 		.  		2006. São Paulo: McGraw-Hill. 720.  	 
\bibitem[Damodaran and Washington ()]{b3}\label{b3} 	 		\textit{Estimation using use case points},  		 			M Damodaran 		,  		 			A Washington 		.  		2002. Victoria.  		 			University of Houston-Victoria 		 	 
\bibitem[Tetila et al. ()]{b14}\label{b14} 	 		\textit{Estimativa de software combinando métricas: um estudo de caso},  		 			E C Tetila 		,  		 			I Costa 		,  		 			M. M ; Simpósio De Administração Da Spínola 		,  		 			Logística E Operações Produção 		,  		 			Internacionais 		.  		2006.  	 
\bibitem[Sowebok ()]{b13}\label{b13} 	 		\textit{Guide to the software engineering body of knowledge},  		 			Sowebok 		.  		2004. Los Alamitos: IEEE Computer Society. 202.  	 
\bibitem[Rational and Process ()]{b9}\label{b9} 	 		\textit{IBM Rational Unified Process Reference and Certification Guide: Solution Designer},  		 			Rup Rational 		,  		 			Process 		.  		2008. IBM Press. 336.  	 	 (S.l.) 
\bibitem[Bcb et al. ()]{b0}\label{b0} 	 		\textit{Inflação e Atividade: Perspectivas para},  		 			Bcb 		,  		 			Banco 		,  		 			Do Brasil 		,  		 			Setor 		.  		 \url{<http://www.bcb.gov.br/?APRES2006012>.Acessoem}  		2006. 2006. p. .  	 	 (Banco Central do Brasil. 06 abr) 
\bibitem[Marconi and Metodologia Do Trabalho Científico ()]{b6}\label{b6} 	 		 			M A Marconi 		,  		 			Metodologia Do Trabalho Científico 		.  		\textit{São Paulo: Atlas},  				2007. 255.  	 
\bibitem[Maturity et al. ()]{b2}\label{b2} 	 		 			Cmmi Maturity 		,  		 			Integration 		,  		 			Cmmi 		.  		\textit{Integração dos Modelos de Capacitação e Maturidade de Sistemas. 6},  				2007. 292.  	 	 (Rio de Janeiro: Ciência Moderna) 
\bibitem[Slack et al. ()]{b10}\label{b10} 	 		 			N Slack 		,  		 			S Chambers 		,  		 			T Johnston 		.  	 	 		\textit{Gerenciamento de Operações e de Processos: Princípios e Práticas de Impacto Estratégico},  				 (Porto Alegre)  		2008. 552.  	 
\bibitem[Softex et al. ()]{b11}\label{b11} 	 		\textit{Software e Serviços de TI: A Indústria Brasileira em Perspectiva. Associação para promoção da excelência do software brasileiro},  		 			Softex 		,  		 			Associação 		,  		 			Promoção Da Excelência 		,  		 			Do 		,  		 			Brasileiro 		.  		 \url{<http://publicacao.observatorio.softex.br/\textunderscore publicacoes/arqui-vos/resumo/Resumo\textunderscore Executivo.PDF>.Acessoem:5janeiro}  		2009. 2010. Campinas, nov.  	 
\bibitem[Charbonneau]{b1}\label{b1} 	 		\textit{Software Project Management -A Mapping between RUP and the PMBOK},  		 			S Charbonneau 		.  		 	 
\bibitem[Paulo and Anais ()]{b15}\label{b15} 	 		\textit{São Paulo: Fundação Getúlio Vargas. 29-31 ago},  		 			São Paulo 		,  		 			Anais 		.  		2006.  	 
\bibitem[Karner ()]{b5}\label{b5} 	 		‘Use Case Points: resource estimation for Objectory projects’.  		 			G Karner 		.  	 	 		\textit{Objective Systems SF AB}  		1993.  	 	 (S.l.], Set) 
\end{bibitemlist}
 			 		 	 
\end{document}
