Fatos e falácias de Engenharia de Software - Testes de Software

Bom pessoal, após mais uma curta temporada sem atualizações por aqui, estou retornando para dar continuidade a série de discussões a respeito de pontos importantes da engenharia de software. O tema abordado na discussão dessa postagem divide opiniões e talvez traga comentários interessantes a respeito de experiências pessoais. Pois bem, hoje falaremos a respeito de Testes de Software.

Essa é a penúltima postagem da série inicial de discussões planejada, sendo assim aproveitem pois está acabando. =)

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo nº 05
Fatos
31 - Remoção de erro é a fase mais demorada do ciclo de vida.
32 - Software que um típico programador acredita ser testado várias vezes, tinha apenas cerca de 55 a 60% dos caminhos de sua lógica executada. Utilizar o suporte automatizado, como os analisadores de cobertura, pode aumentar para cerca de 85 a 90%. É quase impossível testar 100% dos caminhos lógicos de software.
33 - Mesmo se uma cobertura de 100% de teste fosse possível, isso não seria um critério suficiente para o teste. Cerca de 35% de defeitos de software emerge da falta de caminhos lógicos, e outros 40% da execução de uma combinação única de caminhos lógicos. Eles não vão ser apanhados por uma cobertura de 100%.
34 - É quase impossível fazer um bom trabalho de remoção de erro sem ferramentas. Depuradores são comumente utilizados, mas outros, como os analisadores de cobertura, não são.

Discussão
Os fatos estudados analisam os principais problemas relacionados aos testes de software. O fato 31 trata do tempo demandado para a remoção de erros de software. Muitos autores chamam essa fase do processo de desenvolvimento de software por nomes diferentes. Os nomes mais comuns de se ver são Teste, Verificação e Validação. Glass prefere chamar essa fase pelo nome de Remoção de erros, pois considera esse o nome que melhor descreve a atividade.

Segundo Glass [1], a fase de remoção de erros de software é a que gasta mais tempo em todo o processo, podendo gastar até o dobro do tempo gasto em cada uma das outras fases do processo de software (Análise de requisitos, projeto e implementação). Isso geralmente causa grandes surpresas aos desenvolvedores, pois de certa maneira, é possível mensurar o tempo demandado em um projeto para recolher requisitos, projetá-los e codificá-los, porém o tempo gasto na remoção de erros de software é muito relativo, pois este vai depender da qualidade do trabalho realizado nas outras fases do processo. Portanto, quanto pior forem executadas as fases anteriores, maior será o tempo demandado na remoção de erros.

Uma maneira eficiente para diminuir o tempo demandado para remoção de erros de software é enfatizar mais a essência do problema a ser resolvido, ou seja, quanto mais atenção for dada para a análise dos requisitos e o projeto, menor será o tempo gasto com remoção de erros, pois erros de codificação são muito mais simples e menos custosos de serem resolvidos do que erros de requisitos.

Considerando que o desenvolvimento de software seja iterativo, a remoção de erros é conseqüentemente feita também de forma iterativa durante todo o processo.

O fato 32 é relacionado à cobertura dos testes de software. Como sua própria descrição já fala, é praticamente impossível testar 100% de um software. Glass julga como ingênuas as pessoas que acreditam nessa possibilidade.

O autor classifica as abordagens de testes de software em quatro diferentes tipos:

• Testes orientados a requisitos;
• Testes orientados a estruturas;
• Testes orientados a estatísticas;
• Testes orientados a riscos;

Os dados citados pelo autor são baseados em testes estruturais, que são aqueles que verificam os caminhos lógicos de programação. Segundo Glass [1], os testes estruturais de software normalmente cobrem apenas de 55 a 60% dos caminhos lógicos de um software. Com o auxílio de analisadores automáticos de cobertura de testes fica mais fácil identificar as partes do software que ainda não foram abrangidas pelos testes, sendo assim a utilização dos mesmos aumentam a cobertura dos testes para entorno de 85 a 90% dos caminhos lógicos. É praticamente impossível atingir aos 100% de cobertura devido às obscuridades advindas da natureza do software.

É essencial a realização de testes em software utilizando as abordagens que forem relevantes ao projeto em execução, porém dificilmente as baterias de testes na qual os softwares são submetidos irão retirar todos os seus erros.

O fato 33 mostra que mesmo que fosse possível realizar testes de software com 100% de cobertura dos caminhos lógicos, isso ainda não daria garantia da criação de um software livre de erros.

Esse fato é gerado a partir da pesquisa pessoal de Glass. Ao analisar uma série de relatório de erros na indústria aeroespacial, Glass chegou à conclusão de que 35% dos erros encontrados na base de dados analisada eram erros de omissão de lógica, ou seja, requisitos que possivelmente não foram levantados e conseqüentemente não foram implementados. Esse tipo de erro não seria identificado em testes estruturais, pois esse tipo de teste é feito baseando-se na especificação do software.

Outro tipo de erro que não seria identificado mesmo com a execução de testes com 100% de cobertura seriam os erros de análise combinatória. Esses são os erros ocasionados pela combinação de caminhos lógicos. Geralmente os testes estruturais testam os caminhos lógicos separadamente, mas não a combinação deles. Esse tipo de erro de analise combinatória representaram 40% dos erros encontrados por Glass na base de dados analisada.

Em suma, se fosse possível realizar testes de software com 100% de cobertura dos caminhos lógicos, ainda assim, apenas 25% dos erros de software seriam detectados com certeza.

O fato 34 diz respeito à falta de uso de ferramentas para as fases de back-end do desenvolvimento de software. Ao contrário das fases de front-end, onde um grande número de ferramentas para análise e projeto são difundidas e usadas, nas fases de back-end a maioria dos desenvolvedores utiliza apenas ferramentas depuradoras, ignorando analisadores automáticos de cobertura de testes e outras ferramentas.

Há vários fatores que contribuem para a falta de atenção despendida pelos desenvolvedores às ferramentas de back-end. Dentre esses fatores, a super atenção dada às ferramentas de front-end é um dos motivos, pois ao atacar a essência do software no front-end e codificarem seguindo padrões, alguns desenvolvedores acreditam ser desnecessário despender atenção às fases de testes e manutenção.

Em estudo realizado por Zhao e Elhaum [4], foi demonstrado que em apenas 39,6% dos projetos de software-livre, alguma ferramenta de teste foi utilizada e a grande maioria dessas ferramentas eram depuradores. Muito provavelmente esses dados refletem de forma semelhante à situação de projetos de software de uma forma geral, não apenas de software-livre. Porém o motivo principal desse acontecimento em projetos de software livre é a crença na “Lei de Linus”, descrita por Raymond [5] da seguinte maneira: “Dado uma base grande o suficiente de beta-testers e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém”.

Isso pode ser uma verdade em projetos de software livre detentores de comunidades ativas, entretanto não tem como os desenvolvedores garantirem a existência de uma grande quantidade de pessoas interessadas em colaborar com a evolução do software para fazer assim valer a Lei de Linus. Dessa maneira é muito perigosa essa falta de atenção à utilização de ferramentas nas fases de back-end do desenvolvimento.

Controvérsia
No fato 31 a maior controvérsia está relacionada à descrença de que a remoção de erros gaste tanto tempo do processo de software. Porém, segundo Glass [1], em média 20% do tempo do processo é gasto com a análise de requisitos, outros 20% projetando, mais 20% codificando e impressionantes 40% removendo erros. O dobro gasto em cada uma das outras fases.

Considerando que desenvolver software é uma tarefa complexa e propensa a erros, é muito improvável que surjam técnicas para a construção de software que o livre de erros a serem removidos nos testes, porém fica claro pelos estudos de Glass que ao focar mais atenções na essência do problema a ser resolvido, o número de erros cai consideravelmente.

No fato 32, a maior controvérsia está relacionada à noção de softwares isentos de erros. Muitos especialistas consideram ser possível isso ser feito, embora na prática isso só aconteça geralmente para software de pouca complexidade. O objetivo ideal para projetos de software complexos é realização de testes que garantam que o software esteja isento de erros críticos.

Muitas equipes não dão a atenção adequada para a fase de testes de software e a grande maioria não utiliza nenhuma ferramenta que analise automaticamente a cobertura dos testes já realizados na estrutura. Essa falta de motivação para utilizar ferramentas que automatizem a analise de cobertura geralmente ocorre por não acharem viável investir recursos para isso ou até mesmo pelo desconhecimento dessas ferramentas.

O Emma é uma ferramenta open source que ajuda nesta tarefa, fazendo a análise da cobertura de testes de um projeto Java e gerando um relatório em formato texto ou HTML. Esse relatório representa um feedback importante para os desenvolvedores, pois indica quais áreas do projeto ainda não estão sendo cobertas por testes automatizados e portanto devem ser tratadas prioritariamente [2].

A figura 1 apresenta um exemplo de relatório gerado pela ferramenta Emma. Esse relatório informa a porcentagem de cobertura de teste em cada parte da estrutura de um software. 

Figura 1: Relatório HTML para cobertura de teste no Apache Velocity 1.4

Para maiores informações sobre a ferramenta Emma, consulte o site oficial da mesma em [3].

A controvérsia ao fato 33 é referente ao desconhecimento da informação dada pelo mesmo. A pesquisa realizada por Glass que o proporcionou chegar a tal conclusão não foi devidamente divulgada, sendo assim muitos pesquisadores discordaram desse fato por desconhecerem a pesquisa.

Não existe bala de prata capaz de proporcionar o desenvolvimento de um software isento de erros, porém a combinação das abordagens de testes, juntamente com uma maior atenção demandada à essência do software, proporciona softwares com o menor número de erros.

Existem poucas controvérsias a respeito do fato 34. Talvez o motivo disso não seja relacionado à concordância ou discordância com o fato, mas sim com a falta de interesse nele.

Referências
[1] Glass, Robert L. 1992. Software Quality Building. Englewood Cliffs, NJ: Prentice-Hall. Englewood Cliffs, NJ: Prentice-Hall.

[2] TELES, V. M. Cobertura de Testes na Prática. Disponível em : http://www.devmedia.com.br/articles/viewcomp.asp?comp=8973. Acesso em 22 Maio. 2010.

[3] EMMA: a free Java code coverage tool. Disponível em: http://emma.sourceforge.net/index.html. Acesso em 22 Maio. 2010.

[4] Zhao, Luyin e Elbaum Sebastian. "A Survey on Quality Related Activities in Open Source." Software Engineering Notes, May. 2000.

[5] RAYMOND, E.S. The Cathedral and Bazaar. O’Reilly Books, 1999.

O que é uma Infraestrutura de Dados Espaciais?

Dentre os diversos temas que estudei e continuo estudando no mestrado, um dos que mais li a respeito e passei a conhecer melhor foi IDE. Não falo exatamente daquele cabo de transferência de dados do HD (Integrated Drive Electronics), muito menos de um ambiente de desenvolvimento de software (Integrated development environment), estou falando mais precisamente sobre Infraestrutura de Dados Espaciais.

O que é uma IDE? 
Esse termo surgiu no início da década de 90 nos EUA devido a necessidade de se ter acesso a informação geográfica padronizada e desde então vem sendo cada vez mais debatido e recebido investimentos em escalas globais, regionais, nacionais, estaduais e municipais. O  US  Federal Geographic Data Committee define IDE como um conjunto de tecnologias, políticas, pessoal e atividades correlatas, necessárias para adquirir, processar, distribuir, utilizar, manter e preservar os dados espaciais em todos os níveis de governo, setor privado, terceiro setor e também o meio acadêmico.

Assim como toda região civilizada possui infraestruturas elétrica, de água, esgoto, telefone e etc... para fornecer acesso a esses respectivos recursos para a população, uma IDE serve para fornecer acesso a informações geográficas.

O desenvolvimento de uma região esta diretamente relacionado com a utilização adequada de recursos. Tendo posse de informações geográficas precisas, é possível realizar planejamento estratégico em diversos aspectos. Vamos imaginar que estudos consigam prever com antecedência a ocorrência de um desastre natural em uma determinada região e que existam informações geográficas disponíveis para estudos sobre a área que será atingida. A partir dessas informações é possível traçar diversas medidas estratégicas como rotas de fuga para a população, possíveis locais seguros para estabelecimento de abrigos e tomar outras medidas preventivas de maneira a minimizar o número de mortes e prejuízos materiais.

É importante destacar que não basta simplesmente distribuir a informação geográfica, ela precisa seguir padrões definidos pela IDE em que ela é disponibilizada. Devido a diferenças políticas e culturais, é muito comum que IDEs pelo mundo sigam padrões diferentes, dessa maneira torna-se um grande desafio a criação de IDEs de âmbitos maiores como nacionais ou continentais (regionais), pois é necessário que os nodos menores (municipais e estaduais) sejam compatíveis com os nodos maiores. Esse processo envolve principalmente as questões políticas e é ai que mora o grande problema...

Para ilustrar essa situação posso citar como exemplo o problema enfrentado pela Europa em 2002 com as inundações no Rio Danúbio. O Rio Danúbio é o 2º maior da Europa, fluindo por 2857 km e cortando 16 países europeus. Em 2002 inundações no Danúbio causaram 700 mortes, desabrigou 500 mil pessoas e causou prejuízos de €25 bilhões. Por mais que alguns países europeus já possuíssem iniciativas de IDE nessa época, não foi o suficiente para traçar medidas estratégicas preventivas mais eficientes, pois essas IDEs seguiam padrões diferentes que inviabilizavam um planejamento em escala continental.

Atualmente a Europa passa por um processo de criação de sua IDE continental, a INSPIRE. A iniciativa INSPIRE começou em meados de 2000 e está prevista para ficar pronta somente em 2019. Esse é um projeto muito audacioso e complexo, se já é complicado pensar em padronização a nível nacional, imaginem a nível continental! Vários fatores estão envolvidos nesse processo, mas isso já é tema para uma futura postagem.

Para terminar essa postagem eu gostaria de falar rapidamente a respeito de uma IDE que estamos desenvolvendo no Departamento de Informática da UFV, a IDE GeoMINAS. Esta é uma IDE de âmbito estadual que surgiu a partir de um projeto de reestruturação do portal de dados do Projeto GeoMINAS, sendo assim ela disponibiliza os dados espaciais disponíveis no antigo site do GeoMINAS porém agora documentados de acordo com o padrão de metadados (Perfil MGB) da Infraestrutura Nacional de Dados Espaciais (INDE), IDE brasileira lançada no ano passado.

O antigo projeto GeoMINAS foi uma iniciativa pioneira na disponibilização de dados espaciais em âmbito estadual. Ele foi articulado por um grupo de instituições sediadas no estado de Minas Gerais mas acabou abandonado devido a falta de apoio político.

Para quem tiver interesse em conhecer a IDE GeoMINAS, ela encontra-se disponível em: http://www.ide.ufv.br/geominas

Futuramente falarei mais sobre IDEs por aqui. Em caso de dúvidas e sugestões comentem!

Fatos e falácias de Engenharia de Software - Requisitos de Software

Pra compensar o tempo sem muitas novidades por aqui, vamos logo retomar às discussões sobre pontos chave da Engenharia de Software.

Depois de abordar tópicos importantes como Reutilização, Estimativas e Profissionais, discutiremos nessa postagem sobre Requisitos de Software, nada mais nada menos que a espinha dorsal de todo o processo de desenvolvimento!

Para quem já vem acompanhando as discussões anteriores relacionadas a Engenharia de Software, acredito que aos poucos está ficando mais claro a relação existente entre os temas discutidos. Isso proporcionará uma visão crítica muito importante sobre todo o processo de desenvolvimento de software.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo nº. 04

Fatos
23 - Um dos dois motivos mais comuns de projetos saírem de controle são os requisitos instáveis.
24 - Requisitos errados são mais caros para reparar quando encontrados durante a produção, porém são mais baratos para corrigir no início do desenvolvimento.
25 - Requisitos ausentes são os erros de requisitos mais difíceis de corrigir.

Discussão
Os fatos estudados estão relacionados a problemas com requisitos de software e os impactos causados por eles no andamento de um projeto.

O fato 23 trata especificamente de requisitos instáveis. Segundo Glass [1], requisitos instáveis, juntamente com estimativas pobres e muito otimistas, são as principais causas dos projetos de software saírem de controle. Os problemas causados por estimativas falhas não são diretamente relacionados ao desenvolvimento de software, mas sim à gerência. Já os problemas ocasionados por requisitos instáveis são de desenvolvimento de software e são mais complexos de serem resolvidos que os outros.

Grande parte dos problemas causados por requisitos instáveis são gerados por clientes e usuários não entenderem o problema real que desejam solucionar com o software a ser desenvolvido.

Comparada a outras engenharias, como a civil, por exemplo, a engenharia de software é um tópico relativamente novo, portanto é normal que tantos problemas por requisitos instáveis existam, haja vista que muitas das soluções propostas por software ainda são inéditas, e quando esse tipo de solução está em desenvolvimento, o fato de não ter um padrão de comparação com algo já feito pra mesma finalidade, acaba gerando grandes incertezas.

Muitas soluções para requisitos instáveis foram tentadas ao decorrer dos anos. Inicialmente achava-se que o congelamento dos requisitos resolveria tais problemas e assim surgiu a proposta de especificação de software a partir de notações matemáticas, os chamados métodos formais. Segundo Sommerville [2], métodos formais oferecem a possibilidade de analisar através do emprego de cálculos matemáticos a consistência e provar que a implementação de um software corresponde à especificação.

Na prática observou-se que o congelamento dos requisitos, assim como a utilização de métodos formais de especificação de software não são eficientes para resolver o problema de requisitos instáveis, pelo contrário, eles podem atrapalhar e muito devido ao engessamento do processo.

Com o tempo ficou claro que para lidar com requisitos instáveis, o projeto teria que ficar em constante refinamento em busca da desejada estabilidade conceitual. Para isso o uso de protótipos da solução é uma boa prática, pois nem sempre o cliente sabe o que quer, mas geralmente sabe o que não quer. Nesse sentido, todo contato do cliente com novos protótipos gera o refinamento dos requisitos já levantados, pois o feedback do cliente com relação ao protótipo serve para direcionar a equipe de desenvolvimento a um caminho cada vez mais próximo do ideal.

Muitas técnicas surgiram com intuito de inserir cada vez mais os usuários no processo de desenvolvimento do software, especialmente no levantamento de requisitos. JAD (Joint Application Development) é uma dessas técnicas. Ela foi criada pela IBM na década de 70 e propõe que clientes/usuários e desenvolvedores trabalhem juntos em reuniões com objetivo de identificar o problema a ser resolvido pelo software, propor elementos de solução, negociar diferentes abordagens e por fim, especificar um conjunto preliminar de requisitos de solução [3]. A metodologia XP (eXtreme Programming) também prevê dentre suas várias propostas, uma interação semelhante entre cliente e desenvolvedor com o intuito de entender melhor o problema e levantar requisitos mais refinados, porém ambas as propostas devem ser muito bem aplicadas para atingirem sucesso, pois de nada adianta se o usuário/cliente escalado para participar do processo não tiver pontos de vista equivalentes ao da maioria dos clientes e usuários potenciais do software.

