Prof. Gilmar Aquino de software.pdf · Introdução à Engenharia de Software. Modelos de Ciclo de Vida de Software. Produto de Software. Técnicas de ... O arquiteto de informação,

Prof. Gilmar Aquino

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)

O papel evolutivo do Soft.

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.

Curva de banheira / Hardware

Curvas idealizada

Curvas Real

Curvas Real com mudanças

Segundo Pressman Software não se desgasta mas sim deteriora.

O produto Sistema

Sistema

Software Hardware

RedesBanco de Dados

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.

Custo da mudança

Custo da mudança

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.

Processo de Software

Pode ser complexo.

Requisitos...

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.

Ciclo vida Clássico

Segundo Pressman modelo cascata

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

Aula 3

Protótipo;

Processo de prototipação;

Atividade;

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

Protótipos

Protótipos

Balsamiq Mockups

Processo de prototipação

Processo de prototipação em

sistemas

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.

Exemplos:

Exemplos:

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;

Aula 4

Apresentação de protótipos.

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.

http://www.axure.com/

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.

Aula 5

Ciclo de Vida Espiral;

Requisitos Funcionais e não Funcionais;

Técnica de Requisitos.

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

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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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 .


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.


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;


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.


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.


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.


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.


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?


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


Concluir?

Viabilidade do projeto

A alternativa preferida

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).

Custo de um Sistema XYZ




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.

Aula 8

Gerenciamento de Projetos

Qualidade de Software


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.


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.


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.


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.


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)


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 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.


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


• 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;


– 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.


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.


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.


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.


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.


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

Ciclo de Vida

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

Aula 9

Caso de Uso (UML)

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.


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.


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.


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.


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):


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.

Aula 10

Continuação.........


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.


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.


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.



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.


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.


Exemplo (Notação)

Reservar Livro

Usuário

AtorCaso de uso

Relacionamentode comunicação


Exemplo (Notação)

Sistema de Vendas de

Livros por Correio

Cliente

Vendedor

Empresa Transportadora

Realizar Pedido


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.


Notação

Realizar Saque

Cliente

FornecerIdentificação

«inclui»

«inclui»

RealizarTransferência

Obter Extrato

«inclui»


Notação

Editar Documento

Escritor

Corrigir Ortografia

Substituir Texto

«estende»

«estende»


Notação

Professor

Usuário

Solicitar Comprade Título

Reservar Livro

Devolver Livro


Notação

Realizar Pagamento

Realizar Pagamentocom Cartão de Crédito

Realizar Pagamentocom Dinheiro

Cliente



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.


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.


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.

Quais são os atores de uma??

Padaria

Supermercado

Escola



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.


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.


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


Aula 11

Apresentação alunos

Documents

Prof. Gilmar Aquino de software.pdf · Introdução à Engenharia de Software. Modelos de Ciclo de Vida de Software. Produto de Software. Técnicas de ... O arquiteto de informação,