Entrevistas

Sem dúvida, de todas as técnicas de coleta de fatos, a mais comum e mais conhecida é a entrevista.

Uma entrevista é normalmente uma comunicação entre entrevistado e entrevistador. No caso de engenharia de requisitos, o entrevistador é o engenheiro de requisitos e o entrevistado é o cliente ou um interessado no software para o qual se quer conhecer os requisitos.

Um interessado pode ser desde um futuro operador de um artefato no qual o software fará parte ou o executivo da empresa que pagará pelo software, mas que dificilmente irá interagir com o mesmo. Portanto, a diversidade de entrevistados demandará estratégias distintas de entrevista.

Entrevistas são classificadas como estruturadas ou não-estruturadas. Uma entrevista estruturada requer um prévio conhecimento sobre o contexto onde se aplica a entrevista. Uma entrevista não-estruturada é aplicada quando se inicia o contato com o Universo de Informações e serve para garimpar informações iniciais. Fundamentalmente o entrevistador deixa o entrevistado falar, mas procura orienta-lo para que a entrevista mantenha o foco no tópico de interesse.

O papel do entrevistador na entrevista não estruturada é um papel de aprendizado.

A entrevista estruturada é feita com base em perguntas previamente pensadas ou delineadas, é uma entrevista mais focada porque é dirigida por um elenco de perguntas que já têm um foco específico. Claro, que o entrevistador tem liberdade de inserir perguntas de clarificação ou eventualmente outras que se façam necessárias, mas o núcleo de perguntas já é definido a priori.

Ressaltamos que muitas vezes a equipe pode usar perguntas preparadas por outros atores, mas é comum que os entrevistadores sejam aqueles que elaboram as perguntas.

Perguntas de controle, que usam de redundância para identificar problemas, é uma maneira de auferir mais qualidade nas respostas.

O papel do entrevistador na entrevista estruturada é um papel de questionador.

O engenheiro de requisitos no papel de entrevistador deve ter cuidados ao conduzir uma entrevista, tanto porque pode estar falando com interessados de alto poder de decisão como também com interessados que podem estar receosos de mudanças organizacionais. O principal é estabelecer, desde do início, um clima de colaboração, no o qual a entrevista é um fator importante para que o contexto seja melhor compreendido pelos profissionais de informática.

Uma entrevista pode ser conduzida por mais de um entrevistador e pode ter mais de um entrevistado.

Cabe ao entrevistador tomar notas ao longo da entrevista. Essa tarefa é difícil. O método de anotar palavras chaves e usar setas para ligar essas palavras chave é o mais recomendado, mas exige prática. A prática de gravar entrevistas e anotar com base na gravação é um recurso que pode ajudar, mas é preciso levar em conta que haverá o custo extra de escutar a gravação. Em alguns casos o entrevistado tem interesse que a entrevista seja gravada, assim como alguns preferem que se evite o uso do gravador. É claro que a política de gravação deve ser acordada com o entrevistado.

As anotações de entrevistas tornam-se documentos do processo de construção de requisitos e devem seguir padrões de armazenamento de modo a facilitar consultas futuras. Esses padrões devem atender aos requisitos de rastreamento.

Aponto quatro referências que apresentam diferentes visões sobre entrevistas. Vale a pena
conferir. A primeira tem uma visão jornalística, a segunda apresenta uma visão do ponto de vista social, a terceira mostra o esquema de um curso sobre entrevistas e a quarta mostra um procedimento padrão para entrevistas de auditoria.

Técnicas de Coleta de Fatos (Elicitação)

Conforme o texto da Seção 3 da Parte III são as seguintes as estratégias que se pode utilizar para coletar fatos:

• Leitura de Documentos
• Observação
• Entrevistas
  
• Questionários
• Análise de Protocolos
• Participação Ativa dos Atores (Clientes)
• Enfoque Antropológico
• Reuniões
• Reutilização
• Recuperação do Desenho

Outra estratégia que é bastante útil é o Ordenamento de Cartões. Essa técnica é útil para elicitarmos relacionamentos entre conceitos, com também para identificarmos níveis de abstração utilizados no Universo de Informações. A técnica consiste em distribuir cartões com frases ou palavras para os interessados (clientes) e pedir que, individualmente ou em grupo, eles formem grupos com os cartões e nomeiem os grupos. Em Inglês chama-se de “Card-Sorting”. Veja aqui uma animação de como funciona essa técnica (clique em "Open Sort") (em Inglês).

Identificação de Fontes de Informação

