Engenharia de Software I - Aula 24

494 views

Published on

Slides da 24ª aula da disciplina "Engenharia de Software I".

Curso: Sistemas de Informação.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
494
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Engenharia de Software I - Aula 24

  1. 1. Alessandro Almeida | www.alessandroalmeida.com
  2. 2. Aula 2
  3. 3.  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.
  4. 4.  ...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.
  5. 5. Aula 2
  6. 6. 50% 47% 45% 45%45% 43%40%35%30%25% 2011 201220%15%10% 9% 5%5% 3% 3%0% Sempre Na maioria das vezes Poucas vezes Nunca
  7. 7. 60% 55% 55%50%40% 34% 33%30% 2011 201220%10% 7% 7% 5% 4%0% Sempre Na maioria das vezes Poucas vezes Nunca
  8. 8. 70% 64% 61%60%50%40% 2011 201230% 23% 23%20% 12% 13%10% 3% 1%0% Sempre Na maioria das vezes Poucas vezes Nunca
  9. 9. 80% 74% 69%70%60%50%40% 2011 201230%20% 15% 16% 13% 11%10% 2% 0%0% Sempre Na maioria das vezes Poucas vezes Nunca
  10. 10.  Não cumprimento dos prazos Comunicação Escopo não definido adequadamente Mudanças de escopo constantes Estimativas incorretas Entre outros...
  11. 11. Gerente de Projeto (na vida real)
  12. 12.  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.?
  13. 13. Aulas 3, 4 e 5
  14. 14. O que posso considerar ao definir um processo que atenda minhas demandas de Engenharia de Software?
  15. 15. RUP SWEBoK SCRUM BABoK Etc... mps.BrEUP OpenUP Extreme Programming PMBoK CMMI
  16. 16. Qual é o significado do acrônimo?
  17. 17.  Capability Maturity Model Integration®Fontes: Houaiss e Merriam-Webster
  18. 18.  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 capazFontes: Houaiss e Merriam-Webster
  19. 19.  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 desenvolvimentoFontes: Houaiss e Merriam-Webster
  20. 20.  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...
  21. 21.  Capability Maturity Model Integration® 1 : simplificação da realidade 2 : representação em escala reduzida de objeto, a ser reproduzida em dimensões normais; maqueteFontes: Houaiss e Merriam-Webster
  22. 22.  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)
  23. 23.  Agrupamento de práticas comuns de uma determinada “disciplina”. Onde fica o “O que fazer?”.  Por exemplo: Project Planning (PP)
  24. 24.  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)
  25. 25.  Sponsor:  DoD (U.S. Department of Defense) Versão 1.3 publicada em novembro de 2010
  26. 26.  Para quem não quer gastar...
  27. 27.  Para quem quer investir...
  28. 28. CMMI-SVC CMMI Model Foundation CMMI-DEV CMMI-ACQFonte: -http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html
  29. 29.  Representações  Contínua (Capability Levels)  Por estágio (Maturity Levels)
  30. 30.  Exemplo:
  31. 31.  Exemplo:
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35.  “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
  36. 36.  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)
  37. 37.  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)
  38. 38.  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
  39. 39.  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
  40. 40.  Não se esqueçam que ....  são compilação de “boas práticas”  mostram O QUÊ fazer, e não COMO fazer
  41. 41.  “Depende...” Tudo depende da MOTIVAÇÃO.  Qual é o nosso objetivo?  Quem é o nosso cliente?  Qual é a cultura da empresa?  Etc...
  42. 42. Aulas 9, 10, 11, 12, 13 e 14
  43. 43.  O que é?
  44. 44. Entendendo DFD sem precisar consultar o livro...
  45. 45.  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)
  46. 46.  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)
  47. 47.  FLUXO  “escoamento ou movimento contínuo de algo que segue um curso” (Fonte: Houaiss)
  48. 48.  FLUXO  “escoamento ou movimento contínuo de algo que segue um curso” (Fonte: Houaiss) A B C D E
  49. 49.  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)
  50. 50.  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 Aluno16030364 Alessandro Rodrigues de Almeida16030365 Raul Seixas
  51. 51.  O que é um Diagrama de Fluxo de Dados?  Representação gráfica que mostra o movimento das informações dentro de um sistema
  52. 52.  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
  53. 53.  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”
  54. 54.  Quer ser um especialista em DFD?  Quem lembra da referência básica indicada na primeira aula?
  55. 55.  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
  56. 56.  O DFD pode ser desenhado em uma página  Seu cliente vai conseguir examinar o diagrama sem se confundir!
  57. 57.  Também utilizado para modelagem de processos...
  58. 58. Fonte: PMBoK, 4ª Edição
  59. 59. DFD ajuda!
  60. 60. Mas não é A SOLUÇÃO paragerenciamento de requisitos e modelagem da solução.
  61. 61. O DFD ajuda na modelagem da solução.
  62. 62. Entendendo a estrutura – Parte 1
  63. 63.  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
  64. 64.  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
  65. 65.  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
  66. 66.  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
  67. 67. Entendendo a estrutura – Parte 2
  68. 68. 1. Escolher nomes significativos para os processos, fluxos, depósitos e terminadores2. Numerar os processos3. Evitar DFDs complexos demais4. Refazer o DFD tantas vezes forem necessárias, até obter uma boa estética5. Certificar-se de que o DFD seja internamente consistente, além de manter a consistência com outros DFDs
  69. 69.  Rotular os processos de modo a identificar as funções que o sistema executa  Iniciando com um verbo no infinitivo... Validar CPF
  70. 70.  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
  71. 71.  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
  72. 72.  Processo no primeiro nível...
  73. 73.  Processo no segundo nível...  Qual processo estamos detalhando?
  74. 74.  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
  75. 75.  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
  76. 76.  Tome cuidado com...  Poços sem fundo: Bolhas com fluxo de entrada, mas sem fluxo de saída
  77. 77.  Tome cuidado com...  Bolhas com geração espontânea: Bolhas com fluxo de saída, mas sem o fluxo de entrada
  78. 78.  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
  79. 79.  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...
  80. 80. Entendendo a estrutura – Parte 3
  81. 81.  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!
  82. 82.  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
  83. 83.  Vantagens...  Mantém a documentação enxuta  Garante a 3ª diretriz para elaborar um (bom) DFD: Evitar DFDs complexos demais
  84. 84. Neste exemplo, estamosdetalhando somente oprocesso 2. Remeter Livros
  85. 85. Chegamos no Nível 2 do DFD... O que faremos agora?
  86. 86.  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
  87. 87. 2. Remeter LivrosNome do Processo Descrição2.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 • XXXXXX2.3 Encaminhar pedido para a • XXXXXXtransportadora
  88. 88. Entendendo requisitos funcionais e não funcionais...
  89. 89.  De acordo com o Houaiss...  “que foi requisitado, requerido”  “condição para se alcançar determinado fim”
  90. 90.  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
  91. 91.  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
  92. 92.  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
  93. 93.  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
  94. 94. 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 da2 F venda de um produto 3 F O sistema deve gerar relatórios segregados para gerentes e analistas4 NF O sistema deve operar em Windows 95 e Windows 8 5 NF O retorno de uma pesquisa não pode demorar 2 segundos6 NF A base de dados deve ser acessada somente por usuários autorizados
  95. 95. alessandro.almeida@uol.com.brwww.slideshare.net/alessandroalmeida

×