Introdução às áreas de trabalho

Conceitos básicos

Ao implementar áreas de trabalho, é possível modelar diversas versões de uma arquitetura no IBM® Rational® System Architect. É possível criar diversas versões de uma arquitetura para estes cenários:

• Implementação em uma arquitetura empresarial
• Implementação em uma arquitetura no estado em que se encontra e uma arquitetura futura
• Integração de um sistema de arquiteturas de sistemas
• Realização de uma análise de trocas

O conceito de área de trabalho é simples. É semelhante ao conceito de uma enciclopédia. A implementação de áreas de trabalho permite abrir, de fato, versões diferentes de uma enciclopédia. As mudanças em uma área de trabalho não afetarão outras áreas de trabalho. Isso fornece rastreabilidade, comparações entre a versão original e uma versão evoluída da enciclopédia e mesclagem das áreas de trabalho (consulte a seção Recursos para obter referências de como implementar áreas de trabalho).

O seu funcionamento também é simples:

1. É criada uma linha de base somente leitura contendo informações que não mudarão (uma lista de nomes de organizações, por exemplo).
2. Em seguida, as informações da linha de base são copiadas para uma área de trabalho quando a mesma é criada.

É possível alterar ou detalhar as informações de uma área de trabalho e relatar dentro ou ao longo de uma área de trabalho para análise.

É importante lembrar essas informações a respeito das áreas de trabalho:

• Cada enciclopédia tem apenas uma área de trabalho raiz (linha de base).
• Todas as áreas de trabalho criadas a partir da área de trabalho raiz herdam a linha de base pai, portanto, herdam todos os diagramas e definições.
• É possível visualizar a linha de base de uma enciclopédia, mas não editá-la, porque é somente leitura.
• Os usuários só podem abrir uma área de trabalho por vez. Quando você altera a área de trabalho ativa, todos os itens abertos que estão nela se fecham.
• Diversas pessoas podem modelar na mesma área de trabalho.

Também é necessário considerar estas restrições em relação à área de trabalho:

• Não tem como objetivo permitir que você utilize várias enciclopédias e as leve para uma enciclopédia sob uma pseudoestrutura de pasta
• Não permite diversos conjuntos de propriedades dentro de uma única enciclopédia (todas as áreas de trabalho usam o mesmo arquivo usrprops)
• Não habilita empacotamento ou namespaces para os objetos (o que permite mais de um objeto com o mesmo nome)
• Não permite o agrupamento de controle de acesso em um nível mais alto
• Não deve ser usada para resolver problemas ortogonais

Voltar para parte superior

Desenvolvendo arquiteturas DoDAF 2 formais e informais para áreas de trabalho

Os cenários deste artigo se baseiam no conceito de arquiteturas formais e informais e no que essas arquiteturas devem conter, conforme o descrito no padrão DoDAF 2. Esta seção fornece informações sobre as camadas de arquitetura formal e informal e descreve uma abordagem genérica para a modelagem dessas arquiteturas usando áreas de trabalho.

Há três camadas de arquitetura formal definidas no DoDAF 2.0:

1. A arquitetura de departamento fornece controle para as outras duas camadas. É desenvolvida no nível organizacional ou no nível da equipe conjunta, portanto, pode ser uma arquitetura para toda a Guarda Costeira dos EUA ou para um departamento da mesma, como o de Logística. Deve incluir a grade de informações global e a arquitetura empresarial de informações do DoD para garantir que os requisitos e dependências sejam considerados em arquiteturas de nível mais baixo. É na arquitetura no nível do departamento que a visão e a missão são definidas.
2. A arquitetura de recurso ou segmento descreve o uso de recursos específicos nestas áreas:
   • Negócios (por exemplo, como os desenvolvedores da Logística fazem o seu trabalho diário).
   • Compra (quais produtos ou serviços devem ser comprados para suprir os recursos designados ao departamento de logística).
   • Operações táticas (por exemplo, definir uma arquitetura para descrever como a logística suporta a execução das operações referentes à segurança nacional). Essa arquitetura explica como os negócios cotidianos de uma unidade organizacional ou de um ambiente específico (por exemplo, guerrear no Iraque) são feitos.
