Extreme Programming e Qualidade de Software

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

Download "Extreme Programming e Qualidade de Software"

Transcrição

1 Extreme Programming e Qualidade de Software Antonio Sergio Ferreira Bonato Departamento de Sistemas Digitais Escola Politécnica Universidade de São Paulo Resumo Nos últimos anos tem surgido uma nova gama de metodologias de desenvolvimento de software conhecidas como metodologias ágeis. Consideradas por alguns como um antídoto ao excesso de burocracia e uma solução para os problemas das pequenas equipes e por outros como coisa de hackers, estas metodologias vem se firmando e atraindo cada vez mais atenção sobre si. Dentre estas metodologias, a que mais tem se destacado é a Extreme Programming, gerando um grande número de publicações, congressos e aficionados. E um bom número de detratores também. Entretanto, estas metodologias são capazes de produzir software confiável e de qualidade? O intuito deste trabalho é fazer um pequeno estudo neste sentido, analisando a Extreme Programming sob a ótica de uma interpretação não rigorosa do SW-CMM, o Capability Maturity Model para Software, verificando em que pontos ela é aderente ao modelo e em quais pontos ela é não conforme. Por que o SW-CMM? Bem, o modelo SW-CMM é amplamente aceito pela comunidade mundial de Engenharia de Software como um padrão a ser seguido para se produzir software confiável e de qualidade. O trabalho está estruturado de modo a, no início, falar sobre aspectos gerais que caracterizam as metodologias ágeis. Depois, fala sobre os conceitos da Extreme Programming. No final é feita uma breve explicação do SW-CMM e é descrito como cada uma das áreas de processo é ou não atendida pela Extreme Programming. Keywords: Processo, metodologias, desenvolvimento de software, metodologias ágeis, Extreme Programming, qualidade de software, CMM. Introdução O desenvolvimento de software tem se mostrado como uma das atividades mais desafiadoras da humanidade. Apesar de estar envolvida nesta empreitada a quase 50 anos, ainda parece praticamente impossível concluir um projeto de desenvolvimento de software dentro do prazo, do orçamento, com todas os requisitos satisfeitos e alta qualidade. A atividade de desenvolvimento de software é caótica, normalmente caracterizada pela expressão "code & fix", i.e., codifica e conserta. Isto geralmente funciona bem em projetos muito pequenos, mas à medida que as coisas crescem, os problemas começam a aparecer. Como é caracterizada por longas fases de debugging (remoção de erros) após a implementação de cada funcionalidade, difíceis de determinar o quanto duram, via de regra o cronograma não é cumprido. Nos primórdios do software as coisas funcionavam deste jeito (e ainda funcionam assim em muitos lugares quando se trata de pequenas equipes). Com o passar do tempo, entretanto, foram surgindo metodologias com o intuito de tornar o desenvolvimento de software uma atividade mais disciplinada, eficiente e previsível. Só que muitas vezes estas metodologias são acusadas de burocráticas, pois exigem uma grande quantidade de Extreme Programming Brasil - São Paulo - dezembro de

2 Extreme Programming, Qualidade e Confiabilidade de Software documentos. Além disso, é constante a reclamação de que o uso da metodologia por si só atrasa o projeto, tamanho o número de tarefas "improdutivas" realizado. Por tudo isso, estas metodologias são chamadas de pesadas (heavyweight methodologies). As metodologias pesadas se mostraram adequadas aos grandes projetos tocados por grandes equipes, onde há farta disponibilidade de recursos materiais e humanos que torna possível tanto a existência do sem número de papéis exigidos por estes processos bem como a produção da elevada quantidade de documentação demandada. Entretanto, o tamanho destes projetos os torna naturalmente complexos, principalmente nas tarefas de coordenação dos mais variados grupos, justificando o uso destas metodologias. Já os pequenos projetos, tocados por pequenas organizações, não precisam de todo este rigor e formalismo, podendo ser encarados de maneira muito mais simples. Para estes projetos, as metodologias pesadas não são adequadas, pois não há como encolhê-las para se ajustarem ao tamanho do projeto e da organização, que na maioria das vezes não tem como arcar com os recursos necessários para suportar o emprego destas metodologias. É justamente nestes casos que o uso de uma metodologia é pior do que o uso de nenhuma. Como reação à tudo isso apareceram, nos últimos anos, algumas metodologias denominadas metodologias ágeis. Tais metodologias se colocam como um meiotermo entre a ausência de processo e o processo exagerado. Exigindo pouca documentação, às vezes até colocando o código fonte como documentação, elas diferem das metodologias pesadas em dois aspectos básicos: são adaptativas ao invés de preditivas; são orientadas às pessoas, e não orientadas aos processos. Existem várias metodologias que podem ser carimbadas com o estereótipo de ágeis. Todas elas tem em comum o fato de acomodarem bem as mudanças de requisitos e de serem processos fáceis de serem aceitos pelo pessoal de desenvolvimento. Apesar destas semelhanças, todas elas tem diferenças na maneira como conduzem o ciclo de vida de desenvolvimento. Dentre as metodologias ágeis, a que mais tem se destacado é a Extreme Programming, talvez por sua fundamentação teórica e sua estruturação como disciplina, talvez pelo grande senso de marketing de seu principal criador, Kent Beck [1]. Entretanto, mesmo sendo as metodologias ágeis mais adequadas para os pequenos projetos, ainda resta às pequenas organizações o desafio da qualidade. Como usar um modelo de qualidade de processo como o SW- CMM sem perder agilidade. Isso é possível desde que se faça uma interpretação do modelo com bom senso [6]. Desta forma, o uso das metodologias ágeis propicia às pequenas organizações um modo de desenvolver software com agilidade e qualidade. Pequenas Empresas e Pequenos Projetos As pequenas empresas são parte importante da economia do país. A grande maioria das organizações que desenvolvem software no Brasil, segundo levantamento realizado pelo núcleo SOFTEX, que se destina a promover a excelência do software brasileiro, é composta por pequenas organizações [7]. De um universo de 699 empresas pesquisadas, 36% tem o porte de micro organizações, com um número de funcionários variando entre 1 e % das organizações estão na categoria de pequenas, com 10 a 49 funcionários. Portanto, de acordo com o critério força de trabalho, 78% das empresas podem ser consideradas como pequenas organizações. Ainda relatando a mesma pesquisa, 88,8% das 699 empresas são desenvolvedoras de software e a maioria software orientado a negócios, sendo relatados aplicativos como administração de serviços (31,3%), automação comercial (30,0%), página web (29,4%), e- business (26,5%), contabilidade (18,0%), dentre outros. Estas informações corroboram o fato de que no Brasil a maior parte do software desenvolvido é orientado a negócios. Geralmente, as pequenas organizações desenvolvem pequenos projetos. Estes, com relação ao seu tamanho, podem ser classificados como [6]: pequenos, quando envolvem de 3 a 5 pessoas e tem duração de até 6 meses; muito pequenos, quando envolvem de 2 a 3 pessoas e tem duração de até 4 meses; minúsculos, quando envolvem de 1 a 2 pessoas e tem duração de até 2 meses; individual, quanto apenas uma pessoa trabalha no projeto por uma semana. Ainda assim, apesar de pequenos, estes projetos falham. Pode-se citar o CHAOS Report do ano 2000, que relata que neste ano apenas 28% dos projetos de dsenvolvimento de software nos Estados Unidos obtiveram sucesso, 23% falharam totalmente e os 49% restantes terminaram fora do prazo, do orçamento e com menos funcionalidades do que o requisitado no início do projeto [8]. Nota-se aqui que a falta de maturidade e 2

