Geraldo Cruz – Pós-Graduado em Ciência da Computação – gafonso@terra.com.br
A solução inicial certamente estará errada, e certamente não será a melhor solução (solução ótima).
Discussão
Com certeza a primeira parte da afirmação é verdadeira, mas a segunda dependerá de um conjunto de fatores.
Afirmaria que é um processo complexo, principalmente em softwares que trabalham em ambientes críticos (envolvendo vidas humanas, valores financeiros), não deixando de lado os outros domínios, pois a busca pela qualidade e a satisfação do cliente em qualquer área é constante, e não seria diferente na área da engenharia de software.
Não arriscaria afirmar que um design de software está errado, e conseqüentemente não apresentará a melhor solução. Isto vai depender de vários fatores, entre eles o conhecimento do domínio (em cada organização um domínio pode ter enfoque diferente), os desenvolvedores e usuários, os recursos, as técnicas e metodologias, a integração dos subsistemas. Uma especificação entendida errada ou feita de uma forma ad-hoc pode influenciar em todo o projeto, e com isto a solução inicial sofrerá mudanças. Não existe a “bala de prata” (metodologia perfeita) que vai solucionar todos os problemas, para cada caso temos de ter uma solução, e se possível um plano B, caso algo aconteça de errado.
Nos métodos tradicionais (RUP1, PSP2, TSP3, Catalysis4), onde os processos são bem definidos, seguindo uma abordagem seqüencial e cada fase sendo bem definida, tem como pontos chave o formalismo (que depende da metodologia) e o foco no planejamento. Mas o grande problema observado na indústria de software é o maior enfoque na produção, especificamente na escrita de código, e pouco tempo dedicado às atividades de concepção do software, conforme observa o GSI5, o que para os métodos ágeis (XP) não é um problema, pois a codificação é sua principal tarefa. Com isto podemos concluir que a adoção de alguma metodologia depende do domínio que estiver sendo analisado.
O design de software, mesmo seguindo o projeto inicial, sofrerá alterações ao longo do seu desenvolvimento. Estas mudanças não devem ser atribuídas somente a erros de entendimento do problema (especificação de determinada funcionalidade), mas também a própria volatilidade dos requisitos, ou seja, mudanças que ocorrem independente da vontade dos stakeholders.
De acordo com as melhores práticas da indústria de software (BRAGA, 2006), o primeiro item é Desenvolver Software Interativamente, para que você possa planejar a entrega gradual, e com isto fazer um desenvolvimento participativo dos stakeholders, minimizando a complexidade. A abordagem dos Métodos Ágeis6 (XP, SCRUM, DSDM, Crystal Cockburn, ICONIX7) parece vir de encontro a esta prática, que tem como conceitos chaves :
- Indivíduos e Interações ao invés Processos e Ferramentas;
- Software executável ao invés de Documentação;
- Colaboração do Cliente ao invés Negociação de Contratos;
- Respostas rápidas a mudanças ao invés de Seguir planos.
Não que os conceitos utilizados do desenvolvimento tradicional (Processos, Ferramentas, Documentação, Planos, Contratos) sejam descartáveis, mas ficam num segundo plano, dando um enfoque maior às pessoas, que podem fazer uso dos conceitos tradicionais.
O desenvolvimento incremental, através de protótipos (utilizando ferramentas CASE), é uma boa alternativa para contornar a volatilidade. É possível ter feedback dos usuários, e isto faz com o processo iterativo auxilie na tentativa de chegar a “solução ótima”. Apesar das ferramentas CASE não serem utilizadas amplamente, PRESMANN atribui a isto, a falta de conhecimento, por parte dos engenheiros de software. Mas hoje, existem pelo menos três fatores técnicos que tentam diminuir a complexidade para desenvolvimento de software: UML8, XML9 e padrões10 e arquitetura software.
O modelo de desenvolvimento baseado em groupware, 3C11, também é uma boa abordagem para implementação de sistemas interativamente. As variáveis envolvidas têm papel fundamental para contornar as mudanças, e facilitar a “complexidade”.
Controvérsia
Na discussão acima deixamos claro que design de software é um processo complexo, pois a indústria cada vez mais necessita de softwares mais complexos, em um tempo curto e com custo baixo, mas isto é impossível de fazer sem planejamento, ainda mais em sistemas de missão crítica.
Como ser iterativo em projetos críticos?
Para cada projeto, temos de analisar as prioridades, as restrições do sistema, o grupo de pessoas envolvidas (desenvolvedores), não adianta querer adotar uma metodologia para todos os tipos de projetos. Em projetos pequenos, os métodos ágeis se enquadram perfeitamente. Analisando o método XP, seus quatro valores básicos - Comunicação, Simplicidade, Feedback e Coragem – são fundamentais para um desenvolvimento incremental, iterativo e interativo.
Uma coisa é certa, o design de software precisa de planejamento, não importa sua dimensão ou complexidade, e independente da metodologia adotada deve ser:
- Construído de maneira incremental;
- Ter iterações curtas;
- Participação ativa dos clientes;
- Melhoria constante do processo.
Se já é difícil chegar a “solução ótima” com a adoção de metodologias, imagine quando não é adotado nenhum processo. Se não for feito um cronograma ou um planejamento, não é possível cumprir prazos, não cumprindo os prazos não se tem credibilidade, e com este cenário tudo pode ser perdido. Se não é possível adotar alguma metodologia de desenvolvimento, que se monte um “roteiro” para que seja possível, no mínimo, entender o que está sendo desenvolvido.
Não é possível construir uma casa a partir do telhado, assim como a maioria dos projetos (em qualquer área) necessitam de alicerce para poder evoluir.
Conforme afirmação do enunciado, a solução inicial não será a melhor solução. Observe a construção de uma casa, olhe pra ela e você vai observar que está faltando alguma coisa. Agora responda, o erro é de projeto ou são das pessoas? Ou será que as mudanças são inevitáveis, e isto é da natureza humana (usuários e desenvolvedores) ou do próprio contexto que se está sendo analisado?
----------------------------------------------------------------------------------
1.Processo Unificado da Rational, adquirido pela IBM, que fornece técnicas para desenvolvedores aumentarem a produtividade. É uma metodologia de desenvolvimento iterativa, centrado em arquitetura e guiada por casos de uso. Por ser customizável, pode ser aplicado em equipe de dese3nvolvimento de qualquer tamanho.
2.Personal Software Process – SEI, Watts Humphrey.
3.Team Software Process – SEI, Watts Humphrey.
4.Método para Desenvolvimento Baseado em Componentes (DBC), utiliza técnicas UML, proposto pela Universidade
de Brighton (UK), por D’ Souza e Allan Wills.
5.Grupo de Sistemas de Informação, INESC-ID, The XIS Project, http://berlin.inescid.pt/projects/xis/
6.Métodos ágeis, direcionado para equipes pequenas, com pouco formalismo, muita interação e fazer só o necessário. http://agilemanifesto.org.
7.ICONIX Software Engineering. Menos burocrático que o RUP. Baseado em UML e simples como XP, possui uma forte Rastreabilidade de Requisitos.
8.Linguagem de Modelagem Unificada (Unified Modeling Language) definida OMG, padrão para modelagem visual.
9.Extend Markup Language, definido W3C, 1999, linguagem padrão para representar dados e metadados.
10.Resultado de experiências e Reengenharia das melhores praticas (Gamma et al., 1994).
11.Modelo de Colaboração, proposto por Ellis et al. 1991, baseado na comunicação, coordenação e colaboração.
Fontes Bibliográficas
1.http://scholar.google.com.br , acessado em 16/08/2006.
2.http://berlin.inesc-id.pt/projects/xis/capsi2003-amrs.pdf Acessado em 18/08/2006.
3.http://www.guj.com.br/content/articles/patterns/iconix_guj.pdf#search=%22iconix%20%2B'software'%22 Acessado em 19/08/2006.
4.http://www.inf.ufsc.br/resi/edicao04/artigo06.pdf#search=%22Metodologias%20%C3%81geis%20Extreme%20Programming%20e%22 Acessado em 19/08/2006.
5.http://agilebrasil.com.br//index.php?option=com_content&task=view Acessado em 19/08/2006.
6.BRAGA, José Luiz. Anotações sala de aula, 2006.
7.PFLEEGER, Shari Lawrence. Engenharia de Software : teoria e prática. 2ª edição. São Paulo: Prentice Hall, 2004. capítulos 3 e 5.
8.PRESMAN, Roger S. Engenharia de Software. 5ª edição. Rio de Janeiro: McGraw-Hill, 2002.
9.SOMMERVILLE, Ian. Engenharia de Software. 6ª edição. São Paulo: Addison Wesley, 2003.capítulos 3 e 4.