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.

Discussão: Pesquisa no Brasil

O horário de verão acaba de terminar e em conseqüência disso meu dia foi acrescido em uma hora, sendo assim resolvi aproveitar um pouco desse tempo realizando a postagem de hoje.

Na primeira discussão postada aqui no blog fiz uma breve explicação falando que minha intenção era a de postar uma seqüência com 12 discussões, sendo 6 sobre Técnicas de Pesquisa em Ciência da Computação e 6 sobre tópicos em Engenharia de Software. Pois bem, hoje estou fazendo a sexta e última postagem (pelo menos por enquanto) sobre Técnicas de Pesquisa, abordando especificamente o tema: Pesquisa no Brasil. 

Continuem acompanhando o blog pois brevemente darei início às discussões sobre Engenharia de Software, que acredito irão proporcionar trocas de idéias interessantes por aqui também.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 600 - Técnicas de Pesquisa em Ciência da Computação
Resumo nº. 06
Os artigos estudados referem-se questões que envolvem a pesquisa no Brasil, questões relativas à transferência de conhecimento, propriedade intelectual e fontes de financiamento de projetos de pesquisa.

Diferentemente de outros países, as pesquisas realizadas no Brasil possuem um baixo índice de depósitos de patentes. Nos países desenvolvidos é muito comum que pesquisas realizadas na academia gerem patentes e posteriormente tenham esses resultados compartilhados com a indústria gerando assim novos produtos. Para usufruir desse conhecimento, geralmente são firmados contratos de exploração de conhecimento, onde a indústria paga royalties à academia pelo fato de estar utilizando tecnologia gerada pela mesma.

Essa maneira de conduzir as pesquisas voltadas à patentes e o posterior compartilhamento com a indústria mediante a compensação financeira é muito benéfica para ambos os lados. A indústria lucra por estar usufruindo de conhecimentos e invenções inovadores que são agregadas aos seus produtos, produzindo um grande diferencial de mercado, enquanto que a academia passa a ter cada vez mais recursos financeiros que proporcionam a realização de pesquisas cada vez mais importantes e de impacto, gerando assim um grande ciclo virtuoso.

No Brasil vários fatores influenciam para que pesquisadores gerem poucas patentes, principalmente fatores culturais, burocráticos e financeiros. No nosso país é comum que na academia a mistura de papeis com a indústria seja vista com certo preconceito. Algumas vertentes mais tradicionalistas de pesquisadores acreditam que a transferência de conhecimento da academia para a indústria não seja algo benéfico para a academia. Com relação a burocracia, enquanto pedidos de patentes em outros países demoram cerca de 2 anos para serem atendidos, no Brasil esse período pode ultrapassar os 10 anos. Financeiramente falando, nem todo pesquisador tem fundos suficientes para submeter um pedido de patente, pois o custo inicial desse processo é caro, custando em torno de U$7.000,00.

Uma forma de driblar limitações financeiras é a busca por agentes financiadores de pesquisa, como por exemplo, o FINEP, FAPESP, FAPEMIG, CAPES, entre outros.

De maneira geral, para obter-se sucesso na capitação de recursos para pesquisas, deve-se inicialmente estabelecer o que se pretende pesquisar, de que maneira, levantar a importância de realizar pesquisas com o tema proposto, estabelecer um cronograma, estimar custos e antecipar possíveis resultados obtidos pela equipe de pesquisadores também previamente definida. A partir dessas definições, uma busca criteriosa deve ser realizada com intuito de encontrar agentes financiadores que tenham um perfil adequado para a proposta de pesquisa.

Para encontrar os agentes ideais, é importante que seja analisado se esses agentes já financiaram pesquisas semelhantes à proposta e se atualmente continua sendo de seu interesse financiar algo com o perfil proposto. Quanto mais tempo os pesquisadores se dedicarem a encontrar agentes financiadores com perfis específicos, maiores serão suas chances de captarem recursos para suas pesquisas.

Após levantamento prévio de possíveis agentes financiadores, é essencial que a elaboração do projeto que será proposto esteja estritamente dentro das normas e padrões exigidos por cada um, buscando sempre despertar interesse pela proposta, sendo claro, objetivo e ao mesmo tempo detalhista. Outro fator importantíssimo é a demonstração de seriedade, montando equipes de pesquisadores com credibilidade e atendendo os prazos estabelecidos.

Outro tema abordado nas leituras foi com relação ao direito autoral no Brasil, mais especificamente de software. Semelhante aos direitos autorais concedidos a autores de obras literárias que valem por 70 anos após sua morte, direitos autorais de software valem por 50 anos no Brasil. Muitos autores acreditam ser absurdo que o direito de software dure tantos anos, pois na prática essa duração é como se fosse infinita, haja vista que a tecnologia avança de maneira muito acelerada e um software produzido a 50 anos atrás não agrega nenhum valor ao conhecimento da sociedade quando torna-se de domínio público. Isso é um fator prejudicial à inovação tecnológica e ao progresso científico do nosso país.

Referências

[1] CÂMARA, G. (2006). Grandes desafios da Computação: A construção de uma “terceira cultura”. Disponível em: http://www.dpi.inpe.br/gilberto/present/grandes_desafios_gilberto.ppt . Acessado em 28 nov. 2010.

[2] Handbook for Preparing and Writing Research Proposals. C.P. Patrick Reid. Vienna, Austria, IUFRO Special Programme for Developing Countries, 2000. - 164 p.

[3] LUCENA, Carlos José Pereira et al. Grandes Desafios da Pesquisa em Computação no Brasil - 2006-2016. Disponível em: http://goo.gl/fGCyq . Acessado em 28 nov. 2010.

[4] SOCIEDADE BRASILEIRA DE COMPUTAÇÃO. Computação Brasil, Porto Alegre, v. 20, p. 3-11, Jan./Fev.2006.

[5] SAKIYAMA, C. C. H. Captação de Recursos para Pesquisa: Elaboração de Projetos. Seminário Pós-Graduação Informática – UFV – 10 de Julho de 2007.

TCC: forNUT – Software Web para Análise Nutricional Infantil

"Até que enfim Lucas!"... Pois bem pessoal, não sei se algum leitor do blog pensou isso ao ver essa postagem, mas a verdade é que já a um bom tempo (mais de um ano) venho pretendendo postar meu trabalho de conclusão de curso aqui no mr. BIN mas por diversos motivos acabei deixando pra depois. Pois bem, para os que já haviam me cobrado e estavam esperando por essa postagem, o dia chegou! =D

Brincadeiras a parte, decidi compartilhar com vocês esse trabalho por entender que ele possa ser útil para alguém que esteja pesquisando e/ou trabalhando com temas correlatos. Ele foi realizado por mim como pré-requisito para obtenção do título de Bacharel em Sistemas de Informação pela Faculdade de Minas - FAMINAS em 2009. Tive como orientador o Professor Ricardo Esteves Kneipp e como Co-orientador o Professor Gustavo Willam Pereira.

A idéia para realização desse trabalho surgiu quando eu ainda estava no 4º período da graduação e ainda não tinha conhecimentos técnicos e científicos suficientes para realizá-lo. No entanto ao decorrer do curso a idéia foi amadurecendo, sendo aperfeiçoada e após bastante estudo e dedicação pude concluí-lo.

Para uma breve introdução sobre o tema desse trabalho, eis aqui o resumo do mesmo:

Resumo: Este trabalho apresenta o processo de desenvolvimento de um software de nutrição baseado no conceito de computação em nuvens. Este software tem o intuito de avaliar crianças de até 10 anos e prescrever planos alimentares. Ele foi projetado utilizando UML e o projeto foi gerido utilizando o método ágil de engenharia de software SCRUM. A implementação utilizou as linguagens de programação PHP e JavaScript, o SGBD MySQL e o servidor web Apache, todas essas, tecnologias de software livre

O forNUT encontra-se disponível em www.fornut.com.br, no entanto ainda em fase beta e com público restrito. Pretendo tocar esse projeto a frente quando estiver com mais tempo disponível e torna-lo totalmente aberto ao público...idéias novas para ele não me faltam.

Espero que esse trabalho possa servir de contribuição para outros e aguardo o feedback de quem por ventura dedicar um tempo de leitura para ele.

FORNUT – SOFTWARE WEB PARA ANÁLISE NUTRICIONAL INFANTIL