O desenvolvimento de software baseado em processos auxilia muito na gerência de projetos de software com requisitos instáveis, pois para lidar com tantas requisições de mudanças, é muito importante a gestão ter um processo de gerenciamento de mudanças bem definido. Dessa forma, toda requisição de mudança passa a ser analisada detalhadamente, observando todos os impactos que ela causaria no projeto e nível de custos, tempo e riscos. Após essa análise, a gerência pode tomar a decisão precisa juntamente com o cliente, avaliando se as mudanças solicitadas são viáveis ou não, evitando assim que o projeto saia de controle por uma decisão imprópria.

O fato 24 é um senso comum entre todos envolvidos com projetos, sejam eles de software ou não. Quanto mais cedo requisitos errados forem identificados, menos custoso será para corrigi-los. A correção de erros durante o desenvolvimento pode ser até 100 vezes mais custosa do que as correções feitas nas fases iniciais do processo [4]. A Figura 1, presente em [5], representa exatamente a ordem de crescimento dos custos para correções ao decorrer do progresso de um projeto.

Figura 1: Custos para correção de erros.
Para diminuir os custos com as mudanças e correções, o ideal é refinar os requisitos do projeto o quanto antes possível. Para isso, várias técnicas podem ser usadas e o feedback do cliente nas fases iniciais é de extrema importância para evitar que problemas sejam detectados em fases muito avançadas da produção acarretando em custos e riscos elevados.

O fato 25 trata de algo interessante para refletir, que são os requisitos omitidos de software. Segundo o autor, um dos erros de requisitos mais difíceis de serem corrigidos é o de requisitos ausentes. Existem diversas técnicas de testes dos requisitos para identificar se eles correspondem ao que se espera do software, porém, um requisito não levantado, conseqüentemente também não será testado, porque teoricamente ele não existe.

Requisitos são levantados de diversas formas, mas de forma geral, o processo de levantamento de requisitos se baseia em interações de pessoas e análises de documentos. Devido à alta subjetividade dessas atividades, o risco de que algum requisito do cliente seja desconsiderado no levantamento está sempre presente.

Segundo o estudo realizado pelo autor, 30% dos erros de software são oriundos de lógicas omitidas de programação. Esse tipo de omissão é geralmente causada por requisitos não levantados. Testes geralmente baseiam-se em requisitos presentes no projeto, portanto, esses erros acabam passando despercebidos nos testes. A dificuldade de identificação desse tipo de erro acaba tornando-os difíceis de serem corrigidos.

Para tornar a análise de requisitos mais eficiente, o levantamento deve ser feito de forma iterativa, pois dessa forma a idéia sobre o problema principal a ser resolvido ficará mais madura e conseqüentemente os analistas passam a ter uma visão mais crítica sobre o problema, identificando os requisitos mais facilmente assim. A interação entre os analistas também é muito importante, pois a troca de informações entre diferentes pontos de vista pode também aumentar essa visão crítica de todos envolvidos.

Controvérsia
Existem poucas controvérsias sobre o fato 23. Antigamente a controvérsia principal a ele era com relação ao congelamento dos requisitos. Hoje é raro encontrar quem discorde de que o congelamento de requisitos é sinônimo de falhas no projeto.

Atualmente a principal controvérsia ao fato 23 gira em torno da utilização de métodos formais para especificação de software. Na prática eles são pouco utilizados pelos profissionais de software, porém a academia ainda defende a “eficiência” de sua aplicação.

Como o fato 24 é um consenso geral, praticamente não existem controvérsias ao seu respeito. As únicas divergências ao fato 24 são relacionadas às formas de evitar que erros demorem a ser detectados. Existem diversas maneiras de fazer isso, porém dependendo da função que determinada pessoa exerce no processo de desenvolvimento, elas tendem a optar por métodos específicos relacionados a tal função.

A dificuldade para identificar e distinguir entre os tipos de erros cometidos acaba gerando poucas controvérsias sobre o fato 25.

Referências
[1] Glass, R. Facts and Fallacies of Software Engineering. Addison Wesley. October 2002.

[2] SOMMERVILLE, I. Software Engineering, 5th edn, Addison-Wesley Publishing Company, Wokingham England. 1996.

[3] GUIMARÃES, E. C. F. O uso da técnica JAD - Joint Application Design para levantamento de requisites. Disponível em: . Acesso em 7 Maio. 2010.

[4] Boehm, Barry, and Victor R. Basili. 2001. "Software Defect Reduction Top 10 List." IEEE Computer, Jan. "Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design stage."

[5] ANDERSON, K. M. Lecture 04: Software Process, Part 1. Disponível em: http://www.cs.colorado.edu/~kena/classes/5828/s07/lectures/04/index.html. Acesso em 7 Maio. 2010.

Fatos e Falácias de Engenharia de Software - Reutilização

Após quase um mês sem atualizações aqui, estou voltando a postar continuando a seqüência de temas relacionados a Engenharia de Software. Nessa postagem irei abordar um tema que muito me agrada e que tem relação indireta com minha pesquisa: Reutilização no processo de desenvolvimento do software.

Digo que tem relação indireta pois minha pesquisa envolve bastante sobre Padrões de Análise, que basicamente proporciona reutilização conceitual no processo de software, enquanto que na discussão dessa postagem irei abordar mais especificamente a reutilização de código.

Futuramente estarei postando também sobre Padrões de Análise por aqui, mas enquanto isso vamos ao nosso texto de hoje.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo no. 03

Fatos
15 - Reutilização em pequena proporção (bibliotecas de sub-rotinas) começou há quase 50 anos e é um problema bem resolvido.
16 - Reutilização em grande proporção (componentes) continua sendo um problema na maior parte não resolvido, embora todos concordem que é importante e desejável.
17 - Reutilização em grande proporção funciona melhor nas famílias de sistemas conexos e, portanto, é dependente do domínio. Isso restringe a aplicabilidade potencial desse tipo de reutilização.

Discussão
Ambos os fatos estudados tratam da Reutilização, sendo que cada um deles aborda o tópico por visões distintas. Atualmente muito se fala em reutilização de código, sendo que muitos tratam dessa técnica como se ela fosse novidade. O próprio paradigma de programação orientada a objetos coloca a reutilização como uma das suas grandes inovações. O fato 15 mostra que na verdade Reutilização de código é um conceito que surgiu na década de 50 com a Organização Share [1]. A proposta da Organização Share foi a de criar um espaço semelhante a uma biblioteca tradicional, porém lá ao invés de livros, os programadores compartilhavam códigos de programação de uso freqüente, e sempre que precisavam implementar algo que achavam que alguém poderia já ter feito antes, consultavam a biblioteca de códigos para evitar o retrabalho. Dentre esses códigos de uso comum que eram compartilhados, são exemplos funções para realização de operação matemáticas, funções de ordenação e busca de valores.

Com o passar dos anos a idéia de reutilização em pequenas proporções tornou-se muito difundida e ficou claro que isso agiliza muito o desenvolvimento. A maioria das linguagens mais utilizadas atualmente possui vastas bibliotecas de códigos definidos para diversos domínios comuns, como por exemplo, as conexões com os variados tipos de SGBDs.

As bibliotecas das linguagens geralmente possuem funções que já foram exaustivamente testadas e amplamente utilizadas, passando assim um alto grau de confiabilidade. Portanto é muito mais eficiente em termos de agilidade na implementação e até mesmo de segurança (dependendo do domínio), utilizar funções pré-definidas nas bibliotecas do que ter o trabalho de fazer algo já existente.

O fato 16 trata da reutilização de código em grandes proporções, a chamada engenharia de software baseada em componentes. Essa proposta prega que softwares podem ser montadas unicamente a partir de união de “peças” já existentes (componentes), escolhidos mediante a especificação dos requisitos. Essa idéia nos leva a pensar em uma verdadeira linha de montagem de software, porém na prática isso não acontece exatamente assim.

Essa idéia de reutilização de componentes (reutilização de códigos em grande proporção) também não é nova, mas ao contrário da reutilização de bibliotecas de sub-rotinas comuns (reutilização de códigos em pequena proporção), ela nunca se tornou algo utilizado em grande escala. A discussão do fato 16 é basicamente a respeito do motivo pelo qual isso nunca aconteceu, mesmo sabendo-se que na teoria é algo que traria avanços significativos de produtividade no processo de desenvolvimento de software.

O problema maior da criação de componentes reutilizáveis, é que eles devem ser genéricos o suficiente para atender a qualquer domínio. Porém há grandes diferenças de exceções entre os domínios. Embora alguns problemas grandes quando analisados superficialmente possam parecer semelhantes, há uma série de restrições para as possíveis soluções quando analisamos os mesmos problemas em domínios diferentes.

O fato 17 trata de algo extremamente realista e menos utópico que a reutilização de componentes totalmente genéricos. A grande barreira que impede a disseminação da reutilização em grandes proporções são as sutilezas que diferem os domínios. Elas dificultam muito na criação de componentes genéricos que atendam a todos os domínios de forma eficiente. Porém quando se trata de componentes aplicados a um mesmo domínio de problemas, a chance de sucesso aumenta consideravelmente [4].

Os estudos realizados pelo Software Engineering Laboratory (SEL), da NASA-Goddard [2] exemplificam bem essa afirmação, haja vista que 70% dos softwares desenvolvidos por eles dentro do domínio específico de dinâmica de vôos reutilizaram componentes com sucesso.

Grandes empresas como a Microsoft utilizam desses conceitos em seus softwares principais. Plataformas como o pacote Office e o sistema operacional Windows, são desenvolvidas atualmente reutilizando-se de diversos componentes que foram sendo implementados pela empresa ao decorrer dos anos. A cada nova versão, grande parte dos componentes anteriores é reutilizada e inovações são acrescentadas, gerando assim novos componentes que serão reutilizados posteriormente.

Esse processo de reutilização também torna o processo de desenvolvimento de uma empresa cada vez mais maduro, montando uma espécie de linha de montagem de software, mas é importante observar que o domínio de aplicação desses componentes acaba sendo bem restrito para alcançar tal eficiência na sua aplicação.

Controvérsia
A principal controvérsia do fato 15 é relacionada ao desconhecimento da história da reutilização. Principalmente após a difusão do paradigma de programação orientada a objetos, muito começou a se falar sobre reutilização de código como uma grande inovação. O conceito de reutilização de código não é novo como muitos entusiastas imaginam e já existia muito antes de orientação a objetos por exemplo.

Existem muitas controvérsias entre as tentativas de explicações para o fato 16. Enquanto alguns vêem a engenharia de software baseada em componentes como o futuro, outros são completamente céticos com relação a sua aplicação real.

O NASA's Goddard Space Flight Center [2] realizou durante anos estudos relacionado ao desenvolvimento de softwares específicos baseados em componentes. Cerca de 70% dos softwares desenvolvidos dentro do domínio de atuação do NASA-Goddard foram construídos com reutilização de componentes, um número alto, mas que não pode ser interpretado de qualquer maneira. A eficiência da reutilização de componentes nesse caso foi devido à semelhança real dos softwares. Softwares de um mesmo domínio tendem a terem restrições semelhantes, portanto a generalização eficiente dos componentes fica facilitada.

Outro motivo levantado para a possível não adoção em massa da reutilização em grande proporção, é a chamada síndrome do “Não-Inventado-Aqui” (NIH em inglês). Essa síndrome seria comum a profissionais teimosos que acreditam ser mais complicado administrar algo não criado por eles mesmos.

De uma maneira geral, não se pode afirmar que a engenharia de software baseada em componentes é boa ou ruim, para isso é necessário analisar o contexto. Devido às diferenças entre os diversos domínios, é muito complicado que a criação de componentes totalmente genéricos seja eficiente para aplicação em todos os casos, mas em casos específicos eles podem ser extremamente eficientes. Muitos autores, assim como GLASS [3], acreditam que a reutilização de código em grandes proporções não chegará a ser tão difundida e comum quanto a de pequenas proporções, mas essa visão embasa-se na sua complexidade e não na qualidade da proposta.

As controvérsias ao fato 17 são referentes às pessoas entusiastas da reutilização em grandes proporções da forma mais genérica possível, abrangendo a domínios de qualquer espécie. Essas pessoas acabam tendo esse tipo de visão por desconhecerem as diferenças entre os domínios, pois essas diferenças impossibilitam uma maior eficiência na resolução de problemas comuns a domínios distintos utilizando componentes totalmente genéricos.

Referências Bibliográfica

[1] SHARE Inc. About SHARE. Disponível em: http://www.share.org/AboutSHARE/tabid/65/Default.aspx Acesso em 10 Abr. 2010.

[2] NASA-Goddard Space Flight Center. About the Goddard Space Flight Center. Disponível em: http://www.nasa.gov/centers/goddard/about/index.html Acesso em 10 Abr. 2010.

[3] GLASS, R. Facts and Fallacies of Software Engineering. Addison Wesley. October 2002.

[4] McBREEN, Pete. Software Craftsmanship. Boston: Addison-Wesley. Says "cross-project reuse is very hard to achieve." 2002.

SCRUM + Customização de Processos

Segunda-feira (21/03/2011) tive o prazer de proferir uma espécie de palestra para a turma de Engenharia de Software do mestrado em Ciência da Computação da UFV a convite do professor José Luis Braga. Nessa palestra abordei métodos ágeis e customização de processo de software utilizando especificamente SCRUM + RUP + Parte do MPS.br nível G.

Mesmo para quem não assistiu a apresentação, vale muito a pena dar uma olhada no material disponibilizado abaixo com calma pois ele é bem auto-explicativo e abrange principalmente o SCRUM de maneira ampla. Em caso de dúvidas, sugestões, críticas...etc, comentem por ai pessoal.

Scrum + Customização de Processos

View more presentations from Lucas Vegi

Fatos e Falácias de Engenharia de Software - Estimativas de projetos de software

Dando continuidade a seqüencia de postagens sobre temas polêmicos em engenharia de software, o tema da discussão dessa postagem será: Estimativas de projetos de software.

É impressionante como essa parte fundamental do processo de desenvolvimento de software ainda hoje seja realizada de maneira tão errônea e que sofra com influências tão negativas quanto às discutidas nesse resumo.

Caso alguém já tenha sentido na pele algum desses fatores negativos e queira compartilhar essa experiência ruim para enriquecer nossa discussão, não deixe de comentar.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo nº 2

Fatos Estudados
09 - A maioria das estimativas de software são realizadas no início do ciclo de vida. Isso faz sentido, até que percebemos que as estimativas são obtidas antes dos requisitos serem definidos e, portanto, antes do problema ser compreendido. Estimativa, portanto, ocorre geralmente na hora errada.
10 - A maioria das estimativas de software são feitas tanto pela alta gerência ou pelo marketing, não pelos profissionais que irão construir o software ou os seus gestores. Estimativa é, portanto, feita por pessoas erradas.
11 - Estimativas de software raramente são ajustadas conforme o andamento do projeto. Assim sendo, as estimativas feitas no momento errado, por pessoas erradas, geralmente não são corrigidas.

Discussão
Os fatos estudados analisam alguns problemas relacionados às estimativas de projetos de software. O nono fato trata do momento do processo de software em que as estimativas são traçadas. Ele apresenta um problema que pode soar absurdo nos dias de hoje, mas que na prática acontece em alguns projetos. Algumas equipes traçam as estimativas de tempo e custos de um projeto de software previamente ao levantamento de requisitos, algo que é completamente inaceitável, se considerarmos as melhores práticas de gestão de projetos de software. Após o levantamento e análise dos requisitos é que o problema a ser resolvido pelo projeto começa a ser realmente entendido, portanto, fazer estimativas antes na análise de requisitos é como dar um tiro no escuro, pois dificilmente a equipe terá argumentos sólidos onde se basear neste ponto de partida do ciclo de vida.

Segundo MARÇAL [2], em projetos gerenciados por Scrum, o cronograma é extraído do Product Backlog, sendo que as estimativas são feitas em dois níveis. Primeiro em alto nível, analisando cada requisito do Product Backlog para assim obter-se uma visibilidade geral do projeto e durante o processo são feitas estimativas de cada Sprint Backlog, oferecendo dessa forma uma visibilidade mais precisa de cada iteração.

O décimo fato é diretamente relacionado ao nono. Muitas das vezes as estimativas são traçadas no momento errado porque as pessoas responsáveis por elas também eram inapropriadas para tal. A alta gerência e/ou os responsáveis pelo marketing, na maioria das vezes não tem uma visão bem definida ou entendimento suficiente sobre qual é a importância dos requisitos e muito menos em como a alteração deles pode impactar sobre as estimativas do projeto todo. Sendo assim, ao invés dos profissionais de software (analistas, programadores, etc) serem os encarregados por traçarem as estimativas, baseando-se nos requisitos, dados históricos e outros fatores relevantes, quem acaba traçando as estimativas ao cliente são a alta gerencia e o marketing, pessoas geralmente desqualificadas para realizar tal tarefa. Por esse motivo essas pessoas acabam fazendo-a de forma errônea, geralmente considerando muito mais o desejo em detrimento ao que seria realmente possível.

Embora possa parecer absurdo que softwares profissionais sejam concebidos a partir de estimativas errôneas realizadas por pessoas inadequadas, os autores do estudo de CASE [1] mostram que impressionantes 70% dos softwares são concebidos dessa forma, com estimativas sendo definidas pelos usuários (clientes) e apenas 4% das estimativas são realizadas pela equipe do projeto.

O fato 11 relaciona-se aos dois anteriores, acrescentando ainda mais acontecimentos que fogem ao padrão. Considerando que as estimativas são geralmente traçadas no momento errado e por pessoas inapropriadas, o resultado final só poderia ser um projeto mal estimado e que não atende à realidade, porém, por incrível que pareça, a alta gerência além de traçar suas estimativas erroneamente, ignorando fatores como a complexidade do projeto e o custo real para atender aos requisitos, dificilmente ela permite mudanças de cronograma, obrigando assim a equipe de desenvolvimento a trabalhar o quanto for necessário para atender aos seus desejos.

Controvérsia
Dificilmente alguém conseguirá apresentar uma controvérsia ao nono fato, haja vista que antes de detalhar o que será desenvolvido, o risco de traçar uma estimativa errada é muito alto e pode ser determinante para um projeto fracassar. Mesmo em equipes que já possuem ampla experiência em diversos tipos de projetos, traçar uma estimativa analisando superficialmente um problema e comparando-o a outros projetos “semelhantes” já realizados pela equipe é algo perigoso, pois mesmo que exista muitos pontos em comum entre eles, os pequenos pontos que divergem podem impactar em vários outros, gerando assim um “efeito dominó” que impossibilita a precisão dessa estimativa por comparação superficial de semelhanças.

Controvérsias para o décimo fato também são difíceis de serem citadas, pois é claro que para traçar estimativas de software, precisa-se ter conhecimento de causa e basear-se e referências concretas a fim de dar uma visibilidade mais precisa do projeto, e somente as pessoas ligadas diretamente a ele (programadores, analistas, etc) tem essa capacidade. Tanto a alta gerência quanto o marketing, geralmente só são capazes de traçar estimativas baseadas nos negócios, nos desejos comerciais e não no processo em si.

Geralmente as estimativas traçadas pela alta gerência são motivos de discórdia entre os membros da equipe de desenvolvimento, porém quando a equipe é questionada pela alta gerência sobre o que daria pra ser feito no tempo estimado, freqüentemente essa resposta não é dada com precisão pela equipe, o que acaba gerando desconfiança na alta gerência sobre a capacidade da equipe traçar estimativas, entretanto isso é um erro. Possivelmente as equipes têm dificuldade em dar precisão para a alta gerencia sobre o que seria capaz de fazer em determinado tempo devido a esse questionamento ser feito em momento inoportuno, como por exemplo, antes do conhecimento detalhado dos requisitos.

A controvérsia ao fato 11 chega a ser injusta. As estimativas traçadas no momento errado e por pessoas erradas tendem a gerar cronogramas impossíveis de serem cumpridos a risca, pois como eles são feitos considerando geralmente apenas o desejo da gerencia e não a complexidade real do problema a ser resolvido e os prazos previstos, na maioria das vezes acabam não sendo cumpridos e custos adicionais podem ser gerados por esse descumprimento. A culpa principal desses acontecimentos é dos responsáveis pelo estabelecimento das estimativas (alta gerência ou marketing), porém quem realmente leva a culpa é a equipe, que na verdade é a maior vítima de toda a situação.

Analisando os fatos apresentados de forma ampla, percebe-se que existem poucas controvérsias a respeito deles, isso é ocasionado devido ao consenso geral no qual eles estão inseridos. Todos os profissionais de software sabem na realidade quem deve fazer as estimativas dos projetos, o que deve ser levado em consideração para tal, quando as estimativas devem ser traçadas e no caso de falhas ao estimar, medidas corretivas devem ser tomadas no cronograma e informadas aos stakeholders. Infelizmente na prática essas questões não são respeitadas devido a políticas empresariais internas pouco evoluídas.

Referências bibliográficas
[1] CASE. "CASE/CASM Industry Survey Report." HCS, Inc., P.O. Box 40770, Portland, OR 97240. 1991.

[2] MARÇAL, Ana Sofia; FREITAS, Bruno Celso C.; FURTADO, Felipe; MACIEL, Teresa; BELCHIOR, Arnaldo Dias. Estendendo o SCRUM segundo as áreas de processo de gerenciamento de projetos do CMMI. 2007 Disponível em: http://www.cesar.org.br/files/file/SCRUMxCMMI-CLEI-2007.pdf. Acesso em 27 mar. 2010.

Fatos e falácias de Engenharia de Software - Profissionais de software

Carnaval chegando, pessoal se preparando para cair na folia e inspirado nessa animação, nada melhor do que discutirmos um pouco sobre engenharia de software não é pessoal?!

Hoje estou dando início a uma sequência de postagens com discussões sobre temas diversos englobados pela engenharia de software. Boa parte dessas discussões são fruto da minha opinião a respeito de partes do livro "Facts and Fallacies of Software Engineering" escrito por Robert L. Glass em 2003. Esse é um livro muito interessante e de leitura super agradável que recomendo a todos que tiverem interesse em se aprofundarem nessas discussões.

Para auxiliar aos mais interessados no tema, segue abaixo partes do livro de Glass disponibilizada pelo Google Books:


Nessa primeira discussão expresso minha opinião a respeito de alguns tópicos que envolvem diretamente os Profissionais de software e seus respectivos Ambientes de trabalho. Espero comentários e críticas para enriquecermos nossos conhecimentos a respeito desse tema.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo no. 1
Fatos estudados
1 - O fator mais importante no trabalho com software não são as ferramentas e técnicas utilizadas pelos programadores, mas sim a qualidade dos próprios programadores.
3 - Adicionar pessoas a um projeto atrasado faz atrasá-lo mais ainda.
4 - O ambiente de trabalho tem um profundo impacto sobre a produtividade e a qualidade do produto
6 - Aprender uma nova ferramenta ou técnica realmente reduz a produtividade do programador e qualidade do produto inicialmente. O benefício final é alcançado somente após a curva de aprendizagem ser vencida. Portanto, vale à pena adotar novas ferramentas e técnicas, mas apenas (a) se o seu valor é visto de forma realista e (b) se paciência é usada na medição dos benefícios.

Discussão
Ambos os fatos analisados tratam de temas pouco tangíveis por serem relacionados a pessoas.

O primeiro fato trata da importância dos profissionais (analistas e programadores) no desenvolvimento de software. Por questões culturais, muitos engenheiros de software ainda consideram as ferramentas e técnicas empregadas no desenvolvimento de software sendo mais importantes que a qualidade dos profissionais que as utilizam, mesmo sendo a importância da qualidade dos profissionais um objeto de muitos estudos há anos, como relata PRESMAN [5].

Gerenciar ferramentas e metodologias a serem aplicadas no desenvolvimento de software é algo mais tangível que o gerenciamento de pessoas, por esse motivo as empresas tendem a dar maior atenção à quais ferramentas e técnicas de desenvolvimento de software serão usadas em determinado projeto do que despenderem tempo com análises de motivação e perfil dos profissionais que serão alocados para o mesmo. Isso é um grande erro, pois de nada adianta empregar as melhores técnicas e usar as melhores ferramentas se o profissional que as utiliza não for competente para exercer suas atividades.

Para amenizar essa deficiência na gestão de pessoas, o SEI criou o PM-CMM, que nada mais é do que uma extensão do CMM, porém com foco exclusivo nesse tipo de gestão, tendo práticas como o treinamento de pessoal, recrutamento, desenvolvimento de carreira e remuneração [4].

O fato três é relacionado à adição de profissionais a projetos de software atrasados com intuito de acelerar o mesmo. Em processo de desenvolvimento de software isso não funciona muito bem, pois as atividades que envolvem esse tipo de processo são mais mentais do que mecânicas. Nesse sentido torna-se muito difícil um profissional ser inserido em um projeto que está em andamento e imediatamente render no mesmo ritmo dos outros profissionais que já participam do processo. Para ficar sintonizado com a equipe, esse profissional demandará uma maior atenção por parte dos outros e isso acarretará em atrasos e menor rendimento da equipe toda.

Baseando-se na análise de alguns relatórios de projetos open source, YILDIRIM [7] afirma que ocorre aumento na média das contribuições com o acréscimo de programadores nas fases iniciais dos projetos, e um declínio na fase adulta. Isso vem a ratificar a Lei de BROOKS [3].

O fato 4 deixa claro que de nada adianta ter a melhor equipe de programadores, usando as melhores ferramentas e técnicas de desenvolvimento de software se estes não estiverem em um ambiente propício ao trabalho que realizam. Interrupções e desvios de atenção causados por ambientes de trabalho tumultuados podem gerar muitos erros, haja vista que os trabalhos realizados em todas as etapas do desenvolvimento de software exigem muita atenção. Existem algumas iniciativas no sentido de controlar a qualidade do ambiente de trabalho, dentro elas vale ressaltar o PM-CMM, que contém diversas práticas em áreas de gestão de pessoas, sendo uma dessas áreas a de qualidade do ambiente de trabalho [4].

O fato 6 trata da curva de aprendizagem de novas ferramentas e técnicas de programação. Empresas investem em atualizar seus profissionais, possibilitando que os mesmos aprendam novas tecnologias aplicáveis aos seus respectivos processos de desenvolvimento de software, mas todo aprendizado tem seu custo, fazendo com que a produtividade e a qualidade dos produtos caiam inicialmente. Isso se deve a diversos fatores, dentre eles a insegurança e inexperiência dos profissionais ao aplicarem as novas tecnologias.

A qualidade dos profissionais e o ambiente de trabalho que ele está inserido podem influenciar muito no tempo gasto para uma equipe passar a dominar determinada técnica ou ferramenta e assim trazer benefícios a empresa, mas é muito difícil mensurar precisamente o esse tempo.

Segundo ANZANELLO [1], “A curva de aprendizado apresenta-se como uma ferramenta capaz de monitorar o desempenho de trabalhadores submetidos a tarefas repetitivas”. As atividades realizadas no desenvolvimento de software não são repetitivas e a aplicação das novas tecnologias pode acontecer de formas diversas, por esse motivo torna-se complicado precisar tempos.

O mais indicado a uma empresa que busca aplicar novos conhecimentos ao seu processo de desenvolvimento de software é a busca de informações com outros que já passaram pelo mesmo processo, pois esse confronto de informações relevantes poderá servir para que se tenha uma média aproximada de tempo que auxiliará nas tomadas de decisão dos gerentes.

Controvérsia
No fato 1, a controvérsia mais comum é o descaso de muitas empresas com relação a gestão de pessoas. Mesmo que a maioria delas tenha consciência da importância da qualidade do profissional no processo, ainda preferem ignorar esse fato e privilegiar os investimentos em ferramentas e novas técnicas. A proposta do PM-CMM criado pelo SEI é muito interessante no sentido de reverter tal situação, mas ainda está longe de ser tão difundida quanto o CMM.

Em controvérsia com o fato 3, RAYMOND [6] acredita que a adição de novos programadores a um projeto não necessariamente acarretará na diminuição do ritmo da equipe. Ele fez a afirmação conhecida como Lei de Linus “Dado uma base grande o suficiente de beta-tester e co-desenvolvedores, praticamente todo problema será caracterizado rapidamente e a solução será óbvia para alguém”.

A base dessa visão de Raymond vem de uma afirmação de Brooks, que diz que se as tarefas de um projeto são divisíveis, você pode dividi-las bastante e atribuí-las as pessoas que são adicionadas ao final do projeto e tem o perfil adequado.

Investimentos feitos em melhorias do espaço, divisão e organização do ambiente de trabalho são fáceis de serem medidos, o difícil é mensurar o quanto eles trazem de lucros. Isso gera uma controvérsia ao fato 4.

Muitos defendem que o ambiente de trabalho deve ser o mais calmo e amplo possível, dando privacidade ao profissional para assim ele conseguir ter uma maior concentração em suas atividades, evitando distrações geradas por diversos fatores, dentre eles o da aglomeração de pessoas em um espaço inadequado. O Extreme Programming vai contra boa parte desses conceitos, gerando assim uma grande controvérsia.

Segundo BECK [2], o XP prega o desenvolvimento de software em comunidade, para tal, o ambiente de trabalho convencional não atende aos requisitos necessários. Para a aplicação do XP, os computadores devem ficar aglomerados em um espaço comum a toda a equipe, evitando divisórias que separem os profissionais ou disposições muito espalhada dos móveis. O objetivo disso é fazer com que a equipe interaja mais, formando duplas que programam juntas e ao mesmo tempo conseguem ver o que a dupla do lado está fazendo, para se necessário também auxiliá-las. Essa interação traz ganhos tanto na identificação e solução de erros quanto no comprometimento da equipe com o projeto.

Existe um consenso geral de que todo aprendizado tem seu custo inicial, portanto é muito difícil haver controvérsias a respeito do fato 6. As empresas devem ter consciência de que é importante adotar novas técnicas e ferramentas para assim evoluírem seus processos e terem retornos, mas não devem de forma alguma achar que esse retorno será imediato, pois de fato ele não será.
Mesmo sendo difícil mensurar quando esses retornos virão, o feedback de outros que já adotaram as mesmas tecnologias é muito importante para traçar um planejamento e fazer projeções.

Referências bibliográficas
[1] ANZANELLO, M. J.; FOGLIATTO, F. S. Curvas de aprendizado: estado da arte e perspectivas de pesquisa. Gest. Prod., São Carlos, v. 14, n. 1, abril 2007 . Disponível em: http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-530X2007000100010&lng=en&nrm=iso. Acesso em 05 Mar. 2010.

[2] BECK, K. Programação extrema explicada: acolha as mudanças. Porto Alegre: Bookman, 2004.

[3] BROOKS, Frederick P., The Mythical Man Month: Essays on Software Engineering. Addison-Wesley, 1995.

[4] CURTIS, B. A Mature View of the CMM. American Programmer, Vol. 7, No. 9, pp. 19-28, set. 1994.

[5] PRESMAN, Roger S. Engenharia de Software. 5ª edição. Rio de Janeiro: McGraw-Hill, 2002.

[6] RAYMOND, E.S. The Cathedral and Bazaar. O’Reilly Books, 1999.

[7] YILDIRIM, H. Getting the Ball Rolling: Voluntary Contributions to a Large Scale Public Project. Journal of Public Economic Theory 8, 503-528. 2006.