Curso de Engenharia de Computação GARANTIA DE QUALIDADE DE SOFTWARE EM PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR NÍVEL F

Tamanho: px
Começar a partir da página:

Download "Curso de Engenharia de Computação GARANTIA DE QUALIDADE DE SOFTWARE EM PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR NÍVEL F"

Transcrição

1 Curso de Engenharia de Computação GARANTIA DE QUALIDADE DE SOFTWARE EM PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR NÍVEL F Michelle Scarassati Campinas São Paulo Brasil Dezembro de 2009

2 Curso de Engenharia de Computação GARANTIA DE QUALIDADE DE SOFTWARE EM PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR NÍVEL F Michelle Scarassati Monografia apresentada à disciplina de Trabalho de Conclusão do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Esp. Ricardo Cesar Boaretto, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Esp. Ricardo Cesar Boaretto Campinas São Paulo Brasil Dezembro de 2009

3 GARANTIA DE QUALIDADE DE SOFTWARE EM PROJETOS SCRUM ADAPTADOS AO MODELO MPS.BR NÍVEL F Michelle Scarassati Monografia defendida e aprovada em 17 de Dezembro de 2009 pela Banca Examinadora assim constituída: Prof. Esp. Ricardo Cesar Boaretto (Orientador) USF Universidade São Francisco Itatiba SP. Bel. em Análise de Sistemas Lilian de Oliveira Campos (membro externo) Prof. Ms. José Aparecido Carrilho USF Universidade São Francisco Campinas SP.

4 Dedico esse trabalho aos meus pais, ao meu namorado e a minha família que muito me apoiaram e me ajudaram nessa longa caminhada.

5 .Agradecimentos Agradeço primeiramente a Deus por ter me dado forças para chegar ao final do curso e ter me iluminado todos os dias dessa longa caminhada. Agradeço aos professores da Universidade São Francisco de Campinas por terem me passado todo o conhecimento e por terem sido importantes para a minha formação acadêmica. Agradeço também ao Prof. Esp. Ricardo Cesar Boaretto por ter me orientado no trabalho de conclusão de curso e ter me ajudado nessa etapa final e muito importante para minha formação. Pelos seus conselhos, dedicação e paciência. Agradeço ao coordenador do curso André Leon por ter me ajudado durante toda essa caminhada, apoiando e ajudando sempre que foi preciso. Agradeço a todas as pessoas da Dextra Sistemas, empresa onde faço estágio, pela oportunidade que me forneceram e por toda a ajuda para tornar real esse estudo feito por mim. Agradeço também aos meus pais, meu namorado e toda minha família pela paciência que tiveram comigo, nos meus momentos de stress, no nervosismo das vésperas de provas, na ansiedade da espera da divulgação das notas, e nesse final pelo entendimento dos meus nãos para poder me dedicar a esse trabalho de conclusão de curso. v

6 O ENGENHEIRO planeja, ensaia, testa e projeta, calcula, faz e constrói, estuda, ensina e arquiteta, acompanha, fiscaliza, coordena, realiza. Sua Missão e Intuito consistem em melhorar a qualidade dos sistemas produtivos, criando oportunidade, para o desenvolvimento, aumentando o rendimento, a luz, a prosperidade para cada um. Seu ideal é exercer a profissão, com cuidado, entusiasmo, com fé e convicção, com ética, dignidade, transparência, lealdade, com amor e devoção. vi

7 Sumário Lista de Siglas... ix Lista de Figuras... xi Lista de Tabela... xiii Resumo... xiv Abstract... xv 1 INTRODUÇÃO Contextualização Definição do problema a ser tratado Estrutura do Texto FUNDAMENTAÇÃO TEÓRICA Conceitos fundamentais Processo Processo de Desenvolvimento de Software Modelo Cascata Modelo Iterativo e Incremental RUP (Rational Unified Process) Qualidade Qualidade de Software Qualidade de Produto Qualidade de Processo Modelo de Qualidade de Software MPS.Br (Melhoria do Processo de Software Brasileiro) Metodologia ágil de desenvolvimento de software SCRUM O Manifesto Ágil O esqueleto do SCRUM Atividades e Fluxo do SCRUM Estudo de Caso O processo SCRUM da empresa PowerLogic ELABORAÇÃO DA SOLUÇÃO Histórico da Dextra Sistemas Motivação para a elaboração de um processo para projetos SCRUM na Dextra Processo SCRUM da Dextra Sistemas SCRUM Dextra Atividades de Garantia da Qualidade Atividade Realizar Auditoria de Processo Atividade Realizar Auditoria de Produto Atividade Disponibilizar Relatório de Auditoria Atividade Acompanhar as Não Conformidades (NC) Atividade Consolidar todas as Auditorias Realizadas vii

8 3.5 SCRUM Dextra Produtos de Trabalho de Garantia da Qualidade CONCLUSÃO Contribuições Trabalhos futuros Apêndice 1 Ferramentas EPF Composer TRAC Referências Bibliográficas Bibliografias Consultadas viii

9 Lista de Siglas ABNT AP AQU BID CD CMM CMMI CPU DVD EPF FINEP GCO GPR GQA GRE IBM IEC IEEE ISO MA MCT MED MN MPS.Br Associação Brasileira de Normas Técnicas Atributos de Processo Aquisição Banco Interamericano de Desenvolvimento Compact Disc (Disco Compacto) Capability Maturity Model (Modelo de Maturidade de Capacidade) Capability Maturity Model Integration (Integração do Modelo de Maturidade de Capacidade) Central Processing Unit (Unidade Central de Processamento) Digital Video Disc (Disco Digital de Vídeo) Eclipse Process Framework (Estrutura de Processo Eclipse) Financiadora de Estudos e Projetos Gerência de Configuração Gerência de Projetos Garantia da Qualidade Gerência de Requisitos International Business Machines (Máquinas Comerciais Internacionais) International Eletrotechnical Commission (Comissão Internacional de Eletrotécnica) Institute of Electrical and Electronics Engineers (Instituto de Engenheiros Elétricos e Eletrônicos) International Organization for Standardization (Organização Internacional para Normalização) Método de Avaliação Ministério da Ciência e Tecnologia Medição Modelo de Negócio Melhoria de Processo do Software Brasileiro ix

10 MR NC PDCA Modelo de Referência Não Conformidade Plan, Do, Check, Action (Planejar, Executar, Verificar e Atuar corretivamente) ProUD PSP QA RAP ROI RUP SEPG Processo Unificado Dextra Personal Software Process (Processo de Software Pessoal) Quality Assurance (Garantia da Qualidade) Resultados dos Atributos de Processo Retorno do Investimento Rational Unified Process (Processo Unificado da Rational) Software Engineering Process Group (Grupo de Processos de Engenharia de Software) SOFTEX SPICE Associação para Promoção da Excelência do Software Brasileiro Software Process Improvement and Capability determination (Melhoria e Capacidade de Determinação do Processo de Software) TI TQC Tecnologia da Informação Total Control Quality (Controle da Qualidade Total) UML Unified Modeling Language (Linguagem de Modelagem Unificada) x

11 Lista de Figuras FIGURA 2-1: CICLO PDCA DE CONTROLE DE PROCESSOS [3]... 6 FIGURA 2-2: DETALHAMENTO DO CICLO PDCA NOS CICLOS DE MANUTENÇÃO E MELHORIAS [3] FIGURA 2-3: MODELO CASCATA DE DESENVOLVIMENTO DE SOFTWARE. (FONTE: SITE - 9 FIGURA 2-4: MODELO ITERATIVO E INCREMENTAL DE DESENVOLVIMENTO DE SOFTWARE. (FONTE: SITE - F) FIGURA 2-5: PROCESSO RUP [4] FIGURA 2-6: ESTRUTURA DE NÍVEIS DO MPS.BR E COMPARAÇÃO COM OS NÍVEIS DO CMMI. (FONTE: SITE FIGURA 2-7: ESTRUTURA DO MR-MPS DO MODELO DE QUALIDADE MPS.BR [17] FIGURA 2-8: FLUXO DE UM PROJETO SCRUM. (FONTE: SITE FIGURA 2-9: CICLO DE VIDA DOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE ÁREA DE PRODUTOS [14] FIGURA 3-1: PROCESSO DEXTRA PARA DESENVOLVIMENTO EM SCRUM [19] FIGURA 3-2: CICLO DE VIDA DO PROCESSO SCRUM DA DEXTRA FIGURA 3-3: PAPÉIS DO PROCESSO SCRUM DA DEXTRA FIGURA 3-4: DISCIPLINAS DO PROCESSO SCRUM DA DEXTRA FIGURA 3-5: PRODUTOS DE TRABALHO DO PROCESSO SCRUM DA DEXTRA FIGURA 3-6: DIAGRAMA DO SPRINT FIGURA 3-7: DIAGRAMA DA FASE DE EXECUÇÃO FIGURA 3-8: DIAGRAMA DO SUBPROCESSO ACOMPANHAMENTO E CONTROLE FIGURA 3-9: DIAGRAMA DA FASE DE ENCERRAMENTO FIGURA 3-10: DIAGRAMA DA DISCIPLINA GARANTIA DA QUALIDADE FIGURA 3-11: PLANO DE QA FIGURA 3-12: LISTA DE VERIFICAÇÃO DE QA SCRUM FIGURA 3-13: LISTA DE VERIFICAÇÃO DE QA DE STATUS REPORT PARA CLIENTE xi

12 FIGURA 3-14: LISTA DE VERIFICAÇÃO DE QA DE STATUS REPORT INTERNO FIGURA 3-15: PLANILHA DE ACOMPANHAMENTO DE AUDITORIAS DA QUALIDADE FIGURA 3-16: REGISTRO DE NÃO CONFORMIDADES NO TRAC FIGURA 3-17: RELATÓRIO DE AUDITORIA DA QUALIDADE FIGURA 3-18: RELATÓRIO DE PRODUTO FIGURA 4-1: GRÁFICO GERADO A PARTIR DOS DADOS REGISTRADOS NA PLANILHA DE ADERÊNCIA FIGURA 4-2: TELA DA FERRAMENTA EPF COMPOSER FIGURA 4-3: PÁGINA INICIAL DO TRAC [16] FIGURA 4-4: TELA INICIAL DO TRAC DE UM PROJETO DA DEXTRA xii

13 Lista de Tabela TABELA 2-1: FATORES BÁSICOS PARA O CICLO DE MANUTENÇÃO DO CONTROLE DA QUALIDADE [3] xiii

14 Resumo Quando se fala em qualidade de software, logo vem à mente auditorias e cobranças, algo desagradável e que incomoda muitas pessoas. Quando o assunto são os modelos de qualidade de software, as pessoas logo se lembram de processos de desenvolvimento de software pesados, longos, detalhistas, com uma quantidade enorme de documentos a serem gerados. Até recentemente a realidade era essa: as empresas que queriam qualidade no software produzido tinham que colocar em prática processos totalmente complicados, onde se gastava muito tempo gerando documentos e por isso o produto final acabava se tornando mais caro. Porém, atualmente, com as exigências do mercado em relação a custo e prazo, as empresas começaram a implantar metodologias ágeis de desenvolvimento de software. Este trabalho de conclusão de curso apresenta uma forma de continuar com a qualidade nos softwares produzidos utilizando essas novas metodologias, em específico utilizando a metodologia SCRUM. Apresenta também como o conceito de Garantia da Qualidade pode ser executado dentro de um processo SCRUM de desenvolvimento de software, sem que as exigências do modelo de qualidade de software brasileiro, o MPS.Br (Melhoria de Processo do Software Brasileiro), nível F, sejam comprometidas. PALAVRAS-CHAVE: Qualidade de Software, Modelos de Qualidade de Software, Processo de Desenvolvimento de Software, Metodologias Ágeis, SCRUM, MPS.Br. xiv

15 Abstract When software quality is mentioned, words like audits and collections quickly come to mind, these are something unpleasant that bothers many people. Regarding the models of software quality, sometimes people remember heavy, long and detailed software development process, with a huge amount of documents to be generated. Until recently that was the scenario: the companies which want quality in software produced have to practice much complicated processes, and spent much time creating documents, such that the final product becomes too expensive. Nowadays, with the market requirements for cost and time, companies began to implement agile software development methodologies. This dissertation provides means to keep software quality using these news methodologies, in particular using the SCRUM methodology. It also shows how the concept of Quality Assurance can be maintained within a SCRUM process of software development, without the demands of the Brazilian quality of software model, MPS.Br (Melhoria de Processo do Software Brasileiro Brazilian Process Improvement of Software), level F, are compromised. KEY WORDS: Software Quality, Software Quality Models, Software Development Process, Agile Methodologies, SCRUM, MPS.Br. xv

16 1 INTRODUÇÃO 1.1 Contextualização No início da era da computação, os sistemas baseados em computadores eram desenvolvidos com foco no hardware, isso porque naquela época o hardware era o item mais caro dentro do desenvolvimento de um sistema computacional. Haviam controles formais e padrões técnicos para acompanhar os custos de hardware. A engenharia de hardware era a responsável por aplicar controles, métodos e ferramentas para implementar melhorias no hardware, e o software era visto como uma simples reflexão posterior. A programação não era considerada muito importante, poucas pessoas sabiam programar, e quem sabia, havia aprendido por tentativa e erro. O mundo do software era considerado menos importante que o do hardware. Porém, com o passar dos anos, esse pensamento foi mudando e várias perguntas foram surgindo, como por exemplo: Por que os programas demoravam a ser concluídos? Por que os custos eram elevados? Por que os erros não eram todos descobertos antes de o software ser entregue aos clientes? Essas e outras perguntas levaram a adoção de práticas de engenharia de software, que atualmente é a parte mais importante e cara dentro de um sistema computacional. Atualmente, a grande preocupação das pessoas envolvidas no desenvolvimento de um sistema baseado em computador é em relação ao software, pois o hardware passou a ser mais barato e menos importante do que a programação de software. O maior desafio dos profissionais de informática de hoje é conseguir desenvolver software com prazo e custo mínimos e de alta qualidade. Com isso a engenharia de software passou a ser considerada uma área essencial dentro do mundo da computação. O software, por ser um elemento lógico, deve ser desenvolvido ou projetado por engenharia, e não por manufatura como qualquer produto físico, por isso os custos do software estão concentrados no trabalho do engenheiro de software. O software também tem custo maior do que o hardware na manutenção, isso porque a manutenção do software é mais complexa, por envolver erro de projeto ou de processo, ou seja, não envolve uma simples reposição de peça como acontece com o hardware. Em suma, pode-se dizer que os custos da engenharia de software estão distribuídos ao longo do processo de software. Para determinar qual parte do processo tem custo maior, devese levar em conta o tipo de processo utilizado e o tipo de software a ser desenvolvido. De uma forma geral, pode-se dizer que teste de sistema, no caso de desenvolvimento de produto, e 1

17 evolução de sistema, no caso de alteração após o software ter sido colocado em uso, são as duas atividades que possuem o maior custo dentro de um processo de software. Além do desafio de desenvolver software com prazo e custos mínimos e de alta qualidade, como dito anteriormente, a engenharia de software, no século XXI, ainda enfrenta outros três principais desafios. O primeiro deles é o desafio do legado, que envolve a manutenção e atualização de softwares antigos, para evitar custos excessivos e para dar continuidade à prestação de serviços corporativos essenciais. O segundo é o desafio da heterogeneidade, que visa desenvolver softwares confiáveis e flexíveis, que suportem sistemas distribuídos em redes que possuam diferentes tipos de computadores. E por último, o desafio do fornecimento que se refere à redução do tempo de fornecimento de sistemas grandes e complexos sem comprometer a sua qualidade. Por fim pode-se concluir que para um software ser considerado de boa qualidade, ele deve possuir os seguintes atributos: fácil manutenção, como atualmente o ambiente de negócios está em constante mutação, o software deve ser capaz de evoluir e ser modificado para atender as necessidades dos clientes; nível de confiabilidade, que envolve confiabilidade, proteção e segurança, isto é, em caso de defeito o software não deve ocasionar danos físicos e/ou econômicos para o usuário; eficiência, que inclui rapidez de resposta, tempo de processamento, além de evitar desperdício de recursos do sistema, como a memória, por exemplo; e por último, facilidade de uso, isto é, o software deve possuir uma interface apropriada com o usuário, além de uma documentação adequada. 1.2 Definição do problema a ser tratado As empresas de software estão buscando cada vez mais ter um produto final de maior qualidade, através de certificações como MPS.Br e CMMI (Capability Maturity Model Integration - Integração do Modelo de Maturidade de Capacidade), visando atrair mais clientes e manter os que já possui. Porém esses modelos de qualidade de software até recentemente levaram a elaboração e utilização de processos de desenvolvimento de software muito extensos e pesados, sendo os mesmos melhor aplicados apenas em projetos grandes e longos, caso contrário, torna-se muito custoso e trabalhoso para a empresa implantá-los. Por esse motivo, algumas empresas começaram a adotar o desenvolvimento ágil de software, muitas vezes utilizando a metodologia SCRUM, que ao contrário do que muitos pensam, não significa ausência de documentação, mas sim, apenas a documentação necessária e no momento oportuno. 2

18 O grande desafio atualmente é como garantir a qualidade de processo dos projetos que utilizam um processo ágil de desenvolvimento de software. Como conseguir uma certificação MPS.Br em projetos SCRUM, através da elaboração de um processo mais leve, é o objetivo desse trabalho, que tem foco apenas na disciplina Garantia de Qualidade do MPS.Br nível F. 1.3 Estrutura do Texto Esse trabalho está divido em quatro seções, onde a Seção 1 contém a introdução, a qual está dividida em dois itens, que são contextualização e definição do problema a ser tratado. A Seção 2 aborda toda a fundamentação teórica e está dividida em dois itens, onde o primeiro descreve todos os conceitos fundamentais que foram a base deste trabalho (processo, processo de desenvolvimento de software, RUP (Rational Unified Process - Processo Unificado da Rational), qualidade, qualidade de software, modelo de qualidade de software, MPS.Br e SCRUM). O segundo item trata do estudo de caso feito para este trabalho, contemplando o processo SCRUM da empresa PowerLogic, que foi tomado como base do estudo, o histórico da empresa Dextra Sistemas, onde esse trabalho está sendo aplicado na prática e a motivação que levou ao desenvolvimento desse trabalho. A Seção 3 aborda a elaboração da solução, ou seja, o desenvolvimento do trabalho proposto, com a explicação detalhada de cada atividade presente na disciplina Garantia da Qualidade do Processo SCRUM da Dextra. Por fim, a última seção finaliza com as conclusões deste trabalho, as suas contribuições para a empresa onde está sendo aplicado e para quem desenvolveu, e algumas sugestões para trabalhos futuros. 2 FUNDAMENTAÇÃO TEÓRICA 2.1 Conceitos fundamentais Processo Há várias definições para processo, tais como: Uma ação regular e contínua realizada de forma bem definida, levando a um resultado, segundo Oxford English Dictionary; Um conjunto parcialmente ordenado de atividades para se atingir um objetivo, segundo Feiler & Humphrev [1]; Define quem está fazendo o quê, quando e como para atingir um certo 3

19 objetivo, segundo Jacobson, Booch, Rumbaugh [2]; Processo é um conjunto de causas que provoca um ou mais efeitos, segundo Falconi [3]. Conceitualmente, processo é todo conjunto de atividades bem definidas, que possuem responsáveis e artefatos de entrada e saída, atividades com dependências entre as mesmas, ordem de execução e modelo de ciclo de vida. Resumindo, pode-se dizer que processo é qualquer atividade que recebe uma entrada, realiza uma transformação agregando-lhe valor e gera uma saída para um cliente externo ou interno, fazendo uso de recursos para gerar resultados concretos. Os processos possuem a seguinte hierarquia: 1. Macroprocessos: são considerados um centro autônomo de resultados com autonomia decisória e recursos plenos (a organização em si). Melhor dizendo, macroprocessos designam um conjunto de atividades necessárias e suficientes para atender aos pedidos dentro do requisito especificado, a elaboração e a disponibilidade no prazo e local prometido ao cliente. 2. Subprocessos: são divisões do macroprocesso com objetivos específicos. Recebem entradas e geram saídas em um único departamento. 3. Atividades: são divisões que compõem um subprocesso. 4. Tarefas: são as atividades em um nível mais detalhado. Processos também podem ser divididos de acordo com suas finalidades, isto é, processos de fabricação geram produtos ou serviços. Os processos de negócios apóiam processos de fabricação pelos meios operacionais (operações finalísticas) ou administrativos (gestões de recursos (suporte) e operações). Hoje em dia é muito comum a padronização de processos, o que ajuda a reduzir problemas de treinamento, revisões e ferramentas de apoio. Na visão da computação e da engenharia de software, se forem utilizados métodos padrões, cada nova experiência de projeto pode ajudar na melhoria do processo como um todo. Além disso, processos padronizados podem fornecer uma base sólida para se fazer medições de qualidade entre projetos que utilizam o mesmo processo. Existe também o modelo de processo, que é uma representação de um processo e envolve as atividades que serão realizadas, os agentes que realizarão as atividades, os artefatos (produtos) gerados e os recursos necessários para a realização das atividades. Um modelo de processo deve ser descrito de forma completa e formal, utilizando-se diagramas de estados, técnicas de análise e projeto estruturados, UML (Unified Modeling Language - Linguagem de Modelagem Unificada), entre outros formalismos diagramáticos. Esse modelo 4

20 deve ser usado pela organização para o entendimento e comunicação do processo, e deve servir como base para a análise, execução, gerência e melhoria do processo como um todo. Para que um processo seja institucionalizado com sucesso dentro de uma organização, precisa haver um comprometimento da diretoria da empresa, envolvimento de todos, treinamento e orientação das pessoas envolvidas nos padrões e técnicas, infra-estrutura necessária disponível, disciplina e motivação. Para que um processo acompanhe a constante modificação do ambiente de negócios, ele deve ser revisado periodicamente e deve ter melhoria contínua. É importante deixar claro que todo processo deve ajudar e não burocratizar a organização, por isso é importante se ter procedimentos adequados e ferramentas que facilitam o trabalho dentro da empresa. Como um processo pode ter um ou mais resultados, para que se possa realizar o gerenciamento do mesmo é preciso fazer medições desses resultados. Isso pode ser feito através dos itens de controle do processo, os quais medem a qualidade, custo, entrega, moral e segurança dos resultados. É importante ressaltar que não se deve estabelecer um item de controle sobre algo de que não se possa exercer o controle, ou seja, atuar na causa do desvio [3]. O método gerencial para controle de processo mais utilizado é o ciclo PDCA (plan, do, check e action planejar, executar, verificar e atuar corretivamente), como mostra a Figura 2-1. O planejamento consiste em estabelecer metas sobre os itens de controle e a maneira para atingir essas metas. A execução consiste na realização das tarefas exatamente como previstas no planejamento e na coleta de dados para uma futura verificação do processo. Nessa etapa também se deve ter um treinamento no trabalho que foi definido no planejamento. Na fase de verificação se compara o resultado alcançado com as metas planejadas inicialmente. Essa comparação é feita utilizando-se os dados coletados na fase de execução. Por último, existe a fase de atuação corretiva, onde o usuário atuará nos desvios detectados, realizando correções definitivas, de modo que o problema não ocorra novamente. 5

21 Figura 2-1: Ciclo PDCA de controle de processos [3]. O ciclo PDCA pode ser utilizado para quatro objetivos diferentes: manutenção do nível de controle, melhoria do nível de controle, manutenção dos resultados e melhoria dos resultados. Para manutenção do nível de controle, o mesmo é utilizado quando o processo é repetitivo e o plano consta de uma meta que é uma faixa aceitável de valores e de um método que compreende os procedimentos padrões de operação [3]. Nas melhorias do nível de controle, o ciclo PDCA é utilizado quando o processo não é repetitivo e o plano consta de uma meta que é um valor definido e de um método, que compreende aqueles procedimentos próprios necessários para se atingir a meta [3]. Na manutenção dos resultados as diretrizes de controle são mantidas pelo cumprimento dos procedimentos de operação [3], que pode ser visto no seqüenciamento do PDCA, que é o ciclo de manutenção. E por fim, na melhoria dos resultados se tem que a utilização de ciclo PDCA para melhorar as diretrizes de controle é a grande responsabilidade de todas as chefias, desde o presidente até o nível de supervisor [3]. Constitui um método para a solução de problemas, o 6

22 qual deve ser dominado por todas as pessoas da empresa. O detalhamento do ciclo PDCA pode ser visto na Figura 2-2. Figura 2-2: Detalhamento do ciclo PDCA nos ciclos de manutenção e melhorias [3] Processo de Desenvolvimento de Software Existem várias definições para Processo de Desenvolvimento de Software. Segundo Sommerville [5] Processo de Software é um conjunto de atividades e resultados associados que produzem um produto de software. Conforme Pressman [6] definimos um processo de software como um framework para as tarefas que são necessárias para a construção de software de alta qualidade. Um processo de desenvolvimento de software é dividido em atividades genéricas, que englobam: Especificação dos Requisitos, atividade onde são feitas as funcionalidades e restrições do sistema; Desenvolvimento, atividade que envolve a construção do software em si; Verificação, atividade de análise de correção, validação entre outros aspectos relacionados com qualidade; Manutenção, atividade que visa analisar e realizar mudanças no software. Dividido também em papéis e artefatos. Essas divisões possuem a seguinte relação: os artefatos são documentos, modelos e códigos produzidos por uma atividade, onde cada 7

23 atividade é executada por um papel (que pode ser uma equipe ou uma única pessoa) específico. Hoje em dia, muitas pessoas ainda não sabem definir o que é método e o que é processo. De modo geral, pode-se dizer que método é teórico, ele define o que, como e porque fazer, já o processo é prático, ele define quem e quando fazer, é a junção de método com planejamento. Método define papéis. Processo define quem desempenhará cada papel. No método, as atividades que serão realizadas são denominadas disciplinas. No processo as atividades são alocadas aos papéis, e determinam-se o fluxo de trabalho, as dependências e os marcos. Em um método, disciplinas e papéis produzem e consomem artefatos. Em um processo define quem produz e consome os artefatos e quando os mesmos serão produzidos. Estabelecer um processo de desenvolvimento de software dentro de uma empresa é importante para se diminuir a dependência da empresa em relação às pessoas, reduz problemas de treinamento e ferramentas de apoio, fornece a base para medições de qualidade entre projetos, além de facilitar a disseminação de melhores práticas, conhecimento e documentos. Para que se tenha sucesso é importante que o processo seja bem definido, padronizado, divulgado e utilizado de forma correta por todos da empresa. Utiliza-se um modelo de processo para que haja o entendimento e a comunicação do processo, além de prover a sua melhoria. Um modelo de processo deve ser descrito de maneira formal e padronizada. Existem vários modelos de processo de desenvolvimento de software, dentre os quais os mais conhecidos e utilizados são o Modelo Cascata e o Modelo Iterativo Incremental Modelo Cascata O modelo Cascata, também conhecido como modelo ciclo de vida Clássico, é o mais antigo de todos. Ele descreve o desenvolvimento de software de forma linear e seqüencial, isto é, uma vez que uma fase é completada ela não retorna mais, e o desenvolvimento prossegue para a próxima fase. Outra característica importante é que uma fase não pode iniciar enquanto a anterior não estiver finalizada, como pode ser observado na Figura

24 No modelo cascata são contempladas as fases: Requerimento, onde é elaborado um conjunto de requisitos do software; Projeto, que é a fase que se encarrega de transformar o conjunto de requisitos em um documento (desenho ou plano) que será seguido pelos desenvolvedores na implementação desses requisitos Modelo Iterativo e Incremental Dizer que um processo é iterativo, significa que o mesmo possui várias iterações no tempo, isto é, significa que o processo possui vários ciclos de desenvolvimento onde em cada ciclo são identificadas as fases de levantamento e análise de requisitos, projeto, implementação, testes e implantação. Dizer que ele é incremental significa que ele gera novas versões incrementadas a cada ciclo, como mostra a Figura 2-4. Atualmente, o modelo iterativo incremental de desenvolvimento de software é um dos mais utilizados nas empresas de fábrica de software. Figura 2-3: Modelo Cascata de desenvolvimento de software. (Fonte: Site - 3.pdf) 9

25 Figura 2-4: Modelo Iterativo e Incremental de desenvolvimento de software. (Fonte: Site - ro/analise/material/aula5.pdf) Isso ocorre porque neste modelo existem inúmeras vantagens, como por exemplo, a possibilidade de avaliar logo no início os riscos e pontos críticos do projeto, identificar medidas para eliminar ou controlar os riscos avaliados, definir a melhor arquitetura a ser usada, redução do risco de a entrega do projeto atrasar, contato freqüente com o cliente (o que permite manter o entendimento dos requisitos alinhados), a equipe visualiza o software funcionando mais cedo (o que é extremamente motivador) RUP (Rational Unified Process) O RUP foi criado pela Rational Software Corporation e posteriormente foi adquirido pela IBM (International Business Machines - Máquinas Comerciais Internacionais). É o processo de desenvolvimento de software baseado no modelo iterativo incremental mais utilizado atualmente pelas empresas. Por ser considerado um processo pesado, é aplicado em 10

26 grandes projetos, com grandes equipes de desenvolvimento. Apesar disso, por ser um framework de processo, o RUP pode ser adaptado a realidade de pequenas e médias empresas de desenvolvimento de software. Devido utilizar a orientação a objetos como paradigma de desenvolvimento de software, o RUP lança mão da UML como linguagem de modelagem e documentação de projetos. Além disso, o RUP é guiado por casos de uso e centrado na arquitetura. Como já foi dito anteriormente, o ciclo de vida do RUP é iterativo e incremental, isto é, ele se repete através de uma série de ciclos, onde em cada ciclo que se encerra é gerado uma nova release (produto acabado) incrementada. O ciclo de vida é dividido em quatro fases, onde cada fase pode ser subdividida em iterações. As fases são: concepção, elaboração, construção e transição. Elas serão explicadas na seqüência e podem ser observadas através da Figura 2-5. Figura 2-5: Processo RUP [4]. A fase concepção é a primeira fase do ciclo de vida do RUP. Nela são definidos o escopo do projeto, suas fronteiras e os principais casos de uso do projeto. Essa fase tem ênfase no planejamento, por isso é nessa fase que se faz as estimativas de prazo e custo, de forma global para o projeto todo e mais detalhada para a fase seguinte. As idéias são exploradas até alcançarem o ponto em que se possa iniciar a elaboração do sistema. A segunda fase é a elaboração, onde o levantamento inicial dos casos de uso é revisado e, se necessário, complementado. Nessa fase são desenvolvidas a arquitetura do sistema e a versão inicial do manual do usuário, também é feita a revisão da modelagem de negócio do projeto. Resumidamente, pode-se dizer que a fase de elaboração é constituída da análise e projeto. 11

27 A fase construção é a terceira fase do ciclo de vida e é nela que são feitos a implementação e os testes. Nessa fase o sistema é desenvolvido, códigos são gerados e testes são realizados. A quarta e última fase é a transição, a qual ocorre após o último ciclo iterativo da fase de construção. Concentra-se na realização de testes, visando garantir que o sistema possui um nível de qualidade aceitável. Nessa fase o sistema é entregue ao cliente, é feito o plano de implantação, acompanhamento e qualidade de software de modo a obter a satisfação do cliente. Essa fase também contempla a construção de novas versões para permitir ajustes do sistema, corrigir problemas ou construir algumas características que foram postergadas, que surgem após o sistema ter sido colocado em uso pelo cliente. Os elementos pertencentes ao processo RUP são: papéis, atividades, artefatos, fluxos de trabalhos e disciplinas. O elemento papel define as responsabilidades de cada indivíduo da equipe no projeto. Um indivíduo pode assumir vários papéis dentro do mesmo projeto. A atividade é uma tarefa realizada por um papel e que produz um resultado importante para o projeto. Cada atividade pode ser dividida em etapas, para facilitar a execução da mesma por um determinado papel. O artefato é uma parte de uma informação que é produzida, modificada ou utilizada no processo. É o produto de um projeto, que é utilizado como entrada de atividades ou produzido como saída das mesmas. Templates (modelos), documentos, código fonte, executáveis são exemplos de artefatos em um processo. Fluxo de trabalho é uma seqüência de atividades que são executadas para a produção de um resultado importante para o projeto. Essa seqüência é semi-ordenada para o melhor entendimento do processo, podendo quebrá-lo em menores áreas de conhecimento. Um fluxo de trabalho é representado na forma de diagrama de seqüência. Por fim tem-se o elemento disciplina, que é uma coleção de tarefas relacionadas a uma área de conhecimento de todo o projeto. Dividir as atividades em disciplinas diferentes é uma forma de organizar o conteúdo de modo a facilitar a compreensão. O RUP é dividido em nove disciplinas, que são: modelagem de negócios, requisitos, análise e design, implementação, teste, distribuição, configuração e gerenciamento de mudanças, gerenciamento de projeto e ambiente. 12

28 2.1.4 Qualidade A idéia de qualidade surgiu há aproximadamente 4 (quatro) mil anos atrás no Egito, quando os egípcios criaram um padrão de medida de comprimento chamada cúbito, que correspondia ao comprimento do braço do faraó que estava no reinado. Ou seja, a cada troca de faraó, a medida mudava, de acordo com o tamanho do braço do novo faraó. Eram cortados bastões com o comprimento do braço do faraó e este era utilizado para fazer as construções. A partir daí a história da qualidade prosseguiu com os templos construídos na Grécia e Roma antigas, os feitos das grandes navegações, as catedrais medievais. Porém, o grande marco da história da qualidade foi a Revolução Industrial, devido às profundas mudanças econômicas e sociais e, conseqüentemente, o surgimento da concorrência entre as grandes empresas que surgiram nessa época. Segundo a ISO 9000 (International Organization for Standardization - Organização Internacional para Normalização) [7] Qualidade é a adequação ao uso. É a conformidade às exigências. Existem vários pontos de vista sobre o que é qualidade. Para alguns, qualidade é a aparência do produto, para outros é de qual material o produto foi feito, outros que avaliam a qualidade de um produto pelo preço que ele custa. Falconi [3] acredita que um produto ou serviço de qualidade é aquele que atende perfeitamente, de forma confiável, de forma acessível, de forma segura e no tempo certo as necessidades do cliente. Em outros termos, pode-se dizer que: a. que atende perfeitamente = projeto perfeito; b. de forma confiável = sem defeitos; c. de forma acessível = baixo custo; d. de forma segura = segurança do cliente; e. no tempo certo = entrega no prazo certo, no local certo e na quantidade certa [3]. Na verdade a qualidade é subjetiva e está totalmente ligada as necessidades internas de cada pessoa. O aspecto objetivo, que é mensurável da Qualidade, é o processo. É através do processo que se pode implantar sistemas de qualidade. O primeiro sistema padronizado de qualidade surgiu na indústria de produção seriada e é conhecido e utilizado por muitas empresas até os dias de hoje, esse sistema é o ISO. Ele surgiu como uma forma de se manter a perfeita padronização das peças e produtos fabricados, evitando o retrabalho e maiores custos de produção. 13

29 Com o surgimento das certificações que comprovam a qualidade dos produtos gerados por uma empresa o conceito de qualidade evoluiu e deixou de ser apenas a conformidade de determinado produto com o processo estabelecido na empresa, cumprindo todas as etapas do processo de forma homogênea e padronizada. Agora qualidade é vista como sendo um enfoque na satisfação plena das necessidades do cliente. Outro conceito muito utilizado atualmente é o de Qualidade Total. Esse termo busca a satisfação não só do cliente, mas de todas as pessoas que influenciam na existência da empresa e no seu modelo organizacional. Resumindo pode-se dizer que o conceito qualidade total possui seis atributos básicos, que são: qualidade intrínseca (capacidade do produto de cumprir o objetivo ao qual se destina), custo (para empresa e preço para o cliente), atendimento (local, prazo e quantidade), moral (treinamento, motivação), segurança (dos clientes internos e externos) e ética (valores e regras de conduta). A qualidade total valoriza o ser humano no âmbito das empresas e pode ser entendida como uma nova maneira de pensar, antes de agir e produzir. Ela tem como pontos básicos: foco no cliente; trabalho em equipe; decisões baseadas em fatos e dados; e a busca constante da solução de problemas e da diminuição de erros. Por isso, pode-se dizer que a sobrevivência das empresas que precisam garantir aos seus clientes a total satisfação com os produtos produzidos depende da qualidade total, a qual também influencia a competitividade entre empresas. A prática de controle da qualidade é o objetivo principal do Controle da Qualidade Total (TQC Total Control Quality - Controle da Qualidade Total) e é de obrigação de todos. O controle da qualidade total é um novo modelo gerencial centrado no controle de processo, tendo como meta a satisfação das necessidades das pessoas [3]. [3], são: Os três principais objetivos abordados pelo controle da qualidade, segundo Falconi 1. planejar a qualidade desejada pelos clientes; isto implica um esforço de localizar o cliente, saber de suas necessidades (muitas vezes ele não as conhece e você deve colocar-se em seu lugar), traduzir estas necessidades em características mensuráveis, de tal forma que seja possível gerenciar o processo de atingi-las. 2. manter a qualidade desejada pelo cliente, cumprindo padrões e atuando na causa dos desvios. O processo para manter a qualidade desejada pelo cliente está mostrado na Tabela 2-1. Nesse caso o controle (PDCA) é exercido para manter os resultados. 14

30 3. melhorar a qualidade desejada pelo cliente; neste caso é preciso localizar os resultados indesejáveis (problemas) e utilizar o método de solução de problemas para melhorá-los. Tabela 2-1: Fatores básicos para o ciclo de manutenção do controle da qualidade [3]. Dentro da Qualidade Total ainda existe o conceito de Garantia da Qualidade, que tem como finalidade confirmar se todas as atividades da qualidade estão sendo realizadas da maneira como é requerida pela empresa. Segundo Falconi [3], a garantia da qualidade é a embaixatriz do cliente na empresa, é a função que visa a confirmar que todas as ações necessárias para o atendimento das necessidades dos clientes estão sendo conduzidas de forma completa e melhor que o concorrente. Consegue-se a garantia da qualidade em uma empresa através do gerenciamento correto, que é feito via ciclo PDCA descrito anteriormente, de todas as atividades da área da qualidade em cada projeto e em cada processo existente na empresa. A mesma busca eliminar completamente as falhas através da constante preocupação com a total satisfação dos clientes e pela participação e responsabilidade de todos os membros da empresa. Pode-se dizer que, na qualidade total, a garantia da qualidade busca o defeito zero. Existem três estágios da garantia da qualidade, os quais foram evoluindo com o passar dos anos, são eles: a garantia da qualidade orientada pela inspeção, a orientada pelo controle 15

31 de processos e a com ênfase no desenvolvimento de novos produtos. É importante ressaltar que esses estágios não se excluem, a diferença entre os mesmos está na ênfase que cada empresa tem no momento, se é na inspeção, no controle de processos ou no desenvolvimento de novos produtos. Resumidamente, tem-se que a garantia da qualidade orientada pela inspeção é realizada por um grupo independente da produção. O problema é que esse estágio é muito custoso, uma vez que os inspetores aumentam os custos e não produzem nenhum produto, e também não melhora a qualidade do produto se aplicada isoladamente, visto que a inspeção não elimina as causas fundamentais dos defeitos, apenas evita que eles apareçam para o cliente. Já a garantia da qualidade orientada pelo controle de processo é de responsabilidade de todos na empresa. Nesse estágio se garante que os processos da empresa estão perfeitos, fazendo produtos sem defeitos, porém não garante que esses produtos possuem especificações que satisfazem as necessidades dos clientes. Assim, surgiu o terceiro e último estágio da garantia da qualidade, o com ênfase no desenvolvimento de novos produtos, onde a qualidade deve ser construída de acordo com cada projeto e em cada processo. Portanto, neste estágio, além de se ter o controle de processos e a inspeção (ainda que com menor ênfase), procura-se conduzir severamente as avaliações e garantir a qualidade em cada passo do desenvolvimento de um novo produto, desde o seu planejamento até a fase posterior à assistência técnica (serviço) [3] Qualidade de Software Uma famosa definição de qualidade de software foi dada por Crosby [8] que diz que A qualidade é conformidade aos requisitos. Ela é interessante pelo fato de deixar explícito que é preciso um ponto de referência para julgar um produto, e no que diz respeito a software essa referência são os seus requisitos. Além disso, também traz embutida a idéia de como todo o processo pode ser documentado, analisado e os resultados transmitidos a outras pessoas. A qualidade de software está focada em dois aspectos diferentes, mas que são necessários e complementares: a qualidade de produto e a qualidade de processo. Ambos os aspectos garantem a qualidade do software final, interferem no processo de desenvolvimento, realimentando-o com os resultados obtidos durante a verificação e tem um propósito comum, que é o de satisfazer o cliente. 16

32 Qualidade de Produto A qualidade de produto refere-se aos testes realizados no software por uma equipe específica de testes, são as chamadas verificações e validações. Avaliar a qualidade de produto significa verificar, através de técnicas e atividades operacionais o quanto os requisitos são atendidos. A qualidade de produto não se atinge de forma espontânea, ela depende fortemente da qualidade de processo. A finalidade da qualidade de produto é a verificação (verifica se a saída está de acordo com a entrada do processo) e a validação (verifica se a saída está de acordo com a especificação inicial). Quando se fala em qualidade de produto de software, ou melhor dizendo, em testes de software, surge uma dúvida em relação a três termos que parecem ser muito semelhantes: engano, defeito, erro e falha. Apesar de parecerem iguais, eles possuem significados diferentes. Engano é uma ação humana que introduz um defeito no software. Defeito é um conjunto de instruções no software que, ao ser executado, pode causar uma falha. Erro é um estado incorreto de execução do software que pode produzir um resultado incorreto, isto é, pode levar a uma falha no software. Falha é a ocorrência de uma diferença entre o resultado observado do software e o resultado especificado pelos requisitos. [9] Resumindo os termos engano, defeito, erro e falha, pode-se dizer que um engano introduz um defeito no software que, quando ativado, pode produzir um erro que, se propagado até a saída do software, constitui uma falha. [9] Qualidade de Processo Um processo bem escrito e estruturado não garante que os produtos produzidos serão de boa qualidade, mas é um indicativo de que a empresa tem a capacidade de produzir bons produtos. Quando aplicada de forma correta, a qualidade de processo proporciona muitos benefícios para a empresa, tais como: aumento da qualidade do produto final, diminuição do retrabalho, maior produtividade, redução de custos, maior competitividade, maior precisão nas estimativas. A qualidade de processo de software é uma atividade da subárea garantia da qualidade, que faz parte da área de gerência dentro de um processo de desenvolvimento de software. Ela tem como propósito assegurar que os objetivos planejados no início do projeto serão cumpridos ao longo do projeto, até o seu final. Fazem parte da qualidade de processo as auditorias de qualidade, as quais são realizadas por pessoas externas ao projeto que será auditado. A equipe de qualidade não faz parte da equipe do projeto, diferente da equipe de 17

33 testes, que faz parte do projeto para garantir a qualidade de produto de software. A qualidade de processo tem por finalidade realizar auditorias (que verificam a adequação e a conformidade ao processo). A qualidade de um software está vinculada a atributos essenciais que devem ser levados em consideração no projeto de software, para que possam ser aferidos antes, durante e após o desenvolvimento do mesmo. Esses atributos são: funcionalidade (o software deve atender às especificações para as quais foi desenvolvido), facilidade de uso (a operação do software deve ser a mais direta e simples possível, não devendo existir falhas e/ou defeitos), confiabilidade (tempo durante o qual o software atende aos objetivos para os quais foi desenvolvido), desempenho (tempo de resposta, consumo de memória e/ou CPU (Central Processing Unit - Unidade Central de Processamento), capacidade de resolução de problemas), suportabilidade (facilidade de manutenção, apoio técnico adequado). Um assunto muito discutido na área da qualidade de software é a relação entre valor e custo, que conforme Koscianski [10] abrange os prejuízos causados pela falta de qualidade de um produto e os custos com que é preciso arcar para garantir um determinado nível de exigência quanto ao funcionamento do software. A subárea Garantia da Qualidade é a responsável por isso, além de assegurar que os objetivos planejados no início do projeto serão cumpridos ao longo do projeto inteiro, até o seu final. Segundo Koscianski [10], o propósito da garantia da qualidade é estabelecer sistemas para controlar tudo o que ocorre durante o ciclo de vida, com o objetivo de garantir que o programa que será fabricado fará aquilo que se espera dele Modelo de Qualidade de Software Os modelos de qualidade de software, as normas e os organismos normativos surgiram para ajudar na definição de um processo de software. A criação das normas é baseada na experiência e no trabalho de especialistas de todo o mundo. Elas são a base para especificar produtos, organizar fornecimento de serviços e para elaborar leis de diversos países. As normas definem padrões, os quais podem mudar com o passar o tempo. Esses padrões podem ser de dois tipos, são eles: padrões de facto, que são padrões conhecidos e aplicados na prática sem precisar se formalizarem como um regulamento ou como uma lei; padrões de jure, que são padrões escritos seguindo uma regulamentação, transformam-se em leis, e são aprovados 18

34 por instituições reconhecidas mundialmente e que possuem capacidade para realizar essa aprovação [10]. Os organismos normativos são as empresas que escrevem os padrões de jure, as normas regulamentadas. Dentre os organismos mais conhecidos estão o IEEE (Institute of Electrical and Electronics Engineers - Instituto de Engenheiros Elétricos e Eletrônicos), a ISO, a IEC (International Eletrotechnical Commission - Comissão Internacional de Eletrotécnica) e a ABNT (Associação Brasileira de Normas Técnicas). Já os modelos de qualidade de software são parecidos com os modelos de processo de desenvolvimento de software. Eles avaliam a qualidade dos processos de software aplicados em uma empresa. São considerados padrões de processo. Atualmente, existem vários modelos de qualidade de software, dos quais o CMMI e o MPS.Br são os mais utilizados e conhecidos, sendo que o último é de conhecimento apenas do Brasil. Além desses dois modelos também existem o SPICE (Software Process Improvement and Capability determination - Melhoria e Capacidade de Determinação do Processo de Software), o CMM (Capability Maturity Model - Modelo de Maturidade de Capacidade) - que deu origem ao CMMI -, a ISO e o PSP (Personal Software Process - Processo de Software Pessoal). Resumidamente pode-se dizer que os modelos de qualidade definem os requisitos a que o processo deve atender, e tem a possibilidade de se escolher como irá atendê-los, os modelos possuem flexibilidade em relação a como atender esses requisitos. Além disso, os modelos, principalmente os estruturados por etapas, definem um caminho evolucionário para a melhoria do processo. Uma empresa, ao optar por fazer um processo seguindo um modelo de qualidade, faz com que esse processo se transforme em um repositório de melhores práticas que vêm sendo utilizadas ao longo de vários anos com sucesso. Também permite avaliações do processo de forma objetiva e a detecção de pontos fortes e fracos MPS.Br (Melhoria do Processo de Software Brasileiro) O MPS.Br é um modelo de qualidade de software brasileiro criado e coordenado pela SOFTEX (Associação para Promoção da Excelência do Software Brasileiro) em Dezembro de 2003, com o apoio do MCT (Ministério da Ciência e Tecnologia), da FINEP (Financiadora de Estudos e Projetos) e do BID (Banco Interamericano de Desenvolvimento). Foi criado com o objetivo de definir um modelo de referência acessível às micros, pequenas e médias empresas brasileiras, aumentando a competitividade entre elas. 19

35 Foi criada com base no modelo americano CMMI, adequando-se a realidade socioeconômica e cultural das empresas brasileiras. Apesar de ter herdado os conceitos do CMMI, o MPS.Br também se baseia nas normas internacionais ISO/IEC (de desenvolvimento de software) e ISO/IEC SPICE (de avaliação de processos de software). O foco do MPS.Br está na qualidade de processo, uma vez que se acredita que problemas no processo é que geram defeitos no produtos. Com isso, focando-se na qualidade do processo uma empresa consegue aumentar a qualidade do produto, diminuir retrabalho, aumentar a produtividade, reduzir o tempo para atender o mercado, aumentar a competitividade e melhorar a precisão nas estimativas. Uma empresa com processo imaturo tem como conseqüências pouca produtividade, qualidade somente na realização de testes, alto custo de manutenção do produto e riscos na adoção de novas tecnologias. Já uma empresa que possui um processo maduro tem papéis e responsabilidades claramente definidos, acompanhamento da qualidade do produto e da satisfação do cliente, estimativas iniciais para custos, prazo, funcionalidades e qualidade do produto são, quase sempre, alcançadas com sucesso. Assim, pode-se definir, resumidamente, que um processo maduro é aquele processo conhecido por toda a empresa, visivelmente apoiado pela alta administração, possui medidas de produto e de processo, as auditorias são fiéis ao processo e pode-se adotar de forma disciplinada novas tecnologias. O MPS.Br está dividido em três componentes, que são: modelo de referência (MR- MPS), método de avaliação (MA-MPS) e modelo de negócio (MN-MPS). O modelo de referência está descrito de forma detalhada no guia geral MPS.Br, o qual se encontra disponível no site da SOFTEX. O modelo de qualidade de software MPS.Br possui sete níveis de maturidade, que são: - nível A: Em otimização - nível B: Gerenciado quantitativamente - nível C: Definido - nível D: Largamente definido - nível E: Parcialmente definido - nível F: Gerenciado - nível G: Parcialmente gerenciado. Esses níveis de maturidade podem ser atingidos por uma empresa gradativamente, por etapas, começando do nível G e chegando ao nível A, o qual é compatível com o CMMI nível 5. A comparação dos níveis do MPS.Br com os do CMMI pode ser observada através da 20

36 Figura 2-6. Defini-se nível de maturidade como sendo o grau de melhoria de processo para um pré-determinado conjunto de processos no qual todos os objetivos dentro do conjunto são atendidos (ISO/IEC , 2004). Figura 2-7. Figura 2-6: Estrutura de níveis do MPS.Br e comparação com os níveis do CMMI. (Fonte: Site - A estrutura do MR-MPS.Br, conforme descrito pela SOFTEX, é mostrada abaixo, na 21

37 Figura 2-7: Estrutura do MR-MPS do modelo de qualidade MPS.Br [17]. A definição de nível de maturidade já foi dada anteriormente. Processo, nesse contexto, é um conjunto de atividades inter-relacionadas, que transforma entradas em saídas (ABNT, 1998). A SOFTEX define que cada processo é composto de propósito, que é o principal objetivo da execução do processo e os prováveis resultados obtidos com a implementação do mesmo, e de resultado, que é o resultado observável do sucesso do alcance do propósito do processo (ISO/IEC 12207:1995). Em suma, se os resultados esperados atingem o propósito do processo, o mesmo é considerado implementado. Define-se capacidade do processo como sendo uma habilidade da empresa para gerir o processo e atingir seu objetivo, é uma caracterização da habilidade do processo atingir os objetivos de negócio atuais ou futuros (ISO/IEC , 2004). A SOFTEX define que cada capacidade do processo é composta de atributo de processo, que é uma característica mensurável da capacidade do processo aplicável a qualquer processo (ISO/IEC

38 1,2004), e de resultado, que é o resultado observável do sucesso do alcance do atributo do processo (ISO/IEC 12207:1995). Cada nível de maturidade envolve um conjunto de processos, capacidades do processo e resultados esperados. Os níveis de maturidade, como já vistos anteriormente, vão do G ao A. As capacidades do processo (na verdade, os atributos de processo) vão do AP (Atributo de Processo) 1.1 ao AP 5.2. Os resultados esperados vão do RAP (Resultados dos Atributos de Processo) 1 ao RAP 36. E por último, existem vários processos, que são avaliados de acordo com o nível de maturidade desejado pela empresa. Como esse trabalho está focado no nível F do MPS.Br (nível almejado pela Dextra Sistemas inicialmente para projetos SCRUM), serão citados os processos que fazer parte desse nível, que são: gerência de projetos (GPR), gerência de requisitos (GRE), aquisição (AQU esse processo é avaliado apenas para empresas que compram serviços de terceiros, no caso de empresas como fábricas de software esse processo não é avaliado), gerência de configuração (GCO), garantia da qualidade (GQA) e medição (MED). Resumidamente, pode-se dizer que um processo implementado mais uma capacidade implementada resultam em um nível de maturidade referente ao modelo de referência. Um processo é considerado implementado se todas as capacidades do processo e resultados esperados, referente a esse processo, forem considerados totalmente satisfeitos. Se todos os processos, referentes ao nível de maturidade escolhido pela empresa, estiverem totalmente satisfeitos, então a empresa será considerada certificada no MPS.Br no nível em que foi avaliada Metodologia ágil de desenvolvimento de software SCRUM O Manifesto Ágil O início dos métodos ágeis de desenvolvimento de software está fundamentado nos princípios descritos no Manifesto Ágil, ocorrido em Fevereiro de Esse manifesto aconteceu nos Estados Unidos, quando um grupo de dezessete profissionais, veteranos na área de desenvolvimento de software se reuniram em uma estação de esqui para discutir maneiras de melhorar o desempenho de seus projetos. Mesmo cada participante tendo suas próprias práticas e teorias sobre como fazer um projeto de software de sucesso, todos concordaram que, em suas experiências anteriores, um pequeno conjunto de princípios sempre era respeitado quando os projetos davam certo. Kent Beck, Martin Fowler e Ken Schwaber, os 23

39 três maiores defensores das metodologias ágeis estavam nesse grupo de profissionais que participaram do manifesto. Desse manifesto surgiram os doze princípios para desenvolvimento de software de forma ágil, os quais devem ser seguidos sempre que se utilizar uma metodologia ágil. São eles [11]: 1- nossa maior prioridade é satisfazer o cliente através da entrega inicial e contínua de software suscetível de avaliação; 2- mudanças de requisitos são bem-vindas, mesmo que tardia em desenvolvimento (isto porque projetos SCRUM são considerados projetos de escopo aberto, diferente dos projetos que seguem a metodologia tradicional, que são de escopo fechado); 3- entregar software funcionando freqüentemente, de algumas semanas a alguns meses, com preferência para o curto prazo; 4- empresários e desenvolvedores devem trabalhar juntos diariamente durante o projeto; 5- construa projetos em torno de indivíduos motivados, dê-lhes o meio ambiente e suporte que eles precisam e confie neles para fazer o trabalho; 6- o método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa face-a-face; 7- software funcionando é a primeira medida de progresso; 8- processos ágeis promovem o desenvolvimento sustentável, patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente; 9- atenção contínua a excelência técnica e bom design melhoram a agilidade; 10- simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial; 11- as melhores arquiteturas, requisitos e designs emergem de equipes autoorganizáveis; 12- em intervalos regulares, a equipe reflete sobre como tornar-se mais eficaz, depois sintoniza e ajusta seu comportamento em conformidade. O manifesto ágil também declarou quatro valores essenciais para o desenvolvimento de software ágil, são eles [11]: 1- indivíduos e interação entre eles mais que processos e ferramentas; 2- software em funcionamento mais que documentação abrangente; 3- colaboração com o cliente mais que negociação de contratos; 24

40 4- responder a mudanças mais que seguir um plano. O manifesto ágil descreve a essência de um conjunto de abordagens para desenvolvimento de software criadas ao longo da última década, dentre as quais se destaca o SCRUM, uma abordagem atualmente muito conhecida e utilizada por muitas empresas de desenvolvimento de software. Conforme Ken Schwaber [12], criador do SCRUM: "SCRUM é um processo ágil ou framework para gerenciamento de projetos ágeis. Ele é enquadrado como um processo para gerenciamento de projetos e certamente não é uma metodologia, se o fosse, seria muito pesado". Isso porque o SCRUM é um processo imprevisível que possibilita adaptações de forma a entregar algo de valor ao final e também por ter uma equipe autogerenciável, ao contrário das metodologias tradicionais que possuem uma estrutura de comando e controle com um futuro previsível. Assim faz com que parte de seus problemas possam ser identificados mais rapidamente O esqueleto do SCRUM Em seu livro, "Agile Project Management with SCRUM" (Gerenciamento ágil de projetos com SCRUM), Ken Schwaber [12] diz que "o SCRUM trava todas as suas práticas em um esqueleto iterativo e processo incremental" representado pela Figura 2-8, onde "o círculo inferior representa uma iteração de atividades de desenvolvimento que ocorrem uma após a outra. A saída de cada iteração é um incremento do produto. O círculo superior representa a inspeção diária que acontece durante a iteração, na qual os membros da equipe se reúnem para inspecionar as atividades e fazer as adaptações apropriadas. A condução da iteração é uma lista de exigências. Este ciclo se repete até que o projeto não seja mais dividido" [12]. Schwaber [12] considera que "o esqueleto funciona desta forma: no começo e uma iteração, a equipe revê o que deve ser feito. Em seguida, escolhe o que ela acha que pode se transformar em um incremento de funcionalidade potencialmente pronto para o uso, até o final da iteração. A equipe é então deixada sozinha para fazer o seu melhor esforço para o resto da iteração. No final da iteração, a equipe apresenta o incremento de funcionalidade desenvolvido para que os stakeholders (membros externos à equipe) possam inspecionar a funcionalidade e oportunidades de adaptação para que o projeto seja feito" [12]. No SCRUM, a iteração é chamada de sprint (ciclo). A explicação dada por Schwaber a respeito do que ele chamou de esqueleto do SCRUM é exatamente tudo o que deve ser feito dentro de um sprint de um projeto SCRUM. 25

41 Todo gerenciamento e responsabilidades em um projeto SCRUM são divididos entre os três papéis existentes no SCRUM, que são o product owner (dono do produto), o team (equipe) e o SCRUM master (mestre do SCRUM). Ken Schwaber [12] classifica o product owner como o "responsável por representar os interesses de todos, com uma participação no projeto e no seu sistema resultante". É ele quem consegue financiamento inicial contínuo do projeto, através da criação de requisitos globais e objetivos de retorno do investimento (ROI). A lista de requisitos de um projeto, em SCRUM, chama-se product backlog (lista de itens pendentes), e o product owner também é o responsável por priorizar os itens que compõem essa lista, assegurando que a funcionalidade mais valiosa, mais importante, será desenvolvida em primeiro lugar. A equipe é responsável por desenvolver as funcionalidades requisitadas pelo product owner e por descobrir como transformar um item do product backlog em um incremento de funcionalidade dentro de uma iteração. Uma equipe SCRUM tem que ser auto-gerenciável, auto-organizada e multifuncional, isto é, todos os integrantes da equipe devem realizar todas as atividades do projeto, não existem papéis de desenvolvedor, testador, arquiteto, entre outros. Os membros da equipe são coletivamente responsáveis pelo sucesso de cada sprint e do projeto como um todo. E por fim, o SCRUM master, que é quem trabalha para e com a equipe. É o responsável por auxiliar a equipe e garantir que a mesma está seguindo as práticas do SCRUM corretamente. Além disso, é também da responsabilidade do SCRUM master remover qualquer impedimento que a equipe encontra, identificar e auxiliar na resolução de conflitos, tentar tornar as metas claras para a equipe, garantir que a reuniões diárias ocorrem no mesmo horário e com duração máxima de 15 (quinze) minutos e assegurar que a equipe está totalmente funcional e produtiva. De maneira geral, todos os papéis do SCRUM devem estar comprometidos com o projeto. As pessoas não devem ser apenas interessadas pelo projeto, senão não estarão engajadas com o mesmo. Uma história muito conhecida do SCRUM é a do porco e da galinha, a qual é descrita por Ken Schwaber [12] em seu livro "Agile Project Management with SCRUM". A história é a seguinte: "uma galinha e um porco estão andando pela estrada. A galinha diz para o porco, "Você quer abrir um restaurante comigo?"o porco considera a questão e responde: "Sim, eu gostaria. Como você quer chamar o restaurante?"a galinha responde: "Presunto e ovo!"o porco para, pensa e responde: "Pensando bem, acho que não quero abrir um restaurante com você. Eu serei prático e você apenas envolvida". Essa 26

42 distinção é importante no SCRUM e relevante para insistir sobre a total visibilidade do SCRUM". O SCRUM possui alguns novos artefatos que são usados do começo ao fim de um projeto SCRUM. São eles: a user story (história de usuário), o product backlog, o sprint backlog (itens pendentes do sprint), o incremento de potencialidade pronto para ser usado no produto funcional, o release burndown chart (gráfico de manejo do projeto), o sprint burndown chart (gráfico de manejo do ciclo) e o task board (quadro de tarefas). A user story é a descrição da funcionalidade do ponto de vista do product owner, são descritas por item de backlog (itens pendentes) e incluem os critérios de validação de cada item. O product backlog é a lista principal com todas as funcionalidades (requisitos) desejadas pelo product owner no produto final, pode-se dizer que o product backlog é uma lista de requisitos funcionais e não funcionais. O product owner também é responsável por priorizar os itens do product backlog. Ele é dinâmico e evolui na medida em que o produto e o ambiente em que será utilizado evoluem, por isso o product backlog inicial é uma mera estimativa do projeto como um todo. O sprint backlog é a lista de tarefas que a equipe se comprometeu a concluir no sprint corrente. Itens do sprint backlog são retirados do product backlog se baseando na prioridade definida pelo product owner. A definição dos itens que farão parte do sprint backlog do sprint corrente são definidos durante a reunião de planejamento. Depois de definidos os itens, a equipe divide igualmente as tarefas. No final do sprint as tarefas realizadas pela equipe se tornarão um incremento de funcionalidade potencialmente pronto para ser colocado no produto ou até mesmo pronto para ser usado. O incremento de potencialidade pronto para ser usado é o incremento construído durante todo o sprint, o qual pode ser implementado imediatamente depois da entrega, caso o product owner deseje. Isso faz com que o incremento tenha um código perfeitamente testado, bem estruturado e bem escrito, que tenha sido construído dentro de um executável e onde a funcionalidade da operação do usuário é totalmente documentada. O release burndown chart é um gráfico onde a equipe acompanha seu progresso comparado com o planejado no início do projeto. É um gráfico 2D (duas dimensões) onde o eixo horizontal representa os sprints do projeto e o eixo vertical apresenta o total de trabalho restante no início de cada sprint, normalmente representado por pontos. O release burndown chart funciona muito bem em vários projetos e equipes diferentes, porém se o projeto apresenta muitas mudanças de requisitos, ele não funciona muito bem, por isso nem é indicado para projetos com esse perfil. 27

43 O sprint burndown chart é a representação gráfica do trabalho restante no sprint corrente, o qual é calculado diariamente. O eixo vertical do gráfico representa as horas de esforço restantes no sprint. O eixo horizontal representa os dias do sprint. O gráfico do burndown (manejo) deve ser representado por uma linha saindo do início do sprint com as horas iniciais, descendo até o último dia do sprint, sem deixar horas sobrando e, de preferência, sem faltar horas, ou seja, o esperado é chegar ao último dia do sprint com zero hora. Resumindo, o ideal é que o gráfico de burndown do sprint seja uma linha reta decrescente. O task board é um quadro de tarefas que mostra todo o trabalho que a equipe está desenvolvendo durante um sprint. Esse quadro é atualizado diariamente. Usualmente o task board é um quadro branco, o qual é preenchido manualmente com os itens de backlog escritos em post-it (papéis com cola na parte superior). Cada linha do quadro é um item do product backlog. Cada coluna é o estado de cada item de backlog. Normalmente, o quadro possui as seguintes colunas: - User Story: nessa coluna são colocadas as user stories; - To do (a fazer): nessa coluna ficam todos os itens do sprint backlog que deverão ser feitos durante o sprint; - In process (Em processo): post-it do item do sprint backlog que está em andamento (quando alguém da equipe decide por fazer um item do sprint backlog, ela tira o post-it referente a esse item da coluna "to do" e coloca na coluna "in process"; - To verify (Para verificar): quando o item do sprint backlog já foi desenvolvido e falta testar; - Done (Feito): quando o item do sprint backlog já foi desenvolvido, testado e não foi identificado mais nenhum defeito, ele é colocado na coluna "done", que significa que o item já está concluído e pronto para ser entregue ao product owner. Os itens que ficam nessa coluna são removidos no final de cada sprint Atividades e Fluxo do SCRUM O SCRUM possui cinco atividades bem definidas, são elas: estimation meeting (reunião de estimativas), sprint planning (planejamento do sprint), daily SCRUM (reunião diária), sprint review (revisão do sprint) e sprint retrospective (retrospectiva do sprint). A estimation meeting, que é a reunião de estimativas, é a primeira atividade que acontece dentro do ciclo do SCRUM. Nela, o tamanho dos itens de product backlog é estimado pela equipe e posteriormente são priorizados pelo product owner. Todos os membros da equipe fazem uma estimativa por pontos de cada user story. 28

44 É importante deixar claro que, em SCRUM, as estimativas são baseadas na complexidade de cada item de backlog e não pelo tempo que pode ser gasto para desenvolvêlo. A forma mais comum de se fazer estimativa em SCRUM é através do planning poker (planejamento com baralho SCRUM). O planning poker funciona da seguinte maneira: - um baralho é fornecido a cada membro da equipe e cada carta tem um valor de estimativa válido. Esse baralho não é um baralho comum, mas sim um baralho específico para a prática SCRUM, o qual possui cartas com os seguintes valores:? (quando a pessoa não sabe quantos pontos vale determinada user story), 0 (quando não requer nenhum esforço), 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, esses números representam o esforço em pontos; - cada user story é lida e discutida rapidamente pela equipe; - cada membro da equipe escolhe uma carta representando sua estimativa; - quando todos da equipe já tiverem escolhido sua estimativa, eles mostram sua estimativa ao mesmo tempo; - as diferenças das estimativas são discutidas (principalmente os valores discrepantes); - faz-se reestimativas até que toda a equipe chegue a um consenso. A sprint planning, que é a reunião de planejamento do sprint, é a segunda atividade executada no fluxo de atividades do SCRUM. Ela é dividida em duas partes, a sprint planning 1, que é onde se define o objetivo do sprint e onde são selecionados os itens do product backlog. Na verdade essa parte da reunião acontece apenas no início do projeto, pois nela também são definidas a quantidade de sprints que terá o projeto, os dias das sprint review e retrospectivas e também é feito o agendamento das reuniões diárias (local e hora). A segunda parte da reunião de planejamento ocorre todo início de sprint, nela são definidas as tarefas de cada user story para criar o sprint backlog. O ideal é que a tarefa dure apenas um dia, caso a tarefa seja maior que um dia, deve-se quebrar a tarefa em duas tarefas menores. A reunião como um todo não deve ultrapassar oito horas, sendo de quatro horas a duração máxima de cada parte da sprint planning. A daily SCRUM é a reunião diária que deve ser realizada seguindo as exigências do SCRUM. Ela deve ser realizada em pé, com todos os membros da equipe juntos, deve ter duração de no máximo quinze minutos e deve ser sempre no mesmo local e horário. O ideal é que a reunião seja realizada logo pela manhã (no início do dia), uma vez que ela apóia a determinar as atividades do dia, ou então no final do dia, pois os membros da equipe falarão o que foi feito durante o dia e o que farão no dia seguinte. O objetivo dessa reunião é atualizar e inspecionar o progresso da equipe. Todos os impedimentos devem ser apontados, porém 29

45 soluções de problemas maiores ou dúvidas ocorridas durante o dia devem ser discutidas fora da reunião diária. Durante essa reunião todos os membros da equipe, um de cada vez, devem responder a três questões básicas: O que fez ontem? O que vai fazer hoje? Existe algum impedimento? Assim, ao final da reunião a equipe tem uma melhor visão do trabalho que foi concluído e o que ainda falta fazer. A sprint review é a reunião de revisão do sprint. Ela é realizada todo final de sprint, onde a equipe apresenta para o product owner os resultados obtidos durante o sprint e demonstra as funcionalidades e arquiteturas desenvolvidas. Essa reunião é informal, isto é, não precisam ser geradas ata nem apresentação em slides e deve ser feita em, no máximo, duas horas. Durante a reunião o projeto também é avaliado, tendo como base o objetivo do sprint definido na reunião de planejamento, isto é, espera-se que a equipe tenha concluído todos os itens do sprint backlog. Nessa reunião também pode ser solicitado pelo product owner a inclusão de uma nova funcionalidade ou mesmo uma alteração da funcionalidade feita, essa nova solicitação deve ser adicionada como um novo item de backlog. Por fim, temos a última atividade a ser realizada dentro de um ciclo SCRUM, que é a sprint retrospective, a reunião de retrospectiva. Essa reunião também é realizada no final do sprint, preferencialmente depois da sprint review. O objetivo da retrospectiva é aprender com a experiência anterior, melhorando a produtividade da equipe. É obrigatória a presença de todos os membros da equipe na reunião. A retrospectiva também é uma oportunidade para a equipe discutir o que está dando certo e o que não está, e consentir em ações para mudança. Por isso, é comum que na reunião sejam abordadas e discutidas as seguintes questões: O que aconteceu?, O que funcionou bem? e O que precisa ser melhorado? O fluxo de um projeto SCRUM, o qual pode ser visto na Figura 2-8, inicia-se com uma visão do sistema a ser desenvolvido, a qual é fornecida pelo product owner, que também é responsável pelo financiamento do projeto e por entregar a equipe um product backlog. O product owner também é responsável por priorizar os itens do product backlog, para que os itens com maior probabilidade de gerar altos valores sejam desenvolvidos primeiro. Todas essas atividades são realizadas no início do projeto, na chamada estimation meeting. 30

46 A seguir, iniciam-se os ciclos do SCRUM, que são os sprints. Todo o trabalho é feito nos sprints. Cada sprint deve ter duração de 2 (duas) ou 4 (quatro) semanas, no máximo, sendo que todos os sprints de um mesmo projeto devem ter a mesma duração. Cada sprint é iniciado com uma sprint planning, onde product owner, SCRUM master e equipe se juntam para decidir o que será feito no sprint. Selecionando a partir do product backlog priorizado, o product owner diz à equipe o que é desejado e a equipe responde para o product owner o quanto do desejado ela consegue desenvolver no sprint. Seguindo o fluxo do SCRUM, vêm as daily SCRUM, que devem ser realizadas, rigorosamente, todos os dias no mesmo horário e no mesmo local, com duração máxima de quinze minutos. Por fim, no último dia do sprint, são realizadas as reuniões de sprint review e logo em seguida a sprint retrospective. Assim, estará terminado o primeiro ciclo do SCRUM, isto é, o primeiro sprint do projeto. Todas essas atividades se repetem nos demais sprints, até chegar ao último sprint do projeto, que é quando o projeto se encerra. 2.2 Estudo de Caso Figura 2-8: Fluxo de um projeto SCRUM. (Fonte: Site O processo SCRUM da empresa PowerLogic 31

47 Para o desenvolvimento do estudo de caso da Dextra Sistemas, detalhado na próxima subseção, foram realizadas várias pesquisas, a fim de encontrar algum material sobre caso de sucesso de empresas que conseguiram conquistar o MPS.Br, principalmente o nível F, utilizando processo para projetos SCRUM em desenvolvimento ágil de software. Foi muito difícil encontrar material sobre esse assunto. Somente a empresa PowerLogic conseguiu o MPS.Br nível F de um processo SCRUM. Sendo assim, foi utilizado o processo desenvolvido por essa empresa como base deste trabalho, uma vez que o objetivo do mesmo é bem semelhante ao ocorrido com a empresa PowerLogic. Conforme publicado pela SOFTEX [13], a PowerLogic Consultoria e Sistemas é uma empresa brasileira, com sede em Belo Horizonte, com 12 anos de existência atuando no segmento de desenvolvimento de produtos e soluções e de serviços de fábrica de software" e seu objetivo era combinar a agilidade natural dos métodos ágeis e a maturidade adquirida por meio do MPS.Br, constituindo uma experiência concreta na busca de resultados positivos para processos de TI (tecnologia da informação) e para o programa de Melhoria Contínua de Processos MPS.Br Pioneira em métodos ágeis. A PowerLogic já era certificada pelo MPS.Br nível F para o processo que segue o RUP, o qual já era utilizado há um certo tempo pela empresa. A utilização de SCRUM na empresa passou a ser maior uma vez que começaram a surgir problemas com imprevisibilidade, ruídos de comunicação, documentações extensas que pouco ajudavam no processo, que precisavam ser encarados de forma diferente e que exigiam que não seguisse passos semelhantes entre os diversos projetos existentes, que possuem peculiaridades que apenas com a implementação afloram. "Além disso, tarefas do processo de desenvolvimento de software fazem parte de um processo criativo, não linear e não palpável, fazendo com que modelos incrementais e iterativos se apresentem como a melhor solução diante da realidade dos projetos PowerLogic." [13]. Isso fez a empresa buscar a certificação MPS.Br para esse novo processo. Buscando associar os conceitos do MPS.Br com os conceitos do SCRUM, "os princípios e valores de métodos ágeis foram relacionados e mapeados em todo o ciclo de vida do software a um ou mais de um princípio do Manifesto da Agilidade verificando sua aplicabilidade. Estes princípios abordam aspectos do desenvolvimento como análise, projeto, implementação, testes, além de outros, como gerenciamento de projetos e de métricas de satisfação do produto final entregue [13]. 32

48 As áreas de processo do MPS.BR foram cuidadosamente relacionadas com as características dos métodos ágeis. Desse modo, foram discutidos gerência de requisitos, planejamento e acompanhamento de projetos, gerência de configuração, garantia de qualidade de software e medição e análise, presentes no nível F do MPS.BR e sua aplicabilidade ao SCRUM" [13]. A adoção de modelos de qualidade de software, como o MPS.Br, traz para a empresa mais formalismo ao processo por ela utilizado, agregando valor com a qualidade do software desenvolvido. Assim, pode-se dizer que, apesar dos modelos de qualidade e metodologias ágeis possuírem fundamentos inicialmente divergentes, eles puderam complementar um ao outro e estabelecer o equilíbrio no processo de desenvolvimento implantado na empresa. Para desenvolver um processo para projetos SCRUM compatível com o MPS.Br nível F sem aferir os princípios ágeis, a PowerLogic contratou uma empresa de consultoria para auxiliá-los nesse desenvolvimento. Inicialmente, foi feito um levantamento e desenho do processo já existente, o qual é aprimorado a cada dia e aplicado em projetos para verificar a adequação do mesmo. Essas melhorias só são percebidas quando o processo está inteiramente institucionalizado e funcionando em um fluxo contínuo. Analisado inicialmente, o MPS.Br parecia muito formal e pouco aderente à nova realidade da empresa, mas era necessário por causa de seus resultados comprovados e da grande aceitação por todos os clientes. Era difícil para as pessoas envolvidas nesse processo entender como fazer um processo que continuasse com os benefícios do SCRUM e que conseguisse atingir um nível de maturidade do MPS.Br. Mas a empresa chegou à conclusão de que essa fusão não era tão impossível, uma vez que a mesma entende que o MPS.Br diz "o que fazer" mas não impõe o "como fazer" enquanto que as metodologias ágeis contém informações específicas de "como fazer". Ao comparar as metodologias ágeis com os modelos de qualidade, a PowerLogic listou os cinco maiores desafios, que são: - GPR (gerenciamento de projeto): Como gerenciar com base em "planejamento contínuo" em lugar do "grande plano inicial"? - GPR: Como "abraçar" a mudança e "controlá-la" ao mesmo tempo? - GRE (gerenciamento de requisitos): Como estimar requisitos que são parcialmente conhecidos? - GQA (gerenciamento da qualidade): Como averiguar qualidade de produto em um processo "iterativo" com time-boxed (tempo fechado)? - MED (medição e análise): O que são indicadores importantes em um processo ágil? 33

49 Para iniciar o desenvolvimento do processo ágil, a PowerLogic partiu da idéia de que "formalidade não é sinônimo de conformidade" e que "informalidade não é sinônimo de agilidade". Com isso, a empresa pensou na seguinte forma de desenvolvimento do processo: inserir em cada disciplina do nível F do MPS.Br (GPR, GRE, GCO, GQA e MED) os princípios do manifesto ágil com ênfase no SCRUM. A PowerLogic também se baseou nas lições aprendidas em processo de desenvolvimento de software unificado e as lições aprendidas em processos ágeis de desenvolvimento de software. Essas lições são descritas, de forma resumida, a seguir. No final, o resultado foi positivo, e a PowerLogic conquistou o nível F do MPS.Br para um processo ágil. Ainda nesse capítulo será descrito, de forma resumida, o processo ágil desenvolvido pela PowerLogic. PowerLogic - Lições aprendidas em Processo de Desenvolvimento de Software Unificado (experiência da empresa nas décadas de 80 e 90): 1- Processos em cascata não são adequados para o desenvolvimento de softwares complexos, porém, atualmente, a maior parte dos projetos corporativos caem nessa categoria; 2- Projetos complexos são melhor gerenciados por Processos Empíricos e Iterativos; 3- O RUP foi o primeiro Processo Iterativo a se popularizar, no entanto, sua extensão e complexidade usualmente distraem a atenção sobre seu caráter iterativo. A grande maioria das implementações de processos unificados terminam como bisnetos UML dos processos em cascata; 4- Contratos 'escopo fechado' x Necessidades técnicas: o modelo de Fábrica de Software pressupõe a separação física de especialidades, dificultando ou impossibilitando uma abordagem verdadeiramente iterativa; 5- Software é 50% introspecção e 50% comunicação. A comunicação por escrito é boa para a criação de memória, mas é o canal menos eficaz para obtenção de entendimento; 6- Documentação realmente útil em desenvolvimento de software é obtida por conseqüência de atividades produtivas e não como um esforço à parte. Atividades meramente documentacionais tendem ao desperdício [14]. PowerLogic - Lições aprendidas em Processos Ágeis (experiência da empresa em ): 34

50 1- O Manifesto Ágil sumariza de forma sensata a experiência de seus dezessete autores em projetos reais, sendo consistente com a experiência da grande maioria das empresas, como a PowerLogic, que atuam com metodologia aplicada, focada em resultados; 2- O caráter sensato de ênfase do Manifesto Ágil tem sido ignorado em algumas posturas radicais que, precipitadas, chegam a confundir agilidade com mera informalidade; 3- Duas pequenas revisões de um dos princípios do Manifesto Ágil foram realizadas, através da experiência adquirida: indivíduos e interações continuam mais valiosos do que processos e ferramentas, mas muitas ferramentas se mostraram fundamentais para práticas de metodologias ágeis; e não espere auto-organização e soluções técnicas com alta conformidade de equipes frágeis, de perfil mediano. A ênfase em indivíduos e interações exige ênfase na boa formação de equipes e na preservação de talentos; 4- Processos ágeis são mais leves (possuem menos práticas) porém exigem alto índice de disciplina. Suas motivações são mais difíceis de explicar e, por conseqüência, de se compreender [13]. O processo ágil desenvolvido pela PowerLogic está dividido em quatro fases bem definidas, que são: pre-game (pré-jogo), development (desenvolvimento), monitoramento e controle e post-game (pós-jogo). Na Figura 2-9 a seguir, pode ser observada uma ilustração do ciclo de vida do processo elaborado. Figura 2-9: Ciclo de vida dos projetos de desenvolvimento de software área de produtos [14]. No pre-game é feita a concepção arquitetural e organização inicial de um novo release (projeto) de um produto baseado na lista de product backlog elaborado para o mesmo, seguido de uma estimativa inicial de prazo e custo. Nessa fase também são levantados e identificados os riscos e as ações para minimizar o impacto dos mesmos. Também se defini nessa fase a 35

51 equipe do projeto (SCRUM team equipe SCRUM). O pre-game é como a fase de concepção do RUP, porém é mais curta e com duração fixa de 7 a 15 dias. A fase development tem o objetivo de colocar em prática o que foi planejado no pregame. É nessa fase que o principal acontece. É realizada de forma iterativa, através de ciclos de time-boxed chamados de sprints que, no caso do processo da PowerLogic, tem duração de trinta dias corridos. Em cada sprint são executadas atividades de refinamento dos itens do product backlog, análise, projeto, desenvolvimento e testes, cujo resultado final deve ser um incremento do produto funcionando, o qual será apresentado para o product owner na reunião de sprint review que acontece em todo final de sprint. Durante os sprints também são realizadas as reuniões de daily SCRUM que ocorrem diariamente, onde são discutidas as tarefas que já foram realizadas e que ainda serão feitas. A fase de Monitoramento e Controle compreende as atividades de medição e análise e de gestão, que verificam se as atividades estão sendo produtivas. Ela garante o bom andamento do projeto em relação ao planejado nas reuniões de planejamento, que ocorrem todo início de sprint. Esse acompanhamento é feito através das reuniões de daily SCRUM, sprint review, release review (revisão do projeto - que acontece no encerramento do projeto) e retrospective meeting (que também ocorre no final de cada sprint, após a sprint review). Diversas medidas são coletadas diariamente ao longo do projeto. Informações do tipo "previsto x realizado" são disponibilizadas para o SCRUM master e para o product owner. Os quadros brancos também são uma forma de monitoramento, uma vez que eles "mantêm as informações mais importantes disponíveis, afixados em local visível para toda a organização" [13]. E por último vem a fase post-game, que é onde ocorre a entrega final do produto (embalagem, documentação, liberação para o mercado). Nessa fase também é feita a avaliação do projeto como um todo, refletindo sobre as práticas empregadas, indicadores finais e lições aprendidas de uma forma geral. É nessa fase que ocorre a reunião de release review, que consiste em uma demonstração do produto final do ponto de vista do cliente, discussões e levantamento de lições aprendidas. O resultado final dessa fase é a documentação final, que é um CD com o produto e funcionalidades já testadas. Em relação às disciplinas contempladas no MPS.Br nível F (GPR, GRE, GCO, GQA e MED), as alterações feitas pela PowerLogic, para adaptá-las ao processo ágil que estava sendo desenvolvido, serão apresentadas a seguir. Na disciplina de gerência de projetos (GPR) foram adotados os conceitos de release e release plan (plano do projeto). 36

52 O planejamento será realizado via release planning (reunião de planejamento realizada no início do projeto, para definição dos itens do product backlog, equipe, quantidade de sprints) e sprint planning (reunião de planejamento de sprint, realizada todo início de sprint, onde são definidos e estimados os itens que sairão do product backlog e farão parte do sprint backlog), sendo que esse último está dividido em sprint planning 1 (definição e priorização) e sprint planning 2 (estimativas). O acompanhamento contínuo é feito através de inspeção direta do SCRUM master, o acompanhamento formal diário é feito através das reuniões diárias e o acompanhamento mensal via sprint review e release review. O quadro branco, na PowerLogic chamado de agile radiator (radiador ágil), também é uma forma de acompanhamento diário do projeto. É feita também uma reserva de tempo no planejamento de cada sprint para que os impedimentos possam ser discutidos e solucionados. Algumas outras práticas específicas da PowerLogic são: apropriação de horas diárias, medição de produtividade individual, matriz de competências. A disciplina de gerência de requisitos (GRE) possui como pontos chaves a utilização de pocker planning (planejamento com baralho) para realizar as estimativas dos itens de backlog, a quebra de um item do product backlog em atividades que possam ser completadas por cada membro da equipe em um dia, captura contínua de product backlog. Um ponto importante é em relação à forma como o processo ágil da PowerLogic trata as solicitações de mudança. As mudanças ao final ou dentro do sprint que não afetam o objetivo do sprint são consideradas solicitações de mudança leve, isto é, não requerem uma solicitação de mudança propriamente dita. Solicitações de mudança somente são requeridas em situações críticas, por exemplo, quando a equipe não vai conseguir cumprir o objetivo do sprint, ou para mudanças de configuração, por exemplo, em alteração de versão de framework (estrutura). A PowerLogic adota como prática adicional a rastreabilidade do requisito ao código, através de uma matriz de rastreabilidade. Em relação à disciplina de garantia da qualidade (GQA) foi introduzido o conceito de post-sprint (pós-ciclo) de QA, que são iterações de quinze dias (time-boxed) de QA, após cada sprint. São realizados testes funcionais automatizados. Os erros encontrados pelo QA contam pontos contra a equipe, já os erros capturados pelo cliente contam pontos contra o QA. Isso tudo em relação à qualidade de produto. Já as práticas de qualidade de processo devem auditar o desempenho do processo, os produtos de trabalho e atividades previstas em todas as fases. A equipe de QA deve ser compartilhada para todos os projetos, deve garantir que os quadros 37

53 brancos (agile radiators) estão sendo usados e deve fornecer um relatório à Diretoria Técnica da PowerLogic contendo os resultados das auditorias. Na disciplina gerência de configuração (GCO) são utilizados a integração contínua e o controle de código fonte, componente, executável, release plan, documentação e mídia CD/DVD dos produtos. As práticas de gerência de configuração devem ser rigorosas e completas, por se tratarem de produtos de mercado também exigem especial controle de versão. Os itens de configuração são definidos em nível de produto e não de projeto, caso o produto tenha um projeto subseqüente, deve-se definir somente alterações em versões de itens anteriores, evitando assim a redundância. É importante ressaltar que as alterações de versões de itens de configuração devem ser feitas formalmente, através de uma solicitação de mudança que deverá ser aprovada, para evitar a falta de sincronismo e integridade provocada pelas modificações não controladas. Por fim, a disciplina de medição e análise, onde foram definidos indicadores ágeis, que são assiduidade de daily SCRUM, remoção de impedimentos, freqüência de integração e inspeção, e indicadores clássicos, que são produtividade (velocidade x qualidade), metas e previsto x realizado. Os resultados tangíveis obtidos pela medição devem contemplar o desempenho da equipe como um todo e não somente indicadores individuais e devem ser divulgados durante as reuniões de retrospectiva e analisados pela equipe, coletivamente. A PowerLogic também criou a figura do Gerente de Processo que, como apoio ao SCRUM master ajuda no incentivo e catequese de práticas ágeis, e como apoio ao assessor da diretoria, ajuda na garantia de resultados da implantação do processo. Após a implantação e utilização contínua do processo ágil desenvolvido pela PowerLogic, conseguindo resultado positivo na avaliação MPS.Br nível F, foi possível observar melhorias significativas em relação ao desempenho da equipe e na qualidade do produto final. Na fase de pre-game se destacaram as seguintes melhorias: planejamento antecipado da disponibilidade da equipe, levando em consideração impedimentos como horas de trabalho, férias, horas gastas em reuniões; garante a participação real de cada membro envolvido; alinhamento das metas, planejamento e definição do objetivo de cada sprint com o consenso de todos os envolvidos promove o comprometimento e a visibilidade; a definição de indicadores da equipe e individuais estimula o alcance de melhores resultados; e a identificação e categorização dos riscos anteciparam possíveis problemas. "Os indicadores criados para as áreas de processo Gerência de Projetos e Gerência de Requisitos, principalmente, proveram importante feedback (retorno) para a equipe e criou metas a serem alcançadas por cada um. Indicadores de Gerência de Configuração asseguraram 38

54 que as práticas determinadas foram seguidas provendo maior controle das versões geradas e integração contínua. As práticas de Gerência de Qualidade para Processo garantem a institucionalização e desempenho do processo e produtos de trabalho, através das auditorias nas áreas envolvidas" [13]. As melhorias que merecem destaque na fase de development são: gestão a vista através do quadro branco (Agile Radiator), promovendo o feedback real e imediato; realização de reuniões de inspeção contínua (daily SCRUM); integração contínua trouxe resultados importantes e informações essenciais para o planejamento e acompanhamento do projeto; rastreablidade entre requisito e código fonte, gerando uma matriz de rastreabilidade facilita a análise de impacto das mudanças; integração da equipe, estimulando a troca de conhecimento e a utilização de pair programming (programação em par) entre os membros da equipe; conceito de código compartilhado é importante, uma vez que o mesmo poderá ser modificado ou revisado por diferentes membros da equipe; definição de um objetivo, tanto de cada sprint como do projeto como um todo, possibilita melhor visibilidade e norteia o caminho a ser seguido por cada membro da equipe. No post-game a melhoria mais importante observada foi a realização da reunião de retrospectiva, que acontece no final de cada sprint e onde ocorre a coleta das lições aprendidas do projeto, avalia-se o que deu certo e o que deu errado, alimentando o projeto e o processo e avalia também se algo está sendo feito em relação ao que foi levantado na reunião de retrospectiva anterior. Podem-se observar também melhorias organizacionais nas áreas de gerência da qualidade de processo e de produto e de gerência de configuração. A nova área gerência da qualidade de processo criou um desconforto saudável, "fazendo com que as pessoas dêem o melhor de si e concretize ações para o objetivo maior organizacional" [13]. Essa área "provê apoio total à condução dos projetos, executa a manutenção do processo, aceitando sugestões e inserindo melhorias necessárias e executa auditorias para garantia da execução do processo" [13]. Já a área de gerência da qualidade de produto "provê suporte à qualidade dos produtos com testes automatizados, manuais e de integração" [13]. E por último a área de gerência de configuração que garante a integridade dos itens de configuração do release, apóia a geração de baselines (pacote) e a integração contínua. A experiência positiva vivida pela empresa PowerLogic, tanto em relação ao processo de implantação do modelo de qualidade MPS.Br nível F quanto aos bons resultados obtidos com essa fusão (MPS.Br com SCRUM), fez com que a empresa colocasse como próximo objetivo a melhoria do processo ágil desenvolvido com foco na avaliação para obtenção do nível C do MPS.Br. 39

55 3 ELABORAÇÃO DA SOLUÇÃO 3.1 Histórico da Dextra Sistemas A empresa onde foi desenvolvido esse trabalho de conclusão de curso é a Dextra Sistemas. A Dextra está presente no mercado de TI desde Foi fundada como uma empresa especializada em consultoria nas áreas de integração de sistemas corporativos. Atualmente, a mesma possui três linhas de atuação, que são: integração e desenvolvimento de sistemas sob medida, treinamento em TI e consultoria em TI. A excelência dos serviços prestados pela Dextra está apoiada em profissionais especializados, processos estabelecidos e uma larga experiência em projetos. O capital humano é um elemento chave na estratégia de atuação da empresa, que investe continuamente na atualização e capacitação de seus profissionais, propiciando um ambiente encorajador para serem os melhores naquilo que realizam. A alta qualidade dos serviços prestados aliada ao compromisso em gerar resultados e proporcionar maior vantagem competitiva a seus clientes tem propiciado a Dextra relacionamentos duradouros e bem sucedidos com empresas de diversos segmentos de mercado. A Dextra teve um crescimento muito expressivo nos anos de 2006 e 2007 e com isso surgiu a necessidade da definição e implantação de um processo mais formal. A empresa já contava com o ProUD (Processo Unificado Dextra) que se baseava fortemente no RUP. A versão 1.0 do ProUD era bastante enxuta e se aplicava muito bem ao tamanho e características da empresa e de suas equipes de trabalho até então. O objetivo da evolução e melhoria do processo da Dextra era ter um nível maior de formalização das atividades e papéis, bem como coletar e analisar indicadores de projeto que dessem a visibilidade necessária em relação à qualidade do produto, pontualidade nas entregas e previsibilidade de custo. O resultado de um ano de trabalho foi o ProUD 2.0, o qual foi lançado oficialmente na Dextra em Setembro de Essa nova versão do processo possui quatro grandes fases, que são: planejamento, refinamento da solução, execução e encerramento. Um dos objetivos do projeto de melhoria e evolução do ProUD, era a de implementar também um modelo de qualidade reconhecido no mercado de software. A empresa escolheu o 40

56 MPS.BR por ser um programa brasileiro, voltado para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software. A Dextra obteve o certificado de qualidade de software MPS.BR nível F, ratificando assim todo seu processo de desenvolvimento de sistemas. Teve como principais pontos fortes: a) o conjunto de ferramentas adotado, que automatiza as atividades e traz maior controle e ganho de produtividade da equipe; b) o envolvimento das equipes dos projetos com o processo. Ambos eram as grandes preocupações da Dextra desde o início do desenvolvimento do processo. No início de 2008 a Dextra teve o primeiro contato com metodologias ágeis, iniciando um projeto totalmente SCRUM. Com a disseminação das metodologias ágeis no mercado, diversos clientes começaram a procurar por essas metodologias para realização de seus projetos. Por esse motivo e com a experiência positiva do projeto em SCRUM que já estava em andamento, a Dextra resolveu implantar a metodologia ágil SCRUM. Atualmente quase todos os projetos desenvolvidos na Dextra são em SCRUM. O sucesso dessa metodologia se deve, principalmente, ao fato dos projetos serem de escopo aberto, aceitarem tranqüilamente mudanças solicitadas pelo cliente e terem pelo menos uma funcionalidade pronta a cada duas semanas (no caso da Dextra, adotou-se que o ideal é os sprints terem duração de duas semanas). Com esse novo cenário de projetos da Dextra, se tornou importante pensar a respeito de uma padronização para a aplicação do SCRUM nos projetos da empresa, uma vez que até os dias de hoje cada equipe, cada projeto aplica o SCRUM de uma forma diferente, mas sempre respeitando os princípios definidos para essa metodologia. Assim surgiu a idéia de se criar um processo para projetos SCRUM, uma vez que o processo de desenvolvimento de software já existente na empresa, e já avaliado no MPS.Br nível F, é baseado no RUP e não se encaixa para projetos SCRUM. Em meados de Abril de 2009 iniciaram-se estudos sobre SCRUM, como criar um processo para essa metodologia e como conseguir um processo SCRUM que também possa ser, futuramente, avaliado no MPS.Br nível F. Juntos, o SEPG (Software Engineering Process Group Grupo de Processos de Engenharia de Software), a área de qualidade e profissionais qualificados em SCRUM, em meados de Agosto de 2009, deram início ao desenvolvimento do processo para projetos SCRUM da Dextra. O objetivo era criar um processo simples, que não afete a agilidade do SCRUM mas também que não comprometem as exigências impostas pelo MPS.Br nível F. A idéia de se 41

57 criar um processo é que todos os projetos gerem documentos com templates padrões, sigam realmente todos os princípios do SCRUM e trabalhem de maneira similar, para não haver divergências entre os projetos em relação a forma de se aplicar SCRUM dentro da Dextra. O objetivo da Dextra agora é gerar uma primeira versão desse processo que, como aconteceu com o processo baseado no RUP, será atualizado, incrementado e melhorado com o passar do tempo e à medida que o processo for sendo utilizado pelos projetos, realizando as adaptações necessárias. Em um futuro não muito distante, quando o processo para projetos SCRUM já estiver bem consolidado, a expectativa da Dextra é conquistar o MPS.Br nível F também para esse processo, garantindo assim uma maior qualidade dos projetos SCRUM para seus clientes e podendo também conquistar novos clientes. 3.2 Motivação para a elaboração de um processo para projetos SCRUM na Dextra A grande motivação que levou a Dextra a querer implantar um processo também para os projetos em SCRUM foi o sucesso conquistado com o processo de desenvolvimento ProUD, que segue o modelo RUP. Depois do mesmo ter sido avaliado no MPS.Br nível F, novos clientes começaram a procurar e a se interessar pelos softwares produzidos pela empresa. Ter um processo que foi avaliado por um modelo de qualidade traz muita credibilidade para a empresa, os clientes ficam mais seguros em relação ao produto que estão comprando e têm garantia de que estão adquirindo um software com qualidade. Além disso, a necessidade de todos os projetos seguirem um padrão para o desenvolvimento de software seguindo SCRUM também é fundamental para ter um produto final com qualidade igual para todos os clientes. Quando o processo segue um padrão único na empresa, é mais fácil avaliar o que está seguindo as normas, garantindo dessa forma a qualidade de processo e do produto final gerado. É de extrema importância que todos os projetos SCRUM da empresa gerem todos os documentos necessários, de acordo com um template padrão estabelecido pela mesma e com todas as informações que são essenciais para uma futura evolução do projeto, caso venha ocorrer. Também é preciso que todos os projetos sigam os princípios básicos do SCRUM, para que essa metodologia ágil seja aplicada de forma correta. E por fim, é preciso um processo de desenvolvimento padronizado, que seja seguido por todos os projetos que utilizam determinada metodologia, para que se possa aplicar a garantia da qualidade de processo e de 42

58 produto nos mesmos. Sem um padrão e sem um processo é impossível verificar se um projeto está seguindo as normas exigidas pela empresa ou não. 3.3 Processo SCRUM da Dextra Sistemas Para atingir o objetivo proposto por esse trabalho de conclusão de curso (aplicar atividades da Garantia da Qualidade de Software para projetos SCRUM), primeiramente foi necessário pensar em conjunto com o SEPG da Dextra Sistemas (empresa onde esse projeto será aplicado) na elaboração de um processo de desenvolvimento de software ágil, que possa ser seguido por todos os projetos SCRUM da empresa. Após isso, foi realizada uma análise sobre o estudo de caso realizado nesse trabalho, a respeito da experiência positiva da empresa PowerLogic com processo ágil e MPS.Br nível F. Várias dúvidas surgiram e pesquisas e discussões em reuniões foram realizadas para que essas dúvidas fossem solucionadas. As dúvidas foram as seguintes: 1- Como é feita a qualidade de processo em SCRUM? 2- Quais indicadores são coletados em SCRUM? 3- Que alterações devem ser realizadas na ferramenta TRAC (vide Apêndice 1.2) utilizada na Dextra, para contemplar user stories, product backlog, sprint? 4- Como é feito o acompanhamento do projeto? Existe registro formal da reunião diária? 5- Como são guardadas as informações do quadro de tarefas? Como são formalizadas as reuniões? 6- Como será o ciclo de vida do processo ágil? Após vários estudos e reuniões as respostas para as dúvidas surgidas foram aos poucos esclarecidas e foi possível dar início ao desenvolvimento do processo, que está demonstrado na Figura 3-1. As dúvidas que ainda não ficaram definitivamente resolvidas serão discutidas novamente em outras reuniões até se atingir uma resposta final. 43

59 Figura 3-1: Processo Dextra para desenvolvimento em SCRUM [19]. Um dos primeiros aspectos a serem definidos foi o ciclo de vida do processo. Ficou decidido que o ciclo de vida será formado pelas fases: Sprint 0, Execução (onde serão executados os sprints) e Encerramento, as quais podem ser observadas através da Figura 3-2. Figura 3-2: Ciclo de vida do Processo SCRUM da Dextra. 44

60 Os papéis presentes no processo são mostrados na Figura 3-3, sendo: time, product owner, SCRUM master, gerente de projeto, auditor de qualidade e auditor de baseline. As disciplinas, nessa primeira versão do processo (mostradas na Figura 3-4) estão divididas em três: implementação, garantia da qualidade e gestão de configuração. Figura 3-3: Papéis do Processo SCRUM da Dextra. Figura 3-4: Disciplinas do Processo SCRUM da Dextra. 45

61 Inicialmente existem os seguintes produtos de trabalho, que são mostrados na Figura 3-5: user story, gráfico de burndown do projeto, incremento do produto, aceite de sprint, apresentação dos compromissos com cliente, apresentação de kickoff (inicial) interno, lista de verificação de QA SCRUM, release notes (notas do projeto), team planning (planejamento da equipe), quadro de tarefas, gráfico de sprint burndown, sprint backlog, product backlog, relatório de status (estado) para cliente, relatório de status interno, relatório de auditoria de produto e relatório de auditoria da qualidade. Para a primeira versão do processo, a única ferramenta disponível será o TRAC (ferramenta de acompanhamento de alterações), que deverá ser adaptado para o SCRUM. Essa adaptação será realizada futuramente. Figura 3-5: Produtos de trabalho do Processo SCRUM da Dextra. As atividades envolvidas nessa primeira versão do processo, no Sprint 0, demonstradas na Figura 3-6, são: organizar o ambiente do projeto, preparar equipe, reunião inicial com o cliente, reunião inicial com o time, estimar product backlog e as atividades relacionadas a disciplina de Garantia da Qualidade (vide). 46

62 Figura 3-6: Diagrama do Sprint 0. Na fase de Execução (em cada sprint do projeto) as atividades, mostradas na Figura 3-7 são: reunião de planejamento do sprint, manter backlog, validar itens de backlog em desenvolvimento, implementar o sprint backlog, reunião de revisão do sprint, retrospectiva do sprint e atividades da qualidade. 47

63 Figura 3-7: Diagrama da Fase de Execução. Ainda dentro da fase de execução existe um subprocesso chamado Acompanhamento e Controle, o qual envolve as seguintes atividades: monitorar e controlar, manter registros de ação gerencial. Essas atividades estão relacionadas com o acompanhamento formal do projeto durante todos os sprints do mesmo e podem ser observadas na Figura 3-8. O gerente de projeto é o responsável por esse acompanhamento. 48

64 Figura 3-8: Diagrama do subprocesso Acompanhamento e Controle. Na fase de Encerramento as atividades, demonstradas pela Figura 3-9 são: obter aceite do cliente, encerrar projeto, fornecer resultados das medições, liberar baseline, auditar baseline, auditar configuração e todas as atividades da disciplina garantia da qualidade. Figura 3-9: Diagrama da Fase de Encerramento. 49

65 3.4 SCRUM Dextra Atividades de Garantia da Qualidade Dentro da disciplina de Garantia da Qualidade, que está presente em todas as fases do ciclo de vida do processo SCRUM da Dextra, estão as seguintes atividades: realizar auditoria de processo, realizar auditoria de produto, disponibilizar relatório de auditoria, acompanhar as não conformidades e consolidar todas as auditorias realizadas. Em todas as atividades dessa disciplina, que podem ser observadas através da Figura 3-10, o executor principal e único é o auditor da qualidade. Como o foco desse trabalho não é o processo SCRUM completo, e sim apenas a disciplina de garantia da qualidade, as outras disciplinas e atividades relacionadas não serão descritas em detalhes nesse trabalho, podendo ser tema para um trabalho futuro. Só serão tratadas nesse trabalho as atividades e produtos de trabalho relacionados à disciplina Garantia da Qualidade. Figura 3-10: Diagrama da disciplina Garantia da Qualidade Atividade Realizar Auditoria de Processo A atividade realizar auditoria de processo tem como objetivo realizar auditorias para avaliação do processo e dos produtos de trabalho do projeto e para verificar se os mesmos estão seguindo o que foi definido no processo SCRUM. A entrada obrigatória para essa 50

Avaliação e Melhorias no Processo de Construção de Software

Avaliação e Melhorias no Processo de Construção de Software Avaliação e Melhorias no Processo de Construção de Software Martim Chitto Sisson Centro Tecnológico Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil martim@inf.ufsc.br Abstract. This

Leia mais

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE

VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE 1 VANTAGENS DA APLICAÇÃO DO PROGRAMA DE MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO MPS.BR NOS AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE Elvis Ferreira da Silva* Msc. Marta Alves de Souza** Msc. Helder

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza A visão do modelo MPS.BR para Gerência de Projeto - Nível G por Adriana Silveira de Souza Agenda Visão Geral do MPS.BR Processos e Capacidade de Processo Níveis de Maturidade Atributos de Processo Processo

Leia mais

Introdução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira

Introdução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira Introdução ao MPS.BR Guia Geral Prof. Elias Batista Ferreira IMPORTANTE Este NÃO é um curso oficial do MPS.BR. Este curso NÃO é apoiado pela Softex. Objetivo deste Curso Descrever os processos e resultados

Leia mais

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Qualidade de Software Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Ementa Conceitos sobre Qualidade Qualidade do Produto Qualidade do Processo Garantida da Qualidade X Controle da Qualidade Conceitos

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

Qualidade de Software

Qualidade de Software Unidade I Conceito de Qualidade Luiz Leão luizleao@gmail.com http://www.luizleao.com UNIDADE I : Conceito de Qualidade 1.1 Qualidade de processo de software 1.2 Qualidade de produto de software UNIDADE

Leia mais

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

Leia mais

Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail.

Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail. Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura O Modelo Wesley Torres Galindo wesleygalindo@gmail.com Agenda O que é? Motivação Organização do MPS.BR Estrutura

Leia mais

Processo de Desenvolvimento de Software

Processo de Desenvolvimento de Software Unidade IV Introdução aos Padrões de PDS Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo da Unidade 1. CMM / CMMI 2. SPICE 3. ISO 12207 4. MPS/BR CMM - Capability Maturity Model CMM Capability

Leia mais

MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F:

MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F: MPS.BR A EXPERIÊNCIA E OS BENEFÍCIOS EM IMPLANTAR O MODELO NOS NÍVEIS G E F: um estudo de caso. Rodrigo Pereira Assunção 1 Fabrício Pires Vasconcellos 2 RESUMO: Muitas empresas têm buscado no modelo de

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Prof. Dr. Ivanir Costa. Unidade IV QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade IV QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade IV QUALIDADE DE SOFTWARE introdução As mudanças que estão ocorrendo nos clientes e nos ambientes de negócios altamente competitivos têm motivado as empresas a modificarem

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE MODULO 3 SISTEMA DE GARANTIA DA QUALIDADE CONTEÚDO 3.1 A ABORDAGEM NBR ISO 9000 3.2 MODELOS DE QUALIDADE DE PRODUTO DE SOFTWARE 3.2.1 NBR ISO/IEC 9126 (SOFTWARE) 3.2.2 NBR ISO/IEC

Leia mais

Padrões de Qualidade de Software

Padrões de Qualidade de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software Engenharia de Software I Aula 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de Software) Padrões de Qualidade

Leia mais

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI

Profa. Celia Corigliano. Unidade IV GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Unidade IV GERENCIAMENTO DE PROJETOS DE TI Agenda da disciplina Unidade I Gestão de Projetos Unidade II Ferramentas para Gestão de Projetos Unidade III Gestão de Riscos em TI Unidade

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

Introdução à Qualidade de Software

Introdução à Qualidade de Software FACULDADE DOS GUARARAPES Introdução à Qualidade de Software www.romulocesar.com.br Prof. Rômulo César (romulodandrade@gmail.com) 1/41 Objetivo do Curso Apresentar os conceitos básicos sobre Qualidade de

Leia mais

FACULDADE SENAC GOIÂNIA

FACULDADE SENAC GOIÂNIA FACULDADE SENAC GOIÂNIA NORMA ISO 12.207 Curso: GTI Matéria: Auditoria e Qualidade de Software Professor: Elias Ferreira Acadêmico: Luan Bueno Almeida Goiânia, 2015 CERTIFICAÇÃO PARA O MERCADO BRASILEIRO

Leia mais

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade

Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Definição e Implantação de um Processo de Software para o Núcleo de Práticas de uma Universidade Micaelly P. Soares e Silva, Carla I. M. Bezerra, Camilo C. Almendra, Enyo José T. Gonçalves Universidade

Leia mais

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Rodrigo Araujo Barbalho 1, Marília Paulo Teles 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Faculdade de Computação

Leia mais

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL Porto Alegre, Agosto de 2008. Sumário Apresentação Programa MPS.BR Reutilização no MPS.BR Gerência de reutilização Desenvolvimento para reutilização

Leia mais

CERTIFICAÇÃO BRASILEIRA DE MELHORIA DE PROCESSO DE SOFTWARE: O MPS.BR

CERTIFICAÇÃO BRASILEIRA DE MELHORIA DE PROCESSO DE SOFTWARE: O MPS.BR CERTIFICAÇÃO BRASILEIRA DE MELHORIA DE PROCESSO DE SOFTWARE: O MPS.BR Leonardo Galvão Daun Universidade Estadual de Maringá leonardo.daun@gmail.com Profª Drª Sandra Ferrari Universidade Estadual de Maringá

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Engenharia de Software Qualidade de Software

Engenharia de Software Qualidade de Software Engenharia de Software Qualidade de Software O termo qualidade assumiu diferentes significados, em engenharia de software, tem o significado de está em conformidade com os requisitos explícitos e implícitos

Leia mais

QUALIDADE DE SOFTWARE AULA N.7

QUALIDADE DE SOFTWARE AULA N.7 QUALIDADE DE SOFTWARE AULA N.7 Curso: SISTEMAS DE INFORMAÇÃO Disciplina: Qualidade de Software Profa. : Kátia Lopes Silva 1 CMM: DEFINIÇÃO Capability Maturity Model Um modelo que descreve como as práticas

Leia mais

Padrões de Qualidade de Software e Métricas de Software

Padrões de Qualidade de Software e Métricas de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software e Métricas de Software Engenharia de Software I Aula 3 e 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral MPS.BR - Melhoria de Processo do Software Brasileiro Guia Geral Este guia contém a descrição geral do Modelo MPS e detalha o Modelo de Referência (MR-MPS) e as definições comuns necessárias para seu entendimento

Leia mais

CENTRO UNIVERSITÁRIO UNISEB TRABALHO DE CONCLUSÃO DE CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

CENTRO UNIVERSITÁRIO UNISEB TRABALHO DE CONCLUSÃO DE CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CENTRO UNIVERSITÁRIO UNISEB TRABALHO DE CONCLUSÃO DE CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE EM UMA EQUIPE DE DESENVOLVIMENTO Christian Canalli Orientador Prof.

Leia mais

GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G)

GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G) GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G) LONDRINA - PR 2014 GIOVANI HIPOLITO MARONEZE ESTUDO DE CASO CONTENDO IMPLANTAÇÃO DO MODELO MR-MPS-SV (NÍVEL G)

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software Introdução Qualidade é um dos principais objetivos da Engenharia de Software. Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção com qualidade. Tem-se

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM M P S. B R : M E L H O R I A D E P R O C E S S O D O S O F T W A R E B R A S I L E I R O A

Leia mais

www.asrconsultoria.com.br

www.asrconsultoria.com.br www.asrconsultoria.com.br Garantia da Qualidade de Processo e Produto Direitos de Uso do Material Material desenvolvido pela ASR Consultoria e Assessoria em Qualidade Ltda. É permitido o uso deste material

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte I Agenda Processos CMMI Definição Histórico Objetivos Características Representações

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software André Mesquita Rincon Instituto de Informática/Universidade Federal de Goiás (UFG) Goiânia GO Brasil Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas/Fundação

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria

Agenda. Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Agenda Introdução Etapas genéricas Atividades de apoio Ferramentas de apoio Modelos genéricos Modelos de mercado Modelos de melhoria Introdução Processo de software é o conjunto de ferramentas, métodos

Leia mais

Conceitos Fundamentais de Qualidade de Software

Conceitos Fundamentais de Qualidade de Software Especialização em Gerência de Projetos de Software Conceitos Fundamentais de Qualidade de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Qualidade de Software 2009 Instituto

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR

Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR SCIENTIA PLENA VOL 6, NUM 3 2010 www.scientiaplena.org.br Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR F. G. Silva; S. C. P. Hoentsch, L. Silva Departamento

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

Engenharia de Software Processo de Desenvolvimento de Software

Engenharia de Software Processo de Desenvolvimento de Software Engenharia de Software Processo de Desenvolvimento de Software Prof. Edison A. M. Morais prof@edison.eti.br http://www.edison.eti.br Objetivo (1/1) Conceituar PROCESSO E CICLO DE VIDA, identificar e conceituar

