Category Archives: Metodologia

Download Engenharia de Software Metodologia Pesquisa

Um CheckList para Dissertações de Mestrado

Inspirado no documento proposto pela Universidade do Minho (1) preparei um check list para aplicar nos textos de trabalho de mestrado. Os itens destacam o que deve ser encontrado no texto, servindo como referência para quem já escreveu um texto ou para quem ainda vai escrever.

Um outro artigo interessante no website posgraduando descreve como avaliar os trabalhos científicos.

CLIQUE AQUI PARA BAIXAR O CHECK LIST.

Referencias

(1) Check-list orientadora da escrita da dissertação de mestrado. UMinho

(2) http://posgraduando.com/como-avaliar-trabalhos-cientificos/

Engenharia de Software Livros Metodologia Pesquisa Resenhas

Revisão Sistemática uma Técnica Importante de Pesquisa

Revisão Sistemática da Literatura em Engenharia de SoftwareRevisão Sistemática da Literatura em Engenharia de Software by Nakagawa, Elisa
My rating: 4 of 5 stars

A Revisão Sistemática de Bibliografia (RS) é um método de pesquisa que permite partir de questões de pesquisa e chegar nas referências bibliográficas que traduzem o conhecimento disponível em bases biliográficas para responder a estas perguntas. Este processo que já é aplicado com mais frequência na área de saúde, é agora apresentado, com detalhes, para a área de Engenharia de Software. O livro apresenta o processo de forma minuciosa e bastante didática, sendo de leitura fácil, organizado nos passos que o pesquisador deve seguir com sugestões e exemplos bem práticos.

A possibilidade de sistematização do processo de revisão bibliográfica se dá graças à disponibilidade de bases bibliográficas organizadas como a IEEE Xplore, Google Scholar entre outras. Também a disponibilidade de software de apoio como o programa Start da UFSCAR permite a automação e um alto nível de organização do processo, facilitando as decisões na recuperação das referências e na seleção daquelas que irão compor a revisão. Pode parecer paradoxal mas a Engenharia de Software não é a pioneira, nem a mais organizada nas suas pesquisas, e um aspecto que limita de certa forma a aplicação da Revisão Sistemática em engenharia de software é a quantidade de estudos primários de qualidade disponíveis. Ao contrário das áreas de saúde, por exemplo, onde há uma maior quantidade e qualidade das pesquisas, o pesquisador de engenharia de software vai encontrar dificuldade em responder algumas questões de pesquisa diretamente com a RS. No entando, a partir do resuldado da RS o pesquisador terá um quadro preciso do estado da arte e poderá orientar mais adequadamente sua pesquisa.

O resultado de uma RS pode ser publicado como um estudo secundário e pode despertar interesse específico pela comunidade se prover análises aprofundadas e sínteses perspicazes. Concluindo, este é um livro oportuno e altamente recomendado para todos os pesquisadores em especial oa todos os alunos de pós graduação em engenharia de software.

View all my reviews

Compre o livro da Amazon
Compre o livro na Livraria Cultura
Acesso ao programa StArt

Engenharia de Software Metodologia Pesquisa Teste de software

10 anos de Mestrado no IPT

(Observação: os dados acima podem estar mais atualizados que o texto abaixo, escrito em agosto de 2015)

O estudo acima resume as minhas atividades de orientação no mestrado profissional em engenharia de computação no IPT. Dos 33 alunos que iniciaram um trabalho de pesquisa comigo 29 já concluíram mas apenas 14 obtiveram o título de mestre em engenharia da computação, 10 perderam o prazo, 2 desistiram e 3 optaram por mudar de orientador. Assim a taxa de sucesso é de 14/29 = 53% (já descontando os que mudaram de orientador).

Os trabalhos que oriento seguem as disciplinas que eu ministro no curso, há um interesse maior por Teste de Software com 8 trabalhos concluído, Métodos de Desenvolvimento de Software com 3 trabalho e 3 sobre Gerenciamento de Engenharia de Software.

Visite aqui para conhecer mais sobre a minha participação no mestrado do IPT.

Cultura Geek Metodologia Pesquisa

A importância do Doutorado

Ditado popular: Rapadura é doce, mas não é mole.

