FACULDADE ANHANGUERA DE CAMPINAS
UNIDADE III
CURSO DE TADS
Adoção de práticas do nível G do MPS . BR em microempresas.
Disciplina: Engenharia de Software e Gerência de Projetos
Profa. Tânia Ramires
Curso de Tads – 5o. Sem Noturno
Alunos RA
Claudinei Aparecido de Paula 0955516766
Luiz Carlos Bernardes 0901337161
Campinas / 2011
O que é o MPS.BR?
O MPS.BR ou Melhoria de Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.Ele é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro.No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação as normas estrangeiras, sendo ideal para micro, pequenas e médias empresas.Um dos objetivos do projeto é replicar o modelo na América Latina, incluindo o Chile, Argentina, Costa Rica, Peru e Uruguai.
O projeto tem apoio do Ministério da Ciência e Tecnologia, do FINEP e do Banco Interamericano de Desenvolvimento. No Brasil o projeto é desenvolvido pelo Softex, pelo governo e por universidades.
O que é um modelo de maturidade de processos?
Toda empresa ou indivíduo que desenvolve software já faz isso por meio de algum processo. Esse processo pode ser caótico, obscuro e até mudar constantemente, mas não deixa de ser um processo. E isso nada mais é do que uma seqüência de atividades. Mesmo que você não se dê conta disto, tudo que você faz no trabalho de desenvolvimento de software segue uma seqüência de atividades. Às vezes essa seqüência não é fixa. Às vezes essa seqüência não segue uma ordem lógica. Às vezes essa seqüência provoca algum retrabalho. Mas perceba que sempre existirá uma seqüência. Às vezes essa seqüência já é eficiente, mas ninguém mais além de você sabe como funciona. Um modelo de maturidade de processos serve para corrigir esses e muitos outros problemas.
O MPS.BR descreve um modelo de amadurecimento gradual dos processos de desenvolvimento de software. Ou seja, você não precisar melhorar tudo de uma vez. Pode fazer isso aos poucos, de forma gradual. É para isso que servem os níveis de maturidade.
Vale ressaltar que o MPS.BR é apenas um modelo. Ninguém é obrigado a segui-lo a risca. Mas… ele é uma coletânea das melhores práticas relacionadas com o desenvolvimento de software. Assim, talvez valha a pena considerá-lo se não no todo, mas em parte. Entretanto, como ele é uma adaptação do CMMI-DEV, essas melhores práticas foram coletadas em outros mercados como EUA e Europa principalmente. E isso pode por em dúvida a aplicabilidade dessas supostas melhores práticas a nós, brasileiros. Essa dúvida, porém, só o tempo poderá dirimir.
O que é um processo maduro?
Dizer que um processo é, ou não, maduro pode gerar muita polêmica. Um processo é maduro quando ele é previsível, é estável e atinge os resultados esperados , poderiamos adicionar o baixo custo, mas isto normalmente é conseqüência. Mas a dificuldade é justamente medir os resultados e o custo pois em nossa área não há muito a cultura de se trabalhar com dados e as decisões são tomadas muitas vezes com base em percepções e não em resultados.
Portanto, para saber se um processo é ou não maduro, precisamos primeiro conseguir medi-lo. E é justamente esse a base para o objetivo final do MPS.BR: conseguir medir o desempenho dos processos, predizer seu comportamento futuro e melhorar sempre. Em teoria, uma empresa no Nível A do MPS.BR conhece plenamente o desempenho de seus processos e os fatores que os influenciam. Ao descobrir que um processo qualquer não é maduro, cabe à empresa encontrar formas de amadurecê-lo DE FATO, mas isto acontece fortemente no MPS.Br nível B – até chegar à ele você (vamos dizer) organiza a casa.
Na prática, as empresas já terão subsídios para amadurecer os processos desde o Nível F. Ou seja, não se precisa esperar até o Nível A para tomar alguma ação corretiva, elas podem (e devem) ser tomadas desde os níveis iniciais.
E para que um processo possa ser medido e corrigido ele precisa ser transparente, medido e gerenciável. Tudo gira em torno disso. Se um processo não é transparente, então não pode ser medido. Se não pode ser medido, então não temos como saber se os seus resultados são os melhores possíveis a um determinado custo. Se um processo não é gerenciável, mesmo que se possa medi-lo, então não se pode corrigi-lo, melhorá-lo. Se não podemos melhorá-lo, não podemos amadurecê-lo. Essa é a lógica da coisa toda.
O modeloO MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS.
MR-MPS – Modelo de referência para melhoria do processo de softwareO MPS.BR apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que são:
A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.
Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento).
Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistos.
AP 1.1 - O processo é executado;
AP 2.1 - O processo é gerenciado;
AP 2.2 - Os produtos de trabalho do processo são gerenciados;
AP 3.1 - O processo é definido;
AP 3.2 - O processo está implementado;
AP 4.1 - O processo é medido;
AP 4.2 - O processo é controlado;
AP 5.1 - O processo é objeto de inovações;
AP 5.2 - O processo é otimizado continuamente.
MA-MPS – Método de avaliação para melhoria do processo de softwareTem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresa e organizações que implementaram o MR-MPS. Avaliação MA-MPS:
Equipe de avaliação: 3 a 8 pessoas, sendo:
1 avaliador líder no mínimo
1 avaliador adjunto no mínimo
1 técnico da empresa
Duração: 2 a 4 dias;
Validade: 3 anos;
Estruturação da Avaliação:
Planejar e preparar avaliação Plano de Avaliação / Descrição dos indicadores de processo;
Conduzir Avaliação Resultado da avaliação;
Relatar resultados Relatório da avaliação;
Registrar e publicar resultados Banco de dados Softex (Ver portal MPS.BR nas 'Ligações Externas')
MN-MPS – Modelo de negócio para melhoria do processo de softwareInstituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciar através de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase na experiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamento de consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista de consultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinados no modelo e aprovados em prova específica.
Fontes de Referência : Softex/ Wikipedia / Assespro
Nenhum comentário:
Postar um comentário