Leia mais

APLICAÇÃO DE BOAS PRÁTICAS DE QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO DE UM PROTÓTIPO DE SISTEMA DE REGISTRO ELETRÔNICO EM SÁUDE ASSISTENCIAL

APLICAÇÃO DE BOAS PRÁTICAS DE QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO DE UM PROTÓTIPO DE SISTEMA DE REGISTRO ELETRÔNICO EM SÁUDE ASSISTENCIAL APLICAÇÃO DE BOAS PRÁTICAS DE QUALIDADE DE SOFTWARE NO DESENVOLVIMENTO DE UM PROTÓTIPO DE SISTEMA DE REGISTRO ELETRÔNICO EM SÁUDE ASSISTENCIAL Cristiane Machado de Vargas 1 Ana Marcia Debiasi Duarte 2

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Conceitos Fundamentais de Qualidade de Software

Conceitos Fundamentais de Qualidade de Software CBCC Bacharelado em Ciência da Computação CBSI Bacharelado em Sistemas de Informação Conceitos Fundamentais de Qualidade de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

Lista de Exercícios - COBIT 5

Lista de Exercícios - COBIT 5 Lista de Exercícios - COBIT 5 1. O COBIT 5 possui: a) 3 volumes, 7 habilitadores, 5 princípios b) 3 volumes, 5 habilitadores, 7 princípios c) 5 volumes, 7 habilitadores, 5 princípios d) 5 volumes, 5 habilitadores,

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Qualidade de Software. Anderson Belgamo

Qualidade de Software. Anderson Belgamo Qualidade de Software Anderson Belgamo Qualidade de Software Software Processo Produto Processo de Software Pessoas com habilidades, treinamento e motivação Processo de Desenvolvimento Ferramentas e Equipamentos

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Melhoria do Processo de Software MPS-BR

Melhoria do Processo de Software MPS-BR Melhoria do Processo de Software MPS-BR Fabrício Sousa Pinto fabbricio7@yahoo.com.br O que é Qualidade? O problema da gestão da qualidade não é que as pessoas não sabem a respeito dela. O problema é que

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012 MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 2: Fundamentação para Implementação do Nível F do MR-MPS-SW:2012 Este guia contém orientações para a implementação do nível

Leia mais

Programa MPS.BR: resultados e perspectivas

Programa MPS.BR: resultados e perspectivas Programa MPS.BR: resultados e perspectivas Ana Regina Rocha Programa de Engenharia de Sistemas e Computação Coordenadora da Equipe Técnica do Modelo MPS Uma Organização com bom desempenho gasta 80% de

Leia mais

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Tiago Domenici Griffo 1, Gothardo Francisco de Magalhães Santos 1, Rodrigo Becke Cabral 1 1

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto,

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto, De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir.

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Introdução à Qualidade de Software. Profº Aldo Rocha

Introdução à Qualidade de Software. Profº Aldo Rocha Introdução à Qualidade de Software Profº Aldo Rocha Agenda O que é Qualidade? O que é Qualidade de Software? Qualidade do Produto e do Processo Normas e Organismos Normativos Qualidade de Software e Processos

Leia mais

Tecnologias Atuais de. Desenvolvimento de Software

Tecnologias Atuais de. Desenvolvimento de Software Tecnologias Atuais de Desenvolvimento de Software volução dos Processos de Desenvolvimento de Software Prof. Luiz Antônio lpereira@uninet.com.br Agenda onceitos volução dos Processos de Software Modelos

Leia mais

Quem Somos CMM/ CMMI. ISO 9000 PNQ ISO 12207 ISO 15504 ITIL Outros modelos. Gestão Sistêmica da. Alinhamento às Diretrizes Organizacionais.

Quem Somos CMM/ CMMI. ISO 9000 PNQ ISO 12207 ISO 15504 ITIL Outros modelos. Gestão Sistêmica da. Alinhamento às Diretrizes Organizacionais. Quem Somos Missão Promover a melhoria e a busca da excelência na gestão organizacional e o aperfeiçoamento contínuo dos processos dos nossos clientes, por meio de modelos e padrões de qualidade adequados

Leia mais

Estudo de caso para implantação do modelo MR-MPS-SV

Estudo de caso para implantação do modelo MR-MPS-SV Estudo de caso para implantação do modelo MR-MPS-SV Giovani Hipolito Maroneze 1, Jacques Duílio Branches 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.001 86.057-970

Leia mais

Uma Arquitetura de Processos para ISO 9001:2000 e SW- CMM Nível 3

Uma Arquitetura de Processos para ISO 9001:2000 e SW- CMM Nível 3 Uma Arquitetura de Processos para ISO 9001:2000 e SW- CMM Nível 3 Carlo Giovano Pires, Fabiana Marinho, Gabriela Telles, Márcia Sampaio Instituto Atlântico, Rua Chico Lemos, 946, 60822-780, Fortaleza -

Leia mais

Sistemas de Informação Empresarial

Sistemas de Informação Empresarial Sistemas de Informação Empresarial Governança de Tecnologia da Informação parte 2 Fonte: Mônica C. Rodrigues Padrões e Gestão de TI ISO,COBIT, ITIL 3 International Organization for Standardization d -

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO 1 AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br Autor: Julio Cesar Fausto 1 RESUMO Em um cenário cada vez mais competitivo e em franca

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Definição do Framework

Definição do Framework Definição do Framework 1. Introdução 1.1. Finalidade Este documento tem por finalidade apresentar o mapeamento dos processos de Definição de Processo Organizacional e Avaliação e Melhoria do Processo dos

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Sumário. Prefácio...14. Capítulo 1 O que é qualidade?...17. Capítulo 2 Normas e organismos normativos...43. Capítulo 3 Métricas: visão geral...

Sumário. Prefácio...14. Capítulo 1 O que é qualidade?...17. Capítulo 2 Normas e organismos normativos...43. Capítulo 3 Métricas: visão geral... Prefácio...14 Capítulo 1 O que é qualidade?...17 1.1 História... 17 1.2 Uma crise de mais de trinta anos...20 1.3 Qualidade e requisitos...25 1.4 Papel da subjetividade...27 1.5 Qualidade e bugs I: insetos

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo

http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais MPS.BR Rogério Araújo Questões O futuro pertence àqueles que acreditam

Leia mais

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1

Introdução Fatores de Qualidade Garantia de Qualidade Rivisões de Software Conclusão. Qualidade. Plácido A. S. Neto 1 Qualidade Plácido A. S. Neto 1 1 Gerência Educacional de Tecnologia da Informação Centro Federal de Educação Tecnologia do Rio Grande do Norte 2006.1 - Planejamento e Gerência de Projetos Agenda Introdução

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI INTRODUÇÃO Aumento da Importância do Software Software está em tudo: Elemento crítico

Leia mais

UTILIZAÇÃO DE METODOLOGIA SCRUM PARA OBTENÇÃO DE NÍVEL F DO MPS.BR

UTILIZAÇÃO DE METODOLOGIA SCRUM PARA OBTENÇÃO DE NÍVEL F DO MPS.BR UTILIZAÇÃO DE METODOLOGIA SCRUM PARA OBTENÇÃO DE NÍVEL F DO MPS.BR 1 Arthur Mauricio da Silva, 1 Maria Aparecida Denardi 1Curso de Sistemas de Informação - UNIPAR - Universidade Paranaense. CEP 85801-180

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

MPS.BR Melhoria de Processo do Software Brasileiro

MPS.BR Melhoria de Processo do Software Brasileiro Melhoria de Processo do Software Brasileiro (MPS.BR) SUMÁRIO 1. Introdução 2. Implantação do Programa MPS.BR: 2004 2007 3. Consolidação do Programa MPS.BR: 20082010 4. Conclusão Kival Weber Coordenador

Leia mais

Melhoria de Processos de Software com o MPS.BR

Melhoria de Processos de Software com o MPS.BR Melhoria de Processos de Software com o MPS.BR Prof. Dr. Marcos Kalinowski (UFF) kalinowski@acm.org Agenda do Curso Motivação para processos de software Visão geral do programa MPS.BR e do modelo MPS-SW

Leia mais

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br Qualidade de Software Aula 6 / 2010 Prof. Dr. Luís Fernando Garcia luis@garcia.pro.br www.garcia.pro.br Introdução As três dimensões críticas Introdução Começando MAL CMMI Impeditivos CMMI Desculpas CMMI

Leia mais

Capability Maturity Model Integration - CMMI

Capability Maturity Model Integration - CMMI Capability Maturity Model Integration - CMMI Para Desenvolvimento Versão 1.2 M.Sc. Roberto Couto Lima ÍNDICE 1. Definição ------------------------------------------------------------------------------------------------------------

Leia mais

CLEVERSONTPP@GMAIL.COM

CLEVERSONTPP@GMAIL.COM UM BREVE DESCRITIVO DO MODELO MPS-BR (MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO) E SUAS PERSPECTIVAS PARA O FUTURO CLÉVERSON TRAJANO PRÉCOMA PORTES PÓS-GRADUAÇÃO EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO

Leia mais

Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas?

Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas? Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas? Fábio Martinho. obtido [on-line] na URL http://www.testexpert.com.br/?q=node/669, em 11/03/2008. Segundo a NBR

Leia mais

Qualidade de software com MPS.BR nos níveis de maturidade G e F

Qualidade de software com MPS.BR nos níveis de maturidade G e F Qualidade de software com MPS.BR nos níveis de maturidade G e F Marcelo Augusto Resende Cunha Graduado em Sistemas de Informação pela Libertas Faculdades Integradas Alysson Alexander Naves Silva Mestre

Leia mais

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste

MPS.BR - Melhoria de Processo do Software Brasileiro. Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste MPS.BR - Melhoria de Processo do Software Brasileiro Guia de Implementação Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste Este guia contém orientações para a implementação do

Leia mais

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software CCE 876 - Engenharia de Software Introdução à Engenharia de Software Objetivos Introduzir a Engenharia de Software e explicar sua importância. Introduzir os conceitos principais relacionados à Engenharia

Leia mais