PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

AULA 2
Prof. MARCELO VASQUES
mvasqueso@gmail.com

AULA 1 – Prof. MARCELO VASQUES

 OBJETIVOS DA AULA

• Apresentar Estudo de Viabilidade

• Definir conceito e tipos de Requisitos
• Descrever atividades para análise de
requisitos
• Apresentar técnicas para elicitar e analisar
Requisitos

2
 REVISÃO
• Processo de desenvolvimento
• Conjunto de fases, cada qual com
uma finalidade, que descrevem
passo a passo, formalmente, o que
devem ser feito para desenvolver
um sistema.
• Cria um padrão, para todos
seguirem
• Confere qualidade ao software
3
ESTUDO DE VIABILIDADE
• Concepção
 Semente  Necessidade, idéia
 O que é o sistema? – definições
iniciais
 É viável?  Vale a pena?
• Estudo ou Análise de Viabilidade
 Benefício deve superar o Custo?
 Empresa
 Negócio a que se destina
4
ESTUDO DE VIABILIDADE
Entrada:
1. Conjunto preliminar de requisitos de negócio
2. Esboço da Descrição do Software
3. Como apóia a área de negócios

ANÁLISE
DE
VIABILIDADE

Saída:
1. Viável? (técnica, operacional e financeiramente)

5
ANÁLISE DE VIABILIDADE
• O SW contribui para os objetivos da
organização? Beneficia os interessados?
– Viabilidade Operacional
• O SW pode ser implementado com TI atual?
– Viabilidade Técnica
• Restrições de custo serão atendidas?
– Viabilidade econômica
• Restrições de prazo serão atendidas?
– Cronograma

6
VIABILIDADE ECONÔMICA
• Apurar o retorno sobre o investimento (ROI)
– % que mede a relação entre o quanto se
ganha (pretende ganhar) e quanto se investe.
• ROI=(Lucro Liquido)/Investimento
– Lucro Liquido = receitas – despesas (todas)
– Investimento = Tudo que será investido para o
sistema: Softwares, Hardware, Redes, obras
e etc.
– Quanto MAIOR O VALOR, melhor o ROI

7
 VIABILIDADE ECONÔMICA
Investimento = R$ 40.000,00
 Desenvolvimento: 20.000
 Softwares: 5.000
 Hardware + rede + Internet: 10.000
 Mobiliário: 5.000

Receitas (Vantagens) com sistema: R$ 15.000,00

Despesas com sistema = R$ 5.000,00
Lucro Líquido com sistema = R$ 10.000,00
ROI = 10.000,00 / 40.000,00 = ¼ = 0,25
Conclusão: O investimento se paga em 4 anos.
8
ENGENHARIA DE REQUISITOS
• Elicitação  Elicitar = descobrir, tornar
explícito.
– Expliciar o que? Resposta: Requisitos
• Requisitos (necessidade do usuário)
– Descrições dos serviços fornecidos pelo
sistema.
– Restrições e características desses
serviços
Refletem a necessidades dos seus
usuários
9
CLASSIFICAÇÃO:REQUISITOS
• Requisito de usuário (abstratos- nível alto)
– Descrição dos serviços esperados do sistema
e restrições sobre as quais ele deve operar
– “O sistema deve controlar o bloqueio de
exemplares pelo professor”

• Requisito de Sistema (detalhado)

– Definição estruturada e detalhada dos
serviços e restrições operacionais
– Detalhar as funções de Bloqueio de
exemplares
 REQUISITOS DE SISTEMAS

• Funcionais
– Declarações de serviços que o sistema
deve fornecer e como deve se comportar.
– Pode estabelecer o que o sistema NÃO
deve fazer
• Não Funcionais
– Restrições sobre os serviços ou funções
oferecidos pelo sistema
– Características ou qualidades
 EXEMPLOS DE REQUISITOS
• Funcionais
– RF: Sistema deve informar melhor aluno
– RF: Sistema deve permitir incluir e excluir
fornecedores
• Não Funcionais
– RNF: A impressão do boleto deve ser em no
máximo 10 segundos
– RNF: as dimensões dos relatórios devem ser
configuráveis
– Restrições de hardware, ambiente e etc
 EXEMPLOS DE REQUISITOS
• Exemplo: Sistema de Caixa Eletrônico
– Tipos de transações suportadas na Conta
• Funcional
– Tempo de resposta, facilidade de uso e
tempo médio entre as falhas
• NÃO Funcional

13
 ENTREVISTA
• Quando usar?
– Primeira técnica a ser usada com alto escalão
para entendimento da organização
(organograma).
• Fechadas (questionário) ou abertas (roteiro)
• Individual ou pequeno grupo
• V - Eficiente
• D - Cara (falta de tempo das pessoas).
• V- Permite observar postura corporal. “Olhar nos
olhos”.
• D - Cuidado: não se perder (roteiro)
14
 QUESTIONÁRIO
• Quando usar?
– Muitos usuários e há necessidade de uma análise
estatística.
– Falta de tempo dos envolvidos para entrevistas.
– Usuários estão geograficamente distantes (pesquisa de
satisfação na Estácio)
• Evitar: perguntas abertas.
– O que você do procedimento atual... ?
• Focar: perguntas direcionadas ao que se deseja
saber. Exp: Considera o procedimento atual
– ( ) Ruim ( ) Satisfatório ( ) Ótimo

15
 BRAINSTORM
• Reuniões onde participam todos os
envolvidos
• Objetivo: permitir que todos expressem
suas idéias de forma a obter o consenso.
• Todos expressão de forma desorganizada
mesmo
• Organizam-se as idéias
• Identifica-se conflitos entre áreas
• Visões diferentes do requisito nas
empresas.
16
 CASO DE USO (CUIDADO)
• É na verdade um modelo da UML, usado
para: definir o escopo do sistema, identificar
quem interage com o sistema (atores)
identificar os requisitos (casos de uso),
validar os requisitos com os usuários
• Não é em si uma técnica de levantamento
de dados, mas o resultado produzido após.
• E esse resultado, que é o modelo
(desenho) pode ser usado para validar os
requisitos com os usuários.
17
18
 OUTRAS TÉCNICAS

• Observação “in locco” – analista se insere

no dia a dia da empresa. Constatar o que
foi levantado e entender funcionamento na
prática.
• Análise de documentos
• JAD – excelente para projetos que
necessitam discussão de várias áreas da
empresa.

19