Uma Abordagem sobre Custo de Software
Este artigo apresenta, de maneira superficial, as principais técnicas de estimativa de custo de software dentro da criação e manutenção de produtos de software, ponto de extrema importância no ambiente competitivo, onde as fábricas de software, buscando reduzir gastos, procuram aproximar ao máximo sua estimativa de custo de acordo com o custo real. Além disto, serão exemplificados dois modelos de desenvolvimento de software (um ágil e outro tradicional) apresentando simulações.
Palavras-chave: custo de software, engenharia de software, COCOMO, FP, LPC.
1.0 INTRODUÇÃO
A indústria de software vem produzindo softwares cada vez mais complexos e maiores, neste sentido, entregar um produto com qualidade, dentro do prazo e custos esperados é hoje um grande desafio para as organizações. Fatores como esses impulsionam o interesse, por parte das organizações, pela estimativa e controle dos custos dos projetos de software. (BARCELLOS, 2003).
Segundo Pressman (2006), uma alternativa para o desenvolvimento de softwares com qualidade duradoura e que satisfaça o propósito pretendido, é a elaboração de um planejamento de projeto. "Antes que o projeto possa começar, o gerente e o a equipe de software precisam estimar o trabalho a ser feito, os recursos necessários e o tempo que vai decorrer do início ao fim".
A gerência de projetos engloba a atividade de planejamento que consiste em realizar estimativas de custos nos projetos. Alves (2006), afirma que as estimativas de custos têm por objetivo determinar os gastos necessários para produzir um software. Tal preocupação visa garantir a qualidade do software e a harmonia entre a equipe e o cliente, durante todo o ciclo de vida.
Estimativas iniciais podem ser usadas para estabelecer um orçamento para o projeto ou para estabelecer o preço do software para um cliente. (SOMMERVILLE, 2007). Assim, a estimativa de custo de software deve ser realizada com o propósito de prever precisamente o custo total envolvido no desenvolvimento do software, bem como seu preço final.
Conforme Alves (2006), "estimar custo de software não é uma tarefa fácil, pois envolve muitas variáveis como a qualidade do produto gerado, os prazos estabelecidos, os recursos humanos envolvidos, os riscos identificados, entre outros de mesma relevância".
Contudo, as organizações necessitam estimar precisamente o esforço e o custo envolvidos no processo de desenvolvimento de software. Neste sentido, Pressman (2006) apresenta algumas opções para conseguir estimativas de custo e esforço confiáveis:
1.Adie a estimativa até que o projeto esteja mais adiantado;
2.Baseie as estimativas em projetos semelhantes, que já foram completados;
3.Use técnicas de decomposição relativamente simples para gerar estimativas de custos e esforço do projeto;
4.Use um ou mais modelos empíricos para estimativa de custo e esforço do software.
Com mesmo objetivo, conseguir estimativas de custo e esforço confiáveis, Sommerville (2007) apresenta algumas técnicas de estimativas de custos de software, conforme descritos abaixo:
1.Modelagem algorítmica de custos
2.Julgamento de especialistas
3.Estimativa por analogia
4.Lei de Parkinson
5.Atribuição de preço para ganhar
Uma ou mais técnicas descritas por Pressman (2006) e Sommerville (2007) pode(m) ser utilizada(s) para produzir estimativas de custos. Cada técnica apresenta pontos positivos e negativos, para se obter melhores resultados é necessário utilizar mais de uma técnica e comparar seus resultados.
Nas últimas duas décadas, muitos estudos têm sido realizados na área de estimativas de custos para projetos de software. Dentre as técnicas de estimativas citadas o presente artigo aborda duas estimativas de custo e esforço segundo Pressman (2006): Técnicas de Decomposição e Modelos Empíricos. A abordagem Modelos Empíricos também é vista segundo Sommerville (2007), nomeada como Modelagem algorítmica de custos.
2.0TÉCNICAS DE ESTIMATIVAS DE CUSTOS
2.1TÉCNICAS DE DECOMPOSIÇÃO
Segundo Pressman (2006), "a estimativa de um projeto é boa na mesma medida em que é a estimativa do tamanho do trabalho a ser realizado". No contexto do planejamento, o tamanho refere-se ao resultado quantificável do projeto de software.
"Se uma abordagem direta for utilizada, o tamanho pode ser medido em número de linhas de código (LOC ? Lines Of Code). No caso da utilização de uma abordagem indireta, o tamanho pode ser representado por pontos por função (PF)". (PAGNO, 2010).
Pressman (2006) aborda três formas de estimativas para a decomposição e dimensionamento do software: estimativa baseada no problema, estimativa baseada no processo e estimativas com casos de uso.
2.1.1ESTIMATIVA BASEADA NO PROBLEMA
As estimativas baseadas no problema realizam a divisão do software (problema), a ser desenvolvido, em termos de funções. Por conseguinte, são estimados os tamanhos dessas funções por meio de duas principais técnicas distintas: Número de linhas de código (LOC) e Número de pontos por função (PF). (PAGNO, 2010).
?Número de linhas de código (LOC) ? esta técnica é utilizada para estimar o tamanho das funções. A medida desta técnica é dada em termos de quantidade de número de linhas de código, geralmente esta medida é fornecida em KLOC, onde, K = 1000 linhas de código. (PAGNO, 2010)
?Número de pontos por função (PF) ? nesta técnica o tamanho da funcionalidade é dado em termos de combinação de entradas, saídas, arquivos de dados, consultas e interfaces externas, bem como, os valores de ajuste da complexidade. (PRESSMAN, 2006)
As estimativas de LOC e PF são técnicas distintas, porém possuem algumas características em comum. O planejador do projeto começa com uma declaração delimitada do software e a partir dela decompõem o software em funções do problema que podem ser estimadas individualmente. LOC ou PF é então estimada para cada função, e o custo ou esforço corresponde é derivado. (PRESMAN, 2006).
Independente da variável de estimativa que é utilizada, o planejador do projeto começa estimando um intervalo de valores para cada função. Através da utilização de dados históricos, da própria intuição e/ou experiência o planejador estima um valor otimista, mais provável e um pessimista para cada função. Um valor esperado, ou de três pontos, pode então ser calculado, como média ponderada das estimativas otimista (Sot), mais provável (Sm) e pessimista (Spess). (PRESMAN, 2006).
Após obter as estimativas do tamanho de cada função o planejador aplica os dados históricos de produtividade que refletem a realidade da equipe envolvida e, assim, estima-se o esforço exigido para desenvolvimento de cada função do produto de software. Por fim, a combinação destas estimativas, gera a estimativa total, de esforço e custo para a realização de um determinado projeto. (PAGNO, 2010).
As estimativas obtidas não são 100% seguras. Qualquer técnica de estimativa, não importa quão sofisticada, deve ser comparada com outras abordagens, bem como, deve prevalecer o bom senso e experiência. (PRESSMAN, 2006)
2.1.2 ESTIMATIVA BASEADA NO PROCESSO
Segundo Pressman (2006), "a técnica mais comum para estimar um projeto é basear a estimativa em um processo que será usado. Isto é, o processo é decomposto em um conjunto relativamente pequeno de tarefas e o esforço necessário para realizar cada tarefa é estimado"
Assim como na técnica baseada no problema, a estimativa baseada no processo começa com o delineamento das funções do software a partir do escopo do projeto. Em seguida, para o desenvolvimento de cada função é preciso atribuir a execução de uma série de atividades (comunicação com o cliente, planejamento, análise de risco, engenharia e construção/entrega). (PAGNO, 2010).
Após a atribuição de atividades, o planejador do projeto consulta dados históricos da equipe e estima o esforço/custo necessário para cada atividade envolvida. Combinando as funções do problema com as atividades do processo envolvidas, são realizadas as estimativas de tamanho e esforço necessário para a realização de cada atividade do processo de software, e como último passo, são realizados as estimativas para cada função do software. (PRESSMAN, 2006).
Resumidamente, o tamanho e/ou esforço total exigido para a conclusão do projeto é dado pela soma do esforço necessário para executar todas as atividades de cada função, seguida da soma do tamanho e esforço de todas as funções do software. (PAGNO, 2010).
2.1.3 ESTIMATIVA COM CASOS DE USO
O método Pontos por Caso de Uso (PCU) foi proposto por Gustav Karner, em 1993, ele permite estimar o tamanho de um projeto com base em casos de uso, considerando a complexidade das ações e uma análise de alto nível dos passos executados em cada tarefa. (LIMA, 2007).
Segundo Pressman (2006), trata-se de uma técnica utilizada para estimar custos de projetos de software Orientados a Objetos, com base no modelo de casos de uso gerado no início do projeto.
Dekkers (1999) apud Andrade e Oliveira (2004), afirma que a abordagem baseada em Pontos de Casos de Uso (PCU) permite fazer estimativas no início do projeto com base no modelo de casos de uso. Tal regra satisfaz a demanda por métricas que proporcionem estimativas iniciais de tamanho, custo, e/ou esforço do software a ser desenvolvido, sendo assim, bastante utilizado no mercado.
Para Smith (1999) apud Pressman (2006), antes de utilizar casos de uso para estimativa de custo/esforço do software, devem-se estabelecer alguns pré-requisitos, como: nível de hierarquia estrutural; tamanho médio (números de páginas) de cada caso de uso; tipo de software (software de tempo real, negócio, engenharia/científico, embutido); e um esboço da arquitetura do sistema.
Após a definição destes pré-requisitos, "dados empíricos podem ser usados para estabelecer o número estimado de LOC ou FP por caso de uso. Dados históricos são então usados para calcular o esforço necessário para desenvolver o sistema". (PRESSMAN, 2006).
2.2 MODELOS EMPÍRICOS
Segundo Pagno (2010), este modelo de estimativa utiliza fórmulas empiricamente derivadas de dados de uma amostra limitada de projetos com o objetivo de prognosticar as informações de planejamento de projeto. Podem ser utilizadas como complemento às técnicas de decomposição, oferecendo estimativas importantes através de seu próprio método.
Por serem derivados de uma amostra de projetos já concluídos, os modelos empíricos não são adequados a todas as classes de software e a todos os ambientes de desenvolvimento. Assim, o modelo de estimativa deve ser calibrado, a fim de refletir as condições de trabalho locais.
Pressman (2006), diz que o modelo deve ser testado aplicando os dados coletados de projetos já finalizados e comparado aos resultados reais. Se a discrepância for grande, o modelo deve ser modificado e retestado, antes que possa ser utilizado.
Os modelos empíricos são derivados por análise de regressão de dados coletados de projetos de software anteriores.
2.2.1 COCOMO
O modelo COCOMO (Constructive Cost Model) é um modelo empírico que visa medir esforço, prazo, tamanho de equipe e custo necessários para o desenvolvimento de um projeto de software, desde que se tenha a dimensão do projeto. (COCOMO, 1995-2000).
Pagno (2010), afirma que o modelo COCOMO "calcula, também, as estimativas de tempo necessário para o desenvolvimento por meio de fórmulas derivadas empiricamente e condicionadas em sua estrutura.
2.2.1.1 COCOMO 81
O COCOMO 81 trata-se da primeira versão do Constructive Cost Model, desenvolvida em 1981 por Barry Boehm. Este modelo foi "construído e calibrado inicialmente a partir de informações de um número considerável de projetos concluídos, em torno de 83". (LÓPEZ, 2005)
Para Alves (2006), o COCOMO 81 é baseado em um banco de dados de diversos projetos, dividido em três modos de desenvolvimento de software: orgânico, semidestacado e embutido. O COCOMO 81 consiste de três implementações: Básico, Intermediário e Avançado, conforme descritas abaixo, segundo o mesmo autor:
Básico: calcula o esforço e custo para o desenvolvimento de um software, em função do tamanho de linhas de códigos desenvolvidas.
Intermediário: "Calcula o esforço de desenvolvimento de software em função do tamanho do programa, incluindo custo, avaliação subjetiva do produto, ferramentas, pessoal e atributos de projeto".
Avançado: "Incorpora características da versão intermediária com uma avaliação de impacto de custo em cada passo de todo o projeto".
A utilização do COCOMO 81 passou a requerer atualizações, a fim de adaptar-se as novas mudanças nos ciclos de vida do software, tecnologia, componentes, notações e culturas organizacionais. Assim, para suprir as tendências modernas da engenharia de software foi criado o COCOMO II.
2.2.1.2 COCOMO II
"O COCOMO II, assim como o seu predecessor, busca medir esforço, prazo, tamanho e custo, necessários para o desenvolvimento de software, desde que se tenha, como premissa, a dimensão do mesmo". Para o cálculo do custo deve-se conhecer o prazo e equipe de trabalho, para então chegar ao valor final. Para definir o tamanho do programa, é necessário que se caracterize a medida que será adotada (linhas de código, pontos por função ou pontos por caso de uso). (LÓPEZ, 2005).
Pressman (2006), afirma que o COCOMO II é na verdade uma hierarquia de modelos de estimativas que tratam de três áreas, conforme expostas abaixo segundo Pagno (2010):
1.Modelo de composição da aplicação ? modelo utilizado o nos primeiros estágios da engenharia de software, destinado a estimar esforço e prazo em desenvolvimentos rápidos;
2.Modelo Early design ? "modelo utilizado na exploração de alternativas de arquiteturas ou estratégias para o desenvolvimento interativo". Utilizado quando o projeto não começou, mas se conhece os requisitos.
3.Modelo Post-architecture ? utilizado quando a arquitetura do software a ser desenvolvido está pronta e se tem informações detalhadas sobre o sistema, oferecendo assim, maior precisão nas estimativas de custo.
Segundo Boehm et al., 2000 apud Barcellos (2003), "O processo de realização de estimativas de software utilizando o COCOMO II pode ser resumido em quatro etapas: (i) determinar o modelo da aplicação; (ii) realizar estimativas de esforço; (iii) realizar estimativas de prazo; e (iv) realizar estimativas de custos". Para realização destas etapas deve-se verificar qual modelo de estimativa COCOMO II está sendo utilizado, a fim de obter a realização dos cálculos matemáticos adequados.
3 CUSTO DE SOFTWARE NA VISÃO DE METODOLOGIAS DE DESENVOLVIMENTO
3.1 RUP
O Processo Unificado da Rational (Rational Unified Processo) é um processo de engenharia de software criado para auxiliar o desenvolvimento de produtos de software orientados a objetos, utilizando a UML (Unified Modeling Language). (IRUP, 2011).
O objetivo do RUP é proporcionar a criação de um software com qualidade, ou seja, que atenda as necessidades do cliente, visando cumprir um cronograma e um orçamento pré-determinados.
Para efetuar este controle de custo/prazo, são definidas todas as atividades, seus respectivos responsáveis e quando estas serão realizadas, com uma descrição de todas as metas de desenvolvimento. (IRUP, 2011).
O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas questões sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação do software. Cada fase tem um papel fundamental para que o objetivo seja cumprido, distribuídos entre vários profissionais, como: o Analista de sistema, Projetista, Projetista de testes, entre outros.
Na da fase de planejamento, uma das etapas é a estimativa de custo e esforço do projeto. O esforço total da equipe e a programação de um projeto podem ser calculados com base na estimativa de tamanho de produto, usando modelos científicos estabelecidos. Os dois modelos proeminentes em uso atualmente são o modelo de custo construtivo COCOMO II e a metodologia Putnams. (ATIVIDADE, 2011). Após obter estas informações, é necessário juntá-las a métrica de produtividade da equipe, buscando estipular o esforço geral do projeto.
3.2 SCRUM
O SCRUM é um framework para gerenciamento de projetos baseado nos princípios do manifesto ágil. Sua abordagem é empírica, iterativa e incremental, buscando maior envolvimento do cliente e abraçando as novas mudanças. (SCRUM, 2011).
O manifesto ágil possui quatro (4) pilares: Pessoas e interações sobre processos e ferramentas; Software funcionando sobre documentação extensa; Colaboração do cliente sobre negociação de contratos; Trabalhar com mudanças sobre seguir o plano. (AGILE, 2011).
A base do SCRUM são suas sprints (Iterações com tempo fixo - geralmente 2 a 6 semanas - e atividades pré determinadas). Estas sprints são executadas até que não exista mais atividades para serem feitas naquele projeto. Estas atividades são relatadas no Product Backlog e possuem urgência e prioridades definidas pelo cliente. Para que as atividades do Product Backlog entrem em uma Sprint, elas devem ser segmentadas em pequenas atividades.
Por possuir caráter empírico, o SCRUM baseia o custo do software através do conhecimento já adquirido nos projetos anteriores. Ou seja, para determinar em quantos itens o Product Backlog deverá ser segmentado, a equipe e o ScrumMaster (responsável pela boa utilização do SCRUM) buscam conhecimento nos projetos anteriores para estimar quantos itens do Product Backlog serão necessários para que o produto seja produzido. Com estes itens definidos, através do conhecimento empírico, a equipe consegue determinar quantas SPRINTS serão necessárias para realizar as atividades estipuladas, levando com consideração suas prioridades e dificuldade de implementação (utilizando os conceitos de LOC e FP citados anteriormente).
Este tipo de abordagem é utilizado para que o custo do software seja maleável para o cliente. Ou seja, o cliente poderá modificar o Product Backlog e consequentemente a quantidade de itens que devem ser produzidos ao final de cada Sprint. Esta atividade é extremamente útil quando o cliente ainda não possui requisitos bem definidos ou estes requisitos mudam constantemente.
O conceito utilizado no SCRUM é o mesmo conceito da estimativa baseada no processo. O projeto é dividido em processos e segmentado em atividades, onde estas atividades possuem valores de prazo e consequementemente de custos. Para finalizar, o custo no SCRUM é sustentando por: número de iterações, período destas iterações e quantidade de pessoas envolvida(s) no projeto.
CONCLUSÃO
Durante o desenvolvimento do presente artigo procurou-se descrever, através de referências bibliográficas, as principais técnicas de estimativas de custo de softwares confiáveis. Entre estas, foram descritos a técnica SCRUM e o processo RUP, como técnica de gerenciamento de projetos baseado nos princípios do manifesto ágil e processo para auxiliar o desenvolvimento de produtos de software orientados a objetos, respectivamente.
Em suma, concluí-se que o planejamento dos prazos e custos de projetos de software é imprescindível, uma vez que pesquisas mostram que a maioria dos projetos que fracassam tem como principal motivo o incorreto planejamento dos custos e cronograma.
A fim de obter melhores resultados constatou-se que é aconselhável utilizar mais de uma técnica, bem como, combinar os resultados de técnicas distintas, obtendo assim uma estimativa geral e precisa do esforço, duração do projeto ou custo. Em caso de grande desigualdade entre as diferentes estimativas geradas, é importante: rever o entendimento/interpretação do escopo e verificar a aplicação adequada dos dados de produtividade usados para as estimativas.
Verificou-se que a estimativa de projetos de software não é uma ciência exata, mas uma combinação de bons dados históricos e técnicas sistemáticas podem melhorar a precisão da estimativa, o que favorecerá o sucesso do projeto de software, a harmonia entre a equipe de desenvolvimento e o cliente e o alcance das metas pré-estabelecidas.
REFERÊNCIAS
[Agile Manifesto 2011] AGILE Manifesto. 2011. Disponível em:
[Atividade: Planejar fases e iterações 2011]ATIVIDADE: Planejar fases e
iterações. 2011. Disponível em:
PRESSMAN, R. S. Engenharia de Software. 6ª ed. São Paulo: Ed. McGraw-Hill, 2006. 720 p.
SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Ed. Pearson Addison-Wesley, 2007. 552 p.
[Scrum definitions 2011]SCRUM definitions. 2011. Disponível em:
LIMA, A. S. UML 2.0: do requisito à solução. São Paulo: Ed. Érica, 2007. 328 p.
PAGNO, R.T. Uma ferramenta de estimativa de custos para o desenvolvimento distribuído de software, 172f. Dissertação de Mestrado (Ciência da Computação) ? Universidade Estadual de Maringá, Maringá, 2010.
LÓPEZ, P. A. P. COCOMO II: Um modelo para estimativa de custos de Projetos de Software, 98f. Trabalho de Conclusão de Curso (Análise de Sistemas) ? Universidade do Vale do Rio dos Sinos, São Leopoldo, 2005.
[Yourdon 1990]YOURDON, E. Análise Estruturada Moderna. São Paulo: Ed.
Campus, 1990. 836 p.
BARCELLOS, M. P. Planejamento de custos em ambientes de desenvolvimento de Software orientados à organização, 216f. Dissertação de Mestrado (Engenharia de Sistemas e Computação) ? Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2003.
ALVES, C. V. Utilização da Estimativa de Custos no Processo de Desenvolvimento de Software, 97f. Trabalho de Conclusão de Curso (Sistemas De Informação) ? Universidade do Vale do Rio dos Sinos, São Leopoldo, 2006.
ANDRADE, E. L. P; OLIVEIRA, K. M. Aplicação de Pontos de Função e Pontos de Casos de Uso de forma combinada no Processo de Gestão de estimativa de tamanho de Projetos de Software Orientado a Objetos, 2004.
Disponível em: . Acesso em: 20 abril 2011.
COCOMO. COCOMO II: Model Definition Manual, v. 2.1, 1995-2000.
Disponível em:
Acesso em: 23 abril 2011.
Autor: Daniela Justiniano De Sousa
Artigos Relacionados
Engenharia De Software - Visão Geral
Análise De Pontos De Função Como Instrumento De Apoio Na Gestão De Projetos De Softwares
Mda
Aplicando Reuso Na Disciplina De Gerência De Projetos De Software Do Rup
Quando Aplicar A Reengenharia De Software
Scrum - Manisfesto Ágil
Engenharia De Software