Conforme visto anteriormente, no tópico sobre Engenharia de Requisitos, num ambiente de desenvolvimento de software estamos constantemente criando, mudando, adaptando e aperfeiçoando os softwares. Nosso objetivo é conseguir desenvolver um produto de software que atenda às necessidades dos clientes e as demandas de mercado.
Quando fizemos isto estamos realizando alterações nos requisitos do software. Lembrando que requisitos de software podem ser compreendidos como a capacidade do software que deve ser atendida pelo sistema para satisfazer o problema do usuário. (DORFMANN; THAYER, 1990).
As vezes não nos damos conta dos problemas que ocorrem quando realizamos os trabalhos de manutenções em requisitos de software, mas lhes garanto que é algo muito comum num ambiente de desenvolvimento de software.
Os maiores problemas relacionados ao processo de Engenharia de Software são apresentados nas etapas de levantamento e especificação dos requisitos:
Problemas de Escopo: as limitações do sistema são mal definidas ou o cliente especifica detalhes técnicos irrelevantes que confundem ao invés de esclarecer os objetivos gerais do sistema (SOMMERVILLE, 2003).
Problemas de Entendimento: Os clientes não estão certos das necessidades, não compreendem as capacidades e limitações de seu ambiente computacional, não tem pleno domínio do problema, dificuldades para expressar o que necessitam, omitem informações que acreditam ser óbvias, criar requisitos conflitantes ou especificam requisitos ambíguos ou impossíveis de se testar (SOMMERVILLE, 2003). No processo de especificação dos requisitos, os problemas mais comuns estão relacionados aos clientes e desenvolvedores, pois nem sempre o cliente entende os processos de software num grau satisfatório para auxiliar na produção da especificação de um requisito viável. Por sua vez, o desenvolvedor também nem sempre compreende a área de aplicação suficientemente para produzir a especificação de forma satisfatória (PAULA, 2001).
Problemas de Volatilidade: Os requisitos são modificados ao longo do tempo (SOMMERVILLE, 2003).
Além disso, também é um problema comum o cliente pedir mais do que pode ser disponibilizado, considerando as limitações inicialmente impostas pelo negócio (SOMMERVILLE, 2003).
Por fim, existe também o problema relacionado à etapa de Gerenciamento de Requisitos que em algumas situações deixa de ser aplicado, comprometendo o gerenciamento dos requisitos especificados e perdendo o controle sobre suas alterações. Conseqüentemente, se um requisito for modificado, não há como identificar quais os demais requisitos que podem ser afetados por esta modificação (SOMMERVILLE, 2003).
Para resolvermos ou pelo menos minimizarmos é que executamos trabalhos de Gerenciamento de Requisitos de pretendo lhes apresentar numa próxima postagem.
Cordialmente,
Marcelo Schumacher
http://isosoftware.blogspot.com/
Bibliografia:
DORFMANN, Merlin; THAYER, Richard H. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.
PAULA, Wilson de Pádua Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Cordialmente,
Marcelo Schumacher
http://isosoftware.blogspot.com/
Bibliografia:
DORFMANN, Merlin; THAYER, Richard H. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.
PAULA, Wilson de Pádua Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
Boa tarde Pessoal!
ResponderExcluirInteressante no aspecto que trata do processo de desenvolvimento de sistemas e seus estimulantes desafios.
Tais como esclarecer para equipe da área técnica, digo desenvolvedores
que nem sempre compreendem afundo o negócio do cliente o que gera dificuldades,
as atividades do ramo de serviços do cliente. Uma vez entendida as regras
de negócio a desenvolver, com em menor tempo e com menos embaraços se atingem os resultados.
Por outro lado, o cliente, que domina a sua área e sabe o que quer pelo menos
funcionalmente, nem sempre compreende aquilo que é cabível dentro do tempo que deseja, e como esta "pagando" quer a solução apenas isso lhe interessa na maior das vezes.
Todos que atuamos nessa área sabemos que assumir projetos que requerem muitas definições,
uma equipe plenamente integrada ao objeto do negócio dentro de um cronograma apertado é um risco muitas vezes necessário devido a grandeza e solicitação do cliente.
Desta forma; grandes projetos, pessoas em integração com a lógica do sistema a ser desenvolvido,tempo curtíssimo (corda no pescoço). Requer necessariamente de treinamentos constantes, liderança de pulso firme e uma relacionamento interno (entre funcionários) e externo (com parceiros e clientes) satisfatório para contornar situações difíceis e cobranças.
Embora tenha fugido do tema do seu tópico expressei essas conclusões nesse blog que
acredito ser um espaço para troca de informações técnicas e idéias dentro da área de TI.
Abraço Marcelo. Ah, e estou aguardando o seu próximo assunto que parece ser interessantíssimo.
Thiago Corrêa
Olá, Thiago.
ResponderExcluirExcelente sua participação! Está é a idéia, discutirmos os assuntos!
Em breve começarei a postar uma seqüência de posts sobre gerenciamento de requisitos, com os conceitos e uma das técnicas mais conhecidas de se controlar os requisitos que é a matriz de rastreabilidade.
Abraço,
Marcelo Schumacher
http://isosoftware.blogspot.com/