NO ENSINO FUNDAMENTAL
Açúcar mascavo em tijolinhos tem o sabor adocicado, mas não é macio ou flexível.

NO ENSINO MÉDIO
Açúcar não refinado, sob a forma de pequenos blocos, tem o sabor agradável do mel, porém não muda de forma quando pressionado.

NA GRADUAÇÃO
O açúcar, quando ainda não submetido à refinação e, apresentando-se em blocos sólidos de pequenas dimensões e forma tronco-piramidal, tem sabor deleitável da secreção alimentar das abelhas; todavia não muda suas proporções quando sujeito à compressão.

NO MESTRADO
A sacarose extraída da cana de açúcar, que ainda não tenha passado pelo processo de purificação e refino, apresentando-se sob a forma de pequenos sólidos tronco-piramidais de base retangular, impressiona agradavelmente o paladar, lembrando a sensação provocada pela mesma sacarose produzida pelas abelhas em um peculiar líquido espesso e nutritivo. Entretanto, não altera suas dimensões lineares ou suas proporções quando submetida a uma tensão axial em conseqüência da aplicação de compressões equivalentes e opo stas.

NO DOUTORADO
O dissacarídeo de fórmula C12H22O11, obtido através da fervura e da evaporação de H2O do líquido resultante da prensagem do caule da gramínea Saccharus officinarum, (Linneu, 1758) isento de qualquer outro tipo de processamento suplementar que elimine suas impurezas, quando apresentado sob a forma geométrica de sólidos de reduzidas dimensões e restas retilíneas, configurando pirâmides truncadas de base oblonga e pequena altura, uma vez submetido a um toque no órgão do paladar de quem se disponha a um teste organoléptico, impressiona favoravelmente as papilas gustativas, sugerindo impressão sensorial equivalente provocada pelo mesmo dissacarídeo em estado bruto, que ocorre no líquido nutritivo da alta viscosidade, produzindo nos órgãos especiais existentes na Apis mell ifera.(Linneu, 1758) No entanto, é possível comprovar experimentalmente que esse dissacarídeo, no estado físico-químico descrito e apresentado sob aquela forma geométrica, apresenta considerável resistência a modificar apreciavelmente suas dimensões quando submetido a tensões mecânicas de compressão ao longo do seu eixo em consequência da pequena capacidade de deformação que lhe é peculiar.

Engenharia de Software Filmes Metodologia Pesquisa Resenhas

Vídeos de Metodologia de Pesquisa

PORTUGAL-224

O YouTube pode ser usado como um bom recurso de aprendizado. Até acredito que isso vá se firmar no futuro, com cursos completos oferecidos aqui.

Encontrei algum material interessante sobre metodologias de pesquisa científica, que procurei organizar aqui para meus alunos. Apesar de algumas das aulas não serem voltadas para área de engenharia de software, os conceitos gerais podem ser generalizados e aplicados em outras as áreas de pesquisa como a engenharia.

A primeira vídeo-aula, apresenta Métodos de Pesquisa em psicologia, mas que podem ser aplicados facilmente para outras áreas:

Eu traduziria a introspeção como uma experiência pessoal, sem valor científico. Os demais métodos apresentados são equivalentes, na nossa área, aos: Estudo de Caso, Survey e o Método Experimental.

Método Experimental
Este segundo é uma apresentação de 2 minutos sobre o Método de Experimental de Pesquisa:

Esse é o método clássico de pesquisa e pode ser resumido como:
1. Fazer uma pergunta
2. Realizar a pesquisa
3. Formular Hipóteses
4. Experimentar
5. Tirar uma conclusão.

Observar que: “se uma hipótese não puder ser refutada não é uma proposta científica”.

Aqui uma apresentação [video] mais “engraçadinho” do Método Científico (Scientific Method) para quem gosta deste estilo:

Estudo de Caso
Uma palestra em 3 partes muito boa e detalhada (18 minutos) sobre um método de pesquisa muito usado na nossa área o Estudo de Caso.

Parte 1 de 3 -Definição e introdução
Que é uma forma estruturada de pesquisa, usada para estudar um fenômeno atual no seu contexto real.

[video] Parte 2 de 3.
[video] Parte 3 de 3.

Pesquisa-Ação

Esta é uma apresentação bem curta (1m50) em inglês do método de pesquisa e ação, mas é bem superficial e não mostra como se aplica o método.

Aqui começa uma série de 3 apresentações longas sobre o método de Pesquisa-Ação. Não gostei muito destes mas não achei vídeos melhores sobre o assunto:
Parte 1 [video]
Parte 2 [video]
Parte 3 [video]

Grounded-Theories
Uma excente série de 4 partes sobre a Grounded Theory por Graham Gibbs

lectures on grounded theory 1 de 4

Outras referencias interessantes:

[video] Feynman on Scientific Method.
[video] Popper's "Science as Falsification" (1963). A discussion in the philosophy of science.
[video] Metodologias Qualitativas e Quantitativas
[canal] Research Methods in Social Sciences por Graham Gibbs

Conclusão
Para os alunos que estão iniciando uma pesquisa de mestrado é importante conhecer os métodos de pesquisas e suas definições para selecionar a técnica mais adequada para o seu caso.

Engenharia de Software Gerencia Metodologia Pesquisa

Métodos não, Habilidades

Colher de doce de morango

Frequentemente, na minha vida profissional, veja uma procura por métodos, erroneamente chamados de metodologias, como forma de resolver um problema complexo: Metodologia para Gerenciamento de Projetos, Metodologias para Desenvolvimento de sistemas, Método de Estimativa de Esforço, Método de Solução de Problemas. Dá mesma forma, muitos buscam normas e regras que, uma vez seguidas rigorosamente, vão garantir o sucesso. Este é famoso “caminho das pedras”. Estude muito que vai conseguir um bom emprego. Trabalhe bastante que vai ter dinheiro e sucesso profissional. Não faça nada errado, se fizer vai se dar mal. Muitos acreditam de verdade que a vida é assim. Existem regras que podem garantir o sucesso. Tenho um segredo para vocês: a vida não é assim.

Para não transformar este artigo em um tratado filosófico ou religioso, vou me limitar à minha área de competência: ensino e desenvolvimento de software. Posso afirmar com a convicção de um professor na matéria: Não existe método (garantido) para o desenvolvimento (com sucesso) de um software. Não é possível se ensinar isso, simplesmente porque não existe. Existem sim habilidades que bem desenvolvidas, e aplicadas, aumentam a chance de sucesso no desenvolvimento de software. Se vamos chamar de método à organização de um conjunto coerente de habilidades, então existe o método. Mas o nome método é ruim, prefiro: habilidade.

Porque habilidades e não técnicas, boas práticas, ferramentas? Porque elas dependem do ser humano. Uma habilidade não existe solta, ela precisa de uma pessoa para existir, e porque ensinar é dar novas habilidades aos alunos. Os melhores cursos são aqueles que ao final o aluno consegue “fazer” alguma coisa que ele não conseguia “fazer” antes, ou seja ele foi habilitado a realizar alguma coisa nova.

A pergunta certa então é quais são as habilidades necessárias, importantes para um projetos de software?
1. Habilidade de entender o objetivo do software
2. Habilidade de conceber um sistema de software que atinja este objetivo
3. Habilidade de construir este software
4. Habilidade de capacitar (ensinar, habilitar) os usuários no uso deste software.

Tudo isso! Sim. Mas não vai existir alguém que possua todas estas habilidades. Por isso o desenvolvimento de software é um trabalho colaborativo, desenvolvido por uma equipe multidisciplinar. O grau que se deve combinar estas habilidades varia de acordo com o problema, mas mesmo que em pequeno grau elas sempre vão estar presentes. Como as habilidades estão sempre associadas à pessoas, uma equipe de desenvolvimento deve ser composta por integrantes que juntos possuam toda estas habilidades.

Muitos estão procurando uma receita de bolo, ingredientes e uma forma única de combiná-los para produzir uma bolo gostoso. Mas todos sabem que boas cozinheiras raramente seguem uma receita completamente, e produzem bolos deliciosos, e mesmo seguindo uma receita com precisão é garantia de que o bolo vai dar certo.

Assim quando eu estudo um método, me interessa entender os princípios e razões por trás das atividades deste método para garantir que eu tenha a habilidade para aplicá-lo corretamente, e mais ainda tenha a habilidade para ajustá-lo ao problema que estou resolvendo.

Engenharia de Software Fotografia Metodologia Pesquisa

Dica de Hemingway para boas fotos

Obra ensembles de Anna Oppermann

Eu escrevo uma página de obra-prima e noventa e uma páginas de merda“. Hemingway confidenciou para F. Scott Fitzgerald em 1934. “Eu tento colocar a merda no cesto de lixo”

A lição para quem está escrevendo sua dissertação ou para fotógrafos é simples: jogue fora 99% do que você pensa que é bom e mantenha somente o ótimo – suas obras-primas. Se funcionou para o Hemingway vai funcionar para você.

Ref. What Hemingway Can Teach Photographers

Engenharia de Software Metodologia

É Scrum ou Não é Scrum

looking at the sky

Traduzido do Blog do Ken Schwaber (Scrum is, Scrum is not) de 11 de Agosto de 2011.

Scrum é um framework. Você pode usá-lo para gerenciar várias coisas, incluindo o desenvolvimento de produtos complexos. Scrum é definido no Guia do Scrum e consiste de papeis, eventos e artefatos e uma série de regras que os mantém unidos. É baseado em um controle de processo empírico e um pensamento de baixo para cima. O último Guia do Scrum acabou de ser lançado por mim e Jeff, e está publicado no Scrum.org. Algumas coisas como planejamento de versão, tarefas de sprint e burndowns foram removidos da definição formal do Scrum. Eles foram removidos porque eles não eram Scrum. Eles são uteis? Claro quem sim! Mas ficou claro que eles não eram Scrum quando as pessoas propuseram outras técnicas que eram igualmente efetivas. Nós certamente não queremos que as pessoas se sintam restritas ou limitadas para outras práticas efetivas se ele usam Scum.

Você deve se sentir livre para continuar usando burndowns (Sprint e Release), faser o planejamento da versão e se comprometer. Faça qualquer coisa que funciona no framework do Scrum e ajude você a fazer o seu trabalho, contruindo produtos complexos.

Você até se sinta livre para fazer coisas que não são coerentes ou consistentes com o Scrum. Você é livre para fazer um fluxo contínuo, mas se você escolher fazer isso sem incrementos ou e time-box iterativos, você não está fazendo Scrum. Voce é livre para designar tarefas aos recursos baseados na capacidade deles, mas ai você não está fazendo a auto-organização requerida pelo Scrum.

Nós damos a permissão para fazer qualquer coisa que quiser. O Scrum Guide vai ajudá-lo a entender o que é Scrum ou não. Os resultados vão ajudar a você decidir se é uma prática ou técnica aconselhável, ou não.

Engenharia de Software Metodologia

Traduzindo o Scrum para o português

Feliz 456 anos, São Paulo.

Entre as dificuldades em se traduzir um texto técnico, a principal é tentar comunicar a mesma informação em outra língua para leitores de outra cultura. Quase sempre esta tarefa é impossível. Com certeza não se obtém sucesso traduzindo cada palavra, nem mantendo as palavras chave no idioma original.

Meu objetivo ao traduzir o Guia do Scrum é facilitar o seu acesso a ele a desenvolvedores brasileiros que não tem fluência no idioma inglês. Procurei manter em inglês apenas os termos que realmente não encontrei um correspondente em português que pudesse traduzir a mesma idéia. Optei por traduzir termos que facilitariam aos leitores entender o significado que os autores originais tinham em mente ao selecionar aquele termo. Acredito que vou receber criticas de todos. Muitos vão achar que ainda se pode traduzir mais, enquanto outros vão achar que não se deveria traduzir nada.

A eles deixo um glossário de termos abaixo, explicando os principais termos do Scrum e sua tradução.

Scrum (Scrum) – é um substantivo masculino, manter em inglês. Mas é importante saber a origem deste termo para entender porque os autores o escolheram. Em um jogo de rúgbi existe uma formação compacta onde os jogadores se unem tentando chutar a bola que foi jogada para eles. é um sinônimo para uma briga rápida

