Conheça o Microsoft Solutions Framework (MSF)

O caminho das pedras indicado pela Microsoft para o seu projeto encontrar o sucesso.

por Mauro Vianna

Na edição anterior, abordamos a questão de problemas em projetos de desenvolvimento de software. Mais ainda, constatamos que na maior parte das vezes, as causas dos problemas não são de natureza tecnológica, mas sim de como usamos esta tecnologia. Chegamos à conclusão de que precisamos de métodos adequados para utilizar a tecnologia de forma a atingir nossos objetivos. Mencionamos dois dos caminhos disponíveis hoje: Microsoft Solutions Framework (MSF) e Rational Unified Proccess (RUP). Neste artigo, veremos o MSF com mais detalhes.

O Microsoft Solutions Framework surgiu a partir da análise de como a Microsoft desenvolve seus produtos. Basicamente o MSF é uma compilação das boas práticas utilizadas pela empresa, que foi criado tanto para uso interno como para uso de seus clientes. Porém, apesar de ter sido criado pela Microsoft, o MSF aborda basicamente o processo de construção de soluções, não se prendendo ao uso de produtos desta empresa.

A Microsoft não classifica o MSF como uma metodologia, mas sim como uma disciplina. O que isso quer dizer? Basicamente que o MSF serve como um grande guia e uma coleção de boas práticas. Porém, o MSF não se aprofunda em detalhes.

Por exemplo, em um dado momento do projeto, o MSF diz que você terá que fazer uma especificação funcional.

Entretanto, ele não define se você deve usar UML, análise essencial ou outras técnicas. Isso fica a seu critério.

A falta de detalhes do MSF pode parecer uma deficiência a princípio, mas essa característica permitiu uma abordagem simples e direta das técnicas apresentadas. Ou seja, o MSF permite uma fácil compreensão tanto por parte da equipe como do cliente, além de ser bastante flexível em sua aplicação.

Em seguida, abordaremos de forma suscinta alguns tópicos do MSF. Os nomes originais serão mantidos em inglês, para facilitar a consulta em material de referência, que pode ser encontrado no site da Microsoft em http://www.microsoft.com/business/services/mcsmsf.asp.

A consulta a esse material e os treinamentos disponíveis são altamente recomendados para aqueles que desejam implementar esta disciplina.

Modelo de Equipe

O modelo de equipes é composto de seis papéis e se baseia no conceito de “team of peers”, ou seja, todos estes papéis se comunicam entre si e não existe uma hierarquia direta entre eles. Os papéis estão expressos na tabela 1.

Modelo de Equipe
Papel	Responsabilidade	Objetivo
Product Management	Representar o cliente para a equipe e vice-versa	Satisfação do cliente
Program Management	Gerenciar o andamento do projeto e atuar como um facilitador	Manter prazo e custo dentro do estimado
Development	Projeto e construção da solução	Atender à especificação do projeto
Testing	Testar a solução	Abordar os problemas antes da entrega do produto
User Education	Identificar as necessidades e treinar o usuário	Otimizar a performance do usuário
Logistics Management	Planejar e executar a logística necessária	Garantir uma boa implantação e manutenção

O princípio básico deste modelo é que cada um desses papéis aborda um objetivo importante para o projeto. Por isso todos os papéis devem estar representados e poder comunicar-se entre si, além de participar das decisões de projeto.

Por exemplo, ao longo do projeto o Product Manager pode identificar uma funcionalidade de grande importância para o cliente, mas que não foi especificada no início. Conversando com o Developer e Tester, foi identificado que serão gastos mais 5 dias para implementação e testes desta funcionalidade. User Education e Logistics não relataram impacto significativo.

O Program Manager, por sua vez, avaliará se este tempo adicional é tolerável com base nos limites de verba e prazo. Caso contrário, a funcionalidade pode ser postergada para outra versão, ou pode-se remover alguma outra funcionalidade não prioritária.

Fica claro que a boa comunicação permite a rápida tomada de decisões sobre o projeto, levando em consideração todos os objetivos do mesmo, já que cada um deles tem um responsável direto.

É importante realçar que, apesar de serem seis papéis, não é necessário seis ou mais pessoas. Na verdade, um papel pode ser desempenhado por várias pessoas ou uma pessoa pode acumular mais de um papel. Algumas combinações não são recomendadas, tais como Program Manager e Product Manager, pois em geral são conflitantes.

A composição da equipe vai depender do tipo de projeto, custo ou outros fatores. Porém, é importante que todos os papéis sejam representados.

Figura 1: Modelo de Equipes

Modelo de Processos

O modelo de processos do MSF prevê 4 fases : Envisioning, Planning, Developing e Stabilizing. Cada fase descreve um conjunto de subprodutos que devem ser entregues, assim como marcos que devem ser atingidos e os respectivos critérios de aceitação, veja a figura 2.

Figura 2: Modelo de Processos

A primeira fase, Envisioning, tem como produto principal um documento de visão e escopo. Este documento formaliza de forma suscinta a visão do que será o projeto. O marco de término desta fase é a aprovação da visão por todas as partes envolvidas. Neste ponto todos têm um entendimento geral do projeto e dos recursos necessários. Com base nesta visão é tomada a decisão sobre a continuidade ou não do projeto.

A fase seguinte, Planning, tem como produto o plano do projeto, que é composto de subprodutos, dos quais destacamos a especificação funcional e o cronograma da etapa de desenvolvimento.

O marco de término é a aprovação do plano de projeto, composto pelos diversos subprodutos. Neste momento já se tem uma visão detalhada do projeto, bem como maior precisão nos prazos e recursos necessários. Mais do que isso, toda a execução do projeto estará devidamente planejada.

Em seguida, vem a fase de Developing, que é quando construímos a solução propriamente dita. Esta fase gerará diversas versões intermediárias, que servirão como pontos de checagem e testes. O critério de término desta fase é que o escopo esteja completo, ou seja, todas as funcionalidades planejadas estejam implementadas.

A quarta e última fase é a Stabilizing. Ela é dedicada a testes sistêmicos e acertos de bugs e de funcionalidades não adequadas a necessidade do usuário. Novamente são geradas várias versões (alfas e betas). Ela termina quando existe um consenso sobre a qualidade final do produto.

Gerenciamento de Riscos

Por último, mas não menos importante, vem o gerenciamento de riscos. Quando falamos de risco, a primeira coisa a pensar é a seguinte: o que é um risco? Risco não é um problema. Um problema que já ocorreu não é um risco, mas um fato. Risco, na verdade, é algo que pode virar um problema no futuro.

Por exemplo, a possibilidade de incêndio devido a um ar-condicionado sem manutenção é um risco. O processo de gerenciamento de risco procede como na tabela de caracterização de riscos.

Caracterização de Riscos
Causa	Consequência	Probabilidade (1-3)	Impacto (1-3)	Exposição (P x I)
Mau funcionamento do ar condicionado	Incêndio na empresa	1	3	3 (= 1 x 3)

Já identificamos um risco. O passo seguinte seria analisá-lo. Na análise, é recomendado caracterizar o risco nos seguintes aspectos: causa, consequência, probabilidade e impacto.

No exemplo, teríamos a formação da tabela acima.

Percebam que utilizamos uma escala de 1-3 para probabilidade e impacto e criamos uma coluna de exposição, que é o produto de ambas. Isto serve como um critério para ordenar e selecionar os riscos de maior exposição.

O passo seguinte seria planejar como lidar com o risco. O ideal é evitar o risco, logo um plano de prevenção é importante. Caso o risco não possa ser evitado, se torna necessário um plano de contingência. O nosso exemplo ficaria como expresso na tabela de plano de contingência.

Plano de Contingência Prevenção Contingência Gatilho Responsável Manutenção preventiva do aparelho Ter um plano de evacuação do prédio Ao soar o alarme do detector de fumaça Brigada de incêndio

Notem que um responsável foi associado ao risco. Cabe a ele monitorar este risco. As fases seguintes são as de acompanhamento do risco e pontos de controle, onde riscos podem ter sido eliminados e novos riscos podem ter sido identificados.

Quando falamos de riscos, alguns pontos são importantes:

• O documento de riscos é vivo, ou seja, ele muda ao longo de todo o projeto;
• A fase de identificação é semelhante a um brainstorm: só identifique, não analise;
• Para os riscos de maior exposição (top 10), crie planos de prevenção e contingência.

O interessante da análise de risco é que ela se aplica a qualquer tipo de risco, não somente de projetos de software.

Neste artigo sintetizamos os principais aspectos do MSF e colocamos alguns exemplos.