Slides da 24ª aula da disciplina "Engenharia de Software I". Curso: Sistemas de Informação.

1. Alessandro Almeida | www.alessandroalmeida.com

3. Aula 2

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

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

6. Aula 2

7. 50%
47%
45% 45%
45% 43%
40%
35%
30%
25% 2011
2012
20%
15%
10% 9%
5%
5% 3% 3%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

8. 60%
55% 55%
50%
40%
34%
33%
30% 2011
2012
20%
10%
7% 7%
5%
4%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

9. 70%
64%
61%
60%
50%
40%
2011
2012
30%
23% 23%
20%
12% 13%
10%
3%
1%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

10. 80%
74%
69%
70%
60%
50%
40% 2011
2012
30%
20%
15% 16%
13%
11%
10%
2%
0%
0%
Sempre Na maioria das vezes Poucas vezes Nunca

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

12. Gerente de Projeto
(na vida real)

13.  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.?

14. Aulas 3, 4 e 5

15. O que posso considerar ao definir um processo
que atenda minhas demandas de Engenharia
de Software?

16. RUP
SWEBoK
SCRUM
BABoK
Etc...
mps.Br
EUP
OpenUP
Extreme Programming
PMBoK CMMI

18. Qual é o significado do acrônimo?

19.  Capability Maturity Model
Integration®
Fontes: Houaiss e Merriam-Webster

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

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

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

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

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

27.  Agrupamento de práticas comuns de uma
determinada “disciplina”.
 Onde fica o “O que fazer?”.
 Por exemplo: Project Planning (PP)

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

29.  Sponsor:
 DoD (U.S. Department of Defense)
 Versão 1.3 publicada em novembro de 2010

30.  Para quem não quer gastar...

31.  Para quem quer investir...

33. CMMI-SVC
CMMI
Model
Foundation
CMMI-DEV CMMI-ACQ
Fonte: -http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html

34.  Representações
 Contínua (Capability Levels)
 Por estágio (Maturity Levels)

35.  Exemplo:

36.  Exemplo:

37. Optimizing  Causal Analysis and Resolution (CAR)
Organizational Innovation and Deployment (OID)
Quantitatively Managed  Organizational Process Performance (OPP)
Quantitative Project Management (QPM)
Decision Analysis and Resolution (DAR)
Integrated Project Management (IPM)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Training (OT)
Defined  Product Integration (PI)
Requirements Development (RD)
Risk Management (RSKM)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Configuration Management (CM)
Measurement and Analysis (MA)
Project Monitoring and Control (PMC)
Managed  Project Planning (PP)
Process and Product Quality Assurance (PPQA)
Requirements Management (REQM)
Supplier Agreement Management (SAM)
Initial  Processos ad hoc

38. Optimizing  Causal Analysis and Resolution (CAR)
Organizational Innovation and Deployment (OID)
Quantitatively Managed  Organizational Process Performance (OPP)
Quantitative Work Management (QWM)
Capacity and Availability Management (CAM)
Decision Analysis and Resolution (DAR)
Incident Resolution and Prevention (IRP)
Integrated Work Management (IWM)
Organizational Process Definition (OPD)
Defined  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)
Configuration Management (CM)
Measurement and Analysis (MA)
Work Monitoring and Control (WMC)
Managed  Work Planning (WP)
Process and Product Quality Assurance (PPQA)
Requirements Management (REQM)
Service Delivery (SD)
Supplier Agreement Management (SAM)
Initial  Processos ad hoc

39. Optimizing  Causal Analysis and Resolution (CAR)
Organizational Innovation and Deployment (OID)
Quantitatively Managed  Organizational Process Performance (OPP)
Quantitative Project Management (QPM)
Acquisition Technical Management (ATM)
Acquisition Validation (AVAL)
Acquisition Verification (AVER)
Decision Analysis and Resolution (DAR)
Integrated Project Management (IPM)
Defined  Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Training (OT)
Risk Management (RSKM)
Acquisition Requirements Development (ARD)
Agreement Management (AM)
Configuration Management (CM)
Managed  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)
Initial  Processos ad hoc

40.  “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

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

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

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

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

48.  Não se esqueçam que ....
 são compilação de “boas práticas”
 mostram O QUÊ fazer, e não COMO fazer

49.  “Depende...”
 Tudo depende da MOTIVAÇÃO.
 Qual é o nosso objetivo?
 Quem é o nosso cliente?
 Qual é a cultura da empresa?
 Etc...

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

51.  O que é?