Framework (Framework) – muitos traduzem por arcabouço, que é uma palavra pouco usada no dia a dia. A idéia de que um framework define uma moldura (frame) que enquadra um tipo de idéia, algo incompleto que falta a imagem para se colocar no centro da moldura me parece mais adequado. Entendo framework como algo que tem um contorno, define algo mas pode ser aplicado em várias situações. Considerar o Scrum como um framework de processos de gerenciamento de projetos é dizer que ele pode se adaptar a várias situações de gerenciamento de projetos com um processo básico, que pode ser complementado para a situação do contexto.

Team (Equipe) Considero que time está associado a eventos esportivos, e apesar de muitas vezes os autores do Scrum se referenciarem a ele como um jogo, o conceito mais forte aqui é o de equipe, que o Scrum exige o trabalho colaborativo de um grupo de pessoas. Por isso traduzi team por equipe e não por time: Equipe do Scrum (Scrum Team) e Equipe de Desenvolvimento (development team).

Product Owner (Dono do Produto) O conceito de owner é mais amplo do que o significado de propriedade, em ingles. Existe uma idéia de admissão de responsabilidade associado a own (own a debt/ assumir uma dívida). Talvez por isso devessemos ficar com o termo original. No entanto optei por traduzir porque o cliente (o verdadeiro dono do produto) talvez não compreenda que o seu papel significa ser o “dono do produto”. No Scrum o Dono do produto deve saber que é dele a responsabilidade sobre o produto que se desenvolve, mais do que a sua propriedade.

Scrum Master (Scrum Master) Por que não traduzir por Scrum Mestre que traduz a idéia de ensino do conhecimento do Scrum que a palavra significa? É um termo que já conta com uma boa aceitação pela comunidade e possui certificações e como se destina a pessoas ligadas à tecnologia, não tenho objeção em mantê-lo em inglês.

Sprint (Sprint) o termo se refere ao esforço final de uma corrida; pode ser traduzido como “correr em alta velocidade por uma distancia curta”. Como também é um termo com boa aceitação na comunidade de desenvolvedores, não vejo problemas em mantê-lo em inglês. Optei por mantê-lo como um substantivo masculino “o sprint” como é utilizado com frequência em reportagens esportivas, e não no feminino como optou-se na tradução anterior.

Goal (Objetivo) o termo Gol possui em português um significado muito além da idéia de se atingir um objetivo. Por isso, optei por fugir da tradução obvia e optar por objetivo que, acredito, traduz melhor o significado do termo.

Daily Scrum (Scrum Diário) é um evento do Scrum que deve ocorrer todos os dias, e por isso optei por traduzir o termo.

Time-box (time-box) pessoalmente este é o termo mais difícil de traduzir, inicialmente porque não existe esta palavra no inglês formal. O termo é um neologismo que traduz o fato de que no Scrum o tempo está embutido em uma caixa, ou seja limitado. Como é um termo novo e não encontrando nada correspondente, fica em inglês, estimulando uma melhor definição.

Backlog (Backlog) por definição, em inglês, significa uma lista de tarefas ainda não executadas: log está associado a registros, e back está associado ao fato de não estar na frente. Um conjunto de registros que não está na frente, que não é a preocupação no momento.

“Done” (“Pronto”) uma tradução possível seria feito, concluído, terminado e qualquer uma serviria ao propósito do Scrum. O mais importante aqui são as aspas. O termo entre aspas que dizer que ele significa algo diferente do usual. o “pronto” quer dizer que foi para cada item do backlog deve-se definir o que significa que ele acabou. O uso de aspas no inglês foi mantido na tradução para destacar que se trata de um “pronto” especial.

Release (Release) release em ingles significa libertar, liberação, soltura ou lançamento. Como não encontrei uma palavra adequada para usar, mantive release em inglês, para significar o lançamento de uma versão do produto.

Engenharia de Software Metodologia Pesquisa

A empresa como tema de pesquisa: um bom caminho?

Muitos alunos me procuram com desejo de combinar a sua pesquisa de mestrado com o trabalho que realizam na suas empresas. Em uma primeira vista esta abordagem parece correta, especialmente em um mestrado profissional, mas existem alguns riscos nesta opção, e algumas possibilidades de abordagem que eu procuro descrever a seguir.

 

