Pesquisa, projeto de pesquisa e erros comuns

Posted in off topic on February 8, 2010 by José Augusto Fabri

Uma pesquisa é caracterizada como um processo sistemático de construção do conhecimento que tem como principal objetivo gerar um novo conhecimento, refutar e/ou corroborar com um conhecimento existente. O ato de pesquisar culmina em um aprendizado em dois contextos: no pesquisador e na sociedade.

Na literatura é possível encontrar vários métodos de pesquisa, esse texto destaca alguns:

1 – Teórico conceitual: É fundamentado em percepções e discussões conceituais, a partir de literatura advinda de revisões bibliográficas e experiências que permitam arrazoar sobre modelos de conhecimento.  

2 – Pesquisa descritiva: tem como meta buscar a solução de problemas melhorando as práticas existentes. Análise e descrições objetivas, delineadas a partir de entrevistas com especialistas em um determinado domínio do conhecimento contempla esse método.

3 – Pesquisa Experimental: realiza teste das hipóteses através de um experimento controlado, projetado de forma a produzir dados necessários, podendo ser realizada em laboratório ou no próprio campo.

4 – Survey: Tem como objetivo coletar dados. A forma mais comum para coleta de dados é a entrevista utilizando questionários desenvolvidos para este fim. Ao contrário do que ocorre na pesquisa experimental, o pesquisador não intervém em nenhum momento na pesquisa. O Survey é considerado um método de pesquisa quantitativo, pois a análise dos dados exige um tratamento estatístico.

5 – Simulação: método alicerçado no uso de técnicas computacionais que permitam simular situações reais de funcionamento de sistemas.

6 – Pesquisa participante: baseado no método de observação participante, na qual pesquisadores estabelecem relações comunicativas com pessoas ou grupos da situação investigadas, com o intuito de serem bem aceitos.

7 – Pesquisa-ação: realizado juntamente com uma ação ou resolução de um problema, e onde os pesquisadores desempenham papel ativo nessa resolução.

8 – O método estudo de caso pode ser traduzido como a investigação de um fenômeno contemporâneo, dentro do contexto real, onde os limites entre o fenômeno e o contexto não são claros, e utiliza múltiplas fontes de informação.

O projeto de pesquisa é o documento que agrega as idéias de uma pesquisa que será realizada. Ele pode ser caracterizado como:

1 – uma carta de intenções através da qual o pesquisador apresenta sua proposta para uma instituição,

2 – um retrato de uma pesquisa em andamento,

3 – um precioso instrumento para o diálogo científico e acadêmico,

4 – um instrumento importante para a elaboração de idéias e para auto-esclarecimento de quem o produz,

5 – pode funcionar como um eficaz roteiro de trabalho ou instrumento de planejamento, e;

6 – pode desempenhar o importante papel de um instrumento direcionador da pesquisa.

Geralmente o desenvolvimento do projeto está ligado a um trabalho de conclusão de curso, a uma dissertação de mestrado, a uma tese de doutorado ou ao edital de um órgão de fomento.

Todo projeto de pesquisa deve possuir, no mínimo, os seguintes itens:

a) Introdução / Contextualização: apresente a área na qual você quer trabalhar. O crescimento desta área ao longo da história, algumas citações e definições também são itens importantes.

b) Justificativa: Quais são as necessidades levaram o surgimento desse trabalho, lembre-se que uma pesquisa deve gerar algum valor agregado para a sociedade.

c) Motivação: A palavra motivação pode ser interpretada da seguinte forma, motivo para ação. Nesta seção deixe bem claro quais foram os motivos que promoveram a sua ação na constituição do projeto de pesquisa.

d) Revisão literária: Responda as seguintes questões: Quais são as principais definições que permeiam o arcabouço conceitual que compõem o seu projeto? Quais são os principais autores que dialogarão com o seu tema?

e) Hipótese: A hipótese pode ser definida como uma teoria provável, porém não demonstrada. Sua hipótese pode ser considerada o fio condutor de sua pesquisa, ela norteará a revisão literária e o método de pesquisa a ser utilizado.

f) Metodologia: A metodologia de pesquisa é caracterizada em uma área de estudo dos métodos ou etapas de um processo. Este item deve contemplar uma explicação detalhada das ações que conduzirão a pesquisa. A escolha do método está intimamente ligada ao tipo da pesquisa.

g) Cronograma.

h) Recursos necessários.

i) Referências Bibliográficas.

Erros comuns em um projeto de pesquisa:

a) Falta de clareza nos objetivos.

b) Não respeitar a formatação imposta pelo edital da fonte de fomento.

c) Fazer solicitações fora do edital.

d) Confundir projeto de pesquisa com plano de trabalho. Lembre-se que o projeto deve possuir uma hipótese definida e alicerçada pela literatura. O plano de trabalho caracteriza-se em etapas menores a serem desenvolvidas, por exemplo: é necessário desenvolver um software que simule algo. O desenvolvimento do referido software não pode ser o foco principal da pesquisa.

e) Propor um projeto de pesquisa fora da área de conhecimento dos executores. Se você possui formação em engenharia de software, não proponha um projeto de pesquisa na área de redes.

f) Falta de conexão entre objetivos e metodologia.

g) Metas físicas e ou orçamento apresentado inexeqüível. É importante que o projeto de pesquisa seja algo finito.

Abraços

J. A. Fabri

fabri@femanet.com.br

Gerando estimativas no ambiente de desenvolvimento de software

Posted in gestão de projetos, processo de produção de software on January 19, 2010 by José Augusto Fabri

No segundo semestre de 2009 foi convidado a falar sobre estimativas em uma empresa da grande São Paulo. Ao chegar na empresa, fiz a seguinte questão à equipe de desenvolvimento:

- Qual a capacidade de produção de cada um de vocês?

- Resposta (já esperada), não sabemos.

Para gerar as estimativas no referido ambiente tracei a seguinte estratégia:

1) Fixei em uma parede uma folha de papel pardo, dessas que você compra nas livrarias.

2) Com um marcador de quadro branco desenhei uma grande tabela.

3) Na primeira linha da tabela grafei o nome do time dos programadores, veja o exemplo.

4) Distribui para cada programador algumas etiquetas, nela o programador tinha como incumbência grafar o seu nome, o projeto no qual estava participando, a funcionalidade que estava desenvolvendo (esta ligada ao projeto), a data e hora do início e do término do desenvolvimento.

5) Ao codificar a funcionalidade, cada programador colava as etiquetas na coluna de seu time.

6) O time que obtivesse o maior número de etiquetas em um determinado período (pré-estipulado), vence o campeonato.

7) Selecionei um estagiário para planilhar (no final do dia) as informações geradas.

8) Para assegurar certa qualidade no ambiente de produção estipulei a seguinte regra: Se uma funcionalidade de um programador qualquer não passasse no teste, o time daquele programador seria penalizado em dois pontos (ou seja duas etiquetas não seria contadas).

Conclusão:

Os programadores passaram a realizar os apontamentos sobre produtividade, houve um aumento na qualidade do código desenvolvido, pois os programadores não queriam penalizar os seus times e, por fim, o gerente de projeto conseguiu capturar estimativas reais sobre a produtividade de código.

Bastava agora mapear a complexidade das funcionalidades do projeto (com certeza isso irá gerar um outro post).

Abraços

J. A. Fabri

fabri@femanet.com.br

Brinque com o Papai Noel

Posted in off topic on December 24, 2009 by José Augusto Fabri

Pessoal,

Desejo um natal de paz e alegria a todos. Aproveitando a oportunidade o engenhariasoftware deixa um presente para você. Um jogo gratuito em 3D onde você controla Papai Noel . São diversas fases onde seu objetivo é recolher o maior número de presentes correndo, pulando, e desviando de obstáculos e monstros, tudo embalado ao som de músicas natalinas. Faça o download em:

http://www.gratis.com.br/index.mv?pagina=detalhes&pos=241

Divirta-se.

Escopo do Projeto como fator crítico de sucesso

Posted in gestão de projetos on December 16, 2009 by José Augusto Fabri

No último biênio tive a oportunidade de participar de um projeto que tem como um dos objetivos construir uma rede para integrar as entidades de cunho social de diversas cidades do estado de SP.

A comunicação bidirecional entre entidades/entidades, entidades/imprensa, entidade/população e entidade/poder público será feita basicamente por um portal. As entidades sociais cadastram seus projetos, as pessoas atendidas por esses projetos e as promoções que possibilitam a arrecadação de recursos. A imprensa acessa o portal e divulga os projetos sociais e as promoções junto à comunidade. A comunidade também pode acessar diretamente o portal e captar as mesmas informações divulgadas pela imprensa, além de propor iniciativas que podem ser implementadas junto às entidades. O poder público utiliza as informações capturadas pelo portal para determinar políticas sociais. Número de pessoas atendidas dentro de um projeto social agrupadas por idade ou por rendimento familiar caracteriza-se como uma informação que pode ser utilizada pelo poder público. É importante salientar que o acesso as informações geradas pelo portal pode ser efetuado por dispositivos portáteis de comunicação.

Após apresentar os objetivos e algumas características funcionais do produto, proponho de uma forma ampla, duas formas de estruturar o escopo para o desenvolvimento do projeto. Lembro que o escopo caracteriza-se como a linha que une o ponto que você está ao ponto que você quer chegar. É de suma importância que essa linha consuma o menor recurso possível e possibilite a maximização da qualidade do produto ou serviço.

Escopo 1 –

A entidade financiadora do projeto contrata uma empresa de produção de software para construir o projeto.

A empresa de produção de software juntamente com as entidades elege uma cidade piloto para a construção do portal.

A empresa de produção de software constrói o portal com base nos requisitos da cidade piloto, é óbvio que a empresa desenvolve todas as parametrizações detectadas, lembre-se que o portal será utilizado por entidades sociais de outras cidades.

A empresa de produção de software implanta o portal na cidade piloto. Claro que isso não foi tão simples assim e nem tudo está rodando 100%.

A entidade financiadora abre um edital para prover a infra-estrutura de instalação do portal em outras cidades.  Equipamentos, treinamento, recursos humanos para a implantação do portal caracterizam-se como itens financiáveis.

A entidade financiadora elege alguns projetos, utilizando critérios pré-estabelecidos, e inicia o processo de implantação do portal.

Adivinha só o que está acontecendo durante a implantação!!!

Por maior que seja o nível de parametrização, o portal não adere às necessidades das outras cidades. As políticas públicas, a natureza dos projetos sociais varia de região para região e de cidade para cidade.

Conclusão: Projeto desenvolvido em 4 anos, investimento gigantesco, o produto é utilizado somente na cidade piloto.

Escopo 2 –

A entidade financiadora do projeto NÃO contrata uma empresa de produção de software para construir o projeto. Ela  juntamente com seu departamento de TI desenvolve um protocolo de comunicação de informação. Um documento que prevê como as informações devem ser integradas entre as cidades.

A entidade financiadora abre um edital para fomentar a infra-estrutura de construção do portal em cada cidade.

O edital prevê a participação de uma instituição de ensino superior da área de computação, de um professor e de um grupo de alunos do penúltimo ano da graduação na construção do portal. Em cidades maiores o número de instituições, de professores e de alunos é maior.

Os alunos serão remunerados com bolsa de estudo e o professor também receberá um montante financeiro para complementar seu salário.

Equipamentos e treinamentos para os alunos também podem ser contemplados no projeto.

Os alunos e o professor são responsáveis por colher os requisitos das entidades e construir o portal. Lembre-se que o formato das informações que chegarão à entidade financiadora deve contemplar as prerrogativas impostas no protocolo.

Neste caso as entidades e a cidade se sentem responsáveis pela execução do projeto. Existe uma aderência muito maior das funcionalidades as necessidades das entidades.

Conclusão: Projeto desenvolvido em 2 anos, investimento (que não foi gigantesco) utilizado para alinhar universidade e empresa dentro de uma esfera de auxílio social. Produto utilizado. Informações municipais compartilhadas entre entidades/imprensa/população/poder público.

Adivinha só qual foi o escopo escolhido pela entidade financiadora para o desenvolvimento do projeto?

Abraços

J. A. Fabri

fabri@femanet.com.br

Saia da zona de conforto

Posted in gestão de projetos on December 14, 2009 by José Augusto Fabri

Pessoal, o Juliano dá uma contribução fatástica para sairmos da zona de conforto. Vale a pena conferir no link: http://jmmwrite.blogspot.com/2009/11/saia-da-zona-de-conforto.html

abraços

J. A. Fabri – fabri@femanet.com.br

Utilizando tomates no planejamento de seu tempo

Posted in gestão de projetos on December 9, 2009 by José Augusto Fabri

Nesta semana um gerente de projeto de software me fez a seguinte pergunta: Você conhece alguma técnica eficaz que possa ser aplicada ao planejamento temporal de um projeto de software?

Sim, utilize tomate no seu planejamento.

Segundo Chris Sims (tradução de Marcelo Andrade),  a técnica Pomodoro (tomate em italiano) é caracteriza como uma abordagem pessoal para o planejamento temporal de suas atividades. Esta técnica começou a ser desenvolvida por Francesco Cirillo no início da década de 1980. Cirillo buscava a melhorar da qualidade de seu tempo de estudo, focando sempre eliminar as distrações e as interrupções que desviam sua atenção.  

Cirillo fez uma aposta com ele mesmo, conseguir estudar durante 10 minutos sem qualquer tipo de distração ou interrupção. A marcação desse tempo foi feita com um timer de cozinha no formato de um tomate.

A técnica evoluiu até 1992 e atualmente propõe a divisão de nosso tempo de trabalho em sessões de 25 minutos, cada sessão recebe o nome de Pomodoro. Após os 25 minutos é necessário fazer uma pequena pausa. Ao final de 3 sessões consecutivas fazemos uma pausa maior.

A Pomodoro inclui um simples planejamento laboral, ou seja, no começo de seu dia uma lista de tarefas é criada. Para cada tarefa estima-se o número de Pomodoros necessário para execução. Tarefas que utilizam mais de 7 Pomodoros devem ser divididas. Tarefas com tempo de execução inferior a um Pomodoro devem ser agrupadas. As interrupções ocorridas durante o Pomodoro são colocadas em uma fila. Essa fila é tratada quando o Pomodoro terminar. Nas ocasiões em que a interrupção não pode ser inserida na fila, o Pomodoro é parado e invalidado. Francesco costuma dizer, o próximo Pomodoro sempre superará as suas expectativas.

A referida técnica vem atraindo a atenção de vários gerentes de projetos e da comunidade ágil. Várias equipes de desenvolvimento de software vêm aplicando-a com um sucesso.

Para maiores informações Francesco Cirillo disponibiliza um livro e um cheat sheet  para download.

J. A. Fabri

fabri@femanet.com.br

O Tom

Posted in off topic on December 5, 2009 by José Augusto Fabri

Em nossa vida existem vários tons, alguns deles proporcionam os acordes da descoberta, outros aprofundam os acordes do conhecimento. Cada tom possui um significado especial. Qual é o seu tom?

Se eu soubesse o meu, com certeza as decisões em minha seriam muito mais simples. O Tom da crença foi me apresentado quando ganhei, mesmo sem merecer, a oportunidade de ser o que sou. A propósito, em meu singelo olhar, nem sei se sou alguém ou alguma coisa.

O Tom da confiança, apresentado a mim várias vezes, coitados, mal sabiam o que faziam.

O Tom da humildade, esse sim, conheci e pude experimentar em várias pessoas.

Quanto tempo desperdiçado ao meu favor. Tempo este que não consegui aproveitar do modo que deveria. Um olhar mais atento resultaria em acordes mais afinados.

O Tom que toca agora é o da incerteza, o Tom da mudança, ambos são, substancialmente, diferentes daqueles que conheci. Oportunidades foram dadas, e muitas vezes não aproveitadas.

Um tom dará a tônica do acorde final. O tom do aprendizado. Aprendiz de tudo e de todos que estavam e que estarão ao meu lado.

Agradeço a todos os amigos (alunos, professores e funcionários) da FEMA e da FATEC-OU por orquestrarem minha vida nos últimos 15 anos.

J. A. Fabri

fabri@femanet.com.br

Erro no software em produção

Posted in processo de produção de software on December 2, 2009 by José Augusto Fabri

Ao navegar pelo site da globo.com, uma matéria me chamou a atenção,  FIFA define cabeças de chaves: França fica fora e pode encarar a seleção brasileira.

No final do texto, por meio de um “software”, é possível efetuar uma simulação dos grupos para a copa de 2010. Veja só o meu palpite (clicando na figura).

 

Agora veja a restrição que FIFA impõe a  formação dos grupos (publicada na própria reportagem).

“… E, pelos critérios do sorteio, nenhum grupo pode ter mais de um representante do mesmo continente, exceto a Europa, que pode ter no máximo dois”.

Agora de uma olhadinha no grupo da Argentina.

Alguém não implementou a restrição imposta pela FIFA e, pior, isso não foi detectado na atividade de teste.

Abraços

José Augusto Fabri

Algumas desculpas que os programadores emitem na presença dos testadores

Posted in processo de produção de software on November 11, 2009 by José Augusto Fabri

Veja algumas desculpas que os programadores emitem durante a execução da atividade de teste.

1 – Putz: Se eu tivesse validado. (o se é primo de primeiro grau do talvez)

2 – Nem sei se eu validei isso. (eu tenho certeza que não)

3 – O programa não passou no teste porque eu esqueci de retirar um comentário do código. (que pena!)

4 -Essa é ótima: Tá pegando pesado, o usuário nunca irá fazer isso. (utilize sua certeza para programar)

5 – Pelo menos a saída emitida não é lixo de memória. (é… poderia ser pior)

6 – Ih. Por que letra não entra e os caracteres especiais sim? (se você não sabe, quem saberá?)

7 – (Essa é ótima) Poxa que maldade!!! Testar isto para ver se está funcionando!!!

8 – Porque, sei lá. (boa, não?)

9 – Era para passar no teste mas não passou (ainda bem que você pensa assim!)

10 – Tudo isso aconteceu porque modifiquei o programa (inteligente esta!!! né…)

J. A.

fabri@femanet.com.br

Quebra de Paradigma versus Inovação

Posted in gestão de projetos on November 10, 2009 by José Augusto Fabri

No dia 12 de outubro publiquei um texto sobre  inovação. Recebi alguns e-emails solicitado um relacionamento entre inovação e quebra de paradigma. Walter Longo apresenta suas idéias sobre este fato, divirtam-se com o vídeo:

A inovação na Comunicação – O Impacto da revolução tecnológica no relacionamento com o consumidor , por Walter Longo. Forum mundial de inovação – HSM.

Abraços

J. A – fabri@femanet.com.br