Atividades para An�lise de Viabilidade

Concep��o do projeto de sistemas - Fase inicial, que n�o significa que o sistema
vai prosseguir, ainda h� a possibilidade daquele projeto ser abortado em fun��o de
alguma invibilidade. Em geral � um momento de reflex�o, de escolha de qual projeto
vai para o andamento e an�lise dos projetos a serem desenvolvidos na empresa.
Quando a empresa escolhe qual � o projeto, inicia-se a fase de concep��o, aonde a
gente vai recolher as informa��es fundamentais do sistema, vamos fazer uma an�lise
de viabilidade para aferir se aquele projeto � fact�vel ou n�o. Os tipos de
projetos que podem ser s�o : Novo sistema (projeto de um sistema novo, in�dito),
Melhorias do sistema(melhoria de um software existente) e pode ser Novas Solu��es
Tecnol�gicas(mudan�a de alguma tecnologia que voc� vai substituir para que
determinado processo/atividade tenha uma melhor flu�ncia e agilidade). Em geral
nessa fase a gente vai alimentar um documento, que vai trazer inicialmente as
informa��es b�sicas do sistema como: descri��o do produto(sistema) em linhas
gerais, objetivos, problemas que ele ajusta, premissas, restri��es (econ�micas,
t�cnicas, financeiras, operacionais), benef�cios que o projeto vai trazer para a
empresa depois de pronto, escopo do sistema (a abrang�ncia do sistema) e come�amos
a detalhar os requisitos (atividades do sistema/caracter�sticas). Surge uma a��o
importante que � An�lise de risco,nesse momento a gente deve tentar visualizar
todos os riscos que aquele projeto tem de n�o chegar ao final (seja por n�o ter m�o
de obra, por n�o ter estrutura, faltar dinheiro), por exemplo, o cliente n�o sabe o
que ele deseja, isso � um risco muito grande,temos que traz�-lo para a realidade;
tem muita rotatividade de pessoal na equipe, isso tamb�m � um problema;tamanho do
software subestimado, o tamanho dele tamb�m pode ser um risco muito grande; prazos
e custos subestimados,quando voc� vai ver � muito mais do que aquilo que voc� tinha
estimado; e eventualmente o uso de novas tecnologias que vai trazer com que eu n�o
tenha m�o de obra para aquilo, no caso de uma tecnologia que ainda n�o foi usada.
Isso s�o aspectos importantes, vamos nos preocupar tamb�m com a estimativas de
atividades (CRONOGRAMA), estimativa de custos (OR�AMENTO). As quest�es que eu tenho
nesse momento � : existe tecnologia para desenvolver esse produto? O sistema traz
benef�cios? Esses benef�cios trazidos compensam os custos? � poss�vel operar aquele
sistema? tudo isso vai trazer o momento n�mero 2 dessa fase que � o ESTUDO DE
VIABILIDADE, n�s vamos agora avaliar efetivamente em fun��o dos v�rios riscos j�
apontados, considerando os custos, o cronograma, or�amento, a equipe, enfim todo o
contexto e avaliar se aquele sistema � vi�vel: Primeiro TECNICAMENTE: Capacidade,
confiabilidade, disponibilidade da TI necess�ria, se toda a tecnologia est�
dispon�vel,se existe m�o de obra qualificada para atender aquela demanda, se a
empresa tem experi�ncia com aquela tecnologia, s�o aspectos t�cnicos que s�o
considerados.
Depois vamos pensar em aspectos ECON�MICOS/FINANCEIROS - Aonde ir� comprovar se os
retornos que o sistema vai trazer foram superiores ao custo, ao investimento que
foi demandado para que ele fosse realizado, temos que avaliar nesse momento:
Proje��o de receitas ao longo do per�odo, proje��o dos custos, despesas e
investimentos, proje��o de fluxo de caixa, a partir de tabelas temos indicadores:
VPL - Valor Presente L�quido, se for maior que zero quer dizer que o projeto tende
a gerar lucro.
TIR - Taxa Interna de Retorno, vai medir a rentabilidade do investimento em
percentual.
PAYBACK - Vai mostrar o tempo de retorno do investimento.
Conclus�o de um projeto bom:Ele tem que ter economia dos custos, aumento de
receitas, redu��o de despesas ou aumento da lucratividade. Esses elementos tem que
se comportar positivo de maneira que a gente consiga dizer que o projeto �
economicamente vi�vel.
Existe a viabilidade OPERACIONAL (onde vou analisar se toda a opera��o do sistema �
fact�vel, ent�o o grau de adequa��o da empresa vale a pena? se a necessidade de
parcerias para o desenvolvimento, contrata��es externas, se h� o apoio da alta
gest�o), outro fator importante � a quest�o do CRONOGRAMA (os prazos tem que ser
prazos reais, para n�o extrapolar).
Nesse momento a gente tem uma conjuntura econ�mica/financeira e operacional, que a
gente pode chegar a conclus�o final para ver se o sistema � fact�vel de ser
desenvolvido, se mostrar invi�vel t�cnico, econ�micamente ou de algum fator
poss�vel pode ser que esse projeto n�o aconte�a, ent�o ele morre naquele momento, o
projeto � abortado, � feita a documenta��o e ele n�o vai para o desenvolvimento. Se
for ben�fico, ele vai para o desenvolvimento.realizado.
A CONCEP��O leva a gente para a fase de an�lise, ou conclui-se que aquele sistema �
invi�vel e o mesmo � engavetado.

