Quando se fornece um serviço ou cria-se um produto, seja desenvolvendo um software, escrevendo um relatório ou fazendo uma viagem de negócios, segue-se costumeiramente uma sequencia de etapas para completar um conjunto de tarefas. Estas são realizadas na mesma ordem todas às vezes, por exemplo: não se reboca uma parede sem antes colocar a tubulação necessária; não se assa um bolo sem antes misturar todos os ingredientes. Esse conjunto de tarefas ordenadas pode ser considerado um processo: uma série de etapas que envolvem atividades, restrições e recursos para alcançar a saída desejada (Pfleeger 2004, pág. 36).
Nos últimos anos, vários processos de desenvolvimento de software foram propostos e desenvolvidos. Alguns mais rigorosos com as disciplinas a serem seguidas e os artefatos formais a serem produzidos no ciclo de vida do produto[1] de software (Pfleeger and Atlee 2005, pág. 59). Outros, formulados no final dos anos 1990 por alguns desenvolvedores que resistiam a este rigor, destacam os papéis que a flexibilidade poderia ter na produção de software de maneira rápida sem desviar o foco da qualidade. Eles materializaram seus pensamentos no documento conhecido mundialmente como “Manifesto Ágil[2]” (Agile 2010).
Devido à crescente demanda por software de qualidade, cada vez mais processos de desenvolvimento de software eficazes tornam-se necessários. Em vista disto, é imprescindível que o desenvolvimento e aprimoramento de processos de software evoluam constantemente de forma a atender as necessidades atuais, bem como sirvam como um arcabouço de conhecimentos para a elaboração de novos processos e metodologias de desenvolvimento de software, mais eficientes e adaptáveis.
Howard Baetjer Jr., em seu livro “Software as Capital”, faz o seguinte comentário sobre processo de software:
“… Desde que o software, como todo capital, é conhecimento incorporado, e como esse conhecimento está inicialmente disperso, tácito, latente e incompleto na sua totalidade, o desenvolvimento de software é um processo de aprendizado social. O processo é um dialogo no qual o conhecimento, que deve se transformar em software é reunido e incorporado ao software. O processo fornece interação entre usuários e projetistas, entre usuários e ferramentas em desenvolvimento e entre projetistas e ferramentas em desenvolvimento (tecnologia). É um processo iterativo no qual a própria ferramenta serve como meio de comunicação, com cada nova rodada de dialogo explicitando mais conhecimento útil do pessoal envolvido…”.
(Baetjer 1998, pág. 85) (Pressman 2006, pág.16)
Efetivamente, a elaboração de software de computador é um processo de aprendizado, e o resultado, é a incorporação de conhecimentos coletados, destilados e organizados à medida que o processo é conduzido. Processo é o alicerce da engenharia de software. É ele que permite o desenvolvimento racional e oportuno de softwares de computador (Pressman 2006, pág.17). Ele pode ser definido para atividades como desenvolvimento, manutenção, aquisição e contratação de software (Paula Filho 2009, pág.89). Processos de software formam a base para o controle gerencial de projetos de software e estabelece o conteúdo no qual os métodos técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios, formulários, etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas (Pressman, 2006 pág.18).
O Guia PMBOK® define processo como sendo um “conjunto de atividades inter-relacionadas realizadas para obter um conjunto especifico de produtos, resultados ou serviços[3]” (PMBOK 2004, pág. 373). Segundo o IEEE[4], um processo é “uma sequencia de passos executada com um determinado objetivo” (IEEE 2003).
Para o CMMI[5], um processo é definido quando “tem uma descrição que é mantida”, ou seja, tem documentação que detalha o que é feito (produto), quando (etapas), por quem (papéis), os itens utilizados (insumos) e os itens produzidos (resultados)(CMMI 2006). Os processos podem ser definidos com mais ou menos detalhes e suas etapas podem ter ordenação parcial, o que pode permitir paralelismo entre algumas delas (Paula Filho 2009, pág. 89).
Focando no desenvolvimento de software, Ian Sommerville define um processo de software como um conjunto de atividades que leva à produção de um produto de software (Sommerville 2007, pág. 29). Roger S. Pressman define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade (Pressman 2006, pág.16). Wilson de Paula Filho faz uma analogia interessante, para ele processo é uma receita a ser seguida (Paula Filho 2009, pág. 89).
Processos de softwares são complexos e como todos os processos intelectuais e criativos dependem de julgamento humano. A existência de um processo de software não garante que o software será entregue no prazo, de que ele irá satisfazer as necessidades do cliente, ou exibirá os atributos arquiteturais que levarão às características de qualidade em longo prazo. Um processo deve ser acoplado a uma sólida prática de engenharia de software e deve ser avaliado para garantir que satisfaça a um conjunto de critérios básicos de processo que demonstram ser essenciais para uma engenharia de software bem sucedida (Pressman, 2006 pág. 27).
Não existe um processo ideal. As organizações devem criar, fazer verificações, validar e aperfeiçoar seus próprios métodos (CMMI 2006). Várias destas desenvolvem abordagens inteiramente diferentes, adequadas à sua realidade, para o desenvolvimento de software. Os processos evoluem para explorar as capacidades das pessoas em uma organização e as características específicas dos sistemas que estão sendo desenvolvidos. No caso de alguns sistemas, como os sistemas críticos[6], é necessário um processo de desenvolvimento muito bem estruturado. Nos sistemas de negócios, com requisitos que mudam rapidamente, um processo flexível e ágil é provavelmente mais eficaz (Sommervile, 2007 pág. 42).
Existem vários processos de desenvolvimento software, porém algumas atividades fundamentais são comuns a todos eles (Sommervile 2007 pág.43), como:
Processos de software têm como base modelos de processo genéricos. Esses modelos genéricos não são descrições definitivas de processos de software. Ao contrário, são abstrações do processo que podem ser usadas para explicar diferentes abordagens para o desenvolvimento de software. Eles podem ser considerados como frameworks[7] de processo que podem ser ampliados e adaptados para criar processos mais específicos de engenharia de software. Os modelos genéricos de processos de software amplamente utilizados atualmente são o modelo em cascata, o modelo de desenvolvimento evolucionário e o modelo de desenvolvimento baseado em componentes. Estes, não são mutuamente exclusivos e comumente são utilizados em conjunto, especialmente para desenvolvimento de sistemas de grande porte (Sommerville 2007, pág. 43).
O modelo em cascata considera as atividades fundamentais do processo compreendendo especificação, desenvolvimento, validação e evolução, e as representa como fases de processos separadas, tais como especificação de requisitos, projeto de software, implementação, testes, integração e manutenção. Neste modelo não se dá inicio a fase seguinte antes que a anterior tenha sido terminada. As vantagens do modelo cascata consistem na documentação produzida em cada fase e sua aderência a outros modelos de processos de engenharia. Seu maior problema é a divisão inflexível do projeto em estágios distintos. Os compromissos devem ser assumidos no estágio inicial do processo, o que torna difícil reagir às mudanças de requisitos. Este modelo pode ser usado quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o desenvolvimento do sistema.
A engenharia de software baseada em componentes baseia-se na existência de um numero significativo de componentes reusáveis. O processo de desenvolvimento do sistema enfoca a integração desses componentes, em vez de desenvolvê-los a partir do zero. Ela tem a vantagem óbvia de reduzir a quantidade de software a ser desenvolvido e, desta maneira, reduzir os custos e riscos. Isto também leva a uma entrega mais rápida de software. No entanto, compromissos com os requisitos são inevitáveis e isso pode levar a um sistema que não atenda às reais necessidades dos usuários. Além disso, algum controle sobre a evolução do sistema será perdido se novas versões dos componentes reusáveis não estiverem sob controle da organização que os utiliza.
O modelo de desenvolvimento evolucionário intercala as atividades de especificação, desenvolvimento e validação. Um sistema inicial é desenvolvido rapidamente baseado em especificações abstratas. Este sistema é, então, refinado com as entradas do usuário para produzir um sistema que satisfaça suas necessidades. Esta abordagem é mais eficaz do que a abordagem em cascata na produção de sistemas que atendam às necessidades imediatas dos usuários. A vantagem de um processo de software baseado na abordagem evolucionária é que a especificação pode ser desenvolvida de forma incremental. À medida que os usuários compreendem melhor seu problema, esse conhecimento é repassado para o desenvolvimento do software (Sommerville 2007, pág. 43 – 46).
Embora não exista um processo de software ideal, existe espaço para o aprimoramento (Sommervile 2007, pág.43). Os processos podem incluir técnicas obsoletas ou não tirar vantagem das melhores práticas, porém existem processos customizáveis que permitem aliar a boa prática de desenvolvimento, sustentada por um grande arcabouço de métodos, que permitem desenvolver software de qualidade em tempo hábil.
Referências
Agile (2010), “Manifesto for Agile Software Development”, http://agilemanifesto.org. Acesso em 01 de outubro de 2010.
Baetjer Jr., H., “Software as Capital” (1988), IEEE Computer Society Press.
IEEE (2003), IEEE Software Engeneering Collection on CD-ROM. IEEE, New York.
PMBOK, Guia (2004), Project Management Institute (PMI), Terceira Edição.
Pfleeger, S.L. and Atlee, J. M. (2005), Software Engineering: Theory and Practice, Prentice Hall, terceira edição.
CMMI (2006), “CMMI for Development, Version 1.2”, CMU/SEI-2006-TR-008. Software Engineering Institute.
Pressman, R. S. (2006), Engenharia de Software, McGraw-Hill, sexta edição.
Sommerville, I. (2007), Engenharia de Software, Oitava Edição, Pearson Addison-Wesley.
Pfleeger, Shari Lawrance. Engenharia de Software: teoria e prática, Segunda Edição, Prentice Hall, 2004.
[1] Um conjunto de fases do produto que não se sobrepõem, geralmente em ordem sequencial, cujos nomes e quantidades são determinados pelas necessidades de produção e controle da organização (PMBOK 2008).
[2] Disponível em http://www.agilemanifesto.org.
[3] Esta definição é a mesma utilizada pelo CMMI para definir processo (CMMI, 2006).
[4] IEEE é a maior associação profissional do mundo dedicada ao avanço da inovação tecnológica e excelência para o benefício da humanidade (IEEE 2010).
[5] O CMMI descreve as características de um processo de software e os critérios para um processo bem sucedido (CMMI 2006).
[6] Sistemas técnicos ou sociotécnicos dos quais as pessoas ou os negócios dependem. Se esses sistemas falharem ao desempenhar seus serviços conforme esperado, podem causar sérios problemas e prejuízos significativos (Sommerville, 2007 pág. 29).
[7] Framework pode ser definido sob dois aspectos: estrutura e função. Quanto à estrutura, um framework é a reutilização do design de parte ou totalidade de um sistema representado por classes abstratas e pela forma como instâncias destas classes interagem (Johnson 1997, pág. 39 – 42).
Bacharel em Ciência da Computação pela Universidade Federal de Alfenas. Desenvolvi durante a graduação pesquisas nas áreas de engenharia de software e processos de desenvolvimento de software. Tenho sólidos conhecimentos em processos de desenvolvimento de software (RUP e OpenUP), análise e coleta de requisitos, métodos ágeis de desenvolvimento (SCRUM e XP), programação utilizando as linguagens Java, C e SQL e modelagem de dados utilizando UML.
You must be logged in to post a comment.
