Modelos de Processo de Software

Antonio Arias Silva Oliveira1

1

Departamento de Informtica Universidade Federal do Par (UFPA) Rua Augusto Corra, 01 66.075-110 Belm PA Brazil
{arias,antonio.arias}@globo.com

Abstract. We will show the parade of presentations done by several teams of the Piracy of Specialization in it Manages of Projects of Software, in the discipline "Model of Process of Software", supplied by the teacher and master Paulo Bastos. They were 10 models presented by the teams among the days 19/04 to 24/05/2007 in the Federal University of Par. It was a singular experience, to see those works cousins of the Engineering of Software to be shown and discussed for about 36 students, giving their opinions, asking what nobody had asked. The lesson was reviewed masterfully. We don't know which is the best, but now we are great aware in the transport and orientation of a development team, our role as Managers of Projects of Software. Resumo. Vamos mostrar o desfile de apresentaes feito por vrias equipes do Corso de Especializao em Gerencia de Projetos de Software, na disciplina Modelo de Processo de Software, ministrada pelo professor e mestre Paulo Bastos. Foram 10 modelos apresentados pelas equipes entre os dias 19/04 a 24/05/2007 na Universidade Federal do Par. Foi uma experincia singular, ver essas obras primas da Engenharia de Software ser mostradas e discutidas por cerca de 36 alunos, dando suas opinies, perguntando o que ningum havia perguntado. A lio foi magistralmente repassada. No sabemos qual o melhor, mas agora temos grande conscincia na conduo e orientao de uma equipe de desenvolvimento, nosso papel como Gerentes de Projetos de Software.

1. Introduo
Podemos dizer com uma grande dose de certeza que Modelos de Projeto de Software o veculo que conduz qualquer projeto de software rumo ao sucesso e qualidade. Bom, mas qualidade algo abstrato, difcil de ser definido. Portanto vamos recorrer a um pouco de histria da qualidade para podermos entender melhor esse conceito. A histria da qualidade est repleta de exemplos de resultados extraordinrios: os grandes templos construdos na Grcia e Roma antigas, os feitos de navegao do sculo XVI, as catedrais medievais. Em todas essas realizaes, no se dispunha de instrumentos de preciso ou tcnicas sofisticadas. Na Frana, os construtores de catedrais utilizavam simples compassos e cordas com ns a intervalos regulares para desenhar e construir edifcios [Koscianski 2006]. Na dcada de 1920 surgiu o controle estatstico de produo. Nas fbricas que produziam grande quantidade de itens tornou-se impossvel garantir a qualidade individual de cada pea, ao contrrio do que se fazia (e ainda faz) no trabalho artezanal.

Dessa forma foi preciso desenvolver mecanismos diferentes e a resposta veio da estatstica. Um dos pioneiros trabalhos associados ao assunto o livro publicado por Walter Shewhart em 1931, Economic Control of Quality of Manufactured Producto. Shewhart, dos Bell Laboratories, teria introduzido os diagramas de controle (control charts ou Shewhart chart). [Koscianski - 2006]. Na dcada de 1940 foi fundado a ABNT (Associao Brasileira de Normas Tcnicas) e a ISO (International Standardization Organization). Tambm o Japo destacou-se como um importante plo no assunto e contribuiu com diversas novas ferramentas: o mtodo de Taguchi para projeto experimental, a metodologia 5S ou, ainda, os diagramas de causa e efeito de Ishikawa, tambm conhecidos como diagrama espinha de peixe. [Koscianski - 2006] Estas citaes nos mostram claramente que a qualidade de um programa de computador segue as mesmas especificaes de um produto qualquer da indstria tradicional.

2. Os Modelos de Desenvolvimento
Vamos ento nos focar nos modelos, como eles surgiram e evoluiro. Nas dcadas 1960 e 1970 ocorreram mudanas tecnolgicas importantes que afetaram a construo dos computadores e, em conseqncia, a de software. O perodo conhecido como crise de software e as repercusses so sentidas at hoje [Pressman, 2002]. A maior causa da crise de software que as mquinas tornaram-se vrias ordens de magnitude mais potentes! Em termos diretos, enquanto no havia mquinas, programar no era um problema; quando tivemos computadores fracos isso se tornou um problema pequeno e agora que temos computadores gigantescos, programar tornouse um problema gigantesco. [Koscianski, 2006]

2.01. Modelo em Cascata

