No final da década de 90 e início dos anos 2000, um novo grupo de Metologias de Desenvolvimento de Software começou a surgir e em 2001, com a publicação do Manifesto Ágil, tais metodologias passaram a ser chamadas de Metodologias Ágeis. O ICONIX também evoluiu afim de incorporar características que o permitissem ser adaptado a projetos ágeis, ou seja, em um ciclo de vida iterativo e incremental.
Devido às diversas mudanças ocorridas no cenário da Engenharia de Software refletidas gradualmente no ICONIX Process, é comum encontrar na Internet artigos que apresentam uma descrição desatualizada do processo. Com isso, resolvi publicar, em língua portuguesa, uma visão um pouco mais atualizada do ICONIX para que sirva de guia para estudos atuais. É óbvio dizer que, com a evolução do processo, o presente post também ficará desatualizado com o passar dos anos.
Quando utilizado em um ciclo de vida iterativo e incremental, cada iteração do projeto a ser desenvolvido e que servirá de atualização ao incremento anterior, conterá as fases descritas abaixo. Não é minha intenção detalhar as fases, mas apenas apresentar uma visão introdutória.
Requisitos
Como entrada para o processo, é necessário ter em mãos os requisitos funcionais do sistema a ser confeccionado. O ICONIX não define claramente como os requisitos devem ser levantados ou documentados. Algumas abordagens utilizam a criação dos esboços das interfaces gráficas do sistema (storyboards) ou da iteração em questão. Outras abordagens utilizam descrição textual dos requisitos. Proponho aqui, se é que ainda não foi proposto, utilizar as histórias de usuário, que podem ser obtidas através do jogo do planejamento do XP (eXtreme Programming). Gostaria de deixar registrado como opinião pessoal que não acredito que esboço de interface gráfica seja o melhor ponto de partida para um processo baseado em UML. Acredito que elas devam ser identificadas posteriormente, após a análise de robustez, quando identificaremos as classes de fronteira que, em geral, são as interfaces gráficas de usuário.
Com os requisitos em mãos, pode-se identificar o Modelo de Domínio, ou seja, um diagrama de classes sem atributos nem operações, apresentado as principais entidades que serão manipuladas pelo sistema.
Através dos requisitos também será possível identificar os casos de uso do sistema. O ICONIX apresenta uma forma diferenciada de identificar os casos de uso, mas deixarei para apresentá-la em um post futuro. O que julgo necessário destacar aqui é que os casos de uso constituirão a ponte entre os requisitos e a implementação do sistema, portanto, para o ICONIX, é extremamente importante para o processo descobrir os casos de uso de forma a representar com fidelidade os requisitos do sistema.
Milestone 1: Ao final da fase de requisitos, verifique que o texto dos casos de uso (fluxo de eventos) represente com fidelidade os requisitos ditados pelo cliente.
Quando utilizado o ciclo de vida iterativo e incremental, a fase de requisitos deverá mapear apenas os requisitos que serão implementados na iteração.
Análise e projeto preliminar
Para cada caso de uso identificado na fase de requisitos, devemos criar um diagrama de robustez baseado no texto do caso de uso (fluxo de eventos). Pode, também, surgir a necessidade de reescrever o texto do caso de uso. O diagrama de robustez não é um diagrama padrão da UML. No ICONIX, esse diagrama é utilizado para descobrir as classes de análise e detalhar, em alto nível, o funcionamento básico do caso de uso. Dedicaremos um post futuro para tratar do diagrama de robustez, fazendo uma comparação com o diagrama de comunicação com classes de análise usado no Processo Unificado.
Em paralelo ao diagrama de robustez, devemos atualizar o modelo de domínio e adicionar os atributos às entidades identificadas. O modelo de domínio resultante se assemelhará tanto com um modelo de dados que acho válido dizer que a partir deste ponto estaremos prontos para gerar a base de dados do sistema. Vale ressaltar que não encontrei nenhuma referência à geração da base de dados neste ponto nos textos que li, mas a lógica me leva a concluir que este é o momento.
Conforme mencionei anteriormente, ainda com base na minha opinião pessoal, as classes de fronteira do diagrama de robustez nos darão uma ideia de quais são as principais telas da interface gráfica do sistema. Logo, acredito que este também é o momento de se criar o esboço da interface gráfica (storyboards).
Milestone 2: Ao final da fase de análise e projeto preliminar, verifique a consistência dos artefatos gerados, ou seja, do projeto preliminar. Se necessário, realimente a fase de requisitos com eventuais alterações identificadas aqui.
Projeto detalhado
Para cada caso de uso, devemos criar um diagrama de sequência de forma a detalhar a futura implementação do caso de uso. O diagrama de sequência deverá conter as classes que realmente serão implementadas, ou seja, as classes de projeto. As mensagens enviadas entre os objetos deverão corresponder aos métodos que realmente serão implementados.
Atualize o modelo de domínio com as operações encontradas no diagrama de sequência. Inclua também as novas classes de projeto identificadas, criando o diagrama de classes final do seu sistema (ou da iteração).
Milestone 3: Reveja o projeto do sistema (ou da iteração) de forma crítica, fazendo com que ele fique aderente à tecnologia que será utilizada para a implementação.
Implementação
Inicialmente, o ICONIX não trazia detalhes sobre a implementação. Se pensarmos bem, qual processo detalha a implementação? Porém, na última edição do livro intitulado "Use Case Driven Object Modeling with UML: Theory an Practice", Doug Rosenberg e Matt Stephens, é possível encontrar um guia detalhado de cuidados que devemos tomar ao implementar um sistema, tendo claramente uma grande influência das metodologias ágeis. Particularmente, baseado na publicações mais recentes, não considero um erro dizer que a implementação faz parte do ICONIX. Também não considero um erro dizer que não faz. Apresento abaixo uma figura extraída do site do ICONIX Process sugerindo a implementação como uma fase do ICONIX.
Para mais informações sobre o processo ICONIX e também sobre o livro de Doug Rosenberg e Matt Stephens, acesse o site: http://www.iconixprocess.com
É Márcio essas fases do ICONIX tá dando o que falar hein! Concordo com você que, o fato da implementação ser uma fase ou não, vai da interpretação de cada um. Mas independente da metodologia utilizada, sem implentação não tem projeto...rs
ResponderExcluirParabéns pelo blog, tenho certeza que vai ser muito acessado!
É verdade Bruno, precisamos ter cuidado com a analysis paralysis. rsrsrs. Para quem não sabe, analysis paralysis é o termo utilizado quando se analisa demais e se faz muito pouco. Algo que as metodologias ágeis, e o próprio ICONIX, tentam combater.
ResponderExcluirObrigado pelos parabéns! ;)
Apesar de eu não entender muito bem sobre metodologias ágeis gostei do esclarecimento... Esse tal de MAIA deve ter citado o Wikipedia no seu livro... rs!
ResponderExcluirOlá Daniel. Que bom que gostou. Obrigado.
ResponderExcluir