Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Seminaro1-Engenharia de Software: Qualidade de Softwware

No description
by

Henrique Vignando

on 5 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Seminaro1-Engenharia de Software: Qualidade de Softwware

SEMINÁRIO Processo de Software
Gerenciamento de Projeto Software
Padrões de Qualidade
Qualidade de Software
Garantia da Qualidade de Software SEMINÁRIO – Tema 10 Aquitetura JEE
Processo de Software
Testes - TDD
Controle de Versão
IDE STS (SpringSource Tool) Alunos: Alex 59602
Henrique 55761 BSA - Better Solutions Agile Desenvolvimento: Construção Civil
Sistema: SCO (Sistema de Controle de Obras) Organograma BSA - Better Solutions Agile Scrum XP Virtual
Box SVN Scrum DB-Test Selenium Desenvolvimento
Orientado
Test Revisão
De
Código Builds
Frequentes Integração
Continua Tests
Automatizados Virtualização Gerenciamento
De
Config. Teste
não são
Uma Fase Feedback
Mais
Rapido Pronto
É
Pronto Ferramentas
Integradas Todos
são
responsaveis Principios Práticas Ferramentas Q Redmine Hudson Mapa de
Qualidade Arquitetura JEE JAVA EE
(Java Platform, Enterprise Edition)

Arquitetura de Referência Camadas Arquitetura JEE JDBC
(Java Database Connectivity), utilizado no acesso a bancos de dados.
JPA
(Java Persistence API), é uma API que padroniza o acesso a banco de dados através de mapeamento Objeto/Relacional dos Enterprise Java Beans. JTA
(Java Transaction API), é uma API que padroniza o tratamento de transações dentro de uma aplicação Java.
EJBs
(Enterprise Java Beans), utilizados no desenvolvimento de componentes de software. Eles permitem que o programador se concentre nas necessidades do negócio do cliente, enquanto questões de infra-estrutura, segurança, disponibilidade e escalabilidade são responsabilidade do servidor de aplicações.
JCA
(Java Connector Architecture), é uma API que padroniza a ligação a aplicações legadas. Servlets
São utilizados para o desenvolvimento de aplicações Web com conteúdo dinâmico. Ele contém uma API que abstrai e disponibiliza os recursos do servidor Web de maneira simplificada para o programador.
JSP
(Java Server Pages), uma especialização do servlet que permite que conteúdo dinâmico seja facilmente desenvolvido. Arquitetura JEE Camadas GORM API GORM - Hibernate - JBoss GSP, SiteMesh Spring – API Java
– API Groovy GSP HTML – CSS – JavaScript - Ajax Arquitetura JEE Framework Grails Controllers Aplicação G
r
a
n
t Domain Libraries Views Spring SiteMesh Service GORM Grails JVM Groovy Java Arquitetura JEE Contexto do JEE Processo de Software - Ágeis Extreming Programming
FDD – Feature Driver Development
DSDM – Dynamic System Development Method
Adapter Software Development
Crystal
Programatic Programming
Outros... Processo de Software - Scrum Processo interativo e incremental para gerenciamento de projetos complexos.
Pilares: Visibilidade, Inspeção e Adaptação Processo de Software - Scrum Papeis:
Product Owner
ScrumMaster
Time
Artefatos:
Product Baclog
Sprint Backlog / Dashboard
User Store
Burn-Down
Time Boxed Interations Processo de Software - Scrum Fluxo de Trabalho:
Planning
Daily Meeting
Review
Restrospective Processo de Software - Scrum BACKLOG DASHBOARD Processo de Software - Scrum Entrega de uma Sprint XP- eXtreme Programming TDD Testes de Caixa Preta
X
Testes de Caixa Branca TDD Teste de Caixa Branca
Teste Unitário
Teste de Integração Ciclo TDD TDD Mitos e Vantagens E desnecessario criar testes antes de codificar.
TDD é sobre testes de software.
TDD torna lento o ciclo de desenvolvimento . Na verdade ele encurta o cilco de feedback sobre as decisões de modelagem produzindo códigos menos acoplados. Exemplo TDD void testConstraints() {

mockDomain EnderecoDaObra

def enderecoDaObra = new EnderecoDaObra()
assertFalse enderecoDaObra.validate()

def endereco_ok =
new EnderecoDaObra(rua: "Av Colombo",numero: 34
,cep: "87062-240",loteamento: "12"
,numData: 1, quadra: "A1" )
assertTrue endereco_ok.validate()

} Teste Integração
def findAllElementosFilhosByDocumento {
//Carrega os dados para teste
Map dados = setup01();
Documento documento=dados.get("doc01")
//tearDown(dados)
return
dataService.findAllElementosFilhosByDocumento(documento)
} Teste Integração
@Test
void testFindAllElementosFilhosByDocumento() {
long time=System.currentTimeMillis()
List elementos = dataFixtureService.find AllElementosFilhosByDocumento()
time = System.currentTimeMillis() - time
assertTrue(time < MAX_TIME_ALLOWED)
assertNotNull(elementos)
assertTrue(elementos.size()>0)
} Teste Integração List findAllElementosFilhosByDocumento(Documento documento) {
List elementos = ElementoDocumento.executeQuery(
'select distinct ed from ElementoDocumento ed ' +
' where ed.documento = :documento ' +
' order by ed.pai, ed.ordemNumerica, ed.ordemAlfabetica ',
['documento':documento])
return elementos
} Controle de Versão Gerencia arquivos, diretórios e as modificações realizadas ao longo do tempo
Permite visualizar as alterações
Permite restaurar Conceitos Básicos Repositorio
Working-Copy
Checkout
Commit
Update
Merge
Revision
Head teste lib docs fonts leiame.txt delphi java Diretórios especiais trunk: armazena a versão funcional mais recente de desenvolvimento.
branches: armazena versões de desenvolvimento paralelo oriundas do trunk, porém isoladas deste. Deve ser utilizado quando uma implementação trazer o risco de afetar a integridade do trunk.
tags: armazena etiquetas para facilitar a localização de revisões. Cada etiqueta possui um nome único que a identifica, sendo criada como um diretório, sempre atra app trunk branches tags repository Nome do projeto Linha principal de desenvolvimento
Onde importaremos o projeto. Spring Source Tools - STS Spring Source Tools - STS Extensões
Grails
Groovy
Subversion
Outros... Perspectivas:
Spring
Grails
Databases
Team Synchronize
SVN Repository
Java EE
Outros... Dúvidas Perguntas Definição de Processo Organizacional
(Definição da padronização do próprio Scrum híbrido com XP)

Treinamento Organizacional
(Treinamento e serialização de pessoas conforme seus perfis, testes seletivos e conhecimento de perfis)

Gerenciamento Integrado de Projeto [definindo decisões de planejamento, interagindo uma lógica para melhores planejamentos em projetos futuros]

Gerenciamento de Riscos [identificar potenciais problemas antes que ele possa ocorrer, gerenciamento de risco deve acontecer em todo ciclo de vida do projeto, miniminizando ainda mais a ocorrência de possíveis riscos]

Análise de Decisão e Resolução CMMI e MPS.Br
(gerenciados pelo Scrum híbrido) Desenvolvimento de Requisitos
(Desenvolvimento dos Tickets-User Store pelo Team)

Solução Técnica
(Especificação (quebra em sub tarefas) das User Store e desenvolvimento apropriados a elas, desde de prototipação a testes)

Integração de Produto
(Reuso, sub produtos pré desenvolvidos)

Verificação [garantir que o produto está de acordo com os requisitos]
(Feedback rápido do cliente, testes funcionais)

Validação
(Entregas de Release eficientes, testes funcionais automatizados, testes de aceitação pelo PO)

Foco de Processo Organizacional [planejar e implantar melhorias no processo organizacional, com base nos pontos fracos e fortes]
(Reuniões de Retrospectivas ao final das Sprints) CMMI e MPS.Br
(gerenciados pelo Scrum híbrido) CMMI e MPS.Br
(gerenciados pelo Scrum híbrido)
Gerenciamento de Requisitos
(Definição do Product-Backlog com cliente, novas histórias oriundas de ciclo de release)

Planejamento de Projeto
(Ciclo de Plainnig Poker com PO, SM, e team. Definição das Sprints)

Acompanhamento e Controle de Projeto
(Gant, Dashboard, Burndown, Tickets-User Story, reuniões como dailiy meeting diárias, com definição do status do desenvolvimento do projeto pelo time)

Gerenciamento de Acordo com Fornecedor
(Releases ciclos de entrega das Sprints. Acordos de reuniões e treinamentos)

Medição e Análise
(“Não se pode grenciar oq não se pode medir”. Pontuação dos Tickets com base em estimativas, time tracker, gráfico de Grant)

Garantia da Qualidade de Processo e Produto
(Plainnig, Daily Meeting, Review, Retrospective; Definições de princípios e práticas organizacionais como: “programação orientada a testes, feedback rápido, integração de ferramentas, propriedade coletiva, code reveiw, integração continua (builds), virtualização”)

Gerência de Configuração
(Ferramentas de Auxílio: redmine, virtualbox, selenium, jUnit, svn (websvn), hudson, sonar, sts(IDE); Ferramentas de comunicação: email, chat, blogs, wiki, video conferência (google hangout), skype) Nível 1: Inicial (Ad-hoc);
Nível 2: Gerenciado / Gerido;
Nível 3: Definido;
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente;
Nível 5: Em otimização. Alunos: Alex Lima
Henrique Vignando Organização a Gestão e
Administração da Qualidade
(CMMI, MPS-BR, ISO, ...) Seminário – Tema 01 CMMI e MPS.Br
(gerenciados pelo Scrum híbrido) Desempenho de Processo Organizacional [estabelecer e garantir padrões de qualidade no processo, definido por medições no processo]

Gerenciamento Quantitativo de Projeto [manter um entendimento quantitativo do modelo de gerenciamento do projeto oferecendo assim baselines como artefatos] Documentação;
Gestão de Configuração;
Garantia de Qualidade;
Verificação;
Validação;
Revisão Conjunta;
Auditoria;
Resolução de Problemas. Dimensão de Processo
Dimensão de Capacidade Conhecida como SPICE, é um melhoramento do ISO/IEC 12207.
É uma norma para definir um processo de desenvolvimento de software. Processos Fundamentais
Processos Organizacionais
Processos de Apoio Baseado nas normas ISO/IEC 12207 e ISO/IEC 15504
Focado na realidade do mercado brasileiro (compatível com CMMI)
A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado. Premissa: "A qualidade é influenciada pelo processo" Versão Atual: 1.3

Systems Engineering (SE)
Software Engineering (SW)
Integrated Product and Process Development (IPPD)
Supplier Sourcing (SS) Representação Contínua
Representação por Estágios Administração Time Organização Gestão Produto Processo Qualidade O que uma empresa
precisa ser e/ou ter para tira
certificações como:
CMMI,
MPS-BR,
ISO... ? Inicia-se algumas definições importantes para uma gestão de qualidades:
Processos Fundamentais;
Organizacionais;
Apoio. Stap by stap Sem gerenciamento ou pouco gerenciado com pequenas definições no seu processo. CMMI Nível 1
MPS.Br Nível - CMMI (Capability Maturity Model Integration) Representação por Estágios: INÍCIO (Ad-hoc) Nível 2 – G e F (Gerenciando) MPS.Br (Melhoria de Processos do Software Brasileiro) ISO/IEC 15504 Gerenciamento de Software segundo SOMMERVILLE 9ª Edição Gerenciameto de Projetos

Planejamento de Processo

Gerenciamento de Qualidade

Gerenciamento de Configuração

Melhoria de de Processo “O CMMI reconhece que o mais importante é a meta e não a maneira como ela é alcançada.” Sommerville 9ª edição Nível 4 – B (Quantitativamente Gerenciado) Nível 3 – D e C (Definindo) Nível 3 – D e C (Definindo) Como organizar
minha Gestão?
Por onde começar? Nível 5 – A (Otimização) Gestão de Processo Organizacional []

Análise Causal e Resolução [] Application lifecycle management(ALM)
Gerenciamento de Ciclo de Vida de Aplicativos Gerenciamento Continuo do Software
Casamento da gestão de negocio com a engenharia de software.

Requer ferramentas integradas para gerenciar:
Requisitos;
Repositório de Código;
Construção Integrada;
Arquitetura e Codificação;
Testes e Qualidade;
Gerenciamento de versões e componentes; Rastreabilidade e dados post-hoc;
Cultura de planejamento de releases/backlog;
Gerenciamento integrado;
Simplificação nos processos;
Agilidade na construção do software;
Aumento na cultura de testes;
Aumento da reusabilidade;
“Gerenciar sem backlog é como ser um mecânico que recebe carros para conserto sem que expliquem o problema do carro.” Vantagens – A.L.M Pilha A.L.M open-source Oferece esta pilha como SaaS rodando na Amazon.
Redmine,SVN,GIT,Hudson,NexusintegradoscomLDAPéumenormediferencia Tools Cloud Sub-categorias: Apresentando 7 níveis de maturidade: ALM = Album de fotografiado seu software, com retratos tirados automáticamente a cada mudança falha, novo requisito, novo release, etc. ALM Gerenciamento de Requisitos com :
Gestão de pendências;
Gerenciamento de horas gastas/timetracking;
Integração com SVN;
Conceito de projetos e sub-projetos;
Fórum, wiki, arquivos, news, calendário, gantt charte sistema de segurança;

Software open-source construído em RubyonRails;
Utiliza My SQL por default podendo usar outros RDBMS;

Centenas de plug-ins e módulos adicionais;
Muitas possibilidades de customização; Rastreabilidade Visibilidade Transparência Inspeção Adaptação
Full transcript