Aconteceu hoje a primeira aula sobre Análise de Requisitos de Sistemas, na
Pós-Graduação em Produção e Sistemas do
IFF, ministrada pelo
Prof. Dr. Rogerio Atem de Carvalho.
O objetivo desta disciplina é dar ao pós-graduando noções sobre requisitos de software. Cabe esclarecer que o curso não é exclusivo para profissionais de informática, pelo contrário, seu corpo discente é bem diversificado, contendo engenheiros, administradores, etc.
Existe uma dificuldade natural de comunicação entre quem conhece desenvolvimento de software e quem precisa de software. É muito comum que pessoas que precisam de software não saibam bem como o software deva se comportar. Isso é natural. Esta disciplina vem auxiliar neste ponto. Pretende-se capacitar o pós-graduando de Produção e Sistemas a entender, participar e interferir no processo de elicitação dos requisitos. Para tanto, deve-se familiariza-los com um mínimo das linguagens e técnicas de modelagem. Foi discutida, além da abordagem tradicional, uma visão ágil de requisitos e contratos.
É interessante observar que por trás de quase tudo nos frameworks ágeis pode-se encontrar fundamentos do Lean. Tais princípios são muito importantes para a compreensão do contexto de sua aplicação sob a ótica das empresas.
Apesar de parecer, para outros leitores, um óbvio ululante, é preciso ser dito que um software será utilizado com um objetivo (razão de existência), e provavelmente estará integrado dentro do processo produtivo de uma empresa, senão será mais um caso de fracasso.
Neste caso, o software precisa agregar valor à empresa (cliente), sob pena de ser um monte de bits e bytes, bonitinhos somente para quem o construiu. Houve época em que construía-se software usando técnica "A", ou "B", linguagem "C" ou "D", porque estava na moda ou porque se achava bonito. Para tal software o melhor lugar é um quadro na parede.
O Desenvolvimento enxuto propõe princípios para que o software agregue valor ao cliente, seja produzido com qualidade, na hora e momentos certos, alinhado com os interesses e a dinâmica de quem precisa do software. Vale ressaltar: a utilização de técnicas quaisquer sem bom senso, adequação, pode levar ao fracasso.
Foi discutida também "a Regra da Privada". Esta regra foi criada pelo Prof. Rogerio Atem com objetivo didático de discutir sobre o momento certo (mais oportuno/adequado) para mudança de requisitos. Segundo esta regra a mudança de um vaso sanitário de lugar tem um custo baixo enquanto ainda estiver na planta da engenharia civil, porém é muito mais cara após a instalação e o acabamento terminados. Assim também é o software desenvolvido sob o modelo cascata.
Neste ponto entra em discussão o modelo cascata de software, onde a iteração demora a acontecer, e o modelo ágil/lean que propõem iterações rápidas e contato mais próximo ao usuário. No modelo ágil de desenvolvimento as iterações são pequenas e freqüentes, tornando mais prática e tranqüila a identificação e alteração destes problemas.
Continuando neste exemplo, poderíamos imaginar que todos os proprietários de um prédio (stakeholders) pudessem fazer uma visita virtual ao prédio e discutir mudanças antes do construção e acabamento do prédio (produto).
Neste novo modelo, o objetivo é agregar valor ao usuário, portanto é necessário as iterações mais freqüentes para se poder realizar mudanças de escopo.
O escopo precisa ser aberto sob pena de algum dos fatores que alteram constantemente tal escopo tornem o software menos importante do que se desejava inicialmente.
- O escopo pode ser alterado ao se descobrir uma forma mais eficiente, rápida, barata, correta de se fazer algo.
- A legislação pode mudar e obrigar mudanças no escopo.
- A concorrência, os clientes ou mesmo os fornecedores podem obrigar mudanças no escopo.
- O aprendizado do cliente pode suscitar novo pensamento sobre o que foi solicitado inicialmente, e a partir daí surgirem novas regras, novas prioridades, novas soluções, novos requisitos, etc.
Quem trabalha ou já trabalhou sabe como é importante sempre melhorar sua maneira de trabalhar. Possibilidades de melhoria sempre aparecem. Portanto, o escopo do software não pode ser engessado, sob pena de se produzir algo sabendo-se que não é tão eficiente quanto o possível.
O escopo aberto é uma abordagem mais adequada ao aprendizado do cliente e da equipe de desenvolvimento.
Postagens
