Paulo F. Vasconcellos

Slides:



Advertisements
Apresentações semelhantes
Gerenciamento do escopo
Advertisements

Engenharia de Software
APSOO Aula 03.
O Processo Praxis 3.0 Processos de Software 25/03/2017
Identificando requisitos
Engenharia de Software
Empreendorismo para Computação Criando Negócios de Tecnologia
Engenharia de Software Professor Sandro de Paiva Carvalho.
RUP - Rational Unified Process
Projeto de Sistemas de Software
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
MO409 / Engenharia de Software I - 1º Semestre / Prof. Eliane 1 1ª Apresentação (A1) Modelos de Processos de Software RA: / Edson Amorina.
Processo Desenvolvimento de Software Tradicional
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
O processo de coletar os requisitos (escopo do cliente)
Implementação de Sistemas
RUP: Fluxo de Análise e Projeto
Gabriel Silva Bornia Prof. Dr. Roberto Tom Price Orientador
Testes – visão geral Vanilson Burégio.
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
FDD.
Classes e objetos Modelagem
UFRPE – Modelos de Qualidade Teresa Maciel
Rational Unified Process
José Roberto Blaschek Gerência do Escopo José Roberto Blaschek.
Metodologia de Desenvolvimento de Software – RUP 2. Requisitos
Paulo Vasconcellos pfvasconcellos.eti.br Uma Visão Prática.
Desafios do desenvolvimento de software
Prof.Alfredo Parteli Gomes
Visão Geral PRO.NET.
Visão Geral do RUP.
Fundamentos de Engenharia de SW
Cap 2 – Processo de Software
Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
Fase de Elaboração: Fluxo de Requisitos
Processo Praxis – Fase de Concepção
Gerenciamento do Escopo: principais conceitos
Processos de Engenharia de Requisitos
Oficina Mecânica TADS 2011.
GESTÃO DE PROJETOS Aula 5 1.
Prof. Alexandre Vasconcelos
Planejamento e Gerenciamento
Engenharia de Software
Introdução e Fundamentos Engenharia de Requisitos
Gerência de Configuração - GC
Técnicas e Projeto de Sistemas
Fase de Concepção (Início, Planejamento)
PSBD II Projeto de Sistemas de Banco de Dados II
Levantamento de Requisitos
GESTÃO DE PROJETOS DE MANUTENÇÃO
Especificação em Projeto de Sistemas
Levantamento de Requisitos
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Gerência de comunicação
Capturando Requisitos com Use Cases Disciplina: Estudo do RUP Autor: Tiago Lima Massoni Orientacao: Augusto Sampaio Paulo Borba.
GERENCIAMENTO DE PROJETOS DE T.I
Processos de Software.
Processos de Software.
Fase de Concepção Levantamento de Requisitos, Organização de Requisitos, Planejamento dos Ciclos Iterativos.
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
Fase de Concepção (Início, Planejamento)
Requisitos Não funcionais
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
ISO9001:2000 para Software Professor: Alexandre Vasconcelos Equipe: Amanda Pimentel Börje Karlsson Danielly Karine Erika Pessoa Jorge Cavalcanti Jose Edson.
/ de Julho de UFPE - Universidade Federal de Pernambuco CIn - Centro de Informática Pós-Graduação em Ciência da Computação Tópicos Avançados.
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
Elicitação de Requisitos Análise Orientada a Objetos Prof. Wolley W. Silva.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Uma Visão Prática.
Transcrição da apresentação:

Paulo F. Vasconcellos

Programação Requisitos (Engenharia de) –RUP, OpenUP, BABoK... Gerenciando Requisitos (e Mudanças) Entendendo os Requisitos Desenvolvendo Requisitos Analisando, Validando e Priorizando Viabilizando o Projeto

Objetivos Entender os Requisitos a disciplina Engenharia de Requisitos e os Métodos e Processos que a formam. Quem executa O que executa / o que gera Como

A Oficina 5 Grupos de 10 pessoas. 1 Monitor para cada grupo. Exercícios (6) terão limite de tempo. O problema de negócio é relativamente simples. Vamos nos concentrar no processo, nos métodos e técnicas. Ênfase: técnicas de coleta, descoberta, análise e especificação de requisitos.

Flashback

Oficina: O Problema Grande rede de locadoras de DVD's Quer expandir base de clientes e, consequentemente, o faturamento Sem aumentar o número de lojas Imagina um serviço de locação via web

Alguns fatos 50 Lojas (Sampa e interior) 25 mil clientes ativos R$ 5 é o valor médio da locação R$ 1,5 milhão é o faturamento mensal 3 DVD's / cliente / semana As lojas são caras e franquia não é alternativa