Riscos
Um risco importante, que a seleção do problema na empresa possui, é a dinâmica própria das empresas e dos profissionais. Deve-se lembrar que uma pesquisa vai levar no mínimo um ano, e os problemas nas empresas mudam muito neste período o que pode fazer o aluno perder o interesse. As pessoas também podem mudar de emprego e o problema que era importante em um momento passa a não existir mais. Se o problema  não estiver bem classificado ou o emprego não estiver consolidado, melhor talvez seja separar as duas coisas. Pode-se sempre assumir o risco de se a empresa mudar, ou mudar a empresa, a pesquisa deve continuar. Acomodar a pesquisa à nova empresa é impossível e o risco passa a ser de não se conseguir acabar no prazo. O tamanho do problema é outro risco, problemas reais tendem a ser grandes e complexos e a sua solução definitiva pode não ser obtida no prazo da pesquisa. É bom o pesquisador estar consciente das limitações de que o prazo impõe no trabalho, antes de começar, e aceitar que pode não conseguir resolver o problema da empresa completamente.

Do ponto de vista metodológico a empresa pode colaborar na pesquisa 3 formas diferentes: motivador da pesquisa, objeto de pesquisa ou como um ambiente para validar a pesquisa.

Motivador da pesquisa
A empresa possui um problema que motiva uma pesquisa científica, em geral usa-se um método chamado pesquisa-ação. Podemos pegar um problema “real” e fazer a pesquisa para analisar e tentar resolver o problema de uma forma “científica”. A relevância da pesquisa vai depender da relevância do problema para a comunidade. Este relevância pode ser detectada em publicações. Existem artigos relatando este mesmo problema e propondo soluções? Existem problemas/soluções parecidos em outras áreas (analogia) que podem usadas como referência? Deve-se observar que o problema/solução não pode ser o “Fazer o arroz com feijão direito”, ou seja se a empresa não usa corretamente os métodos e ferramentas comuns de mercado, a solução é óbvia. Por exemplo: Temos problemas com requisitos mal definidos, mas não fazemos um levantamento correto dos requisito; solução: faça um levantamento correto dos requisitos.

Objeto de pesquisa
Neste caso supomos que a empresa possui uma característica de interesse científico, por exemplo: usa uma técnica ou método relevante em um problema interessante. Este tipo de pesquisa chama-se estudo de caso (ref.: Robert Yin, Estudo de Caso). A pergunta mais importante é: Temos um caso relevante para estudar? O que foi realizado nesta empresa que tem interesse para outras empresas? Foi realizado de uma forma “academicamente correta”, usando métodos critérios aceitos pela academia/mercado? Por exemplo, Podemos estudar uma empresa que implantou uma método Scrum, se ela realmente implantou o Scrum. Mas não existe um estudo de caso se a empresa implantou um método de desenvolvimento próprio sem nenhuma referencia externa. Existe uma referência acadêmica sobre o que foi realizado? Existe um padrão publicado sobre o que foi realizado? Novamente as referencias bibliográficas podem ajudar a definir se existe um caso a estudar ou não.

Experimento de pesquisa.
O pesquisador usa a empresa como um experimento que confirma/ou não os resultados de uma pesquisa. Esta é uma pesquisa experimental (ref.Wohlin, C.; Experimentation in software engineering: an introduction). Neste caso a pesquisa está livre para seguir o seu próprio caminho. Ela foi justificada com uma motivação própria, foi elaborada uma proposta e foi projetado um experimento para se validar a proposta. A empresa pode servir de berço para o experimento. As perguntas neste caso são: o ambiente da empresa é coerente com o problema da pesquisa? É possível se projetar um experimento controlado na empresa? Podemos obter dados (medidas) objetivas do experimento? De algum modo este estudo é um estudo de caso da proposta da pesquisa e pode ser usado em complemento à primeira proposta.

Vale observar que as três abordagens podem se combinar, gerando uma pesquisa mais completa e ao mesmo tempo muito mais complexa do que um estudo focado em uma abordagem só. Em qualquer caso, minha sugestão é analisar qual é o cenário mais apropriado, fazer uma pesquisa bibliográfica que vai confirmar se a escolha foi correta, elaborar um Projeto de Pesquisa e permanecer alinhado a esta proposta até o fim.