110
Alessandro Almeida | www.alessandroalmeida.com

Engenharia de Software I - Aula 15

Embed Size (px)

Citation preview

Page 1: Engenharia de Software I - Aula 15

Alessandro Almeida | www.alessandroalmeida.com

Page 2: Engenharia de Software I - Aula 15

Prova 1: Dia 9 de outubro

Page 3: Engenharia de Software I - Aula 15
Page 4: Engenharia de Software I - Aula 15

Aula 2

Page 5: Engenharia de Software I - Aula 15

Disciplina de engenharia cujo foco está em todos os aspectos da produção de software, desde os estágios iniciais da especificação do sistema até sua manutenção, quando o sistema já está sendo usado.

Page 6: Engenharia de Software I - Aula 15

...todos os aspectos da produção de software...

Não apenas processos “técnicos”, mas também as atividades de gerenciamento de projeto, por exemplo.

Page 7: Engenharia de Software I - Aula 15

Aula 2

Page 8: Engenharia de Software I - Aula 15

5%

45%

47%

3%

9%

43%

45%

3%

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

Sempre Na maioria das vezes Poucas vezes Nunca

2011

2012

Page 9: Engenharia de Software I - Aula 15

4%

34%

55%

7% 5%

33%

55%

7%

0%

10%

20%

30%

40%

50%

60%

Sempre Na maioria das vezes Poucas vezes Nunca

2011

2012

Page 10: Engenharia de Software I - Aula 15

1%

23%

64%

12%

3%

23%

61%

13%

0%

10%

20%

30%

40%

50%

60%

70%

Sempre Na maioria das vezes Poucas vezes Nunca

2011

2012

Page 11: Engenharia de Software I - Aula 15

0%

15%

74%

11%

2%

16%

69%

13%

0%

10%

20%

30%

40%

50%

60%

70%

80%

Sempre Na maioria das vezes Poucas vezes Nunca

2011

2012

Page 12: Engenharia de Software I - Aula 15

Não cumprimento dos prazos Comunicação Escopo não definido adequadamente Mudanças de escopo constantes Estimativas incorretas Entre outros...

Page 13: Engenharia de Software I - Aula 15

Gerente de Projeto (na vida real)

Page 14: Engenharia de Software I - Aula 15

Agora, a principal motivação para pensarmos em Engenharia de Software:

E na minha empresa, como funcionam os projetos de desenvolvimento ou manutenção

de software?

Enfrentamos problemas com prazo, custo, qualidade, escopo, satisfação do cliente, etc.?

Page 15: Engenharia de Software I - Aula 15

Aulas 3, 4 e 5

Page 16: Engenharia de Software I - Aula 15

O que posso considerar ao definir um processo que atenda minhas demandas de Engenharia

de Software?

Page 17: Engenharia de Software I - Aula 15

Etc... mps.Br

PMBoK

BABoK

SWEBoK

Extreme Programming

SCRUM

RUP

EUP OpenUP

CMMI

Page 18: Engenharia de Software I - Aula 15
Page 19: Engenharia de Software I - Aula 15

Qual é o significado do acrônimo?

Page 20: Engenharia de Software I - Aula 15

Capability Maturity Model Integration®

Fontes: Houaiss e Merriam-Webster

Page 21: Engenharia de Software I - Aula 15

Capability Maturity Model Integration®

1 : the quality or state of being capable 2 : poder de produção, de execução; rendimento máximo 3 : qualidade ou condição de capaz

Fontes: Houaiss e Merriam-Webster

Page 22: Engenharia de Software I - Aula 15

Capability Maturity Model Integration®

1 : the quality or state of being mature 2 : estado, condição (de estrutura, forma, função ou organismo) num estágio adulto; condição de plenitude em arte, saber ou habilidade adquirida 3 : estado ou condição de pleno desenvolvimento

Fontes: Houaiss e Merriam-Webster

Page 23: Engenharia de Software I - Aula 15

Primeiro você torna-se capaz de realizar algo, depois você adquire a maturidade

Sou capaz!

Aprendi, treinei e sei executar...

Possuo maturidade!

Sou capaz e tenho experiência...

Page 24: Engenharia de Software I - Aula 15

Capability Maturity Model Integration®

1 : simplificação da realidade 2 : representação em escala reduzida de objeto, a ser reproduzida em dimensões normais; maquete

Fontes: Houaiss e Merriam-Webster

Page 25: Engenharia de Software I - Aula 15
Page 26: Engenharia de Software I - Aula 15
Page 27: Engenharia de Software I - Aula 15

Compilação de “boas práticas” no processo de diversas empresas de software

Mostra O QUÊ fazer, e não COMO fazer Práticas distribuídas em “áreas de processo”

Área de Processo = PA (Process Area)

Page 28: Engenharia de Software I - Aula 15

Agrupamento de práticas comuns de uma determinada “disciplina”.

Onde fica o “O que fazer?”.

Por exemplo: Project Planning (PP)

Page 29: Engenharia de Software I - Aula 15

Modelos de maturidade mantidos pelo SEI (Software Engineering Institute)

http://www.sei.cmu.edu/cmmi

Abrangem todo ciclo de vida para o desenvolvimento (CMMI-DEV) e operação de software (CMMI-SVC)

Também aborda projetos de aquisição (CMMI-ACQ)

Page 30: Engenharia de Software I - Aula 15

Sponsor:

DoD (U.S. Department of Defense)

Versão 1.3 publicada em novembro de 2010

Page 31: Engenharia de Software I - Aula 15

Para quem não quer gastar...

Page 32: Engenharia de Software I - Aula 15

Para quem quer investir...

Page 33: Engenharia de Software I - Aula 15
Page 34: Engenharia de Software I - Aula 15

CMMI Model

Foundation

CMMI-DEV CMMI-ACQ

CMMI-SVC

Fonte: -http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html

Page 35: Engenharia de Software I - Aula 15

Representações

Contínua (Capability Levels)

Por estágio (Maturity Levels)

Page 36: Engenharia de Software I - Aula 15

Exemplo:

Page 37: Engenharia de Software I - Aula 15

Exemplo:

Page 38: Engenharia de Software I - Aula 15

Processos ad hoc Initial

Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)

Managed

Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER)

Defined

Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed

Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

Page 39: Engenharia de Software I - Aula 15

Processos ad hoc Initial

Configuration Management (CM) Measurement and Analysis (MA) Work Monitoring and Control (WMC) Work Planning (WP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Service Delivery (SD) Supplier Agreement Management (SAM)

Managed

Capacity and Availability Management (CAM) Decision Analysis and Resolution (DAR) Incident Resolution and Prevention (IRP) Integrated Work Management (IWM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Risk Management (RSKM) Service Continuity (SCON) Service System Development (SSD) Service System Transition (SST) Strategic Service Management (STSM)

Defined

Organizational Process Performance (OPP) Quantitative Work Management (QWM) Quantitatively Managed

Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

Page 40: Engenharia de Software I - Aula 15

Processos ad hoc Initial

Acquisition Requirements Development (ARD) Agreement Management (AM) Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Solicitation and Supplier Agreement Development (SSAD)

Managed

Acquisition Technical Management (ATM) Acquisition Validation (AVAL) Acquisition Verification (AVER) Decision Analysis and Resolution (DAR) Integrated Project Management (IPM) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Risk Management (RSKM)

Defined

Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed

Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

Page 41: Engenharia de Software I - Aula 15

“Certificação” e exigências de clientes propiciam o processo só para constar

Perde-se o propósito do CMMI

O CMMI é totalmente “orientado a evidências”

Embora contemple todo o ciclo de vida, há pouca preocupação com gestão de pessoas

Para tentar resolver: People CMM

Alto custo de implementação

Page 42: Engenharia de Software I - Aula 15
Page 43: Engenharia de Software I - Aula 15

Melhoria de processo do software brasileiro

www.softex.br/mpsbr

Criado no final de 2003 Foco em micro, pequenas e médias empresas

Custo de implementação e avaliação menor

Aproximadamente, 380 empresas já foram avaliadas no modelo (mais de 70% são PME)

Page 44: Engenharia de Software I - Aula 15

Base Técnica para a definição do mps.Br

ISO/IEC 12207: Ciclo de Vida de processos de software

ISO/IEC 15504: Avaliações de processos de software

CMMI-DEV, 1.2

Níveis:

G (Parcialmente Gerenciado) até A (Em otimização)

Page 45: Engenharia de Software I - Aula 15
Page 46: Engenharia de Software I - Aula 15
Page 47: Engenharia de Software I - Aula 15

Reconhecido internacionalmente Consolidado (quase 20 anos) Dois tipos de abordagens para

implementação

Contínua

Estágio

Empresas no mundo inteiro utilizam Modelo abrangente

DEV, SVC e ACQ

Page 48: Engenharia de Software I - Aula 15

Modelo brasileiro

A questão do idioma influencia muito

7 níveis de maturidade

Os resultados podem ser visualizados no “curto prazo”

Custo baixo

Comparado com o CMMI

Foca a realidade brasileira

Micros, pequenas e médias empresas

Page 49: Engenharia de Software I - Aula 15

Não se esqueçam que ....

são compilação de “boas práticas”

mostram O QUÊ fazer, e não COMO fazer

Page 50: Engenharia de Software I - Aula 15

“Depende...” Tudo depende da MOTIVAÇÃO.

Qual é o nosso objetivo?

Quem é o nosso cliente?

Qual é a cultura da empresa?

Etc...

Page 51: Engenharia de Software I - Aula 15

Aulas 9, 10, 11, 12, 13 e 14

Page 52: Engenharia de Software I - Aula 15

O que é?

Page 53: Engenharia de Software I - Aula 15

Entendendo DFD sem precisar consultar o livro...

Page 54: Engenharia de Software I - Aula 15

DIAGRAMA

“representação gráfica, por meio de figuras geométricas (pontos, linhas, áreas etc.), de fatos, fenômenos, grandezas, ou das relações entre eles; gráfico, esquema” (Fonte: Houaiss)

Page 55: Engenharia de Software I - Aula 15

DIAGRAMA

“representação gráfica, por meio de figuras geométricas (pontos, linhas, áreas etc.), de fatos, fenômenos, grandezas, ou das relações entre eles; gráfico, esquema” (Fonte: Houaiss)

Page 56: Engenharia de Software I - Aula 15

FLUXO

“escoamento ou movimento contínuo de algo que segue um curso” (Fonte: Houaiss)

Page 57: Engenharia de Software I - Aula 15

FLUXO

“escoamento ou movimento contínuo de algo que segue um curso” (Fonte: Houaiss)

A B C D E

Page 58: Engenharia de Software I - Aula 15

DADO

“informação relativa a um indivíduo, capaz de identificá-lo” (Fonte: Houaiss)

“informação capaz de ser processada por um computador” (Fonte: Houaiss)

Page 59: Engenharia de Software I - Aula 15

DADO

“informação relativa a um indivíduo, capaz de identificá-lo” (Fonte: Houaiss)

“informação capaz de ser processada por um computador” (Fonte: Houaiss)

Prontuário Nome do Aluno

16030364 Alessandro Rodrigues de Almeida

16030365 Raul Seixas

Page 60: Engenharia de Software I - Aula 15

O que é um Diagrama de Fluxo de Dados?

Representação gráfica que mostra o movimento das informações dentro de um sistema

Page 61: Engenharia de Software I - Aula 15
Page 62: Engenharia de Software I - Aula 15

Ferramenta de modelagem gráfica da solução

Análise Estruturada

Permite imaginar um sistema como uma rede de processos funcionais, interligados por dutos e tanques de armazenamentos de dados

Pode ser apresentado para o cliente!

Se for construído da forma correta, é claro

Page 63: Engenharia de Software I - Aula 15

Também conhecido como...

Diagrama de bolhas

DFD

Modelo de processo

Diagrama de fluxo de trabalho

Modelo funcional

“uma representação de como o sistema funciona”

Page 64: Engenharia de Software I - Aula 15

Quer ser um especialista em DFD?

Quem lembra da referência básica indicada na primeira aula?

Page 65: Engenharia de Software I - Aula 15
Page 66: Engenharia de Software I - Aula 15
Page 67: Engenharia de Software I - Aula 15
Page 68: Engenharia de Software I - Aula 15

Analisando um pouco já é possível entender Representação simples Intuitivo Na construção, lembre-se que o cliente

(usuário) é quem vai validar

Ou seja, o cara precisa entender seu desenho

Page 69: Engenharia de Software I - Aula 15

O DFD pode ser desenhado em uma página

Seu cliente vai conseguir examinar o diagrama sem se confundir!

Page 70: Engenharia de Software I - Aula 15
Page 71: Engenharia de Software I - Aula 15

Também utilizado para modelagem de processos...

Page 72: Engenharia de Software I - Aula 15

Fonte: PMBoK, 4ª Edição

Page 73: Engenharia de Software I - Aula 15

DFD ajuda!

Page 74: Engenharia de Software I - Aula 15

Mas não é A SOLUÇÃO para gerenciamento de requisitos e

modelagem da solução.

Page 75: Engenharia de Software I - Aula 15

O DFD ajuda na modelagem da solução.

Page 76: Engenharia de Software I - Aula 15

Entendendo a estrutura – Parte 1

Page 77: Engenharia de Software I - Aula 15

Primeiro componente de um DFD Mostra como uma ou mais entradas são

convertidas em saídas Normalmente, é representado por um círculo

Mas também pode ser uma elipse ou um retângulo

Exemplo:

Validar CPF

Page 78: Engenharia de Software I - Aula 15

Graficamente representado por uma seta que entra ou sai de um processo

Utilizado para mostrar o movimento de fragmentos ou de pacotes de informações de um ponto a outro do sistema

Ou seja, representa os dados em movimento

Exemplo: situação do

pedido

Page 79: Engenharia de Software I - Aula 15

Modela uma coleção de pacotes de dados em repouso

Ou seja, o banco de dados

Normalmente, o nome escolhido para identificar o depósito é o plural do nome dos pacotes transportados pelos fluxos para dentro e para fora dos depósitos

Exemplo:

Pedidos

Page 80: Engenharia de Software I - Aula 15

Representa as entidades externas com as quais o sistema se comunica

Tipicamente, é uma pessoa ou um grupo de pessoas

Mas também pode ser outro sistema com o qual o seu sistema vai se comunicar (por exemplo: B2B)

Exemplo:

Clientes

Page 81: Engenharia de Software I - Aula 15
Page 82: Engenharia de Software I - Aula 15
Page 83: Engenharia de Software I - Aula 15
Page 84: Engenharia de Software I - Aula 15
Page 85: Engenharia de Software I - Aula 15

Entendendo a estrutura – Parte 2

Page 86: Engenharia de Software I - Aula 15

1. Escolher nomes significativos para os processos, fluxos, depósitos e terminadores

2. Numerar os processos 3. Evitar DFDs complexos demais 4. Refazer o DFD tantas vezes forem

necessárias, até obter uma boa estética 5. Certificar-se de que o DFD seja

internamente consistente, além de manter a consistência com outros DFDs

Page 87: Engenharia de Software I - Aula 15

Rotular os processos de modo a identificar as funções que o sistema executa

Iniciando com um verbo no infinitivo...

Validar CPF

Page 88: Engenharia de Software I - Aula 15

Nomes não recomendados para processos: Fazer serviço

Funções diversas

Manipular entrada

Cuidar dos clientes

Processar dados

Edição geral Os nomes acima podem significar muita coisa... Além disso, demonstram que o Analista de Sistemas

não está certo de qual função está sendo executada

Page 89: Engenharia de Software I - Aula 15

Facilitam a referência ao processo

É mais fácil dizer bolha 1 em vez de Editar erros de transações e de relatórios

Facilitam a leitura no detalhamento dos DFDs

A bolha 2 será detalhada através das bolhas 2.1, 2.2 e 2.3

Page 90: Engenharia de Software I - Aula 15

Processo no primeiro nível...

Page 91: Engenharia de Software I - Aula 15

Processo no segundo nível...

Qual processo estamos detalhando?

Page 92: Engenharia de Software I - Aula 15

Um DFD deve ser prontamente compreendido, facilmente absorvido e agradável aos olhos Ou seja, não crie um DFD com diversos processos,

fluxos, depósitos e terminadores... O ideal é que o DFD se ajuste em uma folha

A4 Aprenderemos a “quebrar” o DFD em níveis (nível

0, 1 e 2)

Lembrem do exemplo anterior

Page 93: Engenharia de Software I - Aula 15

Refaça o DFD 5, 10 ou 15 vezes até que esteja...

Tecnicamente correto

Aceitável pelo seu cliente

Tão bem desenhado que você não fique constrangido em mostrá-lo aos diretores da sua empresa

Page 94: Engenharia de Software I - Aula 15

Tome cuidado com...

Poços sem fundo: Bolhas com fluxo de entrada, mas sem fluxo de saída

Page 95: Engenharia de Software I - Aula 15

Tome cuidado com...

Bolhas com geração espontânea: Bolhas com fluxo de saída, mas sem o fluxo de entrada

Page 96: Engenharia de Software I - Aula 15

Tome cuidado com...

Fluxos e processos sem rótulo: Se não conseguiu definir um nome satisfatório para o processo ou fluxo, pode ser que há algum item implícito no sistema que ainda não foi identificado

Page 97: Engenharia de Software I - Aula 15

Tome cuidado com...

Depósitos somente leitura ou somente escrita: Seu banco de dados somente recebe dados ou somente é consultado? Reveja se é assim mesmo que funciona...

Page 98: Engenharia de Software I - Aula 15

Entendendo a estrutura – Parte 3

Page 99: Engenharia de Software I - Aula 15

Nem sempre o DFD vai se ajustar em uma folha A4

Em projetos reais, o fluxo de dados é maior e mais complexo...

Difícil de entender!

O que fazer nestes casos?

“Quebrar” o DFD em níveis!

Page 100: Engenharia de Software I - Aula 15

Vantagens...

Os níveis permitem uma visão geral...

▪ Nos níveis 0 e 1 é possível compreender o diagrama sem a necessidade de entrar no detalhe dos processos, fluxos e depósitos que compõem o DFD

Os níveis permitem o entendimento gradual...

▪ Você pode apresentar um nível de cada vez

▪ Não vai se assustar e nem assustar o cliente e demais envolvidos com um diagrama complexo e extenso logo na primeira apresentação

Page 101: Engenharia de Software I - Aula 15

Vantagens...

Mantém a documentação enxuta

Garante a 3ª diretriz para elaborar um (bom) DFD: Evitar DFDs complexos demais

Page 102: Engenharia de Software I - Aula 15
Page 103: Engenharia de Software I - Aula 15
Page 104: Engenharia de Software I - Aula 15
Page 105: Engenharia de Software I - Aula 15
Page 106: Engenharia de Software I - Aula 15
Page 107: Engenharia de Software I - Aula 15

Neste exemplo, estamos detalhando somente o processo 2. Remeter Livros

Page 108: Engenharia de Software I - Aula 15

\

Page 109: Engenharia de Software I - Aula 15
Page 110: Engenharia de Software I - Aula 15

[email protected] www.slideshare.net/alessandroalmeida