Na Seção 2 da Parte III, descrevemos a importância da identificação das fontes de informação. Afinal, é da qualidade das fontes de informação que dependemos para elicitarmos o conhecimento do que se demanda do software a ser construído ou evoluído.

Além de ressaltarmos que as fontes de informação podem ser de diferentes tipos, além de pessoas, detalhamos heurísticas gerais que ajudam na identificação de fontes de informação.

Em um artigo publicado no WERpapers, um método para identificação de fontes de informação é proposto. O método é colaborativo e envolve pelo menos três engenheiros de requisitos. São 5 as etapas a serem seguidas pelo método.

1. Seleção: nesta etapa, cada engenheiro de requisitos, usando as heurísticas como as da Seção 2, elabora uma lista de fontes de informação encontradas no Universo de Informações. A heurística principal consiste em que observar as fontes de informação que respondem as perguntas: O que? Quem? e Onde?. O “o que” normalmente leva a documentos ou sistemas, o “quem” leva a atores do Universo de Informações e “onde” leva a lugares onde o software irá operar.
2. Desenho: cada engenheiro desenha um grafo de influência ligando através de relacionamentos as várias fontes de informação.
3. Consolidação: em uma reunião os engenheiros constroem coletivamente um grafo que consolide os grafos construídos individualmente.
4. Eleição: em uma reunião com base no grafo consolidado os engenheiros discutem e propõem estratégias de elicitação para cada fonte.
5. Avaliação: através de reunião os engenheiros estabelecem prioridades e custo associados a cada fonte.

Elicitação

A palavra acima é um neologismo. Foi criada para distinguir essa tarefa tão fundamental para a construção de software.

O texto na Parte III define-a como uma mescla de outras palavras como: clarear, entender, extrair. A Figura 1 da Parte III procura detalhar a semântica de elicitar.

A Necessidade da Elicitação

A Seção 1 (Introdução) da Parte III ressalta a importância da tarefa de entendermos o que é preciso ser feito, antes de começarmos a fazer. Essa afirmação é óbvia, mas é muitas vezes esquecida por engenheiros que se apressam em construir antes de entender exatamente o que se deseja construir. Para ressaltar a importância da tarefa de ELICITAR citamos no texto dois autores: von Neumann e Polya. Dois matemáticos: um deles é o responsável pela teorização que levou a concepção dos computadores digitais; outro é responsável por uma série de trabalhos no campo da matemática e do seu ensino, em particular a maneira de resolver problemas.

Sobre von Neumann repito aqui o que escrevi em outro lugar:

Por que os requisitos são importantes? São várias as razões, mas: a mais evidente é porque não se pode construir nada, sem que antes saiba-se o que se quer construir. Eu utilizo, há muito tempo, uma frase atribuída a von Neumann que diz:

There is no sense in being precise about
something when you do not even know what you
are talking about.

Esta frase foi encontrada em um dos livros de Gerald Weinberg. Cabe a ele a citação original. Vale lembrar quem foi von Neumann. Veja também este elo.

Sobre Polya, utilizei três questões que são freqüentes em várias citações ao seu trabalho:

a) “What is the unknown?” ( qual a incógnita?)
b) “Do you know a related problem?” (conheces um problema semelhante?)
c) “Could you restate the problem?” (podes repetir o problema com suas palavras?)

Alcino Simões e Lisette Poggioli fornecem mais detalhes sobre o tema. A Universidade de Lisboa disponibiliza um resumo sobre Polya.

Além das citações a Polya e a von Neumann, gostaria de ressaltar alguns truísmos que identifiquei em um artigo de Michael Jackson, e que considero de fundamental importância.

a)"Distinguish the machine from the problem domain"
b) "Don’t restrict description to the machine",
c) "State explicitly what is described".
d) “Requirements Are Not Given Properties”,
e) “The Model Is Not the Reality”, and
f) “The Problem Is Not at the Interface”

Esses “mantras” estão contextualizados na diferença que Jackson faz da máquina computacional (software e hardware) e o contexto no qual essa máquina irá atuar (“problem domain”). Para ele requisitos é a ponte entre o contexto (Universo de Informações) e a máquina.

Desses seis “mantras” é importante saber: que o “problema” não está na interface, que requisitos não são propriedades previamente existentes, que a máquina deve ser entendida como separada do Universo de Informações e que o modelo não é a realidade.

Fundamentalmente, os “mantras” de Jackson expressam a necessidade da elicitação dos requisitos, e que esses precisam refletir a perspectiva da máquina e a perspectiva do contexto onde a máquina irá atuar.

Evolução do Universo de Informações

A Figura 17 página 26 (Parte II) mostra algo que, comumente, é esquecido.

A Figura mostra que o Universo de Informações evolui na medida em que construímos os requisitos! Ou seja, a base, que utilizamos para entendermos o que os clientes desejam, muda durante o processo de construção dos requisitos. É preciso ter consciência de que isso é uma dificuldade, a mais, no processo de entender as necessidades dos clientes.

Portanto, é importante que a fase de construção de requisitos tenha uma visão de processo contínuo. É preciso saber que os requisitos não estão prontos para serem descritos e formalizados, que o próprio processo de questionamento dos requisitos leva a com que eles mudem.

Processo de Construção de Requisitos

A Figura 16 página 25 mostra nosso entendimento do processo de construção de requisitos. Essa Figura é de um modelo SADT [Ross 77] do tipo “actigrama”, ou seja utiliza a perspectiva de função ou atividade. Nele vemos o quão importante é escolher as pessoas e os métodos com que se irá trabalhar. Mostra também que, fundamentalmente, o processo de construção de requisitos (no livro uso o termo definição) é pautado por três atividades: elicitar, modelar e analisar. É importante notar que a saídas dessa Figura: delta, requisitos e modelo refletem: a importância da retro-alimentação, o papel de comunicação dos requisitos em linguagem natural e a necessidade de utilização de modelos para explicitar a semântica dos requisitos.

A Figura 16 abstrai-se do processo gerencial que é ortogonal ao processo de construção e que fundamentalmente cuida para que o processo seja eficaz e eficiente. Particularmente importante, é notar, que o ciclo de retro-alimentação é inerente ao processo, através da produção de deltas. Esses deltas podem ser gerados pelas atividade de análise. No contexto da atividade de análise é importante ressaltar a implementação de políticas de qualidade quer por processos de verificação, quer por processos de validação.

Referência Bibliográfica

[Ross 77] Douglas T. Ross: Structured Analysis (SA): A Language for Communicating Ideas. IEEE Trans. Software Eng. 3(1): 16-34 (1977)

Universo de Informações

A Seção 2 da Parte II procura ressaltar o papel de contexto na produção de software. O texto enfatiza a importância de modelos como força de contextualização. Esses modelos estabelecem perspectivas para os engenheiros de software.

O conceito de Universo de Informações (UdI) é essencial na produção de software. Todo processo de software tem um UdI, no entanto muitas vezes os engenheiros de software não tem um mapa desse UdI. Você já esteve numa situação onde, em terras estranhas, você precisa locomover-se? Turistas precisam de mapas, porque querem saber como locomover-se em lugares com os quais não tem familiaridade.

Definimos UdI como:

"É o contexto no qual o software deverá ser desenvolvido e operado. O UdI inclui todas as fontes de informação e todas as pessoas relacionadas ao software. Essas pessoas são também conhecidas como os atores desse universo. O UdI é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software."

É no UdI que os engenheiros de requisitos irão trabalhar. É no UdI que o software desempenhará suas funções.

Saber da existência do UdI é fundamental. Saber que o UdI é um corte da realidade, ou seja é uma redução do contexto mais geral, mundo, para um contexto mais específico. Em Banco de Dados utiliza-se o nome Mini Mundo. O termo escopo é também utilizado em alguns métodos de produção de software.

O UdI é representado por uma forma que se assemelha a uma nuvem. Essa forma é importante porque mostra que os limites (vejam os pontos fundamentais da TGS, Parte I) não são bem definidos. A forma gasosa da nuvem passa também a idéia de volatilidade, e essa característica é também presente no UdI, em maior ou menor grau, dependo de cada caso. Na verdade, o UdI diminui ou aumenta na medida em que, no processo de construção de software, melhor entendemos as necessidades dos clientes e as restrições de implantação. O UdI evolui.

A estratégia para mapear o UdI é fundamentada no objetivo mais geral disponível. Ou seja, no evento que dispara o uso do SDS (veja entrada do SDS). Um processo de produção de software é iniciado por atores que têm interesse na construção ou evolução de um determinado artefato de software. Vejamos três casos como exemplo.

Caso 1: uma empresa produtora de software tem conhecimento de um edital para concorrência pública para a evolução de um sistema de software. O edital mencionará o objeto da concorrência, a infra-estrutura de software pré-existente, normas de produção, por exemplo, a Mps. Br, local físico onde o trabalho deverá ser implantado entre outras informações. Nesse caso, o edital, através de suas informações, delineia a primeira versão do UdI.

Caso 2: o departamento de software de uma organização recebe um memorando do diretor financeiro pedindo que um novo sistema de software seja feito para auxiliar a visualização do acompanhamento do fluxo de caixa da organização. O UdI nesse caso já tem um delimitado o ator requisitante (diretor financeiro), o objetivo geral (software de visualização) e onde será empregado (integração como sub-sistema de fluxo de caixa).

Caso 3: um empreendedor resolve apostar na construção de um software para ajudar as pessoas no controle de suas finanças. O empreendedor acredita que as soluções disponíveis deixam a desejar e pensa em fazer um software, que será acessado via navegadores padrão, com facilidade de mobilidade (celular). Portanto esse empreendedor já estabeleceu os contornos do UdI em pauta.

Para a Engenharia de Requisitos o UdI é de fundamental importância porque será no UdI que as fontes de informação serão identificadas. Essas fontes de informação é que permitirão com que o delineamento do UdI seja elaborado e constantemente evoluído. O Engenheiro de Requisitos precisa das fontes de informação da mesma maneira que um repórter precisa de fontes para escrever uma matéria.

O UdI é formado através de aproximações sucessivas, principalmente na identificação de fontes de informação. As fontes de informação podem ser de diferentes tipos, sendo as principais: atores (pessoas ou organizações), artefatos de software, artefatos físicos e documentos.

Uma estratégia utilizada para identificar as fontes de informação é saber que fonte de informação aponta para outras fontes de informação. As fontes mais referenciadas certamente deverão ser consideradas na formação do UdI: se pensarmos em grafos essas fontes seriam nós com um maior número de elos.

Outra maneira de identificar a importância de fontes de informação é através de prioridades. No que se refere a atores, normalmente os "donos" do software são os de maior prioridade.

Um mapa de fontes de informação se assemelharia ao uma rede, como a mostrada num mapa de ligações entre grandes corporações alemãs. O uso do software "They Rule" permite que você monte seu próprio mapa de atores do mundo corporativo americano.

Modelos

Na parte II, ressaltamos quatro pontos fundamentais para melhor entendermos o contexto de um artefato de software.

São eles:

• Aspectos Sociais
• Modelos
• Um Sistema é Sempre um Sub-Sistema de um Sistema Maior
• A Definição de um Sistema é Função da Implantação de Seu Macro-Sistema
• Falácia da Completeza
• Falácia da Página em Branco

Um desses pontos é o conhecimento de modelos (páginas 4 e 5, Parte II). Aqui usamos o sentido da palavra modelo de uma forma bastante ampla. Modelos são abstrações gerais sobre algo do mundo real. Apresentamos diferentes Modelos na Seção 3 da Parte II.

Um desses modelos é o modelo de Sá Carvalho. Esse modelo mostra que, para entendermos o que uma Fábrica de Informações deve produzir, é necessário saber quais as ações concretas que ocorrem no contexto organizacional em que essa Fábrica funcionará. Veja que Sá Carvalho usou de uma analogia para descrever Sistemas de Informação como Fábricas. Ações concretas são ações que ocorrem numa organização e que estão diretamente relacionadas com seus objetivos.

O modelo de Sá Carvalho mostra que devemos deslocar o foco do que a Fábrica produz, ou deverá produzir, e centrar nossa atenção na razão da existência da Fábrica. Dessa maneira, o modelo nos ensina que, para chegarmos as saídas da fábrica, devemos fazer um percurso inverso: identificar as ações, identificar as tomadas de decisão que motivaram a ação, e identificar as informações necessárias para as decisões.

Especificação versus Requisitos

Essa nota repete o que está na Página 2 da Parte II do pré-livro.

Veja aqui a diferença, conforme o dicionário do Aurélio.

Sistema de Desenvolvimento de Software

A Figura 11 na página 20 (Parte I) é um modelo que descreve as partes fundamentais de uma organização que tem por objetivo produzir software. Sua descrição é feita na linguagem SADT (Structured Analysis and Design Technique) de Douglas Ross. No caso estamos usando uma das perspectivas do SADT, a perspectiva de dados (datagrama).

Essa Figura foi produzida com base no livro de Peter Freeman Software Perspectives: The System is the Message e retrata como 5 sub-sistemas fundamentais para a produção de software se inter-relacionam. Vejam que temos duas entradas: “ estabelecer objetivos” e “manter o estado da arte”, uma saída: “produzir software” que é uma composição de “criar sistemas”, “organizar sistemas”, “reutilizar software” e “produzir informação”, e três retro-alimentações: “informar sobre o processo”, “medir desempenho” e “arquivar software”. Veja que na Figura a palavra “sistema” é sinônimo de “software”.

