ACEITE DE SOFTWARE NA VISÃO DO CLIENTE: GARANTINDO A QUALIDADE DOS PROJETOS DE SOFTWARE Resp:Marcelo Nascimento Costa, MSc Sejam Todos Bem-Vindos 1
ORIENTAÇÕES INICIAIS Dê preferência ao uso de uma conexão de banda larga Feche qualquer outro programa que possa interferir na transmissão de áudio ou na conexão de Internet. O evento não fará uso do vídeo (webcam), somente slides e áudio Se necessário, ajuste o idioma da sala na barra de ferramentas superior O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas Você pode mandar suas perguntas pelo chat ao longo da apresentação Para quem possui a certificação PMP, o evento vale 1 PDU A apresentação será gravada e o vídeo publicado posteriormente no site e redes sociais:
MISSÃO Apoiar nossos clientes a ter mais visibilidade do desempenho de seus processos de software e a estabelecer modelos de negócios em que eles tenham o controle sobre os mesmos. DIRECIONAMENTO ESTRATÉGICO COM: Estimativas e Medição de Projetos de Software Implantação da Análise de Pontos de Função (IFPUG, NESMA, COSMIC) Auditoria de Medições de Projetos de Software Medidos com APF Benchmarking e Análises de produtividade Avaliação para Melhoria dos Processos de Software Engenharia de Requisitos Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade) Construção e Monitoramento de Contratos de Software baseados em Resultados Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando Métricas Funcionais
FORMAÇÃO PROFISSIONAL APF: Fundamentos, Benefícios e Implantação 8 horas (EAD e presencial) Capacitação em APF: Medição e Estimativa de Software 16 horas (EAD e presencial) Workshop APF: Metodologia e Práticas de Medição 16 horas (Presencial) Curso Aceite de software garantindo a qualidade dos projetos de software 24 horas Preparação para o Exame CFPS 96 horas (EAD e presencial) Medição e Estimativa de Software com o Método COSMIC 16 horas (Presencial) Oficina de Contagem de Pontos de Função Sessões de 8 ~ 40 horas Curso Teste de Software: entregando projetos com qualidade 24 horas Preparação para o Exame COSMIC 16 horas (EAD e presencial) Engenharia de Requisitos de Software 24 horas Oficina de Requisitos Sessões de 8 ~ 40 horas Estimativa de Projetos de Software: Fundamentos e Técnicas 16 horas Introdução ao Gerenciamento de Projetos 16 horas Gestão de Riscos em Projetos 16 horas Mais de 14.000 alunos capacitados O livro mais vendido de APF no país foi escrito por nós Formou >25% dos CFPS no Brasil
Objetivos do Webinar Apresentar a importância da aceitação do software para uma organização Como o modelo de qualidade aborda a aceitação de software Dois tipos de abordagens utilizadas para aceite de software: Revisões de Software Visão Estática Testes de Software Visão Dinâmica Automação do Aceite de Software 5
Agenda 1. O porquê do aceite de software 2. Verificação e Validação de Software 3. Revisão Estática e Dinâmica 4. Automação do Aceite de Software 6
O porquê do Aceite Vários projetos são implantados sem atingir os objetivos de negócio previamente estabelecidos Atividade considerada isolada realizada ao final do processo de desenvolvimento de software Alto grau de contratação de terceiros pela maioria das organizações no desenvolvimento de software Forte dependência da validação dos artefatos de software do contratante para corrigir e direcionar o desenvolvimento do software adequado para a organização. 7
Validação Esclarecendo a definição: Validação: Estamos construindo o produto certo? ; O software deve atender às necessidades dos usuários. Verificação: Estamos construindo certo o produto? ; Os artefatos construídos devem estar de acordo com a especificação do software. 8
ACEITAÇÃO DO CLIENTE NA VISÃO E AS VERTENTES METODOLÓGICAS 9
Planejamento Aceite na Estratégia Sequencial Marco Requisitos Marco Projeto (Design) Marco Todas as atividades são executadas a partir de uma única disciplina na fase Ciclo de entrega mais longo. Risco de erros serem descobertos tarde Dificuldade para acomodar mudanças ao longo do projeto Codificação e Teste Marco Integração Marco Teste de Sistema 10
Aceite na Estratégia Iterativa e Incremental iteração #1 iteração #2 iteração #3 modelagem de negócio requisitos análise e projeto modelagem de negócio requisitos análise e projeto modelagem não pressupõe de que negócio todo o trabalho de uma disciplina deve estar concluído antes requisitos que haja atividade de outra disciplina análise e projeto implementação Mudanças são mais facilmente tratadas teste ao longo do planejamento das iterações seguintes entrega implementação teste entrega implementação teste entrega 11 11
E os Testes nas em Metodologias Ágeis? Planejamento Sprints Ciclos Reunião diária do Scrum 24h Encerramento Sprint Backlog Acúmulo de tarefas pela equipe 30 dias Levantamento de prioridades do produto Nova demonstração de funcionalidade Homologada pelo Usuário 12
Verificação e Validação & Testes REVISÕES DE SOFTWARE 13
Introdução VV&T Principais Métodos para Validação e Verificação: Validação: Revisões de Software. Testes de Software Verificação: Estática: Revisões de Software. Dinâmica: Testes de Software. 14
Introdução VV&T Curiosidades: Inspeções aumentam significativamente a produtividade, qualidade e estabilidade dos projetos (Fagan, 1976). Uma combinação de diferentes métodos de V&V apresenta melhor desempenho do que qualquer método isoladamente (Hetzel, 1976 & Meyer, 1978). Qualidade melhora a produtividade (Mills, 1983). Prevenção de defeitos é melhor do que remoção de defeitos (Mays, 1990). Corrigir um defeito após a entrega do produto é freqüentemente 100 vezes mais caro do que corrigi-lo durante as atividades de requisitos e projeto do sistema (Boehm, Basili, 2001). 15
Revisões de Software Definição: Processo ou atividade para leitura de um artefato de software visando assegurar que ele cumpre sua especificação e atende às necessidades de seus usuários. Objetivo: Realizar validação e verificação estática de artefatos de software. Pode ser aplicada a qualquer artefato produzido ao longo do processo de desenvolvimento de software. Tipos de Revisão de Software: 4.1 Inspeções de Software. 4.2 Walkthroughs. 16
Inspeções de Software - Revisão Benefícios e Custo de Inspeções: Inspeções vêm sendo utilizadas há mais de duas décadas; Existe evidência experimental de sua usabilidade e adequabilidade; Provêem um bom meio para o gerente do projeto monitorar a qualidade e progresso do projeto; Podem amenizar atividades de manutenção, evitando que erros se propaguem pelo ciclo de vida; Apresentam baixo custo devido ao fato do revisor não precisar investir muito tempo ou mesmo não demandar ferramentas sofisticadas para realizá-las. Entretanto uma alta taxa de atividades de inspeção ao longo do processo pode acrescer de 5% a 10% o custo final. 17
Inspeções de Software: Benefícios Identificação mais cedo de defeitos. 18
Inspeções Assíncronas Reorganização do Processo de Inspeção de Software (Sauer et al., 2000) 19
Walkthroughs Alternativa com um processo menos rigoroso do que o de inspeções de software. Papéis sugeridos: Líder, Autor, Escrivão e Revisores Procedimento: Os participantes são guiados através dos artefatos pelo líder (que eventualmente é o próprio autor) em uma reunião. Durante esta reunião devem interromper a apresentação caso encontrem defeitos. Muitas vezes condições de entrada e saída e decisões são pressupostos pelo líder que segue sua linha de raciocínio durante a apresentação. 20
Walkthroughs Possuem custo aproximadamente igual ao de inspeções mas seus resultados são inferiores (SEI, 2005): Não providenciam resultados mensuráveis; Não fornecem base para a aplicação de controle estatístico de processos, necessário para evoluir na maturidade de processos de software. Podem ser utilizados para atividades de brainstorming, para explorar alternativas de projeto e resolução de problemas. Inspeções são mais focadas em encontrar defeitos. 21
AUTOMATIZANDO O ACEITE DE SOFTWARE 22
BDD Desenvolvimento orientado a comportamento Uma técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação. Foca se o comportamento do código implementado está de acordo com os requisitos de software definidos pelo usuário A linguagem de negócio usada em BDD é extraída das estórias ou especificações fornecidas pelo cliente durante o levantamento dos requisitos Melhora a comunicação entre o que deve ser desenvolvido (desenvolvedores) e o que deverá ser testado e homologado (testador e usuário)
Definição de História do Usuário no Jbehave Specification By Example
Mapeamento para o Código Java 25
Conclusões Com a crescente terceirização do desenvolvimento do software a aceitação é obrigatória para o software se adequar as necessidades de negócio do cliente Não pode ser uma atividade isolada e deixada para a última fase do processo Automatizar também uma alternativa com testes de regressão em todos os níveis: Unitário, Integração e Funcional.
www.fattocs.com.br/blog/ facebook.com/fattocs @fattocs 27