O que é um questionário?
Questionário é o principal instrumento utilizado para obtenção e registro de dados por amostragem. O objetivo deste é coletar dados que se traduzam em informações suficientemente aproximadas sobre uma população alvo, que dizem respeito ao tema abordado. Esta coleta de dados baseia-se na resposta por parte de alguns indivíduos da população alvo de perguntas que abrangem o assunto pesquisado. O questionário pode ser definido como “Um conjunto de perguntas sobre um determinado tópico que não testa a habilidade do respondente, mas mede sua opinião, seus interesses, aspectos de personalidade e informação biográfica.” (Yaremki, R.K. , Harari, H., Harrison, R.C., Lynn, E. (1986). Gunther, H. (2003).)
O questionário pode ser aplicado de diversas formas: pessoalmente, por correio, por telefone, pela web, etc.. Por isto, é um instrumento especialmente útil e econômico para recolher dados de amostras amplas, ou que estejam distantes. Devido ao grande número de respondentes possíveis, abarca aspectos quantitativos e qualitativos.

População alvo

A população alvo deve ser definida no princípio da formulação do questionário. Esta influencia em todas as etapas de planejamento e construção do instrumento: No modo como as perguntas devem ser formuladas, no método de aplicação, na quantidade de perguntas, etc.. Ao selecionar os idosos como população alvo, pode ser necessário descartar a aplicação via e-mail.
Após definir a população alvo, deve-se definir a amostra, ou seja, os indivíduos que realmente responderão o questionário. Este deve ser um passo cuidadoso: os indivíduos devem representar proporcionalmente a população. Grande parte do enviesamento dos dados ocorre neste passo. Esta tarefa, teoricamente, é impossível. Podemos afirmar que o simples fato de responder um questionário já segrega a população entre indivíduos que respondem questionários e indivíduos que não respondem questionários. Assim, devemos assegurar que a proporção entre as facções que ocorrem na população seja igual entre os respondentes.

Técnicas de abordagem

Uma das dificuldades do questionário ocorre quando há desobrigação por parte do respondente. Ao contrário de uma prova, o pesquisador se encontra em posição de pedinte. Por isso, é complicado garantir que grande parte dos questionários distribuídos sejam respondidos, e que sejam respondidos com veracidade. Por isso, o formato do questionário deve ser simples, de forma a facilitar sua resposta. Além disso, é importante que se construa uma relação de confiança com o respondente.

Perguntas abertas ou fechadas

Perguntas abertas podem ser usadas em casos onde o tema pesquisado não é muito conhecido. Sua flexibilidade permite que o respondente exponha sua opinião sobre um tópico que não possua respostas definidas ou as possíveis respostas não são conhecidas(geralmente em um estudo piloto). Além disso, são mais simples de serem elaboradas, já que não é necessário construir um conjunto de respostas.
Perguntas fechadas facilitam a transcrição do resultado, e sua análise (até mesmo através de programas computadores, podendo gerar estatísticas e inferências automaticamente). Porém, sua elaboração é mais complicada. O conjunto de respostas precisa ser exclusivo e exaustivo. Ser exclusivo significa que não é possível eleger duas respostas dentre as pertencentes ao conjunto. Ser exaustivo significa que todas as respostas possíveis devem estar contempladas em algum ítem do conjunto.
Algumas pessoas dizem que a resposta fechada limitam a liberdade de expressão da amostra. Isto é uma falácia. Ao replicar uma questão aberta, o respondente está submetendo suas palavras a uma categorização realizada pelo pesquisador. Já na pergunta fechada, o próprio respondente qualifica sua opinião, sem sujeitar-se a interpretações.

Formulando perguntas

As perguntas precisam ser formuladas e organizadas de modo a manter a tarefa breve e fácil, evitando torná-la aborrecedora ou aversiva. O questionário deve conter apenas perguntas que valem a pena serem analisadas. É importante que o respondedor sinta que as perguntas têm relevância, para que as responda com a atenção devida.
Gunther, H. (2003) indica dois princípios de estruturação:

O questionário deve partir de ítens mais gerais, encaminhando-se para ítens mais específicos. Isto vale também para seções de ítens: cada seção deve começar com perguntas mais gerais. Este tipo de pergunta serve mais como uma introdução o tema a ser tratado, deixando o respondedor mais confortável com o questionário. Apresentar perguntas muito específicas no princípio do instrumento pode inibí-lo, fazendo-o se sentir em uma investigação policial.

    O outro princípio é que, na medida do possível, o questionário deve seguir uma ordem lógica. Isto contribui para que o respondedor eleja suas resposta sem muito esforço, o que é muito importante para manter a tarefa o mais agradável possível.

Referências :     Gunther, H. (2003). Como Elaborar um Questionário (Série: Planejamento de Pesquisa nas Ciências Sociais, N^o 01). Brasília, DF: UnB,Laboratório de Psicologia Ambiental
Muñoz, T. (2003). El Cuestionario como instrumento de investigacón/evaluación (Etapas del Proceso Investigador).
Yaremki, R.K. , Harari, H., Harrison, R.C., Lynn, E. (1986). Handbook of research and quantitavtive methods in psychology. Hillsdale, NJ: Lawrence Erlbaum

Quando os gerentes de projetos enxergam que o processo está falhando, sua primeira sugestão é: temos pouco processo. Então, inflam ainda mais o portfólio de documentos a serem produzidos. Isto é feito porque acredita-se que, se for empregado esforço suficiente, todos os requisitos poderiam ser antecipados.
O desenvolvimento ágil apresenta uma quebra de paradigma: O objetivo é gerenciar o projeto para que as mudanças custem menos, ao invés de tentar prevê-las. Esta é uma resposta à espectativa do mercado, que demanda mais qualidade em menos tempo. Qualidade? Pois é, cada método ágil tem sua preocupação com a qualidade. Alguns, baseados no “mythical man-month“, lembram que introduzir novas pessoas, assim como novos documentos, em um projeto atrasado, não significa melhorá-lo. Pelo contrário, o efeito pode ser bastante negativo. O scrum planeja reuniões diárias para o alinhamento das tarefas. O XP exige que o teste de um módulo seja escrito antes de iniciar seu desenvolvimento.

Existem alguns autores que defendem a idéia de que o ágil é uma máscara para a indisciplina. Assim, criou-se na comunidade de engenharia de software uma guerra entre árabes e judeus: Os defensores do Ágil chegaram com um discurso fervoroso favorecendo sua nova metodologia, provocando grande crítica por parte dos defensores das metodologias tradicionais. Por utilizarem argumentos pretensiosos e utópicos, a nova proposta soou como uma afronta.
Para o professor Julio Leite, o maior erro das pessoas é pensar que a mesma roupa veste todo mundo. Os dois lados da moeda têm muito o que acrescentar, e quem vai estudar o tema tem que ter a maturidade de filtrar as informações úteis do que está lendo. A razão não é algo que possa ser expressado em 0 ou 1. Em todas as discussões, todas as partes tem argumentos relevantes, que merecem ser analisados.

As regras do Ágil não pretendem englobar tudo que é necessário para a produção do software. Elas são apenas uma base, um conjunto de pontos fundamentais que devem ser abordados por quem pretende construir software usando métodos ágeis. Portanto, como Barry Boehm sugere, é possível que haja métodos híbridos, e estes podem ser a melhor solução para a maioria dos negócios.

Os métodos ágeis se apoiam em dois princípios básicos: no código funcionando e no fator pessoa.
O código funcionando é uma nova forma de se comunicar com o cliente: não envolve abstração, e assim elimina possíveis mal-entendidos. O que se tem é o que se pode ver. No ágil, a equipe se compromete a entregar código funcionando em curtos intervalos, de duas a cinco semanas. O cliente pode verificar se o que está sendo feito realmente atende às expectativas.
O fator pessoa se apoia na idéia de que as pessoas interagindo diretamente são a melhor forma de transmissão de conhecimento. O ágil exige proximidade para funcionar, tanto entre os membros da equipe quanto entre a equipe e o cliente. Estando juntas e conversando diretamente, tarefas como constante definição de prioridade, inclusão de um novo membro na equipe, eliminação de mal-entendidos, etc., podem ser realizadas com mais velocidade e menos custo.

Apoiados nessas idéias, 17 pessoas que desenvolviam seus próprios métodos alternativos de desenvolvimento de software assinaram um documento, chamado Manifesto para Desenvolvimento Ágil de Software:

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

Indivíduos e interações entre eles mais que processos e ferramentas

Software funcionando mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Os métodos ágeis possuem características comuns, apesar de cada um implementá-las de forma diferente.
No ágil, especificação, projeto e desenvolvimento ocorrem simultâneamente. Isto quer dizer que nenhuma das tarefas é pré-requisito de outra. O desenvolvimento, por exemplo, ajuda a elicitação dos requisitos.
As iterações, ou seja, o tempo entre as entregas dos incrementos, é bastante curto. Desta forma, é mantido um feedback constante para o cliente. O planejamento é sempre feito para o próximo incremento. O que vai ser feito depois vai ser planejado depois.
Um ponto importantíssimo do ágil é a priorização dinâmica. A todo tempo é necessário rever o que será feito primeiro. O scrum, por exemplo, tem um esquema de priorização de tarefas por pontos, que é revisto junto com o cliente em todo início de iteração.
A equipe deve estar sempre próxima, já que a comunicação no ágil é feita através de interação direta. Tudo deve ser tratado verbalmente, por mais que se escreva algo sobre o que foi discutido depois. Como foi dito anteriormente, este é um dos pilares da metodologia, grande parte do sucesso dos projetos reside aqui.
Da mesma forma que a comunicação dentro da equipe é feita diretamente, o cliente também é tratado desta forma. É importante que, ao menos uma vez a cada ciclo, exista uma reunião entre cliente e equipe que aborde o que foi e o que será feito. A reunião deve ter a presença de todos os integrantes da equipe, além do cliente. Cabe ressaltar que o cliente não necessariamente é alguém da empresa que comprou o software. O cliente pode ser alguém que trabalhe na mesma organização que a equipe, mas o seu papel de cliente deve estar bem claro.
Por fim, os membros da equipe precisam ter em mente a possibilidade de mudança. Portanto, o software precisa ser construído para suportá-la. Assim, princípios como o KISS(keep it simple) são frequentemente acoplados aos métodos.

Referências: HIGHSMITH, Jim, COCKBURN, Alistair: Agile Software Development: The Business
of Innovation. IEEE Computer 34(9): 120-122 (2001)

O software muda.
Mas por quê? O software é um produto gerado com o intuito de resolver problemas anteriormente solucionados pela mente humana. Portanto, são problemas muito complexos. Os produtos convencionais são produzidos para resolver problemas simples, geralmente físicos. No caso do software, os questionamentos são muito maiores. Assim, é natural que se perceba que o que foi pensado antes não atende realmente a necessidade, ou então não atende da melhor forma. Surge a necessidade de mudar. Todo processo tradicional, utilizado para produzir qualquer coisa, impõe limites a mudanças. Ao chegar em um restaurante, normalmente conseguimos trocar nosso pedido caso este ainda não esteja sendo preparado. Caso o bife já esteja sendo frito, no mínimo ganhamos uma cara feia. Isto ocorre porque o restaurante terá um prejuízo material: um bife terá de ser jogado fora. No software, não existe prejuízo material. Por isso, a mudança parece custar menos.
Custa? Não sei. Como assim custar menos? Menos que o que? Lógico, não há o prejuízo material, mas temos o prejuízo homem/hora. Porém, não temos como medir este. Com certeza, o retrabalho não é integral quando uma mudança é sugerida. Não jogamos fora o trabalho anterior e fazemos tudo denovo.

Pois então, se sabemos que vai mudar, o que fazer? Os processos de software tradicionais, dirigidos a planos, cobram caro por mudanças. Normalmente, exigem estabilidade nos requisitos, e “te olham feio” quando aparece algo a ser mudado. A lentidão da resposta a mudanças encarece mais ainda o processo. No final, acabamos encaixando as necessidades no plano inicial e pronto. Ora, quem trabalhou com atendimento de clientes de software sabe que isso não é agradável. Passamos bastante tempo desenvolvendo algo que não deixa o cliente completamente satisfeito.
Além disso, um estudo recente de Michael Mah, da QSM Associate, relatou que, no final dos projetos pesquisados, não era possível encontrar metade dos planos originais para realizar uma comparação. Isto porque seguir o plano não é o objetivo principal. A grande meta é satisfazer o cliente.
A realidade é que as etapas dos processos burocráticos são comidas, ou feitas de qualquer jeito para entregar.

O  desenvolvimento baseado em componentes é praticamente uma utopia. Os problemas que o software resolve são diversos e específicos. Somente algumas partes dos problemas são comuns. Essas subdivisões que são reaproveitadas em outros projetos podem constituir um framework, promovendo facilidade no reúso. Mas a idéia de compor um software através da junção de módulos, sem precisar agregar nenhuma parte nova, não condiz com a realidade. Então, num ponto onde seria necessária uma mudança, é provável que a estrutura montada para reaproveitar o máximo os componentes existentes tivesse que ser refeita, ou então um componente teria que ser modificado.

Não é no sentido de “se não pode vencê-la, junte-se a ela” que promovo o processo orientado a mudanças. Promovo o processo orientado a mudanças porque penso que este é um mercado muito chamativo. O cliente que não está comprometido com uma especificação formal e que está interagindo constantemente com a definição do software se sente no controle do processo produtivo. Isto é extremamente agradável para ele, dando um sentimento de dinheiro bem investido.

O que é processo de software?
Procurei no dicionário michaelis online definições da palavra “processo”. A que se encaixa aqui é: “Série de ações sistemáticas visando a certo resultado”. Adaptando para processo de software, se tornaria: Série de ações sistemáticas visando a produção de software. Na definição de Sommerville, “processo de software é um conjunto de atividades que leva à produção de um produto de software”. Ou seja, o processo é tudo que é feito após o desejo de um cliente por um software até a manutenção do mesmo.
Qual a principal diferença entre estas duas definições?
Sommerville não menciona a palavra “sistemática”(ou qualquer outra com o significado semelhante). Portanto, utilizando seu ponto de vista, poderíamos considerar que uma série de atividades quaisquer como um processo de software. Ou seja, qualquer um que produz software utiliza um ou mais processos de software. Logicamente, quem produz software sem haver determinado  atividades sistemáticas tem grandes chances de, em ciclos diferentes, utilizar atividades diferentes, executar atividades de formas diferentes, ou em ordens diferentes.
Por isso, a primeira forma citada por Sommerville para aprimorar o processo de software em uma empresa seria a padronização dos processos. É importante destacar que a qualidade do produto software está intimamente ligada à qualidade do processo que o produz e mantém. Por isto, existe toda esta preocupação em desenvolver bons processos de software.
A indústria de software está cheia de exemplos de projetos fracassados, atrasados, ou que custaram muito mais do que o previsto. Grande parte destas faltas são atribuídas a processos de software inadequados. É sabido que os maiores problemas das organizações de spftware são gerenciais, e não técnicos.
Segundo Sommerville, processos padronizados reduzem os custos dos projetos, aumentam a qualidade do produto e facilitam a inserção de um novo participante na equipe.
De acordo com o discurso lúdico do professor Fabrício Mello, uma pessoa só pode afirmar que entendeu algo quando é capaz de explicá-lo para uma menina de 7 anos. Portanto, aí vai:
Dorothy, se você fizer seu leite achocolatado todo dia do mesmo jeito, lembrando todos os passos, o leite sempre ficará saboroso. Além disso, sua irmã conseguirá observar e aprender rápido como você faz, então em pouco tempo você somente precisará preparar o seu próprio leite.  
Apesar da lógica simples deste pensamento, e de a engenharia de software já o ter evoluído bastante, muitas empresas continuam sem padronização dos processos. É importante que se entenda que a melhoria dos processos por parte de uma equipe necessita da padronização. A primeira fase de qualquer ação de aperfeiçoamento é a avaliação do que está sendo feito até o momento. Caso não haja padronização, é difícil perceber os pontos falhos do processo corrente.
“Se você não sabe onde está, um mapa não o ajudará” Provérbio de Humphrey

Para dar suporte às organizações, foram criados alguns modelos de qualidade de processos. O mais famoso é o CMM/CMMI. O CMM é um modelo de maturidade dos processos, é um guia para melhorar os processos da organização e sua capacidade para gerenciá-los. O CMM descreve caminhos tornar o processo de software algo repetível e previsível.

Existem diversos modelos de processo de software. A maioria deles é baseada em alguns modelos genéricos, que não são exclusivos, ou seja, podemos usar um pouco de cada um. Segundo Sommerville, existem algumas atividades que são comuns a todos. Quatro delas são: Especificação; Projeto e Implementação; Validação; e Evolução. Neste ponto, me permito uma pequena observação. A atividade de Evolução somente é possível graças a natureza facilmente mutável e intangível do produto software. Assim como existe a dualidade onda-partícula da luz, existe a dualidade produto-serviço do software. Voltarei a abordar esse assunto em uma postagem posterior. 

Modelo Cascata 

O modelo genérico mais conservador, e que se assemelha com os processos industriais é o modelo Cascata(Waterfall, em inglês). Nele, as atividades de desenvolvimento são bem definidas, e produzem um documento após sua conclusão. A próxima atividade só começa quando a anterior já estiver acabada. Desta forma, mudanças na definição de requisitos implicam em um custo alto de alteração. Este modelo é indicado caso a confiança no sistema seja importante, já que a documentação produzida é bastante completa. Este modelo também é mais natural que os demais para quem está acostumado com processos de engenharia.  

Desenvolvimento Evolucionário 

É comum o cliente não saber o que quer. Ou então,  mesmo quando ele sabe o que quer, não sabe como quer. Para esses clientes, o desenvolvimento em cascata é caro, já que várias correções terão que ser feitas nas etapas anteriores devido a insatisfações nas etapas posteriores. Com o fim de reduzir os custos de produção do software devido a problemas com os requisitos, sugeriu-se o desenvolvimento evolucionário. Nele, o software é produzido em ciclos menores, apresentando ao cliente implementações anteriores à distribuiçãofinal  para aperfeiçoar os requisitos.  

O desenvolvimento evolucionário pode ser do tipo exploratório, ou prototipação throwaway.

No exploratório, o protótipo contem os requisitos entendidos, adicionando características solicitadas pelo cliente. Ao exibir este protótipo para o cliente, o desenvolvedor deveria dizer: “Isto nós já entendemos. O que mais falta?” No throwaway, o que está mal compreendido que é implementado, para tentar a satisfação do cliente. Neste caso, o desenvolvedor diria: “É isso que você deseja?” 

Engenharia de Software Baseada em Componentes  

Este modelo idealiza um processo de software onde todos os pedaços para a construção de um software já estão prontos. A tarefa principal seria agrupá-los para que façam em conjunto o que se espera do sistema final. Caso os componentes selecionados para compor o sistema não atendam aos requisitos, o que se faz é tentar ajustar os requisitos ou procurar componentes alternativos que entrem em maior conformidade.

Referências: SOMMERVILLE, Ian Engenharia de Software, 8a edição – São Paulo : Pearson Addison Wesley, 2007.

Olá. Eu sou Guilherme Gonçalves Heringer, aluno da graduação em engenharia de computação da PUC-Rio. Este blog foi construído para conter a síntese de um estudo orientado sobre engenharia de software.

O objetivo deste estudo é avaliar e criticar os processos de software utilizados nas empresas brasileiras.

As soluções sugeridas para os problemas de produção de software ainda estão em processo de maturação, devido à recência desta área de estudo(1968). Porém, com a percepção da grande influência que a qualidade dos processos tem sobre a qualidade do software, a preocupação com o desenvolvimento de métodos, técnicas e ferramentas eficazes e eficientes cresceu acentuadamente.

Este é o contexto mundial da evolução da engenharia de software.

Mas uma característica desta disciplina faz com ela que se distancie muito das outras áreas da computação.  Enquanto nas outras disciplinas de computação o desenvolvimento de uma técnica é aceito universalmente, na engenharia de software existe o regionalismo. Isto ocorre porque os relacionamentos de pessoas com elas mesmas, com o computador, e com outras pessoas são o núcleo da influência na construção dos métodos, técnicas e ferramentas.

Como as pessoas são bastante diferentes, e as sociedades em que vivem também têm diferenças, é natural que os métodos, técnicas e ferramentas sejam diferentes para elas. Portanto, a engenharia de software deveria estar ligada ao local onde se encontra o engenheiro.  

Desenvolvendo esta primeira reflexão, farei uma pesquisa, iniciando com um embasamento teórico e, posteriormente, realizarei entrevistas para relacionar o estudo com as abordagens atualmente utilizadas no Brasil.

Referências: SOMMERVILLE, Ian Engenharia de Software, 8a edição – São Paulo : Pearson Addison Wesley, 2007.