ENGENHARIA DE

SOFTWARE
4/14/16

Eng. Edvaldo Mahesh

edvaldodagloria@gmail.c
om
HAIDER NOOR

NOTAS
Exame escrito

4/14/16

HAIDER NOOR

PLANO CURRICULAR
CAP I Introduo a engenharia de software
CAP II Gesto de projectos
CAP III Processos de Software
CAP IV Metodologias geis de desenvolvimento
CAP V Engenharia de Requisitos
CAP VI Projecto ou desenho de software
CAP VII Implementao ou Desenvolvimento
CAP VIII Verificao e validao
CAP IX entrega e manuteno
4/14/16

HAIDER NOOR

AVALIAES
Semana 4, aula 7 PR1 - 150pts gesto de projectos
Apresentao

2 documentos
Ficha de projecto (

Capa 1 pg
Misso e mbito
Restries
Pressupostos
Objectivos
riscos conhecidos
Custos associados
Marcos do Projecto

Marco
4/14/16

Plano do projecto

No mbito do
nosso
trabalho, o
1 pg qu que ns
no vamos
fazer e
porqu?
dependncia

Data de incio

Data de fim
HAIDER NOOR

AVALIAES
7 semana, aula 16 MT 70pts - Gesto de projectos, processos de
software e metodologias geis.
9 semana, aula 23 T1- 100pts tudo do Mt + eng. de Requisitos.
10 semana, aula 25 PR2 100pts Eng d Requisitos.
12 semana, aula 32 PR3 100pts projecto ou desenho de
sofware
15 semana, aula 42 T2 100pts projecto ou desenho de
software, verificao e validao, entrega e manuteno.
16 semana, aula 44 PR4 150pts implementao, verificao e
validao. Entrega.
4/14/16

HAIDER NOOR

CAP I: INTRODUO
A ENGENHARIA DE
SOFTWARE
4/14/16

HAIDER NOOR

INTRODUO A
ENGENHARIA DE SOFTWARE
Software: so programas/instrues que realizam tarefas
especficas. Conjunto de instrues codificadas numa linguagem de
programao.
Definio do stor -> Um conjunto de programas e a sua documentao
associada.

Desenvolvimento de software: todo o processo de elaborar e

implementar um produto de software.
Engenharia de software: a rea da engenharia que se relaciona
com todos os aspectos de produo de um software.

4/14/16

HAIDER NOOR

MITOS DOS SOFTWARES

Mito 1 o facto de uma equipa ter a sua disposio manuais repletos de padres e
procedimentos de desenvolvimento implica que a equipa est apta a bem
encaminhar o desenvolvimento.
Mito 2 o facto de possuir o melhor computador a melhor ferramenta de
desenvolvimento de software.
Mito 3 Mais pessoas melhora o tempo de desenvolvimento.
Mito 4 uma discrio geral daquilo que o problema suficiente para iniciar o
projecto. (projecto uma fase do desenvolvimento/concepo)
Mito 5 o facto do desenvolvimento de software ser flexvel implica que podemos
aumentar requisitos a qualquer momento.
Mito 6 aps a produo e implementao do software o trabalho est terminado.
Mito 7 no final do projecto, o produto a entregar o programa em funcionamento.
Mito 8 o processo de planeamento fara com que criemos documentao
volumosa que atrasara a execuo do projecto e assim atrasara o cronograma,
4/14/16

HAIDER NOOR

CAP II GESTO DE
PROJECTOS DE
SOFTWARE

4/14/16

HAIDER NOOR

GESTO DE PROJECTOS DE
SOFTWARE
Gesto Objectivo: minimizar os custos e tempo de
desenvolvimento.
Para se estabelecer quanto tempo o nosso projecto vai levar, h
que ter em conta 2 factores:
O produto
Os recursos (pessoal)

4/14/16

HAIDER NOOR

10

PRODUTO (EXEMPLO)
Um software o produto final.
As fases de desenvolvimento do software:

4/14/16

HAIDER NOOR

11

RECURSOS (EXEMPLO)
Os recursos mais difceis de manegar so as pessoas.
Um projecto tem, geralmente:
Gestor de projecto
Desenvolvedor
Analista de projecto

Cada papel deve ser desempenhado pela pessoa certa. Aspectos

como liderana, coordenao, relao com outros, etc.

4/14/16

HAIDER NOOR

12

FORMAO DE EQUIPAS
O tamanho da equipa tem muita influena sobre a eficcia da
equipa. Equipas grandes requerem maior esforo de gesto.
melhor formar muitas equipas pequenas do que poucas equipas
grandes.
Tipos(como gerida) de equipa mais utilizados:
Democrtica descentralizada
Controlada descentralizada
Controlada centralizada

4/14/16

HAIDER NOOR

13

Democrtica descentralizada

O projecto divido em M tarefas que entregue a N indivduos e as

suas equipas. E a gesto feita pelo gestor de projecto.
Controlada descentralizada (a melhor forma de formar equipas)

Leva-se um projeto como um todo e divide-se em subprocessos que

so atribudos a sub-gestores que tem autonomia sobre a gesto
dos mesmos. (Delegao)
Controlada centralizada

O gestor de projecto responsvel por gerir todas as equipas e as

suas interaes.

4/14/16

HAIDER NOOR

14

ESTIMATIVAS
Trazem valores aproximados a aquilo que a realidade do projecto.
Tcnicas para estabelecer estimativas:
1. Postergar as estimativas para o mais tarde no projecto;
Inconveniente -> a maior parte dos clientes precisa ter uma previso de gastos e tempos no principio
do projecto

2. Estimativas baseadas em mtodos no algortmicos;

a) estimativas usando projectos similares; (inconveniente inexistncia de projectos similares)
b) estimativas na base de opinio de um perito (especialista); (inconveniente inexistncia de um
especialista)
c) estimativa na base de melhor preo.
Assume-se que o contracto vai ser sempre respeitado pelo cliente
(inconveniente no h garantia de qualidade de software, preo pode ser sobre ou sub
estimado )

3. Estimativa baseadas em mtodos algortmicos (empricos)

4/14/16

HAIDER NOOR

15

O QU QUE NS
ESTIMAMOS?
1. Tempo
2. Custo
3. Tamanho
4. Esforo
.Primeiramente, necessrio estimar-se o tamanho o projecto em LOC
(Lines of Code). O inconvenientes:
que complicado contar linhas de cdigo no inicio do projecto
complicado estimar linhas de cdigo quando se usam vrias linguagens de
programao.

.Para resolver estes problemas, contam-se pontos de funo e depois,

com ajuda de uma tabela, converte-se em LOC.
4/14/16

HAIDER NOOR

16

TABELA DE CONVERSO PF LOC

Linguagem

LOC/PF

162

C++

66

Java

63

SQL

40

4/14/16

HAIDER NOOR

17

ESFORO
Esforo o tempo que um determinado recurso disponibiliza para
um determinado trabalho. Para tal devemos de tomar em
considerao:
Experincia dos trabalhadores;

TEMPO
Tempo total de desenvolvimento do projecto. Dependente do
tamanho e do esforo. Usando opinies de especialistas ou tempos
de projectos similares.
4/14/16

HAIDER NOOR

18

CUSTO
Custos a considerar so:
Custo de aquisio de equipamento;
Custo de aquisio de software de suporte;
Custos de esforo humano. (equipa de desenvolvimento)
Custos gerais (energia, internet, transporte, etc.. )

4/14/16

HAIDER NOOR

19

GESTO DE RISCO
Risco um evento que, caso ocorra, influenciar negativamente
no desenvolvimento do projecto.
Tipos de risco:
Risco de projecto;
Modificao do cronograma;

Risco de negcio;
Concorrncia;
Cliente muda de ideias;

Risco de produto;
O produto no corresponde as necessidades do cliente;
Compra de componentes defeituosos; falhas de desenvolvimento;

4/14/16

HAIDER NOOR

20

TAREFAS DE GESTO DE
RISCOS
So as diferentes actividade que tem que ser executadas para
Probabilidade de
evitar que o risco ocorra.
Divide-se em:

ocorrncia

Avaliao do risco;
O que causou? Qual a probabilidade de ocorrncia? Qual o seu impacto no projecto?
necessrio de estabelecer nveis de referencia de custos, tempo e produtividade.

Impacto

Administrao de riscos;
Efectuar aces que ajudem a mitigar o risco: reduo do impacto e reduo de probabilidade de
ocorrncia.
Nem todos riscos do projecto devem ser geridos. Devem ser gerir os riscos de mdia a alta
probabilidade de ocorrncia e impacto no projecto.

4/14/16

HAIDER NOOR

21

CRONOGRAMA
Diagrama de Gantt
Limitao da o tempo de trmino mais cedo possvel.

Diagrama de Pert
Fornece o tempo mais cedo e mais tarde possvel.

Tarefa critica aquela que no pode atrasar. Se esta atrasar o

projecto inteiro atrasa.

4/14/16

HAIDER NOOR

22

DIAGR
AMA
DE
GANT
T

4/14/16

HAIDER NOOR

23

Refern
cia

tarefa

Por farinha no recipiente

Por dois ovos

30

Por leite e misturar

60

Escolher aromas

Cortar bananas em laminas

finas

30

Misturar as bananas com

aromas

D,E

Aquecer e misturar

120

Por a mistura num ferro

quente

10

4/14/16

dependncia

durao
3

HAIDER NOOR

24

Desenhar a rede de tarefar e determinar o tempo de fim mais

tardar e mais cedo.
Indicar o caminho critico.

4/14/16

HAIDER NOOR

25

Tarefa

Condio de incio

Durao

Incio do projecto

A,B terminados

B,C,D terminados

C terminado

4/14/16

HAIDER NOOR

26

ATRIBUTOS
DIRECCIONADORES DE
CUSTO DO COCOMO
categori
a
produto

Computa
dor

Atributo

RELY: Required software reliability (confiabilidade requerida do

software)
DATA: Data base size (Tamanho da base de dados)
CPLX: product complexity (complexidade do software)
TIME: execution time constraint (restries de tempo de execuo)
STOR: main storage contraente (restrio da memoria central)
VIRs: Virtual machine volatility (volatilidade da mquina virtual)
TURN: tempo de rotatividade do computador

Pessoal

ACAP: capacidade do analistas

AEXP: experincia com a aplicao
PCAP: capacidade dos programadores
VEXP: experincia com a mquina virtual
LEXP: experincia com a linguagem de programao

projecto

MODP: prtica da programao moderna

TOOL: uso de ferramentas de software
SCED: prazo requerido para o desenvolvimento

4/14/16

HAIDER NOOR

27

EXERCCIO
Foi solicitado o desenvolvimento de um sistema de banco de dados para m
projecto de automacao de escritrio. Segundo o documento de requisitos o
sistema dever ser composto por 4 mdulos cujo tamanho foi estimado em:
Mdulo de entrada de dados: 0.6kloc
Mdulo de utilizao de dados: 0.6kloc
Mdulo de consulta : 0.8kloc
Mdulos de relatrios: 1kloc

O gerente avaliou os 15 direcionadores do custo e chegou ao seguinte resultado

Complexidade alta: 1.15
Armazenamento alto: 1.06
Experiencia baixa: 1.13
Capacidade de programadores baixa: 1.17
Calcular o esforo, produtividade, nr de pessoas e tempo
4/14/16

HAIDER NOOR

28

PROCESSO DE
DESENVOLVIMENTO
DE SOFTWARE

4/14/16

HAIDER NOOR

29

4/14/16

HAIDER NOOR

30

1. ESPECIFICAO
Levantamento dos problemas, requisitos, especificidades, etc.
Divide-se em Eng de Sistema a anlise da parte fsica do sistema
e Eng de Requisitos a anlise da parte lgica do sistema.
Especificacao do sistema faz-se o levantamento do soluo global
para a resoluo do problema.

4/14/16

HAIDER NOOR

31

2. DESENHO
a representao grfica do funcionamento do sistema.
1 desenho da arquitectura
2 desenho de interfaces
3 projecto detalhado

4/14/16

HAIDER NOOR

32

MODELOS DE CICLO
DE VIDA DE
DESENVOLVIMENTO
4/14/16

HAIDER NOOR

33

MODELO DE QUEDA DE
GUA (CASCATA)

desenvolvime
nto

aquele que no se passa

para a fase seguinte sem que
a anterior seja concluda, de
todos os mdulos.
Vantagem:
um modelo vantajoso em
projectos pequenos

Desvantagens:
Difcil manuteno. Considera a
manuteno como uma fase.
No facilita a produo de softwares
de grandes dimenses onde os
requisitos variam.
No permite prototipagem.
4/14/16

Validao

HAIDER NOOR

34

MODELO DE PROTOTIPAO
O avano para a fase seguinte feito similarmente ao modelo em
cascata.
Vantagem:
Resolve o inconveniente do modelo de desenvolvimento em cascata, em relao
a comunicao com o cliente.
Tens como mostrar um exemplar ao cliente. (um demo, etc)

4/14/16

HAIDER NOOR

35

MODELO ITERATIVO
INCREMENTAL
Consiste em repetir o processo de desenvolvimento vrias vezes. (diviso do sistema
em mdulos). Foi desenvolvido para responder ansiedade do cliente
Inconvenientes:
O cliente pode se entusiasmar por uma verso experimental, pensando que este responde as suas
necessidades.

4/14/16

HAIDER NOOR

36

4/14/16

HAIDER NOOR

37

MODELO EM ESPIRAL
Desenvolvimento infinito. o
que mais se assemelha as
formas de desenvolvimento
actuais.

prototipao

Verificao

Eng
de R
equ
is it o
s
De s
enh
o Implementao

fi
di
Co

ca

Desvantagem:

planeamento

tes
Tes

Inclui gesto de riscos e todas as

vantagens de todos outros modelos.
Cada quadrante especfico uma
fase de desenvolvimento. Cada ciclo
passa por todas as fases de
desenvolvimento.
Facilita desenvolvimento de sistemas
em grande escala.

Gesto
de
Riscos

Gesto de risco necessita de muita experiencia.

4/14/16

HAIDER NOOR

38

METODOLOGIA DE
DESENVOLVIMENTO
Orientada a objecto
A base UML.
a mais utilizada, principalmente em sistemas formais.
a que vamos utilizar.
Facilita a manuteno, devido a produo de um grande volume de
documentao.
No existe DFD. ( especificado em vrios outros diagramas)

Estruturada
O sistema visto em forma de 3 componentes: base de dados, anlise
estruturada e a programao.

4/14/16

HAIDER NOOR

39

PR: ENG. REQUISITOS

Descrio de cada funcionalidade (diferentes processos)
Ex: reservar passagem.

Caso de uso
Limite de Pag: 5
Parte terica: Casos de uso

4/14/16

HAIDER NOOR

40

METODOLOGIA GEIS DE
DESENVOLVIMENTO
So as mais perfeitas, se enquadram para qualquer tipo de
projecto.
A documentao no um parmetro para medir o processo de
desenvolvimento.
Baseia-se sobre os princpios:
Interao entre os membros
Aceitar facilmente mudanas do que aceitar um plano.
Software em desenvolvimento do que acima da documentao.
Colaborao com o cliente acima de contrato.

4/14/16

HAIDER NOOR

41

METODOLOGIAS GEIS DE
DESENVOLVIMENTO
Inconvenientes:
so pobres em documentao.
No h como gerir projectos com equipas de desenvolvimento muito grandes.
(baseados em comunicao, quanto maior a equipa mais difcil a comunicao)

4/14/16

HAIDER NOOR

42

XP (EXTREME
PROGRAMING)
A codificao a base em relao as outras fases.
desenvolvida pelos diferentes princpios das metodologia
respeitado valores e por meio de pratica.
Valores
Comunicao-deve ser respondido por qualquer metodologia geis.
Simplicidade No que esta sendo feito ( deve se abortar a soluo mais
simples).
Feedback pode ser dado para os programadores ou o cliente que ajuda eles a
terem maior ideia sobre o sistema.
Coragem no existe propriedade individual do cdigo.

4/14/16

HAIDER NOOR

43

PRATICAS DO XP
Programao em pares.
Propriedade colectiva do cdigo.
Integraes continuas.
Semana de trabalho de 40 horas.
Cliente no local.
Padroes de condificacao

4/14/16

HAIDER NOOR

44

CICLO DE VIDA
Explorao tenta se propor uma especificao para o problema, e
se prope uma arquitetura para o sistema
Planeamento inicial Estorias- possveis primeiras releses

Codificacao
Desenvolve se planos de testes , realizao de testes, integraes

Producao
Manutencao
Morte
4/14/16

HAIDER NOOR

45

PAPEIS
Treinador - questes tcnicas do projecto
Rastreador colecta mtricas que possa permite a avaliao se o
projecto esta a decorrer como deveria.
Programador que projecta, desenha, codifica e testa.
Cliente que agrega valor ao negocio.
Testador pode ser um programador ou da parte do cliente.
Consultor Pessoas que tem conhecimento sobre uma determinada
rea.

4/14/16

HAIDER NOOR

46

LIMITAES
So maioritariamente desconhecidas:
Equipas grandes -> baixo desempenho; Equipas tem um mximo de 12
membros;
Pouca documentao;
Ausncia do cliente;
Pouco feedback?

4/14/16

HAIDER NOOR

47

SCRUM METODOLOGIA
GIL

Iterativa incremental cujo foco a gesto do projecto. Baseado em reunies.

O desenvolvimento comea com os clientes e usurios que definem aquilo que so as
suas necessidades que na linguagem tcnica do SCRUM chama-se backlog. O backlog
uma lista onde os clientes e usurios colocam aquilo que so os seus requisitos.
aconselhado que seja utilizado uma outra metodologia em conjunto com o Scrum.
A cada 30 dias a equipa deve entregar uma nova verso implementando novas
funcionalidades.

4/14/16

HAIDER NOOR

48

4/14/16

HAIDER NOOR

49

SCRUM - CARACTERISTICAS
Caractersticas
Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente
interessados na sada);
Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas;
Planos frequentes de mitigao de riscos desenvolvidos pela equipe;
Discusses dirias de status com a equipe;
A discusso diria na qual cada membro da equipe responde s seguintes perguntas:
O que fiz desde ontem?
O que estou planejando fazer at amanh?
Existe algo me impedindo de atingir minha meta?

Transparncia no planeamento e desenvolvimento;

Reunies frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso;
Problemas no so ignorados e ningum penalizado por reconhecer ou descrever qualquer problema
no visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" no
necessariamente significa "produzir mais".

4/14/16

HAIDER NOOR

50

SCRUM PAPEIS PRINCIPAIS

Product Owner (dono do produto)
O Product Owner representa a voz do cliente e responsvel por garantir que a equipe
agregue valor ao negcio. O Product Owner escreve centrado nos itens do cliente (histrias
tipicamente do usurio), os prioriza e os adiciona para o product backlog. Equipes de Scrum
devem ter um Product Owner, e, embora esse possa tambm ser um membro da equipe de
desenvolvimento, recomenda-se que este papel no seja combinado com o de Scrum Master.
Scrum Master
Scrum facilitado por um Scrum Master, que responsvel pela remoo de
impedimentos capacidade da equipe para entregar o objetivo do sprint / entregas. O Scrum
Master no o lder da equipe, mas age como um tampo entre a equipe e qualquer
influncia ou distrao. O Scrum Master garante que o processo Scrum seja usado como
pretendido. O Scrum Master o responsvel pela aplicao das regras. Uma parte
fundamental do papel do Scrum Master proteger a equipe e mant-la focada nas tarefas
em mos. O papel tambm tem sido referido como um lder-servo para reforar essa dupla
perspectiva.
Equipe (Development Team)
A equipe responsvel pela entrega do produto. A equipe tipicamente composta de 6-9
pessoas com habilidades multifuncionais que fazem o trabalho real (analisar, projetar,
desenvolver, testar tcnicas de comunicao, documentos, etc.) Recomenda-se que a equipe
4/14/16
HAIDER NOOR
seja auto-organizada e autoconduzida, mas que muitas vezes trabalhem com alguma

51

SCRUM PAPEIS AUXILIARES

Os papis auxiliares em equipes Scrum so aqueles com nenhum papel
formal e envolvimento frequente no processo de Scrum, mas, ainda
assim, devem ser levados em conta.
Partes interessadas (clientes, fornecedores)
Estas so as pessoas que permitem o projeto e para quem o projeto vai
produzir o acordado benefcio, que justifica a sua produo. Eles s esto
diretamente envolvidos no processo durante as revises sprint.
Gerentes (incluindo gerentes de projeto)
Pessoas que iro configurar o ambiente para desenvolvimento de
produtos.

4/14/16

HAIDER NOOR

52

CERIMONIAS DO SCRUM
1. Planeamento do Sprint. (max.: 8hrs)

Todos os papeis devem estar presente.

Parte 1 (Primeiras quatro horas): Team Product Owner: dilogo para priorizar o Product Backlog.
Parte 2 (Prximas quatro horas): Team apenas: hash de um plano para a Sprint, resultando no
Sprint Backlog.

2. Reunio diria(max.: 15min)

Equipa e Scrum Master

Report de ponto de situao e impedimentos.

3. Reviso do Sprint (max.: 4hrs)

Todos participam e convidados

4. Retrospectiva (max.: 3hrs)

Faa melhorias contnuas de processos. Duas questes principais so feitas na retrospectiva

do sprint: O que correu bem durante a corrida? O que poderia ser melhorado na prxima
sprint?
SM + Equipa

4/14/16

HAIDER NOOR

53

ARTEFACTOS PRODUZIDOS
PELA METODOLOGIAS
SCRUM
Artefacto - Aquilo que fornecido no final do sprint.
Product backlog lista de funcionalidade do produto.
Sprint backlog lista de funcionalidade prioritrias.
Estrias do usurio descries pelo usurio/product Owner a
explicar certos itens para facilitar a percepo dos
desenvolvedores.
O prprio produto as vrias iteraes e a sua verso final

4/14/16

HAIDER NOOR

54

SPRINT BACKLOG
Para montar um bom backlog deve-se:
Respeitar o tempo da reunio;
sempre bom que todos os membros envolvidos no projecto estejam presentes
na reunio;
Definio do pronto - > especificar o que vai ser o produto final.

4/14/16

HAIDER NOOR

55

CRISTAL/CLEAR
uma metodologia gil para projecto pequenos.
As equipas so constitudas por um mximo de 6 pessoas.
Maior parte dos processos so feitos de forma informal.
Iterativo Incremental.
Verses funcionais so entregues a cada 30 dias.

4/14/16

HAIDER NOOR

56

RUP RATIONAL UNIFIED

PROCESS
Desenvolvido pela IBM, para apoiar o desenvolvimento orientado a
objectos.
Ajuda a tirar melhor vantagem do uso de UML

4/14/16

HAIDER NOOR

57

BASEA-SE EM (CICLO DE
VIDA):
1. Iniciao ou concepo;
1. Define-se os principais casos de uso e das limitaes do projecto;
2. Define-se o escopo

2. Elaborao;
1. Modularizao do sistema
2. Refinamento;
3. Elaboracao do plano do projecto;

3. Construcao;
1. Na fase de construo, comea o desenvolvimento fsico do software, produo de cdigos, testes
alfa
2. Deve-se aceitar testes, e processos de testes estveis, e se os cdigos do sistema constituem
"baseline

4. Transio;
1. Deployment do software
2. Implantao e manuteno
4/14/16

HAIDER NOOR

58

ICONIX
Para projectos de dimenses mdias. Uma junco de XP(para codificao) e
RUP (para modelao).
Quem que faz o qu?
R: diagrama de casos de uso
Quais so os objectos e os relacionamentos que existem entre eles?
R: diagrama de classes
Que objectos so necessrios para cada caso de uso?
R: diagrama de robustez
Como que os objectos interagem e colaboram entre si, num caso de uso?
R: diagrama de sequncia e colaborao.
Como so manipulados em tempo real aspectos de controle?
R: diagrama de estados
4/14/16

HAIDER NOOR

59

ENGENHARIA DE
REQUISITOS
4/14/16

HAIDER NOOR

60

ENGENHARIA DE
REQUISITOS
Requisitos trata de tudo o que necessrio para responder as
necessidades do usurio.
Engenharia de requisitos a parte da engenharia de software
reponsavel pelo levantamento, organizao, representao e
tratamentos de requisitos de um especifico software
Tipos de Requisitos
Requisitos de usurios aquilo que o usurio quer
Requisitos de sistema tudo que o sistema precisa para cumprir os requisitos
do usurio.

4/14/16

HAIDER NOOR

61

REQUISITOS DE SISTEMA
Esto divididos em funcionais e no funcionais. So especficos
ao sistema.
FUNCIONAIS
So coisais que influenciam directamente na lgica de negcio.
Lgica de negcio, funes a ser implementadas.

NO FUNCIONAIS
so factores externos que influenciam o funcionamento do sistema.
Questes de segurana, rede,

Para representar os requisitos funcionais o diagrama de casos de

uso.

4/14/16

HAIDER NOOR

62

USE CASE
Diagramas de casos de uso baseia-se em 3 elementos:
Actor

Interaco

Caso de uso

4/14/16

HAIDER NOOR

63

TIPOS DE RELACIONAMENTO
Associacao estabelecida entre uma actor e um caso de uso
representado por uma interacao. Relaciona um actor a um caso de
uso.
Verificar
extracto

4/14/16

HAIDER NOOR

64

TIPOS DE RELACIONAMENTO
generalizao como herana em POO. Esta divido em 2 partes
:
Entre actores 2 ou mais actores que podem utilizar o mesmo caso de uso.
Entre casos de uso

NB: no existe relao de generalizao entre caso de uso e actor.

vendedor

gestor
4/14/16

Efectua
vendas

Gerir
stock

Venda
a
grosso

Venda
a
retalh
o
HAIDER NOOR

65

TIPOS DE RELACIONAMENTO
Incluso uma relao onde um caso de uso dependente de
outro. uma condio. Todos os casos de uso devem ser
respondidos antes de efectuar a tarefa principal

vendas
vendedor

4/14/16

<<includes>>

Efectuar
log in

HAIDER NOOR

66

TIPOS DE RELACIONAMENTO
Extenso um if em POO. Apenas tem que se responder a um
caso de uso para efectuar a caso de uso principal. No se pode ter
uma relao de extenso sem condio.

>

ds>
n
e
ext

gerentes

Gerir
stock

<<

<<exten

ds>>

Se
Qtd<5

4/14/16

Actualizar
stock
Actualizar
stock

HAIDER NOOR

67

CASO DE ESTUDO HELPDESK

Listar os actores
Administrador
Tcnico
usurio

Identificar os casos de uso

Identificar qual actor esta conectado a qual caso de uso

4/14/16

HAIDER NOOR

68