Aplica-se a:

• Microsoft Visual Studio Team System

• Microsoft SQL Server 2005 Reporting Services

• Fábricas de software

Resumo:

Este white paper discute como as fábricas de software e o Microsoft Visual Studio Team System podem ser utilizados em conjunto para aperfeiçoar a qualidade, previsibilidade e produtividade. Com a utilização do data warehouse e dos recursos de relatórios do Visual Studio Team System, o criador da fábrica de software pode determinar com confiança quais aspectos do desenvolvimento de produtos precisam ser aperfeiçoados e como modificar a fábrica de software para aperfeiçoá-los.

Este white paper conclui que qualidade, previsibilidade e produtividade aperfeiçoadas podem ser conseguidas com a abordagem da fábrica de software, no lugar do desenvolvimento único tradicional. Os conceitos e métodos de trabalho são direcionados a um público de integradores de sistemas e clientes de empresas que desenvolvem software personalizado. (23 páginas impressas)

Nesta página

Introdução
Mudança no modo como criamos software
Medida da qualidade e produtividade
Aplicação do Visual Studio Team System
Utilização de construções de medida (ISO 15939)
Conclusão
Referências

Introdução

Atualmente, criar software é uma tarefa difícil. Os sistemas se tornam, a cada dia, maiores e mais complexos. Enfrentamos uma rápida mudança tecnológica, enquanto tentamos satisfazer as demandas de clientes comerciais que querem que escrevamos software melhores cada vez mais rápidos. É possível, realmente, ser mais produtivo enquanto se produz software de melhor qualidade? Uma produtividade maior pode ser sustentada com manutenção e atualizações, sem que isso degrade a qualidade ou implique reescrever códigos significativamente? Pode ser impossível reescrever códigos de sistemas com milhões de linhas, particularmente se os negócios exigirem mudanças rápidas. Neste white paper, explicaremos como você pode ser mais produtivo e produzir software melhor, lançando mão de uma abordagem de fábrica de software para o desenvolvimento.

Mudança no modo como criamos software

Durante várias décadas, a indústria de software criou sistemas de software para dar suporte às necessidades de seus clientes. Entretanto, apesar de toda essa experiência, a qualidade e a produtividade não foram aperfeiçoadas rapidamente. Hoje em dia realizamos mais ou menos o mesmo nível de produtividade que realizávamos há 10 anos, de acordo com uma pesquisa anual conduzida pelo grupo Standish. Atualmente, 54% de todos os projetos de desenvolvimento de software são fornecidos acima do orçamento, 66% são considerados sem êxito pelos clientes e 90% não são entregues no prazo! No entanto, o aspecto mais perturbador da pesquisa é que esses números não melhoraram muito no decorrer da última década.

Procure um grupo de desenvolvedores ou gerentes de projetos e pergunte a eles se acham que são bem-sucedidos na criação de software atualmente. Quase todos tendem a rir um pouco, admitindo posteriormente que também são vítimas desses tipos de resultados. É triste perceber que acabamos pensando assim, pois a criação de software é um processo tão criativo e temos de conviver com entregas de projetos ruins.

Como o software é criado hoje

Uma produtividade ruim em geral resulta da falta dos requisitos certos ou da falta de todos os requisitos. A produtividade será seriamente prejudicada, não apenas se estivermos criando o sistema errado, mas também se o escopo do projeto for complexo – fazendo-o exceder o volume inicial de funcionalidade. Também achamos difícil alcançar o nível certo de teste, para garantir o nível esperado de qualidade. A manutenção e os lançamentos de atualizações fracassados estão geralmente relacionados à falta de habilidade em prever os efeitos das mudanças do código na qualidade do produto. Como garantir que a mudança efetuada em uma parte do sistema não estragou outra parte?

Vários desses problemas aparecem, pois aprendemos muito pouco dos projetos que fizemos. Pergunte a equipes de desenvolvimento se aprenderam com seus erros e é incrível constatar como poucas delas realmente colhem aprendizados e os aplica em projetos futuros. Poucas equipes reutilizam com regularidade as soluções criadas no passado ou têm controle do que deu certo e do que deu errado. Como resultado, não há transferência de conhecimento suficiente entre projetos; o conhecimento permanece na cabeça dos desenvolvedores. As lições já aprendidas são reaprendidas pelos novos desenvolvedores. Desenvolvedores acham difícil sair de projetos existentes, pois sabem muito sobre eles e acham difícil entrar em projetos novos, pois não existe muita informação escrita sobre eles.

Como muitos projetos não são entregues no prazo nem dentro do orçamento, podemos ver que também temos um problema de previsibilidade. Pergunte aos gerentes de projetos como fazem seus planejamentos e cronogramas, e é ainda mais incrível constatar quantos deles se prendem a velhos hábitos, dizendo coisas do tipo "Pergunto a meu melhor programador uma estimativa de quanto este recurso custará, depois multiplico por dois, pois ele tende a ser muito otimista". Muitas vezes esse tipo de "orçamento" é depois reduzido, para apresentar uma proposta competitiva, para que os números funcionem ou para satisfazer as expectativas. É muito difícil mudar esses velhos hábitos.

Mas, sejamos honestos. Os gerentes de projetos estão quase que destinados a confiar nos palpites dos especialistas, pois não têm métricas confiáveis em que se basear. Precisam é da capacidade de capturar métricas de projetos de desenvolvimento de software de um modo confiável – por exemplo, em um data warehouse. Dessas métricas, podem aprender como as equipes de desenvolvimento operam e usar tal conhecimento para elaborar estimativas melhores. A utilização dos dados históricos para calibrar o desempenho de projetos ou da organização melhora a precisão das estimativas, mas a maioria delas é feita sem eles.

Com uma previsibilidade ruim, é difícil controlar os projetos. Quando os gerentes de projetos tomam uma decisão, como eles sabem qual efeito ela terá no cronograma e nos custos? Você simplesmente não pode utilizar estimativas ruins para prever o impacto da tomada de decisão. É como dar um tiro de olhos fechados e esperar que acerte o alvo.

Devido a esses problemas, produzimos muito pouco software em muito tempo. Fornecemos software de qualidade ruim e imprevisível. Temos dificuldade em manter o desenvolvimento sob controle. É difícil para os profissionais mudar os projetos. Cada hora acima do orçamento custa dinheiro extra, e cada defeito encontrado nos testes – ou, pior ainda, na produção – custa mais dinheiro, assim como cada decisão errada tomada durante o caminho. Criar software hoje em dia é muito caro.

Utilização das fábricas de software

Podemos melhorar? Sim. Podemos criar software no prazo, dentro do orçamento e com a qualidade adequada. Primeiro, entretanto, precisa existir um reconhecimento organizacional de que a abordagem atual da criação de software é grosseiramente ineficiente. Sem o reconhecimento da existência de problemas, não haverá movimento para melhorar. Para começarmos a criar sistemas de software previsíveis, precisamos sofrer uma mudança cultural. Precisamos facilitar os meios para os profissionais saberem o que fazer, quando fazer, por que fazer e como fazer, e precisamos automatizar mais os aspectos rotineiros e/ou braçais do trabalho. Essas metas podem ser alcançadas pela formalização de aspectos selecionados do processo de desenvolvimento. Quais são esses aspectos? Como podemos formalizá-los sem sacrificar a agilidade?

Criatividade e formalidade

A chave é formalizar as atividades refinadas que criam e modificam produtos do trabalho, em vez de tentar formalizar todo o processo de desenvolvimento. Fluxos de trabalho menos elaborados podem evoluir para satisfazer os requisitos e as circunstâncias do projeto, desde que as invariáveis sejam mantidas para garantir que os resultados sejam válidos. Você pode trabalhar escrevendo diversas classes ao mesmo tempo, por exemplo, alternando entre elas, desde que todas as dependências entre elas sejam satisfatórias quando você compilar. Essa flexibilidade preserva a agilidade e evita o enfileiramento em uma única atividade. Ao formalizar as atividades refinadas, em vez de tentar formalizar todo o processo de desenvolvimento, você ganha qualidade, previsibilidade e produtividade sem sacrificar a agilidade. Você aprende onde a formalidade é necessária e onde não é, facilitando um equilíbrio certo entre agilidade e formalidade. Ao aplicar formalidade apenas onde e quando é necessário, você permite ao processo do desenvolvimento, com a experiência, evoluir de modo bastante orgânico e crescente. Essa abordagem também facilita a aquisição de conhecimento e transferência dele entre os projetos e profissionais, como veremos posteriormente.