3 capacidade no desenvolvimento de software ainda é grande nos Estados Unidos. Infelizmente não existem informações deste tipo relacionadas à organizações brasileiras, mas pode-se inferir que o resultado seria o mesmo ou até pior. O que é Extreme Programming? Extreme Programming, ou XP, é uma metodologia leve para equipes de tamanho pequeno e médio desenvolverem software face a requisitos vagos ou que mudem muito rapidamente. Criada em 1996 por Kent Beck, Ron Jeffries e Ward Cuningham a partir de um projeto piloto realizado na Daymler-Crysler, a XP vem ganhando cada vez mais espaço no mercado. Porque extreme? Porque a XP pega um conjunto de práticas de desenvolvimento que estão por aí já faz um longo tempo, conhecidas como best practices, e as leva ao extremo [2]. Por exemplo, se revisão por pares é bom, então vamos fazê-la o tempo todo, implantando a programação aos pares; se projeto é bom, vamos fazer dele nosso dia a dia, com a remodelagem de código; se testar é bom, vamos fazê-lo o tempo todo, e assim por diante. XP é uma maneira ágil, eficiente, de baixo risco, flexível, previsível, científica e até divertida de desenvolver software. Ela se distingue das outras metodologias por seu precoce, concreto e contínuo feedback fornecido pelos ciclos curtos; sua abordagem de planejamento incremental, que rapidamente cria um plano que evolue durante o ciclo de vida do projeto; sua habilidade em tornar flexível a implementação de funcionalidades, respondendo às necessidades de mudança dos negócios; sua dependência dos testes automatizados escritos pelos programadores e clientes para monitorar o progresso do desenvolvimento e encontrar defeitos precocemente; sua dependência da comunicação oral, nos testes e no código fonte para comunicar o intento e a estrutura do sistema; sua dependência do processo de projeto evolutivo que dura enquanto o projeto dura; sua dependência na colaboração estreita entre programadores com habilidades comuns; sua dependência em práticas que funcionam tanto com os instintos de curto prazo dos programadores como com os interesses de longo prazo do projeto. XP é também uma maneira disciplinada de desenvolvimento de software. É disciplinada porque existem determinadas práticas que devem ser executadas para que se pratique a XP. Estas práticas, ou 12 práticas, estão fundamentadas em uma história, quatro valores, alguns princípios e em quatro atividades básicas. Vejamos cada um deles. Os quatros valores fundamentais da XP Comunicação: problemas em projetos normalmente são traduzidos por um "alguém que não falou alguma coisa importante para alguém". A XP torna praticamente impossível a falta de comunicação. Simplicidade: sempre faça a coisa mais simples que possa funcionar. XP é uma aposta de que é sempre mais barato fazer algo simples e mudar depois do que tentar prever o futuro fazer algo complicado que ninguém vai acabar usando. Feedback: retorno concreto dos clientes e dos usuários o mais cedo possível mantém o projeto nos trilhos. Coragem: é preciso coragem para manter os três primeiros valores sempre. Princípios Básicos Os princípios fundamentais são: Feedback rápido: quanto mais demorado o feedback menor o aprendizado produzido por ele. Simplicidade assumida: tratar cada problema como se pudesse ser resolvido de maneira simples; não tentar prever o futuro, resolvendo hoje os problemas de hoje, e deixando para amanhã os de amanhã. Mudança incremental: grandes mudanças tendem a não funcionar; os problemas são normalmente resolvidos com uma série de pequenas mudanças naquilo que faz diferença. Aceitar mudanças: a melhor estratégia é aquela que preserva a maioria das opções enquanto verdadeiramente resolve o problema que estiver pressionando mais; Trabalho de qualidade: todos gostam de fazer um trabalho de qualidade; se as pessoas que estão no Extreme Programming Brasil - São Paulo - dezembro de

4 Extreme Programming, Qualidade e Confiabilidade de Software projeto não gostam da qualidade do trabalho que estão fazendo, a tendência do projeto é fracassar. Além destes princípios fundamentais, existem outros que também são importantes: Ensinar a aprender: melhor do que um monte de frases doutrinárias, tais como "Você deve testar como XYZ...", devemos focar em ensinar estratégias de se aprender quanto teste deve ser feito; isto também vale para a remodelagem de código, projeto, planejamento, etc. Pequeno investimento inicial: muito dinheiro logo no início do projeto não faz bem; a melhor abordagem é ter dinheiro o suficiente para começar e ir incrementando o orçamento conforme o retorno do investimento que vai sendo dado para o cliente. Jogar para ganhar: deve-se sempre jogar para ganhar, e não jogar para não perder. Experiências concretas: antes de tomar decisões deve-se experimentar algumas alternativas. Comunicação honesta e aberta: falta de comunicação dentro da equipe prejudica o ambiente de trabalho e o projeto como um todo. Trabalhar de acordo com o instinto das pessoas, e não contra eles. Responsabilidade aceita: responsabilidade não deve ser imposta às pessoas, mas aceita por elas. Adaptação local: os costumes e práticas de desenvolvimento locais devem ser respeitados ao máximo quando da implantação da XP. Viagem leve: não carregue documentação que não seja essencial para o projeto; jogue fora aquilo que não precisa mais; o código fonte é uma das melhores formas de documentação. Medição honesta: medir sempre o desenvolvimento, mas nunca numa maneira que não seja suportada pelos instrumentos disponíveis. Atividades Básicas A XP considera que o desenvolvimento de software está dividido em apenas quatro atividades básicas: Codificação: no final do dia, sempre tem que haver código; quer seja desenhando diagramas que gerem código ou digitando programas, a atividade principal do desenvolvimento é a codificação; o código permite que os testes sejam feitos, dando rapidamente o feedback necessário de que o que está sendo feito está correto e de acordo com os requisitos do cliente. Testes: são a maneira mais rápida e segura de se obter feedback e aumentar a confiança da equipe e do cliente; nenhuma funcionalidade que não possa ser demonstrada por intermédio de testes realmente existe. Audição: os programadores normalmente não sabem nada da área de negócios; o pessoal de negócios dificilmente sabe alguma coisa de desenvolvimento de software; ambas as partes devem ouvir sempre umas as outras para que o projeto sempre ande na direção correta. Projeto: não se pode apenas ouvir, escrever casos de testes e codificar o tempo todo; é necessário antes se projetar o que vai ser feito; o projeto deve sempre ser simples, e deve ser melhorado sempre que possível. As doze práticas da XP As doze práticas da XP que a definem como uma disciplina são fundamentadas nos quatro valores, nos princípios básicos e nas quatro atividades básicas [3]. O Jogo do Planejamento Ninguém sabe tudo logo no começo. Tanto clientes como desenvolvedores aprendem durante o progresso do projeto. A XP reconhece isso e coloca isso em prática através do jogo do planejamento. A principal idéia por trás deste prática é fazer um plano aproximado no princípio e refiná-lo conforme as coisas vão se tornando mais claras. Os artefatos do jogo do planejamento são uma pilha de cartões, contendo histórias do cliente, que irão orientar as iterações do projeto; e um plano aproximado do próximo release. O fator crítico do trabalho de planejamento é deixar os clientes tomarem as decisões de negócios, enquanto o pessoal do desenvolvimento toma as decisões técnicas. Ao pessoal do desenvolvimento cabe: estimar quanto tempo vai demorar para desenvolver uma história; implicações de custo no uso de várias opções tecnológicas; a organização da equipe; o risco de cada história; 4

5 a ordem do desenvolvimento de cada história dentro de cada iteração. Os clientes tomam as decisões de negócio: escopo (as histórias para um release e as histórias de cada iteração); datas dos releases; prioridades (quais as funcionalidades devem ser desenvolvidas antes, baseados em valor para o negócio). O planejamento ocorre com freqüência. Isto fornece uma oportunidade para que clientes e desenvolvedores façam ajustes a medida em que aprendem coisas novas. Programação por pares Em XP, pares de programadores usando apenas um computador escrevem todo o código fonte. Esta abordagem pode soar ineficiente, uma vez que se utiliza dois recursos para produzir a mesma coisa, mas na verdade ela traz uma série de benefícios, econômicos e outros, tais como: todas as decisões de projeto envolvem pelo menos dois cérebros; pelo menos duas pessoas estão familiarizadas com cada parte do sistema; há menos chance de ambas as pessoas negligenciarem tarefas, tais como testes e remodelagem de código; a mudança de pares difunde o conhecimento pela equipe; o código é sempre revisado por pelo menos duas pessoas. Há dois papéis em cada par. Um dos parceiros, o que detém o teclado e o mouse, pensa na melhor maneira de se implementar um determinado método. O outro parceiro deve pensar mais estrategicamente, como por exemplo, se a abordagem como um todo vai funcionar, se existem ainda casos de teste que não foram testados, se há um modo de fazer aquilo de maneira mais simples, etc. Testes Em XP há dois tipos de testes: testes de unidade; testes de aceitação. Os desenvolvedores escrevem os testes de unidade enquanto escrevem o código. O cliente escreve os testes de aceitação após definir as histórias. Os testes de unidade dizem aos desenvolvedores quando o sistema funciona em qualquer ponto do tempo. Os testes de aceitação dizem à equipe quando o sistema faz o que os usuários desejam que ele faça. Os desenvolvedores escrevem testes de unidade para cada método que possa falhar, antes mesmo de escrever o código para tais métodos. Então eles escrevem somente código o suficiente para passar nos testes. Trabalhar desta forma parece estranho, mas esta abordagem proporciona: mais completo conjunto de testes possível; código mais simples que possa funcionar; uma visão clara da intenção do código. Um desenvolvedor não pode integrar o código ao repositório de código fonte enquanto ele não passar em todos os testes de unidade. Os testes de unidade dão aos desenvolvedores confiança de que o código deles funciona. Eles também dão ao desenvolvedor coragem para fazer a remodelagem do código fonte, porque uma falha no teste diz ao desenvolvedor imediatamente se alguma coisa foi danificada. Os testes de unidade devem ser automatizados e dar um resultado claro do tipo passa/não passa. Os clientes são responsáveis por garantir que cada história tenha um teste de aceitação para validá-la. O cliente pode escrever os testes por si só, recrutar algum membro da organização para fazer isso por ele ou combinar as duas abordagens. Os testes dizem aos clientes se o sistema tem todas as funcionalidades que deveriam ter e se elas funcionam corretamente. Idealmente, o cliente deve ter os testes de aceitação de todas as histórias a serem implementadas em uma interação escritos antes da interação estar terminada. Os testes de aceitação devem ser automatizados e devem ser executados freqüentemente para garantir que os desenvolvedores não estejam estragando nenhuma funcionalidade já implementada enquanto eles implementam uma nova. Nem todos os testes de aceitação tem que passar todo o tempo. Eles ajudam o cliente a medir o quanto do projeto já está pronto. Eles também permitem aos clientes tomar decisões informadas sobre o que está ou não pronto em um determinado release. Remodelagem A remodelagem (refactoring) é uma técnica que permite a melhoria do código sem a mudança de funcionalidade. Uma equipe de XP deve fazer a remodelagem sem perdão. Existem duas oportunidades chave para os Extreme Programming Brasil - São Paulo - dezembro de

6 Extreme Programming, Qualidade e Confiabilidade de Software desenvolvedores melhorarem o código: antes e depois de implementar uma funcionalidade. Antes, os desenvolvedores tentam determinar se a mudança no código existente tornaria a implementação da nova funcionalidade mais fácil. Depois, eles olham para o código que acabaram de escrever para ver se há uma maneira de simplificá-lo. por exemplo, se eles vêem uma oportunidade para abstração, eles fazem a remodelagem para remover todo o código duplicado das implementações concretas. A XP diz que se deve escrever o código mais simples que possa funcionar, mas também diz que se aprende coisa pelo caminho. A remodelagem permite que se incorpore o aprendizado ao código sem danificar os testes. Ele mantém o código limpo. Isto significa que o código irá sobreviver por mais tempo, introduzir menos problemas para os futuros desenvolvedores e guiá-los na direção correta. Projeto simples As metodologias pesadas dizem que até o mais simples projeto (design) deve ser feito logo no começo. XP diz que o projeto não deve ser feito todo de uma vez, no início, na ilusão de que nada vai mudar depois. A XP considera o projeto tão importante que ele deve ser uma preocupação constante. Deve-se sempre tentar usar o projeto mais simples que possa funcionar em um determinado ponto, mudando-o quando ele não mais refletir a realidade. E o que é o projeto mais simples que possa funcionar? É aquele que: passa em todos os testes; não contém código em duplicidade; demonstra claramente as intenções do programador; contém o menor número possível de classes e métodos. Um projeto simples não implica em que todos os projetos sejam pequenos ou triviais. Eles apenas devem ser o mais simples possível e ainda assim funcionarem. Nunca inclua funcionalidades extras que não serão utilizadas. Propriededade Coletiva do Código Qualquer pessoa da equipe deve ter a autoridade para mudar o código a fim de melhorá-lo. Todos possuem o código, de modo que todos são responsáveis por ele. Esta técnica permite às pessoas fazerem as mudanças necessárias em uma peça de código sem caírem no gargalo da propriedade individual do código. O fato de todos serem responsáveis pelo código evita o caos da falta de propriedade do código. Dizer que todos possuem o código não é o mesmo que dizer que ninguém possui o código. Quando ninguém possui o código as pessoas podem causar danos onde bem entenderem e alegarem não ter nenhuma responsabilidade. A XP diz, "Você estraga, você conserta". Existem testes de unidade que devem ser executados antes e depois de cada integração. Se você danifica alguma coisa que estava funcionando, é sua responsabilidade consertá-la, não importa em que lugar do código ela esteja. Isto requer extrema disciplina. Integração Contínua A integração freqüente do código ajuda a evitar o pesadelo da integração. As equipes de XP integram seu código várias vezes ao dia, após terem todos os testes de unidade executados sem problemas. Abordagens tradicionais tendem a trabalhar deste modo: codificam um monte, fazem uma grande integração e depois gastam uma grande quantidade de tempo consertando os problemas. Este estilo realmente atrasa o projeto. Grandes integrações criam uma grande carga de problemas todos de uma vez, e estes problemas podem ter centenas de causas possíveis. Quando a integração é freqüente, a causa das falhas de uma integração em particular é mais óbvia: os testes funcionavam antes, então o que se acabou de integrar é o culpado. Deste modo, quando se encontram problemas, há um conjunto limitado de causas. Consertar é mais fácil, leva menos tempo e mantém a equipe trabalhando em velocidade máxima. Cliente no local Para funcionar de maneira ótima, uma equipe de XP precisa ter um cliente disponível no local para clarear algumas histórias e tomar decisões críticas de negócio. Os desenvolvedores não podem fazer isso sozinhos. Ter um cliente disponível elimina gargalos que possam aparecer quando os desenvolvedores tem que esperar por decisões dos clientes. A XP não finge que um cartão de história seja todo o direcionamento que um desenvolvedor necessite para entregar o código necessário. A história é um compromisso para uma posterior conversa entre o cliente e o desenvolvedor para descrever os detalhes. A idéia é que a comunicação face a face minimize a chance de maus entendidos, o que não ocorre quando se escreve todos os requisitos em um documento estático. Apesar de ter o cliente o local o tempo todo ser a melhor situação possível, este não é o único cenário que funciona. O mínimo necessário é que o cliente esteja 6

7 disponível sempre que necessário para responder à questões e para fornecer direcionamento paro o time baseado em valor para o negócio. Se isto puder acontecer sem a necessidade do cliente estar o tempo todo no local, ótimo. A presença física com a equipe torna as coisas mais fáceis, embora seja apenas uma recomendação. Pequenas versões As versões (releases) devem ser tão pequenas quanto possível e mesmo assim ter valor o suficiente para o negócio de modo que valham à pena. Libere o sistema tão logo ele tenha algum sentido. Isto fornece valor para o cliente tão cedo quanto possível. Pequenas versões também fornecem um feedback concreto para os desenvolvedores sobre quais as expectativas dos clientes foram atendidas e quais não foram. A equipe então pode incluir estas lições no planejamento do próxima versão. Semana de 40 horas Os desenvolvedores devem estar renovados e ansiosos a cada manhã, cansados e satisfeitos toda noite. As 40 horas por semana levam a isso. O número exato de horas não é importante - o princípio sim. Queimar óleo por longos períodos mata a performance. Desenvolvedores cansados cometem mais erros, o que diminui a velocidade do projeto no longo prazo mais do que um horário de trabalho normal o faria. Mesmo que os desenvolvedores possam funcionar bem por longos períodos não significa que devam. Eventualmente eles ficam cansados e deixam seus empregos, ou começam a ter problemas pessoais que acabam tendo impacto negativo em sua performance. Horas extras não são resposta a um problema no projeto. De fato, são um sintoma de um problema maior. Padrões de codificação Ter padrões de codificação faz duas coisas: evita que a equipe se distraia com discussões estúpidas sobre coisas que não importam tanto quanto trabalhar em velocidade máxima; suporta as outras práticas. Sem padrões de codificação é mais difícil melhorar o código, mais difícil trocar os pares de programadores e mais difícil ir rápido. O objetivo é que ninguém na equipe possa reconhecer quem escreveu determinada parte do código. Cria-se um padrão que todos concordem, e então se adota o padrão. Este não deve conter uma lista extensa de regras, mas apenas linha gerais que garantam que o código se comunique claramente. O padrão de codificação deve começar simples e evoluir baseado na experiência da equipe. Não se deve gastar muito tempo com isso no princípio. Criase o padrão mais simples que possa funcionar, e então se coloca em prática. Metáfora O que uma arquitetura faz? Ela fornece uma figura dos vários componentes de um sistema e como eles interagem - um tipo de mapa que permite aos desenvolvedores ver onde novas peças irão se encaixar. A metáfora do sistema em XP é análoga ao que a maioria das metodologias chama de arquitetura. A metáfora dá à equipe uma foto consistente que ela possa usar para descrever o modo como o sistema existente trabalha, onde as novas partes irão se encaixar e qual forma elas devem ter. É importante lembrar que todos entenderem como o sistema funciona como um todo é crítico e fundamental para o sucesso do projeto. Como as práticas funcionam juntas O todo é maior do que a soma das partes. Pode-se implementar práticas simples, ou um pequeno conjunto delas, e ainda assim obter grandes benefícios. Mas só se consegue o máximo de benefícios quando se implementa todas as práticas, pois o poder delas vem da sua interação. Deve-se aplicar a XP ao integralmente no começo. Uma vez que se entende como as práticas interagem, tem-se o conhecimento necessário para adaptar a XP a um contexto em particular. É importante lembrar que a XP não é um objetivo, e sim um meio. O objetivo, sim, é desenvolver software de qualidade rapidamente. Ciclo de Vida de um Projeto de XP O ciclo de vida de um projeto de XP consiste em por as práticas e estratégias da XP em funcionamento de maneira ordenada. Ele consiste de um pequena fase inicial de desenvolvimento seguida por um longo período de refinamento e suporte à produção. O ciclo de vida pode ser divido nas seguintes fases: Exploração: preparar ambiente de produção, praticar a escrita de histórias de usuário, estimar e testar tecnologias e tarefas de programação; desta fase sai a metáfora. Planejamento: por em prática o Jogo do Planejamento; obter o menor número de histórias a ser implementado no versão curta. Extreme Programming Brasil - São Paulo - dezembro de

8 Extreme Programming, Qualidade e Confiabilidade de Software Iterações: planejar cada iteração, fazer o desenho mais simples, criar os casos de teste de unidade, programar aos pares, testar continuamente, integrar diariamente, remodelar sem perdão, fazer os testes de aceitação, implementar as histórias da versão. Produção: em iterações de uma semana, colocar o sistema em produção; implementar novos testes e ajustar a performance do sistema. Manutenção: simultaneamente produzir novas funcionalidades e manter o sistema existente rodando, remodelar se necessário ou migrar para uma nova tecnologia; experimentar novas arquiteturas. Morte: o usuário não consegue pensar em novas histórias; preparar documentação do sistema e encerrar o projeto. O Software CMM O Capability Maturity Model for Software é um modelo organizacional para construção de software que tem sido amplamente adotado na comunidade de software e além dela. O CMM-SW é um modelo em cinco níveis que descreve boas práticas de engenharia e gerenciamento e prescreve prioridades de melhoria para organizações de software [5]. O modelo possui cinco níveis, sumariados a seguir: nível 1 - inicial: nenhum processo; nível 2 - repetível: foco em gerenciamento de projeto; nível 3 - definido: foco em processos de engenharia e no suporte organizacional; nível 4 - gerenciado: foco na qualidade dos processos e do produto; nível 5 - otimizando: foco na melhoria contínua do processo. Cada um dos níveis do CMM (exceto o nível 1) possui um certo número de KPAs, ou áreas chave de processo. Cada KPA permite alcança um certo conjunto de metas ou objetivos. A satisfação a estes objetivos permite dizer se uma organização atingiu um determinado nível de maturidade. As KPAs do nível 2 são: RM - Requirements Management (Gerência de Requisitos), SPP - Software Project Planning (Planejamento de Projeto de Software), SPTO - Software Project Tracking & Oversight (Acompanhamento e Supervisão de Projeto de Software), SSM - Software Subcontract Management (Gerência de Subcontratação de Software, SQA - Software Quality Assurance (Garantia de Qualidade de Software), SCM - Software Configuration Management (Gerência de Configuração de Software). As do nível 3: OPF - Organization Process Focus (Foco no Processo Organizacional), OPD - Organization Process Definition (Definição do Processo Organizacional), TP - Training Program (Programa de Treinamento), ISM - Integrated Software Management (Gerência Integrada de Software), SPE - Software Product Engineering (Engenharia de Produto de Software), IC - Intergroup Coordination (Coordenação entre Grupos), PR - Peer Reviews (Revisões por Pares). As do nível 4: QPM - Quantitative Process Management (Gerência de Processo Quantitativa), SQM - Software Quality Management (Gerência de Qualidade de Software), E, finalmente, as do nível 5: DP - Defect Prevention (Prevenção de Defeitos), TCM - Technology Change Management (Gerência de Mudança Tecnológica), PCM - Process Change Management (Gerência de Mudança de Processo). O CMM é focado nas grandes organizações que desenvolvem software em grandes projetos para o governo. Apesar disso, ele é escrito de uma maneira hierárquica que contém "verdades universais" sobre a engenharia de software e a gerência de projetos. Quando visando apenas a melhoria do processo de desenvolvimento, se interpretado de maneira correta e com bom senso, o CMM pode ser usado por praticamente todas as organizações, independentemente de seu tamanho [6]. 8

9 O Software CMM tem a intenção de ser: um aplicação de bom senso de processos de gerenciamento e conceitos de melhoria de qualidade ao desenvolvimento e manutenção de software; um guia desenvolvido pela comunidade, pois as informações fornecidas por centenas de profissionais de software foram levadas em conta na confecção do modelo; um modelo para melhoria organizacional, que implica em uma série de prioridades que podem diferir das de um projeto específico, mas que se provaram efetivas na transformação de uma organização; uma estrutura para métodos de avaliação baseados no CMM confiável e consistente. Embora o CMM seja descrito em um livro com mais de 500 páginas, os requisitos para uma organização estar no nível 5 podem ser concisamente colocados em 52 sentenças: os objetivos das 18 áreas de processo. As práticas, sub-práticas e exemplos que também são descritos no modelo servem apenas como material informativo para guiar os profissionais de software que estejam adotando o CMM. RM - Requirements Management O objetivo da KPA RM é estabelecer mecanismos para que o produto de software reflita e expectativa do cliente. Objetivo 1: Os requisitos de software são controlados para estabelecer uma baseline que será usada como base tanto para o desenvolvimento quanto para atividades de gerência. Objetivo 2: Os planos de desenvolvimento, os produtos e todas as atividades são mantidos em consistência com os requisitos de software. Documentar os requisitos e os compromissos assumidos, mesmo que seja em apenas uma folha de papel. SPP - Software Project Planning O objetivo desta KPA é estabelecer planos efetivos para servirem como base para as atividades de desenvolvimento de software e gerência. Objetivo 1: As estimativas de software são documentadas para uso no planejamento e acompanhamento do projeto. Objetivo 2: O projeto de software tem as suas atividades e compromissos associados planejados e documentados. Objetivo 3: Os grupos e indivíduos que tenham alguma relação com o desenvolvimento do software conhecem os compromissos assumidos e concordam com eles. Fazer um plano básico que contenha as principais atividades a serem realizadas, bem como os produtos gerados por cada uma delas. Revisar o plano conforme o projeto estiver em andamento. Estabelecer pontos de verificação. SPTO - Software Project Tracking & Oversight O objetivo da KPA SPTO é permitir a visibilidade e acompanhamento do andamento do projeto para que a gerência, nos seus vários níveis, possa tomar as ações apropriadas quando o projeto desviar de maneira significativa do que foi planejado. Objetivo 1: É feito um acompanhamento do realizado com relação ao que foi planejado. Objetivo 2: Quando o andamento do projeto desvia de maneira significativa do que foi planejado ações corretivas são executadas e gerenciadas até a sua conclusão efetiva. Objetivo 3: Eventuais mudanças de compromissos de quaisquer natureza são negociadas e concordadas por todos os grupos afetados. Comparar o que foi feito com o que foi planejado. Atualizar o plano de maneira simples. As tarefas devem ser pacotes binários: ou terminadas ou não terminadas. Uma tarefa 87% pronta é sinal de chute. Se o projeto estiver saindo da linha, parar e replanejar. SSM - Software Subcontract Management O objetivo do SSM é a seleção de subcontratados para o desenvolvimento e sua gerência de maneira Extreme Programming Brasil - São Paulo - dezembro de

10 Extreme Programming, Qualidade e Confiabilidade de Software efetiva. Objetivo 1: O contratante seleciona subcontratados qualificados. Objetivo 2: O contratante e o subcontratado concordam quanto aos compromissos assumidos mutuamente. Objetivo 3: O contratante e o subcontratado mantém comunicação permanente. Pequenas organizações geralmente não subcontratam. Se subcontratarem, escolher organizações competentes e gerenciar seu trabalho. SQA - Software Quality Assurance O objetivo da SQA é proporcionar visibilidade aos vários níveis gerenciais dos produtos e processos em uso. Objetivo 1: As atividades de SQA são planejadas. Objetivo 2: Os produtos e atividades em uso atendem a todos os padrões, normas e requisitos aplicáveis. Objetivo 3: Todos os grupos afetados são informados das atividades do grupo de SQA e dos seus relatórios. Objetivo 4: Não conformidades encontradas e não resolvidas no contexto do projeto são tratadas pela gerência superior. Verificar se os requisitos e os padrões estão sendo atendidos. Utilizar-se de checklists para isso. SCM - Software Configuration Management O objetivo do SCM é estabelecer e manter a integridade de todos os produtos de trabalho ao longo do ciclo de vida do projeto. Objetivo 1: As atividades de SCM são planejadas. Objetivo 2: Produtos de trabalho selecionados, os itens de configuração, são identificados, controlados e tornados disponíveis. Objetivo 3: As mudanças dos itens de configuração são controladas. Objetivo 4: Os grupos afetados e indivíduos são mantidos informados da situação e conteúdo do baseline de software. Estabelecer baselines e controlar sua mudança. OPF - Organization Process Focus Tem por objetivo estabelecer a responsabilidade organizacional pelas atividades de processo de software que melhorem a capacitação geral do processo de software da organização. Objetivo 1: Atividades de desenvolvimento e melhoria do processo de software são coordenadas através da organização. Objetivo 2: Os pontos fortes e fracos dos processos de software utilizados são identificados com relação a um processo padrão. Objetivo 3: Atividades de desenvolvimento e melhoria do processo de software em nível organizacional são planejadas. Atribuir a responsabilidade de melhoria e manutenção do processo de desenvolvimento para alguém. OPD - Organization Process Definition O objetivo desta KPA é desenvolver e manter um conjunto utilizável de processos de software que melhorem a performance do processo através dos projetos e forneçam uma base para benefícios cumulativos e de longo prazo para a organização. Objetivo 1: Um processo de software padrão para a organização é desenvolvido e mantido. Objetivo 2: Informações relacionadas ao uso do processo de software padrão da organização pelos projetos de software são coletadas, revistas e tornadas disponíveis. Documentar o processo de desenvolvimento de software, em alto nível e de maneira e objetiva. Mantenha o processo simples. 10

11 TP - Training Program O objetivo do programa de treinamento é desenvolver as habilidades e o conhecimento dos indivíduos de modo que eles possam desempenhar seus papéis de maneira eficiente e eficaz. Objetivo 1: As atividades de treinamento são planejadas. Objetivo 2: Treinamento para desenvolver as habilidades e o conhecimento necessários para realização de tarefas técnicas e de gerência de projeto é fornecido. Objetivo 3: Indivíduos do grupo de engenharia de software e grupos relacionados ao software recebem o treinamento necessário para desempenharem suas tarefas. Os desenvolvedores tem que dominar as técnicas que utilizam. O treinamento não precisa ser em sala de aula. Atividades de mentoring muitas vezes são mais eficientes. ISM - Integrated Software Management O objetivo desta KPA integrar as atividades de engenharia de software e as de gerenciamento em um processo de software definido e coerente, adaptado do processo de software padrão da organização e de demais processos relacionados. Objetivo 1: O processo de software definido para um determinado projeto é uma versão adaptada do processo de software padrão da organização. Objetivo 2: O projeto é planejado e gerenciado conforme o processo de software definido para o projeto. Nem todos os projetos exigem o uso do mesmo processo. Por isso, o processo original da organização tem que poder ser adaptado para as necessidades do projeto. SPE - Software Product Engineering O objetivo desta KPA é realizar consistentemente um processo de engenharia bem definido que integre todas as atividades de engenharia de software para produzir software correto e consistente de maneira efetiva e eficiente. Objetivo 1: As tarefas de engenharia de software são definidas, integradas e realizadas consistentemente para produzir software. Objetivo 2: Produtos de trabalho de software são mantidos consistentes uns com os outros. Use sempre um processo de desenvolvimento consistente, mesmo para pequenos projetos. Não queime fases. Considere este processo quando for fazer o planejamento. Sempre gaste mais tempo com análise de requisitos, design e planejamento dos testes. IC - Intergroup Coordination O objetivo da KPA IC é estabelecer meios para o grupo de engenharia de software atuar ativamente com os outros grupos de engenharia de modo que o projeto satisfaça as necessidades de cliente eficazmente e eficientemente. Objetivo 1: Todos os grupos afetados concordam com os requisitos do cliente. Objetivo 2: Todos os grupos afetados concordam com os compromissos entre os grupos de engenharia. Objetivo 3: Os grupos de engenharia identificam, acompanham e resolvem questões intergrupos. Comunique-se com seu cliente. Registre compromissos. Resolva conflitos. PR - Peer Reviews O objetivo das revisões por pares é remover defeitos dos produtos de software precocemente e eficientemente. Objetivo 1: As atividades de revisão por pares são planejadas. Objetivo 2: Os defeitos dos artefatos de software são identificados e removidos. Submeta sempre todo trabalho a alguma espécie de revisão. Inspeções geralmente são o modo mais adequado. Extreme Programming Brasil - São Paulo - dezembro de

12 Extreme Programming, Qualidade e Confiabilidade de Software QPM - Quantitative Process Management O objetivo desta KPA é controlar a performance do projeto de software quantitativamente. A performance do processo de software representa os resultados verdadeiros alcançados por seguir um processo de software. Objetivo 1: As atividades de gerenciamento quantitativo de processo são planejadas. Objetivo 2: A performance do processo definido para um projeto é controlada quantitativamente. Objetivo 3: A capacitação do processo de software padrão da organização é conhecida em termos quantitativos. Definir poucas métricas simples e coerentes. Coletálas com disciplina. Comparar os resultados atingidos. SQM - Software Quality Management O objetivo desta KPA é desenvolver um entendimento quantitativo da qualidade dos produtos de software de um projeto e alcançar metas de qualidade específicas. Objetivo 1: As atividades de gerenciamento de qualidade de software são planejadas. Objetivo 2: Metas mensuráveis para a qualidade do software e suas prioridades são definidas. Objetivo 3: O progresso verdadeiro em direção ao atingimento das metas de qualidade para os produtos de software é quantificado e gerenciado. Usando-se as metas coletadas na KPA QPM, definir metas de qualidade a atingir. Monitorar o atingimento destas metas. DP - Defect Prevention O objetivo desta KPA é identificar a causa de defeitos e evitar que eles ocorram novamente. Objetivo 1: As atividades de prevenção de defeitos são planejadas. Objetivo 2: As causas comuns dos defeitos são procuradas e identificadas. Objetivo 3: As causas comuns dos defeitos são priorizadas e sistematicamente eliminadas. Identificar as causas dos efeitos e evitar que ocorram novamente. TCM - Technology Change Management O objetivo desta KPA é identificar novas tecnologias e implantá-las na organização de maneira ordenada. Objetivo 1: A incorporação de mudanças tecnológicas é planejada. Objetivo 2: Novas tecnologias são avaliadas para se determinar seus efeitos em termos de qualidade e produtividade. Objetivo 3: Novas tecnologias apropriadas são transferidas para as práticas normais da organização. Fazer sempre projetos piloto. Coletar as métricas padrão da organização. Medir o impacto do uso da nova tecnologias nestas métricas. Avaliar o custo/benefício. PCM - Process Change Management O objetivo desta KPA é melhorar continuamente o processo de software usado na organização com o intuito de melhorar a qualidade do software, aumentar a produtividade e diminuir seu tempo de desenvolvimento. Objetivo 1: A melhoria contínua do processo é planejada. Objetivo 2: Toda a organização participa das atividades de melhoria de processo de software. Objetivo 3: O processo de software padrão da organização e os processos de software adaptados para os projetos são melhorados continuamente. Manter um programa de sugestões. Avaliar o uso de novas práticas em projetos piloto. A XP e o CMM Os valores da XP devem ser levados em consideração em qualquer projeto de software, mesmo que sua implementação varie radicalmente conforme o ambiente. Comunicação e simplicidade, por exemplo, podes ser colocadas em outros termos, como coordenação e elegância. Mas a verdade é que sem elas qualquer projeto enfrenta problemas enormes. Os princípios de comunicação e simplicidade também são princípios de 12

13 projeto de processo fundamentais para organizações que usam o CMM. Quando estão definindo seus processos as organizações devem capturar a mínima informação essencial necessária, usar bons princípios de projeto ao estruturar suas definições e enfatizar a usabilidade e a serventia. O feedback rápido é crucial para o controle de processo em tempo real. É necessário ter coragem para efetivar a mudança cultural necessária a organização para movê-la do nível 1 para o nível 2. Muito do formalismo que caracteriza a melhoria de processo baseada no CMM é devida aos grandes projetos ou a severas restrições de confiabilidade, especialmente para sistemas que envolvem risco de vida. A estrutura hierárquica do CMM é feita para suportar uma ampla gama de implementações dentro do contexto das 18 áreas chave de processo e os 52 objetivos que consistem nos requisitos para um processo de software totalmente maduro. A medida em que os sistemas vão se tornando maiores, algumas das práticas da XP se tornam difíceis de implementar. Conforme o projeto cresce, a ênfase na boa arquitetura se torna crítica para o sucesso do projeto. Arquitetura baseada em projeto, projetar para a mudança, refactoring e filosofias de projeto similares enfatizam a necessidade de lidar com a mudança de modo sistemático. Variantes destes conceitos, incluindo a arquitetura baseada em projeto e equipes de produto integradas podem ser mais apropriadas para projetos grandes, talvez em conjunto com a XP dentro das equipes. Levando-se em consideração que o projeto de arquitetura que enfatiza a flexibilidade é a meta de qualquer boa metodologia orientada a objetos, então XP (com refactoring) e orientação a objetos foram feitas uma para a outra. Equipes multidisciplinares também são problemáticas, uma vez que XP é direcionada somente para software. A principal objeção ao uso da XP na melhoria de processo é que ela mal toca nas questões gerenciais e organizacionais que o CMM enfatiza. Colocar em prática o tipo de ambiente altamente colaborativo que a XP assume requer gerenciamento esclarecido e apropriada infra-estrutura organizacional. A conversa de que um processo disciplinado ao modo CMM é antiético para XP não é convincente. XP também é um processo disciplinado e bem definido. Na verdade, XP e CMM podem ser considerados complementares. O CMM diz o que deve ser feito em linhas gerais, enquanto a XP e um conjunto de melhores práticas que contém informações de como fazer - um modelo de implementação - para um tipo de ambiente em particular. As práticas da XP podem ser compatíveis com as intenções de uma área chave de processo, mesmo que não a realizem completamente [4]. No nível 2, a KPA Requirements Management é tratada pelas histórias, o cliente disponível no local e a integração contínua. As histórias são os acordos dos requisitos entre os clientes e os desenvolvedores. O cliente no local está sempre esclarecendo os detalhes dos requisitos, e a integração contínua e os testes de aceitação garantem que os requisitos sejam cumpridos. A KPA Software Project Planning é tratada pelo jogo do planejamento e pelos releases curtos. O jogo do planejamento, que inclue os planos de release, os planos de interação e as reuniões diárias demonstra a ênfase da XP no planejamento das atividades. Os releases curtos facilitam o planejamento. A KPA Software Project Tracking & Oversight é tratada pelo "big visual chart" - um grande gráfico, atualizado semanalmente, que mostra para todos a evolução do projeto e outras métricas, pela project velocity (velocidade do projeto), ou a quantidade de dias de calendário dividida pela quantidade de dias estimada para a realização da tarefa. As histórias são os compromissos dos releases curtos. O processo de comprometimento para a XP cria expectativas claras para os clientes e a equipe de desenvolvimento no nível tático e maximiza a flexibilidade do projeto no nível estratégico. A ênfase da XP nas 40 horas de trabalho é um conceito geral de gerenciamento que não é considerado pelo CMM, apesar de se tratar de uma boa prática. A XP também tem ênfase no ambiente de trabalho, outra questão deixada de fora do CMM. A KPA Software Subcontract Management não é tratada pela XP. Embora seja improvável um grupo independente de SQA fazer parte da cultura da XP, a KPA Software Quality Assurance é tratada pela programação aos pares; a conformidade aos padrões de codificação, cuja garantia é tarefa típica do grupo de SQA, é garantida pela pressão dos pares no ambiente de XP. Uma vez implantado, um processo baseado em CMM tem mecanismos para verificar objetivamente a aderência aos requisitos, padrões e procedimentos. A dependência da XP à pressão dos pares, mesmo que eficiente na maioria dos ambientes, pode ser vulnerável a pressões externas, e esta vulnerabilidade deve ser considerada no nível organizacional. A KPA Software Configuration Management é parcialmente tratada via propriedade coletiva do código, releases curtos e integração contínua. Mesmo que não completamente e explicitamente tratada, a gerência de configuração está implícita nestas praticas. A integração contínua, por exemplo, coloca o código sob controle de configuração. A propriedade coletiva do código proporciona um certo controle de mudança, enfatizado Extreme Programming Brasil - São Paulo - dezembro de

14 Extreme Programming, Qualidade e Confiabilidade de Software pelas histórias dos releases curtos. Mas a propriedade coletiva de código pode ser problemática em sistemas grandes, e canais de comunicação mais formais devem ser estabelecidos para serem efetivos no controle de mudança. No nível 3, a KPA Organization Process Focus é tratada no nível de equipe em vez de sê-lo no nível organizacional, mas a filosofia por trás da adoção da XP - uma prática por vez e regras justas - implica em focar em questões de processo. Uma vez que a XP foca nos processos de engenharia de software em vez de focar em questões de infra-estrutura organizacional, este e outros processos que estejam no nível de organização devem ser tratados de maneira independente pelas organizações que estejam adotando a XP. De modo análogo, a KPA Organization Process Definition e a KPA Training Program são parcialmente tratadas por vários livros, artigos, cursos e sites sobre XP, mas questões organizacionais estão fora do escopo da mesma. Como conseqüência, a KPA Integrated Software Management não pode ser tratada uma vez que não há processo organizacional para adaptar. A KPA Software Product Engineering é muito bem endereçada de muitas formas pela Extreme Programming com as metáforas, o projeto simples, o refactoring, o mothball tour - congelar modelos relacionados a código que não vai mais sofrer alterações, os coding standards e os testes. A ausência de documentação de projeto seria uma preocupação em muitos ambientes, tais como sistemas de tempo real, sistemas muito grandes ou equipes virtuais. Nestes ambientes, bons projetos são essenciais para o sucesso, e a estratégia de refactoring pode ser arriscada. Por exemplo, fazer refactoring após um sistema ter provado ser satisfatório a requisitos de tempo real pela técnica da análise monotônica de taxa significaria que toda a análise teria de ser refeita - assumir que a mudança não tem um custo alto não vale para este tipo de ambiente. A KPA Intergroup Coordination é tratada pelo cliente no local e a programação aos pares. A ênfase da XP na comunicação parece resultar em uma solução que compreende a coordenação intergrupos e o desenvolvimento integrado de processo e produto, embora o contexto somente de software ignore ambientes multidisciplinares. A KPA Peer Reviews é tratada pela programação aos pares. A programação aos pares pode ser mais poderosa do que a revisão por pares, comparando-se a leitura de código e a programação propriamente dita, embora a falta de estrutura possa diminuir a eficácia. Poucas das KPAs dos níveis 4 e 5 são tratadas pela XP em um sentido rigorosamente estatístico, embora a KPA Defect Prevention possa ser parcialmente tratada pelo feedback devido aos releases curtos. A satisfação das áreas chaves de processo do CMM pela XP, dentro do domínio apropriado, está sumariada na tabela 1. kpas nível 2 kpas nível 3 satisfação satisfação RM XX OPF X QPM -- SPP XX OPD X SQM -- SPTO XX TP -- SSM -- ISM -- DP X SQA X SPE XX TCM -- SCM X IC XX PCM -- PR XX kpas alta maturidade satisfação TABELA 1 - Satisfação das KPAs do CMM pela XP - XX significa totalmente atendido, X significa parcialemente atendido e -- não atendido Muitas das áreas chave de processo parcialmente cobertas ou não tratadas pela XP são sem dúvida nenhuma tratadas em projetos reais. A XP não pode sobreviver sem gerenciamento e sem suporte de infraestrutura, mesmo que ela não fale disso explicitamente. Parece justo afirmar que a XP foca no trabalho técnico, enquanto o CMM foca no trabalho gerencial, mas a preocupação com questões culturais é evidente em ambas. Conclusão Usar metodologias ágeis não é para qualquer um. Há uma certo número de coisas que se deve ter em mente quando se decide seguir este caminho. Entretanto, estas metodologias são largamente aplicáveis e devem ser usadas por mais pessoas do que as que atualmente consideram usá-las. Nas organizações de hoje, a metodologia mais comum é o code and fix. Aplicando mais disciplina do que caos certamente irá ajudar, e a abordagem ágil tem a vantagem de serem muito menos trabalhosa de se adotar do que as metodologias pesadas. Muito da vantagem dos métodos ágeis está no fato de eles serem leves. É mais provável que processos mais simples sejam seguidos quando se está acostumado a não seguir processo nenhum. Uma das maiores limitações destas novas metodologias está em como elas lidam com equipes maiores. Não há registro na literatura do uso destas metodologias em projetos que envolvam mais de 50 pessoas. As metodologias ágeis são boas quando os requisitos são incertos ou voláteis. Quando não se tem estabilidade nos requisitos fica difícil manter um projeto estável e seguir um processo planejado. Nestas situações o uso de 14

15 um processo ágil é mais confortável. Geralmente a maior barreira é o cliente. É importante fazer o cliente entender que seguir um processo preditivo é arriscado quando os requisitos são instáveis. Isto posto, fica claro que o uso de uma metodologia ágil é melhor do que nada. Mas usar a XP - uma metodologia ágil - me garante software de qualidade, ou é melhor continuar com o code and fix e não perder meu tempo com isso? A maior parte da XP consiste de boas práticas que deveriam ser sabiamente consideradas em qualquer ambiente. Enquanto o mérito destas práticas possa ser discutido em comparação com outros, nenhuma delas deve ser arbitrariamente rejeitada. Colocar todas estas práticas juntas em uma metodologia é uma mudança de paradigma. Além disso, a XP atende a boa parte das KPAs do nível 2 e 3 do CMM, isto quando se faz uma leitura menos rigorosa destas KPAs, usando-se o bom senso. A XP fornece uma perspectiva sistemática para a programação, do mesmo modo que o CMM fornece uma perspectiva sistemática a melhoria de processo organizacional. Organizações que querem melhorar sua capacitação deveriam tirar vantagem das boas idéias de ambos e usar o bom senso no uso e na aplicação destas idéias. O CMM foca nas questões de gerenciamento associadas com colocar processos eficientes e eficazes em prática, juntamente com uma melhoria sistemática de processo. A XP é um conjunto específico de práticas - uma metodologia - que é efetiva dentro do contexto das equipes pequenas e que trabalham juntas. Ambas tem boas idéias que podem ser sinergéticas, particularmente em conjunto com outras boas práticas de engenharia e gerência. É questionável se a XP, como publicada, tem uso em sistemas onde há risco de vida ou sistemas de alta confiabilidade. A falta de documentação de projeto e a falta de ênfase na arquitetura seriam julgadas decisões arriscadas pela maioria dos profissionais competentes, mas uma das virtudes da XP está em que ela pode ser mudada e melhorada para diferentes ambientes. Conclue-se que a XP é capaz de produzir software de qualidade, mas seu uso é limitado. Mas o próprio autor, ciente destas limitações, estabelece o ambiente ideal para o uso de XP: equipes pequenas ou médias, requisitos instáveis, sistemas comerciais onde o maior risco envolvido é o financeiro. Levando-se em consideração eu a maioria das empreitadas de desenvolvimento de software tem estas características, e justamente por isso não usam metodologia nenhuma, pode-se considerar que o uso da XP pode resolver grande parte dos recorrentes problemas de desenvolvimento: custo e tempo maiores do que o previsto, baixa qualidade e diminuição na funcionalidade. Bibliografia [1] FOWLER, Martin - The New Methodology - Software Development Magazine - Dezembro/2000 [2] BECK, Kent - Extreme Programming Explained - Addison Wesley [3] MILLER, Roy W.; COLLINS, Christopher T. - XP Distilled - IBM DeveloperWorks - Março/2001 [4] PAULK, Mark C. - Extreme Programming from a CMM Perspective - IEEE Software - Novembro/2001 [5] PAULK, Mark C.; et al - The Capability Maturity Model: guidelines for improving the software process - Addison Wesley [6] PAULK, Mark C. - Using the Software CMM with Good Judgment - ASQ Sofware Quality Professional, Junho/1999 [7] MINISTÉRIO DA CIÊNCIA E TECNOLOGIA. Secretaria de Política de Informática. Sociedade SOFTEX. Levantamento do Universo das Associadas SOFTEX. Brasilia. Ago [8] The Standish Group International. The CHAOS Report. Dennis, MA, Extreme Programming Brasil - São Paulo - dezembro de

Extreme Programming e Qualidade de Software

Extreme Programming e Qualidade de Software Extreme Programming e Qualidade de Software Antonio Sergio Ferreira Bonato Departamento de Sistemas Digitais Escola Politécnica da USP Objetivo (I) mostrar que o uso de um processo de desenvolvimento de

Leia mais

CMM Capability Maturity Model. Silvia Regina Vergilio

CMM Capability Maturity Model. Silvia Regina Vergilio CMM Capability Maturity Model Silvia Regina Vergilio Histórico O DoD patrocinou a fundação do SEI (Software Engineering Institute) na Universidade de Carnegie Mellon (Pittsburg) com o objetivo de propor

Leia mais

Capítulo 5: CMM, o Capability Maturity Model

Capítulo 5: CMM, o Capability Maturity Model Capítulo 5: CMM, o Capability Maturity Model Capítulo 1: Introdução Capítulo 2: Conceitos Básicos Capítulo 3: Qualidade de Produto (ISO9126) Capítulo 4: ISO9001 e ISO9000-3 Capítulo 5: CMM Capítulo 6:

Leia mais

No Relatório Técnico que apresenta o modelo CMM a apresentação das KPAs segue o formato visto Aqui, ênfase no nível 2

No Relatório Técnico que apresenta o modelo CMM a apresentação das KPAs segue o formato visto Aqui, ênfase no nível 2 Os níveis 3, 4 e 5 No Relatório Técnico que apresenta o modelo CMM a apresentação das KPAs segue o formato visto Aqui, ênfase no nível 2 descrição sucinta das KPAs dos níveis 3, 4 e 5 INF310 - Modelos

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

Unidade VI GOVERNANÇA DE TI. Profa. Gislaine Stachissini

Unidade VI GOVERNANÇA DE TI. Profa. Gislaine Stachissini Unidade VI GOVERNANÇA DE TI Profa. Gislaine Stachissini Capability Maturity Model Integration CMMI SW-CMM (Software Capability Maturity Model): prove informações para o aprimoramento de processos de desenvolvimento

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

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 I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

RESUMO. Assunto - CAPACITAÇÃO EM PROCESSOS DE SOFTWARE MODELOS DE CAPACITAÇÃO

RESUMO. Assunto - CAPACITAÇÃO EM PROCESSOS DE SOFTWARE MODELOS DE CAPACITAÇÃO RESUMO Assunto - CAPACITAÇÃO EM PROCESSOS DE SOFTWARE MODELOS DE CAPACITAÇÃO Consiste em um programa de melhoria de processos nas empresas que deve refletir o acervo de experiência dos profissionais e

Leia mais

Capítulo 6: PSP. Capítulo 6: PSP Personal Software Process

Capítulo 6: PSP. Capítulo 6: PSP Personal Software Process Capítulo 6: PSP Personal Software Process Capítulo 1: Introdução Capítulo 2: Conceitos Básicos Capítulo 3: Qualidade de Produto (ISO9126) Capítulo 4: ISO9001 e ISO9000-3 Capítulo 5: CMM Capítulo 6: PSP

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

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

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

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

GARANTIA DA QUALIDADE DE SOFTWARE

GARANTIA DA QUALIDADE DE SOFTWARE GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características

Leia mais

Capítulo 1. Extreme Programming: visão geral

Capítulo 1. Extreme Programming: visão geral Capítulo 1 Extreme Programming: visão geral Extreme Programming, ou XP, é um processo de desenvolvimento de software voltado para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento

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

Mapeamento entre PMBOK, CMM e RUP

Mapeamento entre PMBOK, CMM e RUP Pontifícia Universidade Católica de São Paulo Monografia de Conclusão de Curso MBIS Master Business Information System Mapeamento entre PMBOK, CMM e RUP Maurício Nacib Pontuschka Coordenadora Prof.ª Lavínia

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

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

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

Práticas Recomendadas para a Melhoria do Processo de Software

Práticas Recomendadas para a Melhoria do Processo de Software 167 Práticas Recomendadas para a Melhoria do Processo de Software Josiane Banov Russo 1, Ettore Bresciani Filho 2 1 Gerente da Qualidade Instituto de Pesquisas Eldorado Rod. Campinas Mogi-Mirim, km 118,5

Leia mais

Fatores humanos de qualidade CMM E CMMI

Fatores humanos de qualidade CMM E CMMI Fatores humanos de qualidade CMM E CMMI Eneida Rios¹ ¹http://www.ifbaiano.edu.br eneidarios@eafcatu.gov.br Campus Catu 1 Curso de Análise e Desenvolvimento de Sistemas Conteúdos Fatores humanos de qualidade

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br PROCESSOS PODEROSOS DE NEGÓCIO ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br POR QUE ESCREVEMOS ESTE E-BOOK? Nosso objetivo com este e-book é mostrar como a Gestão de Processos

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente.

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Desenvolvido por Jeff SUTHERLAND e Ken SCHWABER ; Bastante objetivo, com papéis bem definidos; Curva de Aprendizado é

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

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP extreme Programming extreme Programming (XP) Metodologia ágil para equipes pequenas a médias desenvolvendo software com requesitos vagos ou que mudam freqüentemente. [Beck 2000] Em XP, codificação é principal

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br

XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br XP extreme Programming, uma metodologia ágil para desenvolvimento de software. Equipe WEB Cercomp web@cercomp.ufg.br Introdução Criada por Kent Baeck em 1996 durante o projeto Daimler Chrysler. O sucesso

Leia mais

Aplicando práticas de extreme Programming(XP) em equipes SW-CMM nível 2

Aplicando práticas de extreme Programming(XP) em equipes SW-CMM nível 2 Aplicando práticas de extreme Programming(XP) em equipes SW-CMM nível 2 Carlos Henrique Rodrigues Cardoso DCOM Departamento de Computação Instituto Nacional de Telecomunicações (Inatel) Av. João de Camargo,

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

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

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Qualidade na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

Leia mais

Gerência de Projetos CMMI & PMBOK

Gerência de Projetos CMMI & PMBOK Gerência de Projetos CMMI & PMBOK Uma abordagem voltada para a qualidade de processos e produtos Prof. Paulo Ricardo B. Betencourt pbetencourt@urisan.tche.br Adaptação do Original de: José Ignácio Jaeger

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação Centro de Ciências Agrárias Departamento de Computação Visão Geral do Processo de Desenvolvimento de Software Introdução à Ciência da Computação Introdução à Ciência da Computação COM06850-2015-II Prof.

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

O que é Domain-Driven Design

O que é Domain-Driven Design O que é Domain-Driven Design Desenvolvimento Software é mais freqüentemente aplicado a automatizar processos que existem no mundo real, ou fornecimento de soluções para problemas reais de negócios; Os

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

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

CMM - Capability Maturity Model

CMM - Capability Maturity Model Tema da Aula Normas e Padrões de Qualidade em II CMM Prof. Cristiano R R Portella portella@widesoft.com.br CMM - Capability Maturity Model Desenvolvido pelo SEI (Instituto de Engenharia de ) Carnegie Mellon

Leia mais

Problemas Produção. Requisitos. Prof. Ana Paula A. de Castro. Prazos e custos

Problemas Produção. Requisitos. Prof. Ana Paula A. de Castro. Prazos e custos PRODUTOS ENGENHARIA DE SOFTWARE - I Prof. Ana Paula A. de Castro anapaula.rna@gmail.com Problemas Produção Ciclos de vida Projetos Requisitos Características Especificação dos requisitos Engenharia dos

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

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

Programação extrema (XP)

Programação extrema (XP) Programação extrema (XP) Cursos de Verão 2010 - IME/USP Alfredo Goldman Departamento de Ciência da Computação www.agilcoop.org.br Agenda Primeira versão de XP Segunda versão de XP Perguntas durante a apresentação

Leia mais

Maior Previsibilidade com o Visual Studio Team System 2008

Maior Previsibilidade com o Visual Studio Team System 2008 Maior Previsibilidade com o Visual Studio Team System 2008 White Paper Maio de 2008 Para obter as últimas informações, visite o site www.microsoft.com/teamsystem As informações contidas neste documento

Leia mais

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA PMBoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Desenvolvimento Ágil de Software em Larga Escala

Desenvolvimento Ágil de Software em Larga Escala Desenvolvimento Ágil de Software em Larga Escala Jutta Eckstein Encontro Ágil 2009 1 Agilidade é Quente Gerenciamento Ágil de Projetos Testes Ágeis Arquitetura Ágeis Offshore Ágil Investimento Ágil PLM

Leia mais

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT Exercícios: Governança de TI Walter Cunha PRIMEIRA ATERIA (C) A-C-E-F-H (D) A-G-F-H (E) A-G-I PMoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Estudo do CMM e do CMMI

Estudo do CMM e do CMMI Estudo do CMM e do CMMI Autores Félix Carvalho Rodrigues fcrodrigues@inf.ufrgs.br Georgina Reategui gg@inf.ufrgs.br Manuela Klanovicz Ferreira mkferreira@inf.ufrgs.br Motivação Grande quantidade de projetos

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

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

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL

METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL METODOLOGIA LEAN DE DESENVOLVIMENTO DE SOFTWARE: UMA VISÃO GERAL Guilherme Vota Pereira guivotap@hotmail.com Prof. Pablo Schoeffel, Engenharia de Software Aplicada RESUMO: Este artigo irá efetuar uma abordagem

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

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

Fatores Críticos de Sucesso em GP

Fatores Críticos de Sucesso em GP Fatores Críticos de Sucesso em GP Paulo Ferrucio, PMP pferrucio@hotmail.com A necessidade das organizações de maior eficiência e velocidade para atender as necessidades do mercado faz com que os projetos

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Métricas de Software. Sistemas de Informação

Métricas de Software. Sistemas de Informação Métricas de Software Sistemas de Informação Objetivos Entender porque medição é importante para avaliação e garantia da qualidade de software Entender as abordagens principais de métricas e como elas são

Leia mais

MÉTRICAS DE SOFTWARE

MÉTRICAS DE SOFTWARE MÉTRICAS DE SOFTWARE 1 Motivação Um dos objetivos básicos da Engenharia de Software é transformar o desenvolvimento de sistemas de software, partindo de uma abordagem artística e indisciplinada, para alcançar

Leia mais

Faça com que o CRM trabalhe da mesma maneira que o seu pessoal de vendas

Faça com que o CRM trabalhe da mesma maneira que o seu pessoal de vendas Faça com que o CRM trabalhe da mesma maneira que o seu pessoal de vendas APROVEITE AS TECNOLOGIAS DE HOJE PARA MAXIMIZAR A ADOÇÃO POR PARTE DOS USUÁRIOS Para os profissionais de venda, o tempo nunca havia

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI)

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) 1 MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) Teresinha Moreira de Magalhães 1 Lúcia Helena de Magalhães 2 Fernando Machado da Rocha 3 Resumo Este trabalho visa apresentar uma

Leia mais

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY)

COBIT (CONTROL OBJECTIVES FOR INFORMATION AND RELATED TECHNOLOGY) Universidade Federal de Santa Catarina Departamento de Informática e Estatística INE Curso: Sistemas de Informação Disciplina: Projetos I Professor: Renato Cislaghi Aluno: Fausto Vetter Orientadora: Maria

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

GPAD Gestão de Projetos em Ambientes Digitais

GPAD Gestão de Projetos em Ambientes Digitais GPAD Gestão de Projetos em Ambientes Digitais Tecnologia e Mídias Digitais PUC SP Prof. Eduardo Savino Gomes 1 Afinal, o que vem a ser Gestão? 2 Gestão/Gerir/Gerenciar Gerenciar, administrar, coordenar

Leia mais

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações ENAP Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 3: Gerenciamento da Qualidade, dos Recursos

Leia mais

Especialização em Engenharia de Software e Banco de Dados

Especialização em Engenharia de Software e Banco de Dados Especialização em Engenharia de Software e Banco de Dados Disciplina: Engenharia de Software Tópico: Modelos de Ciclo de Vida Prof. Rodolfo Miranda de Barros rodolfo@uel.br Ciclo de Vida A Engenharia de

Leia mais

PREVIEW DAS PRINCIPAIS SEÇÕES DA NBR ISO 19011

PREVIEW DAS PRINCIPAIS SEÇÕES DA NBR ISO 19011 CENTRO DA QUALIDADE, SEGURANÇA E PRODUTIVIDADE PARA O BRASIL E AMÉRICA LATINA PREVIEW DAS PRINCIPAIS SEÇÕES DA NBR ISO 19011 Diretrizes para auditorias de sistemas de gestão da qualidade e/ou ambiental

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 CMMI. Qualidade e Teste de Software CMMI 1

Introdução CMMI. Qualidade e Teste de Software CMMI 1 Introdução CMMI O propósito da qualidade é estabelecer um diferencial competitivo, através de contribuições como redução de defeitos, redução de custos, redução de retrabalho e aumento da produtividade,

Leia mais

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças. METODOLOGIAS ÁGEIS SURGIMENTO As metodologias ágeis surgiram em resposta ao problema dos atrasos no desenvolvimento de software e aos cancelamentos, devido ao fato dos sistemas demorarem muito tempo para

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

Utilizando o CobiT e o Balanced Scorecard como instrumentos para o. Gerenciamento de Níveis de Serviço

Utilizando o CobiT e o Balanced Scorecard como instrumentos para o. Gerenciamento de Níveis de Serviço Utilizando o CobiT e o Balanced Scorecard como instrumentos para o Gerenciamento de Níveis de Serviço Win Van Grembergen, http://www/isaca.org Tradução de Fátima Pires (fatima@ccuec.unicamp.br) Na economia

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

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

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

O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto

O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto Gerais Processo Produto Propostas NBR ISO 9000:2005 define principios e vocabulário NBR ISO 9001:2000 define exigências para sistema de gerência de qualidade NBR ISO 9004:2000 apresenta linha diretivas

Leia mais

Delfraro Rodrigues Douglas M Gandini José Luiz CMM. Capability Maturity Model

Delfraro Rodrigues Douglas M Gandini José Luiz CMM. Capability Maturity Model Delfraro Rodrigues Douglas M Gandini José Luiz CMM Capability Maturity Model O que é o CMM? Modelo para avaliação da maturidade dos processos de software de uma organização Identificação das práticas chave

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

Gerência e Planejamento de Projeto. SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002

Gerência e Planejamento de Projeto. SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 Gerência e Planejamento de Projeto SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 Conteúdo: Parte 1: Gerenciamento & Qualidade Plano de Projeto

Leia mais