Portanto o subsistema Gerência cuida da interface com os clientes da organização procurando entender os objetivos e utilizando os sub-sistemas de Pessoal, Métodos e Ferramentas para atingir os objetivos. Veja o papel do subsistema de Informação que ajuda a gerência tanto para saber como anda o processo como também como o mercado tem evoluído na prática da construção de software. Esse subsistema também é importante por ser repositório do conhecimento produzido na produção do software. Esse modelo coloca o subsistema Pessoal como central no processo de produção. A produção de software é um trabalho criativo acima de tudo; depende da inteligência e criatividade do ser humano, mas para ser mais homogêneo necessita de padrões (sub-sistema de Métodos), como necessita de apoio para uma maior produtividade (sub-sistema de Ferramentas e sub-sistema de Informação).

Veja que essa Figura é independente do processo de produção a ser utilizado pela organização, ou seja, cada organização pode escolher diferentes maneiras de produzir software (diferentes implementações do subsistema Métodos) dependente de uma série de fatores, mas principalmente, do Pessoal disponível, dos objetivos a serem atingidos assim como pelas Ferramentas disponíveis.

É importante ressaltar que o SDS (Sistema de Desenvolvimento de Software) apresenta um esquema de aprendizado embutido, quer seja combatendo a entropia através da entrada “manter o estado da arte”, bem como aprendendo com os possíveis desvios através de processos de retro-alimentação (“medir desempenho” e “informar sobre o processo”). Ou seja, esta visão do SDS incorpora a idéia do ciclo de aperfeiçoamento presente no ciclo PDCA (veja o uso desse conceito por uma grande empresa) .

Abstração X Formalismo na Produção de Software

A Figura 8 da página 17 (Parte I) é uma tentativa de explicar o dualismo entre alto nível de abstração e alto grau de formalismo. Essa figura procura retratar o problema entre sair do canto superior esquerdo da Figura e atingir o canto inferior direito. O processo de produção de software busca exatamente isso: parte de uma definição abstrata, normalmente informal, e procura atingir uma implantação em forma detalhada e completamente formal. Completamente formal porque será uma descrição a ser executada por uma máquina, que só aceita descrições não ambíguas. Detalhada, porque a máquina é uma máquina construída para tratar lidar com dois estados diferentes (ligado e desligado), e nível lingüístico em que opera, apesar dos compiladores hoje existentes ainda requer um nível de detalhamento bastante grande.

O grande desafio do processo de produção de software é não perder-se na tentativa de sair da origem (canto superior esquerdo) e chegar à meta (conto inferior direito). Ocorre que durante o “caminho” várias distorções podem ocorrer, quer seja devido às falhas no entendimento do que deve ser a meta, a falhas no processo de produção (um desenho equivocado), ou a uma re-interpretação da meta em função de mudanças na origem.

A importância desse gráfico, cuja origem não consigo recordar, mas que está ligado a uma palestra de um Professor da Alemanha, é o de mostrar que o espaço de trabalho do engenheiro de software leva em consideração a dificuldade de ser preciso a um alto nível de abstração e a dificuldade de ser sucinto em face da exigência de um formalismo que impeça interpretações ambíguas.

Forma Canônica

A Figura 7 da página 16 (Parte I) mostra uma abstração do processo de produção em sua forma canônica, isto é na forma mais simples que se pode reduzir o processo de produção de software. Veja que esse modelo, onde o Universo de Informações é a entrada e o Software é a saída, é independente da forma como o processo de produção irá ser executado. Ou seja, pode-se optar por um esquema de protótipos (Figura 5, página 14), por um processo espiral (Figura 4, página 13), por um processo clássico (Figura 3, página 12), por um processo ágil ou pelo processo V.

Independente da estratégia de produção, sempre teremos um início, um meio e um fim. O início está ligado a motivação do que faremos, o meio é como pensamos em tratar o que faremos e o fim é o que fizemos. Portanto: a definição é processo de entender o que vai ser feito; o desenho ou arquitetura é o processo de imaginar como será o que faremos; e a implantação ou código é o processo de programar uma máquina para que ela comporte-se conforme entendemos o que deveríamos fazer. O modo como executamos o meio, o início e o fim, é dependente do esquema de produção (método) escolhido.

Pré-Livro

O Pré-Livro já está disponível na lista aí ao lado e também aqui.

Em breve comentarei os capítulos e eventuais correções ou adições.