No dia 19 de abril de 2007, na disciplina modelos de processos de software, do curso de Especializao em Gerencia de Projetos de Software, foi dado inicio a um desfile de apresentaes, feitas pelos alunos. O primeiro o Modelo em Cascata. Dos modelos prescritivos, o cascata , sem dvidas, o mais referenciados e discutidos em estudos e trabalhos acadmicos e aplicaes. Quando os requisitos de um problema so razoavelmente bem compreendidos, o trabalho flui da comunicao de um modo razoavelmente linear, recomenda-se o cascata. O modelo em cascata o paradigma mais antigo da engenharia de software, entretanto nas ltimas dcadas esse modelo tem sofrido muitos questionamentos. Talvez por essa razo ele seja o modelo mais evidente. Podemos citar trs problemas em que o cascata aplicado: 1) Projetos reais raramente seguem fluxos seqenciais que o modelo prope. Apesar de o modelo linear poder acomodar iteraes, ele o faz indiretamente. Como resultado, as modificaes podem causar confuso medida que a equipe de projeto prossegue.

2) Em geral, difcil para o Cliente estabelecer todos os requisitos explicitamente. O modelo em cascata exige isso e tem dificuldade de acomodar a incerteza natural que existe no comeo de muitos projetos. 3) O Cliente precisa ter pacincia. Uma verso executvel do(s) programa(s) no vai ficar disponvel at o perodo final do intervalo de tempo do projeto. Um erro grosseiro pode ser desastroso se no for detectado at que o programa executvel seja revisto. [Pressman, 2005] 2.02. Modelo de Desenvolvimento Evolucionrio
Este modelo busca o desenvolvimento de software evoluindo a partir de prottipo inicial. Todos os conceitos e idias vo sendo materializado em requisitos a medida que o prottipo evolui, at atingir o produto idealizado. O objetivo trabalhar com o Cliente em toda a fase do desenvolvimento, a partir das especificaes iniciais. Entretanto os requisitos devem ser bem compreendidos. O modelo evolucionrio pode trazer diversas vantagens, tais como antecipar o produto final para avaliao do Cliente, manter uma comunicao entre os desenvolvedores e usurios para solucionar problemas tcnicos e antecipar o treinamento dos usurios.

2.03. Modelo de Desenvolvimento Rpido (RAD)

Aqui o objetivo principal a velocidade do desenvolvimento. O termo Rapid Application Development (RAD) se aplica a projetos que tem prazos curtos e que geralmente usa prototipagem e ferramentas de desenvolvimento de alto nvel. A

orientao a construo de componentes e que os requisitos e o escopo sejam bem conhecidos por diferentes equipes, conforme figura 1.

Figura 1 Modelo de processo RAD Modelagem do Negcio: O fluxo de informao entre os mdulos de funo d negcio so modeladas para que possa responder: Qual a informao que dirige o processo do negcio? Qual a informao gerada? Quem processa? Quem gera a informao? Para onde vai a informao?

Modelagem dos dados: O fluxo definido na modelagem do negcio refinado em um conjunto de objetos de dados necessrios para dar suporte ao negcio; Aqui so identificadas as caractersticas e seus relacionamentos para cada objeto. Modelagem do Processo: Os objetos de dados so transformados para obter uma funo de negcio. Gerao da Aplicao: De posse dos componentes a aplicao gerada. So utilizados ferramentas automatizadas tal como o GeneXus.

2.04. Modelo Formal

Este modelo requer Clientes tecnicamente bem preparados, engenheiros de software com conhecimento profundo do negcio em questo. E as especificaes devem ser bem consistentes, claras sem qualquer ambigidade. Utiliza fortemente os modelos matemticos nas especificaes. Portanto recomendado para aplicao extremamente crtica

Os mtodos formais tm um potencial tremendo para melhorar a clareza e a preciso da especificao dos requisitos e de encontrar erros importantes e sutis. O mtodo formal tem uma slida base matemtica, dada tipicamente por uma linguagem formal de especificao. Essa base fornece um meio para definir precisamente noes como consistncia e completeza, e mais relevantemente, especificao, implementao e correo.

2.05. Modelo de Desenvolvimento Orientado a Reuso

A reutilizao sempre foi utilizada por outras engenharias. Apenas nos ltimos anos que a engenharia de software comeou adotar o reuso como uma abordagem prtica no desenvolvimento de software. A reutilizao o processo de incorporar em um novo produto: Cdigo; Plano de Teste; Conhecimento Geral; Especificaes de requisitos e projetos.

2.06. Modelo de Desenvolvimento Incremental

O modelo incremental combina diversos elementos do Modelo em Cascata, dividindo os requisitos em incrementos, de maneira a garantir um melhor entendimento e uma maior participao do Cliente. Usa bem o conhecimento adquirido em projetos anteriores. um modelo que objetiva minimizar os riscos do projeto, dando maior importncia aos requisitos mais importantes. Veja figura 2.

Figura 2 Modelo de processo Incremental

Podemos dizer que este modelo de fcil gerenciamento. Possibilita o aumento da qualidade do software, facilitando a integrao e reduzindo as falhas. E o projeto pode ser tocado com pouca mo-de-obra. Entretanto trata-se de um modelo, cujo software desenvolvido de difcil modularizao. Tambm no permite alteraes nos requisitos durante os incrementos.

2.07. Modelo de Desenvolvimento em Espiral

Este modelo surgiu com o objetivo de resolver os seguintes problemas: Os projetos raramente seguem o fluxo seqencial que o modelo Cascata prope No incio do projeto difcil para o cliente especificar os requisitos explicitamente Na Prototipagem o cliente v o que parece ser uma verso executvel do software, ignorando que o prottipo apenas consegue funcionar precariamente.

Para tanto esperado que os requisitos bsicos estejam bem entendidos, muito embora os detalhes ainda precisem ser definidos. O produto evoluir com o tempo, gerando verses cada vez mais completas.

2.08. Modelo do Processo Unificado

O RUP uma abordagem de desenvolvimento de software de forma iterativa, baseada na arquitetura e dirigida por casos de uso, que so levantamentos de requisitos baseados na viso do usurio. Tambm pode ser definido como um processo de engenharia de software bem definido e bem estruturado. Definindo de forma clara e precisa quem responsvel, como e quando ser feito. composto por cinco elementos principais: papis, atividades, artefatos, fluxos de trabalho e disciplinas, conforme figura 3.

Figura 3 Fases e disciplinas do modelo RUP

Aps atingir o consenso dos envolvidos, dentro da fase conhecida como concepo, inicia-se a meta dominante. O objetivo da fase concepo estabelecer o escopo do sistema, fazer um esboo da arquitetura, identificar os riscos, estimar tempo/custo e a viabilidade do sistema. E na seqncia as atividades bsicas, com o planejamento e preparao do caso de negcio, formular o escopo, sintetizar a arquitetura e preparar o ambiente.

Depois as fases de Elaborao, Construo e Transio, onde o software j pode ser disponibilizado para o usurio final.

2.09. Modelo Paxis

Este modelo tem o foco principal no processo educacional da engenharia de software. Orientado a objetos e baseado em paradigmas de grande difuso: UML, SWCMM, UP e IEEE. Pode ser bem adaptado a uso individual ou para pequenas equipes. Indicado para organizaes em vias de melhoria de processos. Segue fortemente o Processo Unificado e as fases so compostas por uma ou mais iteraes. Os fluxos so divididos em uma ou mais atividades, sendo essas iteraes e atividades exemplos de passos. As fases so: Concepo, Elaborao, Construo e Transio. E os fluxos tcnicos so: Requisitos, Anlise, Desenho, Implementao, Testes e Engenharia de Sistemas. E os fluxos gerenciais so: Gesto de Projetos, Gesto de Qualidade e Engenharia de Processos.

2.10. XP (eXtreme Programming)

Quando Kent Beck e outros 16 notveis desenvolvedores, produtores e consultores, em 2001, assinaram o Manifesto Agil, estavam buscando valorizar: Indivduos e interaes em vez de processos e ferramentas. Software funcionando em vez de documentao abrangente Colaborao do cliente em vez de negociao de contratos Resposta a modificaes em vez de seguir plano

Data a dificuldade de predizer quais requisitos sero mantidos e quais vo mudar, bem como quais prioridades mudaro. Da mesma forma muito difcil precisar quando um projeto estar pronto para comear. Assim projeto e implementao so feitos juntos. O eXtreme Programming busca melhorar a comunicao entre o Cliente e a Equipe de desenvolvimento e entre a prpria Equipe. o olho - no - olho. Simplicidade para fazer o necessrio e respeito ao ser humano. Baseado em princpios e nas prticas para trabalhar lado a lado, Equipe e Cliente. Decidindo fazer o que realmente importante fazer em reunies, normalmente em p, dando assim maior agilidade as decises. [Astels 2002] O XP normalmente recomendado para projetos sujeitos a mudanas, com equipes pequenas e Clientes com domnio do negcio.

3. Concluso
Com este desfile de modelos possvel compreender que toda a dificuldade de se construir software pode, com simples adoo de um ou mais modelos, assegurar grande controle da situao do processo de software. Como em outras engenharias, os processos so bem definidos e normalizados para que perdure por todo o ciclo de desenvolvimento do produto. E caso aja possvel melhoria a ser feita no modelo, providenciado para uma prxima instancia do referido modelo. Na engenharia de software tambm deve ser assim. E mesmo com as dificuldades naturais de se fazer algo pouco tangvel, devemos buscar adequar um modelo a ser seguido. Qual deles? Isso importante mas, nem tanto. O mais importante adotar um e segui-lo o mais fielmente possvel para que os benefcios possam ser colhidos. Deve ser dado tempo suficiente para as tarefas advindas dos modelos, preencher os documentos preparar os artefatos, seguir o script risca. As adaptaes so necessrias e devem ser feitas mas, sem reinventar a roda, se ela j est disponvel use-a.

4. References
Astels, David; Granville Miller e Miroslov Novak, eXtreme Programming Guia Prtico, 2002 Koscianski, Andr. Qualidade de software, 2006