Analise de Impacto no Enterprise Architect
Quando estamos falando de mudanças em um projeto de desenvolvimento de software existe uma grande necessidade de saber no que essa mudança irá impactar. Esse impacto pode ser encarados de várias formas.
Você precisa saber o impacto da mudança em termos de requisitos, design e até código. É importante ter esse conhecimento para poder dimensionar a mudança e ver a forma certa de lidar com a mesma. Todas essas questões tem impacto direto na gestão do projeto, por que dependendo da mudança vai demandar mais recursos, tempo e complexidade.
Uma ferramenta de requisitos deve tratar com essas questões. Muitas ferramentas analisam o impacto somente a nível de requisitos, de facto isso não é o suficiente por que na pratica vai demandar toda uma analise manual de um projetista ou analista.
Neste post vou mostrar como podemos fazer analise de impacto em dois níveis com a ferramenta Enterprise Architect ou famoso EA. No primeiro nível vou mostrar o impacto entre Requisitos funcionais e casos de uso e em segundo nível mostrarei o impacto dos casos de uso para o código fonte.
Análise de Impacto sempre tem um custo
Esta é uma verdade universal. Você sempre terá um custo com a analise de impacto, ou seja, ela nunca vem de graça. Para poder consultar a ferramenta(EA) e saber o impacto você tem que manter o diagrama de impacto atualizado, isso tem um custo e é mais uma coisa a se preocupar.
Se você não realizar essa tarefa não hora da mudança terá o custo de atualizar a ferramenta, isso pode ser tão custoso que não se pague fazer essa tarefa e você pode acabar tendo que fazer a analise na mão.
Não fazer analise de impacto é um risco, você pode se surpreender com a mudança. Em projetos pequenos não é necessário o uso desta prática, mas em projeto de médio e grande porte onde a complexidade começa a aumentar essa prática mostra ter muito valor.
Exemplo prático no EA
Irei mostrar isso de forma muito simples. Não liguem para a veracidade dos dados. O objetivo aqui é mostrar na prática como usar este recurso, então vamos a estrutura do projeto. No projeto de exemplo EA-Matriz-Impacto, existem as seguintes visões top level:
Código é aonde estão os fontes de aplicação, não tive o trabalho de definir métodos e atributos nas classes, você podem perceber que eu coloquei em uma estrutura que é padrão do maven 2. Isso foi de propósito.
Neste exemplo apesar da estrutura do maven, poderia ser construído com qualquer linguagem como por exemplo PHP, .NET, Python essas são linguagens que assim como Java o EA faz engenharia reversa e pode sincronizar os fontes com os seus diagramas.
Matriz Impacto é aonde está a matriz que liga os requisitos aos fontes. Como esse é um exemplo usei um único diagrama para isto. Somente em projetos pequenos isso é viável. Em projetos maiores você terá que ter diversos diagramas para mapear a realização dos seus requisitos para o código.
Os Requisitos
Requisitos do sistema de Exemplo
Você precisa saber o impacto da mudança em termos de requisitos, design e até código. É importante ter esse conhecimento para poder dimensionar a mudança e ver a forma certa de lidar com a mesma. Todas essas questões tem impacto direto na gestão do projeto, por que dependendo da mudança vai demandar mais recursos, tempo e complexidade.
Uma ferramenta de requisitos deve tratar com essas questões. Muitas ferramentas analisam o impacto somente a nível de requisitos, de facto isso não é o suficiente por que na pratica vai demandar toda uma analise manual de um projetista ou analista.
Neste post vou mostrar como podemos fazer analise de impacto em dois níveis com a ferramenta Enterprise Architect ou famoso EA. No primeiro nível vou mostrar o impacto entre Requisitos funcionais e casos de uso e em segundo nível mostrarei o impacto dos casos de uso para o código fonte.
Análise de Impacto sempre tem um custo
Esta é uma verdade universal. Você sempre terá um custo com a analise de impacto, ou seja, ela nunca vem de graça. Para poder consultar a ferramenta(EA) e saber o impacto você tem que manter o diagrama de impacto atualizado, isso tem um custo e é mais uma coisa a se preocupar.
Se você não realizar essa tarefa não hora da mudança terá o custo de atualizar a ferramenta, isso pode ser tão custoso que não se pague fazer essa tarefa e você pode acabar tendo que fazer a analise na mão.
Não fazer analise de impacto é um risco, você pode se surpreender com a mudança. Em projetos pequenos não é necessário o uso desta prática, mas em projeto de médio e grande porte onde a complexidade começa a aumentar essa prática mostra ter muito valor.
Exemplo prático no EA
Irei mostrar isso de forma muito simples. Não liguem para a veracidade dos dados. O objetivo aqui é mostrar na prática como usar este recurso, então vamos a estrutura do projeto. No projeto de exemplo EA-Matriz-Impacto, existem as seguintes visões top level:
- Requisitos
- Código
- Matriz Impacto
Código é aonde estão os fontes de aplicação, não tive o trabalho de definir métodos e atributos nas classes, você podem perceber que eu coloquei em uma estrutura que é padrão do maven 2. Isso foi de propósito.
Neste exemplo apesar da estrutura do maven, poderia ser construído com qualquer linguagem como por exemplo PHP, .NET, Python essas são linguagens que assim como Java o EA faz engenharia reversa e pode sincronizar os fontes com os seus diagramas.
Matriz Impacto é aonde está a matriz que liga os requisitos aos fontes. Como esse é um exemplo usei um único diagrama para isto. Somente em projetos pequenos isso é viável. Em projetos maiores você terá que ter diversos diagramas para mapear a realização dos seus requisitos para o código.
Os Requisitos
Requisitos do sistema de ExemploNeste exemplo criei um requisito funcional chamado "O Sistema deve possibilitar o cadastro de novos clientes e bem como desativar clientes" e dois requisitos da perspectiva do usuário os casos de uso "Manter Clientes" e "Manter Contratos".
A Codificação
Ciente destes requisitos imagine que o desenvolvedor codifica a solução para atender estes requisitos, não cheguei a especificar os casos de uso, por que o foco aqui é na matriz de impacto e não na qualidade dos requisitos. Mas essa é uma questão que sempre deve estar em sua mente, é essencial a qualidade de bons requisitos.
Dado esses requisitos vamos a implementação, para isso confira o seguinte diagrama de classes que segue a baixo:
Diagrama de classes do exemplo
A Codificação
Ciente destes requisitos imagine que o desenvolvedor codifica a solução para atender estes requisitos, não cheguei a especificar os casos de uso, por que o foco aqui é na matriz de impacto e não na qualidade dos requisitos. Mas essa é uma questão que sempre deve estar em sua mente, é essencial a qualidade de bons requisitos.
Dado esses requisitos vamos a implementação, para isso confira o seguinte diagrama de classes que segue a baixo:
Diagrama de classes do exemploEste é o diagrama de classes da solução. Como pode ver empreguei um ordinário exemplo de codificação usando MVC. Neste ponto o EA não tem como saber que classe serve a qual requisito e logo não poderá estabelecer o impacto.
Mapeando a realização de requisitos
Agora você precisa dizer ao EA como as classes da solução servem os requisitos da mesma. Para isso vamos criar um diagrama "custom" na aba "extended". Com esse diagrama vamos mapear os requisitos para os fontes.
Criar o diagrama é simples, manter nem sempre. Para criar o diagrama você tem que arrastar os requisitos funcionais e os casos de uso da visão do projeto para o diagrama, faça o mesmo com as classes e faça as ligações.
O Diagrama pode parecer confuso, por que quando você puxa uma classe o EA também traz as suas dependências, você pode esconder isso clicando com o botão direito do mouse sobre a dependência e depois em "Set Visibility" e depois em "Hide Connector".
Confira como fica o diagrama.
Diagrama que mapeia Requisitos com Fontes
Mapeando a realização de requisitos
Agora você precisa dizer ao EA como as classes da solução servem os requisitos da mesma. Para isso vamos criar um diagrama "custom" na aba "extended". Com esse diagrama vamos mapear os requisitos para os fontes.
Criar o diagrama é simples, manter nem sempre. Para criar o diagrama você tem que arrastar os requisitos funcionais e os casos de uso da visão do projeto para o diagrama, faça o mesmo com as classes e faça as ligações.
O Diagrama pode parecer confuso, por que quando você puxa uma classe o EA também traz as suas dependências, você pode esconder isso clicando com o botão direito do mouse sobre a dependência e depois em "Set Visibility" e depois em "Hide Connector".
Confira como fica o diagrama.
Diagrama que mapeia Requisitos com FontesUsei um único diagrama pelo motivo que disse antes, este era um exemplo, em um projeto de verdade você terá vários diagramas deste tipo. Agora que fizemos esse mapeamento podemos criar a matriz de impacto no EA.
Criando a matriz de impacto
Para criar a matriz de impacto clique no menu"View" e depois em "Relationship Matrix" e agora ira abrir a visão de impacto do EA, vamos criar duas visões desta matriz, isso é possível graças a capacidade de lidar com profiles do EA.
Vamos primeiro mostrar o impacto dos Requisitos funcionais com os casos de uso. Para isso selecione os seguintes valores, primeiro source de depois target.
* Source:
Matriz de Impacto de RF com UC
Criando a matriz de impacto
Para criar a matriz de impacto clique no menu"View" e depois em "Relationship Matrix" e agora ira abrir a visão de impacto do EA, vamos criar duas visões desta matriz, isso é possível graças a capacidade de lidar com profiles do EA.
Vamos primeiro mostrar o impacto dos Requisitos funcionais com os casos de uso. Para isso selecione os seguintes valores, primeiro source de depois target.
* Source:
- Source: Requisitos
- Type: Requirement
- Link Type: Realization
- Target: CasosDeUso
- Type: UseCase
- Direction: Target -> Source
Matriz de Impacto de RF com UCAgora vamos a segunda matriz, nesta vamos ver o impacto dos Casos de Uso aos fontes para isso configure a matriz da seguinte maneira:
* Source:
Matriz de Impacto de UC com Fontes
* Source:
- Source: Requisitos
- Type: UseCase
- Link Type: Realization
- Target: Java
- Type: Class
- Direction: Target -> Source
Matriz de Impacto de UC com FontesSe você quiser pode salvar essas configurações clicando com o botão direito do mouse sobre a barra cinza das configurações e clicando em "Profiles" e depois "Save as new Profile".
Agora você pode analisar o impacto sempre que necessário, esta é uma pratica importante que está totalmente ligada a gestão de mudanças. Apesar de paga o EA é uma excelente solução de modelagem e quebra o galho legal com os requisitos.
Se você quiser pode baixar este projeto de exemplos que criei aqui.
Abraços e até a próxima.
Agora você pode analisar o impacto sempre que necessário, esta é uma pratica importante que está totalmente ligada a gestão de mudanças. Apesar de paga o EA é uma excelente solução de modelagem e quebra o galho legal com os requisitos.
Se você quiser pode baixar este projeto de exemplos que criei aqui.
Abraços e até a próxima.
