Mostrando postagens com marcador requisitos. Mostrar todas as postagens
Mostrando postagens com marcador requisitos. Mostrar todas as postagens

domingo, março 23, 2014

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.


domingo, abril 27, 2008

Como obter requisitos arquiteturais - parte 2

Mecanismos arquiteturais

Em termos simples, um mecanismo arquitetural representa uma solução comum para um problema encontrado com freqüência. Mecanismos arquiteturais são utilizados com freqüência para perceber requisitos arquiteturais.

A tabela abaixo mostra três categorias de mecanismos arquiteturais e mostra como esse mecanismos são expressos em cada uma dessas categorias.




Mecanismo de Análise Mecanismo de Design Mecanismo de implementação
Persistência RDBMS Oracle
Ingres
OODBMS ObjectStore
Comunicação Object request broker Objeto pedido corretor Orbix
VisiBroker
Message queue Mensagem fila MSMQ
MQSeries




Um mecanismo de análise representa uma implementação independente de solução.
Um mecanismo de design(projeto) é um refinamento de um mecanismo de análise.
E um mecanismo de implementação é um refinamento de um mecanismo de design, e especifica a exata aplicação do mecanismo.

A figura abaixo resume a relação entre os requisitos e mecanismos, mostrando refinamentos do FURPS.






A abordagem proposta para obter requisitos arquiteturais com FURPS é a seguinte:


1. “Mantenha uma lista completa de requisitos arquiteturais, sem levar em
consideração se os itens listados são relevantes ou não para um projeto
particular”;
2. “Para cada requisito arquitetural, formule uma ou mais questões que
possam ajudar no processo de especificação. Tenha certeza de que todos os
envolvidos no projeto possam entender essas questões”;
3. “Ajude os envolvidos no projeto mostrando a eles o impacto potencial
de responder uma questão de uma forma ou de outra”;
4. “Capture as respostas dadas a cada uma das questões”;
5. “Ajude o arquiteto assegurando que os envolvidos no projeto (em adição
às respostas das questões) atribuam uma prioridade ou um peso a cada requisito
arquitetural. Esse peso atribuído ajudará o arquiteto a fazer escolhas entre os
requisitos”.


A tabela abaixo exemplifica um questionário desse tipo, que inclui também exemplos de respostas:


























RequisitoQuestõesImpactoRespostas

Licenças (prioridade: Média)
O sistema, ou parte dele será licenciado? Existem muitas
restrições no
mecanismo
utilizado para
prover
capacidade de
licenciamento?
Quanto maior a
sofisticação do
mecanismo de
licenciamento,
maior o tempo para
realização da
comercialização e
maior o custo de
manutenção.
O módulo de
controle de
estoque será
comercializado
como um
componente
separado do
sistema e irá
requerer licença.
A ferramenta
FlexLM é
utilizada por
toda nossa
organização para
prover
capacidade de
licenciamento.
Disponibilidade (prioridade: alta)Existe algum
requisito a
respeito do tempo
médio entre
falhas do sistema
(MTBF)?
Quanto maior a
disponibilidade,
maior o grau de
comercialização do
sistema.
Disponibilidade
é uma
característica
chave do
produto. O
produto deve ter
um MTBF de 60
dias
Suporte a plataformas (prioridade: alta)Que plataformas o sistema deve suportar?O desenvolvimento para uma única
plataforma pode
reduzir o potencial
de comercialização
do produto.Também
pode permitir uma
integração com as
características das
plataformas.
O produto deve ser
implementado
para rodar nas
seguintes
plataformas
UNIX:
Sun Solaris
IBM AIX
HPUX



Fonte/referencias:

Peter Eeles, Senior TI arquitecto, IBM

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

quinta-feira, março 20, 2008

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.