Belix, José Eduardo;
Ivanoff, Gregorio Bittar. Sobre inconsistências na implementação de requisitos: Uma abordagem prática. Coordenação:
Italo Santiago Vega. GEMS 377, Encontro,
Oficina da organização:
Requisitos em modelagem. Interações: ver
estratégia em requisitos.
Grupo de Estudos em Modelagem de Software, Pontifícia Universidade Católica de São Paulo
PUC-SP, 10 mar.
2020.
Como definir um requisito como complexo (sem usar subjetividade da equipe ou de seu observador)?
Um
requisito complexo é aquele que cobre um cenário de vários caminhos possíveis.
Um exemplo é um requisito do tipo “Cliente Realiza Compra Online” em uma plataforma de compras. Esse tipo de requisito tem um caminho primário, mas lida com caminhos alternativos como a possibilidade do cliente fazer o pedido em múltiplos canais de atendimento distintos, iniciar a compra em um canal e terminar em outro, ter um vendedor fazendo o pedido on-behalf do cliente e por aí vai. São requisitos tipicamente modelados através de técnicas de casos de uso.
Outra situação é um contexto tão complexo para aplicação de uma regra que o requisito tem que ser montado como uma árvore de decisões, onde cada ramo abre novas possibilidades e fecha outras. O cálculo de IOF cai exatamente nesse caso Em resumo, ao contrário de um requisito simples, o requisito complexo abrange múltiplos cenários ou demanda árvores de decisão para poder ser descrito.
Pontos por função, LOC [Linhas de código fonte], heurística, cone da incerteza como base, estimativa em grupo?
Certamente pontos de função e uma variante chamada Pontos de Casos de Uso são aplicáveis para os requisitos do primeiro grupo, ou seja, modeláveis a partir de técnicas de casos de uso.
Estimativas em grupo são sempre muito boas. Pessoas com conhecimento de negócios, arquitetura da solução, programação, testes etc, juntam-se em um petit comité para decidir o tamanho do trabalho. Não é uma abordagem tão metodológica assim, mas é bem razoável. Serve também para os requisitos do segundo tipo LOC (Linhas de código).
Se há uma mistura de grupos de requisitos em um determinada funcionalidade (simples, complexos, novos e existente) somam-se os caminhos possíveis?
Se a pergunta refere-se às métricas de esforço para dimensionar um software, os caminhos possíveis modelados por Pontos de Casos de Uso podem sim ser somados.
Defina documentação OK.
Documentação OK no contexto sugerido no tópico
modelagem em requisitos indica documentação atualizada em relação ao software, quaisquer que forem as técnicas de modelagem aplicadas.
Documentação de software? Documentação do modelo de software (quais)?
Há inúmeras formas diferentes de se documentar software. Quando há múltiplos meios diferentes para se fazer uma tarefa, normalmente isso quer dizer que nenhum meio é eficiente em todos os casos. Um exemplo simples: a
UML modela o comportamento de um software, mas um simples protótipo de tela – não coberto pela
UML – pode dizer muito mais para um usuário e para um programador do que uma pilha de documentos. Esse é um assunto grande demais e pode ser tratado em separado.
Documentação de negócio (quais)?
As necessidades de negócio dos usuários podem ser descritas:
- com requisitos em forma de texto (Casos de uso ou requisitos declarativos),
- com diagramas de processos (IDEF0, BPMN),
- com diagramas de fluxo em swinlanes, simples fluxogramas,
- com protótipos de telas,
- com árvores de decisão,
- com planilhas excel no caso de cálculos.
Meta documentação?
Vários são os objetivos, cada qual com um ponto de vista diferente. Tomando-se o padrão 4+1 de arquitetura como exemplo (apenas exemplo, sem ser exaustivo nas explicações):
Visão Cenários (Scenarios): é o conjunto de requisitos dos usuários. Serve para mostrar as funcionalidades que o time de TI tem que implementar e o que o time de testes tem que testar. Serve também como acordo entre os usuários, ajustando a expectativa deles. Uma vez que o sistema seja implantado, a base de requisitos serve para fazer análise de impacto no caso de novas funcionalidades e/ou alteração das funcionalidades existentes, bem como atender os mesmos pontos listados anteriormente nesse parágrafo.
Visão física (Physical View): Ela cuida da topologia dos componentes de software na camada física, bem como com as
conexões físicas entre esses componentes. Essa visão também é conhecida como visão de implantação. Ela é imprescindível para o time de infraestrutura fazer o deployment do sistema em produção (sistema novo ou atualizações). Também é imprescindível para análise de impacto. Imaginar um caso onde uma rotina agendada (um job) não roda na sua janela de tempo: quais as rotinas que serão afetadas? Caso a janela semanal de manutenção de um servidor seja ampliada, quais rotinas serão afetadas?
Visão Desenvolvimento (Development View): É uma visão para o programador. Mostra como os elementos técnicos do sistema (Classes; componentes, telas, etc.) estão agrupados em pacotes e componentes de
código. IDEs de desenvolvimento fornecem isso de forma nativa. Afinal é necessário saber isso para compilar um código.
Visão de Processos (Process View): Demonstra a comunicação entre componentes de um sistema. Também é uma visão importante para o time de infraestrutura fazer análise de impacto de alterações e troubleshooting no caso de falhas.
Visão Lógica (Logic View): também uma visão de apoio ao desenvolvedor que demonstra os componentes do
sistema segundo as funcionalidades que ele implementa
Documentação ativa?
SEMPRE! A documentação tem que ser viva e atualizada. A melhor forma de se fazer isso é através de ferramentas que interpretem essa documentação e participem ativamente do funcionamento do sistema. Exemplo: uma ferramenta de controle de batches como o CONTROL-M contém toda a sequencia dos Jobs e dos envios de informação entre eles. É uma documentação viva. Infelizmente nem todos os casos são tão claros e diretos.
Documentação de comportamento?
Sem dúvida. Vide resposta
Meta documentação acima.
Palavras-chave:
modelagem de negócios de impacto,
compatibilidade,
investimento,
requisitos
Investment strategy assessment:
Systems in authority. Remodelling Global Cooperation:
Claims in practice 2017. Forming a coalition of people to develop a competition entry, 29 September 2017. Available from <
http://www.ilanet.com.br/cgi-local/portal/bin/view/Ilanet/InvestmentStrategyAssessment?skin=print.pattern >. access on 29 September 2017.
Linhas de código fonte. Disponível em <
https://pt.wikipedia.org/wiki/Linhas_de_c%C3%B3digo_fonte >. Acesso em 12 mar. 2020.
--
GregorioIvanoff - 13 Mar 2020
to top