Objetivos 250 mil clientes, em todo o Brasil (existem mais de 10 milhões de DVD players por aí) Multiplicar por 10 o faturamento Em 1 ano Receita recorrente: Mensalidade Plano de 12 DVD's/mês = R$ 60 (2 lotes com 6 DVD's) Não há taxa de permanência Mas cliente só recebe novo lote após devolução

Estratégia Pontos fortes –Acervo: 50+ mil títulos –Qualidade do Atendimento (personalizado) Oportunidade: Serviço Web é inédito Ameaça: 'canibalização' das lojas Ponto fraco: preço Proposição de Valor: APRISIONAMENTO

Engenharia de Requisitos

Tipos de Processos

Cascata (7 Quedas ou Clássico)

Iterativo & Incremental

Iterativo e Incremental

RUP (Rational Unified Process)

RUP: Requisitos

OpenUP (antes, OpenUP/Basic)

RUP / OpenUP

Equipe de Projeto

RUP, OpenUP e o AN

BABoK: Disciplinas

Engenharia de Requisitos: A Disciplina

Gerenciando Requisitos

Gerenciamento de Mudanças

Antecipando Mudanças e Gerenciando Riscos Estratégia mal definida, difundida ou executada; Processos Doentes; Usuários: dúvidas ou decisões fracas; Requisitos não satisfazem plenamente o checklist.

Controlando Requisitos

Iterativo e Incremental

Entendendo os Requisitos

Definindo Requisitos Uma funcionalidade específica; Uma propriedade geral do sistema; Uma restrição específica do sistema; ou Uma restrição ao desenvolvimento do sistema.

Tipos de Requisitos Requisitos de Negócio Requisitos de Usuário Requisitos Funcionais Requisitos Não-funcionais

Estruturando Requisitos

Estruturando Requisitos II

Ponto de Vista Estratégico Tático Operacional Técnico

Grau de Importância Fundamental Importante Opcional

Relações entre Requisitos Dependente Complementar Substituto Conflitante

Status Pendente Aprovado Recusado Substituído Implementado Verificado Excluído

Estruturando Requisitos

–De 25 mil para 250 mil clientes, em todo o Brasil –Multiplicar por 10 o faturamento –Em 1 ano –Receita recorrente: Mensalidade

Desenvolvendo Requisitos

UML: 5 Visões

Casos de Uso – 4 Dimensões Propósito: Requisitos ou histórias? Conteúdo: Papo consistente, Contraditório ou Formal? Pluralidade: Um ou Vários Cenários? Estrutura: Não estruturado, Semi-formal ou Formal?

Casos de Uso – Motivações: Descobrir e descrever os requisitos funcionais de um sistema; Fornecer uma clara e consistente visão do que o sistema deve realizar; Servir como a base que irá nortear todos os testes do sistema; Permitir o rastreamento total entre requisitos e artefatos construídos.

Diagramas de Casos de Uso

Especificações de Casos de Uso [Número] e Nome do Caso de Uso: Processo de Negócio: [Resumo:] Objetivos: –1... –2... Ator Principal: Fato Gerador (Evento de Negócio): Fluxo Principal: –1... – –3... Regras de Negócio: [Pré e pós-condições:] [Extensões / Fluxos Alternativos:] [Requisitos complementares:]

Estruturando Requisitos III

Por onde começar?

Técnica: Entrevistas BABoK: –Maneira sistemática de levantar informações de uma pessoa ou grupo –De maneira formal ou informal –Perguntando questões relevantes e documentando as respostas. Pró: Objetividade Contra: Falta de pontos de vista divergentes Indicações: –1 ~6 pessoas –Pauta e duração pré-determinados

Start me Up! Coleta de Requisitos A Forma Tradicional: Entrevista Tempo Limite: 30 Minutos Monitor = Dono do Negócio ou seja, [Ponto de Vista = Estratégico] Grupo: –Todos revezam na função do AN que conduz a entrevista –Todos devem registrar os achados Foco: Visão Geral do PROBLEMA

Entrevistas: Atenção! Entrevistado titubeou? Cada derrapada é um risco para o projeto. Se 1ª Entrevista: 2km de extensão – 2cm de profundidade. Temos todos os requisitos do usuário? Perguntando de outra forma: Temos todos os Casos de Uso? Vamos validar?

Pior Cenário

Aprendendo

Quente X Frio [EUP – Avaliando Canais]

Quente x Frio [Avaliando Técnicas]

Socialização Entrevistas Workshop / Brainstormings (aka Face-to-face at whiteboard) (aka Toró de Parpite)

Quente x Frio [Avaliando Técnicas]

Técnica: Brainstorming BABoK: –Uma excelente forma para levantar idéias em torno de uma área específica. –O brainstorming estruturado produz uma série de idéias sobre qualquer questão central. Pró: liberdade de criação. Contra: perda do foco. Indicações: –Usuário titubeante; –Fases iniciais de um projeto; –Projeto realmente exige altas doses de criatividade. Cuidado: Criatividade depende da platéia!

Digging in the Dirt

Técnica: BRAINSTORMING Tempo limite: 30 minutos 4 regrinhas: –Produza o maior número de idéias; –De maneira selvagem; –Trabalhe as idéias dos outros; e –Não julgue!

Técnica: Brainstorming BABoK: –Uma excelente forma para levantar idéias em torno de uma área específica. –O brainstorming estruturado produz uma série de idéias sobre qualquer questão central. Pró: liberdade de criação. Contra: perda do foco. Indicações: –Usuário titubeante; –Fases iniciais de um projeto; –Projeto realmente exige altas doses de criatividade. Cuidado: Criatividade depende da platéia!

O Passo Esquecido

Quem acerta na primeira? As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção - Frank Lloyd Wright A mais importante ferramenta do físico é sua cesta de lixo. - Albert Einstein As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção - Frank Lloyd Wright A mais importante ferramenta do físico é sua cesta de lixo. - Albert Einstein

O Espaço do Problema [Scott Berkun]

Melhor Cenário

Quente x Frio [Avaliando Técnicas]

Técnica: Workshop (ou JAD – Joint Application Development) BABoK: –Forma estruturada de captura de requisitos. –Utilizada para descobrir, definir e priorizar requisitos. –Indicada para fechar o escopo do projeto. –Quando bem executado, é uma das melhores técnicas para o desenvolvimento ágil de requisitos de alta qualidade. Pró: agilidade na tomada de decisões. Contra: perda do foco. Indicações: –Número de usuários entre 6 e 20. Cuidado: Pauta e duração pré-fixados.

I Still Haven't Found what I'm Looking for Técnica: WORKSHOP Tempo limite: 30 minutos Objetivos: –Agrupar Idéias –Desenvolver Requisitos Funcionais Caso: Alugar DVD Atenção: Atributos dos Requisitos

Onde Estamos?

Revendo o Principal Artefato

Caso de Uso #1: Alugar DVD Processo: Locação Fonte(s) / Ponto(s) de Vista: Ator principal: Cliente Objetivos: – a) Montar lote de DVD's (selecionar títulos) – b) Programar entrega dos lotes Importância: FUNDAMENTAL Pré-condição: Cliente deve estar cadastrado.

Caso de Uso #1: Alugar DVD Fluxo (cenário) Principal: – 1. Cliente se identifica – 2. Seleciona seção – 3. Escolhe os títulos – 4. Organiza lotes para entrega – 5. Confirma operação

Caso de Uso #1: Alugar DVD Fluxos (cenários) alternativos (extensões): – 2a. Cliente pede sugestões – 2b. Cliente recupera lista prévia Observações: – 2a é IMPORTANTE – 2b é FUNDAMENTAL

Caso de Uso #1: Alugar DVD Regras de Negócio: – Número de títulos por lote é limitado pelo plano contratado. – Se cliente estiver com 2 mensalidades em atraso, ele deve ser informado que entrega do lote é condicionada ao pagto do débito.

Caso de Uso #1: Alugar DVD Requisitos Complementares: – c1. Interface deve ser personalizada para o cliente [FUNDAMENTAL] – c2. Sempre apresentar lista de sugestões e lançamentos. [IMPORTANTE] – c3. Oferecer busca de títulos por nome, diretor/ator e tipo. [FUNDAMENTAL] – c4. Tela deve ser simples e rápida. (1 clique por título). [FUNDAMENTAL]

Revendo o Principal Artefato

Revendo o principal Artefato

Técnica: Prototipação BABoK: –Quando utilizada como técnica para coleta de requisitos, visa a elaboração dos requisitos de interface. Pró: Redução do vapor que é o software. Contra: Alto risco de criatividade demais. Indicações: –Toda interface crítica do projeto; –Clientes muito inseguros. Atenção: Requisitos devem ser formalizados! Observação: pode ser utilizada como técnica auxiliar em workshops e brainstormings.

Prototipação (Storyboards)

Finish what ya Started Técnica: Prototipação Tempo Limite: 30 minutos Objetivos: –Detalhar requisitos funcionais –Validar requisitos No grupo: –Monitor = Dono do negócio –1 designer –1 AN conduzindo o trabalho –Demais integrantes devem detalhar, validar e registrar os requisitos

Outras Técnicas: Internalização Observação –Ativo –Passivo Engenharia Reversa –Caixa Preta –Caixa Branca Pesquisa –Questionários –Versões de Testes (aka The Google Way)

Quente x Frio [Avaliando Técnicas]

Meet in the Middle

Qualidades dos Bons Requisitos Completo Correto Viável Necessário Priorizado Não Ambíguo Verificável

Características dos Bons Casos de Uso (e das User Stories) Independentes Negociáveis Valiosos para Usuários e Clientes Estimáveis Pequenos Testáveis

Definindo Prioridades Fundamental Importante Opcional Custo de implementação Prazo para implementação Facilidade da implementação técnica Facilidade da implementação no negócio Atendimento de algum requerimento legal, regulatório ou contratual

Definindo Prioridades PrioridadeDificuldade Técnica Grau de Importância Caso de UsoAtor Simples Médio Complexo Muito Complexo Um pesadelo!

Definindo Prioridades

Dificuldade Técnica Avaliação da Equipe Pontos por Caso de Uso

Pontos por Caso de Uso (Contagem de Atores) 3Pessoas invocando o caso de uso através de uma interface gráfica. Complexo 2Pessoas utilizando uma interface texto ou um outro sistema se comunicando através de algum protocolo. Médio 1Outro sistema se comunicando através de uma API (Application Programming Interface). Simples PontosDescriçãoAvaliação

Pontos por Caso de Uso (Contagem de Casos de Uso) 15Mais de 8 cenários.Complexo 10Entre 4 e 8 cenários.Médio 5Menos de 4 cenários ou caminhos de execução. Simples PontosDescriçãoAvaliação

Pontos por Caso de Uso Contagem por Pontos de Caso de Uso (UUCP) não ajustados (# Atores X Pontos) + (# Casos X Pontos) U U C P

Pontos por Caso de Uso Fator de Ajuste 20% - Tecnologia OU Equipe nova 40% - Tecnologia E Equipe novas 100% - Tecnologia E Equipes novas E o Cliente é um mala

Pontos por Caso de Uso Calculando o Esforço X (total de pontos obtido no cálculo anterior) Multiplicamos X por 20 horas! ou 24 ou 36 ou 48 ou 16...

Murder by Numbers Analisar e Priorizar Requisitos Tempo Limite: 20 minutos Objetivos: –Analisar Requisitos –Estimar e Priorizar Requisitos –Fechar 1ª versão do escopo

Cabe tudo num Caso de Uso?

Casos de Uso e Documentos Complementares

O Grande Documento [Cockburn / Robertson] Capítulo 1: Objetivos e Escopo –Objetivos do Projeto –Stakeholders –Escopo / fora do escopo Capítulo 2: Glossário Capítulo 3: Os Casos de Uso –Atores e respectivos objetivos –Casos de Uso de Negócio –Casos de Uso de Sistema

O Grande Documento [Cockburn / Robertson] Capítulo 4: Tecnologia –A Tecnologia que será utilizada –Integração com outros sistemas Capítulo 5: Outros Requisitos –Processo de Desenvolvimento –Regras de Negócio –Performance –Operações, Segurança e Documentação –Uso e Usabilidade –Manutenção e Portabilidade –Não resolvidos ou negados Capítulo 6: Questões Legais, Políticas e Organizacionais

Viabilizando o Projeto

Definindo o Escopo

O Documento de Visão [Berkun: Insanamente Simples]

O Documento de Visão Berkun: Insanamente Simples

O Documento de Visão Características Básicas Simples Guiado pelos Objetivos Consolidado Inspirador Memorável

Estrutura Básica Problemas / Oportunidades –Descrição resumida Destacar processos de negócio –Apresentação dos stakeholders Solução(ões) –Breve descrição Relacionar com problemas –Estimativas Iniciais –Suposições e Dependências –Idéias para Versões Futuras

Zabriskie Point Desenvolver o Documento de Visão Tempo limite: 15 minutos! Dá um tempo! Uma página só! Agora é competição: –Simples –Guiado pelos Objetivos –Consolidado –Inspirador –Memorável

ops... it's what the business needs!

O Livro: É o Negócio, Beócio Garantia de Atualização Versão Eletrônica (até versão 1.0) Previsão de Lançamento: Março/2008 Sua participação é fundamental! – –

Bibliografia Recomendada Software Requirements Karl Wiegers – MS Press (1999) More About Software Requirements Karl Wiegers – MS Press (2006) Requirements-Led Project Management Suzanne e James Robertson – Addison-Wesley (2005) Writing Effective Use Cases Alistair Cockburn – Addison-Wesley (2000) Requirements Engineering Ian Sommerville e Pete Sawyer – Wiley (1997) Agility and Discipline Made Easy: Practices from OpenUP and RUP Per Kroll e Bruce MacIsaac – Addison-Wesley (2006) The Art of Project Management Scott Berkun – OReilly (2005)

Na Web IIBA – International Institute of Business Analysis BPM Forum UML-BR Business Analysis Insight

Créditos & Débitos Tks! –Tempos Real Eventos –BPM Forum / UML-BR / CMM-BR Apresentação liberada sob licença Creative Commons (by+sa) 2.5 Brasil

O QUE PRECISA SER FEITO? Skype:pfvasconcellos