A criatividade é necessária para resolução de problemas, mas não para a execução de atividades rotineiras e/ou braçais. É triste, mas talvez não surpreendente, o fato de que a maior parte do trabalho diário de um desenvolvedor típico consiste em atividades rotineiras e/ou braçais. A chave para ganhar em produtividade e previsibilidade sem sacrificar agilidade é encorajar e apoiar a criatividade onde é necessária e formalizá-la onde não for necessária. Quanto mais formalizamos com padrões, práticas e ferramentas, mais variação gratuita eliminamos do processo. A eliminação de variações gratuitas facilita a medição de projetos de desenvolvimento de software, o aprendizado proveniente deles e a utilização de tais medidas para aperfeiçoamento de projetos futuros. A formalização das atividades rotineiras e/ou braçais permite maior criatividade, reduzindo a quantidade de tempo e energia gastos em atividades que não requerem criatividade.

Fábricas de software

Estamos falando sobre industrialização de desenvolvimento de software, aplicação de tecnologias já comprovadas em outras indústrias para nossa indústria, na esperança de melhorar nossa vida e a de nossos clientes. Essa industrialização é obtida com a criação de fábricas de software, que tornam o desenvolvimento de software mais produtivo e mais previsível ao mesmo tempo.

Uma fábrica de software é um conjunto empacotado de processos, ferramentas e outros ativos integrados usados para acelerar as tarefas de ciclo de vida de um tipo específico de componente, aplicativo ou sistema de software. A aceleração é alcançada fornecendo aos profissionais diretrizes que os ajuda a saber o que fazer, quando fazer, por que fazer e como fazer. Fazemos isso fornecendo orientação de processo com a quantidade suficiente de formalização do processo, componentes que podem ser rapidamente montados e configurados ou estruturas que podem ser facilmente completadas, e fornecendo ferramentas especializadas que automatizam total ou parcialmente as atividades rotineiras e/ou braçais.

Uma das metas principais que queremos atingir com a fábrica de software é aprender com as soluções que criamos no passado para problemas ou requisitos comumente encontrados e aplicar esses aprendizados em projetos futuros. Para isso, precisamos de uma forma para descrever tais soluções reutilizáveis e uma maneira de organizá-las em áreas de interesse ou preocupação, em que os problemas ou requisitos que abordam são normalmente encontrados. A organização deste modo ajuda a restringir o conjunto de problemas e requisitos em foco a qualquer momento, facilitando a identificação de soluções reutilizáveis que podem ser aplicadas. Essas áreas de interesse podem estar em um alto nível de abstração, como na definição de camadas arquitetônicas, ou em um baixo nível de abstração, como na definição de assinaturas de método para interfaces ou classes C#.

Esquemas e modelos

As fábricas de software utilizam a terminologia da IEEE 1471, Recommended Practice for Architectural Description of Software-Intensive Systems (Prática recomendada para descrição arquitetural de sistemas intensivos de software), que chama uma área de interesse de ponto de vista. Os pontos de vista podem ser definidos para várias motivos, como descrever partes diferentes de um produto, em níveis diferentes de abstração, em fases diferentes do ciclo de vida do desenvolvimento do software. Os pontos de vista aninham-se, portanto um ponto de vista da Camada de acesso a dados pode conter um ponto de vista da Biblioteca de acesso a dados, um ponto de vista do Design de banco de dados lógico, um ponto de vista do Design do banco de dados físico e um ponto de vista da Segurança de dados.

Os produtos de trabalho produzidos ou consumidos de um determinando ponto de vista constituem uma exibição. Uma exibição é definida por seus pontos de vista muito similarmente ao modo como um objeto é definido por sua classe. Um produto de trabalho pode ser um arquivo, parte de um arquivo, vários arquivos ou partes de vários arquivos. Em um ponto de vista da Biblioteca de acesso a dados, por exemplo, um produto de trabalho pode ser um arquivo contendo uma classe de acesso a dados para uma tabela de banco de dados. Uma exibição definida pelo ponto de vista da Biblioteca de acesso a dados pode ser um projeto contendo um conjunto de classes de acesso a dados para todas as tabelas em um determinado banco de dados. Os pontos de vista podem ser transversais, bem como modulares. Os produtos de trabalho para um ponto de vista da Segurança de dados, por exemplo, podem ser preâmbulos nos métodos de inserir, substituir e atualizar as classes de acesso a dados.

Os pontos de vista tendem a orientar a criação de tipos de projetos e ferramentas. Por exemplo, um ponto de vista da Biblioteca de acesso a dados pode ser mapeado para um tipo de projeto de biblioteca de classe baseado em um modelo de projeto com determinadas propriedades, contendo modelos de item com determinadas propriedades para classes de acesso a dados. Quando criamos projetos deste tipo, estamos criando exibições baseadas naquele ponto de vista. O conteúdo das exibições são os arquivos na pasta de projeto. Esses são os produtos de trabalho definidos pelo ponto de vista.

Em níveis mais altos de abstração, os pontos de vista tendem a orientar o desenvolvimento de ferramentas. Por exemplo, um ponto de vista de Processo de negócios pode ser manifestado por uma ferramenta de modelagem de processo de negócios. A ferramenta expõe exibições baseadas naquele ponto de vista na forma de modelos, que são os produtos de trabalho definidos pelo ponto de vista. Ela também suporta as atividades definidas pelo ponto de vista com comandos de menu e outros gestos, como operação de arrastar e soltar, da caixa de ferramentas no diagrama, para criar um novo tipo de mensagem.

Para cada ponto de vista, precisamos de um nome e de uma descrição. Também precisamos saber os produtos de trabalho produzidos ou consumidos, as etapas envolvidas na criação ou modificação de tais produtos de trabalho e os ativos utilizados para executar as etapas. Em outras palavras, um ponto de vista deve nos informar o que criar, como criar e o que podemos usar para criar (padrões, ferramentas, modelos etc.). Os pontos de vista são os blocos de construção das fábricas de software. Eles formalizam as atividades refinadas que criam e modificam produtos de trabalho.

Cada fábrica de software define o conjunto de pontos de vista inter-relacionados necessários para criar seus produtos. Esse conjunto de pontos de vista inter-relacionados é chamado esquema. Você pode pensar em um esquema como um índice que o ajuda a descobrir como a fábrica de software é organizada, para que possa usar os ativos que ela fornece para criar os produtos que tem como alvo. Um esquema de fábrica é muito parecido com um esquema de banco de dados, que o ajuda a descobrir como um banco de dados é organizado, para que você possa navegar, consultar e manipular os dados que ele contém. Em vez de descrever a organização de um banco de dados, entretanto, ele descreve a organização de uma fábrica de software.

Para dar um pequeno exemplo de esquema, daremos uma olhada em uma fábrica que cria aplicativos administrativos empresariais com base em SOA (arquitetura orientada a serviços). Para esta fábrica, você pode definir os seguintes pontos de vista:

• Aplicativos de front-end.Descreve a criação de aplicativos Windows ou Web que suportam entrada de dados no desktop do usuário. Informa aos usuários como criar formulários Windows ou Web usando criadores de formulários e controles de entrada de dados provenientes de uma biblioteca que você desenvolveu. As atividades para este ponto de vista são criar formulários Windows ou Web. Os produtos de trabalho são os formulários. Os ativos são os criadores de formulários e a biblioteca de controles de entrada de dados.

• Serviços de processo.Descreve a criação de serviços Web responsáveis pelo gerenciamento de processos de negócios. Os serviços Web são sempre construídos da mesma forma a partir de um padrão e têm um contrato de serviços descrito por uma interface C# com objetos com rigidez de tipos gerados de um esquema XSD. A atividade para este ponto de vista é criar serviços Web. Os serviços Web são os produtos de trabalho. Os ativos são o padrão e o gerador de objeto com rigidez de tipos.

• Serviços de plataforma.Descreve a criação de serviços Web responsáveis não pelos dados de negócios, mas somente pelos serviços genéricos a todos os sistemas, como impressão, auditoria, autorização, etc. Este ponto de vista fornece serviços genéricos disponíveis para reutilização e informa ao usuário como avaliar e personalizar cada serviço. As atividades para este ponto de vista são avaliar e personalizar os serviços. Os produtos de trabalho são os serviços personalizados. Os ativos são os serviços genéricos.

A última parte da nomenclatura da fábrica software a ser entendida é o modelo da fábrica, que é um pacote que pode ser instalado contendo os ativos fornecidos pela fábrica de software. Para utilizar uma fábrica, um profissional deve instalar o modelo de fábrica em uma estação de trabalho.

As fábricas geralmente são desenvolvidas de baixo para cima. Depois de ter identificado uma família de produtos-alvo, conforme cria sistemas, você pode começar a descobrir e descrever produtos de trabalho e atividades; organizando-os em pontos de vista; desenvolvendo ativos para suportar as atividades; organizando os pontos de vista em um esquema de fábrica; e empacotando os ativos em um modelo de fábrica.

Configuração do recurso

Uma das chaves para criação de fábricas eficientes é a definição de produtos de trabalho, atividades e ativos que podem ser colocados em uso em muitas soluções diferentes. Por exemplo, o ponto de vista da Biblioteca de acesso a dados pode fornecer uma biblioteca que o ajuda a acessar o banco de dados SQL. Você pode achar que não utiliza sempre o mesmo RDBMS para todos os projetos e que sua biblioteca deve, portanto, acomodar outros RDBMS. Os produtos de trabalho utilizados com a biblioteca e as descrições das atividades realizadas com a biblioteca também podem ter de se adaptar. Quanto mais variabilidade um ponto de vista aceita, maior flexibilidade você tem para aplicá-lo a soluções múltiplas, mas também maior a quantidade de trabalho a ser executado para configurá-lo corretamente. Acomodar a variabilidade apresenta complexidade. Você tem de encontrar um equilíbrio entre variabilidade demais e de menos, para fazer com que sua fábrica de software seja eficaz. Quanto mais genérica você fizer a fábrica, menos produtividade e previsibilidade ganhará.

Um bom modo de determinar quanta variabilidade deve ser acomodada é analisar os recursos das soluções que espera criar. Utilizando uma técnica chamada análise de variabilidade/aspectos comuns (C/V), você separa recursos comuns (ou obrigatórios) que devem aparecer no mesmo modo em toda solução de recursos variáveis (ou opcionais) que podem aparecer apenas em algumas soluções ou que diferem em como aparecem de uma solução para outra. Não está no escopo deste white paper descrever em detalhes a análise C/V, mas existem muitos documentos e livros sobre o assunto para os leitores interessados.

Na fábrica que cria os aplicativos administrativos empresariais com base em SOA, o acesso a dados é um recurso obrigatório (já que todas as soluções executarão o acesso a dados), mas Web Front End é um recurso opcional (já que algumas soluções terão Web Front Ends e outras terão Windows Front Ends ou mesmo nenhum front end).

Em uma fábrica, você pode usar os modelos de recurso para descrever os recursos que podem aparecer em um membro da linha de produtos, para separar os recursos comuns dos variáveis e para indicar como os recursos variáveis podem aparecer. (Os modelos de recursos são descritos detalhadamente por Czarnecki e Eisenecker. Para obter mais informações, consulte a seção deste white paper). Os modelos de recursos podem também definir o modo como as decisões sobre recursos variáveis influenciam uns aos outros, como afirmar que um recurso variável requer outro ou que um recurso seja incompatível com outro. Essas decisões são tomadas para um determinado aplicativo configurando-se o modelo de recurso. A configuração é um processo simples que envolve a especificação de quais recursos variáveis descritos pelo modelo aparecerão no aplicativo e como cada um deles aparecerá. Um modelo de recurso simples para a fábrica descrita anteriormente é mostrado na Figura 1.

Figura 1. Exemplo de modelo de recurso

Embora modelos de recursos sejam freqüentemente utilizados para recursos visíveis ao usuário expostos como requisitos, eles também podem ser usados para criação, implementação, teste e implantação de recursos visíveis somente a desenvolvedores. Alguns cenários robustos são habilitados pela vinculação desses recursos, de modo que configurando os recursos visíveis ao usuário configura-se os recursos visíveis ao desenvolvedor. Por exemplo, a vinculação de recursos Front end visíveis ao usuário a recursos de camada de solução visíveis ao desenvolvedor pode deixar a fábrica gerar uma camada de solução padrão baseada no tipo de front end escolhido pelo usuário.

A modelagem de recursos é apenas um dos mecanismos bem conhecidos que podem ser utilizados para descrever a variabilidade. Outros incluem formulários, tabelas, assistentes, criadores, modelos, padrões, scripts e código. Os mecanismos de variabilidade podem ser utilizados sozinhos e em várias combinações, para especificar e implementar recursos variáveis em uma fábrica de software.

Chaves para o sucesso

Quais são os fatores-chave para o sucesso da transição para uma abordagem de fábrica de software? Você precisa das seguintes capacidades:

• Encontrar os aspectos comuns e as variabilidades em seus produtos.

• Medir qual o desempenho do processo de desenvolvimento de seu produto hoje, em termos de produtividade e qualidade.

• Definir e aperfeiçoar o processo que suporta o desenvolvimento do produto eficientemente.

• Fornecer um modelo transparente que ajude a todos a entender a produtividade e a qualidade que estão sendo alcançadas, e utilizar um modelo transparente para direcionar a transformação cultural.

• Planejar mais de um projeto por vez.

• Desenvolver de forma rápida e barata ativos reutilizáveis que envolvam conhecimento e facilitem sua reutilização, especialmente ferramentas personalizadas.

• Identificar domínios específicos e objetivá-los com processos e ferramentas personalizados, em vez de tentar aplicar processos e ferramentas de finalidades gerais a todos os domínios.

Medida da qualidade e produtividade

Agora que sabemos um pouco sobre as fábricas de software, vamos examinar mais de perto a medida da qualidade e produtividade no contexto de uma fábrica de software.

O esquema da fábrica, conforme se revela, proporciona um mecanismo útil para organização de métricas. Como cada ponto de vista objetiva um aspecto específico do processo de desenvolvimento de software, você pode utilizar os pontos de vista para definir medidas-alvo de produtividade e qualidade. Ao utilizar tais medidas, você pode reunir dados para aspectos específicos do processo de desenvolvimento de software. Pela análise dos dados, depois você pode determinar quais pontos de vista precisam ser aperfeiçoados, como aperfeiçoá-los e o que você pode ganhar aperfeiçoando-os.

Para implementar essa abordagem, você precisa de um modo para expressar o tamanho do produto, o tempo e orçamento gastos e a qualidade do produto. Essa medidas podem ser utilizadas para quantificar a previsibilidade, produtividade e qualidade de cada ponto de vista. Elas também podem ser usadas para avaliar os produtos finais produzidos por sua fábrica. Pela medição de cada ponto de vista, bem como o desempenho geral da fábrica, você pode determinar como cada ponto de vista afeta o desempenho geral da fábrica e, portanto, quanto investir no suporte às atividades em um determinado ponto de vista com ativos reutilizáveis. Por exemplo, você pode fornecer diretrizes simples para pontos de vista que não afetem significativamente a eficiência geral e criadores sofisticados baseados em DSL (linguagem específica de domínio) para pontos de vista que a afetem.

Essa abordagem é similar ao modo como grandes organizações empresariais otimizam seus processos de negócios. Elas definem as qualificações, os processos e as ferramentas necessários para produção de produtos de trabalho para uma meta de negócios específica. A partir disso, medem o esforço necessário para realizar o processo e então analisam o que pode ser aprovado. Elas chamam isso de monitoramento de processo de negócios, mas é basicamente o que estamos fazendo quando otimizamos uma fábrica de software. Claramente, a medição é um fator crítico no estabelecimento de uma linha de base do desempenho atual de sua fábrica e na identificação dos investimentos certos a serem feitos no desenvolvimento da fábrica de software. Esse processo o ajuda a obter o melhor retorno sobre investimento em termos de previsibilidade, produtividade e qualidade. Ele o ajuda a comparar os resultados às metas inicialmente definidas antes de você iniciar o desenvolvimento da fábrica.

Utilização dos pontos de função para expressar o tamanho do produto

Um dos aspectos do desenvolvimento de software que provavelmente queremos melhorar é a produtividade. Para quantificar a produtividade, você precisa de uma métrica que possa ser utilizada para expressar produtividade em termos de volume criado em um determinado período. Quando somos capazes de prever o tamanho do sistema e medir o crescimento do tamanho do produto durante o desenvolvimento, podemos prever melhor o tempo necessário para concluir o projeto e medir a produtividade em termos de horas gastas por unidade de tamanho de produto. Medindo o crescimento e tamanho reais, somos capazes de identificar diferenças entre os valores reais e planejados e começar a analisar e gerenciar as diferenças quando se tornam aparentes.

Neste momento, você deve estar se perguntando como podemos prever o tamanho do produto e o crescimento com a precisão suficiente para tornar esse tipo de medida e análise úteis. Certamente não parecerá possível se estivermos desenvolvendo aplicativos arbitrários de um projeto de cada vez. Se estivermos utilizando a fábrica de software, entretanto, teremos duas vantagens que melhoram significativamente a previsibilidade. Primeiro, estamos desenvolvendo um membro de uma família específica de produtos com características conhecidas, não apenas um aplicativo arbitrário. Como a fábrica nos permite descrever uma família de produtos e seus recursos de destaque, e mais importante ainda, refinar essa descrição como experiência obtida no decorrer de diversos projetos, sabemos muito mais sobre um aplicativo que está sendo desenvolvido utilizando uma fábrica do que sabemos sobre um aplicativo arbitrário. Em segundo lugar, estamos desenvolvendo o aplicativo aplicando diretivas prescritivas fornecidas pela fábrica. Portanto, executamos diversas tarefas de desenvolvimento muito similarmente de um aplicativo para o outro, utilizando alguns dos mesmos padrões, modelos, bibliotecas e ferramentas. Se padronizarmos o modo como fazemos as coisas, a fábrica tenderá a remover variações gratuitas de um processo de desenvolvimento, tornando-a muito mais provável que o tamanho e o crescimento do produto seguirão padrões de um aplicativo para o próximo. Se estivermos utilizando uma fábrica de software, medir esses valores e identificar, analisar e gerenciar as diferenças entre seus valores reais e planejados poderá ser extremamente útil.

Já existem muitos métodos de estimativas que podem ajudá-lo a determinar o tamanho de seu sistema. Se você quiser uma métrica que possa ajudá-lo a expressar tamanho e produtividade, precisará de uma quantificação objetiva. Essa quantificação objetiva pode ser conseguida com o método que é padronizado. Um desses métodos é o Functional Size Measurement (medida de tamanho funcional), definido na norma ISO 24570. (A ISO/IEC 24570:2004 especifica um método para medir o tamanho funcional do software, oferece diretrizes sobre como determinar os componentes de tamanho funcional do software, especifica como calcular o tamanho funcional como resultado do dito método e oferece diretrizes para o aplicativo do dito método.). Essa norma ISO usa pontos de função como modo de expressar o tamanho do sistema do software com base nas especificações funcionais. Esses pontos funcionais podem ser considerados como uma "medida bruta" para determinar o tamanho de um sistema e estimar o esforço e cronograma. Durante o desenvolvimento, essa métrica pode ser usada para determinar se o projeto requer mais ou menos trabalho em relação a outros projetos similares.

Com os pontos de função, você define o tamanho do sistema em termos de funcionalidade de negócios. Essa funcionalidade é determinada dos requisitos anteriores que você reuniu, e classificada com a especificação. A análise de ponto de função alavanca o conhecimento da criação de aplicativos orientados a banco de dados e pode ser aplicada sempre que você criar um sistema que use manipulação de dados em um banco de dados. Os pontos de função são calculados em torno do conhecimento do número de tabelas estimadas que seu aplicativo terá e do número de funções de manipulação de dados como funções de recuperação de dados e atualização de dados. A partir disso, você pode calcular um número de pontos de função que expresse o tamanho de seu produto. Depois de ter expressado o tamanho estimado de seu produto, você poderá saber quanto tempo levará para implementar um ponto de função ou mesmo usar os dados históricos já disponíveis para fazer previsões sobre quanto tempo custaria para implementar um ponto de função. Uma fábrica de software pode influenciar o tempo gasto para implementar um ponto de função (produtividade), o número de defeitos por ponto de função (qualidade) e a previsibilidade de suas estimativas.

Olhando mais de perto na previsibilidade, vimos como uma fábrica nos permite separar os recursos comuns de todos os membros da família de produtos dos recursos variáveis que estão presentes em apenas alguns membros, ou que tenha tamanhos ou características diferentes em membros diferentes. Em vez de reunir os requisitos de um determinado produto do zero, podemos, portanto, supor que ele tenha recursos comuns compartilhados por todos os membros da família, e focar na especificação apenas de seus requisitos únicos ou variáveis.

Retornando à análise do ponto de função no contexto de uma fábrica, percebemos que podemos começar com um tamanho mínimo de produto fixo que sempre teremos, pois nossa família de produtos sempre contém determinadas partes fixas. O tamanho mínimo de produto fixo é uma medida de recursos comuns da família de produtos. Podemos definir também tamanhos computáveis para muitos dos recursos variáveis que podem ser ou não adicionados ao perfil básico de nosso produto. Com essas informações, podemos estimar quanto custará uma determinada configuração de recursos. Essa informação, por sua vez, poderá nos ajudar a decidir quais recursos criar. Em outras palavras, a análise de ponto de função com base em configuração de recursos nos proporciona um modo de criar compensações informadas no que se refere a custo e funcionalidade.

Digamos, por exemplo, que aplicamos análise de ponto de função e determinamos que o sistema que estamos criando tenha um tamanho estimado de 500 pontos de função. Conforme começamos a criar este sistema, determinamos que ele custará 6.500 horas para ser criado. A partir disso, podemos expressar nossa produtividade como 13 horas (h)/ponto de função (fp).

Se tivermos também controle dos defeitos que encontramos no produto durante o desenvolvimento, o teste de aceitação do usuário e a produção, poderemos inclusive expressar este número como métrica de qualidade. Digamos que encontramos 500 bugs durante o desenvolvimento, 50 durante o teste de aceitação e 5 após entrar em produção. Podemos expressar isso como tendo 1 defeito/fp durante o desenvolvimento, 0,1 defeito/fp no teste de aceitação e 0,01 defeito/fp na produção.

Agora, digamos que muitos desses defeitos possam ser rastreados de volta ao ponto de vista dos aplicativos de front-end. Disso, aprendemos que esse ponto de vista tem uma grande contribuição para o número geral de defeitos e podemos concentrar nossa atenção naquilo que pode ser aperfeiçoado dentro deste ponto de vista. Desse tipo de análise, podemos determinar quais pontos de vista devem ser aperfeiçoados e como aperfeiçoá-los para reduzir o número de defeitos na próxima vez em que a fábrica for utilizada. O que é muito bom em ter a quantificação do número de defeitos em uma métrica como pontos de função é que você agora pode estabelecer metas para aperfeiçoamentos que quer alcançar com seus investimentos. Por exemplo, quero que o número de defeitos/ponto de função tenha uma redução de 20% para o ponto de vista dos aplicativos front-end. A execução de análise de ponto de função e defeito em termos de pontos de vista nos oferece uma poderosa ferramenta para aperfeiçoarmos nosso processo de desenvolvimento de produto, pois nos ajuda a determinar onde estão os gargalos e, portanto, onde devemos investir e como investir para obter resultados melhores.

As métricas básicas que acabo de explicar poderão lhe informar algo para seu próximo projeto, ou até mesmo para o projeto atual, se você tiver mais desenvolvimento a fazer e ele se relacionar aos pontos de vista para os quais reuniu as métricas. Como exemplo, digamos que após reunir os requisitos e aplicar a análise do ponto de função, você sabe que o sistema terá 750 pontos de função. Você pode agora prever que implementando esses requisitos terá um resultado de cerca de 9.750 horas de trabalho e que deverá encontrar cerca de 75 bugs durante os testes de aceitação do usuário.

A precisão dessas previsões depende muito do nível de métrica que você reuniu e de quanto os projetos de desenvolvimento de sistemas futuros se parecerão com esses para os quais você reuniu as métricas. Cada ponto de vista em uma fábrica de software acomoda uma determinada quantidade de variabilidade no desenvolvimento do sistema. Por sua vez, a quantidade de variabilidade determina os tipos de ativos que o ponto de vista pode oferecer ao usuário da fábrica e, portanto, o nível de consistência de um projeto para o outro quanto a este aspecto do produto. Por exemplo, na primeira versão de sua fábrica, você pode ter apenas alguns pontos de vista que descrevem a arquitetura de seu sistema e que fornecem apenas as diretrizes para apoiar os desenvolvedores na elaboração da implementação. Os desenvolvedores utilizando esta fábrica terão de escrever muito código manualmente. No entanto, depois de criar diversos sistemas usando esta fábrica, você poderá observar que a construção da parte de interface do usuário desses sistemas tende a variar muito, pois os desenvolvedores individuais interpretam as diretrizes de forma bem diferente. A partir dessa observação, você poderia concluir que o ponto de vista da interface do usuário acomoda muita variabilidade. Quando você tiver diversos pontos de vista em sua fábrica com muita variabilidade, suas medidas e previsões serão menos precisas do que quando tiver uma variabilidade limitada nos pontos de vista.

Agora, neste momento, podemos perguntar se o nível de variabilidade em um determinado ponto de vista é realmente necessário. Caso contrário, devemos conseguir aumentar a precisão de nossas medidas e previsões removendo o excesso ou variabilidade gratuita. Por exemplo, daremos uma olhada no ponto de vista da interface do usuário novamente; mas neste momento fornecemos um conjunto de componentes de biblioteca apoiando as diretrizes e uma ferramenta gráfica que configura os caminhos de navegação do usuário. Fornecendo esses ativos, estamos formalizando alguns aspectos do processo de desenvolvimento da interface do usuário que foram definidos anteriormente sem rigidez. Essa formalização reduz o valor de variabilidade acomodada pelo ponto de vista da interface do usuário. Os sistemas desenvolvidos com essa fábrica exibirão maior uniformidade na construção da interface do usuário, tornando nossas medidas e previsões mais precisas. Como a magnitude do erro em estimativas diminui conforme a variabilidade acomodada pela fábrica diminui, a previsibilidade pode ser aperfeiçoada conforme a fábrica evolui, removendo o excesso e variabilidade gratuita. Na prática, a produtividade e a qualidade também tendem a melhorar com a previsibilidade, pois a redução da variabilidade reduz a quantidade de tempo necessária para criar um determinado recurso e o número de defeitos apresentados durante sua construção. Neste momento, é importante uma rápida palavra de precaução: Segundo a lâmina de Occam, a variabilidade deve ser reduzida ao máximo possível, mas nunca ao ponto de fazer com que o projeto demore mais tempo ou que o custo fique mais caro limitando exageradamente os desenvolvedores.

Quando você começar a utilizar pontos de função, poderá inicialmente usar dados históricos de organizações vizinhas encontrados na literatura para realizar suas primeiras estimativas. Os dados históricos são úteis, pois levam em conta as influências organizacionais – reconhecidas e não reconhecidas. A mesma idéia se aplica ao uso dos dados históricos dentro da fábrica de software. Os projetos individuais desenvolvidos com a fábrica de software compartilharão muito em comum. Mesmo se você não tiver dados históricos dos projetos antigos, poderá coletá-los do atual e utilizá-los como base para estimar o restante de seu projeto. Sua meta deve ser alternar entre a utilização dos dados organizacionais ou dados médios da indústria e a utilização de dados da fábrica e dados do projeto, o mais rapidamente possível (McConnell, 2006).

Utilização de medidas para aperfeiçoar uma fábrica

Fazendo uma linha de base ou realmente ajustando os parâmetros de produtividade e qualidade medidos em horas por ponto de função e defeitos por ponto de função, você pode analisar os dados do projeto e identificar atividades que podem demorar muito tempo, ou pontos de vista que têm uma grande contribuição de defeito. Após a calibragem, você poderá começar a mudar o modo como sua fábrica está organizada e aperfeiçoá-la de várias maneiras, como as qualificações que requer, o processo que define ou os ativos reutilizáveis que fornece. É crucial identificar as áreas que precisam de aperfeiçoamento, de modo que seus investimentos sejam bem colocados. Entretanto, isso deve ser relativamente fácil, já que agora você tem um modo de determinar quanto cada ponto de vista contribui para previsibilidade, produtividade e qualidade. Depois de ter uma linha de base colocada com os dados iniciais, você poderá executar um loop contínuo que analisa o desempenho de cada ponto de vista, utiliza essas informações para determinar o que deve ser aperfeiçoado, realiza os aperfeiçoamentos e depois repete o processo.

Esse ciclo virtuoso pode ser usado para objetivar diversas medidas. Para aperfeiçoar a produtividade, por exemplo, você pode identificar o ponto de vista menos eficiente em termos de horas/ponto de função e aperfeiçoá-lo fornecendo mais ou melhor orientação ou treinamento; aperfeiçoando os modelos usados para construir os cortes iniciais dos produtos de trabalho; fornecendo ferramentas especializadas que automatizam a construção ou modificação do produto do trabalho, etc. Uma parte-chave deste processo é estimar o custo para realizar um determinado aperfeiçoamento, estimando o provável ganho em produtividade resultante da realização do aperfeiçoamento e estimar se os resultados justificariam o investimento. Depois de implementar o aperfeiçoamento e incorporá-lo na fábrica, será possível medir se ele satisfaz as metas definidas em termos de redução de horas/ponto de função. A Figura 2 ilustra esse processo.

Figura 2. Loop de interação para desenvolvimento da fábrica

Aplicação do Visual Studio Team System

Agora que aprendemos como definir uma fábrica e usar medidas e análise para refiná-la iterativamente, considere como habilitar nossa equipe de desenvolvimento de produto para utilizar a fábrica para criar os produtos de trabalho necessários. Essa habilitação começa com um ambiente de desenvolvimento que suporta todo o ciclo de vida do produto desde o nascimento até a descontinuidade, como o Visual Studio Team System. A utilização do Team System é a chave para habilitar suas equipes de desenvolvimento de produto a se beneficiarem da abordagem descrita anteriormente.

O Team System consiste basicamente em duas partes. Os Visual Studio Team Editions (Team Edition para arquitetos, desenvolvedores e testadores) instalados na máquina de desenvolvimento são parte do Visual Studio Development IDE e fornecem ferramentas para funções específicas em sua equipe de desenvolvimento. A segunda parte é o TFS (Team Foundation Server) que serve de host para os aspectos centrais do ciclo de vida do Team System, como Version Control, Work-Item Tracking, Team Build, Team Portal e o Data Warehouse que contêm dados sobre os projetos que usam o TFS.

Implementação de uma fábrica com o Team System

Atualmente, o Team System não entende fábricas de software. Entretanto, como o Team System é tão configurável e extensível, podemos defini-lo manualmente para suportar uma fábrica de software mapeando diversas partes do esquema de fábrica em vários elementos de configuração ou pontos de extensão.

Lembre-se de que uma fábrica de software contém um esquema que descreve sua organização. Conforme vimos, o esquema de fábrica define um conjunto de pontos de vista inter-relacionados e cada ponto de vista descreve os produtos de trabalho, atividades e ativos relacionados para usuários em uma função específica. Podemos usar essas informações para configurar o Team System para desenvolver aplicativos.

Um ponto de vista pode ser mapeado para um conceito que o Team System chama de área em uma ou mais iterações. A função associada a um ponto de vista pode ser mapeada para uma ou mais funções do projeto do Team System. Na prática, diversas funções de ponto de vista serão provavelmente mapeadas para uma única função de projeto do Team System. As atividades definidas por um ponto de vista podem ser adicionadas como itens de trabalho a essas áreas na criação do projeto e diretamente atribuídas à função apropriada. Elas também podem ser documentadas pela personalização das diretrizes do processo e tipos de item de trabalho personalizados podem ser criados para rastreá-las e vinculá-las a produtos de trabalho. Alguns dos produtos de trabalho podem ser descritos utilizando tipos de item de trabalho personalizados. Ativos de conteúdo, como diretrizes, padrões e modelos podem ser adicionados às bibliotecas de documento do portal do projeto. Os ativos executáveis, como as ferramentas e bibliotecas de classe, podem ser colocados no sistema de controle de versão. Para medir e aperfeiçoar o desempenho de nossa fábrica, podemos adicionar métricas ao Team Foundation Data Warehouse.

As chaves para configurar o Team System são o assistente de criação do projeto e o modelo de processo. O assistente de criação de projeto é uma ferramenta para criação de projetos no TFS. Ele utiliza um arquivo selecionado pelo usuário denominado modelo de processo para configurar o servidor para o projeto. O modelo contém diversas seções, cada uma delas descreve o modo como uma parte específica do servidor será configurada. Com o modelo de processo, por exemplo, você pode definir tipos de item de trabalho, personalizar controle de versão, definir áreas de iterações, definir funções, atribuir os direitos apropriados a cada função, definir o portal do projeto e fazer muitas outras coisas para personalizar o ambiente de desenvolvimento e o processo de desenvolvimento.

Vamos dar uma examinada em como usar o assistente de criação de projeto e modelo de processo para configurar o Team System para suportar a fábrica de software.

Definição de itens de trabalho

O Team System usa os itens de trabalho para acompanhar o trabalho que precisa ser feito para criar um determinado produto. Os itens de trabalho descrevem o trabalho que precisa ser feito e identificam a parte responsável pelo trabalho em um determinado momento. Os itens de trabalho podem ser de diversos tipos criados para descrever diferentes tipos de trabalho. Por exemplo, um bug pode ser descrito por um item de trabalho do tipo Defeito que contém informações pertinentes à resolução do bug, como a descrição do bug, etapas para reprodução, tempo estimado para análise ou resolução o bug, etc. Os tipos de item de trabalho são criados ou modificados pela alteração das definições de XML carregadas no servidor e utilizadas durante a criação do projeto. Eles também podem ser modificados após a definição do projeto.

Alguns tipos de itens de trabalho definidos pelo MSF for CMMI Process Improvement, como Bug e Requisito, descrevem produtos de trabalho. Um tipo de item de trabalho, Tarefa, descreve as atividades realizadas para levar o produto de trabalho de um estado para outro. Os dois tipos podem ser utilizados com eficiência na fábrica, pois eles correspondem muito aos conceitos utilizados para definir a fábrica. Especificamente, podemos reservar itens de trabalho para os produtos de trabalho definidos por um ponto de vista e tarefas para as atividades associadas. Utilizando esses itens de trabalho, podemos reunir informações sobre quanto tempo é gasto em cada atividade e saber qual impacto a atividade causa na produtividade da fábrica.

Um dos problemas que você encontrará ao realizar esse mapeamento é que os itens de trabalho atualmente não se aninham. A incapacidade de aninhamento dos itens de trabalho complica a descrição dos produtos de trabalho de pontos de vista agregados ou compostos, como o ponto de vista da Camada de acesso a dados descrito acima. Você também achará que muitos dos produtos de trabalho não estão descritos explicitamente pelos itens de trabalho em um projeto de equipe típico. Por exemplo, em vez de criar um item de trabalho para descrever uma biblioteca de acesso a dados, podemos criar um item de trabalho para descrever a construção de uma biblioteca de acesso a dados, e então vinculá-lo aos arquivos originais para a biblioteca no sistema de gerenciamento de configuração. Um outro problema é que as tarefas do Team System não trazem condições pré e pós- como atividades em uma fábrica, por isso os critérios para movimentá-las dentro ou fora do escopo não são documentados e as decisões do cronograma devem ser feitas manualmente.

Definição de áreas e iterações

Os itens de trabalho podem ser vinculados a uma assim chamada área de seu projeto e a uma iteração. As áreas proporcionam um modo de reservar o trabalho em uma parte específica da solução que é de interesse quando você quer executar relatórios sobre os dados acumulados no data warehouse. As áreas no Team System correspondem muito aos conceitos de pontos de vista em uma fábrica de software, pois ambos representam áreas de interesse ou preocupação.

Quando você registra o trabalho feito em áreas específicas de interesse, pode descobrir quais áreas contêm mais bugs ou consomem mais tempo. Quando você mapeia áreas de interesse no rastreamento de item de trabalho para os pontos de vista de sua fábrica, pode usar essas métricas para fornecer a produtividade e qualidade dos pontos de vista específicos.

Para obter as informações corretas dos itens de trabalho, defina as áreas e iterações adequadamente quando começar o desenvolvimento do produto. Uma fábrica simplifica essa tarefa definindo os pontos de vista de interesse para o tipo de produto em desenvolvimento. Tudo o que você precisa fazer para definir suas áreas corretamente é definir uma área para cada ponto de vista. Depois, talvez você precise, mapear os nomes dos pontos de vista para os nomes das áreas que serão familiares a sua equipe de desenvolvimento, para que possam identificar prontamente a área a que pertence um item de trabalho.

Um ponto de partida muito bom na definição dos pontos de vista de uma fábrica é um conjunto de pontos de vista comuns que tendem a aparecer em várias fábricas. Bons exemplos de pontos de vista comuns aparecem no esquema para a Fábrica de software de colaboração de negócios (consulte a seção no final deste white paper). Dois desses pontos de vista comuns que se mostram particularmente úteis na configuração do Team System são Engenharia de sistemas e Engenharia de projetos. Na área da Engenharia de sistemas, faça uma subárvore contendo os pontos de vista arquiteturais que descrevem partes de destaque de seu sistema. Isso o ajudará a identificar quais partes do sistema têm impacto mais significativo na produtividade (tempo gasto) e na qualidade (número de defeitos). A área de Engenharia de projetos também é interessante, pois pode ajudá-lo a encontrar anomalias no modo como formalizou as atividades em seu projeto, e pode ajudá-lo a decidir se deve ou não aperfeiçoar a definição do processo em determinados pontos. A Figura 3 mostra um exemplo de áreas e iterações que refletem o esquema de uma fábrica simples que cria um aplicativo administrativo orientado a serviços com diversos front-ends.

Figura 3. Definição de área de exemplo refletindo pontos de vista

As áreas que você definir para rastreamento de item de trabalho evoluem, juntamente com a fábrica. Conforme a fábrica amadurece, o conjunto de pontos de vista que compõe seu esquema será alterado, assim como o conjunto de pontos de vista que você quer medir. A árvore da área pode ficar bastante profunda se você tentar incorporar cada ponto de vista definido pela sua fábrica. É muito importante que você não faça com que a árvore sofra uma explosão em muitos níveis diferentes. Tenha em mente que ela precisa ser muito simples, para que os integrantes da equipe possam identificar com facilidade as áreas às quais os itens de trabalho devem ser vinculados. Quanto mais profundamente aninhada a árvore, mais difícil será encontrar a área certa para um determinado item de trabalho. Se ficar muito difícil, os desenvolvedores simplesmente reservarão itens de trabalho próximo à raiz da hierarquia, derrotando a finalidade da criação de uma árvore aninhada profundamente.

Definição de funções

As funções que você cria dentro do Team System devem refletir todas as funções identificadas pelos pontos de vista no esquema da fábrica. As funções não têm de ser exatamente as mesmas que as identificadas pelos pontos de vista, mas cada função em seu projeto deve ser mapeada para uma ou mais funções identificadas pelos pontos de vista. Como as funções identificadas pelos pontos de vista são geralmente mais refinadas que as funções definidas para um projeto, uma função de projeto em geral implementará diversas funções relacionadas de ponto de vista.

Configuração de recursos do produto

Modificando o assistente e o modelo de processo, você pode habilitar configuração além da configuração habilitada pelo assistente padrão e os modelos de processo entregues com o TFS. De fato, você pode criar páginas personalizadas de assistente que deixam o usuário configurar alguns dos recursos variáveis definidos pela fábrica. Retornando ao exemplo anterior de um bloco de construção para acesso a dados configurado para usar diferentes produtos de banco de dados, você poderá querer perguntar ao usuário qual produto do banco de dados deve ser usado, e depois colocar a versão do bloco de construção pré-configurada para aquele produto no controle de versão como um ponto de partida para o projeto. Embora as fábricas de software geralmente requeiram configuração durante todo o processo de desenvolvimento, a personalização do assistente de criação de projeto e do formato do modelo do processo são um bom ponto de partida. A Figura 4 mostra como o modelo de recurso mostrado na Figura 3 pode ser configurado usando uma página do assistente personalizada.

O assistente de criação do projeto é um ótimo ponto de extensibilidade que suporta totalmente o conceito da fábrica de software. Pegue esses ativos e os desenvolva em separado. Defina a variabilidade diferente que você precisaria para o ativo a ser reutilizado, e use uma página de assistente para questionar o usuário sobre como devem ser definidas as variáveis para este projeto em particular. Depois o assistente pode fazer a personalização com base nas informações de entrada e moldar o ativo conforme as necessidades do projeto. Embora o conceito de aspectos comuns e variabilidade nas fábricas de software ultrapassem a pré-configuração desses ativos, esse pode ser o ponto de partida da personalização. Depois de um ativo selecionado ser configurado, a fábrica poderá também fornecer uma outra ferramenta de configuração para alterar as configurações selecionadas após a definição inicial do projeto.

Em uma fábrica, você usaria os modelos de recursos mostrados anteriormente para descrever os possíveis recursos a serem usados, o modo como determinadas decisões sobre um recurso podem influenciar outros recursos, e o modo como a instância fábrica é criada. Como você viu no exemplo da Figura 1, é possível criar um modelo de recurso que se assemelhe a um conjunto de recursos para uma fábrica que tem como alvo o desenvolvimento de um aplicativo administrativo usando um SOA.

A Figura 4 mostra como este modelo pode ser refletido em uma página de assistente personalizada que lhe permite pré-configurar a fábrica.

Figura 4. Página personalizada do assistente de projeto (clique na imagem para ampliá-la)

Há pelo menos duas maneiras adicionais para dar suporte à configuração na definição do projeto da equipe, além do assistente de criação de projeto. Você pode personalizar o repositório de controle de versão para prever as principais decisões de configuração que serão tomadas durante o desenvolvimento da solução, de modo que seja fácil salvar o estado da solução em gerenciamento de configuração antes de as decisões serem tomadas, e para restaurá-la posteriormente se tiver de mudar a decisão. Esta técnica é chamada backtracking. Você também pode definir os tipos de item de trabalho que capturam as decisões da configuração, e adicionar as instâncias desses tipos ao banco de dados de rastreamento de item de trabalho conforme as decisões são tomadas, para capturar os resultados, bem como programar o trabalho resultante.

Personalização do portal do projeto

O Team System tem um portal de projeto que pode ser utilizado pela equipe de desenvolvimento para compartilhar informações relevantes ao projeto. O portal também é o ponto de entrada para a orientação do processo para um modelo de processo específico, bem como para ativos reutilizáveis, como modelos e diretrizes. Os ativos reutilizáveis a serem carregados no portal serão fornecidos pelo modelo de processo. Você também pode mudar o conteúdo exibido no site da orientação do projeto. Essa personalização é executada usando um documento do InfoPath. O documento do InfoPath é compilado para criar um novo site que pode ser incorporado ao modelo do processo. Após carregar o novo modelo de processo, você poderá criar projetos de equipe que usam seu site de orientação de processo personalizado.

Adição de medidas ao Data Warehouse

O Team System Data warehouse mantém controle de todos os tipos de informações sobre o desenvolvimento da solução. Uma seção do data warehouse guarda informações sobre itens de trabalho, que são interessantes da perspectiva da fábrica, conforme descrito anteriormente. Outras seções guardam informações sobre testes, compilações diárias e outros recursos do Team System. O data warehouse pode ser estendido de dois modos para suportar a medição.

Primeiro, você pode mudar os campos a serem mantidos no warehouse para um tipo específico de item de trabalho, modificando a definição do tipo de item de trabalho, alterando os campos que ele contém ou adicionando campos a novos fatos ou dimensões no warehouse. Quando um campo é marcado como possível de sair no relatório na definição do tipo de item de trabalho, ele será adicionado dinamicamente ao data warehouse. Evidente, se você quiser mostrar relatórios sobre esses campos adicionais, também terá de criar relatórios para os dados e carregá-los no servidor de relatórios, para torná-los acessíveis a outros integrantes da equipe.

Em segundo lugar, você pode incorporar dados gerados por ferramentas personalizadas. Se sua fábrica fornecer ferramentas personalizadas que geram dados, e quiser usar os dados no data warehouse, você poderá adicionar um adaptador personalizado de data warehouse ao TFS, conforme mostra a Figura 5.

Figura 5. Arquitetura do data warehouse do Foundation Server

Por exemplo, para medir o tamanho de cada solução em termos de número de linhas de código, você criaria uma ferramenta personalizada que conta as linhas de código em um arquivo e um adaptador personalizado de data warehouse. Você também adicionaria uma etapa a sua criação diária que executa sua ferramenta personalizada nas origens na solução atual, e coloca os resultados em um arquivo. O adaptador personalizado do data warehouse reuniria as informações do arquivo e faria chamadas ao modelo de objeto do data warehouse fornecido pelo Team System para adicionar as informações ao data warehouse. Os dados personalizados podem ser exibidos com relatórios personalizados.

Utilização de construções de medida (ISO 15939)

Até agora, vimos como definir uma fábrica, refinar uma fábrica usando medidas e análises, e configurar o Team System para suportar uma fábrica. Antes de podermos reunir todos esses insights para criar e refinar fábricas de software com o Team System, temos de saber mais uma coisa: como coletar as informações certas.

O que precisamos é de definições formais das relações entre as coisas que estamos medindo e as informações de que precisamos para apoiar o refinamento. Essas definições são chamadas construções de medidas. As construções de medidas são combinações de medidas básicas, medidas derivadas e indicadores. Uma medida básica captura informações sobre um atributo único de algumas entidades de software usando um método de medição específico e é funcionalmente independente de todas as outras medidas. Uma medida derivada é definida como uma função de duas ou mais medidas básicas e/ou derivadas, e captura informações sobre mais de um atributo. Um indicador é uma medida que fornece uma estimativa ou avaliação aplicando um modelo de análise a uma ou mais medidas básicas e/ou derivadas, para abordar necessidades específicas de informações. Os indicadores são a base para a análise de medidas e tomada de decisão. Uma construção de medida descreve uma necessidade de informação, entidades e atributos relevantes, medidas básicas e derivadas, indicadores e procedimento de coleta de dados. Outras regras, modelos e critérios de decisão podem ser adicionados às medidas básicas, medidas derivadas e indicadores. A Figura 6 ilustra as estruturas de uma construção de medida (McGarry, 2002).

Figura 6. Estrutura de construção de medida

Os termos-chave sobre medidas e métodos de medição de software foram definidos na ISO/IEC 15939 na base do vocabulário de metrologia internacional ISO. Os termos usados neste white paper são derivados da ISO 15939 e PSM (Practical Software Measurement).

Definição de construção de medida

Para definir uma construção de medidas que possamos adicionar a nosso data warehouse do TFS, utilizaremos as seguintes etapas:

• Definir e categorizar necessidades de informação

  Para garantir que medimos as informações que precisamos, devemos entender claramente nossas necessidades de informações e como elas se relacionam às informações medidas. A experiência mostra que a maior parte das necessidades de informações no desenvolvimento de software pode ser agrupada em uma das sete categorias definidas pela ISO 15939: cronograma e andamento, recursos e custos, tamanho do produto e estabilidade, qualidade do produto, desempenho do processo, eficiência da tecnologia e satisfação do cliente. Um exemplo de necessidade de informação na categoria de tamanho de produto e estabilidade pode ser "Avaliar o tamanho de um produto de software para avaliar a estimativa de orçamento original".

  Essas necessidades de informação podem ser utilizadas para medir as propriedades de um ponto de vista específico em uma fábrica de software. Elas precisam ser priorizadas para garantir que o programa de medidas foque nas necessidades com o maior impacto potencial nos objetivos que definimos. Conforme descrito anteriormente, nosso objetivo principal em geral é identificar os pontos de vista cujos aperfeiçoamentos renderão o melhor retorno sobre os investimentos. Como os pontos de vista podem ser aninhados, podemos com freqüência agregar as medidas em pontos de vista de um nível superior. Por exemplo, se tivermos um ponto de vista de Interface de usuário contendo pontos de vista como Desenvolvimento de parte da Web e Autorização de usuário, poderemos agregar as medidas de satisfação do cliente de partes específicas da Web no nível da interface do usuário.

• Definir entidades e atributos

  Um atributo mensurável é uma propriedade distinguível de uma entidade de software. As entidades relevantes à necessidade de informação ("Avaliar o tamanho de um produto de software para avaliar a estimativa de orçamento original", por exemplo) podem ser um plano ou cronograma de desenvolvimento e um conjunto de linha de base de arquivos originais. Os atributos podem ser pontos de função planejados para conclusão a cada período, linhas de origem de código e uma tabela de expressividade de linguagem para as linguagens de programação utilizadas.

• Definir medidas básicas e medidas derivadas

  Medidas básicas são funcionalmente independentes de todas as outras medidas e capturam as informações sobre um atributo único. A especificação do intervalo e/ou tipo de valores que uma medida básica pode ter ajuda na verificação da qualidade dos dados coletados. Em nosso exemplo, temos duas medidas básicas: o tamanho estimado do produto de software e o tamanho real. A escala de ambas as medidas básicas recairá no intervalo entre zero e infinito. Uma medida derivada captura informações sobre mais de um atributo. Esses termos estão ilustrados na Figura 7.

  

  Figura 7. Medidas básicas e derivadas de crescimento de tamanho de software

• Especificar indicadores

  Os indicadores são a base para a análise de medidas e tomada de decisão. Eles são valores de medida apresentados aos usuários. Para utilizar um indicador corretamente, seus usuários devem entender a relação entre a medida que ele é baseado e as tendências que ele revela. A construção de medida deve, portanto, fornecer as seguintes informações para cada indicador:

  • Diretrizes para analisar as informações. Para nosso exemplo, podemos fornecer diretrizes de análise como esta: "Taxa crescente de crescimento de tamanho de software indica risco crescente para alcançar custos e orçamentos do cronograma".

  • Diretrizes para tomar decisões baseadas em informações. Para nosso exemplo, podemos fornecer diretrizes de tomada de decisão como esta: "Investigar quando a taxa de crescimento de tamanho de software tem uma variação maior do que 20%".

  • Uma ilustração da interpretação do indicador. Para nosso exemplo, podemos fornecer uma ilustração como a Figura 8 e descrever o seguinte: "O indicador parece sugerir que a taxa de produção de projeto está à frente do cronograma. Entretanto, após mais investigação, descobre-se que o tamanho real de um item tem um planejamento maior devido a requisitos ausentes que não foram identificados até o início dos testes. Alocações de recursos, cronogramas, orçamentos e cronogramas e planos de testes são afetados por esse crescimento inesperado".

    

    Figura 8. Indicador de representação gráfica, crescimento de software planejado versus real

• Definir procedimento de coleta de dados

  Agora que sabemos como relacionar as medidas básicas com as necessidades de informações, devemos definir o procedimento de coleta de dados. O procedimento de coleta de dados especifica a freqüência da coleta de dados, a pessoa responsável, a fase ou atividade em que os dados serão coletados, regras de verificação e de validação, as ferramentas utilizadas para coletar dados e o repositório para os dados coletados.

Utilização de uma construção de medida

Para utilizar uma construção de medida com êxito, devemos abordar duas questões importantes: influência de indicadores e como evitar medidas não funcionais.

Influência de indicadores

Para utilizar indicadores com êxito para análise de medidas, tomada de decisão e mudança de processos, você precisa ter certeza de que seus usuários devem saber o que representam, como interpretá-los e o que pode ser modificado para influenciar seus resultados. Para nosso exemplo, o usuário tem de entender que para fazer com que o Tamanho real nos Pontos de função corresponda ao Tamanho planejado nos Pontos de função, precisamos produzir mais pontos de função no mesmo período (ou seja, precisamos ser mais produtivos). O usuário também tem de entender como aumentar a produtividade.

Como evitar medidas não funcionais

Os tomadores de decisão também devem saber como evitar medidas não funcionais. A meta da medição é aperfeiçoar o desempenho fazendo alterações, como realizar atividades diferentes, aplicar ativos diferentes, etc. É importante garantir que as mudanças façam sentido. Você não quer que as pessoas que fazem alterações contraproducentes alcancem um resultado esperado em alguma medida. Em nosso exemplo, a pressão para alcançar o Tamanho planejado nos Pontos de função pode ser tão alta que as pessoas começariam a encher a implementação com linhas de código adicionais. Uma das chaves para realização de medição com êxito é identificar e descrever riscos. Uma prática recomendada é evitar medir indivíduos. Quanto mais significado é acoplado a qualquer indicador social quantitativo, maior a probabilidade de ele distorcer e corromper os processos que pretende ajudar a aperfeiçoar.

Juntando as peças

Finalmente, estamos prontos para combinar tudo que aprendemos e conversamos sobre como definir e utilizar construções de medidas para aperfeiçoar uma fábrica de software suportada pelo Team System.

Adição de construção de medidas ao Data Warehouse

Conforme descrito, cada construção de medida precisa definir pelo menos as necessidades de informação, as entidades e os atributos, as medidas básicas e derivadas, os indicadores e um procedimento de coleta de dados. Para mapear isso para o Team System Data Warehouse, precisamos determinar como obter as informações necessárias, modificando as definições de tipo de item de trabalho para adicionar campos e marcá-los como fatos ou dimensões, ou criando uma ferramenta personalizada e adaptador de data warehouse personalizado que colete dados produzidos pela ferramenta. Precisamos também determinar como exibir os indicadores, normalmente criando relatórios personalizados do Microsoft SQL Server 2005 Reporting Services.

Aperfeiçoamento iterativo

Depois de mapear sua fábrica para o Team System, você poderá começar a usá-lo para criar soluções. Ele guiará sua equipe na criação de soluções e lhe fornecerá informações baseadas nas construções de medidas definidas e implementadas. A partir disso, você poderá começar a analisar as medidas e utilizar os indicadores para identificar as oportunidades de aperfeiçoamento. Com essas informações, você pode decidir quais pontos de vista podem ser aperfeiçoados, quanto você pode ganhar aperfeiçoando-os e quanto investir nesse aperfeiçoamento. Finalmente, você pode fazer os aperfeiçoamentos que escolheu, geralmente adicionando orientação e fornecendo ativos melhores para suportar a criação de produtos de trabalho. Conforme você cria soluções utilizando esses aperfeiçoamentos, pode usar novamente as medidas e os indicadores para determinar como os ganhos realizados se comparam aos ganhos esperados e calibrar seu planejamento de investimento adequadamente.

Conclusão

Este white paper é motivado por um desejo de mudar o modo grosseiramente ineficiente em que criamos software hoje em dia com desenvolvimentos únicos ou um projeto de cada vez. Nossos clientes percebem que nos esforçamos para entregar os projetos no prazo, dentro do orçamento e com os recursos esperados. Podemos nos ajudar e ajudar nossa indústria como um todo, adquirindo o conhecimento que ganhamos em nossa experiência e transferindo-o para outros projetos usando fábricas de software. Aprendemos como definir uma fábrica e como medir seu desempenho em termos de produtividade e qualidade.

Quantificando os tamanhos de produtos que criamos, medindo o tempo gasto para criá-los e registrando o número de defeitos encontrados, podemos descrever o desempenho de nossas fábricas. O mapeamento do esquema da fábrica para o Team System é feito com os pontos de personalização e extensibilidade no Team System. Podemos definir o Team System colocando os ativos identificados pelo esquema da fábrica no repositório de controle de versão ou pelo portal de fundação da equipe. Podemos usar o portal para fornecer orientação do processo para atividades descritas pelo esquema da fábrica. Podemos usar o assistente de criação de projeto para organizar a definição inicial de nossa fábrica e usar modelagem de recurso para criar um mapeamento para definir formulários a serem adicionados ao assistente. Uma grande parte do projeto inicial é feita usando os modelos de processo e podemos modificar os modelos para dar suporte a nossas fábricas.

Definindo as construções de medidas e implementando-as no Team System Data Warehouse, podemos reunir métricas que descrevem o desempenho da fábrica de software em termos de produtividade e qualidade. Com o tempo, podemos usar essas métricas para aperfeiçoar nossas fábricas constantemente, bem como para ganhar não apenas produtividade e qualidade, mas também previsibilidade, removendo variabilidade gratuita ou excessos.

O resultado final da implementação de fábricas de software com o Visual Studio Team System é projetos mais bem-sucedidos e maior satisfação do cliente.

Referências

Austin, Robert D. Measuring and Managing Performance in Organizations. Nova York, NY: Dorset House Publishing Co., Inc., 1996.

Greenfield, Jack, and Keith Short. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Indianápolis, IN: Wiley Publishing, Inc., 2004.

McConnell, Steve. Software Estimation: Demystifying the Black Art. Redmond, WA: Microsoft Press, 2006.

McGarry, John, et al. Practical Software Measurement: Objective Information for Decision Makers. Boston, MA: Addison-Wesley Professional, 2002.

Sobre os autores

Marcel de Vries é arquiteto de TI na Info Support na Holanda, bem como Visual Studio Team System MVP. Marcel é o arquiteto líder da fábrica de software Endeavour, que tem como alvo a criação de aplicativos administrativos empresariais orientados a serviços utilizados em muitos grandes clientes empresariais da Info Support. Marcel é um palestrante conhecido em eventos locais na Holanda, incluindo dias do desenvolvedor e Tech-Ed Europe. Ele também trabalha meio-período como treinador no centro de conhecimento da Info Support. Você pode ler seu blog em http://blogs.infosupport.com/marcelv/.

Jack Greenfield é arquiteto de estruturas e ferramentas empresariais na Microsoft Corporation. Ele foi anteriormente chefe de arquitetura, profissional do grupo de desktop na Rational Software Corporation, e fundador e CTO da InLine Software Corporation. Na NeXT Computer, desenvolveu a estrutura de objetos empresariais, agora uma parte dos objetos Web da Apple Computer, Inc. Palestrante e escritor conhecido, ele é co-autor (com Keith Short, Steve Cook e Stuart Kent) do premiado best-seller Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Jack também contribuiu para UML, J2EE e OMG relacionada e especificações JSP. Ele é formado em física na George Mason University.