Fatos e falácias de Engenharia de Software - Requisitos de Software
Autor: Lucas Vegi | Publicado: 2011-09-10T00:12:00-03:00





Pra compensar o tempo sem muitas novidades por aqui, vamos logo retomar às discussões sobre pontos chave da Engenharia de Software.



Depois de abordar tópicos importantes como Reutilização, Estimativas e Profissionais, discutiremos nessa postagem sobre Requisitos de Software, nada mais nada menos que a espinha dorsal de todo o processo de desenvolvimento!

Para quem já vem acompanhando as discussões anteriores relacionadas a Engenharia de Software, acredito que aos poucos está ficando mais claro a relação existente entre os temas discutidos. Isso proporcionará uma visão crítica muito importante sobre todo o processo de desenvolvimento de software.




Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo nº. 04

Fatos
23 - Um dos dois motivos mais comuns de projetos saírem de controle são os requisitos instáveis.
24 - Requisitos errados são mais caros para reparar quando encontrados durante a produção, porém são mais baratos para corrigir no início do desenvolvimento.
25 - Requisitos ausentes são os erros de requisitos mais difíceis de corrigir.

Discussão
Os fatos estudados estão relacionados a problemas com requisitos de software e os impactos causados por eles no andamento de um projeto.


O fato 23 trata especificamente de requisitos instáveis. Segundo Glass [1], requisitos instáveis, juntamente com estimativas pobres e muito otimistas, são as principais causas dos projetos de software saírem de controle. Os problemas causados por estimativas falhas não são diretamente relacionados ao desenvolvimento de software, mas sim à gerência. Já os problemas ocasionados por requisitos instáveis são de desenvolvimento de software e são mais complexos de serem resolvidos que os outros.


Grande parte dos problemas causados por requisitos instáveis são gerados por clientes e usuários não entenderem o problema real que desejam solucionar com o software a ser desenvolvido. 


Comparada a outras engenharias, como a civil, por exemplo, a engenharia de software é um tópico relativamente novo, portanto é normal que tantos problemas por requisitos instáveis existam, haja vista que muitas das soluções propostas por software ainda são inéditas, e quando esse tipo de solução está em desenvolvimento, o fato de não ter um padrão de comparação com algo já feito pra mesma finalidade, acaba gerando grandes incertezas.


Muitas soluções para requisitos instáveis foram tentadas ao decorrer dos anos. Inicialmente achava-se que o congelamento dos requisitos resolveria tais problemas e assim surgiu a proposta de especificação de software a partir de notações matemáticas, os chamados métodos formais. Segundo Sommerville [2], métodos formais oferecem a possibilidade de analisar através do emprego de cálculos matemáticos a consistência e provar que a implementação de um software corresponde à especificação.


Na prática observou-se que o congelamento dos requisitos, assim como a utilização de métodos formais de especificação de software não são eficientes para resolver o problema de requisitos instáveis, pelo contrário, eles podem atrapalhar e muito devido ao engessamento do processo.


Com o tempo ficou claro que para lidar com requisitos instáveis, o projeto teria que ficar em constante refinamento em busca da desejada estabilidade conceitual. Para isso o uso de protótipos da solução é uma boa prática, pois nem sempre o cliente sabe o que quer, mas geralmente sabe o que não quer. Nesse sentido, todo contato do cliente com novos protótipos gera o refinamento dos requisitos já levantados, pois o feedback do cliente com relação ao protótipo serve para direcionar a equipe de desenvolvimento a um caminho cada vez mais próximo do ideal.


Muitas técnicas surgiram com intuito de inserir cada vez mais os usuários no processo de desenvolvimento do software, especialmente no levantamento de requisitos. JAD (Joint Application Development) é uma dessas técnicas. Ela foi criada pela IBM na década de 70 e propõe que clientes/usuários e desenvolvedores trabalhem juntos em reuniões com objetivo de identificar o problema a ser resolvido pelo software, propor elementos de solução, negociar diferentes abordagens e por fim, especificar um conjunto preliminar de requisitos de solução [3].  A metodologia XP (eXtreme Programming) também prevê dentre suas várias propostas, uma interação semelhante entre cliente e desenvolvedor com o intuito de entender melhor o problema e levantar requisitos mais refinados, porém ambas as propostas devem ser muito bem aplicadas para atingirem sucesso, pois de nada adianta se o usuário/cliente escalado para participar do processo não tiver pontos de vista equivalentes ao da maioria dos clientes e usuários potenciais do software.


O desenvolvimento de software baseado em processos auxilia muito na gerência de projetos de software com requisitos instáveis, pois para lidar com tantas requisições de mudanças, é muito importante a gestão ter um processo de gerenciamento de mudanças bem definido. Dessa forma, toda requisição de mudança passa a ser analisada detalhadamente, observando todos os impactos que ela causaria no projeto e nível de custos, tempo e riscos. Após essa análise, a gerência pode tomar a decisão precisa juntamente com o cliente, avaliando se as mudanças solicitadas são viáveis ou não, evitando assim que o projeto saia de controle por uma decisão imprópria.


O fato 24 é um senso comum entre todos envolvidos com projetos, sejam eles de software ou não. Quanto mais cedo requisitos errados forem identificados, menos custoso será para corrigi-los. A correção de erros durante o desenvolvimento pode ser até 100 vezes mais custosa do que as correções feitas nas fases iniciais do processo [4]. A Figura 1, presente em [5], representa exatamente a ordem de crescimento dos custos para correções ao decorrer do progresso de um projeto.


Figura 1: Custos para correção de erros.

Para diminuir os custos com as mudanças e correções, o ideal é refinar os requisitos do projeto o quanto antes possível. Para isso, várias técnicas podem ser usadas e o feedback do cliente nas fases iniciais é de extrema importância para evitar que problemas sejam detectados em fases muito avançadas da produção acarretando em custos e riscos elevados.


O fato 25 trata de algo interessante para refletir, que são os requisitos omitidos de software. Segundo o autor, um dos erros de requisitos mais difíceis de serem corrigidos é o de requisitos ausentes. Existem diversas técnicas de testes dos requisitos para identificar se eles correspondem ao que se espera do software, porém, um requisito não levantado, conseqüentemente também não será testado, porque teoricamente ele não existe.


Requisitos são levantados de diversas formas, mas de forma geral, o processo de levantamento de requisitos se baseia em interações de pessoas e análises de documentos. Devido à alta subjetividade dessas atividades, o risco de que algum requisito do cliente seja desconsiderado no levantamento está sempre presente. 


Segundo o estudo realizado pelo autor, 30% dos erros de software são oriundos de lógicas omitidas de programação. Esse tipo de omissão é geralmente causada por requisitos não levantados. Testes geralmente baseiam-se em requisitos presentes no projeto, portanto, esses erros acabam passando despercebidos nos testes. A dificuldade de identificação desse tipo de erro acaba tornando-os difíceis de serem corrigidos.


Para tornar a análise de requisitos mais eficiente, o levantamento deve ser feito de forma iterativa, pois dessa forma a idéia sobre o problema principal a ser resolvido ficará mais madura e conseqüentemente os analistas passam a ter uma visão mais crítica sobre o problema, identificando os requisitos mais facilmente assim. A interação entre os analistas também é muito importante, pois a troca de informações entre diferentes pontos de vista pode também aumentar essa visão crítica de todos envolvidos.



Controvérsia

Existem poucas controvérsias sobre o fato 23. Antigamente a controvérsia principal a ele era com relação ao congelamento dos requisitos. Hoje é raro encontrar quem discorde de que o congelamento de requisitos é sinônimo de falhas no projeto.


Atualmente a principal controvérsia ao fato 23 gira em torno da utilização de métodos formais para especificação de software. Na prática eles são pouco utilizados pelos profissionais de software, porém a academia ainda defende a “eficiência” de sua aplicação. 


Como o fato 24 é um consenso geral, praticamente não existem controvérsias ao seu respeito. As únicas divergências ao fato 24 são relacionadas às formas de evitar que erros demorem a ser detectados. Existem diversas maneiras de fazer isso, porém dependendo da função que determinada pessoa exerce no processo de desenvolvimento, elas tendem a optar por métodos específicos relacionados a tal função. 


A dificuldade para identificar e distinguir entre os tipos de erros cometidos acaba gerando poucas controvérsias sobre o fato 25. 



Referências


[1] Glass, R. Facts and Fallacies of Software Engineering. Addison Wesley. October 2002.



[2]&nbsp;SOMMERVILLE, I. Software Engineering, 5th edn, Addison-Wesley Publishing Company, Wokingham England. 1996.



[3]&nbsp;GUIMARÃES, E. C. F. O uso da técnica JAD - Joint Application Design para levantamento de requisites. Disponível em: . Acesso em 7 Maio. 2010.

[4]&nbsp;Boehm, Barry, and Victor R. Basili. 2001. "Software Defect Reduction Top 10 List." IEEE Computer, Jan. "Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design stage."

[5]&nbsp;ANDERSON, K. M. Lecture 04: Software Process, Part 1. Disponível em: http://www.cs.colorado.edu/~kena/classes/5828/s07/lectures/04/index.html. Acesso em 7 Maio. 2010.