Engenharia de Software

Transcrição

1 Engenharia de Software [Versão 7 Junho/2019] Professor Emiliano S. Monteiro

2 11. FPA Professor Emiliano S. Monteiro

3 FPA (análise de pontos de função), intro. Desenvolvido por Allan J. Albrecht da IBM em O método foi publicado pela primeira vez em 1979, depois em Em 1984, Albrecht refinou o método e, desde 1986, quando o Grupo Internacional de Usuários de Pontos de Função (IFPUG) foi criado, várias versões do Manual de Práticas de Contagem de Pontos de Função foram publicadas pelo IFPUG. A versão atual do Manual do IFPUG é 4.1. O FPA fornece um conjunto de regras para dimensionar funcionalmente o produto de trabalho de software. A técnica de Análise de Pontos de Função é usada para avaliar a funcionalidade fornecida pelo software. A medida está diretamente relacionada aos requisitos comerciais que o software deve atender. A análise de pontos de função é uma técnica estruturada de classificação de componentes de um sistema. É um método para dividir os sistemas em componentes menores, para que possam ser melhor compreendidos e analisados. A análise de pontos de função pode ser usada para determinar se uma ferramenta, um ambiente, uma linguagem é mais produtiva em comparação com outras dentro de uma organização ou entre organizações.

4 FPA, Não é... O FPA não é uma técnica de estimativa de esforço por si só. A relação entre o tamanho dos requisitos funcionais e o esforço de implementação pode ser e geralmente é bastante solto(bem vago!). Os pontos de função podem ser usados como (uma) entrada para modelos de estimativa mais complexos (como COCOMO [COnstructive COst Model modelo para estimativa de tempo]), que devem levar em conta todos as outros formas de medir esforço. O FPA trata do tamanho funcionar... o tamanho funcional está sempre relacionado aos requisitos do usuário atendidos pelo software. Embora você possa contar e medir linhas de código ou complexidade de código, o tamanho funcional é o resultado de um processo analítico.

5 FPA, quando usar... O FPA pode ser útil para estimar o esforço de um projeto de software em um estágio inicial, quando os requisitos são conhecidos, mas os detalhes da implementação ainda não foram especificados ou avaliados. Os requisitos funcionais são refletidos no tamanho funcional, os requisitos não-funcionais precisam ser inseridos em um modelo de estimativa. Você precisa ter / usar um modelo bom e comprovado (e confiável), caso contrário, o tamanho funcional é inútil para essa finalidade. O FPA também pode ajudar a avaliar o "valor" de um aplicativo no sentido de "custos de recuperação". --- Imagine um índice! Eventualmente, no contexto das relações cliente / fornecedor de TI, o FPA pode ser usado como base para o cálculo de preços. Os clientes são faturados com base em um "preço por FPA" acordado, em vez de uma taxa horária.

6 FPA, quando não usar... Por definição, o FPA requer uma compreensão básica dos requisitos funcionais. Assim, se você não possui ou conhece os requisitos funcionais, será difícil, se não impossível, usar o FPA. O FPA também não é adequado para avaliar o desempenho de indivíduos, pois é uma classificação bastante holística para um aplicativo e não pode ser usado para dimensionar apenas partes dele.

7 Os cinco componentes dos pontos de função Funções de dados: 1. Arquivos lógicos internos 2. Arquivos de interface externa Funções Transacionais: 1. Entradas Externas 2. Saídas Externas 3. Consultas Externas

8 1. Arquivos lógicos internos: Funções de dados Permite que os usuários utilizem os dados que são responsáveis pela manutenção do sistema. Exemplo, um piloto pode inserir dados de navegação por meio de uma exibição no cockpit antes da partida. Os dados são armazenados em um arquivo para uso e podem ser modificados durante a missão. Portanto, o piloto é responsável por manter o arquivo que contém as informações de navegação. Agrupamentos lógicos de dados em um sistema, mantidos por um usuário final, são chamados de Arquivos Lógicos Internos (ALI). O ALI é um grupo identificável pelo usuário de dados logicamente relacionados ou informações de controle mantidas dentro do limite (da aplicação) A principal intenção de um ALI é guardar os dados mantidos através de um ou mais processos elementares da aplicação que está sendo contada. Tabela ou XML!

