Análise e Projeto de

Sistemas - Processo de
Desenvolvimento

Prof.Júlio Martins
Roteiro

● Introdução

● Atividades Típicas no processo de Desenvolvimento

de Software

● O componente humano (participantes do processo)

● UML no processo I&I, prototipagem e ferramentas

CASE

2
“Software é difícil…”

● Porcentagem de projeto que:

○ Terminam dentro do prazo estimado: 10%
○ São descontinuados: 25%
○ Acima do custo esperado: 60%

● Atraso médio nos projetos é de um ano!

3
“Software é difícil…”

● Porcentagem de software:
○ Pago mas não entregue: 29.7%
○ Que pode ser usado quando entregue: 2%
○ Entregue mas nunca usado: 47%
○ Usado mas posteriormente modificado ou
abandonado: 19%
○ Que podia ser usado após mudanças: 3%

GAO Survey (1992)

4
O que é Software?

● “Programas de computador e
documentação associada, tais como
requisitos, modelos de projetos e manuais
de usuário”

Lembrem-se, existem artefatos que não “rodam”!

5
Processo de Desenvolvimento

● Compreende as atividades necessárias

para definir, desenvolver, testar e manter
um produto (sistema) de software

● Tentativas de:
○ Lidar com a complexidade e minimizar os
problemas envolvidos no desenvolvimento de
software

6
Objetivos de um Processo de
Desenvolvimento de Software

● Definir quais as atividades a serem

executadas
● Quando, como e por quem tais atividades
serão executadas
● Prover pontos de controle para verificar
andamento do desenvolvimento

● Padronizar a forma de desenvolver

software em uma organização
7
Atividades

● Levantamento de requisitos
● Análise Foco da disciplina!
● Projeto
● Implementação
● Testes
● Implantação
● Manutenção

8
 Levantamento de Requisitos

● Levantadas e definidas as necessidades (requisitos)

dos futuros usuários

● “Um requisito é uma condição ou capacidade que

deve ser alcançada ou possuída por um sistema ou
componente deste para satisfazer um contrato,
especificação ou outros documentos impostos”

9
Levantamento de Requisitos

● Os requisitos:
○ São identificados a partir de um domínio.
Precisamos de especialistas
○ Registro é feito no documento de requisitos
○ São a base para a definição do escopo(o que faz e
o que não faz parte do sistema)

● Documento de requisitos:
○ Define de forma clara os requisitos
○ Descreve requisitos funcionais, requisitos não
funcionais e requisitos normativos
10
Levantamento de Requisitos

● Os requisitos:
○ São identificados a partir de um domínio.
Precisamos de especialistas
○ Registro é feito no documento de requisitos
○ São a base para a definição do escopo(o que faz e
o que não faz parte do sistema)

● Documento de requisitos:
○ Define de forma clara os requisitos
○ Descreve requisitos funcionais, requisitos não
funcionais e requisitos normativos
11
Levantamento de Requisitos

● Requisitos Funcionais:
○ Definem as funcionalidades do sistema

● Exemplo:
○ “O sistema deve permitir que cada professor
realize o lançamento de notas”
○ “O sistema deve permitir que os alunos visualizem
suas disciplinas”

12
Levantamento de Requisitos

● Requisitos não funcionais:

○ Declaram as características de qualidade que o
sistema deve possuir

● Exemplo:
○ Confiabilidade, desempenho, portabilidade,
segurança e usabilidade
○ Me falem exemplos práticos com o SIPPA

13
Levantamento de Requisitos

● Requisitos normativos
○ Declaram restrições impostas ao
desenvolvimento do sistema. Essas restrições
definem:
○ Adequação a custos e prazos, plataforma
tecnológica, componentes de hardware e
software; etc…
○ Podem correspondem as regras de negócio

● Regra de Negócio:
○ São restrições ou políticas de funcionamento
específicas do domínio do problema 14
Levantamento de Requisitos

● Uma das formas de medir qualidade de

software é pela utilidade
○ Em geral, um sistema é útil para seus usuários se
atender aos requisitos

● Requisitos:
○ Devem ser entendidos para então serem
verificados e comunicados a leitores técnicos e
não técnicos

15
Levantamento de Requisitos

● Requisitos:
○ Pergunta: “O que o usuário necessita do novo
sistema?”
○ Avaliação: Grau de conformidade com os
requisitos

● Documento de Requisitos:
○ Consenso entre Cliente e Equipe
○ Gerenciar escopo e suas mudanças!

16
Levantamento de Requisitos

● Como assim mudanças?

○ Requisito Volátil: Aquele que sofre modificações
durante o desenvolvimento

● Mas o Documento de Requisitos muda?

○ Mas ele não deveria definir de forma clara os
requisitos do sistema? Por que muda?
○ Mudança de requisitos (Aceita que é melhor)
○ Requisitos Congelados x Requisitos Voláteis

17
Levantamento de Requisitos

● Quais requisitos são mais importantes?

○ Grau de prioridade definido pelo cliente
○ Qual requisito fornece mais valor?
○ Gerente toma decisão baseado nisso

18
Levantamento de Requisitos

● Quais requisitos são mais importantes?

○ Grau de prioridade definido pelo cliente
○ Qual requisito fornece mais valor?
○ Gerente toma decisão baseado nisso

19
Análise

● Nessa atividade são construídos os

modelos a partir do estudo dos analistas
sobre os requisitos levantados

● A atividade de análise:
○ Não leva em consideração soluções tecnológicas
para o sistema
○ O que o sistema deve fazer ao invés do como

20
Análise

● Modelos construídos no desenvolvimento

devem ser validados e verificados

● Validação (análise):
○ Objetivo: assegurar que as necessidades do cliente
então sendo atendidas
○ Pergunta: Será que estamos construindo o
software correto?

21
Análise

● Verificação
○ Objetivo: analisar se os modelos construídos estão
em conformidade com os requisitos definidos
○ Pergunta: Será que estamos construindo
corretamente o software?

22
Projeto

● Consiste em duas atividades principais:

○ Projeto de Arquitetura (projeto de alto nível)
○ Projeto detalhado (projeto de baixo nível)

23
Projeto

● Projeto de arquitetura
○ Foca no agrupamento de classes relacionadas do
sistema em subsistemas e componentes
○ Faz a distribuição dos subsistemas e componentes
sobre elementos de hardware disponível

24
Projeto

● Projeto detalhado
○ São modeladas as relações entre as classes de
cada módulo com o objetivo de realizar as
funcionalidades deste módulo

● São realizados:
○ Projeto de Interface do usuário
○ Projeto de Banco de Dados
○ Avaliação da concorrência e distribuição do
sistema
○ Projeto de Algoritmos a serem utilizados no
sistema 25
Análise e Projeto na prática

● Apesar de estarem descritas

separadamente, na prática não existe uma
distinção tão clara dessas duas atividades.
Elas se misturam, principalmente no
desenvolvimento de sistemas OO

26
Implementação

● Implementação
○ Fase responsável pela codificação do sistema
○ Em projetos OO usa-se a linguagens OO (Ex: Java)

27
Testes

● Testes
○ Fase responsável por verificar e validar o sistema
○ O principal produto é o relatório de testes que traz
informações sobre os erros existentes

28
Testes

● Conceito
○ Testar partes pequenas e testar partes grandes
depois

● Testes de Unidade
○ Abrange classes e métodos
○ Programador mesmo faz
○ Verifica retornos de métodos
○ Ajuda a diminuir custos

29
Testes

● Teste de Integração
○ Testa operações do sistema
○ Verifica falhas na interação de objetos

● Testes de Sistema
○ Verifica conformidade do sistema construído e dos
requisitos
○ Testados em ambiente mais próximo do de
produção

30
Testes

● Teste de Aceitação
○ Usuário faz
○ Verifica a conformidade do sistema com os
requisitos

31
Implantação

● Implantação
○ Fase responsável pelo empacotamento,
distribuição e instalação no ambiente de usuário
○ Escrita de manuais do sistema
○ Treinamento de usuários

32
Manutenção

● Manutenção
○ Fase responsável por acompanhar a evolução do
sistema até a descontinuação

33
 O COMPONENTE HUMANO
(PARTICIPANTES DO PROCESSO)

34
Os participantes do Processo

● Gerentes de Projeto
● Analistas
● Projetistas
● Arquitetos de Software
● Programadores
● Especialistas do domínio
● Avaliadores de qualidade

35
Gerentes de Projeto

● São os profissionais responsáveis por:

○ Gerenciar e coordenar o projeto
○ Fazer orçamento do projeto
○ Estimar o tempo de desenvolvimento
○ Definir o processo de desenvolvimento
○ Cronograma de atividades
○ Alocação de Pessoal
○ Solicitar recursos de hardware e software

36
Analistas

● São os profissionais responsáveis por:

○ Conhecer o domínio do problema
○ Entender os problemas do domínio do negócio
para definir requisitos
○ Comunicar-se com especialistas de domínio para
obter conhecimento
○ Entender as necessidades dos clientes e repassar
para a equipe (“a ponte”)

37
Projetistas

● São os profissionais responsáveis por:

○ Avaliar as alternativas de solução do problema
resultante da análise
○ Gerar a especificação de uma solução
computacional detalhada

● Existem diversos tipos de projetistas:

○ Interface
○ Redes
○ Banco de Dados entre outros

38
Arquitetos de Software

● São os profissionais responsáveis por:

○ Elaborar a arquitetura do sistema com um todo

● São encontrados em equipes que

desenvolvem sistemas muito complexos

39
Programadores

● São os profissionais responsáveis por:

○ Codificar o sistema

● Analistas focados em entender questões

ligadas a tecnologia da informação e
processo de negócio
○ Programadores focados em aspectos tecnológicos
○ Mas na prática?

40
Especialistas do Domínio

● São os profissionais responsáveis por:

○ Que possuem conhecimento a cerca da área ou do
negócio em que o sistema em desenvolvimento
está inserido

● Clientes
○ Clientes usuários (especialistas do domínio)
○ Clientes contratantes

41
Avaliadores de Qualidade

● São os profissionais responsáveis por:

○ Assegurar a adequação do processo de
desenvolvimento e do produto de software aos
padrões de qualidade

● Utilizam métricas de software

○ Existem várias
○ Métricas verificam determinado aspecto de
qualidade
○ Ex: Verificar coesão de uma classe

42
MODELOS DE CICLO DE VIDA

43
Modelo de Ciclo de Vida

● Um ciclo de vida corresponde a um

encadeamento específico das fases para
construção de um sistema

● Dois modelos de ciclo de vida

○ Modelo em Cascata
○ Modelo iterativo e incremental

44
Modelo Cascata

● Projetos raramente seguem o fluxo

sequencial

● Assume que é possível declarar

detalhadamente todos os requisitos antes
do início das demais fases do
desenvolvimento

45
Modelo Cascata

● Tendência na progressão sequencial entre

uma fase e a seguinte

46
Modelo Iterativo e Incremental

● Divide desenvolvimento de um produto de

software em ciclos

● Em cada ciclo de desenvolvimento, podem

ser identificadas fases de análise, projeto,
implementação e testes

47
Modelo Iterativo e Incremental

● Cada ciclo considera um subconjunto de

requisitos
○ Requisitos com mais riscos
○ Requisitos com maior prioridade para o nosso
cliente

● Esta característica contrasta com a

abordagem clássica, na qual as fases são
realizadas uma única vez

48
Modelo Iterativo e Incremental

● Iterativo
○ O sistema de software é desenvolvido em vários
passos similares

● Incremental
○ Em cada passo, o sistema é estendido com mais
funcionalidades

49
Modelo Iterativo e Incremental

● Desenvolvimento em “mini-cascatas”

50
Modelo I&I - Vantagens e Desvantagens

● Incentiva a participação do usuário

● Riscos são mais gerenciados
○ Risco é a possibilidade de ocorrência de algum
evento que cause prejuízo ao desenvolvimento
○ Influências: custos de projeto, cronograma,
qualidade do produto e satisfação do cliente

● Mais difícil pro Gerente de Projeto

gerenciar

51
Organização de um Processo I&I
● O ciclo de vida de um processo iterativo e
incremental pode ser estudado sob duas
dimensões
○ Dimensão Temporal
○ Dimensão de Atividades

52
Organização de um Processo I&I
● Temporal
○ O processo é estruturado em fases
○ Em casa uma das fases, há uma ou mais iterações
○ Cada iteração tem uma duração preestabelecida
(duas a seis semanas)
○ Ao final de cada iteração, é produzido um
incremento (uma parte do sistema final)
■ Incremento pode ser liberado pro cliente ou
não

53
Organização de um Processo I&I
● Dimensão de atividades
○ Compreende às atividades realizadas em cada fase
■ Levantamento de requisitos, análise, projeto
○ Cada fase gera um conjunto de artefatos
○ Cada fase é concluída com um marco
■ Um marco é um ponto do desenvolvimento no
qual decisões sobre o projeto são tomadas e
objetivos alcançados

54
Organização de um Processo I&I
● Fases do Processo Unificado
○ Concepção
○ Elaboração
○ Contrução
○ Transição

55
Organização de um Processo I&I
● Concepção
○ A ideia geral e o escopo do desenvolvimento são
definidos
○ Um planejamento de alto nível do
desenvolvimento é realizado

56
Organização de um Processo I&I
● Elaboração
○ Entendimento inicial do sistema dever ser
alcançado
○ Planejamento do projeto é completado
○ Domínio do negócio é analisado
○ Requisitos são ordenados por prioridade e risco

57
Organização de um Processo I&I
● Construção
○ Atividade de análise de projeto aumentam
○ Ocorre o maior número de incrementos
○ O produto é efetivamente construído
○ A construção do manual do usuário é iniciado

58
Organização de um Processo I&I
●

59
UML em um processo I&I
● UML é independente do processo de
desenvolvimento
○ Vários processos podem usar UML

● Os artefatos de software construídos

através da UML evoluem
○ A cada iteração são adicionados novos artefatos
○ Pessoal, documentação é pra ser atualizada e não
para servir como enfeite

60
Prototipagem
● UM protótipo é um esboço de alguma parte
do sistema
● É uma técnica complementar à análise de
requisitos
○ Tenta assegurar que os requisitos foram bem
entendidos

● A construção de protótipos utiliza

ambientes com facilidades para construção
da interface gráfica
61
Prototipagem
● Quando é aplicada?
○ Quando existe dificuldade no entendimento dos
requisitos
○ Quando após o levantamento de requisitos um
protótipo pode ser usado na validação

62
Prototipagem
● Com o protótipo feito
○ Usuários fazem críticas
○ Protótipos são corrigidos e refinados
○ Após aceitação o protótipo é descartado ou
utilizado como uma versão inicial do sistema

63
Prototipagem
● Prototipagem NÃO é um substituto à
construção do modelos do sistema
○ É uma técnica complementar
○ Ajuda a atualizar os modelos do sistema

64
Ferramentas de Suporte
● Existem várias ferramentas que ajudam
○ Construir modelos
○ Gerenciamento do andamento do
desenvolvimento

● Essas ferramentas são conhecidas como

ferramentas CASE (Computer Aided
Software Engineering)
○ Ferramentas que auxiliam o desenvolvimento de
software

65
Algumas ferramentas de suporte

66
Referências

● Princípios de Análise e Projeto de Sistemas com UML

2015

● Slides do professor Marcos de Oliveira

67
Questions?

E-mail:
juliomserafim@gmail.com

68