52. Entendendo DFD sem precisar consultar o livro...

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

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

55.  FLUXO
 “escoamento ou movimento contínuo de algo que
segue um curso” (Fonte: Houaiss)

56.  FLUXO
 “escoamento ou movimento contínuo de algo que
segue um curso” (Fonte: Houaiss)
A B C D E

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

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

59.  O que é um Diagrama de Fluxo de Dados?
 Representação gráfica que mostra o movimento
das informações dentro de um sistema

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

62.  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”

63.  Quer ser um especialista em DFD?
 Quem lembra da referência básica indicada na
primeira aula?

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

68.  O DFD pode ser desenhado em uma página
 Seu cliente vai conseguir examinar o diagrama
sem se confundir!

70.  Também utilizado para modelagem de
processos...

71. Fonte: PMBoK, 4ª Edição

72. DFD ajuda!

73. Mas não é A SOLUÇÃO para
gerenciamento de requisitos e
modelagem da solução.

74. O DFD ajuda na modelagem da
solução.

75. Entendendo a estrutura – Parte 1

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

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

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

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

84. Entendendo a estrutura – Parte 2

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

86.  Rotular os processos de modo a identificar as
funções que o sistema executa
 Iniciando com um verbo no infinitivo...
Validar CPF

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

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

89.  Processo no primeiro nível...

90.  Processo no segundo nível...
 Qual processo estamos detalhando?

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

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

93.  Tome cuidado com...
 Poços sem fundo: Bolhas com fluxo de entrada,
mas sem fluxo de saída

94.  Tome cuidado com...
 Bolhas com geração espontânea: Bolhas com
fluxo de saída, mas sem o fluxo de entrada

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

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

97. Entendendo a estrutura – Parte 3

98.  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!

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

100.  Vantagens...
 Mantém a documentação enxuta
 Garante a 3ª diretriz para elaborar um (bom) DFD:
Evitar DFDs complexos demais

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

107. Chegamos no Nível 2 do DFD...
O que faremos agora?

109.  Descrição de cada processo, no nível mais
baixo do DFD
 Ajuda no entendimento do diagrama de fluxo
de dados e serve de apoio para a construção
do sistema

110. 2. Remeter Livros
Nome do Processo Descrição
2.1 Separar pedido • No módulo de pedidos, pesquisar pedidos em
aberto.
• Na tela de pedidos em aberto, o usuário realiza
a separação do pedido.
2.2 Realizar baixa no estoque • XXXXXX
2.3 Encaminhar pedido para a • XXXXXX
transportadora

111. Entendendo requisitos funcionais e não funcionais...

112.  De acordo com o Houaiss...
 “que foi requisitado, requerido”
 “condição para se alcançar determinado fim”

113.  Em Engenharia de Software...
 “definição de uma característica, atributo,
habilidade ou qualidade que um sistema (ou
qualquer um de seus módulos e sub-rotinas) deve
necessariamente prover para ser útil a seus
usuários”
▪ Fonte: Wikipedia (http://pt.wikipedia.org/wiki/Requisito)
 Divididos em Requisitos Funcionais e
Requisitos Não Funcionais

114.  Funções ou tarefas que o sistema deverá
executar ou fornecer
 Exemplos:
1. O sistema deve permitir o cadastro de CPF, RG e
Título de Eleitor
2. O sistema deve permitir a baixa automática do
estoque quando da venda de um produto
3. O sistema deve gerar relatórios segregados para
gerentes e analistas

115.  Relacionados ao uso da aplicação em termos
de desempenho, usabilidade, confiabilidade,
segurança, disponibilidade, e tecnologias
envolvidas.
 Normalmente, não é preciso o cliente dizer
sobre eles, pois eles são características
mínimas de um software de qualidade

116.  Exemplos:
1. O sistema deve operar em Windows 95 e
Windows 8
2. O retorno de uma pesquisa não pode demorar 2
segundos
3. A base de dados deve ser acessada somente por
usuários autorizados

117. ID Tipo Descrição
1 F O sistema deve permitir o cadastro de CPF, RG e Título de Eleitor
O sistema deve permitir a baixa automática do estoque quando da
2 F
venda de um produto
3 F O sistema deve gerar relatórios segregados para gerentes e analistas
4 NF O sistema deve operar em Windows 95 e Windows 8
5 NF O retorno de uma pesquisa não pode demorar 2 segundos
6 NF A base de dados deve ser acessada somente por usuários autorizados

119. alessandro.almeida@uol.com.br
www.slideshare.net/alessandroalmeida