Faculdade São Luís de Jaboticabal
Professor: Maurício Perecim
Alunos: Caio Henrique de Souza
Emanuel Brentegani Dias de Souza
Emerson Alexandre Santos
Valmir Gabriel Sanchez
Levantamento
de Requisitos:
Consiste em avaliar, analisar e
estudar os vários métodos disponíveis pela emissão e aprovação das técnicas, as
quais serão aplicadas futuramente, oferecendo algumas formas de divulgação que
orientem outras aplicabilidades.
Um
levantamento de requisitos bem feito traz vários benefícios:
- Aumento da qualidade
dos sistemas: Os desenvolvedores têm a sua disposição métodos que permitem
levantar com precisão as necessidades dos usuários e construir sistemas melhor
estruturados.
- Independência
de indivíduos: Como os sistemas são bem estruturados e têm documentação
padronizada e atualizada, um analista consegue, em pouco tempo, dar manutenção
a um sistema que não conhece, evitando a figura do “dono do sistema”.
- Facilidade de manutenção: Pelos
mesmos motivos acima citados: sistemas bem documentados e estruturados.
- Aumento da produtividade:
Sistemas bem construídos têm mais partes reutilizáveis. E, como o sistema é bem
especificado e projetado, gasta-se menos tempo em testes e “emendas” para
atender ao usuário.
Problemas de um levantamento mal feito:
Nas empresas onde não se utiliza
uma metodologia, o processo de desenvolvimento segue mais ou menos os seguintes
passos:
- O usuário solicita um novo
sistema;
- O analista o entrevista
informalmente para ter ideia dos requisitos do sistema;
- O analista explica o que pensa
que deve ser o sistema para sua equipe e todos se sentam imediatamente diante
do terminal (ou micro) e começam a programar. Nenhuma análise mais profunda é
feita. Projeto lógico, então, nem pensar!
- Muitos meses depois do prazo
prometido ao usuário, o sistema é entregue. Não está documentado e sua
estrutura deixa a desejar;
- O usuário descobre nos três
primeiros dias de uso que o sistema não é o que ele queria. Assim sendo, no
quarto dia, o usuário envia ao analista uma enorme lista de modificações;
- A equipe, então, encarrega-se
de executar as modificações o mais rápido possível, comprometendo ainda mais a
estrutura do sistema;
- O resultado é um sistema que
atende parcialmente ao usuário, não está documentado, terá uma taxa altíssima
de manutenção e não será nada fácil modificar.
Técnicas de elicitação de grupo:
Compreendem técnicas de dinâmica
de grupo com o objetivo de entender de forma mais detalhada as necessidades dos
usuários. Englobam o brainstorming, as sessões JAD e RAD.
Brainstorming: as partes interessadas são
reunidas em um local, cujo ambiente encoraje a participação, sendo todas as
idéias declaradas em voz alta (para que os demais sejam influenciados) e
escritas (para que não sejam perdidas). É mais eficaz quando cada parte interessada
detém uma parte do conhecimento sobre algum aspecto do problema;
JAD (Joint Application Design): conjunto de sessões intensivas e mediadas entre usuários e analistas de um sistema, com o objetivo de explicitar os seus requisitos;
JAD (Joint Application Design): conjunto de sessões intensivas e mediadas entre usuários e analistas de um sistema, com o objetivo de explicitar os seus requisitos;
Os componentes básicos de uma sessão JAD são:
- Patrocinador: é o dono do sistema. Deve
ser influente o bastante na companhia para ser capaz de tomar decisões e prover
os recursos necessários para manter o projeto.
- Líder: geralmente é o líder do
grupo de desenvolvimento da aplicação e é capaz de responder perguntas sobre o
escopo do projeto, tempo, assuntos de coordenação e recursos. Devem participar
das sessões desde que não inibam os participantes.
- Facilitador: comanda a reunião e
direciona o grupo a seguir a agenda estabelecida. É responsável por identificar
os assuntos que podem ser resolvidos como parte da reunião e aqueles que devem
ser colocados no final da reunião para ter uma investigação e resolução. Ele
guia os participantes e não contribui com informações.
- Participantes: clientes da área de
negócios afetada direta ou indiretamente pelo projeto, que são experts em suas
funções e possam tomar decisões sobre seus trabalhos. Eles são a fonte de entrada
na reunião.
-
Observadores: geralmente membros do time de desenvolvimento da
aplicação do projeto.
Observam silenciosamente os
procedimentos.
A sessão JAD deve ter objetivos
bem definidos, agenda detalhada e modelos, além de um documento final contendo
todas as decisões tomadas pelo grupo.
As cinco fases das sessões JAD
são:
- definição do projeto JAD;
- pesquisa nos requisitos do
usuário;
- preparação para a sessão JAD;
- conduzir e intermediar a sessão
JAD;
- demonstrar e obter aprovação do
documento final que incorpora todas as decisões tomadas.
RAD (Rapid Application
Development): metodologia
que combina o JAD (para definir rapidamente a especificação do sistema) com o
uso de ferramentas CASE e de metodologias de prototipação, para chegar a um
produto final em menor tempo.
A técnica RAD é um bom ponto de
partida para a elaboração do projeto de interfaces, através de protótipos
elaborados por uma equipe formada por usuários finais e programadores de
sistemas, ferramentas aplicadas para o desenvolvimento do protótipo, métodos e
telas que serão exibidos, retorno das sugestões elencadas pelos usuários, novas
apresentações com o feedback incluído.
Usando de
forma implícita a orientação a objetos, essa técnica fundamenta-se nos
seguintes conceitos: projeto centrado no usuário, prototipação rápida, e
modelagem de objetos
Prototipação:
Um protótipo é
uma visão inicial de um sistema de software, onde possibilita demonstrar
conceitos, experimentar opções de projeto, e em geral para conhecer o problema
e suas possíveis soluções. Em suma, a prototipação é o processo que possibilita
que o programador de software crie um modelo que será construído.
Protótipos é, de modo análogo, uma maquete para a arquitetura, de um sistema
futuro com o qual pode-se realizar verificações e experimentações para se
avaliar algumas de suas qualidades antes que o sistema venha realmente a ser
construído.
A prototipação pode ser utilizada como técnica de análise e redução de riscos
(erros e omissões) pode também se utilizada para outros propósitos, como
treinamento de usuários antes que o sistema seja entregue e também para testes
no sistema.
Uma das dificuldades para a
prototipação de software é que os usuários finais têm dificuldades para prever
a utilização do software e se o sistema é muito complexo a dificuldade aumenta,
chegando a ser quase impossível fazer uma avaliação..
Técnicas
contextuais:
A etnografia é uma técnica de observação que pode ser utilizada para
compreender os requisitos sociais e organizacionais, ou seja, entender a
política organizacional bem como a cultura de trabalho com objetivo de
familiarizar-se com o sistema e sua história. Os cientistas sociais e
antropólogos usam técnicas de observação para desenvolver um entendimento
completo e detalhado de culturas particulares. Nesta técnica, o analista se insere no
ambiente de trabalho em que o sistema será utilizado. O trabalho diário é
observado e são anotadas as tarefas reais em que o sistema será utilizado. O
principal objetivo da etnografia é que ela ajuda a descobrir requisitos de
sistema implícitos, que refletem os processos reais, em vez de os processos
formais, onde as pessoas estão envolvidas.
Etnografia é particularmente eficaz na descoberta de dois tipos de requisitos:
- Os requisitos derivados da maneira
como as pessoas realmente trabalham, em vez da maneira pelas quais as
definições de processos dizem como elas deveriam trabalhar;
- Os requisitos derivados da cooperação
e conscientização das atividades de outras pessoas.
Alguns itens importantes que devem ser
executados antes, durante e depois do estudo de observação:
Antes, é necessário identificar
as áreas de usuário a serem observadas; obter a aprovação das gerências
apropriadas para executar as observações; obter os nomes e funções das pessoas
chave que estão envolvidas no estudo de observação; e explicar a finalidade do
estudo;
Durante, é necessário familiarizar-se
com o local de trabalho que está sendo observado. Para isso é preciso observar
os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas;
coletar amostras de documentos e procedimentos escritos que são usados em cada
processo específico que está sendo observado, e acumular informações
estatísticas a respeito das tarefas, como: frequência que ocorrem, estimativas
de volumes, tempo de duração para cada pessoa que está sendo observada. Além de
observar as operações normais de negócios acima é importante observar as
exceções;
Depois, é necessário documentar as
descobertas resultantes das observações feitas. Para consolidar o resultado é
preciso rever os resultados com as pessoas observadas e/ou com seus superiores.
A análise de observação tem algumas desvantagens como, consumir
bastante tempo e o analista ser induzido a erros em suas observações. Mas em
geral a técnica de observação é muito útil e frequentemente usada para complementar
descobertas obtidas por outras técnicas.
Técnicas
Complementares:
Além das técnicas mostradas
acima, a equipe do projeto pode fazer uso de outras técnicas como a troca de
e-mail e a realização de reuniões (presenciais ou áudio conferência), para
elicitar os requisitos que formarão o escopo do projeto. Para projetos de
manutenção de pequeno porte, onde a quantidade de partes interessadas e a
quantidade de informação a ser elicitada é pequena, a utilização de e-mails ou
reuniões podem agilizar o processo de elicitação dos requisitos.
Porém,
quando há uma grande quantidade de informações a serem coletadas para
definição do escopo do projeto e existem diferentes partes
interessadas, com diferentes visões e expectativas, é mais indicada a
utilização concomitante de e-mail e reuniões com uma ou mais técnicas listadas
acima para um melhor detalhamento das informações.
Para
diminuir as chances de obtenção de diferentes entendimentos acerca do que foi
levantado, o importante é manter as informações registradas por meio de ata de
reunião, no caso de reuniões, e no caso de e-mail, deixá-los guardados para que
a informação elicitada não se perca no decorrer do projeto. Para isso deve-se
disponibilizar a ata de reunião e/ou os e-mails na VOB para futuras consultas
por parte da equipe do projeto. Vale ressaltar que para o caso dos e-mails,
estes devem estar previstos no PGCS.
Em
caso de demandas sumárias, bem pontuais, onde a descrição da demanda traga
todas as informações necessárias para a análise e documentação dos requisitos,
a descrição da demanda pode ser considerada a elicitação dos requisitos para o
projeto
Resumo
das técnicas apresentadas:
Técnicas tradicionais – incluem o uso de
questionários com perguntas pré-definidas, usado quando o número de usuários ou
interessados no sistema é muito grande facilitando a coleta das informações
mais importantes, caso o número de pessoas interessadas seja menor, pode-se usar
a técnica das entrevistas, utilizando sempre perguntas relevantes sobre o
problema que o sistema deve corrigir, é importante lembrar que tanto o
entrevistador quando o entrevistado deve possuir um alto conhecimento e real
interesse em contribuir com o sistema.
Técnicas de Elicitação de grupo: - São técnicas aplicadas a
grupos de interessados no sistema, a fim de buscar as melhores ideias para o
desenvolvimento, através de reuniões estimulando os participantes ativamente
para que seja criado a maior quantidade de ideias possível, e no fim é feito um
filtro para escolher quais serão implementadas.
Prototipação: A ideia de protótipo é mostrar
para o usuário como será o sistema e auxiliar o programador do software a criar
um modelo, a utilização de protótipo diminui a chance de riscos no sistema além
de servir como treinamento para o usuário, a dificuldade de protótipo é fazer
com que o usuário consiga enxergar a utilização futura no caso de sistemas
muito complexos.
Técnicas contextuais: Utiliza a etnografia, ou seja,
um desenvolvedor passa a acompanhar as rotinas dos usuários, aprender sobre as
dificuldades e problemas vividos no dia-a-dia para poder desenvolver o sistema
que atende as necessidades da empresa.
Fontes:
