Projeto de Pesquisa

Características de um Projeto de Pesquisa

• Tem um tema bem definido
• Possui metas alcançáveis bem justificadas
• Tem início, meio e fim (tempo limitado)
• Deve ser viável (recursos em geral)
• Propor resultados verificaveis

Concepção geral do projeto

1º Passo - Identificar o tema

• O tema deve ser de interesse do pesquisador
• Tema muito amplo pode resultar em um trabalho superficial
• É mais interessante selecionar um tema que possa ser analisado em profundidade

Questões a serem feitas

• O que será pesquisado?
• O assunto é de interesse do pesquisador?
• Haverá necessidade de prova ou algum tipo de desenvolvimento?
• O trabalho tem potencial pra ser original?
  

Onde encontrar um tema de pesquisa?

• Experiências pessoais e profissionais
• Desafios apontados por especialistas
• Leituras e reflexões
• Em conversar, debates e discussões

Formulação do problema de pesquisa

• Não basta ter um tema, precisa ter um problema de pesquisa
• Não há uma "fórmula mágica" para se encontrar um problema de pesquisa
• Requer experiência e demanda orientação (de professores)

Exemplo

Necessidade: melhoria da mobilidade em grandes centros urbanos

Tema: controle do trânsito de veículos em vias urbanas

Problema: como melhorar a mobilidade urbana em grandes cidades a partir de um sistema capaz de realizar um controle inteligente do trânsito de veículos.

Problema 1: um sistema de controle de semáforos de trânsito pode melhorar a mobilidade urbana das grandes cidades?

Problema 2: um sistema inteligente de controle de semáforos de trânsito pode melhorar a mobilidade urbana em cidades com um bom sistema de transporte público?

Justificativa

• Todo projeto de pesquisa tem que se justificar
• O tema é atual?
• Porque vale a pena fazer essa pesquisa?
• Quais as possiveis contribuições decorrentes da solução? Há algum tipo de inovação?
• Ou seja, o problema é relevante?

Objetivo

• Decorre diretamente do problema formulado
• O que se pretende alcançar com a pesquisa
• Destacar o objetivo, p.ex., iniciar um parágrafo com "O objetivo desse projeto.."
• Todo projeto deve ter um objetivo geral (umas 3 frases no infinitivo)
• Objetivo geral pode ser dividido em objetivos específicos

Objetivo geral do problema exemplo

Desenvolver um sistema inteligente de controle de semáforos de trânsito para melhorar a mobilidade urbana em grandes centros urbanos

Objetivo específicos do problema exemplo

• Mapear as grandes cidades que serão estudadas, bem como os seus sistemas de trânsito.
• Analisar os sistemas de controle de semáforos de trânsitos utilizados em grandes centros urbanos.
• Especificar os requisitos de um sistema inteligente de controle de semáforos de trânsito para grandes cidades, destacando os problemas  ou deficiências dos sistemas existentes
• Implementar o novo sistema inteligente de controle de semáforos de trânsito para grandes cidades
• Realizar uma análise comparativa do novo sistema com os sistemas atuais 

Plataformas Emergentes

Plataformas emergentes

• Plataformas móveis: em 2014 o número de smartphones superou o de desktops, consolidando a plataforma mobile junto com desktop e web.
• IoT: smartwatch, google glass, tênis com sensores, transporte urbano. 
• Redes sociais: números nunca antes visto de interatividade social. Ex: Facebook, whatsapp.

Todas essas plataformas levam a uma convergência denominada pelo Gartner Group como o Nexus das Forças. Sinaliza uma tendência tecnológica que deve direcionar todo o desenvolvimento de aplicações corporativas.

Plataformas - Open group

• 1a. Plataforma: foi até meados dos anos 80, possuia milhares de usuários suportados por mainframes
• 2a. Plataforma: até inicio do sec. XXI, suportado pelo PC, Internet, e Cliente/Servidor. Possuia centenas de milhões de usuários. Riqueza de interação.
• 3a. Plataforma: Bilhões de usuários. Suportado por banda larga, dispositivos móveis, serviços em nuvem, big data, internet das coisas. Traz desafios importantes em tecnologia, já que Java e .NET por exemplo, não consegue lidar com a 3a. plataforma.

Plataforma Javascript

• As tecnologias Javascript e HTML5 foram repensada e redesenvolvidas para fazer aplicações interativas e que podem ser representadas para qualquer tipo de dispositivo.
• Javascript se tornou uma plataforma com todo um conjunto de elementos existentes em plataformas estabelecidas, Ex:
• Componentes
• Frameworks MVVM
• Servidores
• Testes de unidade
• Gerenciadores de pacotes
• Layouts responsivos
• Linguagens de script
• IDEs
• Bibliotecas Javascript
• Jquery
• Sencha
• ExtJS
• Kendo UI
• Angular
• Framework MVVM JS: Diferente das paginas JSF, o trafego de dados entre o servidor é muito menor ao usar um framework javascript. O Controller fica no browser.
• Backbone
• AngularJS
• Ember
• Knockout
• Servidores de aplicação JS
• NodeJS
• SilkJS
• Testes de Unidade JS
• QUnit
• Mocha
• Jasmine
• Arquilian
• IDEs JS
• Senha Architect
• WebStorm
• Gerenciamento de Pacotes JS
• Bower
• Jam
• Npm
• Framework CSS
• Less
• Bootstrap
• Foundation
• Linguagens de Script JS
• CoffeeScript
• Parse
• TypeScript

Plataformas .NET e LAMP

Tecnologias básicas de plataforma .NET

ASP.NET

Tecnologia para o desenvolvimento de aplicações Web.

• Razor: linguagem de marcação para escrita de páginas ASP.NET
• Windows Forms: tecnologia para desenvolvimento de aplicações desktop
• Smart Clients: tecnologia para facilitar a distribuição e atualização de aplicações desktop

ADO.NET

Tecnologia para interoperabilidade e persistência de dados com banco de dados relacionais

• Entity Framework: tecnologia para mapeamento ORM em .NET
• nHibernate: tecnologia de terceiros para ORM em .NET

WCF

• Tecnologia para componentização e exposição de serviços em ambiente .NET
• Especificar quais os protocolos suportados (HTTP/REST, SOAP, TCP, Named Pipes, entre outros)
• Suporta serviços que operam no IIS ou diretamente sobre o Windows (Service Host)

IIS

• Servidor Web
• Servidor de aplicações baseados em ASP.NET e código gerenciado .NET

Windows Azure

• Plataforma para hospedagem de aplicações para nuvens públicas e privadas
• Suporta .NET, Java e LAMP
• Linux e Windows

Tecnologias avançadas de plataforma .NET

Mensagens - MSMQ

Tecnologia para a criação de aplicações baseadas em mensagens em tecnologias Windows e .NET

Active Directory

Tecnologia para suporte a autenticação e autorização federada de usuários em aplicações

Suporte a LDAP e Kerberos

APP Fabric Caching

Tecnologia para suporte a cache distribuído de aplicações .NET

Microsoft BizTalk

• Barramento de serviço (ESB) com suporte intensivo a tecnologias Windows
• Possui mais de 30 conectores a recursos corporativos legados (ex SAP ou COBOL)
• Suporte a orquestrações BPMS

Plataforma LAMP

• Termo genérico que denota o desenvolvimento de aplicações em ambiente Linux, Apache httpD, MySQL e PHP;
• Generalizado para sinalizar o uso de tecnologias rápidas e simples para o desenvolvimento de aplicações Web;
• Generalizado para linguagens dinâmicas: python, ruby, groovy. 
• Banco de dados abertos: MariaDb ou PostgreSQL
•  Linux (SUSE, Redhat, outros) e Windows

PHP

• Linguagem para desenvolvimento de aplicações Web
• Valores: Simplicidade e produtividade
• Ambientes de produtividade com CakePHP suportam técnicas de aceleração com Scaffolding

Aplicações de scaffolding

• Ruby/Ruby on Rails
• Python/Django
• Groovy/Grails
• Java/Play Framework

Plataforma .NET

O que é o .NET Framework?

• Aplicações Gerenciadas - aplicações ficam num ambiente gerenciado
• .NET Framework - conjunto de bibliotecas que facilitam desenvolvimento de aplicações
• Sistema Operacional Windows - existem variações para linux também

Diferente do Java EE, que somente especifica as tecnologia e a implementação é feita por terceiros. A plataforma .NET fornece tanto as especificações como as implementações.

.NET tem suporte a multilinguagem, mais comuns são C# e VB.NET

Plataformas Java EE

Tecnologias básicas de Java EE

JSF

"A tecnologia Java Server Faces é um framework de componentes no lado servidor para interfaces de usuários Web baseada em tecnologia Java", Java EE 6 Tutorial

JSF é uma especificação, a implementação é o PrimeFaces, RichFaces, IceFaces.

Cuida da renderização de páginas web. É multicamadas e multi-plataforma. 

Servlets

"Um servlet é uma classe da linguagem Java que é usada para estender as capacidades de servidores que hospedam aplicações por meio de um modelo de programação requisição-resposta", Java EE 6 Tutorial

Faz a ligação entre a lógica de negócio e as páginas web. Faz roteamento, auditoria, transações

JAX-WS

"Provê a funcionalidade para serviços Web grandes baseado nos protocolos comuns WS-*", Java EE 6 Tutorial

Usado para integração com outros sistemas

É apenas uma especificação Apache CXF, JBOSS WebServices

JAX-RS

"Provê a funcionalidade para serviços web no estilo RESTful", Java EE 6 Tutorial

É apenas uma especificação, um exemplo de implementação é o Apache Jersey

JPA

"A API de persitência Java provê facilidades de mapeamento objeto relacional para gerenciar dados relacionais em aplicações Java", Java EE 6 Tutorial

Tecnologias avançadas de Java EE

EJB

É um componente servidor que encapsula a lógica de negócio de uma aplicação
Adiciona poderes a uma classe e permite que a aplicação se torne muito escalável.

Vantagens

• Controle transacional automático
• Capacidade de operar em ambientes distribuidos
• Facilita a montagem do estilo arquitetural de microserviços ou implantações SOA (é comparável ao WCF nesse sentido) 

JMS

É uma API Java que permite que aplicações criem, enviem, recebam ou leiam mensagens

É uma especificação e pode ser comparado ao MQServices da IBM ou MSMQ da Microsoft.

Implementação dessa especificação é o Apache MQ

JTA

Permite que aplicações acessem transações de uma maneira independente de implementações específicas.
É um controle de transação global, por exemplo, fazer o controle da transação para enviar dados a receita e salvar esses dados no banco local. Nesse caso, não adianta fazer controle da transação somente no banco de dados.

JCA

A arquitetura de conectores Java EE permite que componentes Java EE interajam com sistemas legados. Ex. SAPCC.
É uma alternativa mais avançada quando o JAX-WS ou JAX-RS não nos permite fazer a integração com sistemas legados.

Plataforma Java EE

É uma das principais plataformas para desenvolver Web e Distribuído. A plataforma Java EE pode ser representada por uma imagem:

O Java EE é na verdade um conjunto de especificações coordenado por um conjunto de empresas, por isso, o Java EE não representa uma tecnologia específica.

Os servidores de aplicação para o Java EE mais conhecidos são:

• Apache Tomcat
• JBOSS Web Server
• JBOSS Application Server
• IBM WebSphere WebServer
• IBM WebSphere Application Server
• Oracle Application Server

Estilos e Plataformas Arquiteturais

Plataformas arquiteturais

Representa um arranjo tecnológico das escolhas técnicas realizadas pelo time e que leva a implementação da solução no software.

Estilo arquitetural

A função de uma arquitetura vai determinar a forma do componente a ser montado. Analogamente, a arquitetura de uma casa a ser montada, vai refletir na sua forma. Portanto, uma casa com telhado fazendo um ângulo acentuado refletiu a intenção de evitar a neve se deposite no telhado da casa. 

A escolha do estilo arquitetural é a maior decisão na definição de uma arquitetura.

Alguns estilos arquiteturais:

• Cliente-servidor
• Baseado em cadastros web (Web 1.0)
• Aplicações Ricas de Internet (Web 2.0)
• Multicamadas (n-camadas)
• Baseado em integração de aplicações (EAI)
• Baseado em serviços
• Baseado em processos de negócio (BPMS)
• Baseado em computação em grade (grid computing)

Plataforma arquitetural

É um tipo particular de mecanismo de implementação. É uma solução que representa o primeiro grande produto técnico que vai ser escolhido na arquitetura.

Exemplos concretos

• Java EE
• .NET

Escolha de plataformas arquiteturais

Como as plataformas podem ser escolhidas?

Uma solução emocional é usar a tecnologia que já se conhece para ser aplicado em qualquer tipo de problema. Não é uma boa ideia.

Decisão estratégica: Escolha de um carro

• Antes de escolher um carro, deve-se compreender a real necessidade
• É importante definir quais os critérios devem conduzir a escolha

Necessidades para compra de um carro

• "Uso o carro para fins urbanos"
• "Sou casado e tenho três filhos"
• "Faço pequenas viagens e minha esposa carrega muita bagagem"
• "Meu orçamento é limitado a R$ 55.000"
• "Moro numa cidade quente"

É preciso fazer uma decisão racional!! Nem sempre a escolha final vai agradar, no caso da escolha do carro, sobrou um carro não muito atrativo. Mas a escolha racional é a mais certa de ser feita.

Através de "plugins" podemos modificar a plataforma escolhida para atender melhor nossos requisitos, no caso do carro, após o ter escolhido, podemos adicionar ar-condicionado, airbag, som, etc. No caso de uma plataforma arquitetural, após ter escolhida Java EE p.ex., pode optar por usar JSF ou PrimeFaces, hibernate ou JPA, etc.

Modelagem Arquitetural

Modelagem Arquitetural com modelo de visualização 4+1. O objetivo é permitir que arquitetos possam capturar, comunicar e expressar de uma forma simples e visual como arquitetura foi pensada para seus times.

• Visualização lógica - perspectiva do usuário final e representa os grandes blocos de construção de um software, os pacotes.
• Visualização de implementação - perspectiva para os desenvolvedores através de diagramas e componentes da UML
• Visualização do implantação - topologia física, descrita através do diagrama de implantação.

Visualização Lógica

Objetivo é capturar os principais elementos/módulo de um sistema e como estão relacionados.

Diagrama de pacote

O objetivo é exprimir como dois ou mais pacotes se comunicam ou dependem um do outro. 

• Dependência entre pacotes (linha pontilhada e seta aberta)
• Um pacote dentro do outro - todo/parte 
• O diagrama de pacotes permite expressar não só a decomposição funcional de um sistema como também padrões arquiteturais, p.ex. MVC.
• É possível expressar também uma arquitetura n-camadas.

Visualização de Implementação

• Expressa os componentes de uma aplicação
• Componentes são DLLs, libs, archives, assembly, JARs, WARs que constituem fisicamente uma aplicação

Diagrama de componentes

• Um componente na UML2 é uma classe estereotipada: <<component>>
• Um componente pode representar qualquer tipo de software como ex. um banco de dados, um servidor de aplicação, servidor web, DLL, JAR
• Dependência é igual aos pacotes (linha pontilhada e seta aberta)
• Através da ligação interface requerida e interface fornecida é possível expressar mais informações no diagrama, do que somente dependência. Ex. browser tem uma interface requerida HTTP e IIS tem uma interface fornecida HTTP.
• Quadrado no componente é chamado "porto"

Visualização de Implantação

Permite expressar a visão topológica, implantação ou rede de um projeto. Representa como um software vai ser instalado e manifestado dentro máquinas na rede onde será hospedado e acessado pelos usuários.

• Tem um caráter físico topológico, por isso fala de uma linguagem mais próxima da linguagem de produção, da infra.
• Permite expressar elementos de hardware, processadores, dispositivos e redes de comunicação.
• Permite mostrar onde os componentes vão residir.

"Nodo" como elemento básico

• É sempre um retângulo em 3D
• Representa um elemento físico, um hardware com capacidade de processamento, ex: iPhone 5S, Samsung Galaxy Tab 3, ATM, Servidor de Banco de Dados
• No diagrama a associação é representada como uma linha contínua
• Dentro de um Nodo, podemos ter vários componentes com dependência, etc.

Mecanismos Arquiteturais

Permite que o arquiteto possa escolher tecnologias de forma correto no projeto.

• Um mecanismo arquitetural representa uma solução comum para um problema recorrente.
• Um mecanismo liga requisitos arquiteturais a soluções técnicas, que podem ser expressas com a visão 4+1
• Os requisitos do projeto influenciam os mecanismos de análise, desenho e implementação.
• Mecanismos de analise: representa a solução independente de tecnologia
• Mecanismos de desenho: a solução com algum viés tecnológico
• Mecanismo de implementação: solução concreta

Exemplo

Requisito arquitetural:

Dados cadastrais devem estar disponíveis indefinidamente para consulta ou modificação.

Baseado nesse requisito, o mecanismo de analise seria a persistência dos dados, já que é uma solução comum no desenvolvimento de software.

Já o mecanismo de desenho, influenciado pelo de análise, terá algum viés tecnológico, ele poderia por exemplo ser um banco de dados relacional ou um arquivo de texto, mas ainda não tem o nome da tecnologia em si.

O mecanismo de implementação como terá uma solução concreta, esse requisito poderia ser implementado com o MS SQLServer.

Exemplo - Hotel ACME

Requisito arquitetural:

Usuários devem ser corretamente identificados

Restrições:

• A solução de segurança deve ser baseada em padrões abertos
• As senhas não devem trafegar sobre a rede
• A empresa já utiliza soluções Microsoft

Mecanismo de Análise

• Os projetistas estudam materiais técnicos sobre autenticação 
• A autenticação é a solução técnica (padronizada) para credenciar usuários do sistema

Mecanismo de Desenho

• As soluções Kerberos e LDAP são elencadas, pois são padrões abertos
• O Kerberos é escolhido, pois não trafega senhas sobre a rede.

Mecanismos de Implementação

• Dado que a empresa já possui produtos MS, escolhemos um produto MS que suporta o protocolo Kerberos
• Active Directory com Kerberos

Requisitos Arquiteturais

Requisitos arquiteturais

Não são requisitos não-funcionais. São requisitos que de alguma forma afetam a arquitetura.

Dado um requisito

O sistema deve ser rápido e capaz de processar grandes quantidades de requisições simultâneas

"Rápido" e "grandes quantidades" são atributos de qualidade chamados performance e escalabilidade, respectivamente. Ainda nesse requisito, fala de todo o sistema, ou seja, é muito genérico. O papel do arquiteto é transformar um requisito como esse em um requisito específico e mensurável. Um exemplo de um requisito esperto seria:

A tela de cadastro de usuários deve possuir um tempo de resposta menor que 8 segundos e suportar 20 usuários simultaneamente em horários de pico (15:00 às 19:00).

Modelo FURPS+

O modelo permite capturar e qualificar requisitos com completude ao longo do projeto.

Devemos capturar requisitos ao longo de cinco dimensões:

• Functionality - Funcionalidade
• Usability - Usabilidade
• Reliability - Confiabilidade
• Performance - Desempenho
• Supportability - Suportabilidade

Dimensão adicional que lida com restrições técnicas:

• Restrições ao desenho
• Restrições à implementação
• Restrições de interface
• Restrições físicas

Funcionais

Funcionalidade

• Lida com aspectos funcionais
• Requisitos funcionais que o sistema deve atender
• Geralmente relacionados ao domínio do problema
• Ex. pequisa de palavras chave do google (muito complexo)
• Segurança, ajuda on-line, log de auditoria, controle de licenças, envio e recebimento de e-mails, i18n, recursos de impressão e relatórios, recursos de work

Não funcionais: URPS

Usabilidade

• Qualidade da interação entre o sistema e o usuário final. Ex: Velocidade que o usuário entre e recupere informações, facilidade de aprendizado para usuários leigos. 

Reliable (Confiabilidade)

• É a disponibildiade do sistema. Qual o tempo que o sistema está disponivel? 
• Ex: um produto com disponibilidade de 99% do tempo ao longo de 24 horas. 
• Outro exemplo é a recuperação de falhas. Dado uma falha, qual o tempo que o sistema demora para se recuperar.

Performance (Desempenho)

• Está relacionado a dois itens: Vazão e Tempo de resposta
• Vazão: associada ao processamento em lote. Ex. processar folha de pagamento
• Tempo de resposta: tempo que o sistema demora pra fazer uma requisição.

Supportability - Suportabilidade

• Está relacionado aos aspectos internos do sistema, onde somente a equipe de TI consegue enxergar e não o usuário final.
• Ex: Manutenabilidade, sistema operacional

Restrições

Elementos que precedem um determinado produto ou escolha a ser feita. Ex: a empresa já usa um banco Oracle, ou a tela de dispositivo é de 3,5'.

• Restrição ao desenho: especifica e restringe as opções de arquitetura do sistema
• Restrição à implementação: especifica e restringe os aspectos de implementação de código
• Restrição de interface: É uma restrição de comunição. Ex. o sistema deve interoperar através de Webservice
• Restrição física: restrições de algum tipo de hardware

Visão Geral da Arquitetura de Software

Exemplo prático de arquitetura de software

Antes de aplicar a arquitetura de software para resolver um problema, deve analisar os condutores para se chegar nas soluções dos problemas desses condutores.

O que é uma arquitetura de software

"Arquitetura de software é o conjunto de decisões que, se feitas incorretamente, podem causar o cancelamento do projeto" - Eoin Woods

Tipos de arquitetos

• Arquiteto de soluções
• Responsável por trabalhar com times comercial e pré-venda na solução pré-liminar de um projeto. 
• Antes do projeto ser aprovado. 
• Faz a ponte entre outros arquitetos, em particular do arquiteto de software.
• Arquiteto de software
• Papel central: liderar a construção de uma arquitetura desde o primeiro dia do projeto
• Usa-se os requisitos críticos
• Toma decisões técnicas
• Arquiteto de dados
• Desafios como BI, ETL, etc.
• Tomada de desciões técnicas
• Arquiteto de Infraestrutura
• Ex.: computação nas nuvens
• Arquiteto de tecnologia Java EE
• Arquiteto de tecnologia .NET
• Arquiteto das nuvens

Conceitos sobre o arquiteto de software

• O arquiteto é um desenvolvedor sênior
• Falso
• Enquanto o desenvolvedor é um especialista, o arquiteto é um generalista.
• O arquiteto não é um desenvolvedor sênior

• O arquiteto domina as APIs de segurança Java ou .NET
• Falso
• Mas precisa dominar as táticas e soluções de mercado que ele vai trabalhar
• O arquiteto domina as táticas arquiteturais de segurança
• O arquiteto desenha plantas e o time de desenvolvimento implementa
• Falso
• O arquiteto junto com o time de desenvolvimento desenvolve cria plantas
• O arquiteto desenvolve a arquitetura
• Falso
• Ele desenvolve a arquitetura junto com time
• O time de arquitetura desenvolve a arquitetura

O que faz um arquiteto de software

Liderar a concepção do software...
...Definindo os atributos de qualidade.

Fornece apoio à construção do software...
...Baseado nos atributos de qualidade.

Decomposição típica das atividades de um arquiteto

• Coleta de requisitos (25%)
• Modelagem e implementação de provas de conceito (50%)
• Provas de conceitos são instrumentos para que arquitetos possam reduzir riscos
• Assistência ao time (25%)

O contexto na arquitetura de software

• É preciso olhar o contexto ambiental onde o arquiteto está envolvido para se tomar decisões arquiteturais. Ex. mudar de framework quando não se tem tempo, nem experiência.

Influências na arquitetura

• Contexto de negócio
• Qual a natureza do projeto que se está trabalhando? Se está trabalhado com um projeto de tempo fechado, não se pode ofender o prazo.
• Diretrizes e requisitos
• Captar as diretrizes do projeto como  escalabilidade, segurança, usabilidade que são elementos críticos.
• Restrições e premissas 
• Tempo, custo e muitas outras restrições. Ex. time júnior sem capacitação.
• Experiência do time
• Ignorar a experiência do time pode trazer consequencias graves no projeto.
• Soluções técnicas disponíveis
• São chamados de ativos arquiteturas. Podem ser elementos importantes para guia o arquiteto no caminho de boas soluções técnicas.
• Atributos de qualidade diversos
• Aspectos como segurança da informação, performance, usabilidade. É preciso conhecer esses atributos para se alcançar uma boa arquitetura

Decisões arquiteturais

"A vida de um arquiteto de software é uma longa sucessão de decisões sub-ótimas e parcialmente tomadas no escuro." - Philippe Kruchten

Pontos a serem observados ao tomar decisões

• Alinhamento estratégico
• nunca colocar a tecnologia na frente do negócio.
• Balanceamento de influências diversas
• experiência do time
• ativos da empresa
• contexto de negócio (diretrizes)
• Análise de riscos
• Processo decisório
• O que é melhor para o projeto e não o que o desenvolvedor quer fazer.

Processo de Testes

Verificação e Validação no MPS-Br

Nível D do MPS-Br

Objetivo: formalizar o processo de teste de software

Os resultados (da verificação e validação) são utilizados por avaliadores se a empresa atingiu os propositos dos processos de teste.

Validação

O propósito do processo Validação é confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.

O objetivo da validação é garantir que o produto correto está sendo desenvolvido. 

Resultados esperados

• VAL1 - Produtos de trabalho a serem validados são identificados
• VAL2 - Uma estratégia de validação é desenvolvida e implementada, estabelecendo cronograma, participantes envolvidos, métodos para validação e qualquer material a ser utilizado na validação.
• VAL3 - Critérios e procedimentos para validação dos produtos de trabalho a serem validados são identificados e um ambiente para validação é estabelecido.
• VAL4 - Atividades de validação são executadas para garantir que o produto esteja pronto para uso no ambiente operacional pretendido.
• A execução dos testes ao longo do processo é possível através de 4 etapas:
• Planejamento
• Projeto de casos de teste
• Execução
• Avaliação dos resultados
• VAL5 - Problemas são identificados e registrados
• VAL6 - Resultados de atividades de validação são analisados e disponibilizados para as partes interessadas.
• VAL7 - Evidências de que os produtos de software desenvolvidos estão prontos para o uso pretendido são fornecidas.

Verificação

O propósito do processo de Verificação é confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados.

Resultados esperados

• VER1 - Produtos de trabalho a serem verificados são identificados
• VER2 - Uma estratégia de verificação é desenvolvida e implementada, estabelecendo cronograma, revisores envolvidos, métodos para verificação e qualquer material a ser utilizado na verificação.
• VER3 - Critérios e procedimentos para verificação dos produtos de trabalho a serem verificados são identificados e um ambiente para verificação é estabelecido.
• VER4 - Atividades de verificação, incluindo testes e revisões por pares, são executadas.
• VER5 - Defeitos são identificados e registrados
• VER6 - Resultados de atividades de verificação são analisados e disponibilizados para as partes interessadas

Estratégias para testes de software

Estratégias para teste de software URL

• Testes de módulos atômicos
• Usa testes de caixa branca
• Testes de integração
• Testes de validação
• Caixa preta
• Testes de sistema
• Desempenho, segurança
• Testes de aceitação
• No ambiente do usuário

Testes de módulos atômicos

• Testar condições limite
• Todos os caminhos são testados (método caminho básico)
• Usa-se Drives que são chamadas aos módulos (que simulam um modulo ainda não testado)

Testes de integração

Consiste em se integrar os módulos do sistema. Possui duas abordagens:

• Bottom-up
• Parte para os módulos no nível mais baixo. Os módulos são agrupados em clusters para que fique mais fácil de testar e cria-se drivers que vão simular uma parte superior na estrutura da hierarquia dos módulos que ainda não foi testada. 
• Vantagem: São mais simples que o top-down.
• Top-down
• Parte para os módulos de nível mais alto. Há duas formas de percorrer os módulos para testes: Profundidade - testa-se verticalmente até chegar numa folha - e Largura no qual se testa horizontalmente cada nível. 
• Stubs = mock

Testes de validação

• Uma sequencia de testes de caixa-preta que demonstram a funcionalidade dos requisitos.
• Os casos de teste devem ser montados seguindo a especificação de requisitos
• Depois de realizar cada caso de teste, vão existir uma das opções
1. Teste é aceito 
2. Uma lista de deficiências é criada

Testes de sistema

Tem como objetivo colocar o sistema à prova. Tipo mais comuns:

• Testes de recuperação: forçar o sistema a falhar e ver a recuperação do sistema
• Testes de segurança: verificar os mecanismos de segurança do sistema. Senhas, proteção de acesso a funções. recomendável um especialista.
• Teste de stress: consiste em testar o programa em situações limite
• Testes de desempenho: realizado para testar os requisitos de desempenho descritos na especificação. Deve ocorrer ao longo de todos os passos do processo de testes. Confundido com teste de stress.

Testes de aceitação

Visam especificamente capacitar clientes a validar seus requisitos. Realizado exclusivamente pelo usuário final. 

• Alfa teste: realizado nas instalações do desenvolvedor
• Beta teste: realizado nas instalações do cliente

Revisões formais

As revisões capturam erros durante as etapas de desenvolvimento e evita que esses erros sejam descobertos no fim do desenvolvimento.

Tipos de revisões:

• Revisão de especificação é uma revisão em que os requisitos e especificações do usuário são revisados
• Revisão de interface do usuário: preocupa-se com os formatos de entrada e saída, layout de tela, relatório, posição dos componentes na tela, etc. Do campo IHC.
• Revisão de projeto é revisão dada nas decisões de implementação, arquitetura de software, técnicas empregadas, etc.
• Revisão de código: verifica o código fonte
• Revisão de teste: conduzidas para que os dados de teste sejam adequados ao sistema, não pra examinar a saída do teste.

Papeis:

• Apresentador: a tarefa é introduzir o produto, apresenta o produto numa reunião.
• Coordenador: responsável para que as atividades sejam organizadas e atua também como moderador.
• Secretário copista: tomar notas durante da revisão
• Oráculo da manutenção: rever o produto sobre manutenções futuras
• Portador de padrões: especialista em engenharia de software que verifica se normas e padrões estão sendo seguidos
• Representante do usuário: verifica se os requisitos estão sendo atendidos
• Especialista na área do sistema: verifica se o sistema está correto na área da especialidade. Ex.: folha de pagamento.

Responsabilidades do autor

• Anunciar sua intenção de fazer uma revisão
• Escolher participantes e coordenador
• Fornecer material apropriado para a revisão
• Escolher um produto que possa ser revisado em no máximo 60min.

Responsabilidades do coordenador

• Assegurar que a revisão aconteça;
• que os participantes atendam a revisão
• Distribuir o material para a revisão

Responsabilidades dos outros membros

• Ler documentação fornecida antes da reunião (1 hora)

Ao final da revisão:

• Coordenador notifica a gerencia
• É distribuída uma cópia da ata aos participantes
• Produtor vai realizar as ações descritas na ata

Testes de Caixa-Preta

3 métodos para geração de testes de caixa

Método 1: Partição de Classes de Equivalência

São casos de testes baseado na geração de valores típicos da entrada do programa.

Classe de Equivalência

É um subconjunto das entradas possíveis do programa

Passos do método:

1. Definir as condições de entrada
• Faixa de Valores: 1 < ITEM < 1000
• Conjunto ordenado: vetor de até 6 elementos
• Conjunto de Valores: Enum
• Condição booleana
2. Definir as classes de equivalência: conjunto de valores que se entra no programa
• Classe válida: 1 < ITEM < 1000
• Classe inválida: ITEM <= 1 e ITEM >= 1000
• As classes são divididas de acordo com o número de condições do programa
3. Identificação dos casos de teste
• Enumerar as classes de equivalência
• Fazer os casos de teste para as classes válidas, as vezes com poucos casos de teste já possível englobar um número grande de classes válidas. 
• Fazer os casos de teste para as classes inválidas, se for o caso, um caso de teste para cada classe inválida.

Método 2: Grafo de Causa e Efeito

É baseado na análise das entradas do programa e saídas possíveis. A diferença do primeiro é que são todas formatadas para um formato booleano.

Seja um programa simples que recebe dois tokens, as entradas possíveis são

1. Primeiro token MOVTOX
2. Primeiro token MOVTOY
3. Segundo token é a letra de A a Z

Efeitos identificados

70-Comando correto

71-Mensagem M1 (msg de erro significa não é o token MOVTOX ou MOVTOY)

72-Mensagem M2 (msg de erro significa não de token de A a Z

Método 3: Análise de valores de fronteira

Trabalha especificamente com os valores que estejam próximos aos intervalos de validade de entrada do programa. Testa valores focados nas fronteiras dos intervalos.

Princípio da Timidez: os bugs se encontram escondidos nos detalhes do programa.

Ex.: Se os extremos da faixa são os valores a e b, geramos os seguintes casos de teste:

• Entrada sobre a (sobre a fronteira inferior)
• Entrada sobre  a - um valor bem pequeno (um pouco abaixo da fronteira inferior)
• Entrada sobre b (sobre a fronteira superior)
• Entrada sobre b + um valor bem pequeno (um pouco acima da fronteira superior)

Introdução e Testes de Caixa-Branca

O objetivo principal de qualquer técnica de testes é maximizar a relação percentagem de defeito sobre o número de testes feitos. O ideal é fazer o menor número de teste e testar a maior parte do sistema todo.

Princípios

• Testar completamente é impossível
• Testar é um trabalho criativo e difícil
• Testes devem ser planejados e projetados
• Teste requer independência (sem vícios)

Conceitos

• Casos de teste: conjunto de entradas possíveis do programa
• Métodos de teste: métodos para se gerar casos de teste
• Caixa branca ou estruturais
• Caixa preta

Métodos de Testes de Caixa Branca

Cobertura Lógica

São critérios que devem ser obedecidos para determinar os casos de testes.

Fatores para escolha dos critérios:

• Complexidade do programa a se testar
• Estrutura do programa a ser testado
• Criticidade do programa a se testar
• Nível de confiança que se deseja atingir

Critérios

• Cobertura de comandos
• Todos os comandos que existem no programa a ser testado sejam executados
• Cobertura de decisões
• O teste deve passar por todas as decisões do programa nos dois casos (verdadeiro e falso) pelo menos uma vez.
• Cobertura de decisões-condições
• Cobertura de múltiplas condições
• Combinar todas as possibilidades nas duas decisões dadas no exemplo.

Método dos caminhos básicos

• Fortemente embasado na teoria de grafos
• Os casos de testes gerados passem por um número ótimo de caminhos entre a entrada e saída do programa

Definições

• Grafo de controle: descreve o fluxo do programa
• Caminhos independentes: é um caminho que não é constituído pela combinação de dois ou mais outros (não apresenta redundância).
• Existem 3 formas de se contar o número de caminhos independentes (Complexidade Ciclomática)
• Número de regiões: contar o número de regiões (blocos dentro do IF) e uma externa
• C = E -N +2 onde, C número de caminhos independentes, E número de arestas e N número de nós.
• Número de estruturas de decisão + 1

Geração dos casos de teste

Cada caminho independente gera um caso de teste

Gestão do Desenvolvimento de Software

Gerência de riscos

Risco, na área de TI está muito relacionado a questões de requisitos, comunicação, tecnologias, etc. São eventos incertos e se acontecerem podem ocasionar problemas, conhecidos como ameaça, ou podem ocorrer riscos positivos, conhecidos como oportunidade.

Devem ser identificados, quantificados e enfrentados se possível. Apresentam duas dimensões:

• Probabilidade de ocorrência 
• Impacto

A origem dos riscos, se deve a dois elementos: Incerteza e Complexidade.

É importante identificar os riscos, pois eles podem levar a:

• Possíveis perdas financeiras
• Podem levar ao fracasso de um projeto
• Pessoas podem ser afetadas 
• Patrocinadores não querem ver os riscos acontecendo
• Equipe deve estar preparada para enfrentar os riscos

O PMBOK define 6 processos para gerência de risco, mostrado a seguir:

1. Planejamento de riscos
• Se faz o planejamento de ações para gerenciar os riscos
2. Identificação dos riscos
• Se faz um estudo individualizado dos riscos
3. Análise qualitativa dos riscos
• Avalia a prioridade dos riscos identificados
4. Análise quantitativa dos riscos
• Atribuir valores aos riscos
5. Planejamento de respostas aos riscos
• Definir as ações que vão ser tomadas
6. Monitoramento e controle dos riscos
• Se faz o monitoramento e tratamento dos riscos

Planejamento e acompanhamento de projetos

• Projetos devem estar alinhados a estrategia da empresa
• Para acompanhar, é preciso, antes, planejar
• Metodologias de gerência de projetos são importantes para viabilizar essas atividades

Função de Planejamento

• Informática, função de apoio
• Estratégias empresarias refletem na informática
• Complexidade inerente a área
• Planejamento de necessidades e recursos devem ser rigorosos
• Diagramas de controle de projetos são fundamentais
• Riscos podem se tornar muito altos e até inviabilizar projetos

O problema básico do planejamento estratégico:

1. Saber pra onde ir -> meta
2. Definir como ir -> metodologia

Planejar um projeto significa estabelecer planos e monitorar resultados e dificuldades, a cada etapa do projeto, visando aplicar os conhecimentos e utilizar bem os recursos.

Planejamento requer diagnóstico da situação atual para elaboração de indicadores.

Relação entre planejamento empresarial e de projeto

• Estratégico: objetivos de longo prazo (mais de 3 anos) que definem metas
• Tático: ações de médio prazo (de 1 a 3 anos) que implementam metas estratégicas
• Operacional: programação de curto prazo (até 1 ano), execução de projetos/subprojetos

Metodologias de gerenciamento de projetos

• Uma boa metodologia de GP deve-se basear no conhecimento e na experiência
• Deve considerar 10 áreas de GP do PMBOK
• Deve ser adequada ao porte do projeto
• Definir a abordagem (foco): orientada a processo, a resultados, qualidade, etc.

Metodologias visam

• Criar padrões
• Definir como chegar aos objetivos
• Prover um checklist gerencial
• Definir o ponto de partida e os pontos de verificação (milestones)

Problemas que podem afetar uma metodologia de gerenciamento projetos

• Preocupação excessiva com procedimentos
• Menosprezar dificuldades
• Definir planos inexequíveis
• Definir recursos sub ou super dimensionado
• Não considerar o contexto
• Ignorar a importância da equipe

Estrutura geral de um projeto, deve passar pelos passos

1. Ambiente de projeto
2. Escopo e objetivos
3. Produtos a serem entregues
4. Todos envolvidos (stakeholders)
5. Análise de custo-benefício
6. Prioridades (projeto e tarefas)
7. Análise dos riscos
8. Detalhamento do projeto

Estrutura geral de um projeto

• Cronograma físico
• Cronograma financeiro
• Mapa de riscos
• Recursos
• Perfis e papéis da equipe
• Treinamentos
• Contratação de serviços

Produtos a serem entregues

• Definir o que será entregue ao cliente, em termos de produtos/serviços
• Os produtos entregues são detalhados nos objetivos do projeto
• A entrega dos produtos e/ou a prestação dos serviços é o objetivo final do projeto

Stakeholders (envolvidos)

• Clientes, fornecedores
• Outros gerentes
• Outros projetos
• Requisitos externos (leis, normas, etc)
• Assessorias/Consultorias
• Recursos
• Processos
• Tecnologias e padrões

Para saber se um projeto é viável, faz-se a análise de custo-benefício, levantando fatores, comparando com outros projetos, etc.

A prioridade do projetos deve ser discutida com o cliente e internamente, deve-se levar em conta a orientação estratégica, importância,  custo/benefício, urgência, etc.

Papel do gerente de projeto

1. Manter visão do projeto
2. Estabelecer comunicação
3. Focar nas metas do projeto
4. Construir um estilo de abordagem pró-ativo
5. Monitorar o projeto (tracking)
6. Gerenciar recursos
7. Tomar decisões pertinentes
8. Fazer o papel de coaching

Competências do gerente de projetos

• Dominar técnicas de gerenciamento de projeto
• Aceitar críticas construtivas da equipe
• Ter disposição para reuniões, seminários, cursos
• Procurar ajuda sobre questões de difícil solução

Métodos e técnicas de GP

• Gantt Chart
• Critical Path Method (CPM)
• Program Evaluation Review Technique (PERT)

Ferramentas de gerência de projetos

• Brainstorming
• Reuniões
• Cronogramas
• Gráfico de Gantt
• Diagrama de rede
• Planos de ação 5w2h
• Análise SWOT

Ferramentas computacionais para gerência de projetos

• WBS Chart Pro
• MindManager
• Microsoft Project
• Primavera Teamplay
• PMOffice
• Open Project Management
• Tassc Estimator Manager

Processos da gerência de projetos no MPS.Br

É aderente ao PMBOK, todos processos atendem ao processos do PMBOK.

• GPR1 - O escopo do trabalho para o projeto é definido
• GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados
• GPR3 - O modelo e as fases do ciclo de vida do projeto são definidos
• GPR4 - (Até o nível F) O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas
• GPR4 - (Até o nível E) O planejamento e as estimativas das tarefas do projeto são feitos baseados no repositório de estimativas e no conjunto de ativos de processo organizacional
• GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle são definidos e mantidos
• GPR6 - Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados
• GRP7 - Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo
• GPR8 - (Até o nível F) Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados
• GPR8 - (A partir do nível E) Os recursos e o ambiente de trabalho necessários para executar os projetos são planejados a partir dos ambientes padrão de trabalho da organização.
• GRP9 - Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição.
• GRP10 - Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos.
• GPR11- A viabilidade de atingir as metas do projeto é explicitamente avaliada considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados.
• GPR12 - O plano do projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido.
• GPR13 - O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados
• GPR14 - Os recursos materiais e humanos são monitorados em relação ao planejado.
• GPR15 - Os riscos são monitorados
• GPR16 - O envolvimento entre as partes interessadas no projeto é planejado, monitorado e mantido
• GPR17 - Revisões são realizadas em marcos do projeto e conforme estabelecidos no planejamento
• GPR18 - Registros de problemas identificados e o resultado da análise de questões pertinentes são estabelecidos e tratados com as partes interessadas
• GPR19 - Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até sua conclusão.
• GPR20 - (A partir do nível F) Equipes envolvidas no projeto são estabelecidas, mantidas a partir das regras e diretrizes para estruturação, formação e atuação
• GPR21 - (A partir do nível E) Experiências relacionadas aos processos contribuem para os ativos de processo organizacional
• GPR22 - (A partir do nível E) Um processo definido para o projeto é estabelecido de acordo com a estratégia para adaptação do processo da organização
• GPR22 - (A partir do nível B) Os objetivos de qualidade e de desempenho do processo definido para o projeto são estabelecidos e mantidos
• GPR23 - (A partir do nível B) O processo definido para o projeto que o possibilita atender seus objetivos de qualidade e de desempenho é composto com base em técnicas estatísticas, etc;
• GPR24 - (A partir do nível B) Subprocessos e atributos críticos para avaliar o desempenho e que estão relacionados ao alcance dos objetivos de qualidade e de desempenho do processo do projeto são selecionados
• GPR25 - (A partir do nível B) Selecionar medidas e técnicas analíticas a serem utilizadas na gerência quantitativa
• GRP26 - (A partir do nível B) O desempenho dos subprocessos escolhidos para gerência quantitativa é monitorado usando técnicas estatísticas e outras técnicas quatitativas
• GPR27 - (A partir do nível B) O projeto é gerenciado usando técnicas estatísticas e outras técnicas quantitativas para determinar se seus objetivos de qualidade e de desempenho do processo serão atingidos
• GPR28 - (A partir do nível B) Questões que afetam os objetivos de qualidade e de desempenho do processo do projeto são alvo de análise de causa raiz

Gerência de Configurações

A Gerência de Configuração tem por objetivo cuidar dos ativos de um projeto de software, tais como

• Programas;
• Documentação Técnica;
• Documentação Gerencial;
• Informações sobre projetos e indicadores;
• Etc.

No RUP, a disciplina que cuida dessa parte é a Gerência de Configuração e Mudança.

Exemplos de ferramentas de GC

• SVN
• Tortoise
• Subversion
• MS Sharepoint
• IBM Clearcase

Conceitos de gerenciamento de mudanças

• SCM (Gerência de Configuração) é uma atividade que abrange e é aplicada em todo processo de engenharia de um software. Como as mudanças podem ocorrer a qualquer tempo, as atividades de SCM são desenvolvidas para (1) identificar mudanças; (2) controlar mudanças; (3) garantir que a mudança esteja sendo adequadamente implementada; e (4) ressaltar a mudança a outras pessoas que possam ter interesse nela. Pressman
• Uma configuração descreve um estado temporal que um elemento se encontra. Deve conter todos elementos significativos daquele sistema, tais como, estado do hardware, do software, documentação técnica relevante, bibliotecas, etc.
• Controle de versão é o controle das revisões, mudanças na evolução de um item de produto. Objetivos:
• Automatizar o rastreamento de arquivos
• Prevenir conflitos de desenvolvedores
• Recuperar versões previas
• Permitir o desenvolvimento paralelo
• Auditar o desenvolvimento
• Reduzir o espaço de armazenamento
• Estabelecer relacionamento entre arquivos, versões e distribuições
• Gerencia de configuração controla as revisões, mudanças e dependências de um item de produto. Portanto, gerencia de configuração é mais amplo que controle de versão.
• Item de configuração são itens que devem ser mantidos sob o controle da gerencia de configuração. São itens individuais. Ex. versão da espec. de requisitos, código fonte, cronograma de projeto, planilha de verificação.
• Baseline é uma versão formalmente aprovada de um item de configuração, independente de mídia, formalmente definida e fixada em um determinado momento durante o ciclo de vida do item de configuração. Ou seja, é o estado inicial de configuração de um projeto. Os principais tipos, são:
• Funcional: proposta do desenvolvimento de sistemas
• Alocação: especificação de requisitos
• Projeto: especificação de implementação e revisão critica
• Produto: doc. de implementação, plano de teste e aceitação
• Operacional: doc. comprova a aceitação do usuário
• Repositório é um local sobre controle de acesso, onde são armazenados os itens de configuração de software.
• Build representa uma versão ainda incompleta do sistema mas com certa estabilidade. Inclui outros docs, além do fonte.
• Branches e Trunks, são ramificações laterais de versões que se originam de uma revisão da linha principal de desenvolvimento.
• Versão alfa, é uma versão produzida após um ciclo de desenvolvimento e utilizada em testes controlados
• Versão de homologação ou beta, é liberada aos clientes para testes
• Versão oficial, liberada comercialmente para clientes
• Versões emergenciais visa resolver bugs
• Checkout quando se obtém uma cópia da versão do arquivo para modificação e simultaneamente se impede o acesso a outros usuários. Checkin quando se cria uma nova versão do arquivo e se libera o acesso a essa nova versão.

Funções da Gerencia de Configuração

1. Identificação de configuração
• Tem como objetivo a seleção dos itens de configuração desejados;
• Definição de um esquema de codificação
• Descrição dos itens
2. Controle de configuração
• Permite o acompanhamento da evolução dos itens de configuração. Estabelece as atividades para que os itens possam evoluir de forma controlada:
• (1) solicitação de modificação, iniciando o ciclo de controle para uma manutenção
• (2) classificação da modificação
• (3) análise de impacto
• (4) avaliação da modificação pelo comitê de controle de configuração
• (5) implementação da modificação
• (6) verificação da modificação com relação à proposta de implementação levantada
• (7) atualização da baseline 
3. Contabilização de configuração
• Possui duas responsabilidades:
• (1) Armazenar informações geradas pelas demais funções
• (2) Permitir que as informações possam ser acessadas
4. Avaliação e revisão da configuração
1. Ocorre quando a baseline (gerada no controle de configuração) é selecionada para ser liberada para o cliente. Suas atividades são:
2. (1) Auditoria funcional da baseline
3. (2) Auditoria física de baseline
5. Gerenciamento de liberação e entrega
1. Construção: produzindo novos itens de configuração
2. Liberação: identificado versões particulares de cada item de configuração
3. Entrega: implantando produto no ambiente final de produção

Papeis, Artefatos e Atividades de GC

• Gerente de configuração: papel de controlar as configurações de software
• Auditor de configuração: responsável pela auditoria dos projetos
• Equipe de projeto: usuários da gerencia de configuração de software
• Bibliotecário: responsável pelo acesso a biblioteca de configurações (repo)
• Comitê Controle de Mudança: responsável pelas decisões de modificação

Gerência de Configuração MPS-BR

Pertence ao Nível F junto com as atividades de 

• Aquisição
• Garantia da qualidade
• Medição
• Gerência de portfólio de projetos

GCO é composta por 7 REPs (Resultados Esperados no Processo), apresentados a seguir:

• GCO1 - Um Sistema de Gerência de Configuração é estabelecido e mantido;
• GCO2 - Os itens de configuração são identificados com base em critérios estabelecidos;
• GCO3 - Os itens de configuração sujeitos a um controle formal são colocados sob baseline
• GCO4 - A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada;
• GCO5 - Modificação em itens de configuração são controladas;
• GCO6 - O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados;
• GCO7 - Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes.

O objetivo da GCO é estabelecer e manter a integridade de todos os produtos de trabalho de um projeto e disponibiliza-los para equipe.

Métricas e Estimativas de Projetos

Métricas, Estimativas e Modelos de software 

Qualidade

A avaliação da qualidade está relacionada a uma série de características intrínsecas do produto, ex.,

• Quantidade de bugs
• Conformidade com requisitos
• Desempenho
• Indicador de qualidade

Métrica

É a medição de atributos de um processo, projeto, etc. É também uma relação entre medidas.

Atividades de medição e análise são importantes para:

• Caracterizar ou permitir entender processos, produtos, recursos e ambiente.
• Avaliar para determinar o status do projeto, com respeito aos planos feitos
• Predizer valores observados possam ser utilizados para predizer outros
• Melhorar, identificando causas de problemas e ineficiências e oportunidades de melhoria

Escalas de mensuração

• Nominal: escala inicial, baseada em uma avaliação nominal
• Ordinal: baseada numa ordem pre-estabelecida. Ex prioridade mínima, média, max.
• Intervalar: baseada em intervalos. Ex temperatura
• Razão: existe uma relação natural entre os valores. Ex: Salário
• Nas métricas de software serão usadas basicamente as escalas de razão e ordinal

Algumas métricas conhecidas no desenvolvimento de software:

• Números de linhas de código 
• Número de pessoas para implementar um caso de uso
• Número de defeitos encontrados num produto
• Esforço necessário para realizar uma tarefa/projeto
• Tempo necessário para realizar uma tarefa/projeto
• Custo necessário para realizar uma tarefa/projeto
• Grau de satisfação do cliente

Objetivos

• Melhorar a previsibilidade e a chance de sucesso no projeto.
• Permitir melhor gerenciamento do projeto
• Reduzir pressões sobre cronogramas
• Apoiar decisões make or buy fazer/comprar
• Indicar a qualidade de um produto de software
• Avaliar benefícios
• Avaliar ROI

Características de uma boa métrica

• Facilmente calculada, entendida e testada
• Pode ser automatizável
• Deve ser útil para de estudos estatísticos
• Deve ser repetível, objetiva
• Capaz de indicar um caminho de melhoria

Classificação

• Métricas Diretas
• É aquela que é realizada em termos atributos observáveis. Números de linhas, número de erros, etc
• Métricas Indiretas
• São baseadas em medidas diretas. Ex. facilidade de manutenção, produtividade, esforço, tamanho baseado em funcionalidade. Não são observáveis diretamente.
• Métricas orientadas a tamanho
• São aquelas aplicáveis a contagem de tamanho de artefatos de software. Ex.: KLOC, número da páginas de documentação.
• Métricas orientadas à função
• Se baseia em métodos para medição de software do ponto de vista do usuário. Ex. Ponto de função, ponto de caso de uso, etc.

Análise de Pontos de Função (APF)

Consiste na contagem das funções que caracterizam um sistema, sob o ponto de vista do que ele faz para o usuário.

• Mede a funcionalidade entregue ao cliente (métrica indireta)
• Utiliza um método padronizado internacionalmente
• Pode ser usada tanto no início, no meio ou no final do projeto de software
• Útil para medição de produtos novos ou existentes, em evolução
• É baseado em função de dois tipos. 
• Dado: relacionam-se ao modelo de dados. Dividem-se em Arquivos Lógicos Internos (ALI) e Arquivos de Interface Externa (AIE)
• Transação: estão relacionadas "as transações realizadas no escopo da aplicação. Geralmente são captadas por meio de casos de uso. Dividem-se em Entradas Externas (EE), Saídas Externas (SE) e Consultas Externas CE).
• É uma métrica indireta e funcional.

O que deve ser contado num produto, segundo a APF?

1. Entradas: transações que alteram o estado do sistema. Ex: CRUD
2. Saídas: transações que enviam dados para fora do sistema. Ex: Arquivos de interface
3. Consultas: transações de consulta a bases de dados
4. Arquivos Lógicos Internos: arquivos mantidos pelo sistema
5. Arquivos de Interface Externa: arquivos externos que não são mantidos pela aplicação

Tipo de Contagem de PF

• Contagem Indicativa: feita no momento inicial do projeto com um modelo preliminar dos dados.
• Contagem Estimada: realizada quando se possui detalhes suficientes para fazer uma estimativa melhor. Quando se tem um modelo de funções básicas.
• Contagem Detalhada: bastante confiável, realizada quando se tem informações completas sobres as funções e dados.

Etapas do processo de contagem de pontos de função

1. Identificação das funções do sistema
2. Classificação de cada função de acordo com sua complexidade funcional
3. Cálculo dos pontos de função brutos através de pesos de acordo com uma tabela
4. Avaliação das 14 "características gerais" do sistema
5. Determinação do fator de ajuste (específico do projeto)
6. Cálculo dos pontos de função ajustados

Contagem por pontos de função

É feito por 5 etapas.

• Entradas
• São elementos que vão alterar algum estado dos dados na aplicação
• Saídas
• São funcionalidades que provem a troca de dados na saída de dados
• Arquivos lógicos internos
• São arquivos que armazenam informações da aplicação internamente
• Arquivos de interface externo
• São arquivos de outras aplicações que são apenas acessados
• Consulta
• Trazem dados que estão armazenados mediante uma seleção desses dados

Transações podem ser

• Entrada 
• Saída 
• Consulta

A produtividade de uma equipe pode ser determinada com a quantidade de horas gastas para disponibilizar uma quantidade de pontos de função.

Produtividade = Tamanho do Produto / Esforço

Obs.: Tamanho do Produto pode ser em diversas unidades, como PF/HH, PF/PM.

Esforço = Pessoas x Tempo

Prdutividade média é baseada em dados históricos, com a fórmula:

Qtd. Pessoas = Tamanho / (Produtividade x Tempo)

Itens de influência (Fatores de Ajuste)

1. Teleprocessamento
2. Processamento Distribuído
3. Performance
4. Carga de Máquina
5. Volume de Transações
6. Entradas de dados online
7. Atualizações online
8. Eficiência do usuário final
9. Complexiadade do processamento
10. Reutilização de código
11. Facilidade de implantação
12. Facilidade de operação
13. Facilidade de manutenção/alterações
14. Operação em múltiplos locais

Etapas para o cálculo da produtividade

• Medição do tamanho em pontos de função
• Registros históricos para determinar o escopo (medido em homens x hora)
• Calcular a produtividade obtida - Horas/PF ou PF/HH
• Estabelecer as produtividades médias para os diversos ambientes de desenvolvimento e tipos de projeto

Fatores que influênciam na produtividade de um projeto

• Inexperiência da equipe
• Gerenciamento ineficiente do projeto
• Requisitos instáveis
• Falta de metodologia 
• Tamanho do projeto

Métodos de estimativas empíricos

• Estimativa Ad-hoc
• Estimativa isolada. Projeto não está conectado a uma outra situação conhecida.
• Estimativa gerencial
• Gerente estima o prazo. Problema de prazo sub-dimensionado.
• Métodos ágeis
• planning poker, etc
• De equipe
• a própria equipe estima o trabalho
• Pode ser feita utilizando uma técnica chamada Delphi: cada pessoa faz uma contagem e depois tenta-se convergir os valores

Reflexões sobre estimativas de software

• Métricas são falíveis
• Mesmo assim é melhor ter métricas do que planejar no escuro
• Utilizar faixas de tolerância é uma recomendação
• Não se consegue boas estimativas no início do projeto
• Mesmo assim uma estimativa inicial deve ser feita
• Uma base histórica é o que faz a diferença para uma boa estimativa

Outras métricas

• COCOMO II
• Bom para estimar custo. Difícil de ser usado.
• Pontos de Caso de Uso
• Derivada dos pontos de função, mas usa atores e casos de uso.
• Pontos de histórias de usuário
• aplicada em histórias de usuário dos métodos ágeis
• COSMIC
• Nova geração de métricas. Não estabelece limites para medição de uma função. Mede não somente a camada da aplicação mas a infraestrutura.
• Deve ser aplicado quando há muita variação de escopo
• Deve ser aplicado com muitos pontos de função
• Propicia o aumento da previsibilidade e menor variabilidade na relação entre o tamanho, custo e esforço.

Princípios da Gerência de Projetos

Parte I

Separação entre os sistemas de produção existentes

1. Produção contínua: grande quantidade de produtos gerados (automoveis)
2. Produção por lote ou encomenda: menos produtos (fast food)
3. Produção por projeto: são feitos um a um e cada projeto tem seu resultado específico. (desenvolvimento de software, construção civil, etc)

4 P's

Elementos gerais que caracterizam a engenharia de software

• Pessoas: produzem
• Produtos: produtos inciais, intermediários e finais do projeto
• Processos: forma de produzir
• Projetos: instanciação de um projeto

Projeto

PMBOK define projeto como sendo um

Esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

VARGAS define como

Um empreedimento não repetitivo, caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade."

Exemplos de projeto

• Pirâmides do Egito
• Reconstrução de um país pós guerra
• Construção de um navio
• Informatização de uma empresa
• Turnê de uma banda

Principais atributos de um projeto

• Meta única
• Recursos humanos
• Escopo bem definido
• Início e fim determinados
• Tarefas bem definidas
• Intervenção humana indispensável
• Grupos de interesse envolvidos
• Recursos limitados
• Planejamento individualizado
• Execução controlada
• Normalmente é inovador
• Objetivos envolvem: prazo, custo, qualidade (pontos críticos)

Conceitos relacionados a projetos

• Empreendimento: sinônimo de projeto
• Programa: conjunto de projetos (ex. Programa de Aceleração do Crescimento)

Porque os projetos falham?

• Pessoas falham
• Falta de planejamento adequado
• Pressão excessiva de prazo e custo
• Falta de suporte ao gerente de projeto
• Equipe despreparada
• Comunicação

Separação de conceitos entre o que é projeto

Projetos são feitos onde e quando?

Exemplos de projetos 

• Desenvolvimento de software
• Manutenção de software (fazer um módulo novo)
• Aquisição de novos servidores
• Criação de rede local
• Customização de um aplicativo
• Prospecção de ferramentas
• Integração entre sistemas

Quando não se faz projetos?

Quando há rotinas. É Focada em resultados rápidos. As atividades são mais operacionais.

Exemplos

• Manutenção periódica ou corretiva
• Serviços de operação de servidores
• Serviços de helpdesk
• Atualização de versão de aplicativo
• Vendas da empresa estão paradas
• Banco de dados apresentando problemas

Parte II

PMBOK

Definição clássica de gerência de projetos:

Aplicação de conhecimentos, habilidades e técnicas para projetar atividades que visem atingir os requisistos do projeto

4 funções que todo gerente de projetos deve executar diariamente

• Planejamento: estabelecer metas, linhas de ação a ser seguidas
• Organização: combinar, juntar recursos Ex. organizar processo produtivo
• Direção: estabelecer um ponto onde se quer chegar. Transformar planos em atividades.
• Controle: acompanhamento do projeto.

Questões fundamentais sobre projetos

• Métrica
• Recursos limitados
• Qualidade
• Conjunto de resultados esperados
• Interface (com pessoas, outras áreas, fornecedores, clientes, etc)

Processos e artefatos

• Cronograma físico: planilha que representa o desenvolvimento do projeto temporalmente
• Cronograma financeiro: deve estar sempre atrelado ao cronograma físico. Como os investimentos serão distribuidos no projeto.
• Análise de riscos envolvidos (viabilidade): tem como resultado uma lista de riscos.
• Estudo de interfaces: como tratar as interfaces do projeto de maneira preventiva, corretiva e pró-ativa
• Análise de custo-benefício: verificar a viabilidade do projeto.
• Prioridade do projeto: prioridades do projeto e tarefas.
• Plano de Projeto: doc. contendo todos os dados gerenciais relevantes.
• Gerenciamento de tempo do projeto: 
• Ciclo de vida: importante definir um ciclo de vida para o projeto
• Fase: subdivisão do ciclo de vida
• Tarefa: menor que uma fase. Pode ser em partes menores chamadas sub-tarefas
• Pacote de trabalho: menor unidade de um projeto. É em que uma pessoa vai trabalhar
• Duração: todo projeto tem uma duração. Ao final do projeto se faz uma comparação entre a duração estimada e a real para saber sobre o sucesso do projeto.
• Precedência: determina a duração de uma tarefa. Pode ser inicio-incio, termino-inicio (espera uma tarefa terminar para começar outra), etc. 

Três questões básicas

1. As partes interessadas no projeto (stakeholders)
2. Aprender com o passado
3. Lei de Murphy (riscos)

PMBOK caracteriza um projeto como um conjunto de processos, que são agrupados em 5 grupos:

Visão de grupos de processos

• Iniciação: conjunto de atividades para definir o que deve ser feito. 
• Planejamento: atividade que envolve a determinação de como será feito. Definir um orçamento, conjunto de tarefas a serem feitas
• Execução: executar as atividades.
• Finalização: conjunto de tarefas que se encerra o projeto. Fazer um balanço, quais os ganhos e quais as perdas.
• Monitoramento e controle: atividade constante realizada pelo gerente de projeto.

Áreas de conhecimento do PMBOK (tópicos de conhecimento)

• Integração: cuida de interfaces (outros projetos, stakeholders, etc)
• Escopo: se preocupa a atender aquilo que o projeto se propõe a fazer
• Tempo: prazos para execução de um projeto
• Custo: trata da parte financeira do projeto
• Qualidade: cuida do que está sendo produzido
• Recursos Humanos: bom gerenciamento das pessoas
• Comunicação: informações do projeto
• Risco: identifica e trata riscos
• Aquisição: aquisições de um projeto
• Stakeholders: gerenciar os envolvidos no projeto

O que o PMBOK não é:

• Uma metodologia
• A verdade absoluta e imutável
• A única fonte de consulta de um gerente de projeto

Padrões de Projeto

Privilegia principalmente a reutilização

Padrão de projeto é uma solução padronizada para um problema que se repete muitas vezes dentro de um determinado contexto.

Padrões de criação

Diz respeito a padronizar a forma como os objetos são criados, compostos e representados.

Abstract Factory

Prover uma interface para criação de famílias de objetos relacionados ou independentes sem que se especifiquem suas classes concretas.

Factory Method

São métodos que retornam um novo objeto

Singleton

Obter somente uma instância de um objeto na aplicação.

Prototype

Quero que, dados dois objetos, eles sejam idênticos, mas não sejam a mesma instância.

a1 = a2 não funciona porque eles viram a mesma instância.

O Java já possui o método clone() que faz isso.

Padrões Estruturais

Estão relacionados a como classes e objetos são compostos de forma a gerar estruturas maiores e mais complexas.

Adapter

Com o adapter é possível por exemplo, trocar de uma biblioteca gráfica por outra sem grande impacto na aplicação.

Definir uma interface que a aplicação (cliente) vai usar, implementar essa interface e dentro da implementação chamar os métodos da biblioteca gráfica. Ex. adaptada.desenharBotao();

Flyweight

Dado um conjunto de pequenos objetos que possuem um atributo em comum, se cria apenas um objeto e todos os pequenos objetos apontam para o mesmo, economizando espaço em memória.

Proxy

Proxy representa uma visão diferente do objeto em questão. Por exemplo, um objeto representa uma imagem de satélite com alta resolução, cria-se o proxy desse objeto com a imagem de baixa resolução e posso manipular os dois da mesma forma, só que um é mais leve.

Façade

Dado que a aplicação precisa chamar a mesma sequencia de métodos em diversos locais diferentes, cria-se um Façade que faz essas chamas para aplicação e a aplicação só chama o Façade.

Composite

Representa estrutura de árvore. Um objeto pode ter nós que são da mesma interface Composite ou então ser uma folha.

Padrões Comportamentais

Estão relacionados ao comportamento dos objetos

Chain of Responsability

Uma vez que existe uma cadeia de objetos, e é necessário ser enviado uma mensagem para um desses objetos. Esses objetos vão encaminhando para o próximo objeto da sequência até que um objeto identifique que a mensagem é pra ele. É uma lista encadeada.

Arquitetura Orientada ao Modelo (Model Driven Architecture-MDA)

Arquitetura Orientada Ao Modelo

• Foi um paradigma criado pelo OMG em 2000
• Ciclo de vida é semelhante ao tradicional, cria-se os mesmos modelos das abordagens tradicionais.
• A ideia é iniciar um projeto de modelagem que vai ser num primeiro momento independente de plataforma, chamado:
• PIM - Platform Independent Model
• Logo depois, 
• PSM - Platform Specific Model
• E depois será convertido em código fonte.

Dentro do conceito de MDA, surge também o MOF - Meta Object Facility, que é uma instância do conceito de MDA.

MOF define uma linguagem abstrata e um framework para especificação, construção e gerenciamento de metamodelo. A UML implementa o MOF.

Tabela do MOF

• M3 - Nível mais alto de abstração. É a especificação de conceitos do modelo MOF
• M2 - Nível de implementação de linguagens como UML
• M1 - Mais comum. Onde os modelos são criados. 
• M0 - Nível das instancias que são criadas a partir desse modelo. Se temos uma tabela Produto, o nível M0 seria os registros dessa tabela.

XMI é uma especificação genérica que é possível exportar diagramas entre softwares diferentes (Argo e Rational)

EMF - Eclipse Modeling Framework

• É um framework que é utilizado para geração de aplicações dentro do conceito de MDA.
• Base para trabalhar com EMF é um doc XMI, Rational, java anotado, etc.
• É semelhante ao MOF mas definição é chamada "EMOF".

Constituído de dois frameworks fundamentais:

• Core Framework: suporte para criação de classes de implementação
• EMF.edit: suporte para edição do modelo

Implementação de software

Frameworks

É com a experiência dos programadores que foram surgindo os frameworks

Construir um software do zero é muito custoso, por isso se usa uma base já implementada

Benefícios de se usar um framework

• O benefício básico de se usar um framework é a produtividade
• Melhora da qualidade através da reutilização do framework, já que ele é mais usado e se detecta mais falhas

Com restrições de prazo e custo, os desenvolvedores devem-se utilizar de componentes, frameworks e padrões de projeto para realização do projeto

Definições

Framework é uma técnica que se beneficia de três características das linguagens de programação orientadas a objeto: abstração de dados, poliformismo e herança;

 O framework é uma arquitetura semi-acabada e passível de reutilização para um domínio de aplicação;

Framework é uma aplicação genérica que permite a criação de diferentes aplicações em um determinado domínio;

Um framework define uma arquitetura para uma família de sistemas, fornecendo partes predefinidas para sua construção;

Conceitos de Frozen Spots e Hot Spots

Frozen Spots: definem uma arquitetura global de um sistema que permanece inalterado em qualquer instanciação do framework;

Hot Spots: são pontos do framework onde ocorrem a especialização (definir classes adicionais para sobrepor métodos, etc.) e adaptação.

Esquema de HotSopts

• Uma classe abstrata de base, que vai definir a interface
• Classes concretas derivadas, representando cada uma das diferentes alternativas para os aspectos variáveis
• Parte opcional com relacionamentos e classes adicionais

Benefícios

• Modulariação
• Reutilização
• Extensão de interfaces
• Framework controla estrutura e abordagem do programa

UML-F 

Usada para fazer modelagem de frameworks e utiliza conceitos comuns e mecanismos de extensão (como estereótipos) da própria UML.

• Estereótipos
• São mecanismos para permitir adicionar novos blocos de construção semelhantes aos existentes
• É representado graficamente por << e >>
• Tag values
• São meios para proporcionar a criação de novas propriedades. É apresentado como uma sequencia de caracteres entre chaves, colocado abaixo de outro elemento.
• Restrições
• São mecanismos para especificar uma nova semântica de algum elemento UML. É representada como uma sequencia de caracteres colocada próxima ao elemento associado.

Hot Spots

Há três tipos de hot spots em um framework orientado a objetos:

• Métodos variáveis: possuem uma interface bem definida, mas que podem variar sua implementação de acordo com a instanciação do framework;
• Classes estendidas: podem ser estendidas durante a instanciação do framework, recebendo novos métodos;
• Interfaces estendidas ou classes abstratas: permitem a criação de subclasses concretas na instanciação do framework. Essas classes são chamadas de classes de aplicação.

Os três tipos podem ser estáticos (instanciação não é requerida em tempo de execução) ou dinâmicos (é requerida em tempo de execução)

Tags utilizadas em UML-F

• Variable: é aplicado aos métodos de uma classe e representa o hot spot Métodos Variáveis;
• Extensible: é aplicada a uma classe e indica o hot spot Classes Estendidas. 
• Incomplete: representa o hot spot Interfaces Estendidas. Colocada ao lado do simbolo de generalização;
• Tag appl-class: Complementa a definição de classes estendidas. Indica um aditivo na estrutura de um framework;
• static e dynamic: complementam a notação dos hot spots, indicando se o mesmo requer instanciação ou não.

Conceitos de Programação Orientada a Objetos

Conceitos Básicos de OO (cap. 1)

• Classes consistem na descrição de atributos e métodos para um conjunto de objetos. Possuem uma visão interna e externa (funções publicas).
• Interface pública são os serviços da classe que poderão ser utilizados por outras partes do programa, ocultando como os serviços são implementados. Essa ocultação é chamada encapsulamento.
• Objetos são entidades unicamente identificados. Eles são uma instancia concreta e dinâmica de uma classe. Possuem dados, comportamento e identidade da classe. Pode-se dizer que um objeto é "uma variável do tipo de dados definido pela classe".
• Os métodos de uma classe podem ser chamados de funções membros ou serviços.
• O estado de um objeto é determinado pelo valor de seus atributos
• Modificadores de acesso
• Público - visíveis em toda aplicação
• Privado - visíveis apenas internamente a classe que foram programados
• Protegido - visibilidade intermediária, visíveis apenas em uma hierarquia de classes (subclasses)
• Herança
• Criar classe mãe e classes filhas que especializam um determinado comportamento
• Herança múltipla: duas ou mais classes que possuem subclasses (java e c# não implementa esse conceito)

Linguagem Java - (cap. 3)

• Em java, um objeto é interpretado como uma referência e não o objeto propriamente dito.
• NomeClasse nomeObjeto -> cria-se referência mas não objeto; uma vez criado objeto com "new" a referência não pode ser manipulada numericamente.
• Construtor: iniciam o objeto
• Modificador "friendly" - visíveis apenas no mesmo pacote
• Membros estáticos: os atributos declarados como estáticos, possuem o mesmo valor durante a execução.
• Destrutores: são utilizados para finalizar um objeto.

Herança de Classe (cap. 4)

• Extends
• Atributos protegidos podem ser explicados depois que o conceito de herança de classe foi introduzido
• Membros protegidos podem ser acessados por classes do mesmo pacote mesmo que não sejam da mesma hierarquia de classes
• Podem ser acessados por classes que estendem dessa classe, mesmo que esta subclasse seja de outro pacote
• Membros protegidos se limitam a uma hierarquia de classes, uma vez que java não permite herança múltipla de classes
• Membros protegidos e estáticos podem ser acessados em qualquer classe estendida
• Construtores em classes estendidas
• Quando uma subclasse é construída, uma superclasse também é.
• A nova classe (derivada) deverá escolher qual construtor da superclasse deseja chamar
• Subclasse chama o construtor da superclasse através do super() com a mesma assinatura da superclasse

Polimorfismo (cap 5)

• Reescrever métodos com mesmo nome, parâmetros diferentes, etc.
• Palavra chave super, pode-se usar super.metodo()
• Palavra chave final, serve para definir atributos ou métodos que não podem ser modificados após sua primeira inicialização. 

Projeto nos Modelos de Qualidade

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)
2. 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
3. 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
4. Decidir como alcançar os objetivos (itens a trabalhar)
• Preciso demonstrar as características chave
5. 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.