O documento discute a importância da engenharia de software e da coleta de requisitos por meio de entrevistas com usuários. Ele fornece diretrizes para realizar entrevistas eficazes, como desenvolver um plano geral de perguntas e obter autorização superior, e aborda formas comuns de resistência dos usuários e outras técnicas para coleta de dados além de entrevistas.

1. Aula 001
Projeto de Sistemas
PRONATEC
Programa Nacional de Acesso ao
Ensino Técnico e Emprego

2. PRONATEC
Programa Nacional de Acesso
ao Ensino Técnico e Emprego

3. 1. Engenharia de Software
• Ciência de aplicar os conhecimentos técnicos e
científicos na criação, aperfeiçoamento e
implementação de projetos de softwares e sistemas
de computador.
• No inicio da década de 80, na primeira página da
revista Business Week dizia: "Software: A Nova Força
Propulsora“
• Em meados da década de 80, a capa da Fortune: "Uma
Crescente Defasagem de Software“
• Começo da década de 90 a Newsweek perguntava:
"Podemos Confiar em Nosso Software?"
• A Engenharia de Software foi criada para preencher a
lacuna criada pelo advento do invento e disseminação
do uso do computador e o que o alimenta: Software

4. 2. Problemas Associados ao Software
• Estimativas de prazos e de custos que são
freqüentemente imprecisos
• Produtividade dos profissionais da área que não tem
acompanhado a demanda por novos serviços;
• A qualidade do software desenvolvido que é
insuficiente
3. A importância do Software
• Antes da década de 80 o principal desafio era criar um
hardware que reduzisse o custo de processamento e
armazenagem de dados
• Hoje o desafio é melhorar a qualidade e reduzir o
custo de soluções baseadas em computador - soluções
que são implementadas com software

5. 5. Categoria dos Softwares
• Software Básico: programas para dar apoio a outros
programas com forte união ao hardware.
• Software de Tempo Real: usados para monitorar, analisar e
controlar eventos do mundo real.
• Software Comercial: maior área de aplicação de softwares.
Controlam operações comerciais para facilitar o
gerenciamento do negócio na empresa
• Software Cientifico e de Engenharia: algoritmos de
processamento numérico pesados para áreas de pesquisa e
da ciência
• Software Embutido: executam atividades específicas e
inseridos em produtos inteligentes
• Software de Computador Pessoal: criados para uso pessoal
tais como planilhas, editores de textos, jogos, etc..
• Software de Inteligência Artificial (IA): aloritmos sofisticados
que imitam o pensamento humano de tomada de decisão

6. 7. Paradigmas: Engenharia de Software
• Paradigmas são os modelos de processos que possibilitam:
• Ao gerente - controlar o processo de desenvolvimento de
softwares
• Ao desenvolvedor - obter a base para produzir, de maneira
eficiente, software que satisfaça os requisitos
preestabelecidos
8. Processos de Software
• conjunto de atividades e resultados associados que levam à
produção de um novo “software”
• Atividades: Especificação de Software, Projeto e
Implementação, Validação e Teste, Evolução e Manutenção.
• Resultados: Retroalimentação (feedback) como forma de
avaliar o quão eficaz e eficiente o software final está para
refazer atividades e adequá-lo aos objetivos propostos

7. 9. Especificação do Software
• Forma de conhecer o software e qual seus objetivos
primários e objetivos parciais.
• Geralmente feito por meio de Técnicas de Entrevista e Coleta
de Dados com o Usuário por intermédio de um “Analista de
Sistemas”
• Precisamos coletar informações e compreender sobre o
comportamento do sistema atual e seus requisitos para
elaborarmos um projeto consistente, preciso e com
parâmetros para calcularmos o seu cronograma e custo
• Entrevista entre Analistas e os usuários do sistema fazendo
anotações sobre o funcionamento do software
• Na entrevista podem ser usadas ferramentas: gravadores,
câmeras, planilhas, processadores de texto, para estruturar o
resultado da entrevista e facilitar seu entendimento

8. 10. Problemas com as Entrevistas
• Entrevistar a pessoa errada na hora errada: entrevistar
usuários que não tem conhecimento muito detalhado sobre
o sistema, ou que são específicos demais. Também marcar
entrevistas para horários onde o usuário não estará
totalmente focado no assunto.
• Fazer perguntas erradas e/ou obter respostas erradas: sendo
analista e usuário de “mundos” diferentes pode acontecer
de o analista perguntar sem que o usuário entenda ou o
usuário responder sem que o analista o compreenda. O
maior perigo é isso acontecer sem que nenhum dos dois
perceba. O melhor é marcar mais de uma reunião sobre o
mesmo tema para confirmar
• Criar ressentimentos recíprocos: o usuário poderá dificultar
o trabalho por ficar receoso de que o novo sistema irá lhe
dificultar ou mesmo tirar seu trabalho. O perigo é ele prestar
informações inverídicas do funcionamento do sistema.

9. 11. Diretrizes para uma boa Entrevista
• Desenvolva um plano geral: Procure já elaborar linhas gerais de perguntas
de acordo com as funções exercidas pelos usuários. No momento da
entrevista poderão surgir adequações mas as linhas gerais permaneceram.
• Obtenha autorização superior: o analista deverá usar o organograma
(formal ou informal) para saber quem são os reais usuários que sabem
dizer sobre o funcionamento do sistema e marcar com seus chefes as
entrevistas.
• Procure não fazer perguntas redundantes: o usuário poderá dar respostas
de uma vez a mais de uma pergunta, então poupe o tempo dele e já salte
as perguntas respondidas
• Utilize ferramentas automatizadas mas não abuse: o usuário poderá ficar
entediado se usar muitos recursos automáticos e a entrevista pode não
render o esperado
• Procure o interesse do usuário: descubra quais funções no sistema o
usuário mais domina e tem mais afinidade e parta desse princípio com sua
entrevista
• Use um estilo adequado de entrevistar: respeite o usuário, ele é quem é o
perito no sistema, você é quem deve aprender com ele. Não o intimide,
nem o coaja, a não ser em casos muito extraordinários.

10. 12. Formas de Resistência à Entrevista
• Você está tomando tempo demais de mim: o usuário pode reclamar de
estar perdendo tempo com sua entrevista, procure lembrá-lo que
posteriormente com o sistema pronto ele terá uma ferramenta que
aumentará a sua produtividade
• Você está ameaçando meu emprego: não minta nem prometa nada ao
usuário, você não é o patrão dele, esse receio pode ou não ter
fundamento. Se tornar-se impedimento à entrevista comunique aos
superiores dele ou ao responsável pela criação do sistema.
• Você não conhece nossa empresa como quer dizer como deve ser o novo
sistema? Responda: você tem razão, por isso estou lhe pedindo ajuda com
esta entrevista para poder entender melhor e fazer o sistema o mais
correto possível
• Você está mudando as coisas aqui: tente convencer o usuário de que o
sistema irá beneficiá-lo e não o contrário.
• Não quero esse sistema: essa é uma variante da ameaça de emprego,
novamente não minta nem prometa nada. Se persistir a dificuldade na
entrevista é melhor direcionar aos superiores e aos responsáveis
• Por que você está desperdiçando nosso tempo com isso? O usuário tem a
noção errada de que se ele sabe você também deveria saber. Tente
explicar a ele que a sua área de atuação não é a mesma dele.

11. 13. Outras Formas de coleta de dados
• Questionários: com perguntas diretas, coerentes e não redundantes.
Distribua os questionários aos usuários do sistema
• Observando outros softwares: pode ser que outros já tenham
desenvolvido softwares para o que você está trabalhando ou partes dele.
Peça cópias de demonstrações e manuais caso existam para compreender
o sistema, marque entrevistas com os usuários desses sistemas usando o
software juntamente com eles para melhor compreensão
• Visitas a outras empresas: se o sistema a ser criado já existem em outra
empresa que não se importa em fornecer detalhes do seu funcionamento
marque entrevistas com os responsáveis daquele software para o
conhecer melhor.
• Coleta de Dados: Procure formulários, relatórios, manuais, procedimentos
escritos,registros, imagens de tela de terminais e listagens de programas
que já existam na organização usuária onde o sistema será criado
• Pesquisa externa: Se você estiver construindo um sistema para uma nova
aplicação, para a qual o usuário não dispõe de qualquer experiência para
descrever os requisitos, talvez seja necessário tentar obter informações
em sociedades profissionais, ou em periódicos e livros técnicos e em
relatórios de pesquisas