9 2. Arquivos de interface externa: Funções de dados Permite ao usuário final também estar relacionado a agrupamentos lógicos de dados. Nesse caso, o usuário não é responsável pela manutenção dos dados. Os dados residem em outro sistema e são mantidos por outro usuário ou sistema. O usuário do sistema que está sendo contado requer esses dados apenas para fins de referência. Exemplo, pode ser necessário que um piloto faça referência a dados de posição de um satélite ou uma instalação/estação terrestre durante o voo. O piloto não tem a responsabilidade de atualizar os dados nesses sites, mas deve referenciá-los durante o voo. Agrupamentos de dados de outro sistema que são usados apenas para fins de referência são definidos como Arquivos de Interface Externa (AIE). O AIE é um grupo identificável pelo usuário de dados logicamente relacionados ou informações de controle referenciadas pelo aplicativo, mas mantidas dentro do limite de outro aplicativo. A intenção principal de um AIE é manter os dados transferidos através de um ou mais processos elementares dentro do limite do aplicativo contado. Tabela externa! Exemplo: tabelas em bancos de terceiros.

10 Funções transacionais 1. Entrada Externa: Permite que um usuário mantenha os Arquivos Lógicos Internos (ALI) através da capacidade de adicionar, alterar e excluir os dados. Exemplo, um piloto pode adicionar, alterar e excluir informações de navegação antes e durante a missão. Nesse caso, o piloto está utilizando uma transação denominada Entrada Externa (EE). Uma entrada externa dá ao usuário a capacidade de manter os dados (Operações CRUD) em ALIs através da adição, alteração e exclusão de seu conteúdo. Uma entrada externa (EE) processa dados ou informações de controle que vêm de fora do limite do aplicativo que está sendo contado. A intenção principal de uma EI é manter uma ou mais ALI e / ou alterar o comportamento do sistema. 2. Saída Externa: A saída externa (SE) envia dados ou informações de controle fora do limite do aplicativo que está sendo contado. A intenção principal de um SE é apresentar informações ao usuário através da lógica de processamento, além de ou além da recuperação de dados ou informações de controle. A lógica de processamento deve conter pelo menos uma fórmula matemática ou cálculo, ou criar dados derivados. Um output externo também pode manter um ou mais ALIs e / ou alterar o comportamento do sistema. Permite ao usuário a capacidade de produzir saídas. Exemplo, um piloto tem a capacidade de exibir separadamente a velocidade no solo, a velocidade real do ar e a velocidade do ar calibrada. Os resultados exibidos são derivados usando dados que são mantidos e dados que são referenciados. Na terminologia do ponto de função, a exibição resultante é chamada de Saída Externa (SE). Saída de consultas ou exibição de dados

11 Incluir Excluir Editar Exportar Sistema externo XYZ Campo 1 cep Campo 2 Campo 3 Transacional GRID Sistema externo ABC Total Exibe + mostra um cálculo! ARQUIVO LÓGICO INTERNO Tabela Dados

12 Funções transacionais 3. Consultas externas: Uma Consulta Externa (CE) envia dados ou informações de controle fora do limite do aplicativo. A intenção principal de um inquérito externo é apresentar informações ao usuário através da recuperação de dados ou informações de controle. A lógica de processamento não contém dados derivados. Nenhuma ALI é mantida durante o processamento, nem o comportamento do sistema é alterado. Permite aos usuários acionar requisito de selecionar e exibir dados específicos dos arquivos. Para conseguir isso, um usuário insere informações de seleção que são usadas para recuperar dados que atendem aos critérios específicos. Nesta situação, não há manipulação dos dados. É uma recuperação direta das informações contidas nos arquivos. Exemplo, se um piloto exibe dados de liberação do terreno previamente definidos, a saída resultante é a recuperação direta das informações armazenadas. Essas transações são referidas como consultas externas (CE).

13 Funções transacionais 1. Entrada Externa: Permite que um usuário mantenha os Arquivos Lógicos Internos (ALI) através da capacidade de adicionar, alterar e excluir os dados. Exemplo, um piloto pode adicionar, alterar e excluir informações de navegação antes e durante a missão. Nesse caso, o piloto está utilizando uma transação denominada Entrada Externa (EE). Uma entrada externa dá ao usuário a capacidade de manter os dados em ALIs através da adição, alteração e exclusão de seu conteúdo. 2. Saída Externa: Permite ao usuário a capacidade de produzir saídas. Exemplo, um piloto tem a capacidade de exibir separadamente a velocidade no solo, a velocidade real do ar e a velocidade do ar calibrada. Os resultados exibidos são derivados usando dados que são mantidos e dados que são referenciados. Na terminologia do ponto de função, a exibição resultante é chamada de Saída Externa (SE). 3. Consultas externas: Permite aos usuários acionar requisito de selecionar e exibir dados específicos dos arquivos. Para conseguir isso, um usuário insere informações de seleção que são usadas para recuperar dados que atendem aos critérios específicos. Nesta situação, não há manipulação dos dados. É uma recuperação direta das informações contidas nos arquivos. Exemplo, se um piloto exibe dados de liberação do terreno previamente definidos, a saída resultante é a recuperação direta das informações armazenadas. Essas transações são referidas como consultas externas (CE).

14 Passos 1. Determinar o tipo de contagem 2. Identificar o escopo da contagem e a fronteira da aplicação 3. Contar funções do tipo dados 3.1. Determinação da complexidade e da contribuição 4. Contar funções do tipo transação 5. Determinar a contagem de pontos de função não ajustados 6. Determinar o valor do fator de ajuste 7. Calcula o número dos pontos de função ajustados

15 Como contar arquivos lógicos internos? São vistos como os dados lógicos da aplicação (tabelas e arquivos mantidos pela aplicação). Atenção: Localize os grupos de dados lógicos da aplicação nos diagramas de modelos de dados e diagramas de classe. Não considere relacionamentos N-N. Entidades fracas não são consideradas ALI (1-n). Nº ALI Simples x 7PF Nº ALI Médio x 10 PF Nº ALI Complexo x 15 PF

16 A contagem de arquivos de interface externa: No banco de dados são apenas referenciados pela aplicação pois são dados mantidos por outras aplicações. São com frequência arquivos usados para validar dados em um cadastro por exemplo. Nº AIE Simples: x 5 PF Nº AIE Média: x 7 PF Nº AIE Complexa: x 10PF

17 Contagem de Entradas Externas São funcionalidades que mantém os Arquivos Lógicos Internos ou alteram o comportamento da aplicação. São funcionalidades de inclusão, alteração e exclusão de dados, devem ser contadas separadamente. Se a aplicação possui processamento batch estas devem ser contadas. Nº EE Simples: x 3 PF Nº EE Média: x 4 PF Nº EE Complexa: x 6 PF CRUD

18 Contagem de consulta externa São funcionalidades que apresentam informações para o usuário sem o uso de processamento de cálculos. São processos elementares do ler e imprimir ou ler e apresentar dados, incluem aqui consultas, relatórios, geração de discos, cds, geração de arquivos que exportam dados, downloads de dados para fora do domínio da aplicação,etc. Nº CE Simples: x 3 PF Nº CE Média: x 4 PF Nº CE Complexa: x 6 PF

19 A contagem de saídas Externas São funcionalidades que apresentam para o usuário o resultados de cálculos. São consultas que geram totalizações, relatórios estatísticos, gráficos, relatórios com porcentagens e outras saídas de processamentos. Nº SE Simples: x 4 PF Nº SE Média: x 5 PF Nº SE Complexa: x 7 PF

20 Tabela de referência para contagem

21 Exemplo: imagine um sistema simples (com uma tela apenas) de cadastro de alunos Funcionalidades: 1. Formulário: Aluno 2. Incluir aluno 3. Alterar aluno 4. Excluir aluno 5. Consultar Aluno 6. Imprimir um registro de aluno 7. Imprimir listagem de alunos 8. Consultas Gerenciais (3 gráficos e 3 relatórios com dados calculados) 9. Consultar financeiro do aluno 10.Envio de ao aluno 11.Consultar Status Aluno pelo site

22 Exemplo: imagine um sistema simples (com uma tela apenas) de cadastro de alunos ALI Arquivo lógico interno, AIE - Arquivo de Interface Externa, EE Entrada Externa, SE Saída Externa, CE Consulta Externa Funcionalidades: Qtde Tipo Complexidade Tamanho Aluno 1 ALI Simples=7 7 PF (1x7) Incluir aluno 1 EE Simples=7 7 PF (1x7) Alterar aluno 1 EE Simples=7 7 PF (1x7) Excluir aluno 1 EE Simples=7 7 PF (1x7) Consultar Aluno 1 EE Simples=7 7 PF (1x7) Imprimir um registro de aluno 1 SE Simples=7 7 PF (1x7) Imprimir listagem de alunos 1 SE Simples=7 7 PF (1x7) Consultas Gerenciais (3 gráficos e 3 relatórios com dados calculados) 6 SE Média=5 30 PF (6x5) Consultar financeiro do aluno 1 AIE Simples=5 5 PF (1x5) Envio de ao aluno 1 SE Média=5 5 PF (1x5) Consultar Status Aluno pelo site 1 CE Simples=3 1 PF (1x3) 90 PF

23 Passos 1. Determinar o tipo de contagem 2. Identificar o escopo da contagem e a fronteira da aplicação 3. Contar funções do tipo dados 4. Contar funções do tipo transação 5. Determinar a contagem de pontos de função não ajustados 6. Determinar o valor do fator de ajuste 7. Calcula o número dos pontos de função ajustados

24 1. Determinar o tipo de contagem Existem 3 tipos de contagem: Projeto de desenvolvimento Para sistemas novos Projeto de melhoria Para novas funcionalidades Aplicação Para sistemas já instalados

25 2. Identificar o escopo da contagem Definir a fronteira da aplicação Definir quais funções serão contadas O usuário determina o que para ele é a aplicação baseados nas funções que ele utiliza Arquivo ou Tabela Aplicação 1 Aplicação 2 Fronteira da Aplicação Neste exemplo temos: 3 aplicações Cada aplicação com seu arquivo lógico interno As aplicações fazem referências a arquivos de interface externa. Aplicação 3

26 3. Contar funções do tipo dado Funções do tipo dado são funcionalidades para o armazenamento de dados em arquivos. Estes arquivos podem ser mantidos pela aplicação de nosso interesse ou por aplicações de terceiros. Temos dois tipos de arquivos: ALI Arquivo lógico interno: São dados mantidos pela aplicação e alterados pelos processos das funcionalidades disponibilizados ao usuário. Podem parecer como tabelas de um banco de dados, mas um grupo de tabelas também pode ser considerado um ALI. São exemplos também: arquivos de senhas, arquivos de conexão, arquivos de configuração. Não são exemplos de ALI: arquivos temporários, viés de banco de dados e arquivos de backup. AIE Arquivo de interface externa: São arquivos de dados mantidos por outras aplicações.

27 3.1. Determinação da complexidade e da contribuição A complexidade é o quanto um arquivo pode tender para alterar as dimensões funcionais do sistema. Para calcular vamos contar... Tipos de dados (TD): Equivale a atributos de uma tabela Tipos de registros (TR): Equivale a tabelas Exemplo: Técnico Bolsa Funcionários IdFuncionário Salário Professor Orientador Funcionários IdFuncionário Salário Bolsa Orientador Funcionário é um ALI As outras tabelas (Técnico e Professor) serão contadas como tipo de registro Os tipos de dados das tabelas (Técnico e Professor serão contados junto à funcionário) O usuário não vê 3 classes! Visão do usuário.

28 3.1. Determinação da complexidade e da contribuição Tabela de complexidade: Tabela de contribuição: Após realizar todas as verificações de complexidade e contribuição, temos...

29 4. Contar funções do tipo transação As funções do tipo transação são o pilar do processamento do sistema. Estes processos básicos são também chamados de elementares : Entradas externas Saídas externas Consultas externas Entradas externas: Processo de controle Processa dados Inclui, exclui e altera dados Qualquer transação que mantenha arquivos lógicos internos Saída externas: Destinado a mostrar informações ao usuário ou a atender uma aplicação externa por meio de cálculo. Relatórios Consultas Apresentação de gráficos a partir de cálculos Consulta externas: Destinado a mostrar informações ao usuário ou a atender uma aplicação externa por consulta simples. Consultar registros por Id ou nome. Apresentar gráficos

30 4.1. Determinação da complexidade e da contribuição As funções do tipo transação são o pilar do processamento do sistema. Estes processos básicos são também chamados de elementares : Entradas externas Saídas externas Consultas externas Entradas externas: Processo de controle Processa dados Inclui, exclui e altera dados Qualquer transação que mantenha arquivos lógicos internos Saída externas: Destinado a mostrar informações ao usuário ou a atender uma aplicação externa por meio de cálculo. Relatórios Consultas Apresentação de gráficos a partir de cálculos. Consulta externas: Destinado a mostrar informações ao usuário ou a atender uma aplicação externa por consulta simples. Consultar registros por Id ou nome. Apresentar gráficos

31 4.1. Determinação da complexidade e da contribuição Tabela de complexidade: Tabela de contribuição:

32 4.1. Determinação da complexidade e da contribuição 1. Identificar processos elementares:

33 4.1. Determinação da complexidade e da contribuição 2. Classifique os processos quanto ao tipo de processo elementar:

34 4.1. Determinação da complexidade e da contribuição 3. Classifique os processos quanto ao tipo de dado:

35 4.1. Determinação da complexidade e da contribuição 4. Classifique os processos quanto aos arquivos referenciados:

36 4.1. Determinação da complexidade e da contribuição 5. Determine a complexidade:

37 4.1. Determinação da complexidade e da contribuição 5. Determine a contribuição de cada processo elementar:

38 4.1. Determinação da complexidade e da contribuição 5. Determine a contribuição total:

39 5. Calculo de pontos de função não ajustados

40 6. Determinar o valor do fator de ajuste O IFPUG determina esta etapa como opcional, portanto será 1. Valor de ponto de função não ajustado (VAF) = 1.

41 7. Calcula o número dos pontos de função ajustados DFP = (UFP + CFP) x VAF DFP: O número de pontos de função do projeto de desenvolvimento. UFP: Número de pontos de função não ajustados das funções disponíveis aos usuários após a instalação. CFP: Número de pontos de função não ajustados das funções de conversão, ou seja, as funções transitórias que são inutilizadas após a instalação. VAF: Valor do fator de ajuste. DFP = (29+0) x 1 DFP = 29

42 12. Mais detalhes sobre: Scrum Professor Emiliano S. Monteiro

43 Esquema Scrum

44 Definição É um framework para gerenciar o desenvolvimento de produtos. Teve seu início em Desenvolvido por Ken Schwaber e Jeff Sutherland. Sua base é o controle de processo. Ele é usado de forma iterativa e incremental. É uma técnica boa para controle de risco.

45 Pilares do SCRUM 1. Transparência: tudo o que vai ser desenvolvido e a forma como será feito deve ser de conhecimento de todos. Informações devem ser compartilhadas por todos. Deve-se criar uma definição de finalizado, Terminado ou Pronto para se possa saber quando partes do trabalho chegaram ao fim. 2. Inspeção: Todo o trabalho e seu progresso deve ser inspecionado por todos para detectar variações ao longo do caminho. A inspeção não deve se tornar uma atividade rotineira a ponto de consumir um integrando da equipe como fiscal! 3. Adaptação: Ao inspecionar os pacotes finalizados, as sprints, product backlog e demais artefatos, e forem localizados desvios fora do aceitável, ajustes devem ser tomados, inclusive a para de sprint, revisão ou cancelamentos.

46 Tipos de reuniões 1. Reunião de planejamento 2. Reunião diária 3. Reunião de revisão 4. Reunião de retrospectiva

47 Participantes 1. Proprietário do produto: é o dono do produto, é o único que pode gerenciar o product backlog (expressar os itens, ordenar os ítens,/priorizá-los, gerir o valor do trabalho realizado, deixar o product backlog transparente a todos), é uma pessoa e não um grupo de stakeholders. 2. Equipe Scrum: são os desenvolvedores que irão transformar o product backlog em um produto funcional. São equipes de 3 a 9 pessoas. São auto gerenciadas. Não são dirigidas por outras pessoas externas ao grupo. A quantidade ideal de pessoas na equipe pode variar de e a 5 pessoas. 9 ou mais pessoas começa a criar a necessidade de controle de comunicação interna no grupo. É necessário que o grupo seja multi funcional, não se importe com titulações de seus integrantes. Não deve existir dentro do grupo um sub-grupo. 3. Scrum master: Assegura que o Scrum seja entendi e aplicado. É o responsável por comunicar os objetivos para a equipe de programação. Ensina e tira dúvidas sobre o Scrum. Não é chefe direto dos programadores. Promove treinamento sobre o Scrum, promove o auto gerenciamento da equipe.

48 Sprint É um evento com espaço tempo definido em aproximadamente um mês. Com intervalos de reuniões diárias e reuniões semanais, uma revisão mensal no final de cada bloco atividades. Ao final de uma sprint temos o início de outra sprint. Dentro de uma sprint estão as atividades de desenvolvimento e as reuniões diárias e as de planejamento. A sprint é usada para desenvolver o que já foi estabelecido, uma sprint não pode mudar sem uma reunião de planejamento. Sprints podem ser canceladas ou reprogramadas.

49 Reunião diária É um evento de aproximadamente 15 minutos, ocorre a cada 24 horas. É realizada para se verificar o progresso do dia anterior desde a última reunião e prever o próximo passo. Deve se deixar claro os seguintes 3 ítens: O que foi feito ontem ajudou a equipe? O que farei hoje para ajudar a equipe? Percebo algum obstáculo a mim e para a equipe?

50 Revisão de sprint O evento é realizado junto com o product owner/dono do produto/stake holders. O Product Owner informa o que é considerado pronto. É discutido o que deu certo e quais os problemas encontrados. São discutidas novas datas de entregas. Pode ser apresentado uma análise de mercado que possa balizar o desenvolvimento das novas funcionalidades. O resultado é um Product Backlog revisado.

51 Product backlog É uma lista ordenada e priorizada pelo product owner. O product owner é o único que pode alterar o product backlog. É uma lista de requisitos, correções, melhorias, funcionalidades. O product backlog evolui com as iterações da equipe nas reuniões de revisão / reuniões semanais. Sempre vai existir um product backlog enquanto o sistema também existir.

52 Sprint backlog São os itens que foram selecionados do product backlog mais o plano de entrega (um cronograma) para ser desenvolvido. O sprint backlog é a quantidade de trabalho que a equipe de desenvolvimento fará para atingir o objetivo daquela sprint. Ele é especificado pela equipe de desenvolvimento. Trabalhos novos (novas features) são adicionadas ao sprint backlog.

53 SCRUM

54 13. Etapas do processo x Ferramentas Professor Emiliano S. Monteiro

55 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação 1. ALM Octane da Microfocus 2. Ca Agile Central 3. Caliber Microfocus 4. IBM Rational DOORS Next Generation 5. Visual Trace Spec 6. Casecomplete 7. codebeamer ALM Requirements Management 8. Kovair ALM Studio 9. Modern Requirements4TFS 10. objectif RM 11. OneDesk Product Management 12. MODELIO BA 13. Polarion REQUIREMENTS da Siemens 14. Requirement One 15. Yonix Bizagi é para modelagem BPMN Brainstorming caso de uso StarUML Mapa mental

56 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação 1. Criação de cenários, Ensaios, estudos em meios de comunicação, análises de mercado, análise da concorrência, contratação de consultores, opiniões de assessores, estudo de produtos similares, observação da concorrência, mapas mentais, relatórios operacionais e gerenciais. 2. Escolha de metodologia: RUP, Agile, RAD, etc. 3. Ferramenta para avaliação de recursos humanos: Skill Base, TalentSoft, Rexx Systems, Coppelis SkillsMinds, SparkHire, Codility, OrangeHRM e Sentrifugo. 4. A escrita do TAP ser em qualquer editor de texto ou no próprio sistema de projetos, inclusive existem templates prontos disponíveis gratuítamente na web.

57 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação 1. Desktop open source: OpenProj, dotproject, Open Workbench, GanttProject, jsproject, ProjectLibre 2. Desktop/server: Microsoft Project, CA PPM. 3. Open source web: qdpm, Feng Office, eyeos, Collabtive, dotproject, ProjectPier, Mantis Bug Tracker, Rukovoditel, The Bug Genie, PHProjekt, TaskFreak, todoyu, Flyspray, Kanboard, phpcollab, Snipe-IT, Admidio, SOPlanning, Traq, ZenTao, Eventum, Bugs, ProjeQtOr, WebCollab, TestLink, Manage Your Team, Burden 4. Ferramentas para desenho: Visio, Project Pencil, Dia, Umbrello, StarUML. 5. Ferramentas para modelagem de dados: MySQLWorkbench, ERWin, Embarcadero ERStudio, Fabforce designer 6. Nclass eng. Reversa 7. Scriptcase gera diagramas do que já feito! 8. Adianti Builder & Workana DER 9. Enterprise Manager SQL Server DER

58 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação 1. Microsoft System Center (Configuration Manager, Operation Manager, Hiper-v Server, Service Manager e Orchestrator). 2. AWS CodeDeploy, Bamboo, Octopus Deploy. 3. Microsoft Azure.

59 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação 1. Ferramentas de desenvolvimento RAD que possam criar GUIs 2. Axure RP 8 3. Project Pencil, Visio, etc Ferramentas CASE

60 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação xunit, DUnit, JUnit, unittest, mstest, nunit

61 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação /* Asdflajflkdsfj */ Editores: Microsoft Office, MarkdownPad, Typora, LibreOffice, Haroopad, TextPad, Visual Studio Code, Plugins para RadStudio e Visual Studio. Documentadores: Helpndoc, Documento!X, Doxygen, NDoc, JavaDoc, Doc-O-Matic, SharpDox, HelpManual, Epsilon Content.

62 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação Gerir O.S. qdpm, Mantis, Microsoft Service Manager MOF

63 Ferramentas para cada etapa do processo 1. Levantamento de requisitos 1.1. Requisitos do usuário e casos de uso 1.2. Requisitos de sistema 2. Análise, avaliação e aprovação 2.1. Estudo de viabilidade/análise de risco 2.2. Escolha de metodologia de desenvolvimento 2.3. Escolha da equipe de projeto 2.4. Escrita do TAP - Termo de abertura de projeto 3. Projeto 3.1. Projeto da arquitetura do sistema 3.2. Projeto do banco de dados 4. Instalação de Configuração de ambientes 4.1. Ambiente de desenvolvimento 4.2. Ambiente de testes 4.3. Ambiente de produção 5. Desenvolvimento 5.1. Desenvolvimento de telas e protótipo 5.2. Codificação e versionamento 6. Testes 6.1. Teste unitários 6.2. Teste de integração 6.3. Teste de usabilidade 7. Documentação 7.1. Documentação para o usuário final 7.2. Documentação para o administrador do sistema 7.3. Desenvolvimento de material de treinamento 8. Treinamento 8.1. Treinamento para administradores do sistema 8.2. Treinamento para usuários finais 8.3. Disponibilização de treinamento on-line 9. Operações 9.1. Instalação e configuração 10. Escrita do TEP - Termo de encerramento de projeto 11. Manutenção 12. Avaliação 1. Microsoft system Center (Configuration Manager, Operation Manager, Hiper-v Server, Service Manager e Orchestrator. 2. AWS CodeDeploy, Bamboo, Octopus Deploy.

64 14. Exemplo de change log

65 15. Exemplo de Road map

66 16. Qualidade de software Professor Emiliano S. Monteiro

67 16.1. Conceitos Básicos O que é qualidade? Existem diversas definições. Qualidade é estar em conformidade com os requisitos dos clientes Qualidade é antecipar e satisfazer os desejos dos clientes Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito Qualidade, de forma simplista, significa que o produto deve esta de acordo com a especificação.

68 16.1. Conceitos Básicos Qualidade de software é definida pelo IEEE (The Institute of Electrical and Electronics Engineers) como "o grau com que um sistema, componente ou processo atende aos requisitos especificados e às expectativas ou necessidades de clientes ou usuários". Já a ISO (The International Standards Organization) define qualidade como "a totalidade de características de um produto ou serviço que comprovam sua capacidade de satisfazer necessidades especificadas ou implícitas"

69 16.2. Gerenciamento da qualidade Visa assegurar que o nível de qualidade requerido é atingido pelo software. Envolve a definição apropriada de procedimentos e padrões de qualidade. Deve proporcionar uma cultura da qualidade onde esta seja vista como uma responsabilidade de cada um dos envolvidos. Não é apenas reduzir defeitos, mas garantir outras qualidades do produto.

70 16.3. Atributos relacionados com a qualidade Correção Um software precisa funcionar corretamente. Um software correto é aquele que satisfaz a sua especificação e que não possui falhas ou erros. Validade Um software válido é aquele cuja especificação satisfaz aos requisitos dos usuários e da organização, isto é, está de acordo com as necessidades dos usuários. Robustez O software deve prever que o usuário pode agir de forma não esperada e deve ser capaz de resistir a estas eventuais situações incomuns, sem apresentar falhas. Confiabilidade Um software correto e robusto ganha a confiança dos usuários uma vez que ele deve se comportar como esperado e não falha em situações inesperadas. Eficiência O software deve realizar suas tarefas em um tempo adequado à complexidade de cada uma delas. A utilização dos recursos de hardware (memória, disco, tráfego de rede) também deve ser feita de forma eficiente. Reusabilidade Diversos componentes de um software devem poder ser reutilizados por outras aplicações.

71 16.3. Atributos relacionados com a qualidade Usabilidade O software precisa ser fácil de aprender e de usar, permitir maior produtividade do usuário, flexibilidade de utilização, flexibilidade de aplicação e proporcionar satisfação de uso. Manutenibilidade Todo software precisa de manutenção, seja para corrigir erros ou atender a novos requisitos. O software deve ser fácil de manter para que estas correções ou atualizações sejam feitas com sucesso. Evolutibilidade Todo software precisa evoluir para atender novos requisitos, para incorporar novas tecnologias ou para expansão de sua funcionalidade. Portabilidade O software deve poder ser executado no maior número possível de equipamentos de hardware. Interoperabilidade Software em diferentes plataformas devem poder interagir entre si. Esta qualidade é essencial em sistemas distribuídos uma vez que o software pode estar sendo executado em diferentes computadores e sistemas operacionais. É interessante que diferentes elementos de software distintos possam ser utilizados em ambos. Por exemplo, uma certo arquivo com uma imagem feita num aplicativo deve poder ser vista em outros aplicativos. Conhecida também como compatibilidade

72 16.4. Métricas de produtos (artefatos de software) Número de linhas de código fonte Número de identificadores de um programa Número de condicionais (ifs) aninhados Complexidade ciclomática Mede a complexidade das estruturas de controle de um programa. Fan-in/Fan-out Mede o número de funções que chama uma outra função. Índice Fog Comprimento médio de palavras e sentenças de um documento. Entre outras... FPA! Tickets em sistemas de OS

73 16.5. Como garantir a qualidade? Com métodos e ferramentas de análise, projeto, codificação e teste; Com revisões técnicas formais que são aplicadas durante cada fase da engenharia de software; Usando uma estratégia de teste de múltiplas fases; No controle da documentação do software e das mudanças feitas nela; Com um procedimento para garantir a adequação aos padrões de desenvolvimento de software, se eles forem aplicados; Com mecanismos de medição e divulgação de resultados.

74 16.6. Especificação de requisitos = base para qualidade O SRS (Software Requirements Specification) é basicamente a compreensão de uma organização e cliente (por escrito) de um requisitos do sistema para este potencial cliente e realizado em determinado ponto no tempo (geralmente) antes de qualquer projeto real ou trabalho de desenvolvimento tenha início. É uma apólice de seguro de duas vias, que assegura que tanto ao cliente como para a organização entender as necessidades de ambas as partes.

75 16.7. Modelos de qualidades & normas existentes

76 16.8. Padrões mais populares CMMI (Capability Maturity Model Integration) ISO (SPICE) (Software Process Improvement & Capability dertemination) Desenvolvido pela International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC)

77 16.9. CMMI O CMMI é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Engenharia de Sistemas (SE), Engenharia de Software (SE), Desenvolvimento de Processo e Produto Integrado (IPPD), Supplier Sourcing (SS). Desenvolvido pelo SEI (Instituto de Engenharia de Software). O CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.

78 CMMI

79 Estrutura do MPS.BR CMMI ISO ISO Governo através do Softex + empresas privadas + universidades MPS.BR Modelo de referência Modelo de avaliação Modelo de Negócio

80 Níveis de maturidade Melhor A Em otimização B Gerenciado quantitativamente C Definido D Largamente definido E Parcialmente definido F Gerenciado G Parcialmente Gerenciado Pior

81

82

83 SPICE Melhoria do processo e determinação da capacidade do processo Consiste de um framework de avaliação, contendo: Facilita o auto-julgamento Desperta consciência do contexto Produz um perfil do processo Direciona a adequação das atividades Apropriado para organizações de diversos tamanhos As empresas poderão identificar quais os processos que devem melhorar, o que deverá ser feito para este fim e deduzir onde devem investir em primeiro lugar, com vista à obtenção de retornos rápidos e significativos.

84 SPICE O SPICE é composto por 9 partes: parte 1: Conceitos e Guia Introdutório parte 2: Modelo de Gerenciamento de Processo parte 3: Avaliação do Processo parte 4: Guia para Condução de uma Avaliação parte 5: Construção, Seleção e Uso das Ferramentas de Avaliação parte 6: Qualificação e Treinamento dos Avaliadores parte 7: Guia para o Processo de Melhoria parte 8: Guia para Orientação da Determinação da Capacidade do Processo parte 9: Dicionários

85 CMMI x SPICE

86 CMMI x SPICE

87 17. Exercícios Professor Emiliano S. Monteiro

88 Exercício 1 Qual destes não é um exemplo de um projeto? 1. Comprar itens raros de colecionador em uma venda especial em um leilão. 2. Planejamento para a festa de aniversário de 10 anos da empresa. 3. Construindo uma casa. 4. Limpeza do carro todo sábado pela manhã.

89 Exercício 2 De onde surgem os projetos? 1. Demanda de mercado 2. Avanço tecnológico 3. Solicitação do cliente 4. Requisito legal 5. Necessidade organizacional 6. Necessidade social

90 Exercícios

91 Exercícios

92 Exercícios

93

94 Exercícios

95

96 Exercícios

97

98 Referências bibliográficas Básica PFLEEGER, Shari Lawrance. Engenharia de software teoria e prática. 2ª. ed. São Paulo : Prentice Hall, SOMMERVILLE, Ian. Engenharia de Software. 6ª. Ed. São Paulo : Addison Wesley, BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 1.ed. Rio de Janeiro: Elsevier, Complementar FERNANDES, Aguinaldo, Aragon. TEIXEIRA, Descartes de Souza. Fábrica de software implantação e gestão de operações. São Paulo : Atlas, LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e o projeto orientados a objetos e ao processo unificado. 2.ed. Porto Alegre: Bookman, Outras referências podem ser encontradas na página da disciplina em:

99

100 Prof. Emiliano S. Monteiro