Iconix

O ICONIX é um processo de desenvolvimento de software

desenvolvido pela ICONIX Software Engineering. Trata-se de uma metodologia

prática e simples, mas também poderosa e com um componente de análise e

representação de problemas sólido e eficaz.

ICONIX pode ser considerada uma metodologia pura, prática e simples,

mas também poderosa e com um componente de análise e representação dos

problemas sólido e eficaz, por isso, a metodologia ICONIX é caracterizada como um

Processo de Desenvolvimento de Software desenvolvido pela ICONIX Software

Engineering (www.iconixsw.com).

O ICONIX é um processo não tão burocrático como o RUP, ou seja, não

gera tanta documentação. E apesar de ser um processo simples como o XP, não

deixa a desejar na Análise e Projeto (Design), e se destaca com um poderoso

processo de desenvolvimento de software.

Este processo também faz uso da linguagem de modelagem UML e possui

uma característica exclusiva chamada "Rastreabilidade dos Requisitos" (Traceability

of Requirements). Mais precisamente, ICONIX nos permite "obrigatoriamente",

através de seus mecanismos, verificar em todas as fases se os requisitos estão

sendo atendidos. A abordagem ICONIX é flexível e aberta, isto é, se for necessário

usar outro recurso da UML para complementar os recursos usados nas fases do

ICONIX, não há problema algum.

O ICONIX é composto pelas seguintes principais fases:

· Modelo de Domínio

· Modelo de Caso de Uso

· Análise Robusta

· Diagrama de Seqüência

· Diagrama de Classe

A vantagem Iconix

O modelo de negócio Iconix é exclusivo para a indústria da moda e tem

muitos atributos interessantes:

Fluxo de receitas previsível devido contratualmente garantidos os

pagamentos de royalties mínimos no inventário operacional, ou risco de um

produto

EBITDA significativamente maior e margem líquida de empresas de vestuário

tradicionais operacionais

Forte fluxo de caixa livre com custos fixos baixos e necessidades de

despesas mínimas de capital

Oportunidade de crescimento acelerado através de estratégia de aquisição

de marca

Segundo MAIA (2005), o ICONIX é dividido em dois grandes setores,

modelo estático e modelo dinâmico, que podem ser desenvolvidos paralelamente e

de forma recursiva. O modelo estático é formado pelos Diagramas de Domínio e

Diagramas de Classe que modelam o funcionamento do sistema sem nenhum

dinamismo e interação com o usuário. O modelo dinâmico, por sua vez, sempre

mostra a interação entre o usuário e o sistema, através de ações onde o sistema

apresenta alguma resposta ao usuário em tempo de execução. O modelo estático é

refinado incrementalmente durante iterações sucessivas do modelo dinâmico.

Borillo (2000), destaca três características fundamentais no ICONIX:

• Iterativo e incremental: várias iterações ocorrem entre o desenvolvimento

do modelo de domínio e a identificação dos casos de uso. O modelo estático é

incrementalmente refinado pelo modelo dinâmico (ver figura 14);

• Rastreabilidade (traceability): cada passo referência para os requisitos

de alguma forma. Silva e Videira (2001) definem rastreabilidade como sendo a

capacidade de seguir a relação entre os diferentes artefatos produzidos. Desta

forma, pode-se determinar qual o impacto que a alteração de um requisito tem em

todos os artefatos restantes;

• Aerodinâmica da UML : a metodologia oferece o uso “aerodinâmico” da

UML (OMG®, 2001) como: os diagramas de casos de uso, diagramas de seqüência

e colaboração, diagramas de robustez.

Pontos Negativos e Problemas com ICONIX

O ICONIX não sugere explicitamente nenhum diagrama para modelar

processo de negócio na fase preliminar do projeto. Mesmo sendo o ICONIX um

processo que pretende ser prático e simples, poderia no entanto, se beneficiar do

diagrama de atividades disponível na UML (OMG®, 2001) para modelar processos

de negócios.

É fundamental pensar sobre todos os fluxos alternativos possíveis para

cada caso de uso, sempre que possível. Considerando que o fluxo principal é mais

fácil de identificar e escrever, não significa, porém, que o fluxo alternativo deva ser

postergado até que o projeto detalhado seja implantado. De fato, se isto acontecer

pode causar omissões sérias nestes pontos, gastando muito tempo para escrever o

fluxo alternativo, frente aos demais artefatos já definidos. Este é um cuidado que o

próprio ICONIX ressalta. Quando importantes fluxos alternativos não são

descobertos até a fase de codificação e depuração, o programador responsável por

escrever o código tender a tratar isto de forma mais conveniente no momento. Isto,

não é saudável para o projeto. Então, pergunte várias vezes: Existe alguma coisa

que pode acontecer? Existe outra forma tratamento? Isto está correto? Garanta com

isto um conjunto rico de fluxos alternativos.

Outra característica forte do ICONIX é a distinção entre requisitos e casos de

uso. Uma desvantagem clara desta posição do ICONIX é obrigar a equipe de

projeto identificar e elaborar de uma lista de requisitos, assim como a manter as

associações entre os requisitos e os casos de uso. Isto requer um esforço adicional

e um acréscimo do volume de trabalho, que poderia ser evitado em um processo

que pretende ser rápido e simples.