MODELOS DE PROCESSO TÉCNICAS INTELIGENTES QUE APOIAM A CONSTRUÇÃO DE UM SOFTWARE Ana Paula Carrion 1, Claudete Werner 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil anapaulacarrion@hotmail.com, claudete@unipar.br Resumo. Após a crise do software, a engenheira surgiu para otimizar o seguimento de desenvolvimento de software, onde, através de rotinas e técnicas inteligentes, o desenvolvedor consegue construir um produto computacional de qualidade que atende as expectativas do cliente, tanto em resultados para a área a ser informatizada, quanto em custos e prazos. O presente artigo trata de descrever três exemplos de modelos de processo, Desenvolvimento Orientado a Reuso, Modelo de Processo Ágil (Scrum) e Modelo de Processo Unificado, e fazer uma análise comparativa entre eles. 1. Introdução A Engenharia de Software é um rebento da engenharia de sistemas e de hardware. Ela abrange um conjunto de três elementos fundamentais métodos, ferramentas e procedimentos que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade produtivamente [PRESSMAN, 1995]. Com o passar dos anos, e após a crise do software que ocorreu na década de 70, houve a necessidade de adotar rotinas que permitissem ao desenvolvedor estabelecer e cumprir requisitos, metas e prazos. Estás técnicas são chamadas de modelos de processo, que consistem em técnicas inteligentes que permitem a produção de um produto computacional de qualidade. Um modelo de processo de software é uma representação abstrata de um processo de software. Cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informações parciais sobre o processo [SOMMERVILLE, 2003]. Desta forma, cada modelo de processo de software define a sequência com que as atividades serão executadas, quais as pessoas estão envolvidas e quais os artefatos são gerados por cada atividade. Embora não exista um modelo de software ideal, existem muitas oportunidades de trabalho para melhorá-lo, em muitas organizações [SOMMERVILLE, 2003]. Sendo assim, não existe regra para a escolha do modelo de processo a ser utilizado, as rotinas úteis devem ser incrementadas e incorporadas pela empresa de forma a atender às diferentes etapas do processo, sendo que, não existe apenas um tipo que possa ser utilizado, processos diferentes são utilizados para desenvolver diferentes partes do sistema. Neste artigo, após visualizarmos uma breve explicação sobre Engenharia de Software e Modelo de Processo, contemplaremos três exemplos de modelo de processo e uma análise entre eles. 2. Desenvolvimento Orientado a Reuso Na maioria dos projetos de software, ocorre algum reuso de software. Isso, em geral, acontece informalmente, quando as pessoas que trabalham no projeto conhecem projetos ou códigos similares àquele exigido. Eles recorrem a esses produtos, fazem as modificações conforme necessário e as incorporam em seus sistemas [SOMMERVILLE, 2003]. No modelo de processo
evolucionário, o reuso é visto freqüentemente como ferramenta essencial no desenvolvimento rápido de um sistema. Mesmo o modelo de reuso ter sido utilizado de maneira informal em um processo de desenvolvimento por muito tempo, seu grande número de usuários fomentou a necessidade de criar uma abordagem para o desenvolvimento a partir desta rotina, que conta com uma ampla base de componentes de software que podem ser acessados, e com alguma infra-estrutura de integração para esses componentes. Algumas vezes esses componentes são sistemas comerciais de prateleira (COTS), utilizados para funcionalidades específicas, como por exemplo, formatação de texto. Este tipo de modelo de processo se diferencia dos outros por possuir atividades específicas, embora o estágio inicial de especificação de requisitos e o estágio de validação sejam comparáveis com os de outros processos. Esses estágios são: - Análise de componentes: com base na especificação de requisitos, faz o levantamento e a análise dos componentes a serem utilizados; - Modificação de requisitos: após a análise dos requisitos, é feita uma comparação com os componentes disponíveis a serem utilizados, e suas adaptações. Se for impossível utilizar os componentes disponíveis, a análise de componentes pode ser refeita; - Projeto de sistema com reuso: nesta fase a infra-estrutura do sistema é projetada, podendo utilizar uma já existente, tendo em vista integrar componentes reutilizáveis e os softwares a serem desenvolvidos; - Desenvolvimento e integração: é o desenvolvimento do sistema e a integração com os componentes e os COTS. Neste tipo de modelo, o problema a ser enfrentado é o controle da evolução do software, pois o controle dos componentes reutilizáveis e dos COTS podem não ser de domínio da empresa que desenvolve o software. O modelo orientado a reuso tem a vantagem óbvia de reduzir a quantidade de software a ser desenvolvido e, assim, de reduzir custos e riscos. Geralmente, ele também propicia a entrega mais rápida do software. Contudo, as adequações nos requisitos são inevitáveis, e isso pode resultar em um sistema que não atenda às reais necessidades dos usuários [SOMMERVILLE, 2003]. 3. Modelo de Processo Ágil (SCRUM) O SCRUM é um modelo de desenvolvimento ágil de software que fornece métodos para se definir o planejamento, os principais papéis de pessoas e a forma de trabalho do time. O nome SCRUM é derivado de uma jogada de rúgbi, onde todo o time avança com apenas uma unidade, trabalhando com os mesmos jogadores e em conjunto, passando sempre a bola pra um e para outro. A idéia do SCRUM é justamente definir papéis bem específicos para as pessoas envolvidas no projeto e o que cada uma vai ter que fazer para o desenvolvimento do software, porém, ele não descreve o que fazer em cada situação, ele é usado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer. Como a metodologia deste modelo de processo define como o time deve trabalhar, o primeiro passo para o desenvolvimento por SCRUM é definir quem vai fazer o quê. Por isso chegamos a três principais definições dentro do projeto: o Proprietário do Produto (Product Owner), o ScrumMaster e o Time/Equipe. - ScrumMaster: é quem mantém os processos (normalmente no lugar de um gerente de projeto), fica mais em contato com o Proprietário do Produto, ele gerencia e repassa o trabalho que foi decidido durante o planejamento pelo Proprietário do Produto; - Proprietário do Produto (Product Owner): é quem representa os stakeholders e o negócio, ele tem que ser a interface entre o cliente e o time de desenvolvedores, ou seja, estar sempre em contato com o cliente e saber exatamente o que o projeto tem que ser;
- Equipe (Team): é o grupo multifuncional com cerca de sete pessoas, que fazem a análise, o projeto, a implementação, os testes, etc. Em geral e resumidamente, esta metodologia pode ser descrita da seguinte forma: primeiro é preciso definir o Produto. Defini-se quais são os seus requisitos, o que realmente o cliente quer. E o responsável por esta tarefa é o que chamamos de Proprietário do Produto (Product Owner). Depois o Proprietário do Produto define quais são as funcionalidades do programa que mais importam, assim cria-se o que chamado Product Backlog. Com as prioridades estabelecidas, defini-se uma pessoa para ser o ScrumMaster, que tem trabalho semelhante ao coordenador de projetos. O ScrumMaster, junto com o Proprietário do Produto e o Time de desenvolvimento definem o que chamamos de Sprints. Cada Sprint possui uma parte de todo o Product Backlog, devem ser trabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprints devem ser preparados de forma que durem de 2 a 4 semanas e ao no final de cada período tenham um produto apresentável para o cliente. Para finalizar, os Sprints vão sendo feitos até o Product Backlog acabar e o Proprietário do Produto definir que o projeto está pronto. Mas isso não quer dizer que novas funcionalidades não podem ser incluídas durante o processo, basta ir adicionando no Product Backlog e realizando outros Sprints. O modelo de processo SCRUM se dá por três etapas: o início, marcado pela reunião de planejamento, o ciclo de desenvolvimento (chamado Sprint) e a conclusão, marcada pela reunião de revisão do Sprint. Os artefatos SCRUM são as ferramentas básicas para se trabalhar com este modelo de desenvolvimento. Estes artefatos servem como guias e indicadores durante o processo. São divididos em três: Product Backlog, Sprint Backlog e Burndown Chart. Durante os passos reais de desenvolvimento, os Sprints, a principal ferramenta de medição de desempenho é o Burndown Chart, que é uma das características mais especiais do SCRUM. É um gráfico que mostra a quantidade de trabalho cumulativo restante de um Sprint e indica a quantidade de tarefas do Sprint Backlog não completadas, sendo que o cumprimento deve ser medido dia a dia. Porém, a informalidade do projeto e a falta de planejamento do escopo podem se tornar características que atrapalhem no cumprimento das metas dentro deste modelo. 4. Modelo de Processo Unificado O modelo de processo unificado se baseia em um conjunto de técnicas e rotinas necessárias para transformar requisitos do usuário em um sistema de software, surgiu para realizar o desenvolvimento visando à construção de sistemas orientados a objetos. Este modelo de processo também pode ser definido como um processo de engenharia de software bem definido e bem estruturado, que desenha de forma clara e precisa quem é responsável, como e quando será feito, e ainda de maneira flexível, sendo que cada projeto pode ser modelado de acordo com suas necessidades. Os aspectos que norteiam o processo unificado são divididos em três conceitos chave: - Dirigido por casos de uso: uma série de fluxos de trabalho derivados dos casos de uso; - Centrado na arquitetura: casos de uso são baseados em uma arquitetura global, definida nas fases iniciais; - Iterativo: repetição de etapas similares; - Incremental: as iterações acrescentam novas funções ao produto. O modelo de processo unificado é baseado em componentes, o que significa que o sistema deve ser construído a partir de componentes de software interconectados via interfaces muito bem definidas, e utiliza-se da Linguagem de Modelagem Unificada (UML) no preparo de todos os artefatos do sistema. Este modelo de processo trabalha com os princípios largamente utilizados no desenvolvimento de software desde o seu surgimento até os dias presentes. Neste processo, não se prega que devemos fazer tudo exatamente como está no papel, e sim que devemos seguir as boas práticas de desenvolvimento de software, deste modo, ele se propõe a ser um guia que ajuda na construção de software de qualidade. O processo é iterativo e incremental, que utiliza
marcos que nos ajudam a nos situarmos no projeto e ver se este tem condições de continuar em termos de riscos e objetivos. O modelo de processo unificado é composto por cinco elementos principais: papéis, atividades, artefatos, fluxos de trabalho e disciplinas, que englobam etapas comuns a outros tipos de modelo de processo, e caracterizam-se pela divisão clara das suas funções (figura 1). Figura 1: Fases e disciplinas do modelo (Fonte: http://www.devmedia.com.br/artigo-engenhariade-software-o-processo-unificado-integrado-ao-desenvolvimento-web/8032/ Acesso em: 28/04/2012). O modelo de processo unificado é um método evolucionário de desenvolvimento de software, sendo assim, a vantagem deste método está em o usuário não esperar até a conclusão do projeto para ter contato com o software. Em contrapartida podem ocorrer divergências entre a documentação e o software, o que ocasiona erros na execução do sistema, a exigência frequente da implantação de novas funcionalidades pelo cliente, o que leva ao aumento dos gastos e dos prazos a serem cumprido, e até mesmo, a não conclusão do software. 5. Análise Após análise dos modelos de processo apresentados, concluí-se que apesar de três modelos de processo totalmente distintos, todos possuem algumas etapas de desenvolvimento em comum, norteiam-se no levantamento e análise de requisitos, modelam o trabalho, definem o processo de desenvolvimento e permitem a participação do cliente para feedback e conclusão do sistema. Porém, o modelo de reuso se concentra no desenvolvimento rápido de sistemas, caracterizado pela reutilização de componentes já existentes que possuem a mesma característica do sistema a ser desenvolvido. Já o modelo de processo ágil, baseia-se na divisão do processo de trabalho que permite a construção do sistema por partes, e foca na qualidade do produto. E por fim, o modelo de processo unificado tem como principal vantagem a estruturação clara do projeto de planejamento, definindo o que acontece, como acontece e quem deve realizar o que em cada etapa, destacando também a flexibilidade que pode ser empregada em cada projeto, analisando individualmente o seu planejamento. Dentre os três modelos de processos apresentados, o que mais me chamou a atenção foi o método ágil. Além de ser um modelo que está evidenciado na área de tecnologia, sua execução por etapas chama a atenção, pois faz com que toda a equipe fique focada na construção do mesmo bloco de atividades, o que proporciona a diminuição do número de erros. Destaco também a flexibilidade do dia a dia dentro dos Sprints, que permite uma avaliação constante da produção e das metas a serem cumpridas.
6. Metodologia Este artigo procurou através de revisão bibliográfica ilustrar três diferentes tipos de modelos de processo, delineando bem suas características e as metodologias de trabalho que podem beneficiar o usuário. 7. Conclusão Com o conteúdo apresentado, pode-se concluir que a engenharia de software tornou-se fundamental para a construção de sistemas computacionais de qualidade, pois suas técnicas norteiam todo o trabalho, proporcionam o apoio necessário para levantamento de dados, desenvolvimento, cumprimento de metas e resolução de problemas. Os modelos de processo vêm unir-se ao dia a dia do profissional, implantando rotinas que se adéquam flexivelmente às necessidades de cada desenvolvedor e softwares a serem desenvolvidos. A escolha de um modelo deve ser feita a partir dos resultados que se quer obter porém, o mais importante após a escolha do modelo de processo, é seguir este modelo e se beneficiar com os resultados que ele pode proporcionar. Nada impede que um modelo seja adaptado à novas necessidades, ou que mais de um modelo seja utilizado para um projeto, para tanto, é preciso conhecer as suas metodologias e empregá-las de maneira correta, para que assim o trabalho seja desenvolvido com êxito. Referências Artigo da Revista Engenharia de Software. http://www.devmedia.com.br/artigo-engenharia-desoftware-o-processo-unificado-integrado-ao-desenvolvimento-web/8032. Acessado em: 28/04/2012. Artigo Engenharia de Software - O processo unificado integrado ao desenvolvimento Web. Gerenciamento de Projetos Scrum com o IBM Rational Team Concert. Millard Ellingsworth, Thomas Starz. http://www.ibm.com/developerworks/br/rational/library/09/scrumprojectmanagementteamconce rt-1/index.html. Modelo de Desenvolvimento Ágil SCRUM. Hugo Cisneiros. http://www.devin.com.br/modeloscrum/. Modelos de Processos de Engenharia de Software. Rafael O. Lessa, Edson O. Lessa Junior. xpsproject.googlecode.com/svn-history/r43/trunk/.../02_artigo.pdf. Modelos de Processo de Software. Antonio Arias Silva Oliveira. http://www.arias.eti.br/publico/artigo_modeloprocessosoftware.pdf. O Processo unificado de desenvolvimento de Software. Vidal Martins. http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1227. Acesso em: 28/04/2012. Pressman, Roger S. Engenharia de Software. São Paulo: Makron Books, 1995. Pressman, Roger S. Engenharia de Software. 6. Ed. São Paulo: McGraw-Hill, 2006. Sommerville, Ian. Engenharia de Software. 6. Ed. São Paulo: Addison-Wesley, 2003. Uma Abordagem sobre Processos de Software. Heitor Silva Temp, Luciano Estanislau Sturza. http://pt.scribd.com/doc/28905719/artigo-uma-abordagem-sobre-processos-de-software.