prof. gilmar aquino de software.pdf · introdução à engenharia de software. modelos de ciclo de...
TRANSCRIPT
Ementa
Introdução à Engenharia de Software.Modelos de Ciclo de Vida de Software.Produto de Software. Técnicas deLevantamento de Requisitos. Estudo deViabilidade. Especificação de Sistemas deSoftware utilizando Paradigmas de Análisee Projeto de Sistemas. Gerenciamento doTempo. Métricas de Software. Introdução àGerência de Projetos. Qualidade deSoftware. Gerenciamento de Riscos.Testes e Revisão de Software. Implantaçãode Software. Manutenção de Software.
Bibliografia
BASICA:
Engenharia de Software Fundamentos,
Métodos e Padrões Autor: PAULA, W.
P. F. – 3ª Edição – LTC – Ano 2009
Engenharia de Software Autor:
PRESSMAN, R. S. – McGraw-Hill – Ano
2006;
UML 2.0 - Do Requisito à Solução Autor:
LIMA, A. S. – Erica – 4ª Edição.
Avaliação
Questões Online
Participação
Prova
MF = (M1 * 0,4) + (M2 * 0,6)MF < 6
MF = (MF * 0,6) + (EXA * 0,4)
40%
60%
Aula1 - Sondagem conceitos Você está recebendo uma lista de objetos, conceitos, elementos, que
fazem parte do estudo de Engenharia de Software. Escreva o que você
sabe sobre cada um deles (podem ser explicações curtas de 1, 2 ou 3
linhas):
Conceitos
Análise
Processo de observação.
Protótipo
Produto na fase de teste / ainda não comercializado.
Sistema
Conjunto de elementos com uma finalidade.
Qualidade
Necessidades e expectativas de algo.
Programa
Conjunto de instruções lógicas que são interpretado por
um dispositivo.
Conceitos
Sistemas Operacionais Conjunto de programas cuja a função é gerenciar os
recursos do sistema.
Hardware Parte concreta de um dispositivo.
Requisitos Definição documentada ( Exigência ou não )
Dados Conjunto de caracteres.
Informação Conjunto de dados organizados que formam algum
sentido.
Conceitos Conhecimento
É o ato ou efeito de abstrair ideia ou noção de alguma
coisa.
Métricas
Conjunto de regras.
Organograma
Gráfico que representa as operações de um programa.
Processo
Módulo individual executável.
Modelos
São os exemplos, padrões a seguir.
Conceitos Codificação
Conjunto de códigos que um dispositivo interpreta.
Diagrama Representação visual estruturada, mostrando o fluxo
de controle.
Implantação Disponibilização do processo ou rotina de trabalho
para o usuário final.
Implementação Colocar o novo processo em funcionamento e em uso.
Métodos / Metodologia Procedimento / Estudo de um método.
Aula 2
Disciplina Eng Soft
Pra que Eng Soft
Evolução
Características
Curvas
Produto Sistema
Tipos de Software
Problemas
Causas
Mitos
Requisitos
Etapas
Ciclo de Vida
Disciplina Eng. Software
É uma disciplina de engenharia que está relacionada com todos os aspectos da produção de software, desde os estágios iniciais da especificação até a manutenção.
- processos técnicos de desenvolvimento de sw
- atividades como gerenciamento de projetos de sw
- desenvolvimento de ferramentas, métodos e teorias que deem apoio à produção de sw.
Para que Eng. Soft?
• Para solucionar o aumento da demanda de software.
• Para solucionar o aumento do custo.
• Para solucionar os problemas do software:
estimativas de prazo e de custo imprecisas
qualidade não adequada
manutenção
complexidade (difícil entender um swgrande como um todo)
Características Software
O software é um elemento de sistema
lógico, e não físico. Portanto, o software
tem características que são
consideravelmente diferente das do
Hardware.
Tipos de Software
Software Básico;
Software de Tempo Real;
Software Comercial;
Software Científico;
Software Embutido;
Software de Inteligência Artificial;
Software Linha de produto;
Software aberto;
Aplicações para WEB;
Software Legado.
Problemas nos Softwares
Não dedicamos tempo para coletar
dados.
Insatisfação do Cliente;
A qualidade de software frequentemente
é suspeita;
O software existente é muito difícil para
manter.
Causas....
Gerentes sem experiência em Software.
Programas sem análise.
Programadores não envolvido no
processo.
Mitos
Ferramentas de ultima geração;
Horas mongóis;
Declaração por escrito sobre os procedimentos;
Projetos ele pode modificar mas as mudanças são facilmente adaptáveis;
Terminou a programação terminou o sistema;
Enquanto não terminar não consigo avaliar;
Projeto concluído é uma coisa, sistema concluído é outra coisa.
O que é Processo mesmo??
Um processo de software é um conjunto
de atividades e resultados que
produzem um produto de software.
Processos de software diferentes
organizam essas atividades de
maneiras diferentes e são descritas em
níveis de detalhes diferentes.
Etapas do Processo de Software
Apesar de existirem diferentes processos para o
desenvolvimento de software, no geral, todos os
processos apresentam as seguintes atividades:
Especificação: A funcionalidade do software e
restrições da sua operação são definidas.
Projeto e Implementação: Converte a
especificação do sistema em um sistema
executável.
Validação: O software é validado para
assegurar que faz o que o usuário deseja.
Evolução: O software deve evoluir para incluir
as mudanças resultantes das novas
necessidades do cliente.
Engenharia de Sistemas
Fase responsável por estabelecer
requisitos mínimos para todos os
elementos do sistema.
Sistema
Software Hardware
RedesBanco de Dados
Análise
Processo de coleta de Requisitos é
intensificado e concentrado no software.
Para atender a natureza dos programas
a serem construídos, o engenheiro
(analista) deve compreender o domínio
da informação para o software, bem
como função, interface. Essa fase é
documentada e revista pelo cliente.
Projeto
Um processo de múltiplos passos,
Estrutura de dados, Arquitetura de
software, Detalhes procedimentais e
caracterização de interface.
Documentado e torna-se parte da
configuração do software.
Codificação
Projeto é traduzido para linguagem de
máquina, se o projeto for executado
detalhadamente, a codificação pode ser
executada mecanicamente.
Teste
Assim que termina a codificação entra o
processo de Teste, concentra-se no
nível lógico do sistema garantindo que
todas as instruções tenham sido
testadas.
Manutenção
Sem duvidas o software terá alteração
após a entrega para o cliente. Ocorrerão
mudanças porque o software
apresentou erro.
Dúvidas??????
Por que concluir um software leva tanto
tempo?
Por que os custos de desenvolvimento são
tão altos?
Por que não conseguimos tanto tempo e
esforço mantendo programas existentes?
Por que continuamos a ter dificuldade em
medir o progresso enquanto o software
está sendo desenvolvido e mantido?
Pressman
Prototipação
Um processo que capacita o
desenvolvedor a criar um modelo de
software que será implementado.
1 – Protótipo em Papel
2 – Protótipo em Sistema
3 – Protótipo em Subsistema.
O Uso em sistemas
O principal uso é ajudar os clientes edesenvolvedores entender os requisitospara o sistema. Levantamento de requisitos. Usuários podem
experimentar o protótipo para ver como osistema pode apoiar o seu trabalho
Validação de requisitos.
O protótipo pode revelar erros e omissões nosrequisitos.
A prototipação pode ser considerada comouma atividade de redução de riscos quereduz os riscos nos requisitos.
Benefícios
Melhoria na facilidade de uso do
sistema;
Maior aproximação do sistema com as
necessidades dos usuários;
Melhoria da qualidade do projeto;
Melhoria na facilidade de manutenção;
Redução no esforço de
desenvolvimento
Prototipação
Ainda que possam ocorrer problemas, a
prototipação é eficiente, o principal
objetivo da prototipação é alinhar as
solicitações do cliente e o
desenvolvedor.
Atividade:
Pesquise sobre uma ferramenta deprototipação;
Os grupos devem se organizar para nãoter ferramentas repetidas;
Pode ser uma ferramenta que rode nodesktop (instalado) ou web (navegador);
Comente as principais características daferramenta escolhida (preço, plataformasque modela, etc.);
Se possível faça uma demonstração daferramenta;
Axure RP
Site: www.axure.com
Cria fluxogramas, wireframes , maquetes , viagensde usuários, personas , placas de idéia emuito mais. arraste rapidamente e soltar elementosde bibliotecas built-in ou personalizados paracriar seus diagramas . Em seguida , o estilo -lo compreenchimentos , gradientes, estilos de linha eformatação de texto.
Cria diagramas de clique simples ou altamentefuncionais , protótipos ricos com lógicacondicional , conteúdo dinâmico , animações ,funções matemáticas , e interações baseadas emdados sem escrever uma única linha de código.
Cacoo
Cacoo é uma ferramenta online de desenho que permiteque você crie mapas de site, wireframes, diagramas UMLe diagramas de rede.
Esta é uma ferramenta que tem a particularidade departilhar e nos permite verdadeira colaboração em tempo.Transforma apresentações de projeto ou trabalhoacadêmico em algo totalmente diferente para que nãoseja um material de textos extensos e entediante,portanto, a variedade de figuras, mapas, setas, cores eimagens que traz incorporado a este recurso permite queeles sejam usados para inovar na criação de gráficos eapresentações
Gratuito
Web
Interface para celular
Mockingbird Os esboços e protótipos podem ser feitos usando papel e lápis, mas existem
algumas ferramentas que podem ajudar nessa tarefa de modo mais técnico e
mais fácil. São as chamadas ferramentas de prototipação ou mockup.
Para isso, existe o Mockingbird (gomockingbird.com). Este foi criado desde
2009 por estudantes da Universidade de Harvard, Saikat Chakrabart e
Sheena Pakanati. Que em decorrência da falta de um aplicativo que trouxesse
a ideia para uma nova forma, resolveram desenvolver por conta própria o
Mockbingbird.
Características:
Totalmente baseado em web (online);
Gratuito por 7 dias;
Tem vários componentes, como: criar rapidamente protótipos que podem
ser visualizados e compartilhados entre clientes e colaboradores;
Porém, as funções funcionam apenas nos navegadores, Safari, Firefox,
Google Chrome e Opera;
É de fácil acessibilidade e os mockups são limpos e claros para boa
visualização.
Lumzy Uma das partes mais importantes na construção de um website é o estudo de
sua arquitetura. O arquiteto de informação, profissional responsável por esta
etapa do projeto, tem por missão fazer com que o usuário localize facilmente as
informações na página.
Existem algumas ferramentas para construção de wireframes que facilitam esse
processo, uma delas, é o Lumzy.
Como usar
O Lumzy é um serviço online para a construção de protótipos interativos, ou
seja, o esqueleto do seu site, que passará a ideia principal e guiará o restante
do trabalho. Usá-lo é muito simples, basta clicar e arrastar para ter a função
inserida no projeto. Há uma diversidade grande de objetos e são divididos em
categorias.
O Lumzy possui ferramentas de uso colaborativas, sendo possível inserir novos
envolvidos pelo seu e-mail. Dispõe de chat e registro de alterações. Outra
possibilidade que ele oferece é enviar seu projeto via correio eletrônico para um
cliente; e para o Twitter, para pedir opiniões, por exemplo.
O aplicativo é gratuito e está disponível para uso via web.
Modelo Espiral
• Ele usa uma abordagem “evolucionária” à engenharia
de software, capacitando o desenvolvedor e o cliente a
entender e reagir aos riscos em cada fase evolutiva.
• O modelo espiral usa a prototipação como um
mecanismo de redução de riscos, mas, o que é mais
importante, possibilita que o desenvolvedor aplique a
abordagem de prototipação em qualquer etapa da
evolução do produto.
• Ele mantém a abordagem de passos sistemáticos
sugerida pelo ciclo de vida clássico, mas incorpora-a
numa estrutura iterativa que reflete mais realisticamente
o mundo real.
Modelo Espiral
O modelo em espiral abrange outros
modelos de processo, como por
exemplo, prototipação;
Não há fases fixas, como especificação
ou projeto, no modelo em espiral;
Requisitos Funcionais
Um requisito funcional define uma
função de um sistema de software ou
seu componente. Uma função é descrita
como um conjunto de entradas, seu
comportamento e as saídas.
Exemplo: Chave primária, tipo de
dados, ação do usuário....
Requisitos não-fucional
Aquele que descreve não o que o
sistema fará, mas como ele fará. Assim,
por exemplo, têm-se requisitos de
desempenho, requisitos da interface
externa do sistema, restrições de
projeto e atributos da qualidade.
Exemplo : interface, plataforma, tempo
de resposta.....
Engenharia de Requisitos
O início para toda a atividade de desenvolvimentode software é o levantamento de requisitos.
Para isto, analistas e engenheiros de softwaretrabalham com clientes e usuários finais paradescobrir o problema a ser resolvido, os serviçosdo sistema, o desempenho necessário, restriçõesde hardware e outras informações. Existemalgumas técnicas que apoiam as atividades delevantamento de requisitos.
Exemplo de fluxos de atividades da etapa deEspecificação de Software ou Engenharia deRequisitos
Técnicas de Eng. Requisitos
Método Conversação;
Método Observação;
Método Analítico;
Método Sintético.
Técnicas de Eng. Requisitos
O método de conversação fornece um meio de comunicação verbal
entre duas ou mais pessoas. Sendo uma forma natural de
expressar as necessidades;
Métodos de Conversação:
Entrevistas;
Workshop;
BrainStorming;
Questionário;
Grupo Focal;
Entrevista
Principais Vantagens Principais Desvantagens
1) Com um plano geral bem elaborado, o analista
terá facilidade em descobrir que informação o
usuário está mais interessado e usar um estilo
adequado ao entrevistar;
2) Poder alterar o curso da entrevista de forma a
obter informações sobre aspectos importantes que
não tinham sido previstos no planejamento da
entrevista;
3) Poder alterar a ordem sequencial das perguntas;
4) Poder eliminar perguntas anteriormente
planejadas;
5) Poder incluir perguntas que não estavam na
programação da entrevista;6) Poder motivar o
entrevistado no decorrer do processo;
1) Podem ocorrer desvios de curso, no decorrer da
entrevista;
2) Consumir mais tempo e recursos com sua
realização;
3) Tratamento diferenciado para os entrevistados;
4) É necessário ter um plano de entrevista para
que não haja dispersão do assunto principal e a
entrevista fique longa, deixando o entrevistado
cansado e não produzindo bons resultados;
5) O usuário tem dificuldade de concentração em
reuniões muito longas;
6) O entrevistado pode não saber expressar
corretamente suas necessidades ao analista.
A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz
bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador
dê espaço ao entrevistado para esclarecer as suas necessidades.
WorkShopTrata-se de uma técnica grupo usada em uma reunião estruturada. Devem fazer parte
do grupo uma equipe de analistas e uma seleção dos usuários que melhor representam
a organização e o contexto em que o sistema será usado, obtendo assim um conjunto
de requisitos bem definidos.
Principais Vantagens Principais Desvantagens
1) Obtêm um conjunto de requisitos
bem definido;
2) Trabalho em equipe tornando o
levantamento de requisitos mais
eficaz;
3) Baixo custo e resposta
relativamente rápida;
4) Tempo de obtenção de
informações é reduzido.
1) Por ser realizado por convocação
por dia e horário, pode ocasionar
problemas no presenciais dos
usuários;
2) Não abre caminho para ideias
externas além da equipe de
analistas; Dados excessivamente
agregados.
BrainStormingÉ utilizado normalmente em workshops. Após os workshops serão produzidas
documentações que refletem os requisitos e decisões tomadas sobre o sistema a ser
desenvolvido.
Principais Vantagens Principais Desvantagens
1) Várias pessoas pensam melhor do
que uma (grupo pensante);
2) Rompe a inibição de ideias;
3) Generaliza a participação do
membros do grupo.
1) Disponibilidade de todos pode
inviabilizar o levantamento de dados.
Questionário
Diferente da entrevista, essa técnica é interessante quando temos uma quantidade
grande de pessoas para extrair as mesma informações. As questões são dirigidas por
escrito aos participantes com o objetivo de ter conhecimento sobre opiniões das
mesmas questões.
Principais Vantagens Principais Desvantagens
1)Atinge um grande número de
pessoas; Menores custos;
2) Permite que os participantes
respondam no momento em que
acharem conveniente;
3) Questões padronizadas garantem
uniformidade.
1) Não há garantia de que a maioria
dos participantes respondam o
questionário;
2) Os resultados são bastante
críticos em relação ao objetivo, pois
as perguntas podem ter significados
diferentes a cada participante
questionado.
Grupo FocalÉ um grupo de discussão informal e de tamanho reduzido (até 12 pessoas), com o
propósito de obter informação qualitativa em profundidade.
Principais Vantagens Principais Desvantagens
1) Baixo custo, resposta rápida e
Flexibilidade;
2) Obtêm informações qualitativas
a curto prazo;
3) Eficiente para esclarecer
questões complexas no
desenvolvimento de projetos;
1) Exige facilitador/moderador com
experiência para conduzir o
grupo; Não garante total
anonimato;
2) Depende da seleção criteriosa
dos participantes;
3) Informações obtidas não podem
ser generalizadas.
Técnicas de Eng. Requisitos
Métodos de Observação:
Etnografia
Observação
Protocolo de Análise
Utilizado para a compreensão do domínio da aplicação, observando as atividades humanas.Utilizado para a compreensão do domínio da aplicação, observando as atividades humanas.Utilizado para a compreensão do domínio da aplicação, observando as atividades humanas.
Utilizado para a compreensão do domínio da aplicação, observando as atividades
humanas.
EtnografiaÉ uma análise de componente social das tarefas desempenhadas numa dada
organização. É utilizado para desenvolver um entendimento completo e detalhado.
Principais Vantagens Principais Desvantagens
1) Capacidade de observar o
comportamento do ambiente,
gerando maior profundidade no
conhecimento.
2) Apoia-se no comportamento real;
3) Permite uma abordagem integral.
1) Dificuldades para analisar e
interpretar situações;
2) A amostra pode ser reduzida;
3) Requer treinamento
especializado;
4) As observações podem ter uma
interpretação complicada.
ObservaçãoA técnica resume-se em visitar o local em foco com a finalidade de observação
do mesmo. Permitindo assim, coletar informações de acordo com o cotidiano das
operações e execução dos processos diários do local.
Principais Vantagens Principais Desvantagens
1) Capaz de captar o
comportamento natural das pessoas
visando o processo;
2) Nível de intromissão
relativamente baixo;
3) Confiável para observações com
baixo nível de inferência.
1) Polarizada pelo observador;
2) Requer treinamento
especializado;
3) Efeitos do observador nas
pessoas;
4) Não comprova/esclarece o
observado;5) Número restrito de
variáveis.
Protocolo de Análise
Principais Vantagens Principais Desvantagens
1) Processo de extração de
registro de tarefas via audio,
vídeo ou notas escritas.
1) o analista deve ter
conhecimento suficiente
sobre domínio atual, a fim de
compreender melhor as
tarefas.
Análise de protocolo é uma forma de levantamento de requisitos no qual o
analista analisa as partes interessadas quando estão envolvidas em algum
tipo de tarefas.
Técnicas de Eng. Requisitos
Método Analítico:
Reuso do Requisito;
Estudo de documentação;
Laddering;
Sorteio de Cartões;
Conjunto de técnicas para analise de documentação e conhecimento existentes com ointuito de adquirir requisitos através do levantamento de informação pertinentes aosistema a ser especificado, como por exemplo, domínio do negócio, fluxos de trabalho ecaracterísticas do produto.
Reuso de RequisitosEstudo e reutilização de especificações e glossários referente a projetos de sistemas legados ou sistemas de mesma família (com funcionalidades de negócio similares).
Principais Vantagens
1) Economia de tempo e dinheiro: Estudos tem
mostrado que sistemas similares podem reutilizar
acima de 80% de seus requisitos; Pode levar a uma
reutilização adicional de outros itens em outras
atividades do ciclo de vida de desenvolvimento (ex.:
reuso do design de componentes já existentes,
testes e código fonte);
2) Redução de risco: Requerimentos reutilizados tem
uma chance maior de serem compreendidos pelos
usuários visto que já são conhecidos de certa forma;
Estudo DocumentalEstudo e reutilização de documentação de diferentes naturezas, para a identificação de
requisitos a serem implementados no sistema que se está modelando. Uma grande
variedade de documentação pode ser analisada incluindo estrutura organizacional da
empresa, padrões de mercado, leis, manuais de usuário, relatório de pesquisas de
mercado, glossário de termos de negócio, etc.
Principais Desvantagens: Documentos com
problemas podem levar a uma falha na
definição dos requisitos;
LadderingÉ um método de entrevistas estruturadas, um-a-um, utilizado para o levantamento de
conhecimento (o que é importante e por que) de especialistas, e que consiste na
criação, revisão e modificação da hierarquia de conhecimento dos especialistas
geralmente na forma de diagramas hierárquicos .
Principais Vantagens Principais Desvantagens
1) Cobre um amplo domínio de requisitos;
2) Necessita de menos tempo para a
preparação e execução das sessões de
levantamento;
3) Necessita de menos experiência para a
execução das sessões de levantamento;
4) Provê um formato padrão que é
adaptável para a automação
computadorizada;
1) Não é capaz de extrair todos os tipos
de requisitos;
2) Necessita da execução combinada de
outras técnicas de levantamento de
requisitos para sua complementação em
determinados domínios;
3) Não é compatível com todo e qualquer
domínio de requisitos, sendo necessário
a verificação de sua adequação ao
levantamento a ser feito;
Sorteio de Cartão
Utilizado para capturar informações e ideias sobre estrutura de requisitos de
especialistas. Neste método um conjunto de cartões é distribuído em um grupo de
usuários onde cada cartão é impresso com a descrição de cada atividade.
Principais Vantagens
1) Ajuda os usuários a levantar os conceitos de atividades e
distinguir entre problemas de alto e baixo nível;
2) O resultado do método pode ser utilizado como insumo para
outros métodos de levantamento de requisitos;
Técnicas de Eng. Requisitos
Método Sintético:
JAD (Joint Application Development);
Prototipação;
Questionário Ambiente;
Storyboards.
Algumas vezes em projetos complexos um único método de levantamento de requisitos
não é suficiente para capturar os requisitos detalhadamente. Para solucionar este
problema os analistas de requisitos tentam utilizar diferentes métodos de levantamento
de requisitos.
JAD (Joint Application
Development)Consiste em workshops e sessões de grupo nos quais usuários e analistas de
requisitos se encontram para discutir as características desejadas do produto. Seu
objetivo é envolver todos os usuários importantes no processo de levantamento, através
de reuniões estruturadas e com foco bem definido.
Principais Vantagens Principais Desvantagens
1) As discussões que ocorrem na fase de
sessões são altamente produtivas porque
resolvem dificuldades entre as partes
enquanto se dá o desenvolvimento do
sistema para a empresa;
2) Melhor aplicado para grandes e
complexos projetos;
1) Somente projetos que possuem pelo
menos uma das características abaixo
podem utilizar o JAD:- Possuir alto número
de stakeholders responsáveis por
departamentos cross na empresa;-
Primeiro projeto na empresa o qual é
considerado crítico para o futuro da
mesma;
2) Requer mais recursos se comparado à
métodos tradicionais;
PrototipaçãoUtilizado no estágio inicial do projeto. Ajuda aos usuário a desenvolver uma forte noção
sobre a aplicação a qual ainda não foi implementada.
Principais Vantagens Principais Desvantagens
1) Permite alcançar um feedback
antecipado dos usuários;
2) Redução de tempo e custo de
desenvolvimento devido a detecção
dos erros em uma fase inicial do
projeto;
3) Prove alto nível de satisfação
dos usuários devido a sensação de
segurança ao ver algo próximo do
real;
1) Demanda um alto custo de
investimento, em relação à outros
métodos, para ser realizado;
2) Demanda um tempo maior para
sua realização devido a
complexidade do sistema e a
limitações técnicas;
Questionário AmbientePermite aos analistas o real entendimento das necessidades dos usuários com a coleta
detalhada de informações através de observação e interação com as pessoas no
ambiente de trabalho.
Principais Vantagens Principais Desvantagens
1) Permite um levantamento
profundo e detalhado das
necessidades dos stakeholders;
2) Pode ser utilizado para resolver
problemas extremamente
complexos;
1) Dependendo dos processos de
trabalho, necessita de uma grande
quantidade de tempo e pessoas
para ser executado;
StoryboardSão sessões interativas que descreve uma sequência de atividades e eventos para um
caso em específico para um processo genérico.
Principais Vantagens
1) Método muito eficiente no esclarecimento de requisitos
relacionados a processos, fluxos de dados e tarefas;
2) Método relativamente barato de ser executado;
Considerações sobre Eng.
Requisitos
Vantagens e desvantagens;
Utilização de técnicas;
Pessoas utilizam sistemas;
Estude o método aplicado;
QUALIDADE
Aula 6 – Estudo de Viabilidade
O que é um estudo de viabilidade?
O que estudar e concluir?
Benefícios e custos
Análise de custo/benefício
Alternativas de comparação
Atividade
Estudo de Viabilidade
Projetos começam quando alguém tem umaoportunidade para criar um negócio com usoda tecnologia de informação;
Estudo que indica se o esforço emdesenvolver a ideia vale a pena; Visa tanto a tomada de decisão;
Como a sugestão de possíveis alternativas desolução.○ se o projeto pode ou não ser feito
○ se o produto final irá ou não beneficiar os usuáriosinteressados
○ escolha das alternativas entre as possíveis soluções
○ a melhor alternativa?
Estudo de Viabilidade - O Que
Estudar?
Sistema organizacional apresentado
Usuários, políticas, funções, objetivos, etc.
Problemas com o sistema apresentado
Inconsistências, funcionalidadesinadequadas, performance, etc.
Objetivos e outros requisitos para onovo sistema
O que precisa mudar?
Estudo de Viabilidade - O Que
Estudar?
Restrições
Incluindo requisitos não-funcionais do
sistema (superficialmente)
Alternativas possíveis
Sistema atual é geralmente uma das
alternativas
Vantagens e desvantagens das
alternativas
Testes de Viabilidade
Operacional
Medida do grau de adequação da soluçãopara a organização
○ Avaliação de como as pessoas se sentemsobre o sistema/projeto
Técnica
Avaliação da praticidade de uma soluçãotécnica específica e a disponibilidade dosrecursos técnicos e dos especialistas
Testes de Viabilidade
Cronograma
Avaliação de quanto razoável está o
cronograma do projeto
Econômica
Avaliação de custo-eficiência de um projeto
ou solução
○ Conhecida como análise de custo/benefício
Viabilidade Operacional
Avalia a urgência do problema (visão efases de estudo) ou a aceitação dasolução (definição, seleção, aquisição, efases do projeto)
Há dois aspectos da viabilidadeoperacional a serem considerados O problema vale a pena ser resolvido ou a
solução proposta para o problema funcionará?
Como o usuário final e a gerência sentem-sesobre o problema (solução)?
Viabilidade Técnica
A solução ou a tecnologia proposta é
prática?
Já possuímos a tecnologia necessária?
Já possuímos o conhecimento técnico
necessário?
Viabilidade de Cronograma
Dado nosso conhecimento técnico, os
prazos dos projetos são razoáveis?
Alguns projetos são iniciados com prazos
específicos
○ Você precisa determinar se os prazos são
obrigatórios ou desejáveis
○ Se são mais desejáveis que obrigatórios, o
analista pode propor outros cronogramas
Viabilidade de Econômica
Talvez a mais crítica
Durante as fases iniciais do projeto, a análise
da viabilidade econômica consiste em julgar se
os possíveis benefícios de solucionar o
problema são ou não vantajosos
Tão logo os requisitos específicos e soluções
sejam identificados, o analista pode levar em
consideração os custos e benefícios de cada
alternativa
○ Isso é chamado de análise de custo-benefício
Tipos de Custos
Custos de desenvolvimento de
sistemas
São custos que ocorrem somente uma vez.
Alguns custos de desenvolvimento de sistemas:
○ Custos com o pessoal
○ Uso do computador
○ Treinamento
○ Custos de equipamentos, duplicação e
suprimentos.
○ Custo de alguns novos equipamentos de
computadores e software.
Tipos de Custos
Custos da operação de Sistemas
Contínuos durante todo tempo de vida do
sistema.
Os custos de operação de um sistema
sobre o seu tempo de vida podem ser
classificados como fixos e variáveis.
Depois de determinar os custos e
benefícios para uma possível solução, você
pode realizar a análise de custo-benefício.
Custo fixos
Ocorrem em intervalos regulares, mas
com taxas relativamente fixas.
Pagamentos de aluguel e pagamentos de
licença de software.
Salários dos operadores de sistemas de
informação e do pessoal de suporte (mesmo
que o salário aumente, o aumento é gradual
e não muda drasticamente de um mês para
o outro).
Custos variáveis
Ocorrem em proporção por algum fatorhabitual.
Custos de uso de computador (tempo deCPU, tempo de conexão de um terminal,armazenamento) que variam com a cargado trabalho.
Suprimentos (formulários, papel daimpressora, disquetes, fitas magnéticas),que variam com a carga do trabalho. Custosadicionais (manutenção, telefone, energia,água, etc).
Benefícios oferecerá?
Benefícios, normalmente, aumentam os
lucros ou diminuem os custos (ambos
são características altamente desejáveis
para um novo sistema de informação).
Tanto quanto possível, benefícios
devem ser quantificados em dólares.
Benefícios são classificados como
tangíveis ou intangíveis.
Tangíveis x Intangíveis
Tangíveis: Aqueles que podem ser
facilmente quantificados.
Benefícios tangíveis são, usualmente,
medidos em termos de economia mensal ou
anual ou de vantagens para a empresa.
Exemplos incluem: diminuição de erros de
processamento, redução de despesas, e
crescimento de vendas.
Tangíveis x Intangíveis
Intangíveis: Aqueles benefícios que são
difíceis ou impossíveis de serem
quantificados.
Exemplos: melhoria da satisfação do
cliente e melhoria da moral do empregado.
Infelizmente, se um benefício não pode ser
quantificado, é difícil aceitar a validade de
uma análise de custo-benefício que está
baseada em dados incompletos.
Atividade
Desenvolva uma planilha com as
despesas de desenvolvimento de
software.
Fixas Mensal
Hardware
Software
Treinamento
Custo total.
Gerenciamento de Projetos
O fracasso de muitos projetos de softwares grandes nas
décadas de 60 e 70 foi uma indicações das dificuldades de
gerenciamento de software que as empresas enfrentavam.
Muitos destes projetos fracassaram porque a abordagem
gerencial estava errada.
O trabalho do gerente de software é garantir que o projeto
cumpra as restrições impostas:
○ Orçamentária; (dólares)
○ Prazo; (Métricas orientadas à função)
○ Requisito;
O bom gerenciamento não pode garantir o sucesso do
projeto, mas o mau gerenciamento geralmente resulta no
fracasso do projeto.
Gerenciamento de Projetos
A engenharia de software é distinta de outros tipos de
engenharia, tornando o gerenciamento de software difícil. As
principais diferenças são:
O produto é intangível;
Não há processo de software padrão;
Grandes projetos de software são frequentemente únicos.
Gerenciamento de Projetos
Segundo Carneiro (2000), o Gerenciamento de projetos é a
aplicação de Conhecimento, Habilidades, Ferramentas e
Técnicas nas atividades de projetos de forma a atender
ou superar as expectativas dos stakeholders (interessados,
atores, participantes) e que envolve o balanceamento de”:
Escopo, tempo, custo e qualidade;
Necessidades (requisitos definidos) e expectativas (subjetivos
ou não definidos);
Diferentes expectativas e necessidades de todos aqueles que
participam do projeto direta ou indiretamente.
Gerenciamento de ProjetosEmbora não percebamos, estamos o tempo todo planejando. Planejar faz
parte da existência humana, qualquer um planeja, vejamos:
Atravessar a rua exige planejamento?
Pegar ônibus exige planejamento?
Paquerar exige planejamento?
Avaliando o Risco
Gerenciamento de Projeto
Na maioria das vezes, o Gerente de Software assume algumas ou todas
as seguintes atividades:
• Elaboração de propostas;
• Planejamento e programação de projetos;
• Levantamento dos custos do projeto;
• Monitoramento e revisões de projetos;
• Seleção e avaliação de pessoal;
• Elaboração de relatórios e apresentações.
Gerenciamento de ProjetosPMI (Project Management Institute) identifica 9 (nove) áreas de
conhecimento em gerenciamento de projetos. Apesar desta
abordagem de apresentá-las de forma separada, por razões
didáticas, deve-se estudá-las com a percepção de todas estão
intimamente interligadas.
Durante algum tempo o principal enfoque do gerenciamento
de projetos era a gerência do tempo: fazer com que as coisas
acontecessem dentro do prazo esperado. Em algumas empresas,
em especial no governo, o enfoque de gerenciamento de projeto
era mais orçamentário, ou seja, quando acabasse o dinheiro,
acabaria o projeto.
Gerenciamento de Projetos
As áreas de conhecimeto de gestão de projetos são chamados na
metodologia PMI de disciplinas:
•Gerenciamento de Integração entre os elementos do projeto;
• Gerenciamento de Escopo de Projeto;
• Gerenciamento de Tempo do projeto;
• Gerenciamento do Custo;
• Gerenciamento da Qualidade;
• Gerenciamento de Recursos Humanos;
• Gerenciamento de Comunicação;
• Gerenciamento de Risco;
• Gerenciamento de Contratos.
Todas estas disciplinas, aliadas às técnicas, métodos e ferramentas de
cada uma, apoiam a condução do projeto de forma a garantir qualidade,
atendimento aos prazos, custos e requisitos desejados.
O PMI® ocupa uma posição de liderança global no desenvolvimento
de padrões para a prática da profissão de Gerenciamento de Projetos
em todo o mundo. O principal documento padrão do PMI®, “A Guide to
the Project Management Body of Knowledge (PMBOK® Guide)”, é um
padrão globalmente reconhecido para o Gerenciamento de Projetos
nos mercados de hoje.
Gerenciamento de Projeto
Além do PMBOK® Guide, outros padrões foram desenvolvidos:
•PMCDF (Project Manager Competency Development
Framework)
•EVM (Practice Standard for Earned Value Management)
•WBS(Practice Standard for WBS – Work Breakdown
Structure)
•PPMS (Program and Portifolio Management Standards)
•OPM3 (Organizational Project Management Maturity Model)
Gerenciamento de Projeto
A aplicação dos princípios de Gerenciamento de Projetos permite que os
executivos:
Estabeleçam medidas do sucesso:
•Mantenham o foco no cliente;
•Quantifiquem o valor agregado correspondente aos custos;
•Aperfeiçoem o uso dos recursos da organização;
•Incorporem princípios de qualidade;
•Coloquem planos estratégicos em marcha;
•Assegurar a atualização da empresa às demandas do mercado.
Gerenciamento de Projeto
Gerenciamento de ProjetoTodo projeto é desenvolvido em cinco etapas: Iniciação, planejamento,
execução, controle e conclusão:
Iniciação é a etapa onde tomamos
conhecimento do projeto a ser feito
Planejamento é onde o projeto é detalhado, se
aplicarmos o principio de Pareto. O resultado do
planejamento é uma lista de tarefas e/ou um
gráfico de Gantt.
Execução é o objetivo do projeto, é a “hora da
verdade”, quem executa é o gestor técnico, é
a hora de colocar o projeto em prática.
Controle, o gestor do projeto faz o controle da
execução, registrando tempo e recursos, e
gerenciando as possíveis mudanças.
Conclusão, bom conclusão dispensa mais
comentários, é a hora em que o projeto termina.
Ciclo de monitoramento e controle
Gerenciamento de ProjetoO desenvolvimento ágil de software reúne uma série de metodologias de baixo
overhead. Reconhecem que software é algo difícil de controlar. Essas
metodologias minimizam riscos garantindo que os engenheiros de software
foquem em unidades menores de trabalho.
É um dos métodos da metodologia ágil para gerenciamento de Projetos. Scrum
vem sendo amplamente adotado por empresas como o portal Terra e a
Globo.com, justamente por atender com precisão às necessidades do
desenvolvimento de software e sites
Gerenciameto de ProjetoTecnologias disponíveis, existem diversas tecnologias disponíveis on e offline
para gestão de projetos, a grande maioria esta disponível gratuitamente. São
elas:
Microsoft Project
É a versão comercializada pela Microsoft e é o padrão do
mercado. O Microsoft project proporciona todas as ferramentas para
gestão de projetos de acordo com as especificações do PMI, e conta com a
possibilidade de compartilhamento utilizando o Microsoft project server.
Serena Open Project
O Serena Open Project é muito semelhante ao Microsoft Project,
em praticamente todas as suas funcionalidades, e inclusive lê arquivos do
Microsoft Project. Alem disto é completamente gratuito e possui versões
para Windows, Linux e Mac OS 10.
Gerenciamento de Projetos
Serena Projects on demand
É uma versão online compatível com o Serena Open Project,
esta versão online permite múltiplos usuários. Para utilizar a versão online
o usuário paga uma taxa mensal.
dotProject
O dotProject é uma solução online totalmente gratuita, é
necessário um servidor com suporte a PHP e MySQL para sua instalação.
Ele apresenta uma interface um pouco mais complexa que a dos demais
gerenciadores e é totalmente focado no uso colaborativo, contendo
inclusive um forum de discusão, lista de links e arquivos dentro do
ambiente de gestão de projetos.
Qualidade de SoftwareHoje em dia, muito se fala em qualidade de software, mas nem sempre as
pessoas têm uma noção desse conceito. Pode-se considerar qualidade sob
diferentes pontos de vista e, portanto, pode-se ter diferentes definições sendo
algumas das mais comuns listadas a seguir:
•Software sem defeitos.
• Software adequado ao uso.
• Software que atende as especificações
• Software produzido por uma empresa que possui o certificado
ISO9000 para seu sistema de qualidade.
• Software que possui confiabilidade / usabilidade /
manutenibilidade.
Qualidade de SoftwareDe acordo com o [PMBOK2000], o Gerenciamento da Qualidade do
Projeto inclui os processos necessários para garantir que o projeto irá
satisfazer as necessidades para a qual ele foi empreendido.
Planejamento da Qualidade
Garantia da Qualidade
Controle da Qualidade
Modelos e Padrões da Qualidade
Aula 9
• Verificação e Validação
• Motivação para teste
• Finalidades dos Testes
• Testes de Software: Definições e Conceitos
• Formando a Equipe de Testes
• Relacionando as atividades de Testes com as de
Desenvolvimento
• Processo de Teste
• Gerenciamento de Bugs
• Ferramentas de Teste
Objetivo
• Apresentar uma abordagem geral sobre o
processo de teste de software, abrangendo
seus principais fundamentos técnicos e
gerenciais. Além disso, serão apresentados
os principais conceitos necessários para
um bom entendimento sobre as atividades
de teste.
VERIFICAÇÃO E VALIDAÇÃO
• O desenvolvimento de software está sujeito a diversos tipos de problemas, os quais acabam resultando na obtenção de um produto diferente daquele que se esperava.
• Muitos fatores podem ser identificados como causas de tais problemas, mas a maioria deles tem uma única origem: erro humano (Delamaro et al., 2007).
• As atividades de Verificação e Validação (V&V) visam garantir, respectivamente, que:
– o software está sendo desenvolvido corretamente,
– o software que está sendo desenvolvido é o software correto.
V&V: ESTÁTICA X DINÂMICA
• As atividades de V&V costumam ser divididas em
estáticas e dinâmicas.
• As estáticas não requerem a execução ou mesmo a
existência de um programa ou modelo executável para
serem realizadas.
• As dinâmicas se baseiam na execução de um
programa ou modelo (Delamaro et al., 2007).
MOTIVAÇÃO PARA TESTE
As falhas causam
prejuízos
financeiros
As falhas causam a
perda de confiança
do cliente
POR QUE ALGUMAS EMPRESAS NÃO
TESTAM
Teste é um
processo
caro
Dificuldade em
implantar um
processo de teste
Desconhecem a
relação
custo/benefício
Só se
preocupam
com teste na
fase final do
projeto
Desconhecem
técnicas de teste
adequadas
MOTIVAÇÃO PARA TESTE
• Segundo pesquisas do SEI ( Software
Engineering Institute):
– 30% dos projetos são cancelados antes de
serem finalizados
– 70% dos projetos falham nas entregas
das funcionalidades esperadas;
– Os custos dos projetos extrapolam mais de 180%
dos valores previstos;
MOTIVAÇÃO PARA TESTE
– Prazos excedem mais de 220%
– Empresas de nível 1 dedicam cerca de 55%
dos esforços para corrigir defeitos
– Esses índices vão sendo gradativamente reduzidos
à medida que elas adotam um modelo de
qualidade
FINALIDADE DOS TESTES
– Verificar se todos os requisitos do sistema
foram corretamente implementados
– Assegurar a satisfação do cliente com o
produto desenvolvido
– Assegurar, na medida do possível, a qualidade e
a corretude do software produzido
– Reduzir custos de manutenção corretiva e
retrabalho
FINALIDADE DOS TESTES
“Teste é o processo de demonstrar que erros não
estão presentes”
“O objetivo do teste é demonstrar que um programa
executa suas funções corretamente”
“Teste é o processo de criação de confiança de que
o programa faz o que ele tem que fazer"
Teste é o processo de executar um programa
com a intenção de encontrar defeitos
TESTE DE SOFTWARE
• É o processo de executar um programa com o
objetivo de encontrar defeitos (Myers, 1979).
• É, portanto, uma atividade de V&V dinâmica.
• Do ponto de vista psicológico, o teste de software
é uma atividade com um certo viés destrutivo, ao
contrário de outras atividades do processo de
software.
PERSPECTIVA DE TESTE
• Bons testadores necessitam de um conjunto especial de habilidades. Um testador deve abordar um software com a atitude de questionar tudo sobre ele (McGregor e Sykes, 2001).
• A perspectiva de teste é, um modo de olhar qualquer produto de desenvolvimento e questionar a sua validade.
• Habilidades requeridas na perspectiva de teste:
– Querer prova de qualidade,
– Não fazer suposições,
– Não deixar passar áreas importantes,
– Procurar ser reproduzível.
TESTE DE SOFTWARE
• Executa-se um programa ou modelo utilizando
algumas entradas em particular e verificar-se se seu
comportamento está de acordo com o esperado.
• Caso a execução apresente algum resultado
não especificado, um defeito foi identificado.
• Os dados da execução podem servir como fonte para
a localização e correção de defeitos, mas teste não é
depuração (Delamaro et al., 2007).
TERMINOLOGIA
• Defeito
– Instrução ou definião incorreta
• Falha
– Resultados Incorretos
• Erro
– Falha resultante de ação humana
• Durante o teste observamos as falhas. Na
depuração do código encontramos os
defeitos (causas) para corrigi-los.
FORMANDO A EQUIPE DE TESTES
Usando a Equipe de Desenvolvimento:
- O Líder do Projeto de
Desenvolvimento também o Líder do
Projeto de Testes;
- A Equipe de Teste é a mesma Equipe de
Desenvolvimento;
- Os Testes serão executados através de rodízios,
onde nunca a pessoa que desenvolveu o
módulo executará testes no próprio modulo.
FORMANDO A EQUIPE DE TESTES
Desvantagens:
- Diminuição da qualidade do produto final;
- Tendência a não visualizar certos defeitos
do projeto (testes de sucesso);
- Tendência a informalidade na execução
dos testes;
- Dificuldade de conciliar os cronogramas
das equipes de desenvolvimento;
- Falta de conhecimento do negócio da equipe
que for executar os testes.
FORMANDO A EQUIPE DE TESTES
Usando Equipe Independente:
• Esta é uma prática que está sendo cada vez mais
usada no mercado;
• Equipes especializadas em teste produzem
resultados, em termos de qualidade do software,
muito melhores;
• Essas equipes possuem um treinamento
adequado para executar com qualidade os
testes e estão bastante familiarizadas com as
suas ferramentas e metodologias.
FORMANDO A EQUIPE DE TESTES
Desvantagens:
- Custos maiores;
- Aumento no tempo de liberação do
software;
- Tendência da equipe de desenvolvimento
em relaxar
- Divergências entre as duas equipes.
FORMANDO A EQUIPE DE TESTES
Usando Equipes de não-especialistas em TI
- Muitas empresas usam grupos de usuários para
fazer o chamado trabalho de homologação do
software ou
o seu teste de aceitação;
- A perspectiva é sempre a do negócio, ou seja,
garantir que o software foi desenvolvido de acordo
com os requisitos que foram estabelecidos pelo
negócio.
FORMANDO A EQUIPE DE TESTES
Desvantagens:
- Custos maiores;
- Falta de familiarização com ferramentas;
- Abordagens exclusivas do negócio,
esquecendo aspectos técnicos do teste.
ESTÁGIOS DE TESTE
Testes
de
unidade
Testes de
Integ ração
Testes de
Sistema
Testes de
Aceitação
Entrega
TIPOS DE TESTE
– Teste Funcional
– Teste de Recuperação de Falhas
– Teste de segurança e controle de
acesso
– Teste de performance
– Teste de estresse
– Teste de configuração ou portabilidade
– Teste de interface com o usuário
– Teste de regressão
ABORDAGENS DE TESTE
• Abordagem funcional(“caixa-preta”)
Os testes são gerados a partir de uma análise dos
relacionamentos entre os dados de entrada e de
saída
• Abordagem estrutural(“caixa-branca”)
Os testes são executados a partir de uma análise
dos caminhos lógicos possíveis de serem
executados.
PROCESSO DE TESTE- Planejar Testes
- Especificar Testes
- Executar Testes
- Reportar Testes
Entradas
–Documento de
Requisitos
–Plano de Projeto
–Modelos de Caso de Uso
Saídas
–Plano de Testes
RELATÓRIO DE TESTES
- Registrar resultados
- Avaliar resultados
- Encaminhar ao desenvolvedor
responsável
GERENCIAMENTO DE BUGS
Classificação de defeitos:
1.Faltante: O defeito ocorre em virtude da falta parcial
ou total de um requisito;
2.Errado: O defeito ocorre porque o requisito
foi implementado corretamente;
3.Acréscimo: O defeito ocorre em virtude de um
comportamento ou elemento que foi implementado
mas não foi especificado no requisito.
Ferramentas de Testes
Automatizam atividades do processo de teste
Podem nos auxiliar em todas as atividades do
processo de teste
Ferramentas de planejamento e projeto de testes:
Elaborar plano de testes. Ex: Project
Projetar testes:Excel, TestManager
Executar testes:Excel, TestManager
Avaliar testes:Excel, TestManager
Implementação: Junit(unidade), Jtest e C++Test (Análise estática de
código)
Gerência de defeitos: Bugzilla, Mantis, Redmine
Considerações• Software com testes melhoram a credibilidade do setor de
informática
• Usuário mais satisfeito
• Desenvolvedor perderá menos tempo resolvendo bugs de
sistemas em produção, enquanto está alocado em outro
projeto
• Desenvolvedor mais satisfeito e motivado
• Sistema só deve ser colocado em produção após
aprovação da equipe de testes.
• A equipe de teste é parte da equipe de desenvolvimento.
• Cronogramas devem levar em consideração os testes.
• Processo de Teste deve ser integrado ao processo de
desenvolvimento
• Testar reduz riscos do negócio
160
Introdução
O modelo de casos de uso é uma
representação das funcionalidades
externamente observáveis do sistema e
dos elementos externos ao sistema que
interagem com o mesmo.
O modelo de casos de uso modela os
requisitos funcionais do sistema.
161
Introdução
O diagrama da UML utilizado na modelagem de casos de uso é o diagrama de casos de uso.
Técnica de modelagem idealizada por Ivar Jacobson, na década de 1970.
Mais tarde, incorporada ao método Objectory.
Posteriormente, a notação de casos de uso foi adicionada à UML.
162
Introdução
Este modelo direciona diversas das
tarefas posteriores do ciclo de vida do
sistema de software.
Além disso, o modelo de casos de uso
força os desenvolvedores a moldar o
sistema de acordo com o usuário.
163
Componentes do modelo
O modelo de casos de uso de um
sistema é composto de:
Casos de uso
Atores
Relacionamentos entre os elementos
anteriores.
Copyright 2002, 2003 Eduardo Bezerra 164
Casos de uso
Um caso de uso é a especificação de uma seqüência de interações entre um sistema e os agentes externos.
Define parte da funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos deste sistema.
Um modelo de casos de uso típico é formado de vários casos de uso.
165
Casos de uso
Um caso de uso representa quemfaz o que (interage) com o sistema, sem considerar o comportamento interno do sistema.
166
Descrições
Cada caso de uso é definido através da descrição narrativa das interações que ocorrem entre o(s) elemento(s) externo(s) e o sistema.
Há várias formas de se descrever casos de uso.
Copyright 2002, 2003 Eduardo Bezerra 167
Exemplo de descrição contínua
O Cliente chega ao caixa eletrônico e insere seu cartão. O Sistema requisita a senha do Cliente. Após o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as opções de operações possíveis. O Cliente opta por realizar um saque. Então o Sistema requisita o total a ser sacado. O Sistema fornece a quantia desejada e imprime o recibo para o Cliente.
Copyright 2002, 2003 Eduardo Bezerra 168
Exemplo de descrição numerada
1. Cliente insere seu cartão no caixa eletrônico.
2. Sistema apresenta solicitação de senha.
3. Cliente digita senha.
4. Sistema exibe menu de operações disponíveis.
5. Cliente indica que deseja realizar um saque.
6. Sistema requisita quantia a ser sacada.
7. Cliente retira a quantia e recibo.
169
Exemplo de narrativa particionada
Cliente Sistema
Insere seu cartão no caixa eletrônico.
Digita senha.
Solicita realização de saque.
Retira a quantia e o recibo.
Apresenta solicitação de senha.
Exibe operações disponíveis.
Requisita quantia a ser sacada.
Copyright 2002, 2003 Eduardo Bezerra 170
Detalhamento
O grau de detalhamento a ser utilizado
na descrição de um caso de uso
também pode variar.
Um caso de uso sucinto descreve as
interações sem muitos detalhes.
Um caso de uso expandido descreve
as interações em detalhes.
Copyright 2002, 2003 Eduardo Bezerra 171
Grau de abstração
O grau de abstração de um caso de uso diz respeito à existência ou não de menção à tecnologia a ser utilizada na descrição deste caso de uso.
Um caso de uso essencial não faz menção à tecnologia a ser utilizada.
Um caso de uso real apresenta detalhes da tecnologia a ser utilizada na implementação deste caso de uso .
172
Grau de abstração
1) Cliente fornece sua identificação.2) Sistema identifica o usuário.3) Sistema fornece operações disponíveis.4) Cliente solicita o saque de uma determinada quantia.5) Sistema fornece a quantia desejada da conta do Cliente.6) Cliente recebe dinheiro e recibo.
Exemplo de descrição essencial (e numerada):
Copyright 2002, 2003 Eduardo Bezerra 173
Cenários
Um caso de uso tem diversas maneiras de ser realizado.
Um cenário é a descrição de uma das maneiras pelas quais um caso de um pode ser realizado.
Um cenário também é chamado de instância de um caso de uso.
Normalmente há diversos cenários para um mesmo um caso de uso.
Úteis durante a modelagem de interações.
174
Cenários
• Um Cliente telefona para a empresa.
• Um Vendedor atende ao telefone.
• Cliente declara seu desejo de fazer um pedido de compra.
• Vendedor pergunta a forma de pagamento.
• Cliente indica que vai pagar com cartão de crédito.
• Vendedor requisita o número do cartão, a data de expiração e o
endereço de entrega.
• Vendedor pede as informações do primeiro item.
• Cliente fornece o primeiro item.
• Vendedor pede as informações do segundo item.
• Cliente fornece o segundo item
• Vendedor pede as informações do terceiro item
• Cliente e informa o terceiro item.
• Vendedor informa que o terceiro item está fora de estoque.
• Cliente pede para que O Vendedor feche o pedido somente com os dois
primeiros itens.
• Vendedor fornece o valor total, a data de entrega e uma
identificação do pedido.
• Cliente agradece e desliga o telefone.
• Vendedor contata a Transportadora para enviar o pedido de O Cliente.
Copyright 2002, 2003 Eduardo Bezerra 176
Atores
Elemento externo que interage com o sistema. “externo”: atores não fazem parte do sistema.
“interage”: um ator troca informações com o sistema.
Casos de uso representam uma seqüência de interações entre o sistema e o ator. no sentido de troca de informações entre eles.
Normalmente um agente externo inicia a seqüência de interações com o sistema, ou um evento acontece para que o sistema responda.
177
Atores
Categorias de atores: pessoas (Empregado, Cliente,
Gerente, Almoxarife, Vendedor, etc);
organizações (Empresa Fornecedora, Agência de Impostos, Administradora de Cartões, etc);
outros sistemas (Sistema de Cobrança, Sistema de Estoque de Produtos, etc).
equipamentos (Leitora de Código de Barras, Sensor, etc.)
178
Atores
Um ator corresponde a um papelrepresentado em relação ao sistema.
O nome dado a um ator deve lembrar o seu papel, ao invés de lembrar quem o representa.
179
Atores primários e secundários
Um ator pode participar de muitos casos de uso.
Um caso de uso pode envolver vários atores, o que resulta na classificação dos atores em primários ou secundários. Um ator primário é aquele que inicia uma
seqüência de interações de um caso de uso. Atores secundários supervisionam, operam,
mantêm ou auxiliam na utilização do sistema.
Exemplo: para que o Usuário (ator primário) requisite uma página a um Browser (sistema), um outro ator (secundário) está envolvido, o Servidor Web.
180
Relacionamentos
Casos de uso e atores não existem sozinhos. Podem haver relacionamentos entre eles.
A UML define diversos tipos de relacionamentos no modelo de casos de uso: Comunicação
Inclusão
Extensão
Generalização
181
Relacionamento de comunicação
Representa a informação de quais atores estão associados a que casos de uso
O fato de um ator estar associado a um caso de uso significa que esse ator interage (troca informações) com o sistema.
Um ator pode se relacionar com mais de um caso de uso.
É o mais comum dos relacionamentos.
182
Relacionamento de inclusão
Existe somente entre casos de uso. Analogia útil: rotina.
Em uma linguagem de programação, instruções podem ser agrupadas em uma unidade lógica chamada rotina.
Sempre que essas instruções devem ser executadas, a rotina correspondente é chamada.
Quando dois ou mais casos de uso incluem uma seqüência de interações comum, esta seqüência comum pode ser descrita em um outro caso de uso.
183
Relacionamento de inclusão
Este caso de uso comum: evita a descrição de uma mesma seqüência
de interações mais de uma vez e torna a descrição dos casos de uso mais
simples.
Um exemplo: considere um sistema de controle de transações bancárias. Alguns casos de uso deste sistema são Obter Extrato, Realizar Saque e Realizar Transferência. Há uma seqüência de interações em
comum: a seqüência de interações para validar a senha do cliente.
184
Relacionamento de extensão
Utilizado para modelar situações onde diferentes seqüências de interações podem ser inseridas em um caso de uso.
Sejam A e B dois casos de uso. Um relacionamento de extensão de B para
A indica que um ou mais dos cenários de A podem incluir o comportamento especificado por B.
Copyright 2002, 2003 Eduardo Bezerra 185
Relacionamento de
generalização Relacionamento no qual o reuso é mais
evidente.
Este relacionamento permite que um caso de uso (ou um ator) herde características de um caso de uso (ator) mais genérico.
O caso de uso (ator) herdeiro pode especializar o comportamento do caso de uso (ator) base.
Pode existir entre dois casos de uso ou entre dois atores.
Copyright 2002, 2003 Eduardo Bezerra 186
Relacionamento de
generalização Na generalização entre casos de uso,
sejam A e B dois casos de uso. Quando B herda de A, as seqüências de
comportamento de A valem também para B. Quando for necessário, B pode redefinir as
seqüências de comportamento de A. Além disso, B participa em qualquer
relacionamento no qual A participa.
Vantagem: comportamento do caso de uso original é reutilizado pelos casos de uso herdeiros. Somente o comportamento que não faz sentido
ou é diferente para um herdeiro precisa ser redefinido.
Copyright 2002, 2003 Eduardo Bezerra 188
Diagrama de casos de uso (DCU)
Representa graficamente os atores, casos de uso e relacionamentos entre os elementos.
Tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema.
Uma espécie de “diagrama de contexto”. Apresenta os elementos externos de um
sistema e as maneiras segundo as quais eles as utilizam.
Copyright 2002, 2003 Eduardo Bezerra 189
Notação
A notação para um ator em um DCU é a figura de um boneco com o nome do ator definido abaixo desta
figura.
Cada caso de uso é representado por uma elipse. O nome do caso de uso é posicionado abaixo
ou dentro da elipse.
Um relacionamento de comunicação é representado por um segmento de reta ligando ator e caso de uso.
Pode-se também representar a fronteira do sistema em um diagrama de casos de uso.
Copyright 2002, 2003 Eduardo Bezerra 190
Exemplo (Notação)
Reservar Livro
Usuário
AtorCaso de uso
Relacionamentode comunicação
Copyright 2002, 2003 Eduardo Bezerra 191
Exemplo (Notação)
Sistema de Vendas de
Livros por Correio
Cliente
Vendedor
Empresa Transportadora
Realizar Pedido
Copyright 2002, 2003 Eduardo Bezerra 192
Notação
Os relacionamentos de inclusão,extensão e herança são representados por uma seta direcionada de um caso de uso para outro.
A seta (tracejada) de um relacionamento de inclusão recebe o estereótipo <<inclui>>.
A seta (tracejada) de um relacionamento de extensão recebe o estereótipo <<estende>>.
A seta (sólida) de um relacionamento de herança não recebe estereótipo.
Copyright 2002, 2003 Eduardo Bezerra 193
Notação
Realizar Saque
Cliente
FornecerIdentificação
«inclui»
«inclui»
RealizarTransferência
Obter Extrato
«inclui»
Copyright 2002, 2003 Eduardo Bezerra 194
Notação
Editar Documento
Escritor
Corrigir Ortografia
Substituir Texto
«estende»
«estende»
Copyright 2002, 2003 Eduardo Bezerra 195
Notação
Professor
Usuário
Solicitar Comprade Título
Reservar Livro
Devolver Livro
Copyright 2002, 2003 Eduardo Bezerra 196
Notação
Realizar Pagamento
Realizar Pagamentocom Cartão de Crédito
Realizar Pagamentocom Dinheiro
Cliente
Copyright 2002, 2003 Eduardo Bezerra 198
Identificação dos elementos do modelo
de casos de uso
Os atores e os casos de uso são identificados a partir de informações coletadas na fase de levantamento de requisitos do sistema. Durante esta fase, os analistas devem
identificar as atividades do negócio relevantes ao sistema a ser construído.
Não há uma regra geral que indique quantos casos de uso são necessários para descrever completamente um sistema.
A quantidade de casos de uso a ser utilizada depende completamente da complexidade do sistema.
Copyright 2002, 2003 Eduardo Bezerra 199
Identificação de atores
Fontes e os destinos das informações a serem processadas são atores em potencial. uma vez que um ator é todo elemento externo que
interage com o sistema.
O analista deve identificar: as áreas da empresa que serão afetadas ou
utilizarão o sistema.
fontes de informações a serem processadas e os destinos das informações geradas pelo sistema.
Copyright 2002, 2003 Eduardo Bezerra 200
Identificação de atores
Perguntas úteis: Que órgãos, empresas ou pessoas irão
utilizar o sistema?
Que outros sistemas irão se comunicar com o sistema a ser construído?
Alguém deve ser informado de alguma ocorrência no sistema?
Quem está interessado em um certo requisito funcional do sistema?
O desenvolvedor deve ainda continuar a pensar sobre atores quando passar para a identificação dos casos de uso.
Copyright 2002, 2003 Eduardo Bezerra 202
Construção do diagrama de casos de
uso
Os diagramas de casos de uso devem servir para dar suporte à parte escrita do modelo, fornecendo uma visão de alto nível.
Quanto mais fácil for a leitura do diagrama representando casos de uso, melhor.
Se o sistema sendo modelado não for tão complexo, pode ser criado um único DCU.
Este diagrama permite dar uma visão global e de alto nível do sistema.
Copyright 2002, 2003 Eduardo Bezerra 203
Construção do diagrama de casos de
uso
Em sistemas complexos, representar todos os casos de uso do sistema em um único DCU talvez o torne um tanto ilegível.
Alternativa: criar vários diagramas, de acordo com as necessidades de visualização. Diagrama exibindo um caso de uso e seus
relacionamentos;
Diagrama exibindo todos os casos de uso para um ator;
Diagrama exibindo todos os casos de uso a serem implementados em um ciclo de desenvolvimento.
Copyright 2002, 2003 Eduardo Bezerra 204
Documentação dos casos de uso
A descrição do modelo deve ser mantida no nível mais simples possível...
PROXIMA AULA!!!
APRESENTAÇÃO DE UM CASO DE
USO
Padaria
Supermercado
Escola
Copyright 2002, 2003 Eduardo Bezerra 205