Marco Mendes´s Blog

O senso comum nos diz que a coleta de requisitos nos ajuda a entender um determinado problema. Entretanto, requisitos são uma forma de definir uma solução e não de entender um determinado problema. Para entender um problema, devemos trabalhar em suas causas raízes através de técnicas formais chamadas de identificação e análise de problemas.

Estas técnicas de identificação e análise de problemas são trabalhadas em uma excelente apresentação por um autor chamado Kurt Bittner que trabalhou anos na Rational como gerência de requisitos e possui excelentes livros de modelagem de casos de uso. Faço aqui um resumo destas técnicas, que devem estar no arsenal de qualquer analista de requisitos, e compartilho ao final deste blog o excelente material disponibilizado por este autor.

• Técnicas dos Cinco Porquês (5P). Esta técnica é uma abordagem usada para explorar relações de causas e efeitos de um determinado problema. Por exemplo, se recebemos uma requisição do tipo “Precisamos de um novo Web Site”, devemos recursivamente nos perguntar o porquê desta requisição. Por exemplo: “Estamos perdendo espaço para os competidores”. Mas porque estamos perdendo espaço para os competidores? Talvez seja porque o nosso site não reflita as nossas ofertas atuais de produtos. E continuamos neste processo até que a verdadeira causa raiz do problema (e não o sintoma) esteja elicitado. O número 5 é uma referência básica (número mágico) do número de questionamentos a serem feitos.
• Espinhas de Peixe (Diagramas de Ishkawa). Esta técnica permitir categorizar as causas raízes de um problema e agrupá-las adequadamente. Como esta técnica utiliza esquemáticos gráficos, ela é ideal para brainstorming de grupos e permite representar muitas perspectivas associadas a causas de um determinado problema.
• Mapas mentais. É uma alternativa a diagramas de espinha de peixe em um formato gráfico mais livre. Esta técnica tem se tornado bastante popular com a disseminação de ferramentas para a montagem de mapas mentais (MapMinds).
• Gráficos de paretos. Um gráfico de pareto (Pa Ray To) é um gráfico de barras onde os valores plotados são arranjados em ordem decrescente. Entretanto, esta técnica somente se aplica se possuimos dados sobre as possíveis causas de um problema.

Além destas técnicas, um outro aspecto interessante na análise de problemas é a determinação de “objetivos” ou resultados desejados. Isto porque é inútil trabalhar em um problema (e suas causas) se não existe um objetivo claro ou preciso a ser alcançado. Neste caso, a técnica de “resultados desejados” pode ser usada. Um “resultado desejado” é algo que o usuário ou cliente deseja alcançar no uso da solução. Para isso, devemos associar a cada requisito um resultado desejado e garantir através de uma matriz de rastreabilidade que não existe um “resultado desejado” sem a cobertura de requisitos.

O resumo de toda esta questão é que a “análise de problema” é algo diferente das técnicas de “coleta e elicitação de requisitos”. Requisitos definem soluções. Antes da definição de requisitos, entretanto, devemos conhecer os problemas e oportunidades que queremos tratar.

A apresentação com estas técnicas está disponível aqui para download.

Pensamento do dia:

“Quem tem somente um martelo como ferramenta, tende a achar que tudo que existe no mundo são pregos”

.

Ouço com alguma frequência perguntas sobre referências de bons livros de engenharia de software em tópicos como requisitos, arquitetura, Java ou gerência de configuração. Comecei uma compilação na Amazon através do seu recurso chamado ListMania que tem como objetivo permitir que pessoas avaliem tecnicamente livros.

Alguns destes livros estão disponíves em português e podem ser adquiridos nas boas livrarias técnicas do Brasil. Outros, infelizmente, somente estão disponíveis em inglês.

• Livros de Gerência e Especificação de Requisitos
  Sem comentários »

O Eclipse cresce, a cada dia, em popularidade e funcionalidades dentro da comunidade de desenvolvedores e em particular na comunidade Java. Uma pergunta intrigante neste meio é: “Quais as funcionalidades mais usadas pelos desenvolvedores Java no uso do Eclipse?”.

A resposta parcial a esta pergunta foi respondida a partir de um trabalho de pesquisa muito interessante, realizada por pesquisadores da Universidade de British Columbia, no Canadá. O artigo mostra as funcionalidades mais usadas pelos desenvolvedores e é extremamente útil para que instrutores e líderes técnicos possam focar seus ensinamentos para as equipe Java nas funcionalidades mais populares em seus cursos ou tutorias.

Do ponto de vista de engenharia de requisitos e engenharia de usabilidade, o artigo apresenta evidências que usuários tendem a usar apenas um pequeno sub-conjunto de funcionalidades de um software complexo.

Leia aqui o paper: How Are Java Software Developers Using the Eclipse IDE?

A modelagem de casos de uso lida com a formalização, documentação e comunicação de partes dos requisitos funcionais de sistemas computacionais e de processos de negócio. Contrariamente ao senso comum, a escrita de um modelo de casos de uso não é uma tarefa trivial e requer muita atenção devido a detalhes que não são óbvios para o analista de requisitos iniciante.

Trabalho aqui um exemplo de como escrever e como não escrever casos de uso, composto de erros comuns a analistas iniciantes e um refinamento sucessivo para a correção destes erros e produção um descritivo maduro de casos de uso. O exemplo é composto de 7 passos, refinados incrementalmente em níveis crescentes de maturidade.

Escolhemos como exemplo um processo didático de saque de dinheiro em uma máquina 24 horas, chamada aqui de máquina ATM (Automatic Teller Machine). Neste processo de negócio, podemos identificar um caso de uso de sistemas chamado “Sacar Dinheiro”, ativado por um ator primário chamado Correntista.

A nossa primeira tentativa de descrever este caso de uso segue abaixo:

Caso de Uso - Sacar Dinheiro - Versão 1

Ator Primário: Correntista
Objetivo: Permitir ao correntista de um banco conveniado ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O correntista insere a senha e o valor a ser retirado.
3. O correntista retira o dinheiro da máquina 24 horas.

Embora este processo atinja o fim esperado (dinheiro em espécie na mão do correntista), ele não descreve a interação entre o ator primário e o sistema sob desenho. O objetivo primário de um caso de uso é descrever a interação entre atores e o sistema sob desenho. Em uma metáfora com um jogo de ping-pong, a bola na versào 1 fica o tempo todo em um lado da mesa. Não existe conversação, não existe diálogo e portanto não existe captura dos processos de negócio que devem ser conduzidos pelo sistema.

A nossa segunda tentativa de descrever este caso de uso corrige este problema.

Caso de Uso - Sacar Dinheiro - Versão 2

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação do cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema valida a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A versão 2 é uma clara evolução. Existe um diálogo entre o ator e o sistema sob desenho. Alguns erros, entretanto, ainda persistem. Observemos, por exemplo, o passo (2). Como estamos projetando o sistema da máquina 24 horas, devemos nos lembrar que está fora do escopo (por pura impossibilidade) do nosso sistema realizar validações como por exemplo “Cartão Bloqueado ou Cancelado”. Isso é realizado pelo sistema do banco real (instituição de crédito), que se apresenta então como um ator secundário no contexto do nosso sistema. Isso seria identificado no mundo real através da definição da fronteira ou limite do nosso desenho. O erro aqui, portanto, foi ignorar a existência do ator secundário Banco Instituição de Crédito na descrição. Isso nos leva a terceira versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 3

Ator Primário: Correntista
Ator Secundário: Instituição de Crédito
Objetivo: Permitir ao correntista de uma instituição de crédito conveniada ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A terceira versão captura nos passos 2 e 6 as interações com atores secundários, ausentes na versão 2. Mais uma vez, entretanto, erros ainda existem na descrição. Um caso de uso deve capturar todos os processos de negócio realizados, sem no entanto entrar no mérito de como estes processos serão implementados. Em outras palavras, os casos de uso capturam as interações (O QUÊ), sem se preocupar com a implementação destas interações (COMO). Na versão 3, não capturamos processos básicos de um saque bancário, como por exemplo a validação da existência de dinheiro disponível na dispensadora de dinheiro, as restrições de saques diários, restrições de horários e o débito em conta corrente ao final da operação. Isso nos leva a uma quarta versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 4

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Embora esta versão 4 seja já razoável, muitos analistas de requisitos terminam o trabalho de escrita de casos de uso neste ponto. Estes analistas se esquecem que a ausência dos fluxos alternativos ou de exceção subestima a complexidades dos sistemas computacionais e gera desvios nos cronogramas de projeto. Portanto, é fundamental identificarmos os pontos de extensão deste fluxo. Não devemos, entretanto, realizar este processo verticalmente, mas primordialmente em amplitude para em um segundo momento realizarmos a escrita de cada ponto de extensão. Isso nos leva a versão 5, agora com os fluxos alternativos/exceção.

Caso de Uso - Sacar Dinheiro - Versão 5

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Ativado do Passo 2 - Cartão Inválido
Ativado do Passo 2 - Cartão Bloqueado ou Expirado
Ativado do Passo 2 - Cartão Não Suportado pela Máquina 24 horas
Ativado do Passo 4 - Senha Inválida
Ativado do Passo 4 - Saldo Insuficiente
Ativado do Passo 4 - Limite Diário na Instituição de Crédito Ultrapassado
Ativado do Passo 5 - Limite de Saque do Banco 24 horas Ultrapassado
Ativado do Passo 5 - Limite de Saque no Horário Ultrapassado
Ativado em Qualquer Passo - Cancelamento da Operação pelo Correntista

Outros pontos de extensão podem existir, naturalmente. O exemplo procura mostrar o fato que um brainstorming destes fluxos alternativos deve ser feito para que estes pontos de extensão sejam capturados.

Dentro da evolução da descrição, devemos também realizar o detalhamento de cada ponto de extensão. Um exemplo para o fluxo Senha Inválida é colocado abaixo.

Caso de Uso - Sacar Dinheiro - Versão 6
…
Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

Este trabalho, como citado, deve ser realizado para cada ponto de extensão da descrição do caso de uso.

Finalmente, devemos lembrar sempre que o modelo de caso de uso captura apenas interações entre os atores primários e o sistema sob desenho. Informações complementares como regras de negócio, interfaces gráficas, desenho detalhado ou persistência não são capturados na descrição. Estas informações podem (e devem complementar) a descrição de um caso de uso, sem entretanto interferir na legiblidade da leitura dos fluxos. A versão 7 (e última) deste artigo mostra como isso poderia ser realizado para regras de negócio simples do nosso exemplo de caso.

Caso de Uso - Sacar Dinheiro - Versão 7 (Final)
…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

… Outros Pontos de Extensão

Regras de Negócio
…
RN006 - Se correntista não possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado.
RN007 - Se correntista possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado mais o valor do limite de crédito.

… Outras regras de negócio

O resumo deste pequeno artigo mostra ao leitor que o processo de escrita de casos de uso é complexo e cheio de nuances. Para os interessados, sugerimos o excelente “Escrevendo Casos de Uso - Allistair Cockburn”, que descreve em bastante profundidade como escrever e como não escrever casos de uso.

Uma das maiores falhas de gerentes e líderes técnicos em projetos de software é ignorar os riscos técnicos inerentes em tecnologias como J2EE, .NET, Delphi, VB, SAP/R3, entre tantas outras. Exemplos destes riscos manifestados incluem:

• Sistemas Web ou de banco de dados que não escalam por ausência de testes de desempenho
• Erros em operações financeiras por falhas de precisão em representação numérica
• Alta taxa de erros em sistemas de atendimento (call center) e perda de clientes devido a falta de testes de usabilidade.

Muito dinheiro é perdido anualmente no Brasil devido a estas falhas. Pense por um instante quantas horas de projeto provavelmente voce já precisou gastar devido a falhas desta natureza…

Um forma de dar com este problema é realizar, no começo do projeto, a identificação dos requisitos não-funcionais ou suplementares de um produto. Um requisito não-funcional determina um critério de qualidade a ser observado, como por exemplo o tempo médio de resposta das telas de um sistema, a taxa de crescimento anual em registros de um banco de dados, a precisão numérica de operações financeiras ou os browsers suportados em uma aplicação Web.

Normalmente estes requisitos podem ser avaliados e medidos durante o ciclo de vida de um projeto, o que garante acordos minímos de qualidade do produto em construção. Uma boa equipe deve, portanto, criar um mecanismo de aferição destes requisitos não-funcionais ainda nas fases preliminares do projeto. Chamamos aqui este mecanismo de aferição de uma arquitetura executável, que consiste de código executável que viabilize a construção do sistema como um todo (requisitos funcionais) e sua operação em produção sem contratempos. Metaforicamente, a arquitetura executável é similar a fundação de um prédio de engenharia civil, que consiste de uma estrutura que garanta que todos os andares de prédio sejam montados posteriormente.

Criamos um roteiro abaixo que mostra como criar uma arquitetura executável, em três passos:

1. Identificação dos Requisitos Não-Funcionais
2. Criação de uma prova de conceito para cada requisito não-funcional que seja risco técnico alto.
3. Validação da arquitetura executável, que consiste do conjunto de provas de conceito realizadas no item 2.

O passo 1 deve ser realizado a partir de questionários e modelos disponíveis na literatura como a norma ISO 9126 ou o modelo FURPS+ (Usado para coletar requisitos não-funcionais no RUP).

O modelo FURPS+, por exemplo, trabalha os seguintes aspectos de qualidade:

• Funcionabilidade: Estética e consistência na interface com o usuário.
• Confiabilidade: Disponibilidade (a quantidade do sistema “funcionando apropriadamente”), exatidão dos cálculos do sistema e a capacidade de recuperação do sistema após falhas.
• Desempenho: Rendimento do processamento, tempo de resposta, tempo de recuperação, tempo de inicialização e tempo de encerramento.
• Suportabilidade: Possibilidade de teste, adaptabilidade, sustentabilidade, compatibilidade, configurabilidade, instalabilidade, escalabilidade e possibilidade de localização.

O problema primário destes modelos é que eles são áridos para iniciantes e pessoas sem background arquitetural. Para ajudar neste problema, colocamos abaixo uma versão mais leve, em formato de questionário, baseado na norma ISO 9126.

1. Precisão
   • O sistema realiza operações financeiras? Se sim, especifique o número de casas de precisão destes cálculos.
   • O sistema é de extração de dados/estatístico/ engenharia e realiza cálculos matemáticos complexos ? Se sim, especifique o número de casas de precisão das regras de transformação/cálculo.
   • O sistema manipula medicamentos, compostos quimícos ou elementos cuja dosagem possam causar danos a seres humanos?
2. Interoperabilidade
   • O sistema se comunica com outros sistemas, hardwares ou bases de dados? Se sim, especifique os sistemas de comunicação, hardwares ou bases de dados.
   • O sistema é de comércio eletrônico (B2C ou B2B)? Se sim, especifique os sistemas de comunicação do B2C ou B2C.
3. Segurança
   • O sistema deve realizar controle de acesso (autenticação e autorização)?
   • O sistema deve garantir o sigilo das informações trafegadas na rede interna ou internet (condidencialidade e integridade)?
   • O sistema deve realizar auditoria (log) das operações?
4. Maturidade
   • O sistema deve funcionar vinte e quatro horas por dia, sete dias por semana (missão crítica)? Se não, especificar o tempo máximo que o sistema pode ficar fora do ar (ou alternativamente porcentagem mínima de operação).
5. Tolerância a Falhas/Recuperação de Falhas
   • Em caso de falha do sistema, existirá algum plano de contingência ou de retomada de operação?
     Se não, especificar o tempo máximo que o sistema pode ficar fora do ar.
6. Facilidade de Entendimento
   • O sistema deve ter help-online ou manual?
   • Deve haver treinamento ou workshops para os usuários do sistema?
7. Operabilidade
   • O sistema usa hardwares específicos (canetas óticas, PDAs, URAs, telefones celulares, plotters ou outros)?
   • O sistema é de pronto atendimento (ex: call-centers)?
   • stema deve operar em browsers outros além do Internet Explorer?
8. Comportamento de Tempo
   • O sistema deve ter funcionalidades que rodem abaixo de seis segundos? (*) Seis segundos é um valor, medido em testes de usabilidade, onde usuários de sistemas computacionais começam a perceber a latência do sistema em uso. Como todo valor, ele deve ser contextualizado à sua realidade.
9. Comportamento de Recursos
   • O sistema irá rodar na Internet ou Intranets de grande porte? Se sim, especificar o número máximo de usuários esperado em horários de pico.
   • O sistema irá manipular bases de dados com muitos registros? Se sim, especificar o número máximo de registros e a taxa de crescimento anual.
10. Conformidade e Facilidade de Troca
    • O sistema deverá rodar em quais sistemas operacionais?
    • O sistema deverá rodar em outros hardwares além dos PCs? Se sim, especificar quais hardwares.
11. Padronização
    • O sistema deve obedecer a alguma lei, norma, regulamentação ou portaria governamental? Se sim, especifique.
    • O sistema deve obedecer a algum padrão definido na organização alvo onde o sistema irá funcionar. Se sim, especifique o padrão.
12. Facilidade de Instalação
    • O sistema deve possuir instalador para usuários finais?

O questionário acima não é completo. Remova, altere e adicione itens ao mesmo, mas não deixe de ter o seu roteiro para entrevistar os seus usuários e coletar estes requisitos suplementares. Temporalmente, você deve terminar esta coleta na fase de iniciação do projeto pois estes requisitos são críticos e normalmente de alto risco. Por exemplo, se o seu projeto tem vinte semanas de duração, você deve ter extraído os requisitos não-funcionais e riscos associados nas duas primeiras semanas do projeto.

Ao terminar este processo, iremos partir para o item 2, que consiste em montar provas de conceito que mitiguem os potenciais riscos destes requisitos. Para isso, iremos trabalhar um exemplo simples. Suponha que coletemos um requisito de desempenho que nos peça para suportar 4.000.000 transações por dia e um máximo de 200 usuários concorrentes no sistema. Um requisito desta natureza impõe um alto risco no produto pois existe uma alta chance de não ser suportado em uma típica configuração PC Intel + windows + Servidor Web. Se existe o risco, devemos mitigá-lo. A mitigação deve ser feita com código executável e não com modelos UML apenas. Criamos então uma primeira versão do produto, que chamamos de Alfa 1, que consiste de um requisito funcional implementado sujeito as condições do requisito não-funcional em análise. Por exemplo, podemos implementar um versão simplificada de um relatório ou página sendo consumida simultaneamente por 200 usuários. A versão Alfa não possui compromissos reais de funcionalidade como por exemplo possuir todos os campos ou realizar todas as consistências de negócio, mas deve ser suficientemente real para mitigar o risco. No nosso exemplo poderíamos ter descoberto que precisaremos de duas máquinas em um cluster para operar com tal carga. O risco foi mitigado e a topologia física agora se baseia em uma decisão técnica e não em uma especulação ou estimativa.

O procedimento exemplificado acima é repetido para cada risco identificado e novas versões (Alfa 2, 3, N) são geradas ao longo de alguns dias ou algumas semanas para projetos de maior porte. Temporalmente, o primeiro terço da vida do projeto deve conseguir gerar uma arquitetura executável que mitigue todos os riscos destes requisitos suplementares. Em um projeto de vinte semanas, este processo deve ser encerrado até a sexta ou sétima semana. O passo 2 (Criação das provas de conceito) se encerra aqui.

Finalmente, temos um conjunto de códigos evolutivos que compreendem alguns requisitos funcionais (normalmente entre 5 e 20% do escopo do sistema), que atendem a todos os requisitos não-funcionais que impõe riscos técnicos alto no sistema. Chamamos isso de uma arquitetura executável, que deve ser então testada e validada por um audiência maior. Eventualmente, ajustes devem ser feitos e novos alfas serão produzidos até que a arquitetura se estabilize. Este produto é chamado de arquitetura executável e serve como linha de base arquitetural do sistema. O passo 3 se encerra aqui.

Quais as vantagens desta abordagem, pode perguntar o leitor mais cético?

• A grande maioria dos riscos técnicos do sistema foram mitigados. As surpresas técnicas em produção nao existem mais, pois foram detectadas, analisadas, implementadas, testadas e homologadas previamente.
• O tempo investido em arquitetura permite agora a paralelização dos recursos o que fornece economia de escala em médio prazo.
• O retrabalho de projeto é reduzido drasticamente. Por exemplo, cito o caso de uma empresa de Belo Horizonte que detectou tardiamente em um projeto que o browser Mozilla precisava ser suportado em sua aplicação Web (Veja novamente o item Operabilidade no item 1 do nosso processo). Após mais de 50 requisitos incorretos, isso gerou um retrabalho de mais de 1000 horas e um custo extra de mais de 50.000 reais!

  A pergunta que pode ficar é: Quem cria uma arquitetura executável? O arquiteto de sistemas é o papel responsável pela criação de uma arquitetura executável. O arquiteto, entretanto, nào é um super-homem. Ele é muitas vezes composto de um comitê de pessoas que em um trabalho conjunto irão identificar e mitigar riscos técnicos e então criar a arquitetura executável de um sistema.

  Se você está começando um novo projeto agora, pare por cinco minutos e pense. Você quer gastar horas e horas intermináveis em sessões de depuração de código à noite. viver a pressão de atrasos, falta de qualidade no código e ter noites mal dormidas? Se não, invista agora em criar a sua arquitetura executável do seu sistema. O trabalho é desafiante, mas o benefício é garantido!

  1 comentário »

O analista de requisitos é o profissional responsável primário pela identificação, análise, priorização, detalhamento de requisitos e principalmente nos processos de controle de mudanças ao longo do ciclo de vida de um software. Este analista tem papel fundamental para o sucesso dos projetos, no apoio ao controle de escopo, prazo e custo realizado pelo gerente do projeto, na interface com os envolvidos (stakeholders) e na passagem do conhecimento de negócio para os analistas de sistemas, desenvolvedores, testadores, arquitetos de software e outros membros do projeto.

Para realizar bem este papel, é necessário que o analista tenha um perfil dinâmico, investigativo e que fomente uma comunicação franca entre todos os envolvidos no projeto. Tecnicamente, é necessário se atualizar e estudar técnicas modernas de análise de requisitos como a gerência de requisitos, modelagem de domínio, UML 2, modelagem de casos de uso, modelagem de processos de negócio/BPMN, mecanismos de controle de mudanças (Change Control Board), desenvolvimento iterativo, entre outras. Coloco abaixo uma lista primária de recursos comentados para apoio ao analista de requisitos iniciante neste complexo mas importante processo.

• Requirements - An Introduction - Nível: Introdutório - Scott McEwen Metasys Technologies, Inc - Abril 2004
  http://www-128.ibm.com/developerworks/rational/library/4166.html

• The seven habits of effective iterative development - Nível: Introdutório - Eric Lopes Cardozo (eric@empulsys.com), Founder and Director, Empulsys - Junho 2002
  http://www-128.ibm.com/developerworks/rational/rationaledge/

• Diagramação UML 2.0 - Nível: Introdutório - Scott Ambler
  http://www.agilemodeling.com/essays/umlDiagrams.htm

• Modelagem UML - Nível: Introdutório - Scott McEwen Metasys Technologies, Inc. - Abril 2004
  http://www-306.ibm.com/software/rational/uml/

• Ferramentas para Redução de Riscos em Gerência de Requisitos - Nível: Intermediário - IBM - 2004 - Requirements and Analysis Kit
  1 comentário »

A escrita de casos de uso não é um processo simples. Através de um pequeno tutorial de casos de uso descrevemos os cuidados e nuances que um analista de requisitos deve considerar ao escrever um modelo de casos de uso.