Projeto e construção do produto MPS.br

O objetivo do processo é definir atividades que permitam a elaboração do projeto e que possibilitem a implementação dos requisitos.

Processos de projeto de software

No MPS.br

  • Projeto e Construção do Produto (PCP) -> Nível D

No CMMI

  • Technical Solutions (TS) -> Nível 3

Na ISO 12207

  • Development Processes

Propósito

  • Projetar (design)

  • Processo criativo de transformar o problema em uma solução.

  • Representação significativa de algo a ser construído

  • Desenvolver

  • Implementar requisitos

Resultados esperados

  • PCP1 - Definição da arquitetura e documentação da arquitetura

  • Necessário fazer a definição da arquitetura do software

  • Criar alternativas para solucionar o problema

  • Exemplos de alternativas

  • Desenvolver ou comprar?
  • Linguagens, frameworks
  • Ambiente desktop, move
  • Banco de dados

  • Escolher uma das alternativas com base nos critérios estabelecidos inicialmente

  • Exemplos de critérios

  • Risco
  • Custo
  • Capacitação da equipe

  • PCP2 - Soluções

  • Soluções são selecionadas com base no cenário que são definidos e em critérios que são identificados

  • Necessário identificar os critérios de seleção e avaliar as alternativas
  • Pode ser necessário repetir o processo todo de tomada de decisão para um componente específico

  • PCP3 - Produto e componentes do produto

  • Projetar o produto de acordo com os requisitos

  • Projeto é constituído da arquitetura do sistema (hardware, software e op. manual) e do software
  • Para evidenciar este resultado pode ser usado documentos técnicos como documento de arquitetura, desenho, análise ou modelo de banco de dados

  • PCP4 - Interfaces

  • Interfaces entre os componentes do produto

  • Componente precisa expor as interfaces que ele fornece e que ele consome.
  • Projeto deve conter a definição das interfaces
  • A escolha da interface leva em conta os requisitos definidos no processo DRE
  • O processo ITP (integração do produto) utilizará as interfaces projetadas

  • PCP5 - Análise dos componentes do produto

  • Análise é necessário para decidir sobre a construção, compra ou reutilização dos componentes

  • Considerar custo-benefício, deve incluir custo direto e indireto.

  • PCP6 - Componentes do produto implementado e verificação

  • Verificar se os componentes estão implementados de acordo com o projeto e a sua documentação desenvolvida

  • MPS.br fornece várias alternativas para fazer a verificação

  • Revisão por pares

  • Testes de unidade
  • Verificação em relação aos requisitos do projeto

  • Como evitar este resultado?

  • Código fonte

  • Lista de verificação
  • Padrões de codificação
  • Relatórios de inspeção
  • Relatórios da execução dos testes

  • PCP7 - Documentação

  • Desenvolvida de acordo com os padrões estabelecidos

  • Doc. deve dar apoio para o desenvolvimento
  • Deve conter

  • O projeto de arquitetura do projeto

  • Justificativa das decisões tomadas
  • Projeto dos componentes
  • Projeto das interfaces
  • Rastreabilidade entre os requisitos e interfaces

  • PCP8 - Documentação é mantida

  • Doc. precisa ser mantida e revisada

  • Pode-se utilizar padrões na documentação, ex:

  • Fontes a serem utilizadas

  • uso de abreviações
  • índice
  • tamanho da fonte

Introdução ao framework SEMAT Essence

SEMAT é a comunidade que trabalha definindo o framework Essence

Framework Essence

O framework inclui uma linguagem e um kernel e oferece:

  • Monitoramento do progresso do projeto de software
  • Direcionamento do progresso dirigido por objetivos

Framework consiste

  • Métodos
  • Práticas
  • Kernel Essence
  • Linguagem Essence

O framework se baseia em três aspectos: Cliente, Solução e Esforço, dentro de cada aspecto tem os:

  • Alphas: itens com os quais trabalhamos

  • Possuem diversos estados

  • Cada estado possui uma lista de verificação
  • Organiza os estados através de cartões

  • Espaços de atividades: itens a fazer

  • Competências: quais as competências para trabalhar dentro da situação

Portanto, a estrutura ficaria assim:

  • Cliente

  • Alphas

  • Oportunidade, Stakeholders

  • Espaços de atividades

  • Competências

  • Solução

  • Alphas

  • Requisitos e Sistemas de Software

  • Espaços de atividades

  • Competências

  • Esforço

  • Alphas

  • Trabalho, Forma de Trabalho e Equipe

  • Espaços de atividades

  • Competências

Kernel do Essence

  1. Olhar o projeto holisticamente
  • Dar atenção de forma holística é observar todos os aspectos do projeto (todos os alpha)
  1. Monitorar o progresso
  • Definir qual o estado atual de um determinado alpha
  • Precisa ter a lista de verificação feita para completar um estado no alpha
  1. Definir a direção e os objetivos do projeto
  • Uma vez definido o estado atual
  • Definir o estado alvo, qual a direção que vou dar para o projeto
  1. Decidir como alcançar os objetivos (itens a trabalhar)
  • Preciso demonstrar as características chave
  1. Agir para concluir os itens a trabalhar
  • Produzir os itens levantados para atingir o objetivo

Alphas relevantes dentro da disciplina

  • Requisitos delimitados

  • Sem eles não é possível elaborar a arquitetura definitiva

  • Requisitos coerentes

  • Não há conflitos entre os requisitos funcionais e não funcionais

  • Sistema de Software

  • o primeiro item é certificar que a arquitetura deve ser selecionada

  • ser capaz de demonstrar a arquitetura selecionada

Kernel provê a estrutura e o mecanismo para:

  • Monitoramento do progresso do projeto
  • Reflexão da equipe
  • Gerenciamento de riscos
  • Direcionamento do projeto

Fundamento do SEMAT Essence é o kernel. Utilizando as práticas e o kernel é possível criar um método personalizado.