Engenharia de Software I - Aula 15

413 visualizações

Publicada em

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

Curso: Tecnologia em Análise e Desenvolvimento de Sistemas.

Publicada em: Negócios
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
413
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
18
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Engenharia de Software I - Aula 15

  1. 1. Alessandro Almeida | www.alessandroalmeida.com
  2. 2. Prova 1:Dia 9 de outubro
  3. 3. Aula 2
  4. 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. 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. 6. Aula 2
  7. 7. 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
  8. 8. 60% 55% 55%50%40% 34% 33%30% 2011 201220%10% 7% 7% 5% 4%0% Sempre Na maioria das vezes Poucas vezes Nunca
  9. 9. 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
  10. 10. 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
  11. 11.  Não cumprimento dos prazos Comunicação Escopo não definido adequadamente Mudanças de escopo constantes Estimativas incorretas Entre outros...
  12. 12. Gerente de Projeto (na vida real)
  13. 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. 14. Aulas 3, 4 e 5
  15. 15. O que posso considerar ao definir um processo que atenda minhas demandas de Engenharia de Software?
  16. 16. RUP SWEBoK SCRUM BABoK Etc... mps.BrEUP OpenUP Extreme Programming PMBoK CMMI
  17. 17. Qual é o significado do acrônimo?
  18. 18.  Capability Maturity Model Integration®Fontes: Houaiss e Merriam-Webster
  19. 19.  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
  20. 20.  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
  21. 21.  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...
  22. 22.  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
  23. 23.  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)
  24. 24.  Agrupamento de práticas comuns de uma determinada “disciplina”. Onde fica o “O que fazer?”.  Por exemplo: Project Planning (PP)
  25. 25.  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)
  26. 26.  Sponsor:  DoD (U.S. Department of Defense) Versão 1.3 publicada em novembro de 2010
  27. 27.  Para quem não quer gastar...
  28. 28.  Para quem quer investir...
  29. 29. CMMI-SVC CMMI Model Foundation CMMI-DEV CMMI-ACQFonte: -http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html
  30. 30.  Representações  Contínua (Capability Levels)  Por estágio (Maturity Levels)
  31. 31.  Exemplo:
  32. 32.  Exemplo:
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36.  “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
  37. 37.  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)
  38. 38.  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)
  39. 39.  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
  40. 40.  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
  41. 41.  Não se esqueçam que ....  são compilação de “boas práticas”  mostram O QUÊ fazer, e não COMO fazer
  42. 42.  “Depende...” Tudo depende da MOTIVAÇÃO.  Qual é o nosso objetivo?  Quem é o nosso cliente?  Qual é a cultura da empresa?  Etc...
  43. 43. Aulas 9, 10, 11, 12, 13 e 14
  44. 44.  O que é?
  45. 45. Entendendo DFD sem precisar consultar o livro...
  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.  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)
  48. 48.  FLUXO  “escoamento ou movimento contínuo de algo que segue um curso” (Fonte: Houaiss)
  49. 49.  FLUXO  “escoamento ou movimento contínuo de algo que segue um curso” (Fonte: Houaiss) A B C D E
  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)
  51. 51.  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
  52. 52.  O que é um Diagrama de Fluxo de Dados?  Representação gráfica que mostra o movimento das informações dentro de um sistema
  53. 53.  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
  54. 54.  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”
  55. 55.  Quer ser um especialista em DFD?  Quem lembra da referência básica indicada na primeira aula?
  56. 56.  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
  57. 57.  O DFD pode ser desenhado em uma página  Seu cliente vai conseguir examinar o diagrama sem se confundir!
  58. 58.  Também utilizado para modelagem de processos...
  59. 59. Fonte: PMBoK, 4ª Edição
  60. 60. DFD ajuda!
  61. 61. Mas não é A SOLUÇÃO paragerenciamento de requisitos e modelagem da solução.
  62. 62. O DFD ajuda na modelagem da solução.
  63. 63. Entendendo a estrutura – Parte 1
  64. 64.  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
  65. 65.  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
  66. 66.  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
  67. 67.  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
  68. 68. Entendendo a estrutura – Parte 2
  69. 69. 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
  70. 70.  Rotular os processos de modo a identificar as funções que o sistema executa  Iniciando com um verbo no infinitivo... Validar CPF
  71. 71.  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
  72. 72.  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
  73. 73.  Processo no primeiro nível...
  74. 74.  Processo no segundo nível...  Qual processo estamos detalhando?
  75. 75.  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
  76. 76.  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
  77. 77.  Tome cuidado com...  Poços sem fundo: Bolhas com fluxo de entrada, mas sem fluxo de saída
  78. 78.  Tome cuidado com...  Bolhas com geração espontânea: Bolhas com fluxo de saída, mas sem o fluxo de entrada
  79. 79.  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
  80. 80.  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...
  81. 81. Entendendo a estrutura – Parte 3
  82. 82.  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!
  83. 83.  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
  84. 84.  Vantagens...  Mantém a documentação enxuta  Garante a 3ª diretriz para elaborar um (bom) DFD: Evitar DFDs complexos demais
  85. 85. Neste exemplo, estamosdetalhando somente oprocesso 2. Remeter Livros
  86. 86. alessandro.almeida@uol.com.brwww.slideshare.net/alessandroalmeida

×