Disciplina Análise de Sistemas

• Prof. Robson Gomes

• E-mail: robson.gomes10@etec.sp.gov.br
 FÁBRICA DE SOFTWARE
• Utopia ou realidade?

Extraído de (http://voat.com.br/rdal/?p=46)
 EVOLUÇÃO DO “FAZER PROGRAMA”
• 1950 – Inexistência de reuso de algoritmo
lógica e código. [programação estruturada].
Como consequência difícil de se fazer
manutenção!
 EVOLUÇÃO DO “FAZER PROGRAMA”

• 1960 – Processo
de desenvolvimento em
cascata.
Definição de métodos e fases.
 EVOLUÇÃO DO “FAZER PROGRAMA”

• 1970 – Metodologia de desenvolvimento. Evita

conflitos de grupos, software e falta de
escalabilidade.
• Definição de Metodologia “forma de trabalho
organizada, que tem como objetivo disciplinar e
definir fases e itens importantes na concepção de
um software”.
 EVOLUÇÃO DO “FAZER PROGRAMA”
• As metodologias produziam muitos
documentos que atrasavam cronogramas.
 PROBLEMAS COM PROJETOS

2% Não iniciam no prazo original,

16% São bem sucedidos,
23% São cancelados,
28% São entregues no prazo e no orçamento,
94% Irão reiniciar pelo menos uma vez,
88% Excedem o orçamento original.

Somente 61% vão manter o escopo original.

 EVOLUÇÃO DO “FAZER PROGRAMA”
• Após a pubicação do livro “Structured Analysis
and System Specification” apresentou-se o
conceito de Engenharia de Software.
• Toda a engenharia era baseada em

modelos
 REQUISITOS FINALIDADE

Estabelecer e manter concordância com os clientes

e outros envolvidos sobre o que o sistema deve
fazer.
REQUISITOS? Pra quê?
 A PARTIR DE 2004 AS PESQUISAS MOSTRARAM

29% de todos os projetos foram bem sucedidos

•Entregues no prazo;
•Orçamento;
•Mantendo o escopo original.

53% ainda desafiam.

• Atraso;
•Orçamento excedente e/ou com escopo original não contemplado
por completo.

18% falharam.
•Cancelados antes da conclusão ou entregue e nunca utilizado.
 RUP

Rational Unified Process (ou Processo Unificado Racional), é

um processo proprietário de Engenharia de software criado
pela Rational Software Corporation posteriormente Comprado
pela IBM.
Iniciação – Elaborar termo de
abertura do projeto
VERIFICAÇÃO DA QUALIDADE DO SOFTWARE

Qualidade do Software?

Isso não é problema meu!

Normalmente pensa-se em qualidade de software após o

término dos projetos, ou a qualidade é responsabilidade de
uma equipe diferente da equipe de desenvolvimento.
 FASES DO PROJETO RUP
As fases (PROX. SLIDE) indicam a ênfase que é dada no projeto em um dado
instante.

Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em

quatro fases diferentes:

•Iniciação ou Concepção: ênfase no escopo do sistema;

•Elaboração: ênfase na arquitetura;
•Construção: ênfase no desenvolvimento;
•Transição: ênfase na implantação.
 Levantamentos de Requisitos
UM CASO REAL

A:O Sistema que queremos , deve fazer isto, isto ..., e

nesse caso também isto;
B:Sim, Sim estou anotando;
A:Conversei com os usuários e basicamente este é o
Sistema que teremos que desenvolver;
B:Sim chefe;
B:Ótimo, começaremos a especificar os requisitos
imediatamente;
Levantar pedidos das partes interessadas ("stakeholders") e transformá-los em um
conjunto de requisitos para o que deve fazer o sistema.
 ELICITAÇÃO DE REQUISITOS
MOTIVAÇÃO
• ... Quatro Meses Depois ...

• Srs. Usuários, após o emprego das mais

modernas técnicas de especificação,
produzimos este documento que descreve
minuciosamente o Sistema.
• Ótimo! Bom! Hum! ... é um documento com
300 páginas! E todos estes gráficos, tabelas...
Enfim, vamos analisá-lo e nos falaremos.
 ELICITAÇÃO DE REQUISITOS
MOTIVAÇÃO
• ... Depois de um mês e meio ...
• Sr. Analista, nosso pessoal “analisou” com
cuidado o documento, tivemos muita
dificuldade e dúvidas em entendê-lo. Mas o
que percebemos é que NÃO FOMOS
COMPLETAMENTE ENTENDIDOS.
 CORRETAMENTE ENTENDIDOS?
• Como não? Tudo que aí está, foi
fruto de Nosso entendimento!
 RESULTADO
“Eu sei que você acredita que
entendeu o que você pensa que eu
disse, mas eu não estou certo de que
você compreendeu que o que você
ouviu não é o que eu quis dizer“
[autor anônimo]
UML 2.0

Elaborando Modelos