Realizar a modelagem arquitetural de um sistema não é uma tarefa trivial. Uma arquitetura tem na maioria das vezes muitos stakeholders envolvidos, tais como os usuários finais, clientes, administradores de sistema, gerente de projetos, analistas de suporte, desenvolvedores, testadores e até outros sistemas. Além disso, cada stakeholder apresenta problemas e demanda requisitos e restrições das mais diferentes naturezas tais como desempenho, usabilidade, segurança, tecnologias legadas ou normas governamentais.

Dado este cenário, apresento aqui uma resenha de um método que tem ganho bastante popularidade nos círculos arquiteturais e já possui dezenas de casos de referência aqui no Brasil. O método, chamado de visão 4+1, foi originalmente publicado por Philip Krutchen, um dos “pais” do processo unificado da Rational (RUP), em 1995 na IEEE - The 4+1 View Model of Architecture.

O método usa a mesma premissa usada na modelagem de “sistemas” complexos na engenharia, onde a complexidade é representada não por um, mas por um conjunto de modelos tais como plantas baixas, plantas estruturais, hidráulicas, elétricas, entre diversas outras.

Na modelagem arquitetural, o método assume como ponto de partida (o elemento +1) um conjunto de cenários significativamente relevantes para a modelagem arquitetural. Um cenário é um caminho ou percurso percorrido por um usuário na sua interação como o sistema sob desenho. Um cenário relevante é um percurso que representa, na visão do arquiteto, um risco ou ponto de atenção para o projeto. Por exemplo, em um projeto que lide com a integração de um sistemas entre plataformas baixas e altas, podemos elencar um cenário de transporte de informações (interoperabilidade) para análise. Uma lista de casos de uso pode ser um ponto de partida para que estes cenários sejam elencados.

Para cada cenário elencado, podemos explorá-lo em diversas outras visões UML conforme os requisitos arquiteturais do pojeto. Estas visões são, respectivamente:

• Visão Lógica - Representada através de diagramas de classes e pacotes para capturar a funcionalidade (domínio) sob desenho.
• Visão de Componentes - Representada através de um diagrama de componentes para capturar a gerência de configuração de um sistema (executáveis, DLLs, componentes e outros elementos).
• Visão de Implantação - Representada através de um diagramas de implantação para capturar a distribuição física de uma aplicação entre os seus elementos físicos (máquinas, nodos) e também servidores de banco de dados, aplicações, messageria e orquestração, entre outros.
• Visão de processos - Representada através de diagramas UML de estruturas compostas, diagramas de estados e atividades para representar concorrência entre threads, contenção de objetos, entre outros aspectos fundamentais na modelagem de sistemas de tempo real.

Nem todas as visões são obrigatórias. Algumas dicas para escolher que visões usar incluem:

• Em sistemas pequenos (ex: cliente-servidor), podemos ignorar a visão de implantação e implementação.
• Em sistemas de informação, normalmente podemos ignorar a visão de processos.

Podemos elencar cinco vantagens primárias do uso deste método.

1. As múltiplas representações capturam os interesses de múltiplos stakeholders.
2. As múltiplas representações permitem realizar validações cruzadas e expor falhas prematuras no modelo.
3. As visões estão centradas nos cenários de risco do projeto e portanto representam uma estratégia de mitigação de riscos técnicos.
4. As visões são independentes e podem ser escolhidas conforme o contexto do problema sendo atacado (uso de duas, três, quatro ou cinco visões).
5. Finalmente, estas visões permitem realizar um elo entre a visão do usuário (casos de uso) e o código. Sem estas visões, o desenvolvedor realizaria suposições diversas e provavelmente cada caso de uso teria um determinado formato. Em outras palavras, teríamos um sistema sem coerência arquitetural (estratégica). Metaforicamente, estaríamos criando um animal com patas de elefante, asas de morcego e cabeça de tamanduá.

Para quem quiser buscar maior embasamento neste método, minha recomendação primária é o RUP versão 7, disponível em português. Outros papers relevantes são:

• Architectural manifesto: Designing software architectures, Part 5 - Introducing the 4+1 view model
• Paper original do Kruchten - The 4+1 View Model of Architecture

Devemos lembrar, entretanto, que a visão “4+1″ nunca foi proposto para ser usado como única técnica. Em outros sistemas, entretanto, devemos avaliar a extensão do modelo 4+1 para incluir outras visões tais como a visão de dados, uma visão de análise de causa raiz ou uma visão de processos de negócio.

Pensamendo do dia:

“Os muito poderosos e os muito estúpidos possuem uma coisa em comum. Ao invés de alterarem as suas visões para se ajustarem aos fatos do mundo, eles alteram os fatos para ajustá-los às suas visões.”, Doctor Who.

O senso comum nos diz que a coleta de requisitos nos ajuda a entender um determinado problema. Entretanto, requisitos são uma forma de definir uma solução e não de entender um determinado problema. Para entender um problema, devemos trabalhar em suas causas raízes através de técnicas formais chamadas de identificação e análise de problemas.

Estas técnicas de identificação e análise de problemas são trabalhadas em uma excelente apresentação por um autor chamado Kurt Bittner que trabalhou anos na Rational como gerência de requisitos e possui excelentes livros de modelagem de casos de uso. Faço aqui um resumo destas técnicas, que devem estar no arsenal de qualquer analista de requisitos, e compartilho ao final deste blog o excelente material disponibilizado por este autor.

• Técnicas dos Cinco Porquês (5P). Esta técnica é uma abordagem usada para explorar relações de causas e efeitos de um determinado problema. Por exemplo, se recebemos uma requisição do tipo “Precisamos de um novo Web Site”, devemos recursivamente nos perguntar o porquê desta requisição. Por exemplo: “Estamos perdendo espaço para os competidores”. Mas porque estamos perdendo espaço para os competidores? Talvez seja porque o nosso site não reflita as nossas ofertas atuais de produtos. E continuamos neste processo até que a verdadeira causa raiz do problema (e não o sintoma) esteja elicitado. O número 5 é uma referência básica (número mágico) do número de questionamentos a serem feitos.
• Espinhas de Peixe (Diagramas de Ishkawa). Esta técnica permitir categorizar as causas raízes de um problema e agrupá-las adequadamente. Como esta técnica utiliza esquemáticos gráficos, ela é ideal para brainstorming de grupos e permite representar muitas perspectivas associadas a causas de um determinado problema.
• Mapas mentais. É uma alternativa a diagramas de espinha de peixe em um formato gráfico mais livre. Esta técnica tem se tornado bastante popular com a disseminação de ferramentas para a montagem de mapas mentais (MapMinds).
• Gráficos de paretos. Um gráfico de pareto (Pa Ray To) é um gráfico de barras onde os valores plotados são arranjados em ordem decrescente. Entretanto, esta técnica somente se aplica se possuimos dados sobre as possíveis causas de um problema.

Além destas técnicas, um outro aspecto interessante na análise de problemas é a determinação de “objetivos” ou resultados desejados. Isto porque é inútil trabalhar em um problema (e suas causas) se não existe um objetivo claro ou preciso a ser alcançado. Neste caso, a técnica de “resultados desejados” pode ser usada. Um “resultado desejado” é algo que o usuário ou cliente deseja alcançar no uso da solução. Para isso, devemos associar a cada requisito um resultado desejado e garantir através de uma matriz de rastreabilidade que não existe um “resultado desejado” sem a cobertura de requisitos.

O resumo de toda esta questão é que a “análise de problema” é algo diferente das técnicas de “coleta e elicitação de requisitos”. Requisitos definem soluções. Antes da definição de requisitos, entretanto, devemos conhecer os problemas e oportunidades que queremos tratar.

A apresentação com estas técnicas está disponível aqui para download.

Pensamento do dia:

“Quem tem somente um martelo como ferramenta, tende a achar que tudo que existe no mundo são pregos”

.

Toda a nossa escola de gerência de projetos tradicional vêm da escolha de gerência de projetos da engenharia. Como exemplo, cito o PMI, talvez a escola mais difundida e aceita de gerenciamento de projetos de TI no Brasil e EUA. O PMI foi criado ainda no final dos anos 60 e seus membros iniciais eram pessoas de engenharia civil. Na escola de engenharia, o paradigma de planejamento detalhado e acompanhamento minuncioso deste planejamento é o modelo mental ainda usado no nosso seculo XXI.

Na área de TI, copiamos este modelo e também as ferramentas (como o Project ou o Primavera). Entretanto, algo parece errado. Quantos projetos eu já acompanhei (como participante, observador ou como executor do cronograma) onde a nossa inabilidade de montar e seguir um plano detalhado foi tornada aparente (e frustante). Várias vezes me questionei - “Algo está errado, mas não sei muito bem o quê”.

Felizmente, parecem existir evidências fortes que estamos usando o modelo errado para atacar um problema comum em TI, que é como gerenciar projetos e obter sucesso.

Gostaria de compartilhar um artigo que li na IEEE, de um autor de renome (Walker Royce) na área de gerenciamento de projetos e que lança luz neste tema - Successful software management style: Steering and balance. Embora controverso, devemos realizar algumas análises sobre a essência de projetos de software. Projetos de software, de forma geral, possuem as seguintes características (identificadas por Walker Royce):

• Não existem leis físicas ou de propriedades de materiais para restringir as soluções aos seus problemas. A restrição está na imaginação humana, restrições econômicas e desempenho da plataforma física que hospedará o software. Sistemas embutidos, obviamente, são excecões.
• Tudo pode ser mudado em um projeto de software - planos, pessoas, financiamentos, marcos, requisitos, desenhos e testes. Praticamente tudo é negociável.
• Métricas e medidas para produtos de software normalmente são melhor avaliadas através de modelo de valor percebido pelo usuário do que modelos clássicos de engenharia como custo e produção. Aspectos de qualidade são muitas vezes subjetivos como por exemplo manutenabilidade, confiabilidade e usabilidade.

Concordo em linhas gerais como esta análise. Uma outra força neste aspecto é o tempo de vida de uma arquitetura de software. Em um recente artigo na InfoQ, Sadek Drobi conjectura que uma arquitetura expira em dez anos - “Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture“. Após este período, as manutenções se tornam cada vez mais caras e o sistema deve ser refatorado em uma nova arquitetura, sob o risco de gerar cada vez mais prejuízos para o negócio. Esta força mostra como a inventidade humana e inovações dificultam a aplicação de leis comuns em engenharia civil como por exemplo “Fazer para durar”.

A conclusão, que eu concordo, é que a melhor metáfora para a construção de softwares é a concepção de um filme. Precisamos, como apontado por Walker Royce, de arquitetos qualificados (diretores), analistas (roteiristas), engenheiros de software (equipe de produção, atores, editores, dublês) e gerentes de projeto (produtores). Entretanto, a metáfora técnica é que a disciplina de gerência de projetos é regida pela disciplina software economics ao invés da disciplina de software engineering. As decisões diárias de gerentes de projetos de software são dominadas por julgamentos de valor, relações de custo benefício, fatores humanos, tendências macro-econômicas, forças de mercado e pressões gigantescas de tempo. A escola de Software Economics, que tem como um de seus mentores Barry Boehm, pode ser definida como a escola científica de desenho de software fundamentada em modelos formais de valores e criação de valores em condições de incerteza, informações incompletas e competição.

O planejamento iterativo (ou planejamento em duas fases) no processo unificado é um escolha de gerência de projetos muito mais adaptável a esta realidade. O planejamento iterativo define planos em alto nível para as etapas de um projeto e somente realiza o planejamento detalhado para a etapa atual. Neste contexto, podemos incluir o SCRUM aqui também. O SCRUM nos ajuda a organizar a dinâmica de eventos variáveis e lidar com as exceções (impedimentos) que vivemos (enquanto gerentes de projetos) em uma iteração (etapa) específica de um projeto. Coloco, então, o SCRUM como um complemento natural ao planejamento iterativo do RUP.

A escola de metologias ágeis de gerenciamento de projeto Extreme Project Management (XPM), embora sem menção explícita a metáfora de filmes, usa princípios similares para o planejamento e acompanhamento de tarefas.

Começamos a observar o nascimento de ferramentas mais adequadas a este paradigma. Apesar de considerar ferramentas como o Primavera ou o MS Project excelentes, não as considero adequadas para o gerenciamento de projetos de TI. Estamos usando um martelo para bater em algo que não é um prego!

Uma versão mais leve do artigo do Walker Royce está disponível aqui no portal da DeveloperWorks da IBM. Recomendo fortemente a leitura deste artigo. São idéias valiosas (embora polêmicas), mas que me parecem descrever melhor a nossa realidade de projetos de TI.

Artigos mais detalhados e referências para os interessados nas escolas alternativas de gerência de projeto estão abaixo:

• Planejamento Iterativo - Planning an Iterative Project.
• SCRUM - Scrum it Now na Prática
• XPM - Extreme Project Management

Finalmente, deixo também uma coleção de publicações sobre a escolha chamada Software Economics, referenciada por Walker Royce em seu artigo.

Gosto do título desta frase, que remonta ao inglês arcaico do século XVI (”Byrdes of on kynde and color flok and flye allwayes together”) e que metaforicamente diz que pessoas com interesses comuns se juntam e permanecem juntas em suas atividades.

Tive a chance de acompanhar dois interessantes eventos de comunidades esta semana (SUN Tech Days - Capítulo MG e o Primeiro Encontro de Comunidades Microsoft de Minas Gerais) e presenciar como redes sociais físicas podem potencializar e criar valor único para todos os seus participantes

O primeiro evento foi organizado pelo MGJUG, comunidade de usuários Java de Minas Gerais. Embora o evento tenha deixado a desejar no seu número de participantes, tivemos a oportunidade de acompanhar três boas palestras em temas como SOA e Java Mobile. Em particular, a SUN divulgou o seu programa de parceria acadêmica que fornece benefícios bem interessantes a alunos das faculdades credenciadas.

O segundo evento foi um encontro para fomentar a criação de comunidades ligadas a temas Microsoft (tecnologias e produtos). Atualmente já existem algumas comunidades em Minas Gerais como por exemplo os .NET Raptors ou o CanalSharePoint. O evento propôs a criação de diversas comunidades que terão espaço permanente no portal de redes sociais do Mundo IT, do Yuri Gitahy. Inicialmente as comunidades de BI, Gerência de Projetos, InfraEstrutura e Arquitetura de Software serão criadas no mundo IT. Impossível não citar também as excelentes palestras e depoimentos do Ricardo Guerra (coordenador regional da INETA - organismo responsável por fomento às comunidades de desenvolvimento Microsoft) e também do Marco Aurélio Peres (Coordenador do grupo de SharePoint MG) , entre vários outros, que mostraram o quão bem organizada a Microsoft é no fomento a programas de parcerias e comunidades. A quantidade e qualidade destes programas é mais um aspecto invejável (no bom sentido da palavra invidia) e que deveria ser copiado por comunidades open-source e empresas como a IBM, SUN ou Oracle.

A mensagem é simples. Se você tem algum interesse, busque comunidades para potencializar o seu interesse, compartilhar experiências e aprender com os nossos amigos de trabalho. Afinal, como diz um outro ditado - “Nenhum de nós é melhor que todos nós”.

A metodologia ágil de gestão de projetos e demandas SCRUM tem se tornado cada vez mais popular e praticada no mercado Brasileiro. Embora este método possa ser implementado em quadro brancos e post-its, ferramentas ágeis podem ser usadas para implementá-lo também. Uma interessante ferramenta lançada este ano, o Rational Team Concert, gratuita para times de até 3 pessoas, possui um suporte completo e personalizável do SCRUM. Li recentemente um excelente paper de como tornar o SCRUM executável, disponível aqui. Este paper discute o uso do Rational Team Concert para implementar o SCRUM na prática.

Para quem ainda não conhece o SCRUM, recomendo um vídeo que recebi recentemente. O vídeo é do Ken Schwabber, um dos seus criadores. Este autor também mantém um excelente blog sobre o SCRUM aqui.

Finalmente, para não banalizar o método, uma entrevista bacana do nosso guru Martin Fowler foi disponibilizada recentemente no InfoQ com informações interessantes sobre como não deturpar esta metodologia

O grupo JBOSS (agora incorporado pela RedHat) tem trazido soluções cada vez mais robustas e completas para a implementação de uma arquitetura sólida de TI e para suporte a iniciativas BPM/SOA. Antes restrito apenas ao mercado de servidores de aplicação com o produto JBOSS AS , o grupo JBOSS está ganhando espaço no disputado mercado de middleware de aplicações.

Esta plataforma (chamada JBOSS Enterprise Middleware Systems) é descrita tecnicamente em uma apresentação gravada no JBOSS RoadShow (Apresentação JEMS), evento técnico do grupo JBOSS que circulou as principais capitais brasileiras neste ano de 2008. Encontramos no link acima também a visão do grupo JBOSS para SOA e um novo produto (JBoss Operations Network), comprado pela RedHat, para cuidar da monitoração de servidores de aplicação e também para suporte a BAM (Business Activity Monitoring).

Alternativamente aos vídeos, as várias apresentações deste evento foram também disponibilizadas em PDF neste link.

Tive a sorte de poder acompanhar e trabalhar com Java desde o começo da linguagem, em 1995. Naquela época, o papel do arquiteto de software era algo praticamente inexistente no Brasil e a menção a estes termos era distante e mencionado por pessoas como Grady Booch, Bertrand Meyer, Erich Gamma, Dana Bredenmeyer, Paul Clements e outros visionários. Desde o começo do século XXI, entretanto, a figura do arquiteto de software começou a se tornar popular no Brasil e em Belo Horizonte. Três fatores que ajudaram neste espalhamento foram o processo unificado (UP), a plataforma Java e a certificação SUN SCEA.

O processo unificado (UP), em minha visão, teve uma importância ímpar no espalhamento da figura do arquiteto. Isso é claro em um livro chave de 1995 chamado Object Solutions, de Grady Booch. Por o processo unificado (e suas derivações como o AUP, RUP ou EUP) ser um processo dirigido por cenários arquiteturais, vários gerentes e várias empresas começaram a entender a importância da figura do arquiteto. Hoje, 2008, toda fábrica de software de porte no Brasil possui algum arquiteto de software em seu corpo de profissionais.

A plataforma Java, por sua grande inovação e grande complexidade exigia também um outro tipo de papel além do clássico programador (hacker) no sentido original e bom desta palavra - sem nenhuma relação com os crackers.

A certificação SUN Java Certified Enterprise Architect também teve um papel chave para que a figura do arquiteto fosse conhecido. Isso certamente foi bom. Isso reconhecou a nossa profissão no mundo Java e nos valorizou profissionalmente. Entretanto, o objeto deste blog é avaliar o quão fraca são as certificações das empresas “Java” de mercado e constatar (heresia!?) que a certificação mais completa de arquitetura de mercado é de uma empresa que não pratica Java.

A certificação Java SCEA certamente foi muito bem construída e muito trabalho sério e competente foi colocado ali. Ela mede, sem dúvida, o nosso conhecimento de Java e aspectos de design de Java EE, APIs Java EE e os Core Java EE Patterns. Entretanto, aos analisarmos os seus objetivos vemos que diversas habilidades de um arquiteto de software não são trabalhados.

Alguns destes aspectos incluem:

• Experiência prática. Todos sabemos que um arquiteto Java que não tem uma vasta experiência prática de projetos (medido em milhares de horas como desenvolvedor e líder técnico) é igual a uma nota de 3 reais.
• Habilidades de liderança. A principal característica de um arquiteto é a capacidade de estabelecer autoridade moral dentro de um time para conseguir transmitir boas práticas e criar uma visão arquitetural e uma arquitetura executável adequada para o projeto.
• Compreensão de aspectos de negócios. Um arquiteto deve conhecer sobre arquiteturas de negócio e saber avaliar requisitos de negócio para saber como a sua solução técnica irá realizar estes aspectos.
• Habilidades de gestão de riscos técnicos. Fazer uma arquitetura é, em boa parte, gerir e mitigar riscos técnicos.
• Conhecimento lateral de tecnologias. Um arquiteto Java deve conhecer (mesmo que superficialmente) outras tecnologias além de Java (ex: Estratégias de EAI, Protocolos de EDI, Plataformas Altas, Bancos de Dados, Sistemas de Messageria, Sistemas de Orquestração de Processos, Ferramentas de BI, Portais, CRMs, ERPs, Sistemas Especialistas para o negócio sendo modelado, Usabilidade, Segurança da Informação, Testes de Desempenho, Planejamento de Capacidade, Processos de Software, Metodologias Ágeis, Redes, BPM, SOA, ITIL, Six Sigma e COBIT).
• Forte conhecimento de métodos arquiteturais (ex: SEI ATAM, RUP 4+1, ARID, FURPS+, ISO 9126).
• Arquiteturas corporativas. (ex: EABOK, TOGAF ou Zachman Framework).

As certificações com título de arquiteto da IBM e BEA, entre outras que observo, medem conhecimentos semelhantes à certificação de Java EE da SUN. Elas pecam, novamente, por não avaliar alguns dos aspectos citados acima.

Tentarei explicar aqui porquê o programa de certificação de arquitetura da Microsoft é tão rico e mais apropriado para alguém que queira trabalhar com arquitetura de software.

• Ele é um programa e não uma prova. Esta certificação é um processo com um tutor do núcleo de arquitetura da Microsoft que culmina na defesa de um projeto do mundo real perante uma banca para a avaliação das habilidades, conhecimentos e atitudes do candidato.
• As principais competências exigidas e avaliadas são (nesta ordem) - Forte conhecimento do negócio, Pensamento Inovador e Estratégico, Capacidade de Investigar Novas Tecnologias, Conhecimento de Frameworks Arquitetônicos e Melhores Práticas, Capacidade de Usar e Criticar Frameworks, Capacidade de Atingir Rápida Proficiência em Qualquer Tecnologia e Capacidade de Trabalhar com Informações Incompletas,

Como curiosidade, em todo o texto detalhado das competências exigidas por esta certificação, a palavra C# não é mencionada uma única vez. A palavra “Java EE” é citada uma vez! Uma outra curiosidade é que a primeira característica citada nesta página chama-se: Liderança.

Infelizmente, esta certificação (MCA) é muito cara (pelo menos para mim!) e requer a defesa em território americano. Talvez não por acaso existam somente 90 pessoas no mundo com esta certificação. Obviamente, esta certificação não é perfeita. Nenhuma certificação o é, mas ela consegue medir mais adequadamente, em minha modesta opinião, o que esperamos de um arquiteto de software em um projeto de TI.

Gostaria que a SUN, a IBM ou mesmo a Microsoft tivessem uma certificação como essa sendo executada em terrítório Brasileiro, com preços mais acessíveis. Até lá, é muito importante ter cuidado com “arquitetos de papel” que habitam o nosso mercado com suas certificações reluzentes.

Uma nota final. Para quem ficou interessado no programa da Microsoft (que inclui também 4 semanas obrigatórias de treinamento em Redmond), segue o link com mais informações.

O BPM ganha cada vez mais espaço nas empresas como uma excelente forma de se realizar a gestão por processos de uma organização e também alinhar ações de TI com as áreas de negócio.

Para simplificar o aprendizado de BPM, a IBM lançou um jogo (!!!) gratuito para BPM. .

Instalei recentemente o jogo e tenho me divertido consideravelmente com ele. Acredito em mecanismos lúdicos de aprendizagem e o que mais me impressionou foi a excelente qualidade dos gráficos e o interessante roteiro do jogo. Em resumo, você é um analista de processos de negócio e você tem a missão de resolver um gargalo em um determinado processo de negócio que apresenta KPIs inaceitáveis. Você tem uma noite para resolver o problema e colocar a empresa no rumo novamente.

Mais informações sobre o jogo, chamado Innov8 (trocadillho para innovate), podem ser encontradas aqui.

O tema de arquitetura de software é bastante árido e desafiante. Um bom arquiteto deve contar, para projetar boas arquiteturas em projetos complexos, bons guias de referência. Dezenas de excelentes livros existem, mas gostaria de recomendar três livros que considero essenciais na estante de todo arquiteto e de toda empresa que produza software. Estes livros vêm de uma compilação do trabalho e experiência do núcleo de trabalho de arquitetura do SEI.

O primeiro é o livro Software Architecture in Practice. Este clássico sobre arquitetura de software cobre aspectos técnicos e gerenciais necessários para um bom projeto de arquitetura e apresenta excelentes exemplos e casos reais da aplicação destes conceitos em projetos.

O segundo é o Evaluating Software Architectures - Methods and Case Studies, que lida com o aspecto de avaliar a qualidade de sistemas legados e novos projetos. Em particular, o método ATAM (Architecture Tradeoff Analysis Method) é explicado e exemplificado com bastante clareza.

Finalmente, o terceiro livro é sobre um aspecto chave em arquitetura de software, chamado comunicação. O livro Documenting Software Architectures fornece valiosos conselhos sobre como expressar arquiteturas de software para analistas, gerentes, técnicos, testadores e outros stakeholders em projetos.

Fábricas de software têm se tornado cada vez mais populares, seja na esfera governamental ou na esfera privada; para suporte às operações de tecnologias de informação. A organização de uma fábrica de software, entrentanto, é bem diferente da execução de um projeto de software e requer outros papéis e habilidades.

Mas o que é uma fábrica de software? Uma primeira definição poderia ser: “Uma área de uma empresa que organiza um conjunto de sistemas de software intensivos que compartilhem um conjunto de requisitos para um segmento de mercado e que são desenvolvidos a partir de um conjunto de ativos comuns de forma previsível”.

Uma fábrica de software, segundo o SEI, deve operar em três dimensões, colocadas a seguir:

• Práticas de Engenharia de Software.
• Práticas de Gerência Técnica.
• Práticas de Gerência Organizacional.

As práticas de engenharia de software envolvem as seguintes áreas: Definição de Arquitetura, Avaliação de Arquitetura, Desenvolvimento de Componentes, Reuso de Ativos Existentes, Engenharia de Requisitos, Integração de Sistemas de Software, Testes, Entendimento de Domínios Específicos, Uso de Softwares Disponíveis Externamente.

As práticas de gerência técnica envolvem: Gerência de Configuração, Análise Make/Buy, Medições, Engenharia de Processos, Gerência de Escopo, Planejamento Técnico, Gerência de Riscos Técnicos e Suporte de Ferramentas.

As práticas de gerência organizacional envolvem: Organização de Business Case, Gerência de Interface com Clientes, Estratégia de Aquisição, Custeio, Iniciação e Institucionalização, Análise de Mercado, Operações, Planejamento Organizacional, Gerência de Riscos Organizacionais, Estruturação da Organização, Previsão de Uso de Tecnologias, Treinamento.

Felizmente, muitas destas informações já foram compiladas em um rico corpo de conhecimento do SEI chamado A Framework for Software Product Line Practice, que está em sua versão 5.0.

Uma rápida introdução ao conceito de uma fábrica de software é apresentado aqui.

Além disso, o SEI também apresenta documentação para aquisição e governança de fábricas de software, montagem de fábricas de software e até mesmo padrões para fábricas de software (Software Product Lines Patterns). Estas informações são compiladas no portal de fábricas de software da SEI.

Finalmente, recomendo o seguinte livro de referência deste trabalho (Software Product Lines: Practices and Patterns), que compila as principais idéias do framework SEI para organização de fábricas de software e principais padrões para adoção destas na sua organização.