SlideShare uma empresa Scribd logo
1 de 20
Baixar para ler offline
C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS
DO RECIFE
ADSON WENDEL CIRILO FERREIRA
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O
MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE
MATURIDADE G E F
Recife
2011
ADSON WENDEL CIRILO FERREIRA
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O
MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE
MATURIDADE G E F
Monografia apresentada ao programa de
Especialização em Engenharia de Software do
Centro de Estudos e Sistemas Educacionais do
Recife – C.E.S.A.R, como requisito para a
obtenção do título de Especialista em Engenharia
de Software com ênfase em Gestão Ágil de
Projetos.
Orientação: Prof. Jorge Luiz Bublitz
Recife
2011
Mapeamento entre a metodologia ágil FDD e o Modelo de
Qualidade MPS.BR nos Níveis de Maturidade G e F
Adson Wendel Cirilo Ferreira1
, Jorge Luiz Bublitz2
1
C.E.S.A.R – Centro de Estudos e Sistemas Avançados do Recife
Adson_wendel@hotmail.com
2
E.S.A.B - Escola Superior Aberta do Brasil
bublitz@hotmail.com
Resumo. O MPS.BR, é uma avaliadora da qualidade de software e serviços
relacionados, utiliza padrões e características semelhantes ao modelo CMMI
e nas normas ISO/IEC 12207 e na ISO/IEC 15504, visando as empresas
desenvolvedoras de software, que seja certificada na norma brasileira, este
artigo baseando-se na FDD, vem com o objetivo de ajudar as empresas a
definirem um processo ágil e ganharem mais velocidades nos processos dos
resultados esperados desta certificação, assim tornando-se ainda mais
competitiva no mercado de software.
1. Introdução
O MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa brasileiro que
apresenta um padrão de qualidade fundamentado no CMMI (Capability Maturity Model
Integration) e nas ISO's 12207 e 15504, o qual é responsável em avaliar não só a
qualidade e a produtividade de software, mas também serviços relacionados a ele. Para
uma empresa que trabalha visando alcançar os resultados esperados do modelo de
maturidade brasileiro.
Seu principal objetivo é traçar os resultados esperados a serem trabalhados de
maneira produtiva e eficiente para o desenvolvimento de um software que busca sempre
um melhoramento geral, voltando-se à condição do mercado brasileiro, para o alcance
das empresas públicas e privadas de vários tamanhos, onde a maior atenção é para as
micros, pequenas e médias empresas, segundo a SOFTEX (2011a) “de forma a atender
as suas necessidades de negócio e ser reconhecido nacional e internacionalmente
como um modelo aplicável à indústria de software” por esses motivos o MPS.BR é
modelo escolhido para este artigo.
O Manifesto Ágil, resultado de uma reunião realizada em 2001 nos EUA, que
teve a participação de dezessete especialistas da engenharia e desenvolvedores de
software, Agile Manifesto (2004) relata que “Como seria difícil outra reunião com estes
anarquistas organizacionais, o que resultou foi o simbólico – Manifesto do
Desenvolvimento Ágil de Software – assinado por todos participantes.”, Relata
Soare(2009) que a agile manifesto importando-se com “os indivíduos e interações,
com o software estar executável, com a colaboração do cliente e as respostas rápidas a
mudanças e alterações”.
Diante disso, os modelo, MPS.BR e CMMI, e as normas, ISO (Institute of
Organization for Standardization) 12207 e 15504, são conhecida como metodologias
tradicionais, segundo Soares (2009) “Processos orientados a documentação para o
desenvolvimento de software são, de certa forma, fatores limitadores aos
desenvolvedores”, chegando a prorrogar a criação dos processos mais complexos,
retardando as entregas. Com base no novo pensamento agilista, este trabalho propõe
ajudar uma empresa a se tornar mais competitiva, aumentar ainda mais sua visibilidade
no mercado e ganhar mais velocidade nos processos requeridos pela norma de
maturidade, baseando-se na metodologia de gerenciamento e engenharia de
software, a FDD(Feature Driven Development), que é utilizada de forma iterativa e
incremental com práticas ágeis.
1.1 Objetivo
O objetivo principal deste artigo é o mapeamento dos resultados esperados do modelo
MPS.BR dos níveis G e F com as práticas da FDD que satisfaça as necessidades de cada
resultado. As áreas de processos que serão utilizadas no modelo brasileiro são: Gerência
de Projetos, Gerência de Requisito, Gerência de Configuração, Garantia da Qualidade e
Medição. Os processos de Aquisição e Gerência de Portfólio de Projetos não são
contemplados. No intuito de consolidar o artigo, foi feita uma revisão bibliográfica no
Manifesto ágil, na FDD, no MPS.BR e suas bases estruturais, que é a ISO 12207, a
15504 e o CMMI.
1.2 Justificativa
A competitividade entre as organizações desenvolvedoras de software fez com que os
clientes ficassem mais rigorosos na qualidade dos produtos por elas produzidos, onde as
empresas podem comprovar com uma Certificação MPS.BR, programa que avalia a
qualidade e serviços relacionados a software, que é direcionado a real situação do
mercado brasileiro, no intuito do alcance das empresas públicas e privadas, com maior
atenção as micros, pequenas e médias empresas.
O MPS.BR utiliza uma metodologia tradicional segundo Soares (2009)
“conhecidas também como pesadas ou orientadas a planejamentos”. Através dele, as
atividades são orientadas a documentação para o desenvolvimento de software, que de
certa forma limita o desenvolvimento dos processos mais complexos.
O foco deste artigo são as empresas que seja certificado no (MPS.BR) , com real
contribuição que a FDD tem para agilizar os resultados esperados pelo modelo
brasileiro. Com isso, tais empresas ganham mais velocidade nos processos, tornando-se
ainda mais competitivas no mercado de software, através da utilização de uma das
metodologias (FDD) que foi associada ao manifesto ágil.
1.3 Estrutura da Monografia
Este artigo está organizado na seguinte forma:
Na seção 2, foi feita uma abordagem sobre as bases da estrutura do modelo
brasileiro MPS.BR, delimitando em resumos a ISO/IEC 12207 e sua evolução, a
ISO/IEC 15504 e o CMMI, descrevendo suas origens e seus desenvolvedores. Foi
apresentado, também em síntese, o conceito e as características de cada norma de
melhoria de processo de software;
Na seção 3, foi realizada uma abordagem sobre o programa MPS.BR,
apresentando informações essenciais sobre o modelo de Referência (MR-MPS),
aprofundando as informações para os níveis de maturidade G e F, com intuito de
delimitar o tema deste artigo;
Na seção 4, foi abordado o surgimento do manifesto ágil, os seus conceitos,
princípios, os profissionais e as metodologias envolvidas;
Na seção 5, foi comentada a criação da FDD, seu conceito, características,
modelo ARO, algumas das práticas mais usadas, principais papéis e os cinco processos
principais;
Na seção 6, foi apresentado um mapeamento conciso entre o modelo MPS.BR
com os resultados esperados dos níveis de maturidades G e F que possuem atividades
similares na FDD;
Na seção 7, foi apresentada uma conclusão analítica sobre o artigo.
2. Base da Estrutura do Modelo MPS.BR
2.1 ISO/IEC 12207
A norma ISO/IEC 12207 foi criada pela ISO e IEC para solucionar um problema de
modelagem e melhoria no processo de software, e segundo Gusmão & Moura (2004) “é
a primeira norma internacional que descreve em detalhes os processos, atividades e
tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de
produtos de software” localizando-se entre as mais antigas normas que definem os
processos de desenvolvimento da área.
Weber (2004) afirma que “a norma foi publicada internacionalmente em 1995, e
no Brasil em 1998”. Segundo Gusmão & Moura (2004) “Essa norma divide os
processos em três grandes classes: Processos Fundamentais, Processos de Apoio e
Processos Organizacionais”, cada classe com suas atividades.
O objetivo fundamental do modelo é instalar uma base comum para os processos
de ciclo de vida e de desenvolvimento do software, estruturada para ser flexível, sem
ligações com treinamentos, ferramentas, métodos e linguagens de desenvolvimento.
Segundo Ferreira (2010; p18) a norma “possibilita um acompanhamento da evolução da
engenharia de software e de organizações com culturas distintas, flexibilidade
importante, pois implica no “o que fazer” e não ficando refém de “como fazer””.
2.2 ISO/IEC 15504
Também conhecida como SPICE e evoluída da ISO 12207, é uma norma de processos
de desenvolvimento de software que teve uma versão aprovada em 1998, que, em união
com a comunidade internacional e através do projeto SPICE, foi publicada em 2003 pela
ISO. Nela é descrito um conjunto de processos considerados universais e fundamentais
para que se possa ter um planejamento e desenvolvimento com qualidade, visando a
melhoria dos processos da criação do software.
As organizações podem solicitar certificação de capacidade específica em áreas
determinadas, sabendo assim quais partes da organização terão que ser feitas melhorias
e quais características manter. Segundo Weber et al. (2004; p6) “a organização pode
realizar a avaliação, gerando um perfil dos processos que será usado para a elaboração
de um plano de melhorias”, das quais a empresa deve continuar sempre a manter, sem
perder a qualidade e o foco no cliente.
2.3 CMMI
É uma modelo de certificação de qualidade empregada no intuito de avaliar as melhorias
na maturidade dos processos em desenvolvimento de software e serviços
correspondentes, com origem no ano de 1980, nos Estados Unidos, com implantação do
projeto desenvolvido pelo SEI(Software Engineering Institute). Segundo Pessôa (2005)
“O desenvolvimento desse modelo foi financiado pelo departamento de defesa
americano, com o objetivo de estabelecer um padrão de qualidade para software
desenvolvido para as forças armadas”. Com essa norma de avaliação, seria possível
mensurar os processos desenvolvidos de software das organizações que concorriam pela
licitação, tendo em vista as indicações, valor do produto, qualidade, garantia de prazos
de entrega e dos projetos contratados. Embora iniciada para projetos militares, é válida
para todo tipo de projetos de software.
Rezende (2002) afirma que “os principais objetivos do CMMI são auxiliar as
empresas a conhecerem e melhorarem seus processos de desenvolvimento e manutenção
de software, fornecendo uma estrutura conceitual para guiar as empresas para obterem
controles de seus processos, com melhoria contínua de seus produtos de software”.
O CMMI é dividido em níveis de maturidade. Segundo Gusmão & Moura (2004)
O SW-CMM foi o primeiro modelo desenvolvido na área de maturidade e capacidade, o
qual apresenta cinco níveis de maturidade, onde o mais avançado corresponde a uma
maior maturidade do processo que está associado a uma maior produtividade, qualidade
e a um menor risco organizacional. As graduações crescentes são: inicial, repetível,
definido, gerenciado e otimização.
3 MPS.BR
O modelo MPS.BR tem como objetivo a melhoria de processo de software, manejando a
empresa buscar a seus produtos desenvolvidos e serviços relacionados com qualidade.
Weber (2004, P3) afirma que “O Projeto MPS.Br visa a melhoria de processos de
software em empresas brasileiras a um custo acessível, especialmente na grande massa
de micro, pequenas e médias empresas”. É um projeto brasileiro empregado,
igualmente, para organizações públicas e privadas, com padrão e qualidade das normas
de desenvolvimento internacionais.
Figura 1: Estrutura do projeto MPS.BR
Fonte: SOFTEX <http://www.softex.br/portal/softexweb/uploadDocuments/sbes2011_
melhoria_processo_folder_com_quadro_a4.pdf >
A figura 1 exibe a estrutura do projeto MPS.BR, as suas bases de sustentação
nas normas internacionais da ISO/IEC 12207 e ISO/IEC 15504 e o modelo CMMI,
apresentando o conjunto do projeto com as respectivas funções. No guia geral, são
demonstrada as informações do modelo de Referência (MR-MPS), níveis, resultados
esperados e outros; no guia de aquisição, são mencionados os processos de aquisição
de software e serviços correlatos; no guia de avaliação, é apresentado o método de
avaliação (MA-MPS), mencionando as informações necessárias para o entendimento
dos processos avaliativos; e no documento de programa, são apresentadas as
informações sobre o modelo de negócio (MN-MPS).
Figura 2: Comparação dos Níveis de Maturidade do modelo MPS.BR com o modelo CMMi
Fonte: SOFTEX < http://www.softex.br/portal/softexweb/uploadDocuments/MN-MPS.pdf>
Na figura 2, são apresentados os níveis de maturidade do modelo de referência.
Segundo a SOFTEX (2011a) são “A (Em Otimização), B (Gerenciado
Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido),
F(Gerenciado) e G (Parcialmente Gerenciado)”. Nos níveis de maturidades, serão mais
detalhados o G e F.
3.1 G - Parcialmente Gerenciado
Por ser o primeiro nível de maturidade a implantar as melhorias dos processos de
software em uma empresa, requer cautela para mudar a cultura da organização para a
melhoria de processo e para a definição de projeto. A SOFTEX (2011b, pag. 6) relata
que “porventura, a organização possuir processos já definidos e os projetos necessitarem
adaptar os processos existentes, tal fato deverá ser declarado durante o planejamento do
projeto”. Essas adaptações podem incluir alteração em processos, atividades,
ferramentas, técnicas, procedimentos, padrões, medidas, dentre outras.
3.1.1 Gerência de Projetos
O guia específico do nível de maturidade G da SOFTEX (2011b) afirma que “O
propósito do processo de Gerência de Projetos é estabelecer e manter planos que
definam as atividades, recursos e responsabilidades do projeto, bem como prover
informações sobre o seu andamento”. Ao acumular os níveis de maturidades, alguns
resultados esperados são incorporados e outros sofrem modificações.
3.1.2 Gerência de requisito
Na gerência de requisito, o objetivo do processo é o controle e a evolução dos
requisitos, vindos de análise junto ao cliente ou gerados pelo projeto, sempre
documentando as mudanças dos requisitos e seus motivos. Segundo a SOFTEX (2011b)
“O propósito do processo e Gerência de Requisitos é gerenciar os requisitos e os
componentes do produto do projeto, identificar inconsistências entre os requisitos,
planos e produtos de trabalho do projeto”.
3.2 F – Gerenciado
No nível de maturidade F, o principal foco é nos processos para a gestão do projeto,
“[...] no que diz respeito à Garantia da Qualidade (GQA) e Medição (MED), bem como
aqueles referentes à organização dos artefatos de trabalho por meio da Gerência de
Configuração (GCO)” relata a SOFTEX (2011c).
3.2.1 Gerência de Configuração
Sua principal atuação ocorre durante o processo de auxiliar no controle e
acompanhamento, manter a integridade do projeto e suas funcionalidades, sendo
fundamental prover o controle sobre os trabalhos desenvolvidos e modificados. A
SOFTEX (2011c) afirma que “em determinados momentos do ciclo de vida do
desenvolvimento e manutenção do software, esses itens de configuração são agrupados
e verificados, constituindo configurações do software, voltadas para propósitos
específicos, denominadas baselines”, assim ficam delegados conjuntos de itens de
configuração.
3.2.2 Garantia da Qualidade
Com a finalidade em confirmar que o produto desenvolvido ou serviços estão em
conformidades com os processos traçados no plano do projeto, exibe visibilidade do
projeto e apoia à gerência. De acordo com a SOFTEX (2009e) “A pessoa ou grupo que
executa a atividade de garantir a qualidade de processos e produtos tem uma
responsabilidade delicada, pois fiscaliza se as pessoas estão desempenhando
adequadamente as suas tarefas e seguindo os procedimentos estabelecidos”. Para isso, é
necessário que os responsáveis tenham autoridade para executar seu trabalho,
documentarem não conformidade do projeto, cobrarem a correção dos artefatos
encontrados, promoverem feedback da verificação realizada para a gerência e equipe de
projeto.
3.2.3 Medição
Segundo a SOFTEX (2009e) “O propósito do processo Medição é coletar, armazenar,
analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos
implementados na organização e em seus projetos, de forma a apoiar os objetivos
organizacionais”. A medição é muito utilizada para o auxílio da tomada de decisão da
gerência
4 Manifesto Ágil
Em 2001, nos EUA, em uma reunião que discutiu formas de melhorar o desempenho de
projetos de softwares, surgindo assim a Aliança do Desenvolvimento Ágil de
Software. onde 17 desenvolvedores assinantes, principais profissionais experientes e
reconhecidos “gurus” desenvolvedores na área de engenharia de softwares, foram: Kent
Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon
Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland e Dave Thomas, os quais têm o objetivo de ajudar outras pessoas com os
métodos ágeis a crescerem seus próprios conhecimentos, segundo Agile
Manifesto(2004) “Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo.”
Na elaboração do manifesto ágil, foram envolvidas várias metodologias ágeis:
XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), Família
Crystal, ASD (Adaptive Software Development), SCRUM e FDD (Feature-Driven
Development), das quais este artigo fará o mapeamento com os níveis G e F do
MPS.BR.
Os valores do desenvolvimento ágil, de acordo com o Agile Manifesto (2004),
são:
• Indivíduos e interações mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
A utilização das metodologias ágeis já é um movimento que é fato no Brasil,
onde vários projetos foram concluídos com êxito. AgilCoop (2011) lista algumas
empresas: Objective Solutions, pioneira no uso de XP no Brasil; LocaWeb, utiliza
Scrum e XP desde de 2007; Paggo, desenvolve software usando XP que também
influencia no funcionamento da empresa; Improve It, consultoria em XP; Teamware,
consultoria, mentoring e treinamento com Scrum Master e Scrum Leader e Neurobox
com Scrum, XP e Lean, entre outras não citadas pelas empresas.
5 FDD
Surgiu em 1997 em Singapura para solução de um projeto de software de
empréstimo para uma instituição bancária, segundo Retamal (2008b) “a partir de
técnicas de gerenciamento de projetos e de modelagem orientadas a objetos, Jeff De
Luca era o gerente do projeto e Peter Coad foi contratado para fazer a modelagem do
domínio do problema”, nascendo assim a FDD que equilibrava as metodologias
prescritivas com as técnicas de De Luca e com as estratégias de Coad, propondo uma
metodologia de desenvolvimento que atendesse a demanda de entrega de resultados
frequentes e sem atrasos, a qual possui o lema “resultados frequentes, tangíveis e
funcionais”. O projeto para a instituição bancária durou 15 meses e foi desenvolvido
com 2000 feature por 50 pessoas.
De acordo com Retamal (2008b) os responsáveis “lançaram as ideias no livro
“Java Modeling in Color with UML” (1999). Posteriormente (2002), Stephen Palmer
[...] e John Mac Felsing [...] lançaram “A Practical Guide to FDD”, com a descrição
completa e atualizada da metodologia.”
Bublitz (2011) afirma que a FDD “é uma metodologia iterativa e incremental de
gerenciamento e engenharia de software, que combina as melhores práticas de outras
abordagens ágeis com técnicas centradas no modelo”, com característica que enfatiza a
qualidade durante o processo, entregas curtas e versões de software pequenas. Com o
intuito de oferecer valor ao cliente, as features são desenvolvidas no máximo em duas
semanas e segue o modelo ARO (Ação, Resultado e Objetivo). Medeiros (2011) explica
que o modelo “Representa uma <Ação> necessária para atingir determinado
<Resultado> de negócio envolvendo determinados <Objetos> de negócio, por exemplo:
“<Autorizar> um <desconto> numa <venda>””.
Os papéis chaves em um projeto FDD são divididos em funções e cargos, são
eles: gerente de Projeto, líder administrativo e financeiro do projeto, o qual tem a
palavra final no que se trata de escopo, cronograma e RH do projeto; arquiteto chefe,
responsável pela modelagem do projeto; gerente de desenvolvimento, este lidera as
atividades diárias do desenvolvimento, sendo responsável para solucionar conflitos
dentro da equipe; programador chefe é o desenvolvedor experiente, presente nas fases
de análise de requisitos e de modelagem de projetos, lidera pequenos times de
desenvolvimento, seleciona as funcionalidades e os donos das classes para a próxima
iteração; donos de classe, geralmente é um desenvolvedor que trabalha orientado pelo
Programador Chefe, executando as tarefas de modelar, codificar, testar e documentar; e
os especialistas no domínio de negócio, os quais são responsáveis em informar a
equipe sobre o que deve ser implementado para que o software agregue valor.
A FDD possui algumas práticas de engenharia de software com o objetivo de
estimularem a produção com qualidade, entre elas: modelagem de objetos do domínio,
desenvolvimento por feature, posse individual de classe (código), equipes de features,
inspeções, builds regulares, demonstrável para o cliente; relatório/visibilidade de
resultados e gerenciamento de configuração que acompanha todo o histórico do código-
fonte.
A FDD é uma metodologia muito objetiva que possui cinco processos, o qual é
dividida em duas etapas, assim tornou esta metodologia escolhida para o
mapeamento com o MPSBR neste artigo, a primeira é concepção e planejamento,
que pensa no modelo e cria uma lista de feature e planeja através dela; a segunda é a
construção, que é um desenvolvimento iterativo e incremental que dura no máximo
duas semanas.
Figura 3: Estrutura da FDD.
Fonte: < http://www.heptagon.com.br/images/fdd.png >
5.1 Desenvolver um Modelo Abrangente
Processo que é executado apenas uma vez em todo o Projeto, composto por um time de
modelagem com especialistas de negócio, programadores e arquiteto líder. Luca (1998)
relata que “É feito um estudo detalhado do escopo do sistema e seu contexto é
executada, então são feitos estudos mais detalhados em cada área a ser modelada”. Em
seguida são formados pequenos grupos por membros do domínio do negócio, os
desenvolvedores criam seus modelos, os quais são estudados, revisados e discutidos,
para através de um consenso escolher um ou mais modelos criados pelos grupos.
5.2 Construir uma lista de funcionalidades Também é um processo único executado no
início do projeto, que visa satisfazer os requisitos e criar as funcionalidades. É composto por
programadores líderes do processo anterior, onde o entendimento do escopo é ampliado através
da descoberta das feature de cada área prioritária. Retamal (2008a) descreve que “para
decompor funcionalmente o domínio em áreas, atividades de negócio dentro delas e passos
dentro de cada atividade de negócio, formando assim a lista categorizada de funcionalidades”, é
utilizada a prática de FBS (Feature Breakdown Structure) para ajudar a identificar as
funcionalidades a desenvolver, segundo Medeiros (2011) “Organiza o entendimento sobre as
áreas, as atividades de negócios e as funcionalidades de um produto” sobre uma leitura
estruturada dos requisitos.
Figura 4: Feature Breakdown Structure.
Fonte: < http://agiles2008.agiles.org/common/pdfs/Pimentel%20-20Agil%20FDD.pdf>
5.3 Planejar por Feature
Último processo da primeira etapa que, igualmente aos dois processos anteriores, é
inicial e abrange todo o projeto onde são planejadas as sequências, nas quais as
funcionalidades serão desenvolvidas, tendo como base para desenvolver as
dependências entre classes, carga de trabalho e complexidade.
A equipe é composta pelo gerente de desenvolvimento e pelos programadores
líderes, de modo que, para cada atividade de negócio, o planejamento deve reportar uma
data com mês e ano para a finalização.
5.4 Projetar por Feature
Primeiro processo da etapa de construção, que tem seu ciclo renovado em todas as
funcionalidades. Certas features são selecionadas e agendadas com uma data de
finalização, consequentemente irá para desenvolvimento, criando uma “caixa de
entrada”, podendo fazer uma junção de funcionalidades, chamada de pacote de trabalho.
Segundo Luca (1998) “o programador chefe, forma uma equipe de recursos,
identificando os proprietários das classes (desenvolvedores) que possam estar
envolvidos no desenvolvimento desses recursos. Essa equipe então produz Vistas
Cenário para o recurso atribuído”.
Cada desenvolvedor produz então prefácios das classes e métodos para cada
feature com seus diagramas de classes e de sequências que servirão de base para o
programador líder refinar o modelo de objetos que serão submetidos ao sistema de
controle de versões. A atividade de projetar por feature pode ou não utilizar UML em
cores, no intuito de auxiliar no entendimento das features. O programador líder pode
fazer inspeção no projeto com os membros da equipe de funcionalidades ou com outros
membros do projeto.
De acordo com Medeiros (2011) “a UML em cores foi inicialmente posta por
Peter Coad, e teve grande contribuição de Eric Lefebvre e Jeff De Luca, os quais
possuem vários anos de experiência em modelagem de aplicações para segmentos de
variados tamanhos”. Para facilitar a identificação das construções das entidades, as
categorias segundo o Coad (1999) são identificada da seguinte forma “Rosa: um
momento ou intervalo de tempo. Amarelo: um papel a ser desempenhado por alguém ou
algo. Azul: a entrada de catálogo-como a descrição. Verde: uma pessoa (partido), lugar
ou coisa”.
5.5 Construir por Feature
Processo onde é realmente desenvolvido o código fonte de cada feature, visando a
entrega contínua com valor ao cliente. Luca (1998) relata que “Começando com o
pacote de projeto, os proprietário das classes implementam os itens que serão
necessários para que suas classes suportem o projeto para a sua funcionalidade.” e após
passar pela inspeção de outra pessoa da equipe ou do projeto, a funcionalidade é levada
a uma build. Cada funcionalidade é medida através de um gráfico constituído por seis
marcos bem definidos, denominados milestones. A cada etapa cumprida, o percentual
respectivo é agregado ao total de progresso e utilizado para o controle das features do
painel de progresso (Parking Lot).
6 Mapeamentos entre FDD e MPS.BR.
Neste capítulo será apresentado um mapeamento conciso entre o modelo MPS.BR com
os resultados esperados dos níveis de maturidades G e F que possuem atividades
similares na FDD, delimitando as áreas de processos do MPS.BR para gerência de
projetos, gerência de requisito, gerência de configuração, garantia da qualidade e
medição, não contemplando os processos de aquisição e gerência de portfólio de
projetos, os quais não possuem práticas que a FDD atenda.
A FDD não é condicionalmente compatível com os resultados esperados dos
níveis do MPS.BR exposto neste artigo, por este motivo foram estabelecidos três
critérios para classificar a equivalência entre da metodologia FDD e o modelo de
qualidade brasileiro, primeiro critério, Atende, a prática da FDD está em plena
conformidade; Atende Parcial, Algumas evidências são encontradas mas não satisfaz
integralmente o que é solicitado; Não Atende, não há como a FDD ajudar com suas
atividades.
Processo Gerência de Projetos (GPR)
O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem
as atividades
Processo Gerência de Projetos (GPR) FDD Critério
GPR1 - O escopo do trabalho para o projeto é
definido.
O escopo é criado em duas etapas:
Desenvolver o modelo abrangente e
Construir a lista de funcionalidades.
Atende
GPR2 - As tarefas e Produtos são
dimensionados, resultado de estimativa de
tamanho, a dimensão das funcionalidades são
contadas, classes, objetos.
No processo Construir a Lista de
Funcionalidades, ocorre a decomposição
funcional das áreas do negócio definidas
na primeira etapa.
Atende
GPR3 - As fases do ciclo de vida do projeto são
definidas.
Ocorre em duas etapas: Desenvolver o
modelo abrangente e Construir a lista de
funcionalidades, onde é decomposto em
funcionalidades.
Atende
GPR4 - O esforço e o custo para a execução do
projeto são estimados com base em dados
históricos onde são recuperadas informações de
tempo e complexidade.
A estimativa de esforço encontra-se na
etapa Planejar por Funcionalidade, onde
são realizadas através da complexidade e
experiências anteriores.
Atende
Parcial
GPR5 - O orçamento e o cronograma do
projeto, incluindo a definição de marcos e
pontos de controle, são estabelecidos e
No fim do processo Planejar por
Funcionalidade é criado o Plano de
Desenvolvimento, onde encontram-se: as Atende
mantidos. features com suas dependências, a
sequência de criação, as atividades de
negócio com as datas de términos e os
pontos de controle do cronograma.
Parcial
GPR6 - Os riscos do projeto são identificados,
o seu impacto é documentado e os riscos são
analisados e priorizados.
O gerente de desenvolvimento tem o
papel de ser o responsável pela resolução
de riscos que possam vir a ocorrer dentro
da equipe. As funcionalidades mais
complexas de maiores riscos ficam sob a
responsabilidade dos programadores
chefe.
Atende
GPR7 - Os recursos humanos para o projeto são
planejados considerando o conhecimento,
habilidades e experiências possuídas.
Os papéis são definidos e cada um tem
suas funções e as atividades realizadas no
processo Planejar por Funcionalidade,
onde as pessoas da equipe são alocadas
de acordo com as classes que lhes foram
atribuídas.
Atende
GPR8 - Os recursos e o ambiente de trabalho
necessários para executar o projeto são
planejados.
O gerente de projeto é responsável por
fornecer condições de trabalho
adequadas para a equipe.
Atende
GPR9 - Os dados do projeto são identificados e
planejados quanto à forma de coleta,
armazenamento e distribuição.
São identificados em diagrama de classes
(Modelo Abrangente de Dados),
diagramas de sequência, de estado, de
casos de uso entre outros; já o
armazenamento é submetido a um
controle de versão.
Atende
GPR10 - Um plano geral para a execução do
projeto é estabelecido com a integração de
planos específicos.
No plano de desenvolvimento contém
atividades, onde os programadores
líderes atribuem as funcionalidades das
atividades de negócio aos seus
respectivos desenvolvedores
proprietários.
Atende
Parcial
GPR11 - A viabilidade do projeto,
considerando as restrições e os recursos
disponíveis, é avaliada, se necessário, ajustes
são realizados.
Ainda no plano de desenvolvimento no
processo Planejar por Funcionalidade são
geradas atividades de negócio com datas
de término, e o acompanhamento do
projeto é revisto de acordo com as
alterações junto ao cliente.
Atende
GPR12 - O Plano do Projeto é revisado com
todos os interessados e o compromisso com ele
é obtido.
O processo Desenvolver o Modelo
Abrangente é realizado por membros de
domínio do negócio, por programadores
e pelo arquiteto líder. Após construir a
lista de features, o plano de
desenvolvimento é criado. Este é
revisado pelo cliente e pela equipe, todos
se comprometendo.
Atende
Parcial
GPR13 - O projeto é gerenciado utilizando-se o
Plano do Projeto e outros planos que afetam o
projeto, e os resultados são documentados.
No plano de desenvolvimento, contém as
datas para as entregas das features. Ao
fluir das atividades, as datas são
comparadas.
Atende
Parcial
GPR14 - O envolvimento das partes
interessadas no projeto é gerenciado,
informando em quais fases eles são importantes
e como serão envolvidos.
Todos os processos e as partes
interessadas são planejados, Desenvolver
o Modelo Abrangente com domínio do
negócio, desenvolvedores e arquiteto
líder. No processo Construir a Lista de
Funcionalidades programadores líderes e
Atende
desenvolvimento assim sendo
envolvidos.
GPR15 - Revisões são realizadas em marcos do
projeto e conforme estabelecido no
planejamento.
No plano de desenvolvimento,
contemplam as datas de finalização.
Nessas datas são realizadas inspeções do
progresso das atividades e do projeto em
relação ao planejado.
Atende
GPR16 - Registros de problemas
identificados, incluindo dependências críticas,
são estabelecidos e tratados com as partes
interessadas.
Não
Atende
GPR17 - Ações para corrigir desvios em
relação ao planejado e para prevenir a repetição
dos problemas identificados são estabelecidas.
No plano de desenvolvimento contem as
lista de funcionalidades nas quais são
realizadas inspeções e testes podendo
identificar possíveis riscos que é de
responsabilidade do gerente de projeto
aplicar medidas que sanem problemas em
desvios de planejamento.
Atende
Parcial
Quadro1: Descrição dos resultados esperados do processo de Gerência de Projetos e o mapeamento na FDD
Nível G – Processo Gerência de Requisitos (GRE)
O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e
componentes do produto do projeto. Ele possui os seguintes resultados esperados:
Processo Gerência de Requisitos (GRE) FDD Critério
GRE1 - Os requisitos são entendidos, avaliados
e aceitos junto aos fornecedores de requisitos.
É realizado o levantamento dos
requisitos e armazenado na lista de
funcionalidades, com o cliente priorizado
as funcionalidades.
Atende
GRE2 - O comprometimento da equipe técnica
com os requisitos aprovados é obtido.
As aprovações das funcionalidades pela
equipe técnica ocorrem na etapa Planejar
por Funcionalidade que é gerado o Plano
de Desenvolvimento revisado pelo
cliente e pelos membros da equipe.
Atende
GRE3 - A rastreabilidade bidirecional entre os
requisitos e os produtos de trabalho é
estabelecida e mantida.
Não
Atende
GRE4 - Revisões em planos e produtos de
trabalho do projeto são realizadas visando
identificar e corrigir inconsistências em relação
aos requisitos.
Na atividade inspeção de código e na de
testes de unidade, possibilita identificar
inconsistências, visando a entrega de uma
atividade de valor ao cliente.
Atende
GRE5 - Mudanças nos requisitos são
gerenciadas ao longo do projeto.
As alterações de requisitos podem
ocorrer no projeto, alterando, nesse caso,
o Plano de Desenvolvimento. As
mudanças nos requisitos são gerenciadas
através do controle das versões.
Atende
Parcial
Quadro 2: Descrição dos resultados esperados do processo de Gerência de requisito e o mapeamento na FDD
Nível F – Processo Gerência de Configuração (GCO)
Tem propósito de estabelecer e manter a integridade de todos os produtos.
Processo Gerência de Configuração (GCO) FDD Critério
GCO1 - Um Sistema de Gerência de
Configuração é estabelecido e mantido.
É realizado o gerenciamento de
configurações durante o controle de
versões do projeto de software.
Atende
GCO2 - Os itens de configuração são
identificados com base em critérios
estabelecidos.
No Processo Detalhar por
funcionalidade, os diagramas de classe,
métodos, atributos são identificados para
controle de versão.
Atende
GCO3 - Os itens de configuração sujeitos a um
controle formal são colocados sob baseline.
Não
atende
GCO4 - A situação dos itens de configuração e
das baselines é registrada ao longo do tempo e
disponibilizada.
Os proprietários das classes escrevem os
prefácios sobre suas classes e as mesmas
são publicadas na intranet.
Atende
GCO5 - Modificações em itens de configuração
são controladas.
Fica sob a responsabilidade do
programador líder fazer as alterações.
Atende
GCO6 - Todos os produtos de trabalho que
forem itens de configuração, tanto de projetos
quanto de processos, são armazenados no
sistema de Gerência de Configuração.
Diagrama de sequência, métodos,
atributos, parâmetros, tipos de retorno,
exceções e mensagens são submetidos a
um controle de versão.
Atende
GCO7 - Auditorias de configuração são
realizadas objetivamente para assegurar que as
baselines e os itens de configuração estejam
íntegros, completos.
Não
Atende
Quadro 3: Descrição dos resultados esperados do processo de Gerência de Configuração e o mapeamento na FDD
Nível F – Processo Garantia da Qualidade (GQA)
O propósito do processo Garantia da Qualidade. Este processo compreende os
resultados esperados:
Processo Garantia da Qualidade (GQA) FDD Critério
GQA1 - A aderência dos produtos de trabalho,
os padrões, procedimentos e requisitos
aplicáveis são avaliados objetivamente antes
dos produtos serem entregues ao cliente e em
marcos predefinidos ao longo do ciclo de vida
do projeto.
O produto concluído passa pelo teste e
inspeção que são feitos por membros da
equipe ou outros membros do projeto,
que tem sua data (mês e ano) para a
entrega de cada atividade de negócio.
Atende
GQA2 - A aderência dos processos executados,
as descrições de processo, padrões e
procedimentos são avaliados objetivamente.
Atende
GQA3 - Os problemas e as não-conformidades
são identificados, registrados e comunicados.
As não-conformidades são recolocadas
no plano de desenvolvimento e é
verificado se isso irá trazer impacto no
cronograma. Se ocorrer, o plano é
readequado.
Atende
Parcial
GQA4 - Ações corretivas para as não-
conformidades são estabelecidas e
acompanhadas até as suas efetivas conclusões.
As correções dos problemas são
identificadas na inspeção e nos testes do
código.
Atende
Parcial
Quadro 4: Descrição dos resultados esperados do processo da Garantia da Qualidade e o mapeamento na FDD
Nível F – Processo Medição (MED)
O propósito do processo Medição é coletar, analisar e relatar as atividades
desenvolvidas, o processo possui os seguintes resultados esperados:
Processo Medição (MED) FDD Critério
MED1 - Objetivos de medição são
estabelecidos e mantidos a partir dos objetivos
da organização e das necessidades de
informação.
O painel de progresso (Parking Lot)
apresenta informação do andamento das
atividades. Atende
Parcial
MED2 - Um conjunto adequado de medidas,
orientado pelos objetivos de medição, é
identificado e definido, priorizado,
documentado, revisado e, quando pertinente,
atualizado.
As medições dos processos são
estabelecidas nos (Milestone), cada um
com um peso em relação à
funcionalidade que são: Estudo dirigido
da funcionalidade 1%, Desenho 40%,
Inspeção de Desenho 3%, Codificação
45%, Inspeção do Código10% e
Promover para Build 1%.
Atende
MED3 - Os procedimentos para a coleta e o
armazenamento de medidas são especificados.
É estabelecido o processo de medição
das funcionalidades (Milestone).
Atende
Parcial
MED4 - Os procedimentos para a análise das
medidas são especificados, após escolha de uma
métrica em MED2, têm que ser documentadas
as atividades e responsabilidades pela análise
das medições e como os resultados serão
comunicados.
Os programadores chefe e o gerente de
desenvolvimento ficam com a
responsabilidade de coletar e analisar as
features.
Atende
MED5 - Os dados requeridos são coletados e
analisados.
Os dados coletados são analisados e
atualizados no quadro de tarefas no
processo Construir por Funcionalidade.
Atende
MED6 - Os dados e os resultados de análises
são armazenados.
As informações são coletadas com os
proprietários das classes para medirem o
andamento da funcionalidade.
Atende
MED7 - As informações produzidas devem ser
comunicadas para os usuários das medições,
apoiando-os nos processos de tomada de
decisão.
Há uma preocupação com o
armazenamento da coleta dos dados para
serem usados como apoio de decisões.
Atende
Parcial
Quadro 8: Descrição dos resultados esperados para o processo de Medição e o mapeamento na FDD
Portanto neste mapeamento foi visto 40 resultados esperado nos processos dos
níveis G e F do MPS.BR, dos quais de acordo com os critérios pré-estabelecidos, foram
distribuídos da seguinte forma: Atende com 24, Atende Parcial com 12, Não Atende
finalizando com 04, ao qual é demostrada no gráfico abaixo.
Figura 4: Gráfico do Resultado do Mapeamento.
Processo Resultados
Esperados
Atende Não
Atende
Atende
Parcial
Gerência de Projetos (GPR) 17 10 1 6
Gerência de Requisitos (GRE) 5 3 1 1
Gerência de Configuração (GCO) 7 5 2 0
Garantia da Qualidade (GQA) 4 2 0 2
Medição (MED) 7 4 0 3
Quadro 9: Resumo dos resultados esperados com a distribuição nos critérios pré-
estabelecido.
No quadro 9, demostra o resumo do mapeamento dos resultados esperados do
MPSBR com as praticas da FDD em relação aos critérios de classificar, assim fica
transparente a real contribuição da FDD, expondo a forma com que as práticas se
relacionam com o com MPS.BR
7. Conclusões
Este artigo realizou, como alvo principal, o Mapeamento dos resultados esperados entre
o modelo MPS.BR apenas nos níveis G e F com a FDD, a qual possui as práticas e
tarefas similares, a FDD não cobre todas as atividades em total compatibilidade que é
exigida pela norma brasileira. Por esse motivo, a metodologia FDD vem ajudar e não
substituir as atividades esperadas pelo programa brasileiro.
Esta pesquisa analisou, em síntese, o conceito das normas já existentes no
mercado mundial, o CMMI e as ISO’s 12207 e 15504, no intuito de demonstrar a base
que é constituída o modelo MPS.BR, tornando-o aceitável no mercado brasileiro.
Conhecido como metodologia tradicional, também demonstrou o surgimento do
manifesto ágil em 2001 nos EUA, que, entre as metodologias ágeis, são abordadas as
características e práticas de engenharia de software da FDD que estimula agilidade da
produção com qualidade.
Na última seção deste artigo, foi demonstrado o mapeamento do MSPBR com a
FDD, onde ele é passível de interpretações. O trabalho proposto vem apresentar, em
forma de porcentagens, o quanto a FDD há de ajudar nas tarefas requeridas, e sim,
demonstrar que existe uma alternativa viável para agilizar as atividades. Essa agilidade é
conseguida com várias das boas práticas que a FDD disponibiliza, são elas: modelo
ARO, papéis-chaves, dono do código FBS, Inspeções, builds regulares, demonstrável
para o cliente, utilização da UML em cores e outras.
Referências
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO “Guia Geral”, 2009. Disponível <http://www.softex.br/mpsbr/_guias
/guias/MPS.BR_Guia_Geral_2011.pdf >.Acessado em 21 de abril de 2011, 2011a.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO “Guia de Implementação – Parte 1: Fundamentação para
Implementação do Nível G do MR-MPS”, 2009. Disponível <http://www.softex.br
/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_1_2011.pdf >.Acessado
em Julho de 2011 de 2010, 2011b.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO “Guia de Implementação – Parte 2: Fundamentação para
Implementação do Nível F do MR-MPS”, 2009. Disponível <http://www.softex.br
/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_2_2011.pdf>.Acessado
em 25 de Julho de 2011, 2011c.
AGILCOOP, Cooperativa de Desenvolvimento Ágil de Software, “Empresas Ágeis no
Brasil”. 2011. Disponível em < http://ccsl.ime.usp.br/agilcoop/empresas_ageis >
Acessado em: 23/08/2011
BECK, K at all. “Manifesto para Desenvolvimento Ágil de Software”.2001.
Disponível em: < http://agilemanifesto. org/iso/ptbr/.> Acesso em: 09/08/2011.
BUBLITZ, Jorge Luiz “FDD - Feature-Driven Development - Desenvolvimento ágil
dirigido a funcionalidades”,2011, Disponível em <http://www.slideshare.net/brjedi
/aula-fdd-cesar-recife-gap > Acessado em: 09 Out. 2011
COAD, Peter; LEFEBVRE, Eric.; LUCA , Jeff de “Java Modeling In Color With
UML: Enterprise” Components and Process. Prentice Hall, 1999
FERREIRA, Adson Wendel Cirilo. “Melhoria de processo de software brasileiro
aplicado no nível de maturidade f em uma empresa alagoana desenvolvedora de
software”.Disponível em <http://www.slideshare.net/adsonwendel/melhoria-de-
processo-de-software-brasileiro-aplicado-no-nvel-de-maturidade-f-em-uma-empresa-
alagoana-desenvolvedora-de-software-8534557> Acessado em: 12 junho 2010.
LUCA, Jeff de “The Original FDD Processes”.1998, Disponível em
<http://www.nebulon. com/articles/fdd/originalfdd.html>. Acesso em 05 Mai. 2011.
GUSMÃO, Cristine Gomes de; MOURA, Hermano Perrelli. Gerência de Risco em
Processos de Qualidade de Software: Uma análise Comparativa. 2004. P.6
Disponível em <http://www.cefetrn.br/~placido/disciplina/pgp/material/sbqs05_
Gusmao.pdf>Acessado em: 19 de Mar 2010
MEDEIROS, Manoel Pimentel. “FDD - O ponto de Equilíbrio Ágil ”. In Artigo Java
Magazine 76, Para projetos de desenvolvimento de software em ambientes corporativos
complexos, 2011 Disponível em < http://www.devmedia.com.br/post-15854-FDD-O-
ponto-de-Equilibrio-Agil.html> Acessado em: 09 Out. 2011
PÊSSOA, Marcelo Schneck de Paula. Modelo Integrado de Maturidade da
Capacidade de Processo. Lavras: UFLA/FAEPE, 2005.
RETAMAL, Adail Muniz “Feature-Driven Development - Descrição dos Processos”,
2008, Dispoível em < http://www.heptagon.com.br/files/FDD-Processos.pdf > Acessado
em: 09 Out. 2011. 2008a
RETAMAL, Adail Muniz “Metodologias de Desenvolvimento: UDP, FDD e XP”,
2008, Disponível em <http://adailmr.sites.uol.com.br/artigos/fdd-udp-xp.htm> Acessado
em: 09 Out. 2011. 2008b
REZENDE, Denis Alcides. Engenharia de Software e sistemas de informação. 2. ed.
Rio de Janeiro: Brasport, 2002.
SOARES, Michel dos Santos. “Comparação entre Metodologias Ágeis e
Tradicionais para o Desenvolvimento de Software”.2009. Disponível em <
http://www.inf.ufrgs.br/~dsogari/material/S5/INF01127/Material/Comparacao-Metodos-
Ageis-Tradicionais .pdf> Acessado em: 21 Mai. 2011
WEBER, Kival C.; ROCHA, Ana Regina; ALVES, Ângela; AYALA, Arnaldo M.;
GONÇALVES, Austregésilo; PARET, Benito; SALVIANO, Clênio; MACHADO,
Cristina F.; SCALET, Danilo; PETIT, Djalma; ARAÚJO, Eratóstenes; BARROSO,
Márcio Girão; OLIVEIRA, Kathia;OLIVEIRA, Luiz Carlos A.; AMARAL, Márcio P.;
CAMPELO, Renata Endriss C.; MACIEL,Teresa. Modelo de Referência para
Melhoria de Processo de Software: uma abordagem brasileira. Disponível em <
http://pos.facom.ufu.br/~willian/uniube/eng_software/arteng2.pdf.> Acessado em: 20
Jan. 2010, 2004.
Weber, K. C., Rocha, A. R., Alves, A., Ayala, A. M., Gonçalves, A., Paret, P., Salviano,
C., Machado, C. F., Scalet, D., Petit, D., Araújo, E., Barroso, M. G., Oliveira, K.,
Oliveira, L. C.A., Amaral, M. P., Campelo, R. E. C., Maciel, T. “Modelo de Referência
para Melhoria de Processo de Software: uma abordagem brasileira”, In: XXX
Conferencia Latinoamericana de Informatica (CLEI 2004). Arequipa, Peru: Septiembre
2004.

Mais conteúdo relacionado

Mais procurados

Enegep2002 tr10 1133
Enegep2002 tr10 1133Enegep2002 tr10 1133
Enegep2002 tr10 1133
Caco Ramos
 
Trabalho qualidade de_software
Trabalho qualidade de_softwareTrabalho qualidade de_software
Trabalho qualidade de_software
stefaniak2004
 
Es17 predicao de defeitos em software
Es17   predicao de defeitos em softwareEs17   predicao de defeitos em software
Es17 predicao de defeitos em software
Victor Hugo
 

Mais procurados (20)

UM ESTUDO SOBRE SOA
UM ESTUDO SOBRE SOAUM ESTUDO SOBRE SOA
UM ESTUDO SOBRE SOA
 
MPS.BR - Melhoria de Processo de Software Brasileiro
MPS.BR - Melhoria de Processo de Software BrasileiroMPS.BR - Melhoria de Processo de Software Brasileiro
MPS.BR - Melhoria de Processo de Software Brasileiro
 
MPS.BR
MPS.BRMPS.BR
MPS.BR
 
Luke artigo sobre_o_framework_petic- final
Luke artigo sobre_o_framework_petic- finalLuke artigo sobre_o_framework_petic- final
Luke artigo sobre_o_framework_petic- final
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
 
Enegep2002 tr10 1133
Enegep2002 tr10 1133Enegep2002 tr10 1133
Enegep2002 tr10 1133
 
Slide sobre o estudo do MPS.BR
Slide sobre o estudo do MPS.BRSlide sobre o estudo do MPS.BR
Slide sobre o estudo do MPS.BR
 
MPS.BR - Melhoria do processo de Software Brasileiro
MPS.BR - Melhoria do processo de Software BrasileiroMPS.BR - Melhoria do processo de Software Brasileiro
MPS.BR - Melhoria do processo de Software Brasileiro
 
Trabalho qualidade de_software
Trabalho qualidade de_softwareTrabalho qualidade de_software
Trabalho qualidade de_software
 
Mps.br
Mps.brMps.br
Mps.br
 
Engenharia de Software
Engenharia de SoftwareEngenharia de Software
Engenharia de Software
 
Revista Engenharia de Software n° 44
Revista Engenharia de Software n° 44Revista Engenharia de Software n° 44
Revista Engenharia de Software n° 44
 
Es17 predicao de defeitos em software
Es17   predicao de defeitos em softwareEs17   predicao de defeitos em software
Es17 predicao de defeitos em software
 
Artigo Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia ...
Artigo Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia ...Artigo Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia ...
Artigo Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia ...
 
Analise essencial 2
Analise essencial 2Analise essencial 2
Analise essencial 2
 
Engenharia de software
Engenharia de softwareEngenharia de software
Engenharia de software
 
Artigo jad utfpr
Artigo jad utfprArtigo jad utfpr
Artigo jad utfpr
 
Documento de requisitos
Documento de requisitosDocumento de requisitos
Documento de requisitos
 
MPS.BR
MPS.BRMPS.BR
MPS.BR
 
O emprego do_rup_na_uml_-_trabalho_poo_2012
O emprego do_rup_na_uml_-_trabalho_poo_2012O emprego do_rup_na_uml_-_trabalho_poo_2012
O emprego do_rup_na_uml_-_trabalho_poo_2012
 

Semelhante a MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE MATURIDADE G E F

Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
ingrid_fatec
 
Processos de software
Processos de softwareProcessos de software
Processos de software
Dann Volpato
 
Apresentação-07JUN10-MPS.BR-SBQS-2010 (1).ppt
Apresentação-07JUN10-MPS.BR-SBQS-2010 (1).pptApresentação-07JUN10-MPS.BR-SBQS-2010 (1).ppt
Apresentação-07JUN10-MPS.BR-SBQS-2010 (1).ppt
DETUDOUMPOUCO42
 
Mps br final - mps
Mps br final - mpsMps br final - mps
Mps br final - mps
Edvaldo Cruz
 

Semelhante a MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE MATURIDADE G E F (20)

MPS.BR - Melhoria de Processos do Software Brasileiro
MPS.BR - Melhoria de Processos do Software BrasileiroMPS.BR - Melhoria de Processos do Software Brasileiro
MPS.BR - Melhoria de Processos do Software Brasileiro
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
 
Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?Como especificar requisitos em metodologias ágeis?
Como especificar requisitos em metodologias ágeis?
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
RAD - Métodos ágeis
RAD - Métodos ágeisRAD - Métodos ágeis
RAD - Métodos ágeis
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
 
Apresentação TCC I - IES/SC 2013
Apresentação TCC I - IES/SC 2013Apresentação TCC I - IES/SC 2013
Apresentação TCC I - IES/SC 2013
 
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
Artigo   asap - metodologia de gestão de projetos para implementação de pacot...Artigo   asap - metodologia de gestão de projetos para implementação de pacot...
Artigo asap - metodologia de gestão de projetos para implementação de pacot...
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Mps.br guia de_implementacao_parte_5_2016
Mps.br guia de_implementacao_parte_5_2016Mps.br guia de_implementacao_parte_5_2016
Mps.br guia de_implementacao_parte_5_2016
 
Apresentação-07JUN10-MPS.BR-SBQS-2010 (1).ppt
Apresentação-07JUN10-MPS.BR-SBQS-2010 (1).pptApresentação-07JUN10-MPS.BR-SBQS-2010 (1).ppt
Apresentação-07JUN10-MPS.BR-SBQS-2010 (1).ppt
 
Mps br final - mps
Mps br final - mpsMps br final - mps
Mps br final - mps
 
Artigo corrigido
Artigo corrigidoArtigo corrigido
Artigo corrigido
 
Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
 
Mpsbr
MpsbrMpsbr
Mpsbr
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
PDF - Projeto de Pesquisa: MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICA...
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
 
Estudo empírico da metodologia do desenvolvimento ágil de software
Estudo empírico da metodologia do desenvolvimento ágil de softwareEstudo empírico da metodologia do desenvolvimento ágil de software
Estudo empírico da metodologia do desenvolvimento ágil de software
 

Último

SEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptx
SEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptxSEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptx
SEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptx
avaseg
 

Último (8)

treinamento de moldagem por injeção plástica
treinamento de moldagem por injeção plásticatreinamento de moldagem por injeção plástica
treinamento de moldagem por injeção plástica
 
SEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptx
SEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptxSEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptx
SEG NR 18 - SEGURANÇA E SAÚDE O TRABALHO NA INDUSTRIA DA COSTRUÇÃO CIVIL.pptx
 
ATIVIDADE 1 - FSCE - FORMAÇÃO SOCIOCULTURAL E ÉTICA II - 52_2024.pdf
ATIVIDADE 1 - FSCE - FORMAÇÃO SOCIOCULTURAL E ÉTICA II - 52_2024.pdfATIVIDADE 1 - FSCE - FORMAÇÃO SOCIOCULTURAL E ÉTICA II - 52_2024.pdf
ATIVIDADE 1 - FSCE - FORMAÇÃO SOCIOCULTURAL E ÉTICA II - 52_2024.pdf
 
CONCEITOS BÁSICOS DE CONFIABILIDADE COM EMBASAMENTO DE QUALIDADE
CONCEITOS BÁSICOS DE CONFIABILIDADE COM EMBASAMENTO DE QUALIDADECONCEITOS BÁSICOS DE CONFIABILIDADE COM EMBASAMENTO DE QUALIDADE
CONCEITOS BÁSICOS DE CONFIABILIDADE COM EMBASAMENTO DE QUALIDADE
 
ST 2024 Apresentação Comercial - VF.ppsx
ST 2024 Apresentação Comercial - VF.ppsxST 2024 Apresentação Comercial - VF.ppsx
ST 2024 Apresentação Comercial - VF.ppsx
 
Proposta de dimensionamento. PROJETO DO CURSO 2023.pptx
Proposta de dimensionamento. PROJETO DO CURSO 2023.pptxProposta de dimensionamento. PROJETO DO CURSO 2023.pptx
Proposta de dimensionamento. PROJETO DO CURSO 2023.pptx
 
Planejamento e controle da Produção_Lustosa.pdf
Planejamento e controle da Produção_Lustosa.pdfPlanejamento e controle da Produção_Lustosa.pdf
Planejamento e controle da Produção_Lustosa.pdf
 
Normas Técnicas para aparelho de solda oxi-acetileno.pdf
Normas Técnicas para aparelho de solda oxi-acetileno.pdfNormas Técnicas para aparelho de solda oxi-acetileno.pdf
Normas Técnicas para aparelho de solda oxi-acetileno.pdf
 

MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE MATURIDADE G E F

  • 1. C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE ADSON WENDEL CIRILO FERREIRA MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE MATURIDADE G E F Recife 2011
  • 2. ADSON WENDEL CIRILO FERREIRA MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE MATURIDADE G E F Monografia apresentada ao programa de Especialização em Engenharia de Software do Centro de Estudos e Sistemas Educacionais do Recife – C.E.S.A.R, como requisito para a obtenção do título de Especialista em Engenharia de Software com ênfase em Gestão Ágil de Projetos. Orientação: Prof. Jorge Luiz Bublitz Recife 2011
  • 3. Mapeamento entre a metodologia ágil FDD e o Modelo de Qualidade MPS.BR nos Níveis de Maturidade G e F Adson Wendel Cirilo Ferreira1 , Jorge Luiz Bublitz2 1 C.E.S.A.R – Centro de Estudos e Sistemas Avançados do Recife Adson_wendel@hotmail.com 2 E.S.A.B - Escola Superior Aberta do Brasil bublitz@hotmail.com Resumo. O MPS.BR, é uma avaliadora da qualidade de software e serviços relacionados, utiliza padrões e características semelhantes ao modelo CMMI e nas normas ISO/IEC 12207 e na ISO/IEC 15504, visando as empresas desenvolvedoras de software, que seja certificada na norma brasileira, este artigo baseando-se na FDD, vem com o objetivo de ajudar as empresas a definirem um processo ágil e ganharem mais velocidades nos processos dos resultados esperados desta certificação, assim tornando-se ainda mais competitiva no mercado de software. 1. Introdução O MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa brasileiro que apresenta um padrão de qualidade fundamentado no CMMI (Capability Maturity Model Integration) e nas ISO's 12207 e 15504, o qual é responsável em avaliar não só a qualidade e a produtividade de software, mas também serviços relacionados a ele. Para uma empresa que trabalha visando alcançar os resultados esperados do modelo de maturidade brasileiro. Seu principal objetivo é traçar os resultados esperados a serem trabalhados de maneira produtiva e eficiente para o desenvolvimento de um software que busca sempre um melhoramento geral, voltando-se à condição do mercado brasileiro, para o alcance das empresas públicas e privadas de vários tamanhos, onde a maior atenção é para as micros, pequenas e médias empresas, segundo a SOFTEX (2011a) “de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software” por esses motivos o MPS.BR é modelo escolhido para este artigo. O Manifesto Ágil, resultado de uma reunião realizada em 2001 nos EUA, que teve a participação de dezessete especialistas da engenharia e desenvolvedores de software, Agile Manifesto (2004) relata que “Como seria difícil outra reunião com estes anarquistas organizacionais, o que resultou foi o simbólico – Manifesto do Desenvolvimento Ágil de Software – assinado por todos participantes.”, Relata Soare(2009) que a agile manifesto importando-se com “os indivíduos e interações,
  • 4. com o software estar executável, com a colaboração do cliente e as respostas rápidas a mudanças e alterações”. Diante disso, os modelo, MPS.BR e CMMI, e as normas, ISO (Institute of Organization for Standardization) 12207 e 15504, são conhecida como metodologias tradicionais, segundo Soares (2009) “Processos orientados a documentação para o desenvolvimento de software são, de certa forma, fatores limitadores aos desenvolvedores”, chegando a prorrogar a criação dos processos mais complexos, retardando as entregas. Com base no novo pensamento agilista, este trabalho propõe ajudar uma empresa a se tornar mais competitiva, aumentar ainda mais sua visibilidade no mercado e ganhar mais velocidade nos processos requeridos pela norma de maturidade, baseando-se na metodologia de gerenciamento e engenharia de software, a FDD(Feature Driven Development), que é utilizada de forma iterativa e incremental com práticas ágeis. 1.1 Objetivo O objetivo principal deste artigo é o mapeamento dos resultados esperados do modelo MPS.BR dos níveis G e F com as práticas da FDD que satisfaça as necessidades de cada resultado. As áreas de processos que serão utilizadas no modelo brasileiro são: Gerência de Projetos, Gerência de Requisito, Gerência de Configuração, Garantia da Qualidade e Medição. Os processos de Aquisição e Gerência de Portfólio de Projetos não são contemplados. No intuito de consolidar o artigo, foi feita uma revisão bibliográfica no Manifesto ágil, na FDD, no MPS.BR e suas bases estruturais, que é a ISO 12207, a 15504 e o CMMI. 1.2 Justificativa A competitividade entre as organizações desenvolvedoras de software fez com que os clientes ficassem mais rigorosos na qualidade dos produtos por elas produzidos, onde as empresas podem comprovar com uma Certificação MPS.BR, programa que avalia a qualidade e serviços relacionados a software, que é direcionado a real situação do mercado brasileiro, no intuito do alcance das empresas públicas e privadas, com maior atenção as micros, pequenas e médias empresas. O MPS.BR utiliza uma metodologia tradicional segundo Soares (2009) “conhecidas também como pesadas ou orientadas a planejamentos”. Através dele, as atividades são orientadas a documentação para o desenvolvimento de software, que de certa forma limita o desenvolvimento dos processos mais complexos. O foco deste artigo são as empresas que seja certificado no (MPS.BR) , com real contribuição que a FDD tem para agilizar os resultados esperados pelo modelo brasileiro. Com isso, tais empresas ganham mais velocidade nos processos, tornando-se ainda mais competitivas no mercado de software, através da utilização de uma das metodologias (FDD) que foi associada ao manifesto ágil.
  • 5. 1.3 Estrutura da Monografia Este artigo está organizado na seguinte forma: Na seção 2, foi feita uma abordagem sobre as bases da estrutura do modelo brasileiro MPS.BR, delimitando em resumos a ISO/IEC 12207 e sua evolução, a ISO/IEC 15504 e o CMMI, descrevendo suas origens e seus desenvolvedores. Foi apresentado, também em síntese, o conceito e as características de cada norma de melhoria de processo de software; Na seção 3, foi realizada uma abordagem sobre o programa MPS.BR, apresentando informações essenciais sobre o modelo de Referência (MR-MPS), aprofundando as informações para os níveis de maturidade G e F, com intuito de delimitar o tema deste artigo; Na seção 4, foi abordado o surgimento do manifesto ágil, os seus conceitos, princípios, os profissionais e as metodologias envolvidas; Na seção 5, foi comentada a criação da FDD, seu conceito, características, modelo ARO, algumas das práticas mais usadas, principais papéis e os cinco processos principais; Na seção 6, foi apresentado um mapeamento conciso entre o modelo MPS.BR com os resultados esperados dos níveis de maturidades G e F que possuem atividades similares na FDD; Na seção 7, foi apresentada uma conclusão analítica sobre o artigo. 2. Base da Estrutura do Modelo MPS.BR 2.1 ISO/IEC 12207 A norma ISO/IEC 12207 foi criada pela ISO e IEC para solucionar um problema de modelagem e melhoria no processo de software, e segundo Gusmão & Moura (2004) “é a primeira norma internacional que descreve em detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de software” localizando-se entre as mais antigas normas que definem os processos de desenvolvimento da área. Weber (2004) afirma que “a norma foi publicada internacionalmente em 1995, e no Brasil em 1998”. Segundo Gusmão & Moura (2004) “Essa norma divide os processos em três grandes classes: Processos Fundamentais, Processos de Apoio e Processos Organizacionais”, cada classe com suas atividades. O objetivo fundamental do modelo é instalar uma base comum para os processos de ciclo de vida e de desenvolvimento do software, estruturada para ser flexível, sem ligações com treinamentos, ferramentas, métodos e linguagens de desenvolvimento. Segundo Ferreira (2010; p18) a norma “possibilita um acompanhamento da evolução da engenharia de software e de organizações com culturas distintas, flexibilidade importante, pois implica no “o que fazer” e não ficando refém de “como fazer””.
  • 6. 2.2 ISO/IEC 15504 Também conhecida como SPICE e evoluída da ISO 12207, é uma norma de processos de desenvolvimento de software que teve uma versão aprovada em 1998, que, em união com a comunidade internacional e através do projeto SPICE, foi publicada em 2003 pela ISO. Nela é descrito um conjunto de processos considerados universais e fundamentais para que se possa ter um planejamento e desenvolvimento com qualidade, visando a melhoria dos processos da criação do software. As organizações podem solicitar certificação de capacidade específica em áreas determinadas, sabendo assim quais partes da organização terão que ser feitas melhorias e quais características manter. Segundo Weber et al. (2004; p6) “a organização pode realizar a avaliação, gerando um perfil dos processos que será usado para a elaboração de um plano de melhorias”, das quais a empresa deve continuar sempre a manter, sem perder a qualidade e o foco no cliente. 2.3 CMMI É uma modelo de certificação de qualidade empregada no intuito de avaliar as melhorias na maturidade dos processos em desenvolvimento de software e serviços correspondentes, com origem no ano de 1980, nos Estados Unidos, com implantação do projeto desenvolvido pelo SEI(Software Engineering Institute). Segundo Pessôa (2005) “O desenvolvimento desse modelo foi financiado pelo departamento de defesa americano, com o objetivo de estabelecer um padrão de qualidade para software desenvolvido para as forças armadas”. Com essa norma de avaliação, seria possível mensurar os processos desenvolvidos de software das organizações que concorriam pela licitação, tendo em vista as indicações, valor do produto, qualidade, garantia de prazos de entrega e dos projetos contratados. Embora iniciada para projetos militares, é válida para todo tipo de projetos de software. Rezende (2002) afirma que “os principais objetivos do CMMI são auxiliar as empresas a conhecerem e melhorarem seus processos de desenvolvimento e manutenção de software, fornecendo uma estrutura conceitual para guiar as empresas para obterem controles de seus processos, com melhoria contínua de seus produtos de software”. O CMMI é dividido em níveis de maturidade. Segundo Gusmão & Moura (2004) O SW-CMM foi o primeiro modelo desenvolvido na área de maturidade e capacidade, o qual apresenta cinco níveis de maturidade, onde o mais avançado corresponde a uma maior maturidade do processo que está associado a uma maior produtividade, qualidade e a um menor risco organizacional. As graduações crescentes são: inicial, repetível, definido, gerenciado e otimização. 3 MPS.BR O modelo MPS.BR tem como objetivo a melhoria de processo de software, manejando a empresa buscar a seus produtos desenvolvidos e serviços relacionados com qualidade. Weber (2004, P3) afirma que “O Projeto MPS.Br visa a melhoria de processos de software em empresas brasileiras a um custo acessível, especialmente na grande massa de micro, pequenas e médias empresas”. É um projeto brasileiro empregado, igualmente, para organizações públicas e privadas, com padrão e qualidade das normas de desenvolvimento internacionais.
  • 7. Figura 1: Estrutura do projeto MPS.BR Fonte: SOFTEX <http://www.softex.br/portal/softexweb/uploadDocuments/sbes2011_ melhoria_processo_folder_com_quadro_a4.pdf > A figura 1 exibe a estrutura do projeto MPS.BR, as suas bases de sustentação nas normas internacionais da ISO/IEC 12207 e ISO/IEC 15504 e o modelo CMMI, apresentando o conjunto do projeto com as respectivas funções. No guia geral, são demonstrada as informações do modelo de Referência (MR-MPS), níveis, resultados esperados e outros; no guia de aquisição, são mencionados os processos de aquisição de software e serviços correlatos; no guia de avaliação, é apresentado o método de avaliação (MA-MPS), mencionando as informações necessárias para o entendimento dos processos avaliativos; e no documento de programa, são apresentadas as informações sobre o modelo de negócio (MN-MPS). Figura 2: Comparação dos Níveis de Maturidade do modelo MPS.BR com o modelo CMMi Fonte: SOFTEX < http://www.softex.br/portal/softexweb/uploadDocuments/MN-MPS.pdf> Na figura 2, são apresentados os níveis de maturidade do modelo de referência. Segundo a SOFTEX (2011a) são “A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F(Gerenciado) e G (Parcialmente Gerenciado)”. Nos níveis de maturidades, serão mais detalhados o G e F. 3.1 G - Parcialmente Gerenciado Por ser o primeiro nível de maturidade a implantar as melhorias dos processos de software em uma empresa, requer cautela para mudar a cultura da organização para a melhoria de processo e para a definição de projeto. A SOFTEX (2011b, pag. 6) relata
  • 8. que “porventura, a organização possuir processos já definidos e os projetos necessitarem adaptar os processos existentes, tal fato deverá ser declarado durante o planejamento do projeto”. Essas adaptações podem incluir alteração em processos, atividades, ferramentas, técnicas, procedimentos, padrões, medidas, dentre outras. 3.1.1 Gerência de Projetos O guia específico do nível de maturidade G da SOFTEX (2011b) afirma que “O propósito do processo de Gerência de Projetos é estabelecer e manter planos que definam as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o seu andamento”. Ao acumular os níveis de maturidades, alguns resultados esperados são incorporados e outros sofrem modificações. 3.1.2 Gerência de requisito Na gerência de requisito, o objetivo do processo é o controle e a evolução dos requisitos, vindos de análise junto ao cliente ou gerados pelo projeto, sempre documentando as mudanças dos requisitos e seus motivos. Segundo a SOFTEX (2011b) “O propósito do processo e Gerência de Requisitos é gerenciar os requisitos e os componentes do produto do projeto, identificar inconsistências entre os requisitos, planos e produtos de trabalho do projeto”. 3.2 F – Gerenciado No nível de maturidade F, o principal foco é nos processos para a gestão do projeto, “[...] no que diz respeito à Garantia da Qualidade (GQA) e Medição (MED), bem como aqueles referentes à organização dos artefatos de trabalho por meio da Gerência de Configuração (GCO)” relata a SOFTEX (2011c). 3.2.1 Gerência de Configuração Sua principal atuação ocorre durante o processo de auxiliar no controle e acompanhamento, manter a integridade do projeto e suas funcionalidades, sendo fundamental prover o controle sobre os trabalhos desenvolvidos e modificados. A SOFTEX (2011c) afirma que “em determinados momentos do ciclo de vida do desenvolvimento e manutenção do software, esses itens de configuração são agrupados e verificados, constituindo configurações do software, voltadas para propósitos específicos, denominadas baselines”, assim ficam delegados conjuntos de itens de configuração. 3.2.2 Garantia da Qualidade Com a finalidade em confirmar que o produto desenvolvido ou serviços estão em conformidades com os processos traçados no plano do projeto, exibe visibilidade do projeto e apoia à gerência. De acordo com a SOFTEX (2009e) “A pessoa ou grupo que executa a atividade de garantir a qualidade de processos e produtos tem uma
  • 9. responsabilidade delicada, pois fiscaliza se as pessoas estão desempenhando adequadamente as suas tarefas e seguindo os procedimentos estabelecidos”. Para isso, é necessário que os responsáveis tenham autoridade para executar seu trabalho, documentarem não conformidade do projeto, cobrarem a correção dos artefatos encontrados, promoverem feedback da verificação realizada para a gerência e equipe de projeto. 3.2.3 Medição Segundo a SOFTEX (2009e) “O propósito do processo Medição é coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais”. A medição é muito utilizada para o auxílio da tomada de decisão da gerência 4 Manifesto Ágil Em 2001, nos EUA, em uma reunião que discutiu formas de melhorar o desempenho de projetos de softwares, surgindo assim a Aliança do Desenvolvimento Ágil de Software. onde 17 desenvolvedores assinantes, principais profissionais experientes e reconhecidos “gurus” desenvolvedores na área de engenharia de softwares, foram: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas, os quais têm o objetivo de ajudar outras pessoas com os métodos ágeis a crescerem seus próprios conhecimentos, segundo Agile Manifesto(2004) “Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.” Na elaboração do manifesto ágil, foram envolvidas várias metodologias ágeis: XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), Família Crystal, ASD (Adaptive Software Development), SCRUM e FDD (Feature-Driven Development), das quais este artigo fará o mapeamento com os níveis G e F do MPS.BR. Os valores do desenvolvimento ágil, de acordo com o Agile Manifesto (2004), são: • Indivíduos e interações mais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação de contratos; • Responder a mudanças mais que seguir um plano. A utilização das metodologias ágeis já é um movimento que é fato no Brasil, onde vários projetos foram concluídos com êxito. AgilCoop (2011) lista algumas empresas: Objective Solutions, pioneira no uso de XP no Brasil; LocaWeb, utiliza Scrum e XP desde de 2007; Paggo, desenvolve software usando XP que também influencia no funcionamento da empresa; Improve It, consultoria em XP; Teamware,
  • 10. consultoria, mentoring e treinamento com Scrum Master e Scrum Leader e Neurobox com Scrum, XP e Lean, entre outras não citadas pelas empresas. 5 FDD Surgiu em 1997 em Singapura para solução de um projeto de software de empréstimo para uma instituição bancária, segundo Retamal (2008b) “a partir de técnicas de gerenciamento de projetos e de modelagem orientadas a objetos, Jeff De Luca era o gerente do projeto e Peter Coad foi contratado para fazer a modelagem do domínio do problema”, nascendo assim a FDD que equilibrava as metodologias prescritivas com as técnicas de De Luca e com as estratégias de Coad, propondo uma metodologia de desenvolvimento que atendesse a demanda de entrega de resultados frequentes e sem atrasos, a qual possui o lema “resultados frequentes, tangíveis e funcionais”. O projeto para a instituição bancária durou 15 meses e foi desenvolvido com 2000 feature por 50 pessoas. De acordo com Retamal (2008b) os responsáveis “lançaram as ideias no livro “Java Modeling in Color with UML” (1999). Posteriormente (2002), Stephen Palmer [...] e John Mac Felsing [...] lançaram “A Practical Guide to FDD”, com a descrição completa e atualizada da metodologia.” Bublitz (2011) afirma que a FDD “é uma metodologia iterativa e incremental de gerenciamento e engenharia de software, que combina as melhores práticas de outras abordagens ágeis com técnicas centradas no modelo”, com característica que enfatiza a qualidade durante o processo, entregas curtas e versões de software pequenas. Com o intuito de oferecer valor ao cliente, as features são desenvolvidas no máximo em duas semanas e segue o modelo ARO (Ação, Resultado e Objetivo). Medeiros (2011) explica que o modelo “Representa uma <Ação> necessária para atingir determinado <Resultado> de negócio envolvendo determinados <Objetos> de negócio, por exemplo: “<Autorizar> um <desconto> numa <venda>””. Os papéis chaves em um projeto FDD são divididos em funções e cargos, são eles: gerente de Projeto, líder administrativo e financeiro do projeto, o qual tem a palavra final no que se trata de escopo, cronograma e RH do projeto; arquiteto chefe, responsável pela modelagem do projeto; gerente de desenvolvimento, este lidera as atividades diárias do desenvolvimento, sendo responsável para solucionar conflitos dentro da equipe; programador chefe é o desenvolvedor experiente, presente nas fases de análise de requisitos e de modelagem de projetos, lidera pequenos times de desenvolvimento, seleciona as funcionalidades e os donos das classes para a próxima iteração; donos de classe, geralmente é um desenvolvedor que trabalha orientado pelo Programador Chefe, executando as tarefas de modelar, codificar, testar e documentar; e os especialistas no domínio de negócio, os quais são responsáveis em informar a equipe sobre o que deve ser implementado para que o software agregue valor. A FDD possui algumas práticas de engenharia de software com o objetivo de estimularem a produção com qualidade, entre elas: modelagem de objetos do domínio, desenvolvimento por feature, posse individual de classe (código), equipes de features, inspeções, builds regulares, demonstrável para o cliente; relatório/visibilidade de
  • 11. resultados e gerenciamento de configuração que acompanha todo o histórico do código- fonte. A FDD é uma metodologia muito objetiva que possui cinco processos, o qual é dividida em duas etapas, assim tornou esta metodologia escolhida para o mapeamento com o MPSBR neste artigo, a primeira é concepção e planejamento, que pensa no modelo e cria uma lista de feature e planeja através dela; a segunda é a construção, que é um desenvolvimento iterativo e incremental que dura no máximo duas semanas. Figura 3: Estrutura da FDD. Fonte: < http://www.heptagon.com.br/images/fdd.png > 5.1 Desenvolver um Modelo Abrangente Processo que é executado apenas uma vez em todo o Projeto, composto por um time de modelagem com especialistas de negócio, programadores e arquiteto líder. Luca (1998) relata que “É feito um estudo detalhado do escopo do sistema e seu contexto é executada, então são feitos estudos mais detalhados em cada área a ser modelada”. Em seguida são formados pequenos grupos por membros do domínio do negócio, os desenvolvedores criam seus modelos, os quais são estudados, revisados e discutidos, para através de um consenso escolher um ou mais modelos criados pelos grupos. 5.2 Construir uma lista de funcionalidades Também é um processo único executado no início do projeto, que visa satisfazer os requisitos e criar as funcionalidades. É composto por programadores líderes do processo anterior, onde o entendimento do escopo é ampliado através da descoberta das feature de cada área prioritária. Retamal (2008a) descreve que “para decompor funcionalmente o domínio em áreas, atividades de negócio dentro delas e passos dentro de cada atividade de negócio, formando assim a lista categorizada de funcionalidades”, é utilizada a prática de FBS (Feature Breakdown Structure) para ajudar a identificar as funcionalidades a desenvolver, segundo Medeiros (2011) “Organiza o entendimento sobre as áreas, as atividades de negócios e as funcionalidades de um produto” sobre uma leitura estruturada dos requisitos.
  • 12. Figura 4: Feature Breakdown Structure. Fonte: < http://agiles2008.agiles.org/common/pdfs/Pimentel%20-20Agil%20FDD.pdf> 5.3 Planejar por Feature Último processo da primeira etapa que, igualmente aos dois processos anteriores, é inicial e abrange todo o projeto onde são planejadas as sequências, nas quais as funcionalidades serão desenvolvidas, tendo como base para desenvolver as dependências entre classes, carga de trabalho e complexidade. A equipe é composta pelo gerente de desenvolvimento e pelos programadores líderes, de modo que, para cada atividade de negócio, o planejamento deve reportar uma data com mês e ano para a finalização. 5.4 Projetar por Feature Primeiro processo da etapa de construção, que tem seu ciclo renovado em todas as funcionalidades. Certas features são selecionadas e agendadas com uma data de finalização, consequentemente irá para desenvolvimento, criando uma “caixa de entrada”, podendo fazer uma junção de funcionalidades, chamada de pacote de trabalho. Segundo Luca (1998) “o programador chefe, forma uma equipe de recursos, identificando os proprietários das classes (desenvolvedores) que possam estar envolvidos no desenvolvimento desses recursos. Essa equipe então produz Vistas Cenário para o recurso atribuído”. Cada desenvolvedor produz então prefácios das classes e métodos para cada feature com seus diagramas de classes e de sequências que servirão de base para o programador líder refinar o modelo de objetos que serão submetidos ao sistema de controle de versões. A atividade de projetar por feature pode ou não utilizar UML em cores, no intuito de auxiliar no entendimento das features. O programador líder pode fazer inspeção no projeto com os membros da equipe de funcionalidades ou com outros membros do projeto. De acordo com Medeiros (2011) “a UML em cores foi inicialmente posta por Peter Coad, e teve grande contribuição de Eric Lefebvre e Jeff De Luca, os quais possuem vários anos de experiência em modelagem de aplicações para segmentos de variados tamanhos”. Para facilitar a identificação das construções das entidades, as categorias segundo o Coad (1999) são identificada da seguinte forma “Rosa: um momento ou intervalo de tempo. Amarelo: um papel a ser desempenhado por alguém ou algo. Azul: a entrada de catálogo-como a descrição. Verde: uma pessoa (partido), lugar ou coisa”.
  • 13. 5.5 Construir por Feature Processo onde é realmente desenvolvido o código fonte de cada feature, visando a entrega contínua com valor ao cliente. Luca (1998) relata que “Começando com o pacote de projeto, os proprietário das classes implementam os itens que serão necessários para que suas classes suportem o projeto para a sua funcionalidade.” e após passar pela inspeção de outra pessoa da equipe ou do projeto, a funcionalidade é levada a uma build. Cada funcionalidade é medida através de um gráfico constituído por seis marcos bem definidos, denominados milestones. A cada etapa cumprida, o percentual respectivo é agregado ao total de progresso e utilizado para o controle das features do painel de progresso (Parking Lot). 6 Mapeamentos entre FDD e MPS.BR. Neste capítulo será apresentado um mapeamento conciso entre o modelo MPS.BR com os resultados esperados dos níveis de maturidades G e F que possuem atividades similares na FDD, delimitando as áreas de processos do MPS.BR para gerência de projetos, gerência de requisito, gerência de configuração, garantia da qualidade e medição, não contemplando os processos de aquisição e gerência de portfólio de projetos, os quais não possuem práticas que a FDD atenda. A FDD não é condicionalmente compatível com os resultados esperados dos níveis do MPS.BR exposto neste artigo, por este motivo foram estabelecidos três critérios para classificar a equivalência entre da metodologia FDD e o modelo de qualidade brasileiro, primeiro critério, Atende, a prática da FDD está em plena conformidade; Atende Parcial, Algumas evidências são encontradas mas não satisfaz integralmente o que é solicitado; Não Atende, não há como a FDD ajudar com suas atividades. Processo Gerência de Projetos (GPR) O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades Processo Gerência de Projetos (GPR) FDD Critério GPR1 - O escopo do trabalho para o projeto é definido. O escopo é criado em duas etapas: Desenvolver o modelo abrangente e Construir a lista de funcionalidades. Atende GPR2 - As tarefas e Produtos são dimensionados, resultado de estimativa de tamanho, a dimensão das funcionalidades são contadas, classes, objetos. No processo Construir a Lista de Funcionalidades, ocorre a decomposição funcional das áreas do negócio definidas na primeira etapa. Atende GPR3 - As fases do ciclo de vida do projeto são definidas. Ocorre em duas etapas: Desenvolver o modelo abrangente e Construir a lista de funcionalidades, onde é decomposto em funcionalidades. Atende GPR4 - O esforço e o custo para a execução do projeto são estimados com base em dados históricos onde são recuperadas informações de tempo e complexidade. A estimativa de esforço encontra-se na etapa Planejar por Funcionalidade, onde são realizadas através da complexidade e experiências anteriores. Atende Parcial GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e No fim do processo Planejar por Funcionalidade é criado o Plano de Desenvolvimento, onde encontram-se: as Atende
  • 14. mantidos. features com suas dependências, a sequência de criação, as atividades de negócio com as datas de términos e os pontos de controle do cronograma. Parcial GPR6 - Os riscos do projeto são identificados, o seu impacto é documentado e os riscos são analisados e priorizados. O gerente de desenvolvimento tem o papel de ser o responsável pela resolução de riscos que possam vir a ocorrer dentro da equipe. As funcionalidades mais complexas de maiores riscos ficam sob a responsabilidade dos programadores chefe. Atende GPR7 - Os recursos humanos para o projeto são planejados considerando o conhecimento, habilidades e experiências possuídas. Os papéis são definidos e cada um tem suas funções e as atividades realizadas no processo Planejar por Funcionalidade, onde as pessoas da equipe são alocadas de acordo com as classes que lhes foram atribuídas. Atende GPR8 - Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados. O gerente de projeto é responsável por fornecer condições de trabalho adequadas para a equipe. Atende GPR9 - Os dados do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. São identificados em diagrama de classes (Modelo Abrangente de Dados), diagramas de sequência, de estado, de casos de uso entre outros; já o armazenamento é submetido a um controle de versão. Atende GPR10 - Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos. No plano de desenvolvimento contém atividades, onde os programadores líderes atribuem as funcionalidades das atividades de negócio aos seus respectivos desenvolvedores proprietários. Atende Parcial GPR11 - A viabilidade do projeto, considerando as restrições e os recursos disponíveis, é avaliada, se necessário, ajustes são realizados. Ainda no plano de desenvolvimento no processo Planejar por Funcionalidade são geradas atividades de negócio com datas de término, e o acompanhamento do projeto é revisto de acordo com as alterações junto ao cliente. Atende GPR12 - O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido. O processo Desenvolver o Modelo Abrangente é realizado por membros de domínio do negócio, por programadores e pelo arquiteto líder. Após construir a lista de features, o plano de desenvolvimento é criado. Este é revisado pelo cliente e pela equipe, todos se comprometendo. Atende Parcial GPR13 - O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto, e os resultados são documentados. No plano de desenvolvimento, contém as datas para as entregas das features. Ao fluir das atividades, as datas são comparadas. Atende Parcial GPR14 - O envolvimento das partes interessadas no projeto é gerenciado, informando em quais fases eles são importantes e como serão envolvidos. Todos os processos e as partes interessadas são planejados, Desenvolver o Modelo Abrangente com domínio do negócio, desenvolvedores e arquiteto líder. No processo Construir a Lista de Funcionalidades programadores líderes e Atende
  • 15. desenvolvimento assim sendo envolvidos. GPR15 - Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento. No plano de desenvolvimento, contemplam as datas de finalização. Nessas datas são realizadas inspeções do progresso das atividades e do projeto em relação ao planejado. Atende GPR16 - Registros de problemas identificados, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas. Não Atende GPR17 - Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas. No plano de desenvolvimento contem as lista de funcionalidades nas quais são realizadas inspeções e testes podendo identificar possíveis riscos que é de responsabilidade do gerente de projeto aplicar medidas que sanem problemas em desvios de planejamento. Atende Parcial Quadro1: Descrição dos resultados esperados do processo de Gerência de Projetos e o mapeamento na FDD Nível G – Processo Gerência de Requisitos (GRE) O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto. Ele possui os seguintes resultados esperados: Processo Gerência de Requisitos (GRE) FDD Critério GRE1 - Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos. É realizado o levantamento dos requisitos e armazenado na lista de funcionalidades, com o cliente priorizado as funcionalidades. Atende GRE2 - O comprometimento da equipe técnica com os requisitos aprovados é obtido. As aprovações das funcionalidades pela equipe técnica ocorrem na etapa Planejar por Funcionalidade que é gerado o Plano de Desenvolvimento revisado pelo cliente e pelos membros da equipe. Atende GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. Não Atende GRE4 - Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. Na atividade inspeção de código e na de testes de unidade, possibilita identificar inconsistências, visando a entrega de uma atividade de valor ao cliente. Atende GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto. As alterações de requisitos podem ocorrer no projeto, alterando, nesse caso, o Plano de Desenvolvimento. As mudanças nos requisitos são gerenciadas através do controle das versões. Atende Parcial Quadro 2: Descrição dos resultados esperados do processo de Gerência de requisito e o mapeamento na FDD
  • 16. Nível F – Processo Gerência de Configuração (GCO) Tem propósito de estabelecer e manter a integridade de todos os produtos. Processo Gerência de Configuração (GCO) FDD Critério GCO1 - Um Sistema de Gerência de Configuração é estabelecido e mantido. É realizado o gerenciamento de configurações durante o controle de versões do projeto de software. Atende GCO2 - Os itens de configuração são identificados com base em critérios estabelecidos. No Processo Detalhar por funcionalidade, os diagramas de classe, métodos, atributos são identificados para controle de versão. Atende GCO3 - Os itens de configuração sujeitos a um controle formal são colocados sob baseline. Não atende GCO4 - A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada. Os proprietários das classes escrevem os prefácios sobre suas classes e as mesmas são publicadas na intranet. Atende GCO5 - Modificações em itens de configuração são controladas. Fica sob a responsabilidade do programador líder fazer as alterações. Atende GCO6 - Todos os produtos de trabalho que forem itens de configuração, tanto de projetos quanto de processos, são armazenados no sistema de Gerência de Configuração. Diagrama de sequência, métodos, atributos, parâmetros, tipos de retorno, exceções e mensagens são submetidos a um controle de versão. Atende GCO7 - Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos. Não Atende Quadro 3: Descrição dos resultados esperados do processo de Gerência de Configuração e o mapeamento na FDD Nível F – Processo Garantia da Qualidade (GQA) O propósito do processo Garantia da Qualidade. Este processo compreende os resultados esperados: Processo Garantia da Qualidade (GQA) FDD Critério GQA1 - A aderência dos produtos de trabalho, os padrões, procedimentos e requisitos aplicáveis são avaliados objetivamente antes dos produtos serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do projeto. O produto concluído passa pelo teste e inspeção que são feitos por membros da equipe ou outros membros do projeto, que tem sua data (mês e ano) para a entrega de cada atividade de negócio. Atende GQA2 - A aderência dos processos executados, as descrições de processo, padrões e procedimentos são avaliados objetivamente. Atende GQA3 - Os problemas e as não-conformidades são identificados, registrados e comunicados. As não-conformidades são recolocadas no plano de desenvolvimento e é verificado se isso irá trazer impacto no cronograma. Se ocorrer, o plano é readequado. Atende Parcial GQA4 - Ações corretivas para as não- conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. As correções dos problemas são identificadas na inspeção e nos testes do código. Atende Parcial Quadro 4: Descrição dos resultados esperados do processo da Garantia da Qualidade e o mapeamento na FDD
  • 17. Nível F – Processo Medição (MED) O propósito do processo Medição é coletar, analisar e relatar as atividades desenvolvidas, o processo possui os seguintes resultados esperados: Processo Medição (MED) FDD Critério MED1 - Objetivos de medição são estabelecidos e mantidos a partir dos objetivos da organização e das necessidades de informação. O painel de progresso (Parking Lot) apresenta informação do andamento das atividades. Atende Parcial MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e definido, priorizado, documentado, revisado e, quando pertinente, atualizado. As medições dos processos são estabelecidas nos (Milestone), cada um com um peso em relação à funcionalidade que são: Estudo dirigido da funcionalidade 1%, Desenho 40%, Inspeção de Desenho 3%, Codificação 45%, Inspeção do Código10% e Promover para Build 1%. Atende MED3 - Os procedimentos para a coleta e o armazenamento de medidas são especificados. É estabelecido o processo de medição das funcionalidades (Milestone). Atende Parcial MED4 - Os procedimentos para a análise das medidas são especificados, após escolha de uma métrica em MED2, têm que ser documentadas as atividades e responsabilidades pela análise das medições e como os resultados serão comunicados. Os programadores chefe e o gerente de desenvolvimento ficam com a responsabilidade de coletar e analisar as features. Atende MED5 - Os dados requeridos são coletados e analisados. Os dados coletados são analisados e atualizados no quadro de tarefas no processo Construir por Funcionalidade. Atende MED6 - Os dados e os resultados de análises são armazenados. As informações são coletadas com os proprietários das classes para medirem o andamento da funcionalidade. Atende MED7 - As informações produzidas devem ser comunicadas para os usuários das medições, apoiando-os nos processos de tomada de decisão. Há uma preocupação com o armazenamento da coleta dos dados para serem usados como apoio de decisões. Atende Parcial Quadro 8: Descrição dos resultados esperados para o processo de Medição e o mapeamento na FDD Portanto neste mapeamento foi visto 40 resultados esperado nos processos dos níveis G e F do MPS.BR, dos quais de acordo com os critérios pré-estabelecidos, foram distribuídos da seguinte forma: Atende com 24, Atende Parcial com 12, Não Atende finalizando com 04, ao qual é demostrada no gráfico abaixo. Figura 4: Gráfico do Resultado do Mapeamento.
  • 18. Processo Resultados Esperados Atende Não Atende Atende Parcial Gerência de Projetos (GPR) 17 10 1 6 Gerência de Requisitos (GRE) 5 3 1 1 Gerência de Configuração (GCO) 7 5 2 0 Garantia da Qualidade (GQA) 4 2 0 2 Medição (MED) 7 4 0 3 Quadro 9: Resumo dos resultados esperados com a distribuição nos critérios pré- estabelecido. No quadro 9, demostra o resumo do mapeamento dos resultados esperados do MPSBR com as praticas da FDD em relação aos critérios de classificar, assim fica transparente a real contribuição da FDD, expondo a forma com que as práticas se relacionam com o com MPS.BR 7. Conclusões Este artigo realizou, como alvo principal, o Mapeamento dos resultados esperados entre o modelo MPS.BR apenas nos níveis G e F com a FDD, a qual possui as práticas e tarefas similares, a FDD não cobre todas as atividades em total compatibilidade que é exigida pela norma brasileira. Por esse motivo, a metodologia FDD vem ajudar e não substituir as atividades esperadas pelo programa brasileiro. Esta pesquisa analisou, em síntese, o conceito das normas já existentes no mercado mundial, o CMMI e as ISO’s 12207 e 15504, no intuito de demonstrar a base que é constituída o modelo MPS.BR, tornando-o aceitável no mercado brasileiro. Conhecido como metodologia tradicional, também demonstrou o surgimento do manifesto ágil em 2001 nos EUA, que, entre as metodologias ágeis, são abordadas as características e práticas de engenharia de software da FDD que estimula agilidade da produção com qualidade. Na última seção deste artigo, foi demonstrado o mapeamento do MSPBR com a FDD, onde ele é passível de interpretações. O trabalho proposto vem apresentar, em forma de porcentagens, o quanto a FDD há de ajudar nas tarefas requeridas, e sim, demonstrar que existe uma alternativa viável para agilizar as atividades. Essa agilidade é conseguida com várias das boas práticas que a FDD disponibiliza, são elas: modelo ARO, papéis-chaves, dono do código FBS, Inspeções, builds regulares, demonstrável para o cliente, utilização da UML em cores e outras.
  • 19. Referências ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO “Guia Geral”, 2009. Disponível <http://www.softex.br/mpsbr/_guias /guias/MPS.BR_Guia_Geral_2011.pdf >.Acessado em 21 de abril de 2011, 2011a. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO “Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS”, 2009. Disponível <http://www.softex.br /mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_1_2011.pdf >.Acessado em Julho de 2011 de 2010, 2011b. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO “Guia de Implementação – Parte 2: Fundamentação para Implementação do Nível F do MR-MPS”, 2009. Disponível <http://www.softex.br /mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_2_2011.pdf>.Acessado em 25 de Julho de 2011, 2011c. AGILCOOP, Cooperativa de Desenvolvimento Ágil de Software, “Empresas Ágeis no Brasil”. 2011. Disponível em < http://ccsl.ime.usp.br/agilcoop/empresas_ageis > Acessado em: 23/08/2011 BECK, K at all. “Manifesto para Desenvolvimento Ágil de Software”.2001. Disponível em: < http://agilemanifesto. org/iso/ptbr/.> Acesso em: 09/08/2011. BUBLITZ, Jorge Luiz “FDD - Feature-Driven Development - Desenvolvimento ágil dirigido a funcionalidades”,2011, Disponível em <http://www.slideshare.net/brjedi /aula-fdd-cesar-recife-gap > Acessado em: 09 Out. 2011 COAD, Peter; LEFEBVRE, Eric.; LUCA , Jeff de “Java Modeling In Color With UML: Enterprise” Components and Process. Prentice Hall, 1999 FERREIRA, Adson Wendel Cirilo. “Melhoria de processo de software brasileiro aplicado no nível de maturidade f em uma empresa alagoana desenvolvedora de software”.Disponível em <http://www.slideshare.net/adsonwendel/melhoria-de- processo-de-software-brasileiro-aplicado-no-nvel-de-maturidade-f-em-uma-empresa- alagoana-desenvolvedora-de-software-8534557> Acessado em: 12 junho 2010. LUCA, Jeff de “The Original FDD Processes”.1998, Disponível em <http://www.nebulon. com/articles/fdd/originalfdd.html>. Acesso em 05 Mai. 2011. GUSMÃO, Cristine Gomes de; MOURA, Hermano Perrelli. Gerência de Risco em Processos de Qualidade de Software: Uma análise Comparativa. 2004. P.6
  • 20. Disponível em <http://www.cefetrn.br/~placido/disciplina/pgp/material/sbqs05_ Gusmao.pdf>Acessado em: 19 de Mar 2010 MEDEIROS, Manoel Pimentel. “FDD - O ponto de Equilíbrio Ágil ”. In Artigo Java Magazine 76, Para projetos de desenvolvimento de software em ambientes corporativos complexos, 2011 Disponível em < http://www.devmedia.com.br/post-15854-FDD-O- ponto-de-Equilibrio-Agil.html> Acessado em: 09 Out. 2011 PÊSSOA, Marcelo Schneck de Paula. Modelo Integrado de Maturidade da Capacidade de Processo. Lavras: UFLA/FAEPE, 2005. RETAMAL, Adail Muniz “Feature-Driven Development - Descrição dos Processos”, 2008, Dispoível em < http://www.heptagon.com.br/files/FDD-Processos.pdf > Acessado em: 09 Out. 2011. 2008a RETAMAL, Adail Muniz “Metodologias de Desenvolvimento: UDP, FDD e XP”, 2008, Disponível em <http://adailmr.sites.uol.com.br/artigos/fdd-udp-xp.htm> Acessado em: 09 Out. 2011. 2008b REZENDE, Denis Alcides. Engenharia de Software e sistemas de informação. 2. ed. Rio de Janeiro: Brasport, 2002. SOARES, Michel dos Santos. “Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software”.2009. Disponível em < http://www.inf.ufrgs.br/~dsogari/material/S5/INF01127/Material/Comparacao-Metodos- Ageis-Tradicionais .pdf> Acessado em: 21 Mai. 2011 WEBER, Kival C.; ROCHA, Ana Regina; ALVES, Ângela; AYALA, Arnaldo M.; GONÇALVES, Austregésilo; PARET, Benito; SALVIANO, Clênio; MACHADO, Cristina F.; SCALET, Danilo; PETIT, Djalma; ARAÚJO, Eratóstenes; BARROSO, Márcio Girão; OLIVEIRA, Kathia;OLIVEIRA, Luiz Carlos A.; AMARAL, Márcio P.; CAMPELO, Renata Endriss C.; MACIEL,Teresa. Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira. Disponível em < http://pos.facom.ufu.br/~willian/uniube/eng_software/arteng2.pdf.> Acessado em: 20 Jan. 2010, 2004. Weber, K. C., Rocha, A. R., Alves, A., Ayala, A. M., Gonçalves, A., Paret, P., Salviano, C., Machado, C. F., Scalet, D., Petit, D., Araújo, E., Barroso, M. G., Oliveira, K., Oliveira, L. C.A., Amaral, M. P., Campelo, R. E. C., Maciel, T. “Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira”, In: XXX Conferencia Latinoamericana de Informatica (CLEI 2004). Arequipa, Peru: Septiembre 2004.