Metodologia Pro.NET

Este artigo apresenta um resumo da metodologia Pro.NET, ressaltando seus objetivos, suas características principais e seus diferenciais em relação a outras metodologias.

por Andre Furtado

Por André Furtado e colaboradores do Centro de Inovação Microsoft de Recife

Introdução

Este artigo tem por objetivo apresentar as principais características da metodologia Pro.NET, resultante do trabalho realizado no projeto "Pro.NET - PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE PARA PLATAFORMA .NET". O projeto foi conduzido pelo Centro de Inovação Microsoft de Recife, que conta com a participação do Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE), o Centro de Estudos e Sistemas Avançados do Recife (CESAR), a Empresa de Soluções para o Processo de Construções de Software Qualiti, o complexo tecnológico Porto Digital e a Empresa de Fomento a Informática do Estado de Pernambuco (FISEPE) como parceiros e recebe o apoio da Financiadora de Estudos e Pesquisas (FINEP), Microsoft e HP Brasil.

Objetivo

O objetivo da Pro.NET é estabelecer uma metodologia que viabilize baixo custo, alta qualidade e agilidade no desenvolvimento de projetos que utilizem a plataforma .NET.

Motivação

O mercado de desenvolvimento de software, para ser competitivo, necessita cada vez mais de um conjunto de ferramentas (metodologias, linguagens, ambientes de desenvolvimento, etc.) que o faça produzir software, atendendo a três importantes variáveis: baixo custo, alta qualidade e agilidade. Aliado a esse contexto, o mercado de desenvolvimento de software tem uma demanda cada vez mais crescente de dominar e utilizar tecnologias e ferramentas, tais como MSF (Microsoft Solutions Framework), .NET, C#, VB.NET, MS Project, Visual Studio, eXtreme Programming, Rational Unified Process, PMBOK (Project Management Body of Knowledge) do PMI (Project Management Institute), etc.

O Microsoft Solutions Framework (MSF) foi criado em 1994 pela Microsoft Consulting Services (MCS), com o objetivo de aumentar sua taxa de sucesso no desenvolvimento de projetos em soluções de tecnologia. O MSF é baseado em boas práticas utilizadas em projetos bem sucedidos de soluções de tecnologia. Essa necessidade deu-se pela razão da grande quantidade de projetos que não obtiveram resultados satisfatórios. O MSF é um conjunto de práticas para planejar, construir e implantar soluções de Tecnologia da Informação. Ao contrário de uma metodologia, o MSF é um framework flexível e escalável, que atende às necessidades de uma organização ou time de qualquer tamanho. O MSF contém um conjunto de princípios, modelos e disciplinas para gerenciar pessoas, processos e elementos tecnológicos que a maioria dos projetos enfrenta. Vale destacar sua reputação de ser o framework utilizado pela maior empresa de desenvolvimento de software do mundo.

Sendo a Plataforma .NET uma tecnologia idealizada pela Microsoft, é interessante que os usuários da plataforma utilizem os princípios do MSF, pois a própria Plataforma foi desenvolvida utilizando esse framework. Neste contexto, vale ressaltar que o MSF utiliza a "linguagem Microsoft". Isso quer dizer que alguns termos utilizados na documentação da Plataforma .NET também são utilizados pelo MSF.

Tecnologias-alvo

A Pro.NET é uma metodologia direcionada para a Plataforma .NET e desenvolvida com base no MSF para estabelecer um processo de desenvolvimento altamente produtivo. O fato do MSF ser um framework flexível e escalável permitiu sua extensão para a criação da metodologia Pro.NET.

Ao contrário de grande parte dos processos de desenvolvimento existentes atualmente no mercado, a Pro.NET direciona a tecnologia a ser utilizada. O desenvolvimento da metodologia considerou a necessidade de um grupo específico de projetos de Tecnologia da Informação: os que utilizarão como base tecnológica a Plataforma .NET.

Apesar dessa característica, a Pro.NET pode ser utilizada em qualquer projeto de desenvolvimento de software. A maior parte da customização para a tecnologia-alvo está nos artefatos e guias, existindo uma independência nos processos e fluxos das atividades.

De que a Pro.NET não trata?

A Pro.NET não aborda os seguintes tópicos:

• Processo de operação de uma solução depois da implantação.
• Gestão de pessoas: contratação, acompanhamento etc.
• Gestão de orçamentos: definição, alocação, etc.
• Gestão de contratos com fornecedores, clientes e empresas subcontratadas.
• Processo de instanciação da Pro.NET para a realidade de uma organização ou projeto.

As próximas seções deste documento apresentam a estrutura da Pro.NET, o detalhamento do Modelo de Processo e de Equipe, comparação da Pro.NET com o MSF, glossário e a bibliografia utilizada.

Estrutura da Pro.NET

Esta seção apresenta brevemente as duas partes que compõem a estrutura da metodologia Pro.NET: o Modelo de Equipe e o Modelo de Processo.

O Modelo de Equipe descreve como estruturar a equipe e suas responsabilidades para atingir sucesso do projeto. Esse modelo utiliza o conceito de papéis para dividir as responsabilidades entre os membros do projeto. Além disso, apresenta guias de como a equipe deve agir e se relacionar. A seção Modelo de Equipe apresenta mais informações sobre esse tópico.

O Modelo de Processo descreve processos e métodos a serem realizados pelo time do projeto para planejar, desenvolver e implantar soluções de tecnologia da informação. O modelo de ciclo de vida de desenvolvimento de software da Pro.NET combina dois outros: cascata e espiral. Esse novo modelo define fases a serem seguidas em seqüência, como o modelo cascata, e que devem ser executadas várias vezes no mesmo projeto, definindo as iterações do modelo espiral. O final de cada fase é um marco e durante cada fase ocorrem marcos internos.

Cada iteração possui sua fase de Visão, Planejamento, Desenvolvimento, Estabilização e Implantação. O desenvolvimento deve seguir iterações de curto tempo, para acomodar mudanças dos requisitos da solução. A idéia é desenvolver o projeto de modo iterativo e incremental. A seção Modelo de Processo apresenta maiores informações sobre esse tópico.

Modelo de Equipe

O Modelo de Equipe da Pro.NET é inteiramente baseado no Team Model do MSF, fundamentando-se nos seguintes princípios:

• Estabelecer uma visão compartilhada do projeto: essa visão permite esclarecer os objetivos e traz à luz conflitos e asserções erradas para que os mesmos possam ser resolvidos. Uma visão compartilhada é uma maneira de medir o sucesso do projeto.

• Focar no valor agregado ao negócio do cliente: a equipe deve estar atenta ao que é realmente importante para o negócio do cliente. A tecnologia é utilizada como meio e não como foco.

• Permanecer ágil e esperar mudanças: todos os membros da equipe devem estar cientes de que mudanças ocorrerão e modificarão seu trabalho. Deve ser estimulada a prática de revisões e sugestões no trabalho realizado por outros membros.

• Incentivar comunicação aberta: a comunicação entre os integrantes deve ser estimulada e coordenada. Isso reduz os enganos provenientes da falta de informação. Se precisarem existir informações confidenciais, a equipe deve estar ciente de que existe o sigilo e que ele contribui para o sucesso do projeto.

• Compartilhar responsabilidade: cada membro da equipe é ciente das suas atribuições e divide a responsabilidade pelo sucesso do projeto.

• Dar a liberdade necessária e confiar nos membros da equipe: isso significa entregar aos membros da equipe a autoridade e os recursos necessários para preencher as responsabilidades associadas com seus papéis.

A equipe deve ser organizada como uma Equipe de Colaboradores (Team of Peers), isto é, cada papel da equipe é único, valioso e igualmente valorizado. Esse conceito está representado na Figura 1. Como ilustra a figura, os papéis do Modelo de Equipe são: Gerente de Produto, Desenvolvedor, Analista de Testes, Gerente de Release, Analista de Usuário e Gerente de Projeto.

Figura 1: Papéis da Equipe de Colaboradores
Fonte: referência [R2] Cada papel é responsável por um conjunto de responsabilidades de determinadas áreas funcionais que atingem um objetivo específico. Os objetivos, áreas funcionais e responsabilidades de cada papel do Modelo de Equipe são resumidas na Tabela 1.

Papel	Objetivo	Áreas funcionais	Responsabilidades
Gerente de Produto (Product Management)	Garantir a satisfação do cliente	Marketing Valorização do negócio Defesa do cliente Planejamento do produto	Age como advogado do cliente, representado seus interesses Gerencia a visão/escopo da solução Desenvolve e mantém análise de viabilidade Gerencia expectativas do cliente Gerencia decisões de escopo vs. cronograma vs. recursos Gerencia marketing e relações públicas Desenvolve, mantém e executa plano de comunicação
Gerente de Projeto (Program Management)	Entregar a solução dentro das restrições do projeto	Gerenciamento do projeto Especificação de subsistemas Processos Serviços administrativos	Desenvolve processo de desenvolvimento para entrega da solução conforme planejado Gerencia a especificação da solução Facilita a comunicação e negociação com equipe Reporta status do projeto Participa de decisões críticas do projeto Desenvolve, mantém e executa Plano de Projeto e cronograma Gerencia todo processo de riscos do projeto
Desenvolvedor (Devepment)	Construir a solução seguindo sua especificação	Consultoria de tecnologia Análise & Projeto Desenvolvimento da aplicação Desenvolvimento da infra-estrutura	Especifica requisitos de instalação Estima tempo e esforço para desenvolver cada caso de uso Constrói e supervisiona a implementação de casos de uso Prepara aplicação para implantação Oferece consultoria em tecnologia para a equipe
Analista de Testes (Test)	Garantir que defeitos da aplicação a ser entregue estão identificados e tratados	Planejamento de testes Engenharia de testes Reportagem de resultado de testes	Garante que todos os defeitos estão identificados Desenvolve planejamento de testes Conduz testes
Analista de Usuário (User Experience)	Garantir a produtividade do usuário	Comunicação técnica Treinamento Usabilidade Design gráfico Internacionalização Acessibilidade	Age como advogado da equipe, representado seus interesses Gerencia definição de requisitos dos usuários Cria e desenvolve sistema de suporte a produtividade Gerencia decisões de usabilidade vs. aumento da produtividade do usuário Especifica funcionalidades e mecanismos de educação dos usuários Desenvolve e fornece treinamento de usuários
Gerente de Release (Release Management)	Garantir uma implantação de sucesso para a solução	Infra-estrutura Suporte Operação Gerenciamento da implantação	Age como advogado para operação, suporte e canais de distribuição Gerencia implantação da solução Gerencia decisões para facilitar a administração do sistema e suporte ao usuário Gerencia relacionamento entre operação, suporte e canais de distribuição Oferece suporte logístico à equipe

Tabela 1: Papéis, objetivos, áreas funcionais e responsabilidades

A Pro.NET não define quem é o gerente do trabalho da equipe, sob o ponto de vista administrativo. Isso condiz com a noção de Equipe de Colaboradores, que afirma que cada papel é igualmente valorizado. Inclusive, em muitos casos, a equipe do projeto inclui membros de diferentes organizações, que estão subordinados a gerentes diferentes. No entanto, existem ocasiões em que a equipe não entra em consenso sobre um problema. Nessas situações, o Gerente de Projeto assume o controle e decide o rumo a seguir, já que esse papel deve garantir a entrega da solução dentro das limitações (incluindo tempo) do projeto. Depois de resolvido o problema, a equipe volta a dividir as responsabilidades e ser igualmente valorizada.

Para que os objetivos do projeto sejam alcançados com sucesso, é necessário existir comunicação com os stakeholders externos. É importante definir uma visão clara de quem será o responsável por facilitar essa comunicação. A Figura 2 apresenta como flui a comunicação visando negócios e tecnologia. O Desenvolvedor e Analista de Testes estão isolados da comunicação externa, que é executada por outros papéis. Isso não quer dizer que, por exemplo, um Desenvolvedor não poderá se comunicar com um cliente; no entanto, uma comunicação externa formal não é assumida por esse papel.

Figura 2: Comunicação externa
Fonte: referência [R2]

Cada papel pode ser desempenhado por várias pessoas. Nesse caso, deve existir uma hierarquia para determinar quem é o líder daquele papel. Por exemplo, vários Desenvolvedores podem ser subordinados a um Desenvolvedor líder. Essa hierarquia também pode ser definida para áreas funcionais.

Outro modo de se dividir a equipe é formar pequenas equipes multidisciplinares. Essa organização forma uma equipe de equipes, sendo cada uma das sub-equipes chamada de Equipes Multidisciplinar, havendo uma equipe a líder. Essas equipes menores não precisam ter todos os seis papéis e trabalharão em paralelo. A Figura 3 demonstra essa idéia.

Figura 3: Equipes Multidisciplinares
Fonte: referência [R2]

Numa equipe pequena, ocorre o caso em que uma mesma pessoa pode desempenhar vários papéis. Neste caso, deve-se ter cuidado para que uma pessoa não seja sobrecarregada de atribuições. A Tabela 2 ilustra o risco de se combinar papéis. A legenda utilizada é a seguinte: R - recomendável, P - possível, NR - não recomendável, X - não faz sentido (pois são os mesmos papéis).

	Gerente de Produto	Gerente de Projeto	Desenvolvedor	Analista de Testes	Analista de Usuário	Gerente de Release
Gerente de Produto	X	NR	NR	R	R	P
Gerente de Projeto	NR	X	NR	P	P	R
Desenvolvedor	NR	NR	X	NR	NR	NR
Analista de Testes	R	P	NR	X	R	R
Analista de Usuário	R	P	NR	R	X	P
Gerente de Release	P	R	NR	R	P	X

Tabela 2: Combinação de papéis para pequenas equipes

Analisando-se a Tabela 2, percebe-se que algumas combinações não são recomendadas. A primeira é que membros do papel Desenvolvedor nunca devem exercer outro papel, já que as atividades do Desenvolvedor são de prioridade máxima para o projeto e o seu atraso tem grande impacto no cronograma geral do projeto. Outra combinação não recomendada é do Gerente de Projeto com o Gerente de Produto, pois tais papéis representam interesses conflitantes. Enquanto o Gerente de Produto defende o interesse do cliente, o Gerente de Projeto defende o interesse da equipe. Modelo de Processo

O Modelo de Processo corresponde a todo o trabalho de desenvolver a aplicação. Este modelo descreve os processos e métodos a serem realizados pela equipe do projeto para planejar, construir e implantar soluções de tecnologia da informação. O Modelo de Processo da Pro.NET é baseado no Process Model do MSF. A seção Pro.NET vs. MSF apresenta maiores informações sobre as diferenças entre esses dois modelos.

O modelo de ciclo de vida de desenvolvimento de software da Pro.NET é dividido em iterações. A Figura 4 ilustra como o desenvolvimento das iterações gera versões da solução. Os pontos da figura representam o final das fases a serem seguidas em cada iteração.

Figura 4: Geração de versões da solução
Fonte: referência [R2]

A decisão da ordem em que os casos de uso devem ser implementados é baseada na importância do caso de uso para o cliente e os usuários, nos seus riscos associados e na sua importância para o estabelecimento de uma arquitetura em camadas estável. É através dessa decisão que são estabelecidos o escopo de cada iteração e a ordem de implementação dos casos de uso dentro de cada versão.

Cada iteração possui as seguintes fases: Visão, Planejamento, Desenvolvimento, Estabilização e Implantação. O final de cada fase é caracterizado por um marco conforme apresenta a Figura 5. Embora esta figura apresente um círculo dividido em cinco partes iguais, as fases não ocorrem necessariamente durante tempos iguais. A duração de cada fase depende da natureza do projeto.

A Fase de Visão é a primeira da iteração. É nesse período que o cliente e o time definem, em alto nível, os objetivos do projeto. Esta fase pode ser vista como um estágio inicial do planejamento. A aprovação do documento de Visão & Escopo é o marco ao final dessa fase. Com ele, o time e o cliente estabelecem uma visão única do que será o projeto.

Durante a Fase de Planejamento, a equipe está trabalhando na construção do Documento de Especificação Funcional da solução e no planejamento geral do projeto. O planejamento do projeto deve ponderar três fatores principais: escopo da solução, recursos do projeto e datas acordadas com o cliente. A fase termina com o marco aprovação do Plano de Projeto, indicando que os stakeholders concordam com o que e como será construído, além de quando a solução estará disponível aos usuários.

Figura 5: Fases e marcos
Fonte: referência [R2]

Na Fase de Desenvolvimento, a equipe constrói o código da aplicação, desenvolve a infra-estrutura e escreve uma parte da documentação. No decorrer da fase, são gerados e testados alguns releases internos. O marco do final da fase caracteriza que o escopo total da aplicação já foi construído, mas ainda podem existir defeitos.

É na Fase de Estabilização que os defeitos ainda existentes da aplicação são corrigidos. A equipe está focada em testar, priorizar e corrigir os defeitos encontrados, gerando novos builds, e em preparar a solução para a implantação no ambiente de produção. Um dos builds gerados será utilizado para implantação final da solução e marca o final desta fase.

A última fase da iteração é a Fase de Implantação. É nela que a implantação final é realizada e a responsabilidade pela solução passa para o time de operação e suporte. Deve ser realizado um postmortem, revisão geral das lições aprendidas durante o projeto, com objetivo de enriquecer a base de conhecimento da organização. A implantação final da solução é o último marco da iteração e caracteriza o início da próxima iteração.

A idéia do modelo de ciclo de vida da Pro.NET é baseada no desenvolvimento iterativo e incremental. Em cada marco, ocorre a validação do trabalho já executado, promovendo a comunicação entre os stakeholders. Além disso, a solução pode ser validada com o cliente ao final de cada iteração e é possível acomodar mudanças dos requisitos nas próximas iterações.

Além dos marcos já citados, podem existir marcos internos a uma fase. Esses marcos são pontos de sincronização e revisão do trabalho realizado, mas não são necessariamente validados com o cliente e usuários.

Disciplinas da Pro.NET

Além da estruturação do Modelo de Processo em um aspecto temporal, representado pela sucessão das fases apresentadas na seção anterior, existe uma estruturação atemporal, que organiza as atividades do projeto não em relação ao tempo (como as fases), e sim de acordo com a área de conhecimento. A metodologia Pro.NET divide as áreas de conhecimento, também chamadas de disciplinas, em dois grupos: disciplinas de processo e disciplinas de suporte.

As disciplinas de processo estão relacionadas ao trabalho de desenvolver a solução. São elas: Requisitos, Análise & Projeto, Implementação, Testes e Implantação. A disciplina de Requisitos busca entender a estrutura e a dinâmica do cliente, seus problemas correntes e identificar melhorias de processos, de modo a garantir que os clientes, os usuários finais e a equipe de desenvolvimento tenham um entendimento comum da solução a ser desenvolvida e de como esta solução atende aos objetivos da organização. O uso de protótipos é estimulado para aprimorar a especificação. Análise & Projeto, por sua vez, é a disciplina que possibilita a transformação dos requisitos em um projeto da aplicação, sugerindo uma arquitetura em camadas robusta e uma solução que atenda aos requisitos de implantação.

A disciplina de Implementação produz o código em várias camadas, implementa as funções e estruturas de dados, testa unitariamente o código desenvolvido e realiza inspeção nos artefatos criados. A disciplina de Testes verifica a integração de partes de código construídas separadamente, se todos os requisitos foram corretamente implementados e identifica e garante que defeitos serão resolvidos antes da implantação da solução. A disciplina de Implantação, por fim, disponibiliza versões da solução para os usuários e realiza treinamentos.

As disciplinas de suporte são formadas por um conjunto de atividades de apoio que possibilitam a execução das disciplinas de processo. São elas: Planejamento & Gerencia-mento, Riscos e Ambiente & Gerencia de Configuração.

A disciplina de Planejamento & Gerenciamento abrange os principais aspectos do planejamento e gerenciamento de projetos em um conjunto de atividades bem definidas. O planejamento agrupa os vários planos criados (sendo alguns deles em outras disciplinas) em um Plano de Projeto integrado, considerando uma data fixa para a entrega da solução e o uso de buffer time para acomodar futuros problemas ao longo do desenvolvimento. O gerenciamento do projeto assegura que as atividades programadas estão sendo executadas, gerencia mudanças e garante a qualidade dos artefatos produzidos e dos processos executados. Ao final do projeto, esta disciplina captura as lições aprendidas.

A disciplina de Riscos, por sua vez, descreve uma maneira pró-ativa de lidar com a incerteza e a considera nas decisões no ciclo de vida do projeto. A disciplina inclui identificação, priorização, planejamento, monitoração e controle dos riscos. Ao longo do projeto, é essencial a captura de lições aprendidas com os riscos.

A disciplina Ambiente & Gerência de Configuração, por fim, descreve como tratar a evolução dos artefatos produzidos, a geração de releases e builds de uma aplicação sendo desenvolvida e o controle das solicitações de mudanças na solução. Uma prática sugerida é a integração contínua do código da aplicação. Outro objetivo é planejar e gerenciar o ciclo de vida dos ambientes e dos recursos de hardware e software do projeto durante o progresso da solução. A Figura 6 mostra como as atividades das disciplinas são executadas durante uma iteração. As disciplinas de suporte, que aparecem ao centro, são executadas de forma contínua durante toda a iteração.

Figura 6: Relacionamento entre as disciplinas

Reunindo os Conceitos: Navegando pela Pro.NET

Assim como o RUP, a metodologia Pro.NET é interativa e está disponibilizada através de um site HTML, sendo, portanto, facilmente acessível ao usuário. Uma das principais seções do site da metodologia, apresentada na Figura 7, relaciona o aspecto atemporal e temporal da Pro.NET. As fases estão na primeira linha e, as disciplinas, na primeira coluna. As células centrais representam quais são as macro-atividades a serem realizadas naquelas fases e disciplinas.

Figura 7: Matriz de macro-atividades da Pro.NET

Macro-atividades contêm um conjunto de atividades que são executadas conjuntamente para a realização de um objetivo. Elas fornecem um nível mais elevado de abstração na descrição do trabalho a ser realizado. Na Figura 7, cada macro-atividade está associada a uma disciplina e várias fases. A barra de cada macro-atividade representa o período do projeto em que existirá esforço para executá-la.

A ordem de execução das macro-atividades durante as fases e das atividades em uma macro-atividade é apenas um direcionamento, podendo ser alterado de acordo com a necessidade do projeto.

Para cada macro-atividade, a metodologia descreve o fluxo de execução de suas atividades, como mostrado na Figura 8. Este detalhamento de macro-atividades deixa claro o conjunto de atividades a serem executadas por cada papel na macro-atividade, além de exibir visualmente o relacionamento entre as atividades.

Figura 8: Detalhamento de uma macro-atividade

Figura 9: Detalhamento de uma atividade

O nível de detalhamento da Pro.NET, por fim, atinge cada atividade individualmente. Como ilustrado na Figura 9, cada atividade possui um objetivo, um responsável, passos, artefatos de entrada e saída e, possivelmente, guias. O objetivo indica o que a realização daquela atividade pretende atingir dentro do contexto de desenvolvimento do projeto. O responsável é um membro do Modelo de Equipe que irá liderar a execução da atividade, respondendo pelo seu progresso. Os passos representam a divisão do trabalho a ser realizado na atividade em unidades menores. Os artefatos de entrada são necessários à execução da atividade, que gera artefatos de saída. A metodologia ainda apresenta templates, com instruções de preenchimento, para cada um dos artefatos apresentados nas atividades. Os guias, por fim, contêm um conjunto de orientações para facilitar a execução da atividade.

Arquitetura Pro.NET

Além da estruturação da equipe, atividades e disciplinas, a metodologia Pro.NET também disponibiliza a seus usuários os detalhes de uma arquitetura em camadas para o desenvolvimento de soluções para a Plataforma .NET. Por este se tratar de um assunto tecnicamente muito específico, apenas uma visão geral dessa arquitetura será apresentada neste artigo.

No contexto da elaboração da arquitetura sugerida pela Pro.NET, quatro principais variáveis foram levadas em consideração: o aproveitamento do código gerado pela ferramenta Visual Studio .NET, facilidades nativas da plataforma .NET (como delegates, eventos, etc.), experiência da equipe no desenvolvimento em aplicações em camadas e, por fim, dicas de arquitetura em camadas para .NET oriundas de trabalhos antecedentes [R7]. Essas variáveis foram combinadas para a elaboração de uma arquitetura que atende aos seguintes requisitos:

• Modularidade - A arquitetura desenvolvida segue a abordagem "dividir para conquistar", sendo separada por diferentes camadas, cada uma com um propósito específico. Através dessa separação de conceitos, a reusabilidade e extensibilidade da aplicação a ser desenvolvida, assim como de seus componentes, foi facilitada.

• Facilidade de manutenção - A arquitetura desenvolvida levou em consideração o fato de que os custos de manutenção representam de 50% a 80% do custo total de um software [R8]. Dessa forma, a arquitetura foi concebida de forma que mudanças em uma camada não afetam as demais camadas, desde que as interfaces entre as mesmas sejam preservadas.

• Produtividade - A geração de código realizada pelo Visual Studio .NET e facilidades nativas da Plataforma .NET foram levados em conta para garantir a produtividade de aplicações baseadas na arquitetura proposta pela metodologia Pro.NET. Em alguns casos, a produtividade foi considerada mais importante do que a manutenção do purismo do paradigma de Orientação a Objeto.

A arquitetura resultante pode ser visualizada na Figura 10. À implementação dos elementos de interface gráfica, presentes na primeira camada, recomenda-se a utilização de tecnologias da Plataforma .NET como CodeBehind, DataBind e Validators, cujo detalhamento foge ao escopo deste artigo. Web Services, por sua vez, constituem um ponto de distribuição da aplicação, podendo ser acessados pela camada de serviços de outras aplicações.

Figura 10: Arquitetura em camadas sugerida pela Pro.NET

A Camada de Negócios apresenta uma fachada como único ponto de acesso à aplicação, além de cadastros que contêm regras de negócios relacionadas a operações em um conjunto de entidades do mesmo tipo. A fachada e os controladores agrupam regras de negócios de relação de cadastros distintos. O controle de transação fica na fachada, caso exista. Se a fachada não existir, o mesmo passa a ser responsabilidade dos controladores. A Pro.NET recomenda a utilização de Typed DataSets para a implementação das entidades de negócio.

A camada mais inferior da arquitetura diz respeito à utilização de diferentes serviços pela aplicação (como serviços de enfileiramento de mensagens e log de eventos, por exemplo), além de apresentar o mecanismo de persistência da aplicação. É importante observar que, no caso da utilização de um banco de dados relacional, esta camada não faz o mapeamento objeto-relacional, pois isto já é realizado automaticamente através da utilização de Typed DataSets.

Por fim, uma camada intitulada Gerenciamento Operacional oferece suporte à implementação de questões comuns às camadas de Negócio e Persistência/Serviços, como o Gerenciamento de Transações, por exemplo.

Um estudo de caso disponibilizado pela Pro.NET, intitulado Internet Banking (IB), foi desenvolvido seguindo a arquitetura acima especificada, permitindo um processo contínuo de melhorias e, por fim, sua validação.

Pro.NET vs. MSF

A Pro.NET é mais objetiva e concreta do que o MSF, embora ainda se mantenha simples como o framework. A qualidade de ser objetiva é justificada pela disponibilização de uma visão de quais atividades devem ser realizadas em um determinado momento do desenvolvimento do projeto, como explicado na seção Modelo de Processo. Além disso, através da definição de uma tecnologia-alvo, grande parte dos artefatos da metodologia foi desenvolvida especificamente para essa tecnologia, o que torna a Pro.NET simples. Sendo assim, não é necessário interpretar processos e métodos genéricos do MSF para a realidade do projeto, pois isso foi justamente o que a equipe de desenvolvimento da Pro.NET já fez.

A Pro.NET oferece uma concretização das boas práticas definidas pelo MSF. Isso quer dizer que a Pro.NET preserva o conteúdo MSF, agregando a este descrições de como executá-los e acrescentando outros processos e métodos. Desse modo, enquanto o MSF diz o que fazer, a Pro.NET diz como. Para isso, a Pro.NET utiliza o mesmo modelo de ciclo de vida do MSF (iterativo e baseado em marcos) com o detalhamento de atividades assim como faz o RUP. Entretanto, a Pro.NET não apresenta todas as atividades de uma disciplina ao mesmo tempo, como faz o RUP. Pelo contrário, as atividades estão agrupadas em macro-atividades, permitindo uma visão mais clara do que deve ser feito em um determinado momento.

A Pro.NET, no entanto, não é somente uma concretização das boas práticas do MSF. O Modelo de Processos da nova metodologia também possui os seguintes diferenciais, se comparado ao MSF: novos processos, novos guias, templates para artefatos, maior estruturação de atividades e, obviamente, direcionamento para a Plataforma .NET.

O diferencial "direcionamento para a Plataforma .NET" já foi comentado quando apresentada a tecnologia-alvo. Sendo o MSF um framework para a construção de soluções de Tecnologia da Informação, ele não pode considerar os detalhes de uma plataforma específica. Os benefícios de se restringir a tecnologia-alvo de uma metodologia também já foram citados anteriormente. Um exemplo desse direcionamento é a indicação de ferramentas e disponibilização de alguns programas específicos para aplicações .NET.

Não se limitando a concretizar o MSF, os novos processos da Pro.NET são também são provenientes de outras metodologias, como RUP, XP e PMBOK. Por exemplo, a Pro.NET define um processo para a gerência de mudanças, enquanto que o MSF apenas cita a existência de artefatos de Solicitação de Mudanças e indica que deve existir um processo para realizar mudanças.

A Pro.NET também possui novos guias e templates para artefatos. Um dos guias mais importantes disponibilizados pela Pro.NET é o que especifica uma proposta de arquitetura em camadas, que por questões de espaço não pôde ser abordada neste artigo. Existem também novos templates e adaptação de alguns templates utilizados no MSF para a tecnologia-alvo.

O MSF divide suas boas práticas em disciplinas e fases. Não fica claro em que fases as boas práticas de uma disciplina do MSF devem ser realizadas. A Pro.NET define uma maior estruturação do conhecimento, através da apresentação do aspecto temporal e atemporal. A maior estruturação da Pro.NET facilita o entendimento da metodologia e a execução de seus processos. Esta estrutura foi descrita na seção do Modelo de Processo.

Enquanto o MSF possui três disciplinas, a Pro.NET possui oito. Das disciplinas do MSF, apenas a MSF Readiness Management Discipline não é contemplada pela Pro.NET. Ela detalha um modo de gerenciar conhecimento e habilidades da equipe necessárias para planejar e construir soluções.

É importante lembrar que as comparações realizadas nesta subseção se referem ao Modelo de Processos da Pro.NET, sendo o Modelo de Equipe da Pro.NET é equivalente ao Team Model do MSF.

Conclusões

A Pro.NET é uma iniciativa pioneira, que oferece um rico suporte, sem similar, ao desenvolvimento de aplicações para a Plataforma .NET. Este suporte é oferecido de diferentes formas, seja na estruturação da equipe de desenvolvimento, na condução das atividades do projeto, na sugestão de uma arquitetura bem-definida para a aplicação a ser desenvolvida, na presença de templates para artefatos ou de guias contendo análises de ferramentas e orientações para cada disciplina específica. Atualmente, a Pro.NET também apresenta uma seção especial que registra os cuidados e adaptações necessárias para a condução de projetos classificados como Provas de Conceito (PoCs).

O Centro de Inovação Microsoft de Recife concluiu dezenas aplicações da Pro.NET em Provas de Conceito, sendo a mesma também utilizada em um projeto externo ao Centro de Inovação, referente à extensão da ferramenta Visual Studio .NET para o suporte a novas linguagens [R4]. Os resultados obtidos até então são bastante satisfatórios e animadores, estando os demais Centros de Inovação Microsoft do Brasil, além da própria Microsoft Corporation, interessados na utilização da Pro.NET como uma alternativa para enriquecer o Microsoft Solutions Framework.

Apesar da metodologia se encontrar em uma versão estável, deve-se reconhecer que muitas melhorias ainda podem sem implantadas. Os desenvolvedores da Pro.NET têm consciência disso, estando a metodologia em constante estado de evolução. O feedback obtido com as aplicações da Pro.NET em Provas de Conceito, no Centro de Inovação Microsoft, vem permitindo a correção de eventuais defeitos e a incorporação de melhorias à metodologia. Além disso, existe um trabalho em andamento para a incorporação à Pro.NET dos requisitos necessários do CMM nível 2 [R5].

Em relação à arquitetura da Pro.NET, é necessário ainda abordar questões como segurança e concorrência, assim como padronizar o tratamento de exceções. Adicionalmente, é vislumbrada a possibilidade de automatizar a geração de código de diversos elementos da arquitetura, através de ferramentas de geração de código, como o Qualiti Coder [R6], atualmente estudado como uma alternativa concreta para essa tarefa.

Por fim, espera-se que novas versões da Pro.NET sejam acompanhadas de uma análise mais profunda das ferramentas de mercado atualmente existentes para a execução das atividades de projetos que envolvam a Plataforma .NET. Além disso, é considerada a possibilidade de criação de ferramentas específicas para a Pro.NET, que se adeqüem perfeitamente ao seu Modelo de Processo e sua arquitetura proposta. É desejado que a metodologia, no futuro, incorpore demais peculiaridades da Plataforma .NET, como o suporte multi-linguagem e a interoperabilidade com componentes COM. A intenção final é permitir que a idéia de software disponível "a qualquer hora, em qualquer lugar" seja embasada por processos que representem "baixo custo, alta qualidade e agilidade".

Referências

[R1] Booch, G., Jarcobson, I., Rumbaugh, J., The Unified Software Development Process, Addison-wesley, 1999
[R2] Site oficial da Microsoft que apresenta uma descrição do MSF 3, http://www.microsoft.com/msf, visitado em 14/05/2003
[R3] Site oficial da Rational que contém demonstrações do RUP, http://www.rational.com/tryit/rup/seeit.jsp?SMSESSION=NO, visitado em 12/05/2003
[R4] Furtado, André W. B., Santos, André L. de M., VHS-AM: Extensão do Visual Studio .NET para a integração de Haskell com a ferramenta Assignment Manager, Trabalho de Graduação em Ciência da Computação, CIn/UFPE, 2003
[R5] Maranhão, Suzana M. de B., Moura, Hermano P., Vasconcelos, Alexandre M. de L.: Análise Comparativa entre PRO.NET e CMM Nível 2, Trabalho de Graduação em Ciência da Computação, CIn/UFPE, 2003
[R6] Qualiti.com: Qualiti Coder, disponível em http://coder.qualiti.com (03/04/2004)
[R7] Microsoft.com: Application Architecture for .NET: Designing Applications and Services, disponível em http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp?frame=true (17/04/2004)
[R8] Collofello, J. S., Woodfield, S. N. Evaluating the effectiveness of reliability-assurance techniques, Journal of Systems and Software, 9(3):191-195, 1989.