VIDEO 2 - CLASSIFICA��O DE REQUISITOS

Conceitos de Requisitos - � a mat�ria prima do desenvolvimento de um sistema.
No dicion�rio: Requisito - � uma condi��o necess�ria e indispens�vel para realizar
algo.
� uma necessidade que existe e quem tem essa necessidade s�o os usu�rios do
sistema.
Os requisitos v�o descrever os servi�os que aquele sistema vai ter e as restri��es
sobre esses servi�os. Ex:tenho que ter um relat�rio, mas ele n�o pode demorar mais
do que 5 segundos. Ent�o o servi�o � o relat�rio, vai especificar que relat�rio �
esse e a restri��o � que tem que ser impresso em 5 segundos.
S�o as necessidades do sistema, do ponto de vista dos seus usu�rios, da� a
import�ncia que a defini��o tem que ser clara, pois preciso entender o que as
pessoas precisam para descrever com clareza o requisito daquele sistema.
Fatores que levam ao fracasso de um projeto: Requisitos incompletos, falta de
envolvimento dos usu�rios, falta de recursos, expectativas irreais, falta de apoio
executivo, mudan�a nos requisitos, falta de planejamento, sistema n�o mais
necess�rio.
Temos 2 classifica��es de requisitos:
1 - CLASSIFICA��O QUANTO A FORMA DE ESPECIFICA��O - Pode ser escrita de duas
formas: pelo Requisitos de usu�rio e Requisitos de sistemas. Onde:
Requisito de usu�rio- � o mais abstrato, aquele que uso em um primeiro momento,
onde eu estou captando e conversando com as pessoas, para entender as necessidades
delas. Ela vai descrever o requisito, seja ele funcional ou n�o-funcional,sobre o
ponto de vista dos steakholders (que s�o os interessados no desenvolvimento de
sistema : gestores, analistas, usu�rios). Esses requisitos de usu�rios v�o
identificar aqueles que n�o s�o t�cnicos. � uma linguagem informal, as vezes uso
umas tabelas.
Ex de descri��o : O software deve fornecer um meio de representar e acessar
arquivos externos criados por outras ferramentas. Essa seria uma descri��o sobre a
forma de usu�rio.
Requisitos de sistemas- S�o mais detalhados e mais voltados para a equipe t�cnica,
s�o descri��es mais detalhadas. Ex de descri��o: O usu�rio deve dispor de recursos
para definir os tipos de arquivos externos, cada tipo de arquivo externo pode ter
uma ferramenta associada aquele arquivo, cada tipo de arquivo externo pode ser
representado por um �cone diferente.
EVOLU��O: Requisitos de Usu�rio > Requisitos de sistemas > Especifica��o.
O requisito de usu�rio � o primeiro, o mais gen�rico, o mais abrangente. Vai dar
origem ao requisito de sistemas que � mais detalhado e esse vai dar origem a
especifica��o, que s�o os modelos que vamos construir na fase de an�lise,
especificando aquele projeto. Ent�o um deriva do outro. A diferen�a entre esses
tr�s � referente ao detalhe do que deve ser feito, cada vez mais detalhes ao longo
do tempo.
A outra CLASSIFICA��O que eu tenho quanto aos requisitos � POR FINALIDADE:
CLASSIFICA��O QUANTO A FINALIDADE - Pode ser funcional (REQUISITOS FUNCIONAIS), ou
pode ser n�o funcional (REQUISITOS N�O FUNCIONAIS).
REQUISITOS FUNCIONAIS - Funcional tem a ver com fun��o, � a fun��o que o sistema
vai fazer, � um servi�o que o sistema vai prestar. Foco na funcionalidade e
servi�os oferecidos pelo sistema.
Ex: o sistema deve controlar entrada e sa�da de funcion�rios, o sistema deve emitir
relat�rio di�rio com movimento financeiro.
REQUISITOS N�O FUNCIONAIS - S�o crit�rios que qualificam os n�o funcionais,por
exemplo, eu sei que vou ter que ter uma interface, ent�o vou caracterizar como �
que eu quero as caracter�sticas daquela interface, isso � um requisito n�o
funcional, porque n�o � uma fun��o do sistema, mas � uma caracter�stica que vai
fazer com que aquele sistema tenha alguns crit�rios relevantes.
Os requisitos n�o funcionais podem ser classificados em 3 grandes �reas: PRODUTO,
ORGANIZACIONAIS E EXTERNOS.
Ex de requisitos n�o funcionais: o sistema deve ser implementado em java, o sistema
deve emitir o relat�rio em 4 segundos.
Resumindo: Os requisitos podem ser de usu�rio ou de sistema, isso � o detalhamento
com o que a gente descreve aquele requisito e pode ser classificado como funcional
(descreve uma fun��o) ou n�o funcional (descreve caracter�sticas daquela fun��o e
do sistema como um todo).

VIDEO 3 - T�cnicas de elicita��o de requisitos

T�cnicas de Levantamento de Requisitos - J� sabemos que o requisito � a mat�ria

prima, o elemento fundamental na especifica��o de um sistema de informa��o, de um
software. Esse requisito precisa ser especificado, detalhado com muita clareza, com
precis�o e sem ambiguidade para que todos compreendam exatamente como ele �. Ou
seja, � preciso muita aten��o nesse processo de especifica��o dos requisitos.
A obten��o das necessidades para gerar os requisitos � feita conversando com as
pessoas, utilizando t�cnicas de levantamento de dados (usar mais de uma t�cnica -
em geral,necess�rio) e voc� precisa conhecer, saber como aplicar e combinar.
T�CNICAS:
*Entrevistas ou Reuni�es - Pode ser feito individualmente ou com poucas pessoas.
Deve utilizar sempre que precisar, no in�cio do projeto, no meio, no fim.Essa
t�cnica pode ser usada em qualquer situa��o e em conjunto com outras.
Vantagem: Tem flexibilidade, pode alterar a ordem das perguntas, pode incluir
perguntas que n�o estavam na programa��o, pode motivar o entrevistado por valorizar
sua opini�o.
Dificuldades: O tempo pode ser estourado, desvios no decorrer da entrevista,
consumir mais tempo e recursos.
*Question�rios - Deve ser empregado quando existir grande n�mero de pessoas com
opini�o relevante.E ou, se essas pessoas estiverem fisicamente longe de voc�.
Vantagem: Tinge um grande n�mero de pessoas, custos reduzidos, permite que os
participantes respondam quando acharem conveniente, quest�es padronizadas garantem
uniformidade.
Dificuldades - N�o h� garantia de que todos os participantes respondam o
question�rio, as perguntas podem ter significados diferentes a cada participante.
* Brainstorming (tempestade de id�ias)- Quando voc� tem um determinado tema para
debater, voc� coloca as pessoas relacionadas aqueles temas juntas e conduz uma
reuni�o planejada e a id�ia � voc� colocar temas para que as pessoas discutam as
id�ias. E assim uma completa a id�ia da outra e voc� vai unificando, solidificando
e formalizando requisitos com mais clareza. � uma t�cnica que voc� precisa ter
bastante conhecimento, porque voc� pode ser perder no caminho.
* Prototipagem - � usada quando n�o h� muita clareza sobre o que o usu�rio quer,
ent�o � necess�rio mostrar pra ele a tela do sistema; quando h� d�vida sobre como
vai ficar a interface.
Vantagem: Permite alcan�ar um feedback antecipado dos steakholders, detec��o dos
erros do sistema na fase inicial enseja menor custo, evita confus�es sem�nticas
entre a comunica��o entre o analista e o agente de interesse.
Dificuldades - Grande custo se comparado �s outras t�cnicas, grande demanda de
tempo.
*Observa��o - S�o t�cnicas aonde o analista de sistema, o profissional, vai at� o
ambiente de trabalho das pessoas para fazer algumas observa��es.
*Etnografia que � a primeira delas, a id�ia � voc� ver aspectos sociais da pessoa,
o envolvimento e a coopera��o dela no trabalho. A gente sabe que os processos hoje
as pessoas tem que interagir. A etnografia visa observar se aquela equipe � coesa.
Deve ser utilizada se a organiza��o possuir recursos, pode ser utilizada em
concurso com outras, emrpegada na descoberta de requisitos que complementem os
levantados por outras t�cnicas.
Vantagens - Identifica requisitos relacionados a coopera��o entre os agentes.
Identifica requisitos da utiliza��o cotidiana e pr�tica, oferece uma pr�xima das
necessidades dos agentes, capacidade de observar o comportamento do ambiente,
profundidade no conhecimento.
*Observa��o Direta - Vai observar uma pessoa trabalhando sobre o aspecto de
conhecimento, comportamento, sem visar a intera��o. Para ver se o trabalho dela
est� otimizado, se est� sendo bem feito.
USO UMA T�CNICA S�? N�o, vou ter que escolher as t�cnicas em conformidade com a
necessidade.
Tenho que estabelecer o PRAZO, T�CNICA, USU�RIOS ENVOLVIDOS.Tem toda uma
comunica��o pr�via de como ser� o trabalho para que consiga fazer o levantamento de
dados. IMPORTANTE: Tudo que for realizado nessas t�cnicas de levantamento, deve ser
muito bem documentado, preferencialmente, gravar, filmar (pedindo permiss�o), para
que consiga a todo momento rever aqueles momentos.
O principal finalidade disso tudo � voc� entender das pessoas o que elas precisam
que o sistema fa�a e a partir dai declarar os requisitos com clareza, sem
ambiguidade e com qualidade.
Lembrando que requisitos mudam e a gente tem que ter t�cnicas de conduzir esses
requisitos de forma organizada.
O levantamento � a base de tudo, uma vez que o requisito � a base de toda a
defini��o de como vai ser o sistema.