Usando o Mingle para Projetos Scrum

Estava fazendo análise de um sistema e escolhi utilizar o mingle da ThroughWorks como gerenciador para um projeto que será feito com Scrum. Achei muito prático e funcional, vou utilizá-lo e ao final do projeto falo mais informações sobre a experiência que tive com ele.

Diagrama de Contexto

Após vários meses sem publicar nada vou começar o ano com um post pelo menos..

Ontem minha colega de trabalho Juliana Parollo me mostrou um processo um tanto obscuro que era realizado aqui em nossa empresa. Verificamos e chegamos à seguinte conclusão: precisamos mapear este processo para entender como ele funciona, caso contrário, não conseguiremos fazer nada para melhorar.

Minha sugestão para iniciar o mapeamento deste processo foi realizar uma análise em cada departamento com seus respectivos intervenientes e, na sequencia, documentar formalmente.

Para fazer a documentação utilizamos um formato de documento semelhante a um artefato do RUP. Este documento deverá ter um diagrama de contexto (DFD em alto nível) onde ilustraremos de maneira bem simples o fluxo de dados e descreveremos cada parte do processo do diagrama.

Mesmo nesta modelagem que não é um padrão UML podemos seguir as dicas de Fowler − de que quando estamos modelando a UML, devemos manter o padrão sempre que possível. No entanto é necessário lembrar que a clareza do modelo é o mais importante. Ou seja, se for preciso sacrificar o padrão para que o modelo fique mais claro, faça-o una o útil ao agradável.

Utilizando esta idéia, desenvolvi um diagrama de contexto um pouco diferente do convencional (que utiliza basicamente círculos e quadrados). Ao invés disso, preferi usar alguns ícones e cores. Neste exemplo utilizei o programa yEd, excelente para fazer rapidamente modelos simples como esse.


Como este é apenas o primeiro modelo, ele ainda não está completo. Após uma segunda análise este modelo foi melhorado com algumas mudanças.



A idéia é a de que este modelo junto com a documentação funcione sempre como uma base para vários trabalhos posteriores e para um possível e mais abrangente modelo de processo.

Como obter requisitos arquiteturais - parte 1

O que é um requisito arquitetural?

Trata-se de qualquer requisito que é arquiteturalmente significante, onde o nível de significância pode estar implícito ou explícito. Requisitos arquiteturais implícitos são aqueles
que possuem atributos particulares. Por exemplo, qualquer requisito de alto risco,
alta prioridade ou baixa estabilidade pode ser considerado arquiteturalmente significante.
Entretanto o artigo foca primeiramente nos requisitos explícitos, segue alguns exemplos de requisitos arquiteturais explícitos:

• O sistema deve ter apoio a múltiplas linguagens humana;
• A persistência será feita através de um banco de dados relacional;
• A base de dados será Oracle 8i;
• O sistema irá correr sete dias por semana, vinte e quatro horas por dia;
• Um sistema de ajuda on-line é necessário;
• Toda apresentação lógica será feita em Flex.
  

Como você pode perceber, estes requisitos são muito diferentes e estão misturados. Alguns são funcionais, outros não-funcionais; alguns são independentes dos mecanismos técnicos, e outros não. O que nós precisamos é de uma abordagem sistemática que proveja um framework para classificação das exigências arquiteturais, garantindo que essas valiosas declarações como as que estão listadas acima não sejam esquecidas.

FURPS + sistema de classificação de requisitos

Para auxiliar a categorização utilizamos o modelo FURPS+ [GRA92] que descreve as principais categorias de requisitos:

• Funcionalidade
• Usabilidade
• Confiabilidade (Reliability)
• Desempenho (Performance)
• Suportabilidade

O "+" na FURPS + também nos ajuda a lembrar preocupações como:

• Requisitos de design
• Requisitos de implementação
• Requisitos de interface
• Exigências físicas

Vamos analisar em pormenor cada categoria.


Requisitos funcionais

Requisitos funcionais geralmente representam as principais funcionalidades do produto. Em um armazém pedido, talvez tivéssemos requisitos relativos à ordem processamento ou estoque controle. No entanto, requisitos funcionais nem sempre são específicos do domínio. Proporcionar impressão capacidade funcional é um requisito de particular importância para arquitetura.

Requisitos não-funcionais

Os restantes "URPS" categorias descrever requisitos não-funcionais que são geralmente arquiteturalmente significativos.

• Usabilidade: interesse em características como estética e coerência na interface do utilizador.
  
  
• Confiabilidade (Reliability): interesse em características como a disponibilidade, a exatidão do sistema de cálculos, bem como a capacidade do sistema de recuperação de falhas.
  
  
• Desempenho (Performance): interesse em características como a velocidade do tempo de resposta, o tempo de recuperação, tempo do start-up , e tempo do shutdown .
  
  
• Suportabilidade (Supportability): interesse em características como testabilidade, adaptabilidade, durabilidade, a compatibilidade, configurabilidade, instalabilidade, escalabilidade e localizabilidade.

O "+" no FURPS + sigla é usada para identificar outras categorias que geralmente representam restrições.

• Um requisito de design, muitas vezes chamado de restrição de design, especifica ou restringe as opções para projetar um sistema. Por exemplo, se você especificar que uma base relacional é necessária, isto é uma restrição de design.
  
  
• Um requisito de implementação especifica ou restringe a codificação ou a construção de um sistema. Exemplos podem incluir normas exigidas, as liguagens de execução, dos recursos e limites.
  
  
• Um requisito de interface especifica um meio externo com o qual um sistema deve interagir, ou restringe algum formato ou outros fatores utilizados dentro dessa interação.
  
  
• A exigência física especifica uma limitação física imposta ao hardware utilizado para abrigar o sistema - forma, tamanho ou peso, por exemplo.

Identificando os requisitos

A partir da descrição acima, podemos ver facilmente que algumas exigências funcionais, e mais exigências no FURPS+ de outras categorias, são arquiteturalmente significativas. Agora vamos analisar como poderíamos classificar os requisitos arquiteturais que aparentemente não estão relacionados enumerados anteriormente. Usando o FURPS + na classificação podemos ver:

• “O sistema deve ter apoio a múltiplas linguagens humana” é um requisito de suportabilidade.
  
  
• “A persistência será feita através de um banco de dados relacional" é um requisito de design.
  
  
• " A base de dados será Oracle 8i" é um requisito de implementação.
  
  
• “O sistema irá correr sete dias por semana, vinte e quatro horas por dia" é um requisito confiabilidade.
  
  
• "Um sistema de ajuda on-line é necessária" é um requisito funcional.
  
  
• " Toda apresentação lógica será feita em Flex" é um requisito de implementação.

Fonte/referencias:

Peter Eeles, Senior TI arquitecto, IBM

[GRA92] Robert Grady 1992. Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall.