Inconsistências na implementação de requisitos
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.
English
Se desejar, apresente
sugestões.
Sistemas podem ter falhas na implementação de requisitos mesmo que haja uma boa gestão dos mesmos. As anotações a seguir representam um ensaio sobre requisitos funcionais e qualidade de testes.
A preparação do encontro GEMS 377 envolveu atividade de exploração do
conflito em requisitos.
Iniciando com uma tipologia de requisitos, diferentes enfoques de enfrentamento práticos na forma de técnicas e processos, foram apresentados e discutidos ao longo da sessão. Introduzidos de maneira informal, podem ser complementados com as sugestões propostas pelo
IEEE (Std 1233, 1998 Edition), ao menos como referencial de discussão.
Sob um ponto de vista sintético, podemos associar requisitos funcionais a
comportamentos de máquina. A atividade de teste procura averiguar se os requisitos foram (plenamente) atendidos. Isto pode ser feito seguindo a ideia de Popper (Falsifiability, Wikipedia, 2020), procurando invalidar afirmações verdadeiras a respeito da qualidade da implementação. Caracteriza-se, assim, uma empreitada de software considerada como Ciência: procura-se demonstrar que os requisitos não foram atendidos pela implementação do modelo proposto como solução.
Edsger Dijkstra procura traduzir tais preocupações por meio de duas sentenças muito representativas:
- "Software testing proves the existing of bugs not their absence."
- "If debugging is the process of removing bugs, then programming must be the process of putting them in."
Questões
- Novas funcionalidades; sistemas raramente são feitos do zero
- Funcionalidades são implementadas sobre plataformas pré-existentes, fornecidas por provedores de software, que não fornecem a base completa de requisitos
- A decisão por adotar desenvolvimento próprio ou contratar provedor é custo e time-to-market
Desenvolvimento de sistemas não é algo que se faça sempre do zero. Pelo contrário, novas funcionalidades costumam ser implementadas a partir de software pré-existente, o qual por vezes foi produzido por fornecedor externo e cujo código-fonte não fica disponível para o contratante.
O trade-off para esse tipo de escolha está ligado a custos e time-to-market. Uma empresa que precise automatizar processos frequentemente opta por contratar software de fornecedores especializados em um segmento.
Esse tipo de software tem a vantagem de já conter muitas regras de negócios implementadas, porém normalmente os fornecedores não disponibilizam os requisitos dessas regras.
De forma similar a empresa pode evoluir um software dela própria, pré-existente, porém sem uma documentação abrangente de apoio.
Caminhos
- POCs [Provas de conceito] detalhadas antes de contratar a solução
- Criar procedimentos de conciliação de dados para detectar possíveis falhas o quanto antes,
- Criar workarounds no caso de falha de sistema
- Definir claramente a janela de trabalho do sistema e implementar suporte operacional, tanto técnico como de negócios durante essa janela
- Manter o tracking de anomalias durante períodos de homologação e tracking de incidentes durante a operação do software para dimensionar homologação
- No caso waterfall, restringir o número de releases por ano para conter custos / uso de recursos de homologação
Com o intuito de conhecer soluções externas, criar provas de conceito bastante detalhadas antes de quaisquer contratações de software.
Criar procedimentos de conciliação de dados para detectar possíveis falhas o quanto antes, permitindo ações tempestivas da área técnica e da área de negócios.
Criar workarounds no caso de falha de sistema. Fazer isso para evitar interrupção da produção (exequível em muitos casos).
Definir claramente a janela de trabalho do sistema e implementar suporte operacional, tanto técnico como de negócios durante essa janela.
Manter o tracking de anomalias durante períodos de homologação e tracking de incidentes durante a operação do software para verificar quão confiável é o processo de homologação da empresa.
Manter capacity adequado à homologação do sistema. Caso a homologação demande muitos recursos e caso o estilo de desenvolvimento seja waterfall, limitar o número de releases de software por ano para reduzir os custos de teste.
Questões
- Há requisitos que não podem ser simplificados. Ex: regras legais.
- Há requisitos onde a complexidade não é inerente e precisa ser identificada e evitada porque ela fragiliza o software e onera a empresa tanto em sua construção quanto em sua operação.
Há situações onde os requisitos são muito complexos e não podem ser simplificados. Ex:
requisitos legais. Essa é a complexidade inerente ao negócio.
Há casos, entretanto, onde a complexidade não é inerente e precisa ser evitada porque ela fragiliza o software e onera a empresa tanto em sua construção quanto em sua operação.
Caminhos
- Cobrar Business Plan da área de negócios para justificar novas funcionalidades
- Buscar fazer um MVP (Minimum Viable Product) e evoluí-lo após estabilização (redução de desperdícios)
- Sempre verificar se as funcionalidades estão em linha com a estratégia da empresa
Requisitos com contexto muito complexo
Questões
- Há requisitos complexos e a validação deles no software é dispendiosa. Ex: regras de IOF.
Às vezes os requisitos não são tão complexos - como cálculos matemáticos - mas o contexto onde aplicá-los é muito difícil de ser descrito com precisão. Um exemplo interessante é o cálculo de IOF:
- Ele prevê duas alíquotas diferentes:
- Múltiplos cenários de aplicação:
- sobre operações de crédito
- sobre operações de câmbio
- sobre operações de seguros
- sobre operações relativas a títulos e valores mobiliários
- sobre operações com ouro, ativo financeiro ou instrumento cambial
- Múltiplas regras que definem o fato gerador
- 34 regras que permitem alíquota zero
- 12 regras que permitem isenção
São muitas regras e elas precisam ser aplicadas em uma sequência correta. É preciso não criar requisitos de forma incremental, mas levar em conta todos os requisitos anteriores para evitar uma
especificação inconsistente por falta de um contexto claro para as regras.
Igualmente importante é a configuração dos cenários nos ambientes de teste antes da execução de um caso de testes. Pode ser que um caso de testes de poucos minutos demande algumas horas de preparação de massa de testes e configuração de cenários.
Caminhos
| Busca de apoio de validação para a área de negócios |
|---|
| Área de negócios usa sistemas porque não tem braço para fazer todas as operações manualmente. É um paradoxo então onerá-la com grandes esforços de homologação, portanto contratar serviços profissionais de teste para auxiliar as áreas de negócio é uma boa estratégia. Esses serviços preparam o ambiente de testes para que esteja com o contexto correto antes da execução dos cenários de teste. |
Alteração de requisitos
Questões
- Dificuldade de manter a base de requisitos compatível com a implementação ao longo de múltiplas alterações
Mesmo que um sistema e toda a sua documentação estejam OK em um determinado momento, isso não significa que continuarão OK após
mudanças.
Caminhos
| Preservar e atualizar os artefatos e ambientes de testes |
|---|
| Buscar suporte profissional para montar uma área de testes que manterá os artefatos já criados e os evoluirá conforme demanda. Os artefatos são os planos e casos de testes e as evidências geradas. Assume-se que a base de requisitos seja corretamente atualizada. |
| Estratégia de Deployment |
|---|
| Não fazer deploy em datas específicas (ex: fechamento de mês. Sempre escolher momentos adequados para a implantação de uma nova funcionalidade: Não fazer deployment pouco antes ou pouco depois de fechamento de mês. Essas são data onde procedimentos especiais das áreas de negócio são executados, como balanços mensais. Normalmente a área de negócios e a área de TI estão mais ocupadas que o normal nesse período e terão menor disponibilidade para fazer frente a eventuais problemas. |
| Normalmente as empresas não têm pessoal completo em finais de semana. Caso isso seja verdade e caso os sistemas sejam usados aos finais de semana, não fazer deployment às quintas e sextas-feiras, tampouco sábados e domingos. Caso haja problema, não haverá pessoal técnico e de negócios para resolvê-lo. |
| Sempre ter um plano de rollback antes de fazer um deployment. |
| Estratégia de Roll-out |
|---|
| Evita turning-key: busca roll-out progressivo. |
| Confiabilidade de software é uma abordagem prática: colocar o software em produção restrita e controlada e aumentar a abrangência assim que ele se prova confiável. Não dá pra fazer turning-key de uma coisa nova e grande. Esse é um jeito de pegar erros que a homologação comum não consegue pegar. |
Aprendizado e crescimento:
conflito em escolha
Palavras-chave:
desafios em implementação de sistemas,
modelagem de negócios de impacto,
desenvolvimento,
fornecedores,
modelagem,
heurística,
requisitos,
produção,
recursos,
apoio
English: requirements in modeling,
modeling requirements
Action in algorithms /
Ação em algoritmos:
Algorithms in projects /
Algoritmos em projetos. 2 August / ago. 2019.
Claims in practice Education /
Educação Reivindicações em prática:
2019.
First edition: March - June,
Second edition: August - November /
Primeira edição: março - junho,
Segunda edição: agosto - novembro. Education enacted from the
production platform indicated in
2019 Scorecard / Educação concretizada a partir da
plataforma de produção indicada em
pontos 2019, 2 August / ago. 2019. Available from / Disponível em <
http://www.ilanet.com.br/cgi-local/portal/bin/view/Ilanet/ActionInAlgorithms?skin=print.pattern >. access on / Acesso em 2 August / ago. 2019.
Falsifiability. Available from <
https://en.wikipedia.org/wiki/Falsifiability >. access on 12 march 2020.
--
GregorioIvanoff - 11 Mar 2020
to top