3. Arquitetura de componente considera uma necessidade específica (por exemplo, ao executar operações de segurança nacional, quais sistemas ou serviços são necessários na Logística). É aí que as tecnologias de suporte e serviços para o ambiente operacional são definidas. A arquitetura de componente mostra os novos serviços e tecnologias são necessários para suportar as operações ou quais serviços e tecnologias estão sendo usados no momento. Trata-se da estrutura tradicional de "projeto" ou arquitetura de solução .

Esses três níveis ajudam a controlar os elementos de modelo na arquitetura para criar um uso padrão da terminologia. Por exemplo, as unidades organizacionais são definidas no nível do departamento. Quando uma arquitetura de nível de recurso é criada, deve reutilizar as unidades organizacionais já definidas no nível do departamento. Isso deixará a modelagem mais rápida e precisa. Também fornecerá a capacidade, no nível do departamento, de que um tomador de decisão consulte dados comuns usados em diversas arquiteturas de recurso ou solução. A vantagem é que, por exemplo, se uma unidade organizacional está sendo renomeada, eliminada ou reorganizada, o impacto pode ser avaliado em toda a empresa — diferentemente da solução que é comum atualmente, na qual algo muda em um departamento e prejudica algo em outro departamento.

Há quatro camadas de arquitetura informal no DoDAF 2, que são usadas para definir, em cada nível formal, ao tipo de arquitetura que está sendo criado.

1. A arquitetura operacional descreve as operações táticas e de negócios e se concentra na visualização de recurso, visualização de projeto e visualização operacional.
2. A arquitetura de sistemas descreve os sistemas, redes e recursos de comunicações e se concentra na visualização do sistema e na visualização padrão. Deve se basear na arquitetura operacional.
3. A arquitetura de serviços descreve recursos de serviço internos e externos e se concentra na visualização de serviço e na visualização padrão. Deve se basear na arquitetura operacional.
4. A arquitetura de solução analisa uma arquitetura já existente e determina as mudanças que deverão ser feitas no futuro. Usa todas as visualizações necessárias para definir a solução.

Como mostra a Figura 2, as arquiteturas informais existem em todas as camadas da arquitetura formal.

As áreas de trabalho ajudarão a garantir a consistência dentro das arquiteturas e também impingirão as convenções de nomenclatura e outros requisitos de controle da arquitetura.

Implementando arquiteturas formais e informais usando áreas de trabalho

Arquitetura formal:

• Arquitetura de departamento (linha de base)
• Arquitetura de recurso ou segmento (área de trabalho)
• Arquitetura de componente (recurso como linha de base, componente como área de trabalho, podem ser divididos por ciclos de desenvolvimento)

Arquitetura informal

• Operacional (linha de base)
• Sistema (linha de base)
• Serviço (linha de base)
• Solução (área de trabalho)

Voltar para parte superior

Cenários para o uso de áreas de trabalho

Os cenários apresentados neste artigo se baseiam na experiência concreta no trabalho com projetos, mas isso não significa que essa é a única abordagem à modelagem desses tipos de projetos, nem que certos modelos sempre estarão na linha de base.

Cenário 1: Implementação de uma arquitetura empresarial

Arquiteturas empresariais vêm sendo implementadas na maioria dos componentes do DoD. A forma de documentar os níveis de arquitetura formal no System Architect — e, em seguida, controlar as mudanças — é um problema que surge com frequência.

Por exemplo, a Guarda Costeira dos EUA implementou uma arquitetura empresarial. A Guarda Costeira tem uma lista padrão de atividades, sistemas e organizações dentro de uma arquitetura de departamento. Esses nomes padrão são usados pelas linhas de negócios para desenvolver as arquiteturas de recurso ou segmento (Logística ou Finanças, por exemplo). Isso garante que todas as linhas de negócios usem a mesma terminologia. Também ajuda as linhas de negócios a entender os seus pontos de interação (por exemplo, como a Logística interage com as Finanças).

Usando áreas de trabalho, é possível criar um conjunto de diagramas de nível empresarial que irá restringir o desenvolvimento de arquiteturas de nível mais baixo. Isso garante, por exemplo, que um nome de sistema seja usado de forma consistente em todos os projetos de arquitetura. Também permitirá a emissão de relatórios ao longo de diversas arquiteturas, porque os mesmos nomes são usados em toda a organização (por exemplo, criar um relatório para ver o efeito da eliminação ou automatização de uma função).

As arquiteturas empresariais podem ser criadas por meio de uma de duas formas para desenvolver uma lista de artefatos empresariais padrão. Na melhor das hipóteses, os elementos de arquitetura (listas de sistemas, nomes de organizações, etc.) são criados em uma arquitetura de nível de departamento que, em seguida, seja expandida no nível do recurso/segmento e no nível da solução. Em alguns casos, é mais fácil definir o nível de solução ou recurso/segmento e, em seguida, filtrar elementos comuns provenientes das várias arquiteturas até chegar ao nível do departamento (exemplo: tomar uma lista de sistemas provenientes de três arquiteturas de recurso/segmento e criar uma lista completa na arquitetura de departamento).

Para simplificar, esse exemplo pressupõe uma abordagem de cima para baixo.

A área de trabalho raiz da linha de base (nível do departamento) dentro de um projeto de arquitetura empresarial (EA) deve conter o seguinte:

• CV-1 (lista de recursos disponíveis ao longo de toda a organização)
• OV-4 (gráfico organizacional para toda a organização)
• OV-5a/b (atividades de alto nível realizadas pela organização)
• DIV-2 (modelo de dados para toda a empresa das entidades em comum ao longo da organização)
• Lista de sistemas e tecnologias (Modelo de Referência Técnica)

A linha de base também deve conter os elementos de arquitetura ou diagramas que restringem as arquiteturas de nível mais baixo. Por exemplo, se o departamento tem que seguir a Federal Enterprise Architecture Framework (FEAF), os elementos de dados de FEAF devem ser incluídos na linha de base. Outro exemplo é uma organização restrita por outra organização — como acontece com a Guarda Costeira e a Segurança Interna dos EUA. Os elementos que devem ser consistentes entre as duas arquiteturas devem ser incluídos (por exemplo, usando o modelo de dados corporativo da Segurança Interna).

As áreas de trabalho serão constituídas pela arquitetura de recursos/segmento, que deve expandir as informações disponíveis na linha de base. Por exemplo, um recurso pode incluir entidades adicionais no modelo de dados corporativo para suprir as suas necessidades específicas.

As áreas de trabalho da arquitetura de recurso/segmento devem incluir:

• AV-1 (explicando o ponto de vista, etc. da arquitetura que está sendo criada — por exemplo, o recurso de logística)
• OV-1 (descrição de como o recurso ou segmento deve operar)
• OV-2 (fluxos de recursos entre os executores dentro de um recurso ou segmento)
• Decomposição de OV-5a/b (tomando as atividades de alto nível da linha de base e fornecendo mais detalhes)
• SV-1 (descrevendo os fluxos de recursos entre os sistemas que suportam o recurso ou segmento — os sistemas devem se basear na lista de sistemas da linha de base)
• SV-2 (descrevendo as interfaces físicas entre os sistemas no SV-1 — os sistemas devem se basear na lista de sistemas da linha de base)
• DIV-2 (aprimorando o modelo de dados corporativo)
• DIV-3 (para refletir os bancos de dados físicos que são usados dentro do recurso/segmento)

Depois que as arquiteturas de recurso ou segmento são concluídas e aprovadas e as mudanças necessárias são feitas na arquitetura de departamento, a arquitetura de recurso ou segmento pode ser dividida em diversas arquiteturas de solução, com o recurso ou segmento como linha de base.

Benefícios do uso de áreas de trabalho para definir uma arquitetura empresarial

• A mesma terminologia é usada de forma consistente dentro da organização, eliminando a confusão e permitindo a emissão de relatórios no nível do departamento ao longo da organização.
• O desenvolvimento da arquitetura será mais rápido, porque cada arquitetura de nível mais baixo é preenchida com definições e diagramas predefinidos.
• A emissão de relatórios pode ser feita ao longo das áreas de trabalho para garantir a consistência (para se certificar de que um nome de sistema não foi alterado, por exemplo).
• O preenchimento de uma nova enciclopédia (uma nova enciclopédia de recurso/segmento, por exemplo) com dados de toda a empresa é simples e requer apenas a criação de uma nova área de trabalho.
• Melhor integração dos sistemas, porque os elementos de dados subjacentes têm o mesmo nome e formato de dados.
• Redução da duplicação da funcionalidade do sistema e reutilização da funcionalidade já existente do sistema

Cenário 2: Implementação de uma arquitetura da forma que está e de uma arquitetura futura

O DoD não está interessado apenas em analisar o estado atual da organização. Também há a necessidade de criar planos para o futuro e garantir que os futuros recursos sejam identificados e financiados para que possam ser desenvolvidos. A linha de tempo do planejamento geralmente é de 1, 5, 10 ou 20 anos no futuro.

O programa de reconhecimento e inspeção espacial dos EUA é um exemplo disso. Os recursos, como um processamento mais eficiente e capacidades melhoradas de coleta, foram planejados antes que a tecnologia para oferecê-los estivesse disponível. Quando a tecnologia (câmeras maiores e a capacidade de lançar um satélite maior) se tornou disponível, foram estabelecidos programas para implementar os novos recursos — e, durante 30 anos, os requisitos do programa espacial não mudaram.

As áreas de trabalho simplificam esse tipo de planejamento, já que cada área de trabalho dentro da enciclopédia pode representar um dos períodos de tempo futuros para os quais o DoD está planejando. Já que a mudança de uma definição ou de um diagrama em uma área de trabalho não afeta a definição ou o diagrama com o mesmo nome em outras áreas de trabalho, é possível fazer alterações e atualizações para cada período de tempo e, em seguida, os relatórios identificarão o que mudou ao longo das áreas de trabalho.

A arquitetura de linha de base normalmente será a arquitetura de recurso/segmento, porque o planejamento é realizado nesse nível (pressupondo que o recurso/segmento corresponda a um componente dentro de uma organização, como a Logística na Guarda Costeira dos EUA). Deve incluir os modelos atuais (da forma que estão):

• AV-1
• CV-1
• OV-1
• OV-2
• OV-4
• OV-5
• SV-1
• SV-2
• SV-4
• DIV-2
• DIV-3

As áreas de trabalho se basearão na linha de tempo futura. Os produtos que serão modificados nas áreas de trabalho são:

• CV-1 (incluindo recursos futuros)
• OV-1 (descrevendo as novas operações com os novos recursos)
• OV-2 (mostrando os executores adicionais e fluxos de recursos necessários; os executores e fluxos de recursos também podem ser eliminados)
• OV-4 (mostrando, ao longo do tempo, uma reorganização, eliminação ou inclusão de executores ou pessoas)
• OV-5 (atividades adicionais de baixo nível podem ser incluídas, mas a maioria das mudanças no OV-5 estará relacionada a os dados produzidos e consumidos pelas atividades)
• SV-1 (mostrará alterações nas interfaces do sistema ao longo do tempo, bem como a inclusão ou exclusão de sistemas)
• SV-2 (mostrará as mudanças nas comunicações físicas entre executores ou sistemas)
• SV-4 (é possível que uma funcionalidade adicional de sistema seja incluída para suprir um novo recurso ou aproveitar novas tecnologias)
• DIV-2 (entidades e atributos adicionais necessários para novos recursos)
• DIV-3 (possíveis mudanças na implementação física do banco de dados quando a tecnologia de banco de dados for melhorada)

Benefícios do uso de áreas de trabalho para arquiteturas da forma que estão e arquiteturas futuras

• Rastreamento de mudanças em uma medida de desempenho (por exemplo, a disponibilidade de 86% aumentou para 95% no quinto ano)
• Rastrear uma mudança em uma interface de sistema
• Rastrear a substituição de um sistema por um serviço
• Analisar o impacto da eliminação ou introdução de um novo executor ou uma nova função
• Prever melhor os orçamentos
• Identificar os novos ativos necessários para suprir um novo recurso

Cenário 3: arquitetura de integração de sistemas

Projetos em grande escala ou sistemas de sistemas, frequentemente são divididos em projetos menores e gerenciáveis. Esses projetos normalmente são realizados por um contratado ou mais, especializado no desenvolvimento do componente específico do sistema. Entretanto, no final, todos os projetos devem ser integrados para fazer com que todo o sistema seja interoperável.

O desenvolvimento de um novo avião é um exemplo desse tipo de sistema. Um contratado desenvolverá os motores, outro, a estrutura do avião, outro, a aviônica e assim sucessivamente. Todos esses sistemas precisam ser unidos em um sistema integrado. Ao documentar os subsistemas de uma forma padrão e fornecer um plano geral de integração, a integração do sistema deve requerer menos retrabalho e ser mais fácil de realizar.

A arquitetura da linha de base normalmente será arquitetura de componente, que identifica o sistema ou o sistema de sistemas a ser desenvolvido. Deve incluir os modelos de design de alto nível:

• AV-1
• CV-1
• OV-1
• OV-2
• OV-4
• OV-5
• SV-1
• SV-2
• SV-4
• DIV-2
• DIV-3

As áreas de trabalho serão os subsistemas e podem ser divididas de acordo com as responsabilidades das empresas subcontratadas. Os modelos de linha de base podem ser decompostos de forma mais detalhada para mostrar o design do subsistema. Estes são os modelos que serão modificados nas áreas de trabalho:

• OV-2 (mostrando os executores adicionais e fluxos de recursos necessários para o subsistema; o OV-2 da linha de base só mostrará detalhes em alto nível)
• OV-5 (atividades adicionais de baixo nível poderão ser incluídas se o detalhamento for necessário para as atividades designadas a cada subcontratada)
• SV-1 (mostrando detalhes adicionais sobre os subsistemas e fluxos de recursos de um subsistema específico)
• SV-2 (mostrará detalhes adicionais sobre comunicações físicas utilizadas no subsistema)
• SV-4 (a funcionalidade do sistema pode ser decomposta para identificar os fluxos de recursos internos entre as funções de sistema de baixo nível do subsistema)
• DIV-2 (entidades e atributos adicionais necessários para fornecer detalhes sobre os dados que o subsistema requer)
• DIV-3 (implementação do banco de dados físico do subsistema)

Benefícios do uso de áreas de trabalho para arquiteturas integradas

• Controle do design
• Facilidade de integração, já que há um entendimento claro em relação aos pontos de integração
• Análise para garantir que os requisitos de cada subsistema foram preenchidos
• Identificação e gerenciamento de risco dos pontos de integração
• Definição clara dos limites dos sistemas das subcontratadas
• Terminologia em comum ao longo dos limites dos sistemas
• Análise de impacto em caso de mudança em um subsistema
• É possível identificar a linha de tempo da integração dos sistemas, porque as interdependências do sistema são entendidas com clareza

Cenário 4: análise das trocas

O DoD frequentemente solicita estudos para fazer a análise das trocas sobre possíveis soluções para uma diferença de recursos. Também faz estudos com frequência para testar a possibilidade de usar novas tecnologias.

O programa de coleta de inteligência da Força Aérea dos EUA é um bom exemplo disso. Nos primórdios da história do reconhecimento, depois da II Guerra Mundial, havia uma controvérsia sobre o uso de balões, bombardeiros modificados (o RB-29) e caças modificados (o RF-84) para a coleta de inteligência. Os prós e contras de cada recurso (alcance/penetração, confiabilidade, risco de detecção e captura) foram analisados, e tomou-se uma decisão sobre os ativos que deveriam ser financiados para dar o melhor resultado.

As áreas de trabalho simplificam a análise das diversas possíveis soluções, fornecendo um cenário operacional de linha de base e, em seguida, detalhando a viabilidade de cada possível solução (no caso da Força Aérea, qual ativo deve ser usado para a coleta de inteligência). A viabilidade técnica de uma solução se torna evidente, assim como a capacidade de preencher os requisitos operacionais e as medidas de desempenho. Pode-se tomar uma decisão com base nos resultados de uma possível solução.

Normalmente, a arquitetura de linha de base será a arquitetura de componente, já que a mesma contém os requisitos operacionais de alto nível que a solução deve cumprir. Essa arquitetura pode ser a atual (da forma que está) ou uma arquitetura em estado futuro (da forma que será). Deve incluir estes modelos atuais (da forma que está) e futuros (como eles serão):

• AV-1
• CV-1
• OV-1
• OV-2
• OV-4
• OV-5
• SV-1
• SV-2
• SV-4
• DIV-2
• DIV-3

A área de trabalho terá como base as diversas opções sob análise. A maior parte do trabalho de engenharia será a análise de diversas opções relacionadas à visualização do sistema; as informações no ambiente operacional não devem mudar. Os produtos que serão modificados nas áreas de trabalho são:

• SV-1 (mostrará interfaces de sistema adicionais ou revisadas)
• SV-2 (mostrará mudanças nas comunicações físicas entre executores ou sistemas, possivelmente baseados nas novas tecnologias cuja viabilidade está sob análise)
• SV-4 (pode-se incluir mais funcionalidade de sistema para aproveitar novas tecnologias)
• DIV-3 (possíveis mudanças na implementação do banco de dados físico devido à inclusão de novos recursos ou com o objetivo de estruturar o banco de dados para uma nova tecnologia que está sendo introduzida)

Benefícios do uso de áreas de trabalho para a análise de trocas

• Capacidade de relatar os custos das várias opções
• Capacidade de relatar as medidas de desempenho e os requisitos relacionados referentes às várias opções, para evitar o excesso ou a insuficiência na engenharia da solução
• Garantia de que nada no ambiente operacional tenha mudado para fazer com que uma opção pareça mais viável
• Capacidade de controlar os riscos associados às diversas opções
• Normatização das diversas opções para facilitar a análise (os nomes de definição permanecem iguais; os diagramas contêm dados consistentes)

Voltar para parte superior

Ferramentas de análise de área de trabalho

Recurso SA Compare

É possível usar o utilitário SA Compare do Rational System Architect para mostrar mudanças nas áreas de trabalho. Por exemplo, pode-se usar o SA Compare com uma arquitetura DoDAF 2 para identificar qualquer uma destas mudanças:

• As mudanças nos nomes de itens na raiz dentro de uma área de trabalho (exemplo: o nome de uma organização na raiz foi alterado posteriormente em uma área de trabalho)
• Inclusões ou exclusões entre a raiz e as áreas de trabalho (exemplo: inclusão de funcionalidade adicional no sistema em uma área de trabalho ou exclusão de um sistema em uma área de trabalho)
• Inclusões ou exclusões ao longo do tempo (caso as áreas de trabalho sejam baseadas em tempo)
• Mudanças nas propriedades dentro de uma definição

Para obter mais informações, consulte a seção sobre o SA Compare no centro de informações do Rational System Architect, citado em Recursos.

Software IBM Cognos

O software de inteligência de negócios e gerenciamento de desempenho IBM® Cognos® permite a emissão de relatórios ao longo das áreas de trabalho. Também pode ser usado para executar relatórios que fazem cálculos. Estes são exemplos de usos do Cognos com uma arquitetura DoDAF 2:

• Relatar uma lista completa das atividades contidas em duas áreas de trabalho (o SA Report Generator só relata dentro de uma área de trabalho, não em várias áreas de trabalho)
• Fornecer uma lista das funcionalidades de sistema com custo mais alto ao longo de diversas áreas de trabalho
• Fornecer um custo geral referente às atividades e funções de sistema em todas as áreas de trabalho (no caso da análise de troca, pode-se executar um relatório para ver quais são as opções com custo mais alto e mais baixo)
• Relatar todos os fluxos de recursos necessários para um sistema (no caso da integração de sistemas, pode-se executar um relatório para mostrar todos os fluxos de recursos necessários para criar o sistema integrado)

Para obter mais informações, consulte a documentação do SA Compare no Centro de Informações do Rational System Architect, citado em Recursos.

Software Rational Focal Point

O software IBM® Rational® Focal Point oferece gerenciamento de produtos e portfólio baseado no mercado e nos negócios. Estes são exemplos de uso do Focal Point com uma arquitetura DoDAF 2:

• Painéis para uma área de trabalho específica ou várias áreas de trabalho para ajudar a gerenciar o risco do projeto, o planejamento e o custo
• Uso de informações objetivas para tomar uma decisão sobre o design com base em uma análise quantitativa, e não em uma suposição sobre a abordagem com custo mais reduzido ou risco mais baixo
• Captura da priorização dos requisitos do cliente para que a arquitetura reflita os recursos de prioridade mais alta.
• Recursos de roteirização e planejamento para permitir a análise hipotética em possíveis projetos futuros

Para obter mais informações, consulte a citação sobre a visão geral do Rational Focal Point em Recursos.

Software Rational DOORS

O IBM® Rational® DOORS é uma ferramenta que fornece um ambiente abrangente de gerenciamento de requisitos. Os requisitos podem ser vinculados desde o nível do departamento até o nível do componente para mostrar que a arquitetura de componente preenche todos os requisitos de alto nível para o recurso e o departamento. Estes são exemplos de uso do DOORS com uma arquitetura DoDAF 2:

• Indicador gráfico em um diagrama mostrando que um símbolo ou definição tem um requisito associado
• Relatórios para mostrar elementos de arquitetura sem um requisito associado (o que gera uma engenharia excessiva no sistema) ou requisitos sem vínculo com a arquitetura (requisito esquecido).
• Gerenciamento de três requisitos no nível da camada de arquitetura, com rastreabilidade entre os níveis.
• Os padrões e o controle das arquiteturas podem ser colocados no DOORS e vinculados à arquitetura.
• A análise de impacto sobre uma mudança de arquitetura ou de requisito pode ser realizada facilmente por meio de um relatório.

Para obter mais informações, consulte a página de visão geral do Rational DOORS citada em Recursos.

Recursos

Aprender

• Informações adicionais sobre áreas de trabalho:
  • Configurando áreas de trabalho do SA
  • IBM Rational System Architect: Cenários de área de trabalho, de Ian Hancock, Jog Raj e Ed Vail (developerWorks, novembro de 2010)
  • Demo: Using workspaces with Rational System Architect de Jason A. Green (developerWorks, outubro de 2009)
  • Biblioteca técnica do developerWorks sobre o Rational System Architect:
  
  
• Para obter informações sobre os softwares IBM Rational mencionados neste artigo:
  • Rational System Architect página da Web no developerWorks e demonstração on-line, além da documentação do SA Compare no Centro de Informações
  • Rational Focal Point página do developerWorks e página de visão geral
  • Rational DOORS página do developerWorks e página de visão geral
  
  
• Visite a área do software Rational no developerWorks para obter recursos técnicos e as melhores práticas para todos os produtos Rational Software Delivery Platform.
  
  
• Fique por dentro dos eventos técnicos e webcasts do developerWorks com foco em uma variedade de produtos da IBM e tópicos do segmento de mercado de TI.
  • Participe de um briefing ao vivo e gratuito do developerWorks para se atualizar rapidamente sobre produtos e ferramentas IBM, bem como tendências do segmento de mercado de TI.
  • Acompanhe Demos on demand do developerWorks, variando de demos de instalação e configuração de produtos para iniciantes a funcionalidades avançadas para desenvolvedores experientes.
  
  
• Melhore suas qualificações. Verifique o catálogo Catálogo de treinamento e certificação do Rational que inclui muitos tipos de cursos em uma ampla variedade de tópicos. É possível realizar alguns deles em qualquer local, a qualquer momento, e muitos dos cursos para iniciantes são gratuitos.
  
  

Obter produtos e tecnologias

• Faça o download de uma versão de teste gratuita e com funcionalidades completas do Rational System Architect.
  
  
• Avalie o software IBM da forma que melhor lhe convier: faça o download para uma versão de testes, experimente on-line, use em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.
  
  

Discutir

• Em relação ao Rational System Architect, participe do fórum Enterprise Architecture and Business Architecture hospedado pelo developerWorks e o grupo de usuários do Rational System Architect no LinkedIn.
  
  
• Compartilhe seu conhecimento e ajude outros a usar o software Rational, escrevendo um artigo para o developerWorks. Você terá um público mundial, organização RSS, reconhecimento de autoria e uma biografia, e o benefício da edição e produção profissional no Web site do Rational no developerWorks. Descubra quais são as características de um bom artigo do developerWorks e como realizá-lo.
  
  
• Siga o software Rational no Facebook, Twitter (@ibmrational) e no YouTubee adicione seus comentários e solicitações.
  
  
• Faça e responda perguntas, e aumente seu conhecimento participando dos Fóruns do Rational, cafésée a wikis.
  
  
• Entre em contato com outros que compartilham seus interesses fazendo parte da comunidade do developerWorks , e respondendo aos blogs de desenvolvedores.
  
  

Sobre o autor

Franki Schafrik tem 17 anos de experiência no uso do Rational System Architect e do DoDAF com clientes de defesa do mundo todo. Ela presta consultoria e leciona sobre o DoDAF internacionalmente.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução às áreas de trabalho
• Desenvolvendo arquiteturas DoDAF 2 formais e informais para áreas de trabalho
• Cenários para o uso de áreas de trabalho
• Ferramentas de análise de área de trabalho
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais