UNIVERSIDADE FEDERAL DO ESPRITO SANTO DEPARTAMENTO DE INFORMTICA MESTRADO EM INFORMTICA

BRUNO CARREIRA COUTINHO SILVA

PROCESSOS E FERRAMENTAS PARA O DESENVOLVIMENTO DE SOFTWARE LIVRE: UM ESTUDO DE CASO

VITRIA 2006

BRUNO CARREIRA COUTINHO SILVA

PROCESSOS E FERRAMENTAS PARA O DESENVOLVIMENTO DE SOFTWARE LIVRE: UM ESTUDO DE CASO

Dissertao apresentada ao Programa de Mestrado em Informtica da Universidade Federal do Esprito Santo, como requisito parcial para obteno do Grau de Mestre em Informtica. Orientador: Prof. Dr. Ricardo de Almeida Falbo.

VITRIA 2006

BRUNO CARREIRA COUTINHO SILVA

PROCESSOS E FERRAMENTAS PARA O DESENVOLVIMENTO DE SOFTWARE LIVRE: UM ESTUDO DE CASO

COMISSO EXAMINADORA

______________________________________ Prof. Dr. Ricardo de Almeida Falbo, D. Sc. Orientador

_________________________________________ Prof. Dr. Srgio Antnio Andrade de Freitas, D.Sc. Universidade Federal do Esprito Santo

_________________________________________ Carlos Alberto Marques Pietrobon, D.Sc. Pontifcia Universidade Catlica de Minas Gerais

Vitria, 03 de outubro de 2006.

ii

RESUMO

O movimento de Software Livre tem ganhado cada vez mais espao e importncia nos segmentos da comunidade de software (governo, academia, indstria etc), tanto em mbito mundial quanto nacional, contando atualmente com a existncia de diversos projetos dessa classe em andamento. Esse tipo de software no traz consigo somente inovaes na forma de se desenvolver software, mas tambm proporciona comunidade uma nova filosofia, afetando muitos dos atuais princpios da indstria de software. Apesar de seu notrio crescimento, na maioria das vezes, seu desenvolvimento no tem sido realizado segundo as melhores prticas da Engenharia de Software, incluindo nesse cenrio a no utilizao de processos de software bem definidos. A elaborao desses processos pode ser facilitada se assistida por normas e modelos de qualidade de processo de software adequados. A aplicao dos processos definidos a uma organizao se torna mais vivel se auxiliados por um bom ambiente de apoio ao desenvolvimento de software. No caso do desenvolvimento de Software Livre, esse ambiente deve ser composto por ferramentas preferencialmente disponveis pela Internet, dada a disperso geogrfica dos colaboradores participantes de projetos desse tipo. Este trabalho tem por objetivo definir uma infra-estrutura para apoiar o desenvolvimento de software livre a ser aplicada ao Projeto ODE (Ontology-based software Development Environment), dando origem ao Projeto ODE Livre. O Projeto ODE visa ao desenvolvimento de um Ambiente de Desenvolvimento de Software Centrado em Processos e o principal projeto em andamento no Laboratrio de Engenharia de Software (LabES) da Universidade Federal do Esprito Santo. A infra-estrutura proposta inclui processos padro para software livre, bem como a definio de requisitos para a construo de um ambiente de apoio aos processos elaborados o Portal ODE Livre.

Palavras-chave: Software Livre, Qualidade de Software, Ambiente de Desenvolvimento de Software e Ferramentas CASE.

iii

ABSTRACT

Free Software is more and more earning space in software market. Nowadays, there are several projects of this kind in progress around the world. This new software

development model brings along a new philosophy, affecting many of the software industry principles. Despite of its importance and growth, in most cases, free software development is not being done according to the best practices of Software Engineering. In this scenario, many times software processes are not formally defined. This paper discusses an effort for defining a standard process for free software projects at LabES/UFES. The initial goal of defining these processes is to apply it in ODEs Project, a project that aims to develop a software engineering environment as a free software The goal of this work is to define an infrastructure to support free software projects at LabES/UFES, which includes standard software processes for open source software projects, as well as the definition of requirements for the development of an environment that is able to support the processes defined. This infrastructure is to be applied to ODE Project, a project that aims to develop the software engineering environment ODE (Ontology-based software Development Environment) as a free software, giving rise to the Free ODE Project. ODE Project aims to develop a Process Centered Software Development Environment and it is the main project in progress in the Software Engineering Laboratory of the Federal University of Esprito Santo (LabES/UFES).

Key words: Free Source, Software Quality, Software Development Environment and CASE Tools.

iv

LISTA DE FIGURAS Figura 2.1 Modelo para Definio de Processos em Nveis................................... Figura 2.2 Estrutura da ISO/IEC 12207 (Emendas 1 e 2)...................................... Figura 2.3 Processos do Exemplo de Modelo de Avaliao de Processos da ISO/IEC 15504....................................................................................... Figura 2.4 Componentes do Modelo CMMI.......................................................... Figura 2.5 Processos do MPS.BR.......................................................................... Figura 2.6 Estrutura do Processo Padro para Equipes Distribudas..................... Figura 4.1 Definio de Processos em Nveis e o Projeto ODE Livre................... Figura 4.2 Estrutura Original dos Processos Padro do LabES............................. Figura 4.3 Estrutura Bsica dos Processos Padro do LabES Atualizada.............. Figura 4.4 Detalhamento da atividade Definir Processo de Projeto do Processo de Gerncia de Projetos do Processo Padro LabES............................... Figura 4.5 Detalhamento da atividade Definir Processo de Projeto do Processo de Gerncia de Projetos do Processo Padro LabES para Software Livre......................................................................................................... Figura 5.1 Formulrio de Defeitos do Bugzilla...................................................... Figura 5.2 Tela inicial do Controle de Consulta do Bonsai.................................... Figura 5.3 Tela principal do Tinderbox.................................................................. Figura 5.4 Exemplo de pgina gerada pelo LXR.................................................... Figura 5.5 Pgina inicial do Wiki-Mozilla.............................................................. Figura 5.6 Tela principal de um Frum Apache..................................................... Figura 5.7 Exemplo de utilizao do Difftool do BitKeeper.................................. Figura 5.8 Tipos de Usurios.................................................................................. Figura 5.9 Diagrama de Pacotes do Portal ODE Livre........................................... Figura 5.10 Diagrama de Casos de Uso do subsistema de Controle de Usurios... Figura 5.11 Diagrama de Casos de Uso do subsistema de Controle de Contribuies........................................................................................ 79 62 67 69 70 71 71 73 74 76 77 78 56 18 21 24 33 53 54 55 08 12

LISTA DE TABELAS

Tabela 2.1 Nveis de Maturidade e reas de Processos do CMMI-SE/SW........... Tabela 2.2 Nveis de Maturidade e Processos do MPS.BR.................................... Tabela 2.3 Relao entre MPS.BR e CMMI...........................................................

22 25 28

vi

SUMRIO

Captulo 1 Introduo ......................................................................................... 1.1 Contexto e Motivao................................................................................. 1.2 Objetivos..................................................................................................... 1.3 Metodologia................................................................................................ 1.4 Organizao do Trabalho............................................................................

01 02 02 04 05

Captulo 2 Processo de Software......................................................................... 2.1 O que Processo de Software...................................................................... 2.2 Nveis de Processo de Software................................................................... 2.3 Qualidade de Processo de Software............................................................. 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 ISO 9000:2000...................................................................................... ISO/IEC 12207..................................................................................... ISO/IEC 15504..................................................................................... CMMI................................................................................................... MPS.BR................................................................................................ IEEE 1219-1998...................................................................................

06 07 07 09 09 11 15 19 22 28 30 33

2.4 Processo Padro para Equipes Geograficamente Dispersas......................... 2.5 Consideraes Finais do Captulo................................................................

Captulo 3 Software Livre...................................................................................... 3.1 O que Software Livre................................................................................... 3.2 Licenciamento................................................................................................. 3.3 Caractersticas de Desenvolvimento de Software Livre................................. 3.4 Projetos de Software Livre.............................................................................. 3.4.1 3.4.2 3.4.3 O Projeto Linux........................................................................................ O Projeto Mozilla..................................................................................... O Projeto Apache.....................................................................................

35 36 37 39 42 43 43 44 45

3.5 Concluses do Captulo...............................................................................

vii

Captulo 4 Processos Padro para Software Livre....................................... 4.1 4.2 4.3 4.4 4.5 4.6 4.7 Ambientes de Desenvolvimento de Software......................................... O Projeto ODE........................................................................................ Em Direo a ODE Livre........................................................................ Processos Padro do LabES..................................................................... Processos Padro para Projetos de Software Livre.................................. Licena para Disponibilizao de ODE como Software Livre................ Consideraes Finais do Captulo............................................................

46 47 49 51 54 57 62 63

Captulo 5 Requisitos de um Ambiente de Apoio ao Projeto ODE Livre.........

64

5.1 Caractersticas de Ambientes de Apoio ao Desenvolvimento de Software Livre 65 5.1.1 5.1.2 5.1.3 O Projeto Mozilla................................................................................... O Projeto Apache................................................................................... O Projeto Linux...................................................................................... 65 73 74 75 75 80 82 83

5.2 Requisitos de um Ambiente de Apoio ao Projeto ODE Livre....................... 5.2.1 5.2.2 5.2.3 Requisitos Funcionais Iniciais para o Portal ODE Livre....................... Outros Requisitos Gerais Desejados para o Portal ODE Livre............. Utilizando ODE no Projeto ODE Livre.................................................

5.3 Consideraes Finais do Captulo..................................................................

Captulo 6 Consideraes Finais......................................................................... 6.1 Concluses................................................................................................... 6.2 Perspectivas Futuras.....................................................................................

84 84 86

Referncias Bibliogrficas ......................................................................................

88

viii

Captulo 1 Introduo
O modelo de Software Livre (SL) tem despertado interesse e suscitado reflexes nos mais diversos segmentos da comunidade de software (governo, academia, indstria etc) no Brasil e no exterior. O surgimento de uma rede virtual de desenvolvedores e usurios, complexa, auto-organizada, com motivaes diversas e a existncia de novas formas de licenciamento de software sinalizam a introduo de novas variveis no setor de software (SOFTEX, 2005a). A recente pesquisa realizada pelo Observatrio Econmico da Softex e o Departamento de Poltica Cientfica e Tecnolgica da UNICAMP, com o apoio do Ministrio de Cincia e Tecnologia, indica que, apesar de no se tratar de uma ruptura tecnolgica, o modelo de SL traz uma nova forma de desenvolver e licenciar software que est quebrando modelos tradicionais de apropriabilidade e de desenvolvimento tecnolgico (SOFTEX, 2005a). H, atualmente, um grande nmero de projetos de SL em desenvolvimento e este nmero crescente (SOURCEFORGE, 2006). Dentre os projetos existentes, alguns possuem qualidade considervel. Porm, tal qualidade, muitas vezes, no obtida atravs da utilizao das melhores prticas de engenharia de software. amplamente reconhecido que a qualidade dos produtos de software depende da qualidade dos processos de software utilizados em seu desenvolvimento e manuteno, e h diversas normas e modelos de qualidade, reconhecidos internacionalmente, tratando da questo da qualidade do processo de software. Seguindo essa tendncia de busca da qualidade do produto pelo uso de processos de software de qualidade, este trabalho procura explorar o tema qualidade de software livre por meio da definio de processos para projetos de software livre.

1.1 Contexto e Motivao

O Laboratrio de Engenharia de Software (LabES) da Universidade Federal do Esprito Santo (UFES) um laboratrio de pesquisa e ensino em Engenharia de Software que preza pela busca da qualidade em seus processos de desenvolvimento com vistas qualidade de seus produtos. Dentre os projetos em desenvolvimento no LabES, destaca-se o Projeto ODE (FALBO et al., 2003), que visa ao desenvolvimento de um Ambiente de Desenvolvimento de Software (ADS) Centrado em Processo. ODE o resultado do esforo conjunto de diversos alunos de graduao e mestrado pertencentes ao LabES e possui ferramentas importantes para apoiar diversas atividades do processo de software. Dado seu estado atual e, principalmente, motivado por sua origem acadmica, uma evoluo natural para o Projeto ODE a sua disponibilizao comunidade de software como software livre (SL), permitindo, assim, que essa comunidade possa desfrutar de um ADS livre. importante frisar que a disponibilizao de ODE para a comunidade ser feita sob uma ou mais licenas de software, visando proteger o trabalho j realizado e possibilitar sua evoluo. Apesar de existirem projetos de software livre relatados na literatura que adotam processos utilizando boas prticas de engenharia de software e buscando a qualidade de seus produtos (REIS, 2003), o fato de no se ter encontrado nenhum projeto de SL que seguisse um processo de software baseado em normas e modelos de qualidade foi uma das principais motivaes para este trabalho.

1.2 Objetivos

Este trabalho aborda a temtica qualidade de software no desenvolvimento de software livre, tendo como objeto de estudo o Ambiente de Desenvolvimento de Software ODE, a ser disponibilizado como software livre. De modo geral, o objetivo deste trabalho o estabelecimento de processos de software padro para o Projeto ODE Livre, tomando por base caractersticas de software livre e normas e modelos de qualidade reconhecidos, e a definio de requisitos para um arcabouo de ferramentas

livres de apoio aos processos definidos. A seguir, esse objetivo descrito com mais detalhes na forma de sub-objetivos: Definir um processo padro de desenvolvimento para o Laboratrio de Engenharia de Software (LabES) a ser aplicado no desenvolvimento de software livre, em especial no Projeto ODE Livre. Esse processo deve ser estabelecido com base em normas e modelos de qualidade de processo, sobretudo ISO/IEC 12207 e MPS.BR. Definir um processo padro de manuteno para o Laboratrio de Engenharia de Software (LabES) a ser aplicado na manuteno de software livre, mais especialmente no Projeto ODE Livre. Assim como o processo padro para desenvolvimento de software livre, esse processo deve ser estabelecido com base em normas e modelos de qualidade de processo, com destaque para a norma IEEE 1219. Adaptar outros processos padro (de apoio e organizacionais) para o desenvolvimento e manuteno de software livre, a serem aplicados no Projeto ODE Livre. Esses processos padro devem ser estabelecidos com base em normas e modelos de qualidade de processo, sobretudo ISO/IEC 12207 e MPS.BR. Os processos definidos devem levar em conta, tambm, projetos de software livre de sucesso, buscando identificar as melhores prticas adotadas nesses projetos. Tanto os produtos resultantes dos processos quanto as ferramentas de apoio s atividades, bem como os processos em si, devem ser livres, de modo a se poder contar posteriormente com a colaborao de pesquisadores de outras universidades e de centros de pesquisa, bem como de profissionais interessados no Projeto ODE Livre. Estabelecer requisitos de ferramentas de apoio aos processos padro definidos para software livre, buscando apoiar de forma automatizada os processos de software propostos. Tais ferramentas devem ser integradas em um ambiente na Web.

1.3 Metodologia

Aps a definio dos objetivos iniciais deste trabalho, uma profunda e detalhada reviso bibliogrfica da literatura foi efetuada no que tange aos conceitos de qualidade e processo de software, abrangendo o estudo de diversas normas e modelos de qualidade, a saber: ISO 9000, ISO/IEC 12207, ISO/IEC 15504, CMMI, IEEE 1219 e MPS.BR. Em paralelo, foram realizados estudos referentes aos conceitos de Software Livre e caractersticas de seu desenvolvimento, apoiando-se, principalmente, em exemplos de projetos de Software Livre bem sucedidos. A partir desse levantamento, o escopo do trabalho foi revisado, chegando aos objetivos descritos na seo anterior, destacando-se o foco voltado ao Projeto ODE Livre como base para a definio dos processos. Paralelamente ao levantamento bibliogrfico, os processos padro foram sendo definidos. Inicialmente, o processo padro j definido para o LabES foi reformulado aos moldes propostos pelo MPS.BR. A partir da, o processo padro de desenvolvimento de software livre para o LabES foi definido, seguido do processo padro de manuteno do LabES (at ento inexistente) e do processo padro LabES de manuteno de software livre. Aps a definio dos processos padro, um artigo referente a este trabalho foi produzido e submetido ao V Simpsio Brasileiro de Qualidade de Software, com o objetivo principal de se ter um sentimento sobre a aprovao da comunidade em relao ao trabalho produzido. O artigo (SILVA et al., 2006) foi aceito, publicado e apresentado no referido evento, sendo que algumas consideraes feitas pelos revisores foram incorporadas ao trabalho. Finalmente, com o intuito de prover auxlio aos processos definidos, requisitos de um ambiente de apoio automatizado aos processos definidos foram levantados, contando, inicialmente, com a integrao de algumas ferramentas livres ao Portal ODE Livre, em desenvolvimento (SILVA, 2006).

1.4 Organizao da Dissertao

Esta dissertao contm, alm deste captulo que apresenta a Introduo, mais cinco captulos. O Captulo 2 Processo de Software aborda o tema processo de software, discutindo nveis de processo e qualidade de processos software atravs de normas e modelos de qualidade, dentre eles ISO 9001, ISO/IEC 12207, CMMI, ISO/IEC 15504 e MPS.BR-MR. Este captulo apresenta, ainda, um processo padro proposto para equipes geograficamente dispersas. O Captulo 3 Software Livre apresenta o movimento de Software Livre, caractersticas de desenvolvimento de SL, alm de apresentar alguns projetos de SL bem sucedidos. O Captulo 4 Processos Padro para Software Livre inicia apresentando o objeto de estudo ao qual este trabalho se aplica, o Ambiente de Desenvolvimento de Software ODE. A seguir, feita uma discusso sobre os processos padro para software livre desenvolvidos para o LabES, organizao responsvel pelo Projeto ODE Livre. O Captulo 5 Requisitos de um Ambiente de Apoio ao Desenvolvimento de Software Livre discute aspectos relacionados ao apoio automatizado para apoiar os processos definidos no captulo anterior, apresentado os primeiros esforos no sentido de construir o Portal ODE Livre, onde o ambiente ODE ser disponibilizado para a comunidade e no qual se encontraro muitas ferramentas de apoio aos processos propostos. O Captulo 6 Consideraes Finais apresenta as concluses deste trabalho e perspectivas futuras.

Captulo 2 Processo de Software

Uma importante contribuio da rea de pesquisa de processo de software tem sido a conscientizao de que o desenvolvimento de software um processo complexo. Pesquisadores e profissionais tm percebido que desenvolver software no est circunscrito somente criao de linguagens de programao e ferramentas efetivas. O desenvolvimento de software um processo coletivo, complexo e criativo. Sendo assim, a qualidade de um produto de software depende fortemente das pessoas, da organizao e de procedimentos utilizados para cri- lo e disponibiliz- lo (FUGGETTA, 2000). Dada a complexidade envolvida na definio de processos de software, no uma boa estratgia definir cada processo de projeto a partir do zero. Assim, apesar de cada projeto ter suas caractersticas prprias, possvel estabelecer conjuntos de elementos que devem estar presentes em todos os processos de uma organizao. Esses elementos em comum possibilitam a formao dos processos padro da organizao, que, por sua vez, podem ser especializados para determinadas classes de projetos dessa organizao. Processos padro e especializados podem, ento, ser instanciados em processos de projeto, em uma abordagem de definio de processos em nveis (ROCHA et al., 2001). Idealmente, os elementos de um processo de software devem ser definidos segundo normas e modelos de qualidade, objetivando obter processos de qualidade. Este captulo visa a dar uma viso geral da rea de processos de software e est estruturado da seguinte forma: a seo 2.1 discute o que processo de software; a seo 2.2 apresenta os diferentes nveis de processo de software; a seo 2.3 trata da qualidade de processo de software e apresenta sucintamente os principais modelos e normas de qualidade de processo de software; na seo 2.4 so abordadas caractersticas de um processo padro para equipes geograficamente dispersas; e finalmente, na seo 2.5 so apresentadas as consideraes finais deste captulo.

2.1 O que Processo de Software

Um processo de software pode ser definido como um conjunto coerente de atividades, polticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessrios para conceber, desenvolver, dispor e manter um produto de software (FUGGETTA, 2000). Um processo eficaz deve, claramente, considerar as relaes entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessrios e a habilidade, o treinamento e a motivao do pessoal envolvido (FALBO, 1998). A escolha de um modelo de ciclo de vida (ou modelo de processo) o ponto de partida para a definio de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macro-atividades bsicas, estabelecendo precedncia e dependncia entre as mesmas (FALBO, 1998). Processos de software definem o conjunto de atividades conduzidas no contexto do projeto, tais como anlise de requisitos, projeto, codificao, teste, instalao etc, os recursos (software, hardware e pessoas) necessrios e os procedimentos a serem adotados na realizao de cada uma das atividades. Sendo que essas atividades so compostas por outras atividades e podem se comunicar entre si e operam sobre artefatos de entrada para produzir artefatos de sada (FALBO, 1998) (GRUHN, 2002). Outra questo que envolve a elaborao de um processo de software a sua adequao ao domnio de aplicao e ao projeto. A cada projeto, o processo de software deve ser ajustado s especificidades da aplicao, tecnologia a ser utilizada na sua construo, grupo de desenvolvimento e usurios finais (FALBO, 1998).

2.2 Nveis de Processo de Software

Apesar de cada projeto ter suas caractersticas prprias, possvel estabelecer conjuntos de ativos de processo (sub-processos, atividades, sub-atividades, artefatos, recursos e procedimentos) comuns para toda a organizao. Esses conjuntos constituem os chamados processos padro de uma organizao. A partir deles, outros processos, ainda padro, podem ser especializados, levando-se em considerao caractersticas como tipos de software, paradigmas ou domnios de aplicao. Finalmente, para cada projeto, pode-se instanciar um processo padro, especializado ou no, buscando atender
7

s suas caractersticas prprias, definindo os chamados processos de projeto (ROCHA et al., 2001) (BERTOLLO et al., 2006). Esse modelo de definio de processos em nveis adotado no Laboratrio de Engenharia de Software (LabES) da UFES, como mostra a Figura 2.1. Os processos padro para o desenvolvimento e manuteno de software do LabES so definidos tomando por base modelos e normas de qualidade, principalmente as normas ISO/IEC 12207 (ISO/IEC, 1998) e IEEE 1219 (IEEE, 1998) e o modelo MPS.BR (SOFTEX, 2006).
Normas e Modelos de Qualidade, Cultura Organizacional
ISO/IEC 12207, IEEE 1219, MPS.BR

Definio

PPLabES

Processo Padro

Tipo de Software, Domnio do Problema, Paradigma e Tecnologia de Desenvolvimento

Especializao
PPELabES-OO Processo Especializado 1 PPELabES-Est Processo Especializado n

Particularidades do Projeto, Modelo de Ciclo de Vida (ou Modelo de Processo)

Processo de Projeto 1

Instanciao

Processo de Projeto m

Figura 2.1 Modelo para Definio de Processos em Nveis A partir deles so especializados outros processos padro de desenvolvimento e manuteno, tais como os Processos Especializados para o Desenvolvimento Orientado a Objetos (PPELabESOO) e para o Desenvolvimento segundo o Paradigma Estruturado (PPELabES-Est). Esses processos podem ser recursivamente especializados, criando outros nveis na hierarquia. Por exemplo, conforme discutido no captulo 4 deste trabalho, a partir dos processos especializados para desenvolvimento e manuteno orientados a objetos, foram definidos processos especializados para desenvolvimento e manuteno de Software Livre no LabES, considerando a heterogeneidade dos grupos de trabalho, caractersticas do desenvolvimento de software com equipes geograficamente dispersas e prticas aplicadas a projetos de Software Livre bem sucedidos.

2.3 Qualidade de Processo de Software

Quando se produz um software, assim como qualquer outro produto, desejvel que o mesmo possua elevada qualidade, que seja produzido de forma otimizada e dentro dos prazos estabelecidos previamente. No desenvolvimento de software, uma das principais maneiras de se garantir tais caractersticas para o produto final atravs de um processo de software de qualidade. Ou seja, se um produto de software foi desenvolvido seguindo um processo de qualidade, as chances do mesmo ser um produto de qualidade so maiores. Alm disso, para que a organizao que produz software tenha sua qualidade reconhecida em todo o mundo, seus processos devem respeitar padres de qualidade definidos pela comunidade de software. Desde a dcada de 1980, iniciaram-se esforos para melhoria de processos de software, com o objetivo de melhorar a qualidade, aumentar a produtividade e diminuir os custos. Diferentes modelos so utilizados dependendo do mercado alvo das organizaes de software (ROCHA et al., 2001). As principais normas e modelos de qualidade difundidos atualmente so: ISO 9000 (ISO, 2000), ISO/IEC 12207 (ISO/IEC, 1998), ISO/IEC 15504 (ISO/IEC, 2003), CMMI (SEI, 2001) e MPS.BR (SOFTEX, 2006), sucintamente apresentados na seqncia juntamente com a norma IEEE 1219 (IEEE, 1998), que voltada exclusivamente para manuteno.

2.3.1 ISO 9000:2000

As normas da famlia NBR ISO 9000:2000 (ISO, 2000) foram desenvolvidas para apoiar organizaes de todos os tipos e tamanhos (no s as de software), na implementao e operao de sistemas de gesto da qualidade eficazes. A norma ISO 9000 descreve os fundamentos de sistemas de gesto da qualidade, que constituem o objeto da famlia NBR ISO 9000, e define os termos a ela relacionados (ISO, 2000). Segundo XAVIER (2001), a famlia NBR ISO 9000 composta de uma srie de normas, mas somente as normas ISO 9001, 9002 e 9003 podem ser utilizadas como requisitos entre clientes e fornecedores. A ISO 9003 abrange somente requisitos para a garantia da qualidade em inspeo e ensaios finais. A ISO 9002 abrange requisitos para

a garantia da qualidade em produo, instalao e servios associados. J a ISO 9001 a mais completa, abrangendo todo o ciclo de vida de um produto ou servio, cobrindo os requisitos para a garantia da qualidade em projetos, desenvolvimento, produo, instalao e servios associados (MUTAFELIJA et al., 2003). Com a chegada da verso 2000 da ISO 9000, os requisitos da ISO 9001 foram reestruturados e as normas ISO 9002 e 9003 devero ser canceladas (WEBER, 2001). XAVIER (2001) considera que a grande modificao introduzida pela verso 2000 da ISO 9001 est na mudana do objetivo dos sistemas de gesto da qualidade, passando do atendimento aos requisitos especificados pelo cliente, para a satisfao do cliente, ou seja, para o atendimento no somente dos requisitos explcitos, especificados pelo cliente, mas tambm dos requisitos implcitos (WEBER, 2001). A ISO 9000:2000 baseada em um conjunto de princpios de gerenciamento de qualidade, definidos a partir da experincia de vrias organizaes (ISO, 2000): Princpio 1 - Foco no cliente: Dado que as organizaes dependem de seus clientes, recomendvel que atendam s suas necessidade atuais e futuras e aos seus requisitos e procurem exceder as suas expectativas. Princpio 2 - Liderana: Lderes estabelecem a unidade de propsito e o rumo da organizao. Convm que criem e mantenham um ambiente onde as pessoas estejam totalmente envolvidas no propsito de atingir os objetivos da organizao. Princpio 3 - Envolvimento de pessoas: Pessoas de todos os nveis so a essncia de uma organizao. Seu envolvimento possibilita o

aproveitamento de suas habilidades por toda a organizao. Princpio 4 - Abordagem de processo: Um resultado desejado alcanado mais eficientemente quando suas atividades e recursos so gerenciados como um processo. Princpio 5 - Abordagem sistmica para a gesto: Identificar, entender e gerenciar os processos inter-relacionados como um sistema contribui para a eficcia e eficincia da organizao no sentido desta atingir os seus objetivos.

10

Princpio 6 - Melhoria contnua: Convm que a melhoria contnua do desempenho global da organizao seja seu objetivo permanente.

Princpio 7 - Abordagem factual para tomada de deciso: Decises eficazes so baseadas na anlise de dados e informaes.

Princpio 8 - Benefcios mtuos nas relaes com os fornecedores: Pelo fato de organizao e fornecedores serem interdependentes, uma relao de benefcios mtuos aumenta a capacidade de ambos em agregar valor.

Para que as organizaes funcionem de forma eficaz, elas tm que identificar e gerenciar processos inter-relacionados e interativos. Freqentemente, a sada de um processo resultar diretamente na entrada do processo seguinte. A identificao sistemtica e a gesto dos processos empregados na organizao e, particularmente, as interaes entre tais processos so conhecidos como abordagem de processos. Assim, a inteno desta norma encorajar a adoo da abordagem de processo para a gerncia da qualidade em uma organizao (ISO, 2000).

2.3.2 ISO/IEC 12207

A norma internacional NBR ISO/IEC 12207 Tecnologia da Informao Processos de Ciclo de Vida de Software (ISO/IEC, 1998) estabelece uma estrutura comum para os processos de ciclo de vida de software, com terminologia bem definida, podendo ser referenciada pela indstria de software. Sua estrutura composta de processos, atividades e tarefas, que podem ser aplicados durante a aquisio de um sistema que contm software, de um produto de software independente ou de um servio de software, e tambm durante o fornecimento, desenvolvimento, operao e manuteno de produtos de software. Recentemente foram feitas duas emendas ISO/IEC 12207. A Emenda 1 (ISO/IEC, 2002) foi publicada em 2002 visando estabelecer um conjunto coordenado de informaes de processo de software que pudesse ser utilizado para a definio, avaliao e melhoria de processos. A Emenda 1 resolveu o problema de granularidade relacionado ao uso da ISO/IEC 12207 para avaliao de processo e definiu propsitos e resultados esperados de um processo para estabelecer um Modelo de Referncia de Processo, de acordo com os requisitos da norma ISO/IEC 15504-2 (ISO/IEC, 2003).
11

Um Modelo de Referncia de Processo fornece definies de processos num ciclo de vida, descritas em termos de propsitos e resultados do processo, juntamente com uma arquitetura descrevendo a relao entre eles. A utilizao da Emenda 1 para avaliao de processos revelou defeitos tcnicos e problemas editoriais em certos processos do Modelo de Referncia de Processo. Os defeitos notados tiveram impacto sobre o desenvolvimento do modelo de exemplo de avaliao da ISO/IEC 15504-5 (ISO/IEC, 2004). A Emenda 2 resolve essas deficincias e fornece aos usurios do Modelo de Referncia de Processo e aos desenvolvedores dos modelos de avaliao uma base melhorada para o seu trabalho (ISO/IEC, 2004). Os processos do ciclo de vida do software esto agrupados em trs classes nessa norma: Processos Fundamentais, Processos de Apoio e Processos Organizacionais, como mostra a figura 2.2. Os processos so compostos por atividades e estas so decompostas em tarefas. Processos Fundamentais Aquisio Fornecimento Processos de Apoio

Desenvolvimento

Documentao Gerncia de Configurao Garantia da Qualidade Verificao Operao Validao Reviso Auditoria Usabilidade Manuteno Gerncia de Resoluo de Problemas Gerncia de Solicitao de Mudanas Avaliao do Produto Processos Organizacionais Engenharia de Domnio Infra-estrutura Recursos Humanos Melhoria

Adaptao

Gerncia Gesto de Ativos Gesto de Programa de Reso

Figura 2.2 Estrutura da ISO/IEC 12207 (Emendas 1 e 2) A seguir, os processos da norma, j contendo as alteraes das emendas 1 e 2, so descritos segundo seu propsito (ISO/IEC, 2002) (ISO/IEC, 2004): Processos Fundamentais 1. Processo de aquisio Obter um produto e/ou servio que satisfaa a necessidade expressa pelo cliente. O processo inicia com a identificao de

12

uma necessidade do cliente e encerra com a aceitao do produto e/ou servio. 2. Processo de fornecimento Fornecer um produto ou servio ao cliente que atenda aos requisitos acordados. 3. Processo de desenvolvimento Transformar um conjunto de requisitos em um produto de software ou um sistema baseado em software que atenda s necessidades explicitadas pelo cliente. 4. Processo de operao Operar o produto de software no seu ambiente e fornecer suporte aos clientes desse produto. 5. Processo de manuteno Modificar um produto de software/sistema aps sua entrega para corrigir falhas, melhorar o desempenho ou outros atributos, ou adapt- lo a mudanas no ambiente. Processos de apoio 1. Processo de documentao Desenvolver e manter registradas as

informaes do software produzidas por um processo. 2. Processo de gerncia de configurao Estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizlos a todos os envolvidos. 3. Processo de garantia da qualidade Fornecer garantia de que os produtos de trabalho e processos esto em conformidade com os planos e condies pr-definidos. 4. Processo de verificao Confirmar que cada produto de trabalho de software e/ou servio de um processo ou projeto reflete apropriadamente os requisitos especificados. 5. Processo de validao Confirmar que so atendidos os requisitos de um uso especfico pretendido para o produto de trabalho de software. 6. Processo de reviso Manter um entendimento comum com os envolvidos (stakeholders) a respeito do progresso obtido em relao aos objetivos acordados e ao que deveria ser feito. Isso realizado para ajudar a assegurar o desenvolvimento de um produto que satisfaa os envolvidos. As revises conjuntas ocorrem nos nveis gerencial e tcnico e so conduzidas durante o ciclo de vida do projeto.

13

7. Processo de auditoria Determinar, de forma independente, a conformidade dos produtos e processos selecionados com os requisitos, planos e contratos, quando apropriado. 8. Processo de usabilidade Garantir que sejam considerados os interesses e necessidades dos envolvidos de forma a proporcionar otimizao do suporte e do treinamento, aumento da produtividade e da qualidade do trabalho, melhoria das condies para o trabalho humano e reduo das chances de rejeio do sistema por parte do usurio. 9. Processo de gerncia de resoluo de problemas Assegurar que todos os problemas identificados so analisados e resolvidos e que as tendncias so identificadas. 10. Processo de gerncia de solicitao de mudanas Garantir que pedidos de mudanas so gerenciados, seguidos e controlados. 11. Processo de avaliao de produto Garantir, por meio de exames e medies sistemticos, que o produto atinge as necessidades indicadas e implcitas dos usurios do produto. Processos organizacionais 1. Processo de gerncia Organizar, monitorar e controlar a iniciao e a execuo de qualquer processo de forma a atingir as suas metas, tendo por base as metas de negcio da organizao. 2. Processo de infra-estrutura Manter uma infra-estrutura estvel e confivel, necessria para apoiar a execuo de qualquer outro processo. A infraestrutura pode incluir hardware, software, mtodos, ferramentas, tcnicas, padres e instalaes para o desenvolvimento, a operao ou a manuteno. 3. Processo de melhoria Estabelecer, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software. 4. Processo de recursos humanos Fornecer organizao os recursos humanos adequados e manter as suas competncias consistentes com as necessidades do negcio. 5. Gerncia de ativos Gerenciar a vida dos ativos reutilizveis desde a sua concepo at a sua descontinuao.

14

6. Gerncia do programa de reutilizao Planejar, estabelecer, gerenciar, controlar e monitorar esse programa em uma organizao e sistematicamente explorar as oportunidades de reso. 7. Processo de Engenharia de Domnio Desenvolver e manter modelos, arquiteturas e ativos de domnio. Processo de adaptao O Processo de adaptao possui atividades que permitem adaptar a norma para sua aplicao na organizao ou em projetos. A adaptao deve ser executada baseando-se em alguns fatores que diferenciam uma organizao ou projeto de outros, dentre eles a estratgia de aquisio, modelos de ciclo de vida, caractersticas de sistemas e software e cultura organizacional. Este processo permite que a norma seja adaptvel a qualquer projeto, organizao, modelo de ciclo de vida, cultura e tcnica de desenvolvimento (ROCHA et al., 2001).

2.3.3 ISO/IEC 15504

A norma internacional ISO/IEC 15504 (ISO/IEC, 2003) estabelece uma estrutura para a avaliao de processos. Essa estrutura pode ser usada por organizaes envolvidas com planejamento, gerenciamento, monitorao, controle e melhoria de aquisio, fornecimento, desenvolvimento, operao, evoluo e suporte de software. So propsitos dessa norma: ajudar organizaes a compreender o estado de seus prprios processos com vistas melhoria; ajudar organizaes a determinar a adequao de seus processos para um requisito particular ou classe de requisitos; ajudar organizaes a determinar a adequao de processos de uma outra organizao para um contrato particular ou classe de contratos. A norma consiste das seguintes partes, sob o ttulo geral Tecnologia de Informao Avaliao de Processo de Software (ISO/IEC, 2003):

15

Parte 1: Conceitos e vocabulrio (informativo): prov uma introduo geral aos conceitos de avaliao de processos e um glossrio de termos relacionados a avaliao.

Parte 2: Realizando uma avaliao (normativa): define os requisitos mnimos para a realizao de uma avaliao.

Um modelo de referncia para processos e capacidade de processos Parte 3: Guia para a realizao de avaliaes (informativa): prov orientaes para interpretar os requisitos para a realizao de uma avaliao.

Parte 4: Guia para uso na melhoria de processo e na determinao da capacidade de processo (informativa): identifica a avaliao de processo como uma atividade que pode ser realizada tanto como parte de uma iniciativa de melhoria de processo quanto parte de uma abordagem de determinao da capacidade.

Parte 5: Um Exemplo de modelo de avaliao de processo baseado na ISO/IEC 12207 e suas Emendas 1 e 2 (informativa): contm um exemplo de modelo de avaliao de processo que baseado no modelo de processo de referncia definido na ISO/IEC 12207 e suas emendas 1 e 2.

A parte 5 da norma ISO/IEC 15504 desperta maior interesse para os interessados na definio de processo, por oferecer um modelo de referncia disposto a guiar a definio de um processo de software de qualidade. De fato, o objetivo dessa parte da ISO/IEC 15504 definir um exemplo de um Modelo de Avaliao de Processo que satisfaz os requisitos da ISO/IEC 15504-2 e que apia a realizao de uma avaliao, provendo indicadores para guiar a interpretao dos propsitos de processo, conforme definidos nas emendas 1 e 2 da ISO/IEC 12207, e dos atributos de processo definidos ISO/IEC 15504-2. O Modelo de Avaliao de Processo nesta parte da ISO/IEC 15504 dirigido a patrocinadores de avaliaes e avaliadores competentes que desejem escolher um modelo para avaliao, seja para determinao da capacidade seja para melhoria de processo. Adicionalmente, esse modelo pode ser til para os desenvolvedores de

16

modelos de avaliao, provendo exemplos de boas prticas de gerncia e engenharia de software. A Figura 2.3 lista os processos das emendas 1 e 2 da ISO/IEC 12207 que foram includos na dimenso de processos do exemplo de Modelo de Avaliao de Processo e mostra sua classificao em categorias e grupos de processos.

17

Processos Primrios Grupo de Processos de Aquisio Preparao para Aquisio Seleo de Fornecedor Acordo de Contrato Monitorao de Fornecedor Aceite do Cliente Grupo de Processos de Fornecimento Proposta do Fornecedor Entrega do Produto Suporte ao Aceite do Produto Grupo de Processos de Engenharia Levantamento de Requisitos Anlise de Requisitos do Sistema Projeto de Arquitetura do Sistema Anlise de Requisitos de Software Projeto de Software Construo de Software Integrao de Software Testes de Software Integrao de Sistema Testes de Sistema Instalao de Software Manuteno de Sistema e Software Grupo de Processos de Operao Uso Operacional Suporte ao Cliente

Processos Organizacionais Grupo de Processos de Gerncia Alinhamento Organizacional Gerncia Organizacional Gerncia de Projeto Gerncia da Qualidade Gerncia de Risco Medio Grupo de Processos de Melhoria de Processos Estabelecimento de Processos Avaliao de Processos Melhoria de Processos Grupo de Processos de Recursos e Infraestrutura Gerncia de Recursos Humanos Treinamento Gerncia de Conhecimento Infra-estrutura Grupo de Processos de Reso Gerncia de Ativos Gerncia do Programa de Reutilizao Engenharia de Domnio

Processos de Apoio Grupo de Processos de Controle de Configurao Documentao Gerncia de Configurao Gerncia de Resoluo de Problemas Gerncia de Solicitao de Mudanas Grupo de Processos de Garantia da Qualidade Garantia da Qualidade Verificao Validao Reviso Conjunta Auditoria Avaliao do Produto

Figura 2.3 Processos do Exemplo de Modelo de Avaliao de Processos da ISO/IEC 15504.

18

2.3.4 CMMI

O projeto CMMI (Capability Maturity Model Integration) (SEI, 2002) foi concebido para solucionar o problema do uso de mltiplos modelos de maturidade de capacitao, tendo como foco trs modelos principais: SW-CMM (Capability Maturity Model for Software), SECM (System Engineering Capability Model) e IPD-CMM (Integrated Product Development Capability Maturity Model) (CHRISSIS et al., 2003). um projeto patrocinado pelo Departamento de Defesa Americano, em conjunto com a indstria, por meio do Comit de Engenharia de Sistemas na Associao Industrial de Defesa Nacional, e o Instituto de Engenharia de Software (Software Engineering Institute SEI). O projeto CMMI envolveu um grande nmero de pessoas de diferentes organizaes de todo o mundo, interessadas nos benefcios do desenvolvimento de uma estrutura integrada em prol da melhoria de processos. Apesar de prover um novo modelo, o CMMI procura preservar ao mximo os investimentos feitos em melhoria de processos baseadas no SW-CMM. O objetivo do CMMI fornecer direcionamentos para melhorar os processos de uma organizao e sua capacidade de gerenciar o desenvolvimento, aquisio e manuteno de produtos e servios. O CMMI prov abordagens comprovadas em uma estrutura que ajuda organizaes a avaliar sua maturidade ou capacidade em determinada rea de processo, estabelecer prioridades para melhoria e implementar essas melhorias. bom lembrar que o CMMI direcionado para a melhoria de processos de organizaes de qualquer tipo. Alm disso, como outros modelos de maturidade de capacitao, os modelos do CMMI fornecem orientaes a serem utilizadas no desenvolvimento de processos. Ou seja, esses modelos no so processos ou descries de processos. Os processos reais utilizados em uma organizao dependem de vrios fatores, incluindo domnio de aplicao e tamanho e estrutura da organizao. Assim, normalmente, as reas de processo do modelo CMMI no podem ser mapeadas uma a uma em processos utilizados em uma organizao (SEI, 2002). O CMMI tem duas representaes: em estgio e contnua. Ambas as representaes contm reas de processo comuns. Porm, na representao em estgio, as reas de processo esto agrupadas em nveis de maturidade e na representao contnua, a mesma rea de processo est dividida em categorias.

19

A representao contnua permite selecionar a seqncia de melhorias que melhor atende aos objetivos de negcio e reduz as reas de risco da organizao. Tambm permite comparaes entre organizaes em uma rea de processo pela comparao de resultados utilizando estgios equivalentes (SEI, 2002). A representao em estgios oferece uma seqncia comprovada de melhorias, comeando com prticas bsicas de gerncia e progredindo por um caminho prdefinido e comprovado de nveis sucessivos, cada um servindo de base para o prximo. Alm disso, permite comparaes entre organizaes pelo uso de nveis de maturidade (SEI, 2002). Mesmo no sendo objetivo principal da representao contnua a classificao em um determinado nvel de maturidade, e sim o desenvolvimento de determinadas reas de processos, um determinado nvel de maturidade pode ser atingido por quem usa a representao contnua, se todas as reas de processo relevantes para tal nvel tiverem atingido a capacidade mnima para o nvel de maturidade. Os componentes do Modelo CMMI incluem nveis de maturidade (Maturity Levels), reas de processo (Process Areas - PAs), metas genricas (Generic Goals GG), metas especficas (Specific Goals - SG), prticas genricas (Generic Practices GP) e prticas especficas (Specific Practices - SP), como ilustra a Figura 2.4. Uma rea de processo um grupo de prticas relacionadas em uma rea que, quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas importantes para trazer uma melhoria significativa naquela rea. As reas de processos do CMMI so as mesmas para ambas as representaes (contnua e em estgios). Na representao em estgios, as reas de processo esto organizadas por nveis de maturidade. As metas especficas se aplicam a uma rea de processo e contemplam caractersticas nicas que descrevem o que deve ser implementado para satisfazer tal rea. Metas especficas so componentes exigidos do modelo e so utilizadas nas avaliaes para auxiliar a determinar se a rea de processo est sendo satisfeita. Prticas especficas so atividades consideradas importantes na satisfao de suas metas especficas associadas. Descrevem atividades focadas no atendimento de metas especficas de uma rea de processo. As prticas especficas so componentes esperados do modelo. As metas genricas so chamadas de genricas, pois a mesma declarao de meta encontrada em diversas reas de processos. Na representao em estgios, cada
20

rea de processo tem somente uma meta genrica. A satisfao de uma meta genrica em uma rea de processo significa um controle melhorado do planejamento e implementao dos processos associados com aquela rea de processo, indicando, portanto, se esses processos parecem ser eficientes, repetveis e durveis. As metas genricas so componentes exigidos do modelo e so utilizadas em avaliaes para determinar a satisfao de uma rea de processo. As prticas genricas oferecem uma institucionalizao que garante que os processos associados com a rea de processo em questo sero eficientes, repetveis e durveis. As prticas genricas so categorizadas pelas metas genricas e caractersticas comuns e so componentes esperados em modelos CMMI.
Nveis de Levels Maturity Maturidade

rea de Area 1 Process Processo 1

rea de Area 2 Process Processo 2

rea de Area n Process Processo n

Specific Goals Metas Especficas

Metas Genricas Generic Goals

Caractersticas Comuns Commitment Compromisso to Perform Specific Practices Prticas Especficas Ability Habilitao to Perform Directing Implementao Implementation Implementation Verifying Verificao da Implementation Implementao

Prticas Genricas Generic Practices

Figura 2.4 Componentes do Modelo CMMI.

O nvel de maturidade de uma organizao uma maneira de prever o futuro desempenho da mesma dentro de dada disciplina ou conjunto delas. A experincia mostra que as organizaes funcionam melhor quando concentram seus esforos de melhoria de processos em um nmero controlado de reas de processos que exigem esforo cada vez mais sofisticado medida que a organizao melhora. Cada nvel de maturidade, alm de representar uma etapa evolucionria definida da melhoria de processos, estabiliza uma parte importante dos processos da organizao.

21

Nos modelos CMMI com representao em estgios, existem cinco nveis de maturidade, cada um representando uma camada da base da melhoria de processos, definidos pelos nmeros de 1 a 5. A Tabela 2.1 apresenta as reas de processo do CMMI para Engenharia de Sistemas / Engenharia de Software, organizados em nveis de maturidade.

Tabela 2.1 Nveis de Maturidade e reas de Processos do CMMI-SE/SW. Nvel 5 (mais alto) 4 rea de Processo Inovao e Implantao na Organizao Anlise de Causas e Resoluo Desempenho do Processo Organizacional Gerncia Quantitativa do Projeto Anlise de Deciso e Resoluo Gerncia de Riscos Desenvolvimento de Requisitos Soluo Tcnica Integrao do Produto Verificao Validao Treinamento Organizacional Foco no Processo Organizacional Definio do Processo Organizacional Gerncia de Projeto Integrada Medio e Anlise Gerncia de Configurao Gerncia de Acordo com Fornecedores Garantia da Qualidade do Processo e do Produto Gerncia de Requisitos Planejamento de Projeto Monitorao e Controle de Projeto

2.3.5 MPS.BR

O MPS.BR (SOFTEX, 2006) um programa para Melhoria de Processo do Software Brasileiro, que est em desenvolvimento desde dezembro de 2003, sendo coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX) e com o apoio do Ministrio da Cincia e Tecnologia (MCT),

22

Os objetivos principais do MPS.BR so (SOFTEX, 2006): (i) definir e aprimorar u m m o d e lo de melhoria e avaliao de processos de software, com foco preferencialmente nas micro, pequenas e mdias empresas, de forma a atender suas necessidades de negcio e (ii) ser reconhecido nacional e internacionalmente como um modelo aplicvel indstria de software. Ele aderente a modelos e normas internacionais, estando fortemente baseado, sobretudo, nas normas ISO/IEC 12207 e suas emendas 1 e 2, ISO/IEC 15504 e no CMMI-SE/SW. Alm disso, o MPS.BR define regras para a sua implementao e avaliao, dando sustentao e garantia de que o modelo est sendo empregado de forma coerente com as suas definies (SOFTEX, 2006). O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliao e melhoria da qualidade e produtividade de produtos de software e servios correlatos. Dentro desse contexto, o MPS.BR decomposto em trs partes: Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-MPS) e Modelo de Negcio (MNMPS) (SOFTEX, 2006). O ponto inicial para a definio do MR-MPS (WEBER et al., 2004) foi a anlise das empresas brasileiras, as normas ISO/IEC 12207 e ISO/IEC 15504-2 e o modelo CMMI. A definio dos processos de software do MR-MPS segue a forma apresentada na emenda 1 da ISO/IEC 12207, declarando o propsito e os resultados esperados de sua execuo. Isso permite avaliar e atribuir graus de efetividade na execuo dos processos. Da mesma forma que a norma ISO/IEC 12207, o MR-MPS define processos fundamentais, processos de apoio e os processos organizacionais (mostrados na Figura 2.5) e um processo de adaptao. Cada empresa interessada em implantar o MR-MPS deve selecionar os processos pertinentes a partir desse conjunto, de acordo com o processo de adaptao, e deve definir as atividades e tarefas necessrias para atender ao propsito e aos resultados esperados de cada processo (SOFTEX, 2006). O M R -MPS define sete nveis de maturidade: A (Em Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nvel G e progride at o nvel A. Para cada um desses sete nveis de maturidade foi atribudo um perfil de processos e de capacidade de processos que indica onde a organizao tem que colocar esforos para melhoria, de forma a atender aos seus objetivos de negcio (SOFTEX, 2006).
23

Figura 2.5 Processos do MPS.BR Os processos no MR-MPS so descritos em termos de seu propsito, resultados e informaes adicionais. O propsito o objetivo geral que deve ser atingido na execuo do processo em questo. Os resultados esperados estabelecem os resultados a serem atingidos com a implementao efetiva do processo. As evidncias desses resultados podem ser tanto artefatos produzidos quanto mudanas significativas na

24

execuo do processo. As informaes adicionais so referncias que podem ajudar na definio do processo organizacional, fornecendo descries de atividades, tarefas e melhores prticas, que podem apoiar a definio e implementao do processo nas organizaes. A Tabela 2.2 mostra os processos correspondentes a cada nvel de maturidade do MPS.BR e seus propsitos. Tabela 2.2 Nveis de Maturidade e Processos do MPS.BR.
Nvel A (mais alto) Processos Implantao de Inovaes na Organizao Anlise Resoluo de Causas e Propsito de Processo Selecionar e implantar melhorias incrementais e inovadoras que, de forma mensurada, melhorem os processos e as tecnologias da organizao. Identificar causas de defeitos e de outros problemas e tomar aes para prevenir suas ocorrncias no futuro.

Desempenho do Processo Organizacional

Estabelecer e manter um entendimento quantitativo do desempenho dos processos-padro da organizao para apoiar os objetivos para qualidade e para o desempenho dos processos. Fornecer dados, linhasb s i c a s (baselines) e modelos para gerenciar quantitativamente os projetos da organizao.

Gerncia Quantitativa do Gerenciar quantitativamente o processo definido para Projeto o projeto de forma a alcanar os objetivos para qualidade e para o desempenho do processo estabelecido para o projeto. C Anlise Resoluo Gerncia de Riscos de Deciso e Analisar possveis decises usando um processo formal da avaliao das alternativas identificadas em relao a critrios estabelecidos. Identificar, gerenciar e reduzir continuamente os riscos em nvel organizacional e de projeto.

25

Tabela 2.2 Nveis de Maturidade e Processos do MPS.BR (Continuao).

D Desenvolvimento de Requisitos Soluo Tcnica Integrao do Produto Estabelecer os requisitos dos componentes do produto, do produto e do cliente. Projetar, desenvolver e implementar solues para atender aos requisitos. Compor os componentes do produto, chegando a um produto integrado consistente com o projeto (design), e demonstrar que os requisitos funcionais e no-funcionais so satisfeitos para o ambiente alvo ou equivalente. Verificao Confirmar que cada servio e/ou produto de trabalho do processo ou do projeto reflete apropriadamente os requisitos especificados. Validao Confirmar que um produto ou seu componente atender a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido. E Treinamento Prover a organizao e os projetos com profissionais que possuam os conhecimentos e as habilidades necessrias para executar suas funes de forma efetiva. Definio do Processo Organizacional Estabelecer e manter um conjunto de ativos dos processos organizacionais usveis e aplicveis s necessidades de negcio da organizao. Avaliao e Melhoria do Determinar Processo Organizacional o quanto os processos-padro da organizao contribuem para a organizao a planejar e implementar melhorias contnuas nos processos com base no entendimento de seus pontos fortes e fracos. Adaptao do Processo para Gerncia do Projeto Estabelecer e gerenciar o projeto e envolver os interessados de acordo com o processo definido e integrado que adaptado do conjunto de processospadro da organizao.

26

Tabela 2.2 Nveis de Maturidade e Processos do MPS.BR (Continuao).

F Medio Coletar e analisar os dados relativos aos produtos desenvolvidos e aos processos implementados na organizao e em seus projetos, de forma a apoiar os objetivos organizacionais. G e r n c i a Configurao Aquisio d e Estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizlos a todos os envolvidos. Obter um produto e/ou servio que satisfaa a necessidade do cliente. Garantia da Qualidade Garantir que os produtos de trabalho e a execuo dos processos esto em conformidade com os planos e recursos predefinidos. G Gerncia de Requisitos Gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistncias entre esses requisitos e os planos e produtos de trabalho do projeto. Gerncia do Projeto Identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou servio, com base nos requisitos e restries do projeto.

A Tabela 2.3 mostra a relao entre os processos do MPS.BR e as reas de processo do CMMI, alm de relacionar seus nveis de maturidade. O mapeamento obtido s possvel pelo fato do modelo MPS.BR ser fortemente baseado no CMMI.

27

Tabela 2.3 Relao entre MPS.BR e CMMI. MPS.BR Nvel A (mais alto) Processo Inovao e Implantao na Organizao Anlise de Causas e Resoluo Desempenho do Processo Organizacional Gerncia Quantitativa do Processo Anlise de Deciso e Resoluo C Gerncia de Riscos Desenvolvimento de Requisitos D Soluo Tcnica Integrao do Produto Verificao Validao Treinamento Avaliao e Melhoria do Processo Organizacional Definio do Processo Organizacional Adaptao do Projeto para Gerncia de Projetos Medio Gerncia de Configurao Aquisio Garantia da Qualidade Gerncia de Requisitos Gerncia de Projeto CMMI-SE/SW rea de Processo Inovao e Implantao na Organizao (CMMI-5) Anlise de Causas e Resoluo (CMMI-5) Desempenho do Processo Organizacional (CMMI-4) Gerncia Quantitativa do Projeto (CMMI-4) Anlise de Deciso e Resoluo (CMMI-3) Gerncia de Riscos (CMMI-3) Desenvolvimento de Requisitos (CMMI-3) Soluo Tcnica (CMMI-3) Integrao do Produto (CMMI-3) Verificao (CMMI-3) Validao (CMMI-3) Treinamento Organizacional (CMMI3) Foco no Processo Organizacional (CMMI-3) Definio do Processo Organizacional (CMMI-3) Gerncia de Projeto Integrada (CMMI-3) Medio e Anlise (CMMI-2) Gerncia de Configurao (CMMI-2) Gerncia de Acordo com Fornecedores (CMMI-2) Garantia da Qualidade do Processo e do Produto (CMMI-2) Gerncia de Requisitos (CMMI-2) Planejamento de Projeto (CMMI-2) Monitorao e Controle de Projeto (CMMI-2)

2.3.6 IEEE 1219-1998

A norma IEEE 1219 (IEEE, 1998) descreve um processo iterativo para gerenciar e executar atividades de manuteno de software, sendo que sua utilizao no restringida por tamanho, complexidade, nvel crtico ou aplicao do produto de

28

software. Ela prescreve requisitos para o processo, o controle e a gerncia do planejamento, da execuo e da documentao das atividades de manuteno de software. O modelo de processo bsico descreve as fases do processo de manuteno, suas entradas, sadas e controles necessrios. Vale realar que ele no pressupe o uso de qualquer modelo de ciclo de vida particular (ex. cascata, espiral etc.). Segundo essa norma, um processo de manuteno de software deve incluir as seguintes fases: Identificao, classificao, e priorizao do problema / modificao: as modificaes de software so identificadas, classificadas e recebem uma posio inicial no ranking de prioridades. Cada solicitao de alterao deve ser avaliada para que se determine sua classificao e prioridade; Anlise: nesta fase, informaes do repositrio e da solicitao de alterao validada na fase anterior, junto aos documentos do sistema e do projeto, so utilizadas para estudar a viabilidade e o escopo da modificao e para definir um plano preliminar para o projeto, implementao, teste e entrega. Alm disso, uma anlise detalhada feita para definir os requisitos da modificao e para identificar e alterar os elementos necessrios; Projeto: toda a documentao corrente do sistema e do projeto, software e bancos de dados existentes, bem como os resultados obtidos na fase anterior, devem ser utilizados para projetar a modificao no sistema; Implementao: nesta fase, os resultados da fase de projeto, o cdigo fonte corrente e a documentao do sistema devem ser usados para guiar os esforos de implementao; Testes de regresso / sistema: testes de sistema devem ser realizados no sistema modificado. Testes de Regresso fazem parte dos testes de sistema e devem ser realizados para validar o cdigo modificado quanto introduo de falhas que no existiam antes da atividade de manuteno; Testes de aceitao: devem ser conduzidos em um sistema totalmente integrado. Testes de aceitao devem ser realizados pelo cliente, usurios do pacote de modificao ou uma terceira parte designada pelo cliente; Entrega: refere-s e entrega do sistema de software modificado e procedimentos associados.

29

2.4 Processo Padro para Equipes Geograficamente Dispersas

O crescimento rpido e contnuo da Internet vem possibilitando uma forma de desenvolvimento de software antes no explorada: o desenvolvimento por equipes dispersas geograficamente. Esse tipo de desenvolvimento se mostra muito produtivo por impedir que a distncia seja uma barreira para o desenvolvimento, dado que a comunicao, essencial para o desenvolvimento de software por equipes, tem um timo parceiro a rede mundial de computadores. Neste contexto, as atividades de software podem ser classificadas como atividades assncronas, quando os desenvolvedores trabalham em diferentes horrios com a mesma informao ou trocam mensagens e dados para coordenar suas tarefas; ou atividades sncronas, quando algumas tarefas, tais como reunies, requerem discusses, em uma determinada hora, entre profissionais que podem ser responsveis por diferentes aspectos do software (MAIDANTCHIK, 1999). Pelo fato dos sistemas de computao serem desenvolvidos por vrias equipes, normalmente, a interao e a comunicao entre esses grupos pode determinar o fracasso ou sucesso de um projeto. Uma equipe deve ser conduzida por um coordenador local, enquanto a gerncia de projeto deve supervisionar todo o processo. Os problemas encontrados no desenvolvimento de software por equipes distribudas so comuns a outros contextos de desenvolvimento, porm so agravados quando os grupos de trabalho no se encontram num mesmo lugar. Tais problemas podem ser divididos nas seguintes classes (MAIDANTCHIK, 1999): Coordenao de equipes: r e f e r e -se multidisciplinariedade e

heterogeneidade das equipes; Coordenao das atividades: refere-se aos problemas de identificao de atividades concorrentes e formas de resoluo de problemas de sincronismo; Controle de artefatos: envolve os problemas de integrao de componentes, autoria distribuda, visibilidade dos resultados, notificao de mudanas e gerncia de configurao; Apoio comunicao: aplica-se resoluo de problemas, notificao de decises, registro, acesso e compartilhamento de dados do software e publicao de informaes que auxiliam o acompanhamento de atividades.

30

qualidade

dos

produtos

de

software

desenvolvidos

por

equipes

geograficamente dispersas fortemente dependente de uma comunicao efetiva, da coordenao dos grupos distribudos, do rastreamento sistemtico das atividades e artefatos, e da disponibilidade das informaes do processo de software. Dadas essas caractersticas, os processos de software para equipes geograficamente dispersas possuem requisitos especficos, tais como (MAIDANTCHIK, 1999): Determinar a capacidade das equipes - O processo deve incorporar atividades para identificar o conhecimento, experincia e os recursos humanos, tecnolgicos e econmicos de cada equipe. A determinao da capacidade dos grupos de trabalho deve ser executada antes de se iniciar um projeto de software, permitindo definir os papis de cada membro da equipe e atribuir tarefas, de forma adequada, s diferentes equipes. Apoiar a coordenao distribuda - Por trabalhar em diferentes localidades, cada equipe deve ser supervisionada, localmente, por um coordenador, o qual responde diretamente gerncia do projeto. Tal requisito exige a rastreabilidade do processo e o acompanhamento das atividades tcnicas pela coordenao local. Apoiar a gerncia distribuda do projeto - responsabilidade da gerncia de uma organizao monitorar a execuo de todo o processo de software, atravs da superviso das atividades relatadas pelos coordenadores locais. A gerncia deve identificar tarefas concorrentes, determinar trabalhos cooperativos entre as diversas equipes e definir os pontos de controle do projeto. Apoiar o controle de artefatos - O processo deve incorporar atividades para acompanhar o desenvolvimento de artefatos, garantir que a sua produo siga os procedimentos pr-definidos pela gerncia do projeto e administrar a integrao com outros artefatos produzidos pelas diversas equipes. Apoiar a comunicao entre as equipes - responsabilidade da organizao identificar os recursos disponveis para transmitir e receber mensagens e implantar mecanismos tradicionais ou eletrnicos para permitir a comunicao entre as equipes de software. Apoiar a publicao e o compartilhamento de informaes - responsabilidade da organizao instalar repositrios e mecanismos de

31

acesso a todas as informaes do software, tais como idias, decises, restries e o estado do trabalho em execuo. O processo deve incorporar procedimentos para informar mudanas realizadas por uma determinada equipe e que possam influenciar o trabalho de outras equipes. Apoiar a resoluo de problemas - A anlise e a resoluo de problemas em ambientes distribudos requer que o processo de software incorpore atividades para notificar a existncia de um problema, divulgar a sua resoluo e identificar as possveis implicaes no trabalho das outras equipes. Incorporar um repositrio de terminologias - responsabilidade da organizao identificar, padronizar e documentar um glossrio sobre o domnio da aplicao do projeto, garantindo a compreenso nica dos termos pelas vrias equipes. Apoiar a redefinio de atividades do software - responsabilidade da organizao identificar, redefinir e controlar a execuo das atividades do processo de software, considerando as caractersticas e restries das equipes dispersas. A organizao deve estabelecer os procedimentos e a infraestrutura necessria para a realizao de tarefas de forma distribuda, tais como gerncia de configurao, especificao, projeto, codificao e testes, autoria e documentao, validaes, verificaes e revises.

Seguindo a tendncia de definio de processos em nveis, MAIDANTCHIK (1999) props um processo de software padro definindo uma estrutura nica a ser seguida por todos os grupos de trabalho em um desenvolvimento com equipes geograficamente dispersas que visa a atender aos requisitos citados anteriormente. Como base para construo desse processo, foi utilizada a norma ISO/IEC 12207. Pelo fato de ser um processo destinado s organizaes formadas por grupos geograficamente dispersos, o processo de aquisio foi substitudo pelo processo de definio do problema e o processo de contratao, pelo processo de planejamento. Alm disso, atividades especficas para o desenvolvimento distribudo foram adicionados ao processo padro (MAIDANTCHIK, 1999). De acordo com os requisitos citados anteriormente, necessrio definir um repositrio com informaes sobre as equipes de trabalho. Tal repositrio deve conter avaliaes das capacidades e caractersticas dos membros de cada grupo, e coleta de
32

dados e observaes de projetos anteriormente realizados. A organizao tambm deve estabelecer procedimentos para a gerncia do projeto, coordenao de atividades das equipes, controle de artefatos, comunicao entre os profissionais e instalar a infraestrutura necessria execuo do processo de software (MAIDANTCHIK, 1999). A Figura 2.6 mostra a estrutura do processo padro para equipes geograficamente distribudas proposto em (MAIDANTCHIK, 1999).

Figura 2.6 Estrutura do Processo Padro para Equipes Distribudas (MAIDANTCHIK, 1999).

2.5 Consideraes Finais do Captulo

Por ser um dos principais objetivos deste trabalho a definio de processos padro de qualidade para o Projeto ODE Livre, neste captulo, procurou-se conceituar o que processo de software e como esses processos podem ser definidos em nveis. Vale destacar que este trabalho est inserido no contexto do Laboratrio de Engenharia de Software (LabES) da UFES, que possui processos padro e especializados j definidos, o que conduziu especializao em outros nveis de processos padro com o objetivo de possibilitar a criao de projetos de software livre

33

por essa organizao. A partir desses processos especializados, instncias devero ser criadas por cada organizao ou indivduo que queira colaborar com o Projeto ODE Livre. Pelo fato da qualidade ser um requisito fundamental para os processos a serem definidos, foram estudadas as principais normas e modelos de qualidade de processo vigentes. Alm disso, outro ponto importante levantado neste captulo foi a caracterizao de um processo padro para equipes geograficamente dispersas. Esse processo uma referncia importante para a definio de processos padro para software livre por introduzir caractersticas comuns a esse tipo de software, tal como a disperso geogrfica dos desenvolvedores do sistema. Assim, este captulo apresentou o referencial terico referente a processos de software utilizado como base para o desenvolvimento deste trabalho. A essa base, foram adicionadas caractersticas do desenvolvimento de software livre, descritas no prximo captulo.

34

Captulo 3 Software Livre

Alavancado, principalmente pela crescente utilizao do Sistema Operacional livre Linux, o conceito de Software Livre (SL) ganhou espao tanto no meio acadmico quanto no mercado em geral. Uma das principais caractersticas de desenvolvimento deste tipo de software a disperso geogrfica dos profissionais que o produzem. Alm disso, produtos de Software Livre so caracterizados pela distribuio de seus cdigos fonte correspondentes e pela utilizao, na maioria das vezes, de mo-de-obra voluntria para seu desenvolvimento. Esses fatores podem fortalecer a desconfiana dos usurios desses produtos, necessitando, assim, que seu processo de desenvolvimento possua qualidade reconhecida em busca de maior credibilidade. Conforme discutido no captulo anterior, a qualidade do produto fortemente dependente da qualidade do processo utilizado para seu desenvolvimento. Assim, o caminho pela busca da qualidade de SL passa por processos de software livre de qualidade. Como a definio de processos de software deve levar em conta as caractersticas dos produtos a serem desenvolvidos, necessrio considerar atentamente as caractersticas especficas de SL, sobretudo no que diferem em relao a produtos de software desenvolvidos de maneira tradicional. O objetivo deste captulo explorar os conceitos envolvidos em Software Livre, licenas aplicveis a tais produtos de software, caractersticas especficas de seu desenvolvimento e apresentar exemplos de projetos de Software Livre que tm alcanado sucesso. O captulo est estruturado da seguinte forma: a seo 3.1 define o que Software Livre; a seo 3.2 mostra a importncia do licenciamento para produtos de software deste tipo e apresenta as principais licenas aplicadas; na seo 3.3 caractersticas prprias do desenvolvimento de Software Livre so exploradas; a seo 3.4 descreve brevemente alguns dos principais projetos de Software Livre; e, finalmente, na seo 3.5 so apresentadas as consideraes finais deste captulo.

35

3.1 O que Software Livre

Software Livre - SL (Free Software) o software disponvel com a permisso para qualquer um us-lo, copi- lo e distribu- lo, seja na sua forma original ou com modificaes, seja gratuitamente ou com custo. Em especial, a possibilidade de modificaes implica que o cdigo fonte esteja disponvel (HEXSEL, 2002). SL uma questo de liberdade, no de preo. Mais precisamente, se refere a quatro liberdades para seus usurios, a saber (FREE SOFTWARE FOUNDATION, 2006): 0. 1. Liberdade de executar o programa, para qualquer propsito; Liberdade de estudar como o mesmo funciona e adapt- lo para as suas necessidades; 2. 3. Liberdade de redistribuir cpias de modo a ajudar ao prximo; Liberdade de aperfeioar o programa e liberar os seus aperfeioamentos, de modo que toda a comunidade se beneficie. As liberdades 1 e 3 implicam na necessidade de se ter, pelo menos, acesso ao cdigo-fonte, apontado como a principal caracterstica de produtos de software livres. Na dcada de 1980, a idia de SL se popularizou, com a criao da Free Software Foundation FSF, por Richard Stallman. O movimento de SL nasceu de uma contestao aos mercados proprietrios mais poderosos da indstria de software, revelando todo um apelo poltico, institucional e emocional (SOFTEX, 2005a), e hoje um movimento slido. Produtos de software livres apresentam algumas caractersticas vantajosas peculiares, muitas vezes, resultantes do prprio processo de desenvolvimento dessa classe de produtos de software (NAKAGAWA, 2002), incluindo estabilidade, portabilidade para uma variedade de plataformas, acesso ao cdigo-fonte, suporte aos usurios por parte dos desenvolvedores, baixo custo e evoluo contnua, com verses mais novas do software sendo lanadas com maior freqncia e defeitos sendo corrigidos em um tempo menor do que em softwares proprietrios (DAVIS et al., 2000). Pelo seu carter cooperativo, propiciado principalmente pela distribuio do cdigo fonte, o desenvolvimento de SL feito por colaboradores dispersos

36

geograficamente, muitas vezes, ao redor do mundo. Por todas essas caractersticas, SL exige uma abordagem de desenvolvimento diferente da tradicionalmente empregada.

3.2 Licenciamento
O software pode ser considerado um produto como qualquer outro e, portanto, a nica forma de garantir sua proteo atravs do copyright. Uma pessoa que escreve um programa de computador detm o copyright sobre o mesmo. Isso permite que o autor controle a cpia, o uso e a adaptao do mesmo. Para disponibilizar o software para terceiros, o autor deve dar autorizao a eles para certas operaes. Isso chamado de licena. Dependendo dos desejos do autor, diferentes licenas padro podem ser adotadas, ainda que o autor possa tambm escrever sua prpria licena (ENGELFRIET, 2003). Assim, a licena de software um documento que estabelece a forma como o proprietrio do copyright permite a distribuio e cpia de um software. importante frisar que todo software livre deve ser registrado sob uma licena de software para que sua distribuio seja corretamente controlada e suas liberdades sejam protegidas, no ganhando, assim, caractersticas de um software de domnio pblico e evitando que abusos legais sejam cometidos. Existem vrias licenas disponveis para o registro desses softwares, tendo cada uma delas caractersticas prprias de distribuio (HEXSEL, 2002), a saber: GPL: A Licena Pblica Geral GNU (GNU General Public License - GPL) a licena que acompanha os pacotes distribudos pelo Projeto GNU e mais uma gama de produtos de software, incluindo o ncleo do sistema operacional Linux. A formulao da GPL tal que, ao invs de limitar a distribuio do software por ela protegido, ela, de fato, impede que esse software seja integrado a software proprietrio. A GPL baseada na legislao internacional de copyright, o que garante cobertura legal para o software licenciado com a GPL. Debian: A licena Debian (Debian Free Software Guidelines - DFSG) parte do contrato social celebrado entre o Projeto Debian e a comunidade de usurios de software livre. O Projeto Debian responsvel por uma distribuio de um Sistema Operacional Livre que contm o Linux como kernel, possuindo diversos pacotes prprios incorporados. Em essncia, essa
37

licena contm critrios para a distribuio que incluem, alm da exigncia da publicao do cdigo fonte, os seguintes: (a) a redistribuio deve ser livre; (b) o cdigo fonte deve ser includo e deve poder ser redistribudo; (c) trabalhos derivados devem poder ser redistribudos sob a mesma licena do original; (d) pode haver restries quanto redistribuio do cdigo fonte, se o original foi modificado; (e) a licena no pode discriminar qualquer pessoa ou grupo de pessoas, nem quanto a formas de utilizao do software; (f) os direitos outorgados no podem depender da distribuio onde o software se encontra; e (g) a licena no pode 'contaminar' outro software. Open Source: A licena do Open Source Initiative derivada da Licena Debian, com as menes Debian removidas. BSD: A licena BSD cobre as distribuies de software da Berkeley Software Distribution, alm de outros programas. Essa uma licena considerada 'permissiva', porque impe poucas restries sobre a forma de uso, alteraes e redistribuio do software licenciado. O software pode ser vendido e no h obrigaes quanto incluso do cdigo fonte, podendo, at mesmo, o mesmo ser includo em software proprietrio. Essa licena garante o crdito aos autores do software, mas no tenta garantir que trabalhos derivados permaneam como software livre. Creative Commons: um projeto que disponibiliza opes flexveis de licenas que garantem proteo e liberdade para artistas e autores de obras intelectuais, no se limitando a software. O Creative Commons define um espectro de possibilidades entre o direito autoral total todos os direitos reservados e o domnio pblico nenhum direito reservado, ou seja, permite ao autor manter seu direito autoral e, ao mesmo tempo, permite certos usos de sua obra um direito autoral de alguns direitos reservados. Existem seis licenas principais nesse projeto, sendo que a mais restritiva impede a distribuio comercial e a modificao da obra, e a menos restritiva exige somente que sejam atribudos os devidos crditos ao autor da obra (CREATIVE COMMONS, 2006).

38

3.3 Caractersticas de Desenvolvimento de Software Livre

Pelo seu carter cooperativo, propiciado principalmente pela distribuio do cdigo fonte dos programas, o desenvolvimento de Software Livre feito por colaboradores dispersos geograficamente, na maioria das vezes, ao redor do mundo. Essa forma de desenvolvimento exige uma abordagem de desenvolvimento diferenciada. O modelo de desenvolvimento de software tradicionalmente utilizado para produzir software proprietrio ou acadmico chamado por RAYMOND (1999) de Modelo Catedral. Sua caracterstica principal sua forma centralizada e controlada de desenvolver o software e a necessidade de uma pessoa (ou grupo de pessoas) que centralize o processo de desenvolvimento. Quando pensamos em software livre, o Modelo Catedral no adequado para seu desenvolvimento, principalmente pela disperso geogrfica dos inmeros desenvolvedores. Devido a esse fato, RAYMOND (1999) props a adoo de um modelo denominado Modelo Bazar para o desenvolvimento de SL, incluindo caractersticas peculiares, tais como: disponibilizao de cdigo fonte; envolvimento de diversos desenvolvedores, muitas vezes, voluntrios; disperso geogrfica dos mesmos em um processo colaborativo; tempo curto de desenvolvimento; e liberdade para os desenvolvedores escolherem o trabalho que desejam realizar. Vale apontar que esse modelo requer uma pessoa (ou grupo de pessoas) centralizando o processo. O Modelo Bazar tem sido aplicado com sucesso em diversos projetos, tais como os projetos do Linux e do Apache, apresentados na seo 3.4. Observa-se, contudo, que para se obter sucesso na sua utilizao, necessrio, ainda, ter (NAKAGAWA, 2002): um objetivo bem definido do que ser desenvolvido; uma motivao fcil de ser compreendida; um bom lder que mantenha os desenvolvedores motivados e o objetivo em mente; uma comunidade de participantes que trabalhe com entusiasmo e de forma descentralizada; e uma tecnologia que possibilite a comunicao de forma eficiente. Assim, o sucesso do Modelo Bazar no depende somente da disponibilizao do cdigo fonte, sendo necessrio organizar e coordenar todo o processo de forma apropriada. Apesar de interessante e muito til, o Modelo Bazar apenas uma referncia inicial para um processo de software livre, principalmente quando confrontado com normas e modelos de qualidade, tal como a ISO/IEC 12207. Sob a tica dessas normas e modelos, um processo de software pode ser definido como um conjunto de atividades,
39

mtodos, prticas, estruturas organizacionais, tecnologias e artefatos que so necessrios para conceber, desenvolver, entregar e manter um produto de software (FUGGETA, 2000). Assim, um processo eficaz deve considerar claramente as relaes entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessrios e a habilidade, o treinamento e a motivao do pessoal envolvido. Claramente, o Modelo Bazar no chega a esse nvel de definio. Na verdade, RAYMOND (1999) estava focado nas estruturas organizacionais e caractersticas de um projeto de SL, no estando diretamente preocupado com atividades, artefatos e procedimentos que um processo deveria seguir. At porque, processos tm de ser definidos caso a caso, levando em considerao caractersticas especficas do projeto em questo, incluindo as tecnologias envolvidas, o tipo de software a ser desenvolvido, o domnio da aplicao e a equipe de desenvolvimento (ROCHA et al., 2001). REIS (2003) procurou levantar e quantificar aspectos essenciais do processo de software utilizado nos projetos de software livre, discutindo questes como: De que forma os projetos de software livre trabalham para produzir software? Existe um processo comum entre os projetos de software livre? De que forma esses processos diferem do processo de software convencional documentado na literatura de engenharia de software? Dentre as concluses a que ele chegou em sua pesquisa, podem-se destacar: C1. Na maioria dos projetos de SL, a equipe trabalha de maneira descentralizada, envolvendo, muitas vezes, desenvolvedores que no se conhecem pessoalmente. Vale destacar, ainda, que nos ltimos anos esto ocorrendo mudanas neste perfil, com organizaes investindo na contratao de desenvolvedores para projetos de software livre. C2. Em grande parte dos projetos de SL, os desenvolvedores so tambm usurios do produto em desenvolvimento e contribuem efetivamente para determinar sua funcionalidade. C3. Existe, na maior parte dos projetos de SL, um sistema de liderana, sendo as formas mais utilizadas: lder com delegao informal, lder com delegao formal e comit.

40

C4.

H um uso amplo de ferramentas para viabilizar a comunicao entre membros da equipe geograficamente dispersa, com destaque para ferramentas de controle de verso e listas de correio eletrnico, alm de sistemas de acompanhamento de alterao / defeitos, servio de hospedagem de projetos e ferramentas de comunicao em tempo real. No que tange a ferramentas de desenvolvimento, sua utilizao aparece majoritariamente centrada em ferramentas de implementao.

C5. C6.

A maior parte dos projetos de SL possui equipe pequena. H indcios fortes do uso de conhecimento pr-existente para estabelecer os requisitos do projeto, seja por meio da reutilizao de levantamentos anteriores feitos por outras equipes, atravs de padres estabelecidos ou documentados, seja por replicar de maneira significativa um outro produto de software.

C7.

Parece existir muito pouco processo sistemtico em relao qualidade, incluindo testes. No h evidncias de uma poltica forte de controle e reviso relacionada aceitao, integrao e auditoria de contribuies. Contudo, ter seu trabalho constantemente sob olhar pblico, parece forar os desenvolvedores a encararem sua tarefa com ateno e padro de qualidade superiores. Assim, mesmo que o cdigo no seja revisado e auditado com freqncia, o fato de poder ser avaliado e publicamente criticado parece influenciar significativamente a atitude dos

desenvolvedores na construo de SL. C8. Pouca ateno dada usabilidade do software, o que, muitas vezes, leva produtos de software livres a ter uma reputao de complexo ou difcil de usar.

Alm das concluses de Reis sobre caractersticas de projetos de software livre, vale a pena destacar outras consideraes relatadas na literatura: C9. primeira vista no dada muita nfase especificao de requisitos (SCACCHI, 2002), seja porque a maioria dos projetos de software livre replica um software j existente ou por partirem de uma motivao pessoal do autor, trazendo requisitos implcitos (RAYMOUND, 1999). O conceito

41

de um documento de especificao de requisitos parece raro entre a comunidade de software livre, embora, existam especificaes formais descrevendo partes restritas de alguns sistemas mais complexos (REIS, 2003). C10. Na fase de projeto, os modelos so de mais alto nvel, no sendo possvel identificar uma arquitetura bem definida do sistema (VIXIE, 1999). Segundo REIS (2003), existe pouca documentao formal de projeto e provvel que grande parte do trabalho de descrever o projeto fique a cargo do prprio cdigo-fonte. C11. A melhor estratgia de lanamento de software livre disponibiliz-lo o quanto antes, de modo que ocorra um crescimento evolutivo por meio de sugestes e crticas dos usurios. Contudo, para que o software seja lanado, deve apresentar funcionalidade interessante o suficiente para atrair ateno (RAYMOUND, 1999). C12. Para que se alcance o sucesso, os participantes de projetos de software livre precisam ter sua contribuio reconhecida. C13. Projetos de software livre, geralmente, no so alvo de presses referentes a p razos, propiciando maior tranqilidade aos colaboradores e trabalhos mais elaborados. Alm disso, prazos no podem ser estabelecidos, pois um trabalho voluntrio. C14. A escolha, por parte dos desenvolvedores, do trabalho que desejam realizar, pode proporcionar sua motivao.

As caractersticas citadas acima so o resultado de um apanhado geral em torno dos principais projetos de software livre disponveis na Web. Alguns desses projetos so sucintamente apresentados na prxima seo.

3.4 Projetos de Software Livre

Existem milhares de projetos de software livre espalhados pelo mundo, sendo alguns ativos e outros inativos, alguns bem sucedidos e outros no. Esta seo descreve

42

alguns dos projetos de software livre que se destacam pela qualidade, grande nmero de usurios e colaboradores, a saber os projetos Linux (LINUX, 2006), Mozilla (MOZILLA, 2006) e Apache (APACHE, 2006). Contudo h muitos outros projetos importantes, tais como os projetos relacionados ao desenvolvimento dos bancos de dados MySQL (MYSQL, 2006) e PostgreSQL (POSTGRESQL, 2006) e das linguagens de programao PHP (PHP, 2006) e Perl (PERL, 2006)

3.4.1 O Projeto Linux

O Linux um sistema operacional que foi inicialmente criado como um hobby por um estudante jovem, Linus Torvalds, na universidade de Helsinki na Finlndia. Linus tinha interesse no Minix, um pequeno sistema UNIX, e decidiu desenvolver um sistema que excedia os padres do Minix. Comeou seu trabalho em 1991 e em 1994 liberou a verso 1.0 do Kernel do Linux. O Kernel, corao de todos os sistemas Linux, desenvolvido e liberado sob a licena GNU-GPL, tornando seu cdigo fonte disponvel livremente a qualquer um. Atualmente existem centenas de empresas, organizaes e indivduos que disponibilizam suas prprias verses de sistemas operacionais baseados no Kernel do Linux. A verso em que o Linux se encontra atualmente a de nmero 2.6 e o desenvolvimento continua (LINUX, 2006). Alm do fato de ser distribudo gratuitamente, a funcionalidade, adaptabilidade e robustez do Linux tm feito dele a principal alternativa aos sistemas operacionais proprietrios da Microsoft e UNIX. A IBM, a HP e outros gigantes da computao tm adotado o Linux e tm dado suporte ao seu desenvolvimento.

3.4.2 O Projeto Mozilla

O Projeto Mozilla um projeto livre dedicado ao desenvolvimento de ferramentas relacionadas ao navegador Web Mozilla. Desde a sua criao em 1998, o projeto atraiu milhares de participantes e possui uma das maiores comunidades colaboradoras de um projeto de software livre atualmente (MOZILLA, 2006). Apesar do produto principal ser um navegador, o Projeto Mozilla possui vrios subprojetos relacionados. O projeto desenvolvido e acompanhado por uma organizao prpria que responsvel pela gerncia, planejamento e suporte para o desenvolvimento do mesmo.
43

Em linhas gerais, essa organizao responde pelo processo de desenvolvimento do Mozilla. Os membros que compem essa organizao so voluntrios e profissionais de organizaes diferentes, sendo que os mais assduos e melhor preparados possuem privilgios e posies de mais destaque na organizao (REIS, 2003). O fato de ter sido originado de um projeto proprietrio trouxe algumas caractersticas importantes para a evoluo necessria no processo de desenvolvimento. Uma das principais contribuies dessa evoluo foi a criao e utilizao de um conjunto de ferramentas livres para o apoio do processo adotado, conforme discutido com mais detalhes no Captulo 5.

3.4.3 O Projeto Apache

O Projeto Apache, dedicado ao desenvolvimento e manuteno de um servidor http livre, seguro e eficiente para sistemas operacionais modernos, foi iniciado em fevereiro de 1995, resultado de um esforo combinado para coordenar manutenes no programa de httpd NCSA desenvolvido por Rob McCool. Depois de passarem vrios meses adicionando funcionalidades e corrigindo pequenos erros, os desenvolvedores do Apache substituram o cdigo do servidor antigo em julho de 1995 por uma nova arquitetura projetada por Robert Thau. Depois disso, todas as antigas e novas funcionalidades foram traduzidas para a nova arquitetura e foram disponibilizadas para testes, resultando na disponibilizao formal do Apache httpd 1.0 em janeiro de 1996. O processo de desenvolvimento de software do Apache resultado tanto da natureza do projeto quanto do conhecimento dos lderes de projeto. O Projeto Apache j comeou com uma tentativa consciente de resolver os problemas de processo primeiro, antes mesmo de iniciar o desenvolvimento, porque estava claro, desde o incio, que conjuntos de desenvolvedores geograficamente dispersos, sem nenhum vnculo organizacional, necessitariam de um nico processo de desenvolvimento para poderem tomar decises (MOCKUS et al., 2002). Um estudo realizado em (MOCKUS et al., 2002) comprovou algumas das hipteses relacionadas s caractersticas de desenvolvimento no Projeto Apache, por meio de estudos de casos. Dentre elas, destaca-se a hiptese de que o desenvolvimento de software livre envolve um grupo principal de desenvolvedores, que controla a base de cdigo. Esse grupo possui, no mximo, de 10 a 15 pessoas e cria aproximadamente 80% ou mais das novas funcionalidades do software. Outra hiptese relacionada
44

anterior a de que, se o projeto to grande que o nmero de pessoas do grupo principal no capaz de desenvolver 80% do cdigo num espao de tempo razovel, ento novos grupos devem participar do desenvolvimento. Porm, o trabalho deve ser subdivido em vrios projetos. Por fim, hiptese desse estudo, tambm, o fato de que em projetos de software livre bem sucedidos, um grupo maior que o grupo principal em uma ordem de magnitude corrige os erros, e um grupo maior ainda (por outra ordem de magnitude) reporta problemas.

3.5 Concluses do Captulo

Software Livre possui conceitos bem particulares quando confrontado com produtos de software tradicionais, tanto em termos polticos, econmicos e legais, mas principalmente culturais. Dentre as inovaes trazidas comunidade de software, o Software Livre trouxe novas formas de se licenciar software, dentre elas, a Licena Pblica Geral GNU. Como no poderia ser diferente, dadas as mudanas conceituais, Software Livre traz novos desafios comunidade no que se refere forma de desenvolver software, trazendo caractersticas e necessidades, antes no evidenciadas. Neste captulo foram apresentados os conceitos envolvidos no desenvolvimento de SL e caractersticas dos principais projetos de SL, que foram fundamentais para a realizao deste trabalho. Assim, as informaes relatadas neste captulo, reunidas aos conceitos de qualidade discutidos no captulo anterior foram a base para a definio de processos padro de desenvolvimento e manuteno de software livre apresentados no prximo captulo.

45

Captulo 4 Processos Padro para Software Livre

O Laboratrio de Engenharia de Software (LabES) da Universidade Federal do Esprito Santo (UFES) vem conduzindo desde 1999 o Projeto ODE (FALBO et al., 2003), inicialmente denominado Projeto ADS (MIAN et al., 2001), que visa ao desenvolvimento de um Ambiente de Desenvolvimento de Software (ADS) Centrado em Processo. Desde ento, o ambiente vem amadurecendo e no final de 2004 foi implantado experimentalmente em uma organizao de software parceira do LabES para avaliao de sua adequao a organizaes de software reais. Dado seu estgio atual em termos de funcionalidades, aliado sua origem acadmica, um caminho de evoluo natural para o Projeto ODE a sua liberao como software livre (SL), permitindo, assim, que a comunidade de software possa se beneficiar com o uso de um ADS livre, dado que existem poucos ambientes dessa natureza disponveis e que a grande maioria dos ADSs disponveis no mercado tm suas licenas disponibilizadas por preos muito altos, o que inviabiliza sua compra pela maioria das organizaes de software de pequeno e mdio porte. Surge, assim, o Projeto ODE Livre. Pelas razes expostas acima, a disponibilizao de ODE como software livre tende a chamar a ateno da comunidade de Engenharia de Software, tanto para sua utilizao como para a colaborao. Mesmo que haja algum custo para sua obteno, tal custo tende a ser muito baixo, dada a possibilidade de fcil distribuio a custo zero proporcionada pela poltica do software livre. Uma questo importante a ser observada nessa nova etapa do Projeto ODE est relacionada a como garantir que a qualidade do ambiente no ser afetada por essa nova modalidade de desenvolvimento. Visando tratar essa questo, decidiu-se definir processos de software padro a serem adotados no Projeto ODE Livre. A idia que cada contribuio feita ao ambiente seja tratada como um projeto que deve instanciar, a partir dos processos padro definidos para o Projeto ODE Livre, um processo de software adequado s suas caractersticas.
46

A base terica para a definio desses processos padro foi levantada nos captulos anteriores e o foco deste captulo a apresentao dos processos padro definidos para software livre a serem aplicados no Projeto ODE Livre. Assim, este captulo est estruturado da seguinte forma: a seo 4.1 aborda brevemente o tema Ambientes de Desenvolvimento de Software; a seo 4.2 apresenta o Projeto ODE em linhas gerais; na seo 4.3 apresentada a abordagem adotada para a transformao de ODE em um ADS Livre; na seo 4.4 os processos padro do LabES so brevemente apresentados; na seo 4.5 so descritas caractersticas dos processos padro definidos para apoiar o Projeto ODE Livre; a seo 4.6 trata da definio da licena sob a qual o ambiente ODE ser disponibilizado; e, finalmente, na seo 4.7 so apresentadas as consideraes finais do captulo.

4.1 Ambientes de Desenvolvimento de Software

Um dos grandes desafios da Engenharia de Software a automatizao de partes do processo de software. Com este objetivo, vrias ferramentas para apoiar o engenheiro de software na construo dos seus produtos j foram e continuam sendo desenvolvidas. Contudo, importante que essas ferramentas sejam capazes de se comunicar para que possam fornecer apoio integrado s vrias atividades do processo de software. Essa necessidade de integrao fez surgir os Ambientes de Desenvolvimento de Software (ADSs). Um ADS pode ser visto como uma coleo de ferramentas integradas que facilita as atividades da engenharia de software, durante todo o ciclo de vida do software ou pelo menos em pores significativas dele. ADSs possuem o objetivo de interferir positivamente no tempo de desenvolvimento, no custo e na qualidade de um projeto (HARRISON et al., 2000). Os ADSs combinam diferentes ferramentas, com diferentes informaes e possibilitam a comunicao entre elas, objetivando a troca de informaes e evitando inconsistncias. Entre os benefcios de um ADS, podem ser citados (PRESSMAN, 2002): A transferncia harmoniosa de informaes entre ferramentas e entre etapas de engenharia de software; Reduo do esforo exigido para realizar certas atividades, tal como o gerenciamento de configurao de software;

47

Apoio produo de documentao; Aumento no controle do projeto, uma vez que possvel haver melhor planejamento, monitorao e comunicao;

Melhor coordenao entre os membros de uma equipe que estejam trabalhando em um grande projeto de software.

Existem vrios nveis de integrao de ferramentas. Dentre eles, podem ser citados (TRAVASSOS, 1994) (FALBO, 1998) (PFLEEGER, 2001): Integrao de Dados: A chave para integrar ferramentas a habilidade de compartilhar informaes de projeto. Integrao de Apresentao: A integrao de apresentao tem como objetivo tornar as interfaces do ADS consistentes, permitindo que o usurio utilize as ferramentas, alternando de uma para outra, sem sofrer um impacto na interface. Os componentes utilizados devem ser os mesmos, com as mesmas funcionalidades, no havendo a necessidade de aprender como utilizar cada ferramenta. A partir do momento que se aprende uma, consegue-se trabalhar mais facilmente com as outras. Integrao de Processo: Para integrar um conjunto de ferramentas, preciso ter um foco forte no gerenciamento do processo. Engenheiros de software tm se tornado mais orientados a processos, usando mtodos, tcnicas e ferramentas para controlar e guiar seu trabalho. Integrao de Controle: As ferramentas devem ser capazes de notificar umas s outras sobre eventos, ativar outras ferramentas e compartilhar funes. Mecanismos de integrao de controle incluem a passagem explcita de mensagens, gatilhos ativados por tempo ou acesso, e servidores de mensagens. Integrao de Conhecimento: Com o aumento da complexidade dos processos de software, faz-se necessrio considerar informaes de natureza semntica, sem as quais a integrao no plenamente obtida. O conhecimento, assim como os dados, deve estar disponvel e representado de forma nica no ambiente, de forma a poder ser acessado por todas as ferramentas que dele necessitarem, evitando redundncia e inconsistncias. Integrao de Plataforma: Diz respeito capacidade do ADS funcionar em

48

diferentes plataformas de software e de hardware. A prtica de desenvolvimento de software independente de plataforma e, portanto, interessante que as ferramentas utilizadas no desenvolvimento tambm sejam.

As dimenses de integrao anteriormente citadas so importantes para o desenvolvimento de quaisquer ADSs, seguindo qualquer modelo de desenvolvimento. Porm, merecem ateno especial quando se fala em desenvolvimento de um ADS livre. Isso se deve ao fato dos colaboradores de projetos de software livre estarem dispersos geograficamente, podendo estar localizados em organizaes com metodologias e culturas diferentes. Dadas tais dificuldades, a comunicao e o processo devem ser capazes de favorecer que padres de integrao sejam respeitados por quaisquer colaboradores ao redor do mundo, uma vez que uma violao a esses padres pode acarretar a no aceitao de uma colaborao para um projeto. Como exemplo, pode-se citar a importncia da integrao de apresentao para um ADS. Caso um colaborador no siga os padres de interface determinados para o mesmo, sua colaborao tende a ser descartada pelo grupo coordenador do projeto de tal ADS.

4.2 O Projeto ODE

Conforme discutido anteriormente, em um ADS as ferramentas precisam estar bem integradas para que haja um compartilhamento de informaes eficiente. Para tal, importante que as ferramentas tenham um entendimento comum a respeito dos principais conceitos envolvidos em Engenharia de Software. A conceituao comum necessria para que esse compartilhamento possa ser alcanado em um ambiente pode ser obtida atravs do uso de ontologias. ODE (Ontology-based software Development Environment) (FALBO et al., 2004) um ADS Centrado em Processo que tem sua fundamentao em ontologias. Um ADS Centrado em Processo um ambiente que suporta a definio de processos de software, utilizando-se desta para estabelecer uma ligao explcita entre ferramentas do ambiente e os processos definidos (integrao de processo) (BERTOLLO et al., 2002).

49

A interao das ferramentas em ODE facilitada pelo fato destas serem construdas tomando por base as mesmas ontologias. Isso significa que os principais conceitos manipulados pelas ferramentas esto bem definidos, dado que a mesma ontologia pode ser utilizada para construir diferentes ferramentas dando apoio a atividades relacionadas da Engenharia de Software. O Projeto ODE est em desenvolvimento no Laboratrio de Engenharia de Software da Universidade Federal do Esprito Santo (LabES/UFES) desde 1999, motivado pela existncia de poucos ambientes desse tipo disponveis. ODE vem sendo desenvolvido no meio acadmico, sendo o resultado do esforo conjunto de vrios alunos de graduao e mestrado. Ele implementado em Java, com persistncia em banco de dados relacional PostgreSQL. Com o amadurecimento do trabalho, em 2004, foi possvel experimentar sua aplicao prtica. Para tal, foi feita uma parceria com uma organizao de software visando test- lo num ambiente corporativo. Dessa interao universidade-empresa, diversas sugestes foram dadas e uma nova verso de ODE foi desenvolvida e implantada em maro de 2006 nessa organizao. Nessa ltima verso, ODE possui ferramentas para apoiar a definio do escopo de um projeto de software (ARANTES, 2006), a definio de processos (incluindo processos padro, especializados e de projeto) (BERTOLLO, 2006), a alocao de recursos (SCHWAMBACH, 2002), a realizao de estimativas (ARANTES, 2006), a gerncia de riscos (FALBO et al., 2004), a gerncia de requisitos (FREITAS et al., 2006) e o acompanhamento de projetos (DAL MORO et al., 2005). Outras ferramentas, j desenvolvidas ou em desenvolvimento, esto sendo integradas a ODE e h previso para a distribuio de uma nova verso do ambiente em outubro de 2006, incluindo melhorias nas ferramentas citadas, uma ferramenta de apoio modelagem UML e um sistema de gerncia de conhecimento. Dado o objetivo de transformar ODE em um software livre e a importncia da comunicao entre colaboradores do Projeto pela Internet, seria ideal que algumas ferramentas de ODE pudessem ser disponibilizadas na Internet para que apoiassem o desenvolvimento de ODE. Ou seja, usando os processos padro de desenvolvimento e manuteno de ODE Livre, as prprias ferramentas de ODE poderiam ser usadas para apoiar o processo definido para o projeto do colaborador.

50

4.3 Em Direo a ODE Livre

O LabES um laboratrio de pesquisa e ensino em Engenharia de Software, no qual h vrios projetos de software em andamento, sobretudo no contexto de projetos de pesquisa, ainda que alguns projetos sejam contratados por organizaes externas. Visando colocar em prtica o que ensinado, o LabES adota uma poltica de desenvolvimento de software com qualidade, seguindo o preceito de que a qualidade do produto pode ser mais facilmente obtida se o mesmo for desenvolvido segundo um processo de qualidade. Assim, tomando por base modelos e normas de qualidade, principalmente a norma ISO/IEC 12207 (ISO, 1998) e o modelo de referncia do MPS.BR (SOFTEX, 2006b), foi definido um processo padro para o LabES. Alm desse processo, seguindo uma abordagem de definio de processos em nveis (ROCHA et al., 2001), foram definidos processos especializados para os paradigmas orientado a objetos e estruturado, seguindo a abordagem discutida no Captulo 2 e mostrada na Figura 2.1. Essa abordagem se caracteriza pela existncia de um processo padro da organizao, processos padro especializados a partir do processo padro da organizao e processos instanciados ou de projeto. No caso do LabES, o processo raiz o Processo Padro LabES (PPLabES). A partir dele, so especializados os Processos Padro LabES Orientado a Objetos (PPELabES-OO) e Estruturado (PPELabES-Est), a partir dos quais so instanciados os processos de projeto. O principal projeto desenvolvido pelo LabES o Projeto ODE, caracterizado na seo anterior. Pela variada gama de ferramentas existentes em ODE, pode-se notar que o projeto de um ADS no uma tarefa simples. H muitas ferramentas potencialmente teis a serem desenvolvidas e, alm disso, organizaes diferentes podem necessitar customizar algumas dessas ferramentas para melhor adequ- las sua forma de trabalho. Assim, o modelo de software livre passou a ser considerado potencialmente interessante para a evoluo do projeto, dando origem ao Projeto ODE Livre. Pensando ODE como software livre, a comunidade poderia se privilegiar de um ADS poderoso e, em contrapartida, o LabES contaria com a ajuda da comunidade para torn- lo um ambiente mais completo e que atendesse melhor s necessidades de vrias organizaes. Conforme discutido no captulo anterior, muitas das caractersticas requeridas para o sucesso de um projeto de software livre se aplicam ao Projeto ODE, tais como: (i) usurios do produto podem contribuir efetivamente para determinar sua funcionalidade,

51

podendo vir a se interessar em se tornar tambm desenvolvedores; (ii) a liderana do projeto pode ser exercida pelo LabES, de forma compartilhada por seus membros, ficando um membro ou um grupo de pessoas responsvel por analisar as contribuies enviadas para uma ferramenta ou funcionalidade do sistema; (iii) o ambiente ODE j tem funcionalidade interessante o suficiente para atrair a ateno da comunidade de desenvolvimento de software, como pode ser comprovado pela sua implantao em uma organizao de desenvolvimento de software; (iv) o LabES continuar fornecendo desenvolvedores para o projeto, sendo importante fora de trabalho para o projeto, mas novas instituies, sejam de ensino, sejam de mercado, podero se engajar ao projeto. Por exemplo, muitos ex- integrantes do LabES podem levar o ambiente para suas novas organizaes, tornando-se colaboradores (SILVA et al., 2006). Contudo, algumas caractersticas do Projeto ODE Livre so um pouco diferentes da maioria dos projetos de software livre (SILVA et al., 2006). Primeiro, como h poucos ambientes deste tipo disponveis, geralmente de difcil acesso, bem como no h padres documentados para a maior parte das ferramentas de um ADS, ateno especial tem de ser dada atividade de levantamento de requisitos, inclusive no que tange elaborao de um documento formal de especificao de requisitos. Segundo, usabilidade uma caracterstica de qualidade essencial para um ADS. Assim, esse aspecto tem que ser cuidadosamente tratado. De fato, por um ADS estar muito em linha com o desenvolvimento de software de qualidade, natural que o Projeto ODE tenha um cuidado especial em relao qualidade e, portanto, padres devem ser estabelecidos e dever ser verificada a conformidade das contribuies a esses padres. Por fim, dado que um ADS um sistema muito complexo, em que a integrao de ferramentas uma questo fundamental, a documentao de sua arquitetura e do projeto de suas ferramentas vital para a evoluo do ambiente. Tendo em vista as caractersticas que aproximam e afastam o Projeto ODE da prtica corrente do movimento de software livre, procurou-se chegar a uma abordagem prpria para o desenvolvimento do Projeto ODE Livre. Essa abordagem consiste na definio de processos padro para software livre a serem seguidos pelos colaboradores do projeto. Esses processos foram definidos tomando por base os processos padro do LabES, seguindo a abordagem de definio de processos em nveis, como ilustra a Figura 4.1.

52

Normas e Modelos de Qualidade (ISO/IEC 12207, IEEE 1219, MPS.BR), Cultura Organizacional

Definio

Processo Padro LabES (PPLabES)

Paradigma

Especializao

Processo Especializado para Desenvolvimento OO (PPELabES-OO)

Processo Especializado para Desenvolvimento Estruturado (PPELabES- Estruturado)

Caractersticas de Desenvolvimento de Software Livre

Especializao

Processo Especializado para o Desenvolvimento de Software Livre (PPELabES-SL)

Particularidades do Projeto, Modelo de Ciclo de Vida (ou Modelo de Processo)

Instanciao

Processo de Projeto A

Processo de Projeto B

Processo de Projeto C

Figura 4.1 Definio de Processos em Nveis e o Projeto ODE Livre.

Como o Projeto ODE desenvolvido segundo o paradigma orientado a objetos, os processos padro para software livre foram definidos como especializaes dos processos j especializados para esse paradigma (PPELabES-OO). A idia que, para que uma contribuio seja incorporada ao ambiente ODE, ela ter de ser desenvolvida segundo um processo em conformidade com os processos padro para software livre do LabES. Ou seja, processos tm que ser instanciados a partir dele, para cada sub-projeto de contribuio, levando-se em conta as caractersticas desse sub-projeto e da organizao colaboradora. Antes de apresentar os processos padro para software livre definidos, importante apresentar a estrutura de processos padro do LabES, uma vez que muitos elementos so diretamente reutilizados desses processos.

53

4.4 Processos Padro do LabES

O Processo Padro do LabES (PPLabES) era originalmente estruturado em duas categorias de processos Processos Fundamentais e Processos de Apoio e continha quatro sub-processos (Processo de Desenvolvimento de Software, Processo de Gerncia de Projetos, Processo de Garantia da Qualidade e Processo de Gerncia de Configurao), como representado na Figura 4.2. Suas atividades eram descritas com base em cinco itens: 1. Entradas: artefatos de insumo para a atividade. 2. Recursos Humanos: papis das pessoas envolvidas na atividade. 3. Sadas: artefatos produzidos pela atividade. 4. Ferramentas: apoio ferramental atividade. 5. Procedimentos: mtodos, tcnicas, modelos de documento, roteiros e outros procedimentos adotados na realizao da atividade. O processo padro organizacional tinha duas especializaes: Processo Padro LabES Especializado para o Desenvolvimento Orientado a Objetos (PPELabESOO) e Processo Padro LabES Especializado para o Desenvolvimento Estruturado (PPELabES-Estruturado). Esses processos especializados refinavam as atividades de anlise de requisitos e projeto para os respectivos paradigmas.

Processos de Apoio Processos Fundamentais Processo de Desenvolvimento Levantamento e Anlise de Requisitos Projeto Implementao e Teste de Unidade Testes de Integrao e Validao Liberao do Produto Processo de Garantia da Qualidade

Processo de Gerncia de Configurao

Processo de Gerncia de Projetos Planejamento de Projeto

Definio do Escopo do Projeto Definio do Processo do Projeto Realizao de Estimativas Gerncia de Riscos Elaborao do Plano de Projeto

Acompanhamento de Projeto Encerramento de Projeto

Figura 4.2 Estrutura Original dos Processos Padro do LabES.

54

Durante a elaborao deste trabalho, o PPLabES foi revisado, melhorado e a descrio de suas atividades passou a ser feita nos moldes definidos no MPS.BR. Esta deciso foi tomada depois de um estudo feito sobre o MPS.BR-MR, pois se deseja uma aderncia ao mesmo. Vale destacar que durante a atualizao do Processo Padro LabES, buscando aderncia ao MPS.BR, os processos foram agrupados em trs categorias: Processos Fundamentais, incluindo os processos de desenvolvimento e manuteno, Processos de Apoio, englobando os processos de garantia da qualidade e gerncia de configurao, e Processos Organizacionais, que inclui o processo de gerncia de projetos, como mostra a Figura 4.3.

Processos Fundamentais Processo de Desenvolvimento Levantamento e Anlise de Requisitos Projeto Implementao e Teste de Unidade Testes de Integrao e Validao Liberao do Produto

Processos de Apoio Processo de Garantia da Qualidade

Processo de Gerncia de Configurao

Processos Organizacionais Processo de Gerncia de Projetos Planejamento de Projeto

Definio do Escopo do Projeto Definio do Processo do Projeto Realizao de Estimativas Gerncia de Riscos Elaborao do Plano de Projeto

Processo de Manuteno Identificao do Problema Levantamento e Anlise de Requisitos Projeto Implementao e Teste de Unidade Testes de Integrao e Validao Liberao do Produto

Acompanhamento de Projeto Encerramento de Projeto

Figura 4.3 Estrutura Bsica dos Processos Padro do LabES Atualizada.

Esses processos esto definidos em termos de atividades e sub-atividades e, para cada atividade, so definidos, ainda: nome, descrio, critrios de entrada e sada, responsveis, participantes, artefatos requeridos e produzidos, pr e ps-atividades, ferramentas, procedimentos, resultados esperados (em termos dos resultados esperados definidos no MPS.BR), observaes e um indicador da necessidade de execuo (obrigatrio, fortemente recomendado, recomendado, desejvel). A Figura 4.4 mostra o detalhamento para a atividade Definir Processo de Projeto do Processo de Gerncia de Projetos.

55

Nome Descrio Critrios Entrada Sada Responsvel(is) Organizao Papel(is) Participantes Organizao Papel(is) Artefatos Requeridos Artefatos Gerados Pr-atividade Ps-atividade Sub-atividades Ferramentas Procedimentos Indicador de Execuo Resultados Esperados

Definir Processo de Projeto Um dos processos padro do LabES deve ser instanciado para o projeto em questo e adequado a ele. Escopo definido Processo de Projeto LabES Gerente de Projeto LabES Analista de Sistemas Escopo do Projeto, Caractersticas do Projeto e Processo Padro LabES ou alguma de suas especializaes Processo de Projeto Definir Escopo do Projeto Realizar Estimativas Ferramenta de Apoio Definio de Processos Obrigatrio DFP (Definio do Processo Organizacional) 5 - So desenvolvidas estratgias para adaptao do processo-padro de acordo com as necessidades dos projetos.

Observaes Figura 4.4 Detalhamento da atividade Definir Processo de Projeto do Processo de Gerncia de Projetos do Processo Padro LabES.

Alm da reviso dos processos existentes, neste trabalho foi elaborado o Processo Padro de Manuteno do LabES. Esse processo est descrito tambm nos moldes do MPS.BR e seus processos e atividades so aderentes norma IEEE 1219 (IEEE, 1998). Esse processo foi inserido na categoria de Processos Fundamentais, como mostra a Figura 4.3. Na seo que se segue, so discutidas as principais caractersticas do processo padro especializado para software livre definido e os fatores que motivaram a incluso dessas caractersticas no processo.

56

4.5 Processos Padro para Projetos de Software Livre

O estudo para a definio do Processo Padro Especializado LabES para Software Livre (PPELabES-SL) comeou por um exame de caractersticas relevantes de produtos livres e por uma avaliao de quais processos do MPS.BR se aplicariam a um processo desse tipo. A seguir, procuraram-se encontrar no Processo Padro do LabES (PPLabES) os elementos de processo correspondentes, visando a compatibilidade. Tendo em vista que um objetivo do LabES manter seus processos em linha com as diretrizes do MPS.BR, a definio do PPELabES-SL serviu de base, tambm, para a melhoria do PPLabES, que passou a incorporar algumas das recomendaes do MPS.BR ainda no tratadas. Conforme discutido no Captulo 2, o modelo de referncia do MPS.BR (SOFTEX, 2006b) define 21 processos, agrupados em trs categorias: Processos Fundamentais: Aquisio, Gerncia de Requisitos, Desenvolvimento de Requisitos, Soluo Tcnica e Integrao do Produto. Processos de Apoio: Garantia da Qualidade, Gerncia de Configurao, Validao, Verificao, Medio e Anlise de Deciso e Resoluo. Processos Organizacionais: Gerncia de Projeto, Definio do Processo Organizacional, Adaptao do Processo para Gerncia de Projeto, Avaliao e Melhoria do Processo Organizacional, Gerncia de Riscos, Treinamento, Gerncia Quantitativa do Projeto, Desempenho do Processo Organizacional, Anlise de Causas e Resoluo e Implantao de Inovaes na Organizao. Esses processos so organizados em sete nveis crescentes de maturidade (G a A), sendo que, inicialmente, foram considerados apenas os processos dos quatro primeiros nveis (G a D), uma vez que esses nveis j proporcionam um elevado nvel de qualidade. Assim, foi avaliada a aplicabilidade a software livre dos seguintes processos: Gerncia de Projeto e Gerncia de Requisitos (nvel G), Garantia da Qualidade, Aquisio, Gerncia de Configurao e Medio (nvel F), Adaptao do Processo para Gerncia de Projeto, Definio do Processo Organizacional, Avaliao e Melhoria do Processo Organizacional e Treinamento (nvel E) e Desenvolvimento de Requisitos, Soluo Tcnica, Integrao do Produto, Verificao e Validao (nvel D).

57

Todos esses processos foram considerados aplicveis e suas atividades foram classificadas, segundo a importncia de seus resultados esperados, em: obrigatria, fortemente recomendvel, recomendvel e desejvel. Atividades obrigatrias devem ser executadas e os artefatos por elas produzidos tm de ser entregues como parte da contribuio para que a mesma seja aceita. Para facilitar sua realizao, ferramentas de apoio devero ser providas. Atividades fortemente recomendveis, ainda que no obrigatrias, tambm so muito importantes e ser incentivada a sua realizao, provendo-se ferramentas de apoio. Para as demais atividades, inicialmente, no ser provida nenhuma facilidade nem ser exigida nenhuma evidncia de sua realizao, ainda que as mesmas estejam definidas no processo. Algumas das atividades do processo ficaro sob responsabilidade do colaborador, ou seja, do indivduo ou organizao que esteja trabalhando uma contribuio, e outras ficaro sob responsabilidade da organizao que detm o controle do projeto, no caso, o LabES. Assim, informaes sobre a responsabilidade de execuo do processo / atividade tambm foram definidas. Visando tornar o processo mais enxuto para os colaboradores, processos que so integralmente de responsabilidade do LabES no foram incorporados ao PPELabES-SL. Este o caso dos processos de Definio do Processo Organizacional e Avaliao e Melhoria do Processo Organizacional. No que tange ao processo de aquisio, vale destacar que, nos sub-projetos do Projeto ODE Livre, um novo projeto de desenvolvimento ou manuteno se iniciar a partir da demanda de um usurio de ODE que registrar sua crtica ou sugesto (bug no sistema, oportunidade de melhoria, sugesto de nova funcionalidade etc) no Portal do Projeto. Algumas vezes, esse usurio tambm vai ser o colaborador responsvel pelo desenvolvimento de sua prpria requisio, mas acredita-se que, na maioria das vezes, outro colaborador desenvolver um novo projeto baseado nos requisitos deixados pelo usurio idealizador. Esses fatores comprovam a falta de uma identificao clara da relao cliente/fornecedor para projetos de software livre, levando simplificao deste processo. Apesar disso, critrios para aceitao e seleo de contribuies so fortemente recomendveis. Pelas caractersticas de software livre, o Processo de Treinamento, ainda que considerado desejvel, no foi definido, uma vez que cabe a cada organizao definir como tratar essa questo. Tutoriais sobre Engenharia de Software e sobre como realizar atividades do processo podem ser disponibilizados no Portal do Projeto. Essa poro do Processo de Treinamento, contudo, ficaria a cargo do LabES e, por isso, no foi includa
58

no processo. No caso do treinamento de usurios, material de apoio tambm deve ser produzido e disponibilizado no Portal do Projeto. Estuda-se a criao de um wiki (WIKI, 2006) voltado ao Projeto ODE e conhecimentos relacionados a Engenharia de Software importantes para o uso de ODE. Os Processos de Gerncia de Projeto e Adaptao do Processo para Gerncia de Projeto foram tratados como um processo nico, denominado Processo de Gerncia de Projetos, composto das seguintes atividades, tomando por base o processo padro LabES: Planejamento de Projeto, Acompanhamento de Projeto e Encerramento de Projeto. A atividade de Planejamento de Projeto decomposta nas seguintes subatividades: Definio do Escopo do Projeto (obrigatria), Definio do Processo de Projeto (obrigatria), Realizao de Estimativas (fortemente recomendvel), incluindo estimativas de tamanho e esforo, alocao de recursos e elaborao de cronograma, Gerncia de Riscos (desejvel) e Elaborao do Plano de Projeto (obrigatria). No acompanhamento, as atividades do planejamento so realizadas novamente, sendo que um relatrio de acompanhamento deve ser elaborado. O encerramento inclui anlises post-mortem. Todas essas atividades so realizadas pelo colaborador, com exceo do encerramento que pode envolver tambm membros do LabES. Ainda no que se refere Gerncia de Projetos, julgou-se que, geralmente, no se aplica a software livre atividades relacionadas a planejamento e acompanhamento de custos, tendo em vista que, por princpio, o desenvolvimento de software livre tende a no prever custo financeiro. Vale destacar, ainda, que a realizao de estimativas considerada apenas fortemente recomendvel, e no obrigatria, pela inexistncia de prazos fixos para um projeto de software livre. Cabe ao colaborador gerenciar seu tempo, ainda que estimativas de tamanho, esforo e tempo, juntamente com o cronograma do projeto, facilitem a organizao e a viabilidade do projeto. No Processo de Medio, toda a parte de definio de mtricas deve ficar a cargo do LabES, bem como a definio das atividades de medio e a anlise dos resultados. Caberia s organizaes colaboradoras apenas a coleta dos dados, bem como o uso dessas informaes para apoiar suas decises. Para tal, muito importante prover ferramentas de apoio para que esse processo se torne vivel, incluindo um sistema de gerncia de conhecimento. Assim, optou-se por postergar a introduo desse processo para uma futura melhoria do PPELabES-SL. De fato, esse processo no foi incorporado ao PPLabES.

59

O s d e mais processos foram todos considerados muito importantes e incorporados ao PPELabES-SL. Visando simplicidade e para manter a compatibilidade com o PPLabES, os processos de Garantia da Qualidade, Verificao e Validao foram agrupados em um nico processo, denominado Processo de Garantia da Qualidade. Assim, o processo de garantia da qualidade proposto envolve atividades de verificao e validao, incluindo a garantia da conformidade a padres e reviso conjunta. Vale destacar que no mbito da definio deste processo, diversos modelos de documento foram propostos, tais como Modelo de Plano de Projeto, Modelo de Especificao de Requisitos e Padro de Codificao, e, portanto, verificar a aderncia a esses padres fundamental. Assim, as atividades desses processos devero ser realizadas tanto pelos colaboradores quanto pelos membros do LabES, durante a avaliao de uma contribuio. O Processo de Gerncia de Configurao de extrema importncia para os projetos de software livre. Os itens de configurao devem ser muito bem controlados, pois disso depende o sucesso do projeto de software livre. Os colaboradores devem ter acesso aos itens para poderem colaborar efetivamente e as verses de cada item devem ser controladas e documentadas de modo a evitar retrabalho e para permitir um bom entendimento por parte dos colaboradores. Os demais processos Gerncia de Requisitos, Desenvolvimento de Requisitos, Soluo Tcnica e Integrao do Produto foram todos incorporados a um processo de engenharia. Na verdade, seguindo o PPLabES, foram definidos dois processos de engenharia: um Processo de Desenvolvimento e outro de Manuteno. Esses processos tm um esqueleto muito similar, embora o primeiro esteja focado no desenvolvimento de novos artefatos, enquanto o foco do segundo a manuteno de artefatos previamente desenvolvidos (ainda que novos artefatos possam ser criados). Esse esqueleto composto das seguintes atividades: Levantamento e Anlise de Requisitos, Projeto, Implementao e Teste de Unidade, Testes de Integrao e Validao, e Liberao do Produto. Todas essas atividades, com exceo da Liberao do Produto, so de responsabilidade do colaborador. Contudo, atividades de Integrao e Testes de Integrao e Validao so realizadas tambm por membros do LabES. Por fim, cabe aos membros do LabES decidir quando liberar uma nova verso do ambiente, devendo descrever, ainda, as modificaes efetuadas e os responsveis por elas. importante destacar, ainda, algumas caractersticas do Processo de Manuteno. Ele tem como objetivo principal a soluo de Solicitaes de Alterao
60

feitas por usurios. Esse processo, assim como o Processo Padro de Manuteno do LabES, fortemente baseado na norma IEEE 1219 (IEEE, 1998). Assim, alm das atividades comuns ao processo de desenvolvimento, h uma atividade inicial de Identificao do Problema, que envolve as seguintes sub-atividades: Submeter Solicitao de Alterao: O processo iniciado quando um usurio de ODE submete uma solicitao de alterao pelo Portal do Projeto. A solicitao numerada automaticamente e armazenada; Analisar Validade e Classificar Solicitao de Alterao: Membros de LabES so designados para analisar a validade da Solicitao de Alterao registrada e, caso seja verificada sua real necessidade de execuo, a mesma ser classificada segundo tipo (corretiva, adaptativa, perfectiva ou preventiva) e rea do projeto; Efetuar Estimativa Preliminar de Tamanho / Magnitude da Manuteno: Depois de classificada, o tamanho e a magnitude da Solicitao devem ser estimados. Essas estimativas so feitas por membros do LabES e so importantes por auxiliarem a deciso de colaboradores, indicando recursos necessrios para a sua realizao; Priorizar Solicitao de Alterao: As solicitaes devem ser agrupadas por classe e reas do projeto e submetidas a uma anlise, efetuada em reunio entre membros do LabES, na qual so priorizadas e posteriormente publicadas como um novo sub-projeto no Portal do Projeto, estando disponvel para os colaboradores. As reunies so peridicas. A partir deste ponto o colaborador o agente ativo na soluo de Pacotes de Solicitaes de Alterao. Atravs do Portal do Projeto, o colaborador se prope a solucionar um pacote de solicitaes e obtm os artefatos necessrios para tal. Uma vez selecionado um sub-projeto de manuteno por um colaborador, um processo semelhante ao processo de desenvolvimento realizado, incluindo as interaes com os processos de apoio. importante frisar que a estrutura do Processo Padro LabES para Software Livre a mesma que a do Processo Padro LabES, apresentada na Figura 4.3, assim como o detalhamento das atividades. A Figura 4.5 mostra o detalhamento da atividade

61

Definir Processo de Projeto do Processo de Gerncia de Projetos, agora no contexto do Processo Padro LabES Especializado para Software Livre. Nome Descrio Critrios Entrada Sada Responsvel(is) Organizao Papel(is) Participantes Organizao Papel(is) Artefatos Requeridos Artefatos Gerados Pr-atividade Ps-atividade Sub-atividades Ferramentas Procedimentos Indicador de Execuo Resultados Esperados Definir Processo de Projeto O processo padro LabES para Software Livre deve ser instanciado para o projeto em questo e adequado a ele. Escopo definido Processo de Projeto Colaborador Gerente de Projeto Colaborador Analista de Sistemas Escopo do Projeto, Caractersticas do Projeto e Processo Padro LabES Livre Processo de Projeto Definir Escopo do Projeto Realizar Estimativas Ferramenta de Apoio Definio de Processos, Ferramenta de Groupware (Portal). Obrigatrio DFP (Definio do Processo Organizacional) 5 - So desenvolvidas estratgias para adaptao do processo-padro de acordo com as necessidades dos projetos.

Observaes Figura 4.5 Detalhamento da atividade Definir Processo de Projeto do Processo de Gerncia de Projetos do Processo Padro LabES para Software Livre.

Os processos padro do LabES, incluindo suas especializaes para software livre, esto publicados na ntegra no Portal do LabES e podem ser acessados a partir do site do www.inf.ufes.br/~labes.

4.6 Licena para Disponibilizao de ODE como Software Livre

Um requisito fundamental para a transformao de ODE em um SL que se decida sob qual licena o software ser disponibilizado. Essa escolha fundamental,

62

pois espelha os objetivos da organizao (no caso o LabES) ao disponibilizar seu produto como SL. Portanto, se mal escolhida, pode representar o fracasso de todo um planejamento de um projeto. Neste trabalho foram realizadas pesquisas sobre as vrias licenas de SL existentes, buscando confrontar cada licena estudada s caractersticas do Projeto ODE. Havia a possibilidade de se criar uma licena prpria para ODE Livre, porm essa opo foi desconsiderada, tanto por no haver, por parte dos participantes do projeto, uma pessoa que domine a legislao correspondente, quanto por ser uma escolha perigosa no sentido de estar sujeita a incompatibilidades entre as licenas j existentes. Das licenas pesquisadas, as que mais se destacavam eram a FreeBSD (FREEBSD, 2006) e a GNU-GPL (GNU-GPL, 2006), sendo que foram encontrados, inclusive, documentos que indicavam a adoo de licenas do estilo BSD para pesquisadores. Porm, dada a origem acadmica do Projeto ODE (sem fins lucrativos) e pelo fato da licena GNU-GPL estar mais de acordo com os conceitos reais definidos para Software Livre, decidiu-se adotar essa licena para o Projeto ODE Livre. Vale destacar que essa deciso foi auxiliada por uma consulta feita FSF (Free Software Foundation) (FREE SOFTWARE FOUNDATION, 2006), por meio de mensagem eletrnica .

4.7 Consideraes Finais do Captulo

Com o objetivo de produzir um Ambiente de Desenvolvimento de Software livre, o Projeto ODE Livre foi criado. Neste captulo foram apresentadas as motivaes para a transformao do Projeto ODE em um projeto de software livre e as novas caractersticas que essa nova modalidade de desenvolvimento traria para o processo de software. Para dar o apoio necessrio a essa transformao, foi definido um novo nvel na estrutura de processos de software do LabES, onde foram inseridos os processos padro especializados para software livre. Contudo, para tornar vivel a utilizao dos processos definidos, necessrio que se crie um ambiente que os apie. O prximo captulo discute caractersticas, requisitos e ferramentas que tal ambiente deve possuir.

63

Captulo 5 Requisitos de um Ambiente de Apoio ao Projeto ODE Livre

Durante a definio do processo que uma organizao deve seguir, desejvel que sejam disponibilizadas ferramentas de apoio, visando facilitar a realizao das atividades pertencentes ao mesmo. No caso do desenvolvimento de Software Livre, o apoio ferramental se torna essencial, principalmente, devido disperso geogrfica dos colaboradores. Esse fato tambm exige que as ferramentas sejam disponibilizadas pela Internet, ou que os artefatos produzidos o sejam. Dentro deste contexto, este captulo se inicia com um levantamento de caractersticas e requisitos de um ambiente de apoio ao desenvolvimento de Software Livre. Esse levantamento foi feito por meio de pesquisas a alguns projetos de Software Livre existentes, buscando identificar funcionalidades de apoio necessrias ao Projeto ODE Livre. Aps essa pesquisa, foram definidos requisitos para o Portal ODE Livre, portal que concentrar todo o apoio ferramental necessrio para o desenvolvimento de ODE seguindo o processo padro definido no Captulo 4. Este captulo est estruturado da seguinte forma: na seo 5.1 so levantadas caractersticas ambientes de apoio ao desenvolvimento de Software Livre (SL) levando em conta projetos de SL bem sucedidos; a seo 5.2 descreve os requisitos de um ambiente de apoio ao Projeto ODE Livre com base nas caractersticas levantadas e a estrutura geral e as funcionalidades que se pretende disponibilizar no Portal ODE Livre; finalmente, na seo 5.3 so apresentadas as consideraes finais do captulo.

64

5.1 Caractersticas de Ambientes de Apoio ao Desenvolvimento de Software Livre

Tendo como base as caractersticas de desenvolvimento de Software Livre levantadas no Captulo 3 desta dissertao, chega-se concluso de que a caracterstica fundamental e bsica de um ambiente de apoio ao desenvolvimento de SL que a grande maioria de suas funcionalidades esteja disponvel pela Internet. Essa caracterstica facilmente observada pelo fato de que os colaboradores de um projeto de SL esto, na grande maioria das vezes, dispersos geograficamente, exigindo que o apoio ferramental fornea suporte ao desenvolvimento colaborativo e acesso simultneo a um grande volume de informaes. Contudo, importante observar outras caractersticas importantes, sobretudo funcionais. Pelo destaque adquirido mundialmente, as caractersticas levantadas neste captulo tm como base, principalmente, trs dos mais importantes projetos de SL existentes Projeto Mozilla, Projeto Apache e Projeto Linux cujos ambientes de apoio so sucintamente apresentados a seguir.

5.1.1 O Projeto Mozilla

A maioria das ferramentas de apoio ao Mozilla pode ser acessada por um navegador Web e todas elas esto disponveis sob licenas de Software Livre, de modo que possam ser utilizadas em qualquer projeto, seja livre ou proprietrio. Dentre elas destacam-se: CVS, Bugzilla, Bonsai, Tinderbox, LXR e ferramentas de comunicao.

CVS (Concurrent Version System)

um sistema de controle de verso, um componente importante da Gerncia de Configurao de Software. Com sua utilizao, possvel registrar o histrico de evoluo do cdigo fonte e dos documentos de um projeto (FREE SOFTWARE FOUNDATION, 2006). Segundo REIS (2002), so aspectos interessantes que dessa ferramenta:

65

Repositrio Central: o CVS opera no modo cliente-servidor. Um repositrio central armazena o cdigo fonte e informaes da verso, e os clientes requisitam o cdigo e recebem cpias do mesmo.

Controle de Verses: a funcionalidade bsica de um sistema de gerncia de configurao. O CVS permite que verses de arquivos anteriores possam ser recuperadas.

Ramos (Branches): o CVS suporta mltiplos ramos de desenvolvimento, que podem coexistir independentemente. Essa caracterstica importante na integrao de novas funcionalidades com grande impacto.

Desenvolvimento Concorrente: o CVS no bloqueia o artefato (cdigo ou documento) em um checkout (registro de que uma alterao no artefato est sendo feita). Em vez disso, cada desenvolvedor faz um checkout do artefato, obtendo uma cpia local, modifica o mesmo, e quando estiver pronto, submete de volta ao repositrio. Conflitos de alteraes no artefato so resolvidos no lado do cliente, e no no repositrio.

Suporte de Rede: o CVS funciona bem em redes de qualquer tamanho, que um pr-requisito para o desenvolvimento de SL.

Funcionalidades Oferecidas: o CVS implementado como uma ferramenta que apia as vrias tarefas envolvidas no controle de verses, fazendo checkout do cdigo, atualizando uma cpia local, imprimindo diferenas entre verses e submetendo mudanas.

Bugzilla

Bugzilla um sistema de controle de defeitos que permite que indivduos ou grupos de programadores acompanhem relatrios de erros ou pedidos de melhoria, sendo atualmente a principal ferramenta existente para gesto de erros (BUGZILLA, 2006). Bugzilla a ferramenta de apoio de maior destaque do Projeto Mozilla, tanto que utilizada pelos principais projetos de Software Livre existentes. Bugzilla possui um grande nmero de funcionalidades de apoio ao processo de desenvolvimento do Projeto Mozilla, oferecendo suporte a diferentes atividades e agindo como um eixo central para comunicao e reviso de cdigo entre membros da comunidade do projeto (REIS, 2002). Os desenvolvedores o utilizam diariamente para

66

registrar pacotes e pedir e fornecer reviso; os membros do grupo de garantia da qualidade o utilizam para reportar e controlar defeitos (bugs); gerentes o utilizam para alocar desenvolvedores e controlar o progresso. Entre as caractersticas do Bugzilla, destacam-se (REIS, 2002): Conta de Usurio: cada usurio tem uma conta, identificada por seu endereo eletrnico (e- mail). O processo de criao e validao da conta muito simples, o que reduz a barreira de adeso e encoraja a participao. Atributos de Defeito (Bug): os defeitos tm propriedades que combinam muito bem com os requisitos de processo do Mozilla e permitem um bom controle sobre a responsabilidade, o planejamento, dependncias e estado. A Figura 5.1 mostra os vrios atributos de defeitos.

Figura 5.1 - Formulrio de Defeitos do Bugzilla.

67

Registro de Comentrios: pelo fato de cada defeito manter uma lista seqencial de comentrios de usurios, o Bugzilla trabalha muito bem como um frum de discusso focado.

Controle de Anexos: defeitos podem ter anexos, que so arquivos carregados pelo usurio e ligados a um defeito especfico. A maioria dos anexos so complementos para o defeito, mas tambm podem ser casos de teste, capturas de telas e especificaes. O controle de anexos tambm fornece apoio para reviso de cdigo e tem uma interface especial para isso.

Interface de Busca: Bugzilla registra centenas de milhares de defeitos. Para apoiar as consultas a essa base de dados, h uma funo de busca que permite especificar que atributos definem o defeito sendo pesquisado.

Integrao de E-mail: as mudanas geram mensagens eletrnicas para todas as partes envolvidas em um defeito, permitindo que as pessoas sejam notificadas das requisies e do progresso do mesmo.

Modelo Conceitual Simples: Bugzilla basicamente um registrador de defeitos e embora possua uma gama extensa de funcionalidades, os conceitos so simples de entender: produtos, componentes (que so subdivises de um produto), anexos e defeitos (bugs).

Bonsai

Bonsai uma interface de busca para o repositrio do CVS, que permite a realizao de diversas consultas no contexto de um arquivo de CVS, tais como: obter uma lista de checkins (registros de realizao de alterao), ver que checkins foram realizados por uma determinada pessoa, ou num dado ramo (branch) de CVS, ou num determinado perodo de tempo. Tambm inclui ferramentas para visualizar registros (logs) d e checkins (e comentrios), exibir diferenas entre verses de um arquivo e descobrir que pessoa responsvel por alterar determinada linha de cdigo (BONSAI, 2006). A Figura 5.2 mostra a tela inicial de controle de consulta do Bonsai.

68

Figura 5.2 Tela inicial do Controle de Consulta do Bonsai.

Tinderbox

Tinderbox um sistema automatizado que controla compilaes e testes. uma ferramenta cliente-servidor: as mquinas do cliente de variadas arquiteturas e sistemas operacionais formam um conjunto. A tarefa dessas mquinas compilar, testar e reportar de volta os resultados ao servidor Tinderbox. A principal caracterstica visvel ao usurio uma pgina exibindo os resultados da compilao associada mquina individual no conjunto e as mudanas de cdigo que foram integradas ao repositrio ao mesmo tempo, como mostra a Figura 5.3. Cada mquina do conjunto de compilao representada por uma coluna, que mostra as vrias construes que aconteceram durante um perodo de tempo. As construes mais recentes aparecem nas colunas de cima. A cor de cada seo das colunas indica um resultado diferente da compilao (REIS, 2002).

69

5.3 Tela principal do Tinderbox.

LXR

uma ferramenta de hipertexto que indexa cdigo fonte e gera pginas HTML, como mostra a Figura 5.4. Foi originalmente desenvolvida como uma ferramenta para o estudo do Kernel do Linux, mas foi adaptada ao Mozilla pela comunidade. Exibe arquivos de cdigo como pginas, com links pra cada linha e para cada identificador, isto , funes, classes e variveis so ligadas por hiperlinks. Assim, possvel acessar a declarao e a implementao de uma funo que est sendo chamada em um certo arquivo (LXR, 2006).

70

Figura 5.4 Exemplo de pgina gerada pelo LXR.

Wiki-Mozilla

Uma ferramenta vem ganhando cada vez mais adeptos para o auxlio na gerncia de conhecimento de projetos de software: o Wiki. O Projeto Mozilla tem o seu Wiki, o Wiki-Mozilla, cuja pgina inicial exibida na Figura 5.5 (WIKI-MOZILLA, 2006).

Figura 5.5 Pgina inicial do Wiki-Mozilla

71

Wiki uma ferramenta que permite que usurios criem contedo livremente e editem contedo na Web usando qualquer tipo de navegador Web. Oferece suporte a hiperlinks e possui uma sintaxe simples para criar novas pginas e referncias a outros documentos internos (WIKI, 2006). Esta ferramenta possibilita que usurios cadastrados tenham a liberdade de criar e editar pginas Web a qualquer momento, encorajando a utilizao democrtica da Web e promovendo a composio do contedo por usurios no tcnicos. Wikis podem ser facilmente utilizados no apoio Gerncia de Conhecimento de Projetos de Software Livre por armazenarem e disponibilizarem a experincia dos mais diversos colaboradores e usurios.

Ferramentas de Comunicao

Motivado pela disperso geogrfica dos colaboradores, ferramentas de comunicao via Web so fundamentais para a viabilidade de projetos de Software Livre. Apesar da comunidade do Mozilla utilizar, muitas vezes, o Bugzilla como uma ferramenta de apoio comunicao, listas de discusso via e- mail e IRCs (Internet Relay Chats) so mais viveis para tal propsito. Um IRC um sistema de comunicao em tempo real que aloca seus participantes em canais. Apresenta um cenrio interessante para um ambiente de desenvolvimento distribudo: embora funcione em tempo real, permite comunicao seletiva. Portanto, pode ser usado como um substituto razovel para um telefone quando questes tcnicas esto sendo discutidas (REIS, 2002). Em relao s listas de discusso, o fato delas apoiarem a troca de experincias na comunidade tem como efeito colateral a possibilidade de se arquivar essa comunicao para anlise futura. Normalmente esses arquivos online so indexados por servios de busca na Web e so utilizados como uma fonte importante de documentao para os usurios, j que freqentemente apresentam problemas recorrentes, j discutidos no passado por outros (REIS, 2002).

72

5.1.2 O Projeto Apache

De forma anloga ao Mozilla, o Projeto Apache tem a gerncia de configurao apoiada pelo CVS, possui seu prprio Wiki para auxlio gerncia de conhecimento (WIKI-APACHE, 2006), sua comunicao fortemente baseada em listas de discusso classificadas de acordo com o papel do colaborador e h uma ferramenta de controle de defeitos, inicialmente BUGDB e atualmente o Bugzilla (APACHE, 2006). O Projeto Apache utiliza, tambm, uma ferramenta de comunicao responsvel por armazenar informaes para anlise futura: o Web-frum. O Web- frum uma ferramenta que disponibiliza um espao de discusso no qual seus membros podem inserir comentrios a qualquer momento sobre um assunto abordado, caracterizando-se como uma ferramenta de comunicao assncrona. A Figura 5.6 exemplifica um frum criado para o Projeto Apache.

Figura 5.6 Tela principal de um Frum Apache.

73

5.1.3 O Projeto Linux

Apesar de ser um dos principais projetos de Software Livre existentes, o Projeto Linux um dos projetos mais minimalistas em relao infra-estrutura de desenvolvimento. Por muito tempo os desenvolvedores do Kernel do Linux possuam somente o apoio de e- mails e listas de discusso para o desenvolvimento e manuteno do cdigo fonte. Apesar de ainda no ser uma unanimidade, o Bitkeeper (BITKEEPER, 2006) est sendo usado como ferramenta para controle de verses. A Figura 5.7 apresenta um exemplo de utilizao da ferramenta para analisar diferenas entre verses de cdigo fonte (REIS, 2003). Alm disso, tambm recentemente, o Bugzilla tem sido utilizado para apoiar o Projeto Linux em seu controle de defeitos e evolues e wikis tambm so utilizados no apoio gerncia de conhecimento (WIKI-LINUX, 2006).

Figura 5.7 Exemplo de utilizao do Difftool do BitKeeper.

74

5.2 Requisitos de um Ambiente de Apoio ao Projeto ODE Livre

A partir do levantamento feito sobre as caractersticas de apoio ferramental para o desenvolvimento de software dos principais projetos de Software Livre, procurou-se descrever requisitos mnimos de um ambiente de apoio ao Projeto ODE Livre. Tendo como base o principal requisito de um ambiente de apoio ao desenvolvimento de Software Livre possuir suas ferramentas disponveis pela Internet foi definido neste trabalho que todas as funcionalidades do ambiente de apoio ao Projeto ODE Livre deveriam ser passveis de acesso a partir de um Portal Web, denominado Portal ODE Livre.

5.2.1 Requisitos Funcionais Iniciais para o Portal ODE Livre

Com base no levantamento realizado na seo anterior sobre as ferramentas utilizadas em projetos de SL e nas caractersticas especficas do projeto ODE, alguns requisitos foram definidos para a construo do Portal ODE Livre. Esses requisitos esto descritos em detalhes no Projeto de Graduao de Julierme Silva (SILVA, 2007), que foi fortemente baseado nas caractersticas e conceitos levantados neste trabalho. Para a primeira verso do portal, foram identificadas funcionalidades de apoio ao controle de usurios e contribuies, sendo importante frisar que os requisitos levantados no obrigam que a construo do Portal do ODE Livre se d por meio do desenvolvimento de um novo produto de software. Ou seja, nada impede que seu desenvolvimento se d pela incorporao de ferramentas livres que atendam aos requisitos especificados para o Portal ODE Livre. O gerenciamento e o acesso ao Portal do Projeto ODE Livre sero feitos de acordo com o tipo de usurio. Para tal os usurios so agrupados nas seguintes categorias: Internauta, Usurio Padro, Membro LabES, Colaborador, Professor e Administrador, como mostra a Figura 5.8.

75

Figura 5.8 - Tipos de Usurios O Portal ODE Livre um portal direcionado ao apoio ao desenvolvimento de ODE como Software Livre, um projeto desenvolvido no LabES. Porm, existe tambm o Portal LabES, uma porta de entrada na Internet para o LabES, cujo propsito facilitar a interao do LabES com o pblico interessado na rea de Engenharia de Software. Sendo assim, o Portal do ODE Livre est relacionado ao Portal do LabES e os tipos de usurios acima exibidos visam tratar o escopo de ambos os portais. O Internauta representa qualquer pessoa que esteja navegando na Internet. Esse tipo de usurio pode se cadastrar como um Usurio Padro, tem acesso s funcionalidades de visualizao de qualquer material ou informao disponvel e pode efetuar download de publicaes e materiais do Portal do LabES. Um Usurio Padro representa usurios cadastrados no Portal do LabES / Portal do ODE Livre. Esse tipo de usurio pode alterar seus dados e sua senha, e ter de se autenticar no sistema para ter acesso s funcionalidades especficas dessa classe de
76

usurios. Apenas usurios padro podero fazer o download do ambiente ODE. Alm disso, podero relatar falhas do ambiente e propor novas funcionalidades para o mesmo. O Colaborador representa um usurio padro que se disps a colaborar com o Projeto ODE Livre, corrigindo alguma falha ou desenvolvendo uma nova funcionalidade para o ambiente. A classes de usurios Membros de LabES agrupa todos os usurios que atuam dentro do laboratrio. Esse tipo de usurio pode consultar os dados de qualquer outro membro do LabES e pode registrar materiais a serem disponibilizados no portal. Professor representa os professores associados ao LabES. Esse tipo de usurio pode disponibilizar publicaes e projetos, cadastrar reas de pesquisa, alm de poder consultar os dados dos membros do LabES e registrar materiais, como qualquer membro do LabES. Por fim, a classe de usurios Administrador representa os administradores do sistema, que tm permisso para cadastrar novas funcionalidades, tipos de usurios, membros do LabES, professores e outros administradores. De fato, um administrador tem acesso a todas as funcionalidades do sistema. No que se refere ao Portal do ODE Livre, neste levantamento inicial, dois subsistemas foram definidos, como mostra a Figura 5.9: Controle de Usurios: envolve toda a funcionalidade relacionada com o controle de usurios do Portal ODE Livre / Portal do LabES, abrangendo controle de funcionalidades, tipos de usurios e usurios. Controle de Contribuies: disponibiliza funcionalidades que permitem gerenciar as falhas (bugs) relatadas e as novas funcionalidades que so sugeridas pelos colaboradores do projeto.

Figura 5.9 Diagrama de Pacotes do Portal ODE Livre Para cada um desses subsistemas, um conjunto de funcionalidades inicial foi identificado e modelado na forma de casos de uso. A Figura 5.10 mostra o diagrama de casos de uso do subsistema Controle de Usurios, cujas funcionalidades so (FIORIO, 2005):

77

Figura 5.10: Diagrama de Casos de Uso do subsistema de Controle de Usurios.

Cadastrar Usurio: este caso de uso responsvel pelo controle de usurios, abrangendo a criao de um novo usurio, consulta e excluso de usurios existentes.

Autenticar Usurio: este caso de uso responsvel pela autenticao do usurio no sistema, abrangendo a efetuao de login, logout e envio de senha.

Alterar Dados Usurio: Este caso de uso permite que um usurio padro efetue a alterao de seus dados pessoais e senha.

A Figura 5.11 mostra o diagrama de casos de uso referente ao subsistema de Controle de Contribuies. Nesse subsistema atuam os atores Membro LabES e Colaborador, para os quais so disponibilizadas funcionalidades relacionadas ao controle de contribuies feitas por colaboradores ao Projeto ODE Livre. Uma descrio sucinta de cada caso de uso apresentada a seguir. Para maiores detalhes, vide (SILVA, 2007).

78

Figura 5.11 Diagrama de Casos de Uso do subsistema de Controle de Contribuies.

Controlar Solicitao: este caso de uso responsvel pelo controle de solicitaes feitas pelos usurios de ODE. Por meio dele, um usurio padro pode solicitar a correo de uma falha por ele detectada no ambiente ou pode sugerir uma nova funcionalidade para o ambiente, dentre outros.

Avaliar Solicitao: este caso de uso trata da avaliao de solicitaes. Por meio dele, membros do LabES consultam solicitaes e registram avaliaes das mesmas, aprovando ou rejeitando solicitaes feitas pelos usurios. Solicitaes aprovadas so preparadas para serem colocadas disponveis para colaboradores no Portal.

79

Selecionar Solicitao para Tratar: este caso de uso permite que um Colaborador selecione uma solicitao, se responsabilizando por trat-la, isto , por desenvolver uma soluo para a solicitao.

Enviar Contribuio: este caso de uso permite que um colaborador envie uma contribuio ao Projeto ODE Livre

Avaliar Contribuio: este caso de uso permite que um membro do LabES registre a avaliao de uma contribuio enviada por um usurio ao Projeto ODE Livre.

importante frisar que, dados os requisitos funcionais descritos anteriormente na forma de modelos de casos de uso, nada impede que o Portal ODE Livre seja construdo pela integrao da ferramenta livre de acompanhamento de alteraes Bugzilla, visto que tal ferramenta abrange todos os requisitos citados (BUGZILLA, 2006). Porm, a escolha de uma opo de construo de uma ferramenta prpria de controle de contribuies e alteraes seria justificada por algumas particularidades: Para uma melhor integrao do Portal ao prprio Projeto ODE; Criao de novas funcionalidades particulares ao projeto; Automatizao do processo de distribuio de pedidos de apoio (envio de solicitaes e contribuies) para colaboradores (desenvolvedores e avaliadores), utilizando-se mecanismos de gerncia de conhecimento para tal. Como dito no incio desta seo, os requisitos aqui definidos no obrigam a construo prpria de um novo produto de software.

5.2.2 Outros Requisitos Gerais Desejados para o Portal ODE Livre

Alm dos requisitos funcionais especificados para o Portal ODE Livre, para que este se torne um ambiente adequado para o Projeto ODE Livre, h, ainda, outros requisitos gerais a serem considerados, tipicamente tratados em projetos de SL e levantados a partir de colocaes feitas em (NAKAGAWA, 2002) e (REIS, 2003), dentre outros. Esses servios devem ser disponibilizados via Portal do projeto e incluem:

80

Endereo de correio eletrnico do Projeto: Um endereo eletrnico do projeto deve ser disponibilizado, permitindo aos usurios o contato direto co m o coordenador do projeto ou com os responsveis pela integrao (membros do LabES).

Lista de discusso: O projeto deve apresentar uma srie de listas, cada uma para um pblico-alvo. Decidiu-se criar dois tipos de listas, sendo que cada um desses tipos subdividido em outras listas. As listas mais importantes no sentido de promover o desenvolvimento so: o Lista de usurios: Nessa lista, circulam mensagens referentes ao uso e operao do ambiente. Essa lista importante por criar uma comunidade ao redor do software e por facilitar a comunicao referente a pedidos de alteraes e problemas. Em geral, nessa lista concentram-se usurios avanados, que respondem s perguntas mais bsicas, e alguns desenvolvedores, que captam mensagens que tm impacto no

desenvolvimento e respondem s questes mais complexas. Este tipo de lista pode ser subdividido em listas para cada ferramenta de ODE, incluindo o Portal; o Lista de Desenvolvedores: Nessa lista so discutidas decises de projeto. Em geral, essa lista tem alto trfego e apresenta discusses abordando questes mais elaboradas. Esse tipo de lista pode ser subdividido em listas para cada ferramenta de ODE ou at mesmo pelo nvel hierrquico dos colaboradores; Fruns e Chats: Listas de discusso so importantes ferramentas de comunicao, porm, por ser um projeto de SL, muito importante a utilizao de outras ferramentas de comunicao, tais como fruns e chats. A integrao de uma ferramenta livre de frum ao Portal ODE Livre pode permitir uma forma de comunicao assncrona mais eficiente e organizada dos colaboradores, por meio da subdiviso de tpicos de discusso e visibilidade controlada. Chats integrados, por sua vez, possibilitam a existncia de comunicao sncrona, ideal para colaboraes dinmicas.

81

Repositrio de software: Possibilita que verses (mais recentes ou no) do ambiente possam ser obtidas. Esse repositrio deve ser disponibilizado no Portal ODE Livre;

Repositrio de controle de verso: um requisito fundamental para que o desenvolvimento distribudo seja possvel e agilizado por meio do controle e anlise das diversas verses do software. Atualmente, o LabES controla a verso de seus produtos utilizando a ferramenta Subversion (SUBVERSION, 2006). Assim, devese estudar a utilizao desta ferramenta de forma integrada ao Portal ODE Livre .

Wiki: Esta ferramenta possibilita a insero de conhecimento para todos os envolvidos no projeto a partir da criao de pginas Web livres. Vrios Wikis referentes s ferramentas de ODE podem ser criados no intuito de fornecer conhecimento aos usurios e colaboradores do projeto. Os wikis so importantes por impedir que o conhecimento fique retido com determinados membros colaboradores, disseminando-o com os demais.

5.2.3 Utilizando ODE no Projeto ODE Livre

Pelo fato de ODE ser um Ambiente de Desenvolvimento de Software (ADS), cujo objetivo fornecer apoio ao longo de todo o processo de software ou em pores significativas dele, seria um desperdcio deixar de utilizar as diversas ferramentas providas por ODE para auxiliar o seu prprio desenvolvimento como Software Livre. Conforme discutido anteriormente, idealmente, seria interessante que todas as ferramentas de apoio fossem disponibilizadas pela Web para que os colaboradores do Projeto ODE Livre pudessem utiliz- las. Assim, o prprio ambiente ODE e todas as suas ferramentas teriam de ser aplicaes Web, o que no ocorre. Tendo esta limitao em mente, foi estabelecida uma nova funcionalidade para ODE: a importao e exportao de projetos no formato XML. Dessa forma, este requisito possibilita que um colaborador utilize qualquer ferramenta de ODE para produzir um artefato, de forma off-line, gere um arquivo XML correspondente ao projeto contendo um ou mais artefatos produzidos e submeta este arquivo ao Projeto ODE Livre atravs do

82

Portal ODE Livre, utilizando a funcionalidade de Controle de Contribuies. De forma similar, colaboradores que queiram utilizar ou alterar os artefatos produzidos por outros poderiam fazer o download dos arquivos XML correspondentes e import- los para a verso de ODE local em sua mquina. Desta forma, consegue-se, parcialmente, a integrao de ODE ao Portal, tornando-o mais completo e permitindo a colaborao em vrios artefatos de projeto.

5.3 Consideraes Finais do Captulo

Definido o processo padro a ser seguido para o desenvolvimento e manuteno de ODE Livre, preciso fornecer apoio ferramental para viabilizar a implantao e uso de tal processo. Neste captulo, foram levantadas caractersticas de apoio ferramental a projetos de SL atravs de pesquisas feitas, principalmente, a trs dos projetos de maior destaque em mbito mundial: Projeto Mozilla, Projeto Apache e Projeto Linux. A partir do levantamento realizado, requisitos foram estabelecidos para a elaborao do Portal ODE Livre. Todos os requisitos levantados tm como necessidade bsica o acesso a suas funcionalidades pela Internet. Parte desses requisitos dever ser incorporada ao projeto do Portal ODE Livre, j em andamento, que em sua verso atual possui funcionalidades definidas para controle de usurios e controle de contribuies. Finalmente, este captulo apresentou uma forma de utilizar ODE para apoiar seu prprio desenvolvimento, por meio de mecanismos de importao e exportao de arquivos XML.

83

Captulo 6 Consideraes Finais

Os principais objetivos deste trabalho foram definir processos padro de qualidade para o desenvolvimento de Software Livre e estabelecer uma estrutura computacional de apoio adequada para tal, tendo como estudo de caso o Projeto ODE Livre. S foi possvel alcanar este objetivo atravs da realizao de um levantamento detalhado sobre os dois conceitos principais deste trabalho: qualidade de software, incluindo normas e modelos de qualidade, e caractersticas de projetos de software livre bem sucedidos, incluindo ferramentas de apoio ao seu desenvolvimento. Este captulo procura destacar as contribuies deste trabalho para a comunidade de software em geral e, mais especificamente, para os envolvidos no desenvolvimento de Software Livre. Apesar de ter alcanado o principal objetivo previamente imaginado, algumas questes ficaram em aberto e novas perspectivas surgiram para trabalhos futuros relacionados.

6.1 Concluses

O desenvolvimento de Software Livre (SL) tem evoludo bastante, proporcionando o surgimento de um nmero cada vez maior de projetos de SL e adquirindo importncia considervel no cenrio mundial de desenvolvimento de software. O SL trouxe comunidade de software, uma nova forma de se desenvolver software, diferente da tradicional, acarretando mudanas culturais, polticas e econmicas. Sua principal caracterstica a liberdade, ou seja, a distribuio dos arquivos binrios de um sistema livre deve ser feita junto ao cdigo fonte, permitindo o estudo e alterao a qualquer pessoa e, dependendo da licena de software utilizada, a nova liberao aps alteraes tambm deve respeitar as mesmas regras. Em relao ao desenvolvimento,

84

caracterizado, na maior parte das vezes, pelo trabalho voluntrio e pela distribuio geogrfica dos envolvidos. A partir de uma anlise sobre o cenrio atual do desenvolvimento de software livre, constatou-se no haver nenhum projeto de SL desenvolvido com a utilizao de processos baseados em normas e modelos de qualidade mundialmente reconhecidos. Assim, o objetivo principal deste trabalho foi reforado e decidiu-se elaborar processos padro para o desenvolvimento de software livre no Laboratrio de Engenharia de Software (LabES) da Universidade Federal do Esprito Santo, associados a requisitos de um ambiente de apoio ferramental a esses processos. Aps considervel estudo bibliogrfico sobre qualidade de software e caractersticas de desenvolvimento de SL, foram elaborados os processos padro para desenvolvimento e manuteno de Software Livre no LabES. Visando adequar uniformemente todos os processos padro do LabES (livres e no livres), decidiu-se reformular o processo padro de desenvolvimento LabES nos moldes sugeridos pelo MPS.BR e criou-se o processo padro de manuteno LabES com base no padro IEEE 1219. A partir da elaborao dos processos padro, era necessrio definir o ambiente ferramental de apoio aos processos. Devido a limitaes de prazos, decidiu-se definir os requisitos necessrios para o ambiente proposto o Portal ODE Livre, contando com a ajuda de Julierme Silva (SILVA, 2007) para tal. Assim, foram contribuies deste trabalho: Elaborao do Processo Padro LabES de Desenvolvimento de SL nos moldes sugeridos pelo MPS.BR; Elaborao do Processo Padro LabES de Manuteno de SL nos moldes sugeridos pelo MPS.BR e com base no padro IEEE 1219; Elaborao do Processo Padro LabES de Manuteno nos moldes sugeridos pelo MPS.BR e com base no padro IEEE 1219; Reviso do Processo Padro LabES de Desenvolvimento nos moldes sugeridos pelo MPS.BR; Definio da GNU-GPL como licena livre sob a qual ODE Livre dever ser disponibilizado; Definio dos Requisitos para a construo do Portal ODE Livre.

85

Durante o desenvolvimento deste trabalho, algumas limitaes foram identificadas. Dentre elas, pode-se citar a necessidade de se aplicar os processos propostos em projetos piloto no intuito de avali- los e melhor- los. Para que se pudesse efetivar essa aplicao, seria necessrio um tempo maior que, comumente, no disponvel elaborao de uma dissertao de mestrado. Outra limitao enfrentada neste trabalho foi a impossibilidade de se construir o Portal ODE Livre para averiguar se os requisitos levantados so suficientes para atender ao objetivo do projeto.

6.2 Perspectivas Futuras

Conforme discutido na seo anterior, uma vez definidos os processos padro para o Projeto ODE Livre, preciso aplic- los em projetos piloto para que sejam feitos os ajustes necessrios, aperfeioando-os a ponto de serem realmente disponibilizados para apoiarem o desenvolvimento de ODE como Software Livre. Inicialmente, espera-se disponibilizar ODE para parceiros do LabES, criando instncias dos processos padro elaborados para cada projeto desenvolvido por uma organizao colaboradora, de acordo com suas peculiaridades. Aps feitos os ajustes necessrios, ODE ser efetivamente disponibilizado como SL. Dada a necessidade de se fornecer apoio ferramental aos colaboradores para facilitar a aplicao dos processos definidos, importante no s concluir a construo do Portal ODE Livre com os requisitos levantados no Captulo 5, mas tambm procurar definir novas ferramentas para melhorar a qualidade do apoio fornecido. Neste sentido, importante evoluir as pesquisas relacionadas o como utilizar ODE no desenvolvimento de ODE. H uma expectativa de que os benefcios decorrentes do uso de ferramentas de apoio ao desenvolvimento de ODE Livre seriam muito maiores se o prprio ambiente ODE pudesse ser usado integrado s demais ferramentas do Portal. Uma das formas de atingir tal integrao seria atravs da disponibilizao de ODE pela Internet, ou seja, transformando-o numa aplicao Web.

86

O objetivo de transformar ODE em Software Livre tem sido visto como muito promissor pelo LabES, principalmente, pelo fato de se poder vislumbrar a evoluo de ODE contando com o apoio da comunidade de software brasileira. A crena neste interesse depositada na considervel quantidade de funcionalidades oferecidas por ODE, um ADS centrado em processos.

87

Referncias Bibliogrficas
APACHE, Apache Software Foundation. Disponvel em: http://www.apache.org/. Acesso em: 13/09/2006. ARANTES, L. O., Apoio Automatizado Gerncia de Projetos, Projeto de Graduao, Curso de Cincia da Computao, UFES, 2006. BERTOLLO, G., Definio de Processos em um Ambiente de Desenvolvimento de Software, Dissertao de Mestrado, Mestrado em Informtica, Universidade Federal do Esprito Santo, Maio de 2006. BERTOLLO, G.; RUY, F.B.; MIAN, P.G.; PEZZIN, J.; SHWAMBACH, M.M.; NATALI, A.C.C.; FALBO, R.A., ODE: Um ambiente de Desenvolvimento de Software Baseado em Ontologias. Anais do XVI Simpsio Brasileiro de Engenharia de Software - SBES'2002. Caderno de Ferramentas, pp. 438-443, Gramado - RS, Brasil, Outubro 2002. BERTOLLO, G.; FALBO, R. A., Apoio Automatizado Definio de Processos em Nveis. Anais do II Simpsio Brasileiro de Qualidade de Software, p. 77-91, Fortaleza, Brasil, Setembro 2003. BERTOLLO, G., SEGRINI, B., FALBO, R.A., Definio de Processos de Software em um Ambiente de Desenvolvimento de Software Baseado em Ontologias. Anais do V Simpsio Brasileiro de Qualidade de Software, p. 61 75, Vila Velha, Brasil, Maio 2006. BITKEEPER, The Scalable Distributed Software Configuration Management System. Disponvel em: http://www.bitkeeper.com/. Acesso em: 13/09/2006. BONSAI, The Mozilla Organization. Bonsai. 2000. Disponvel em:

http://www.mozilla.org/bonsai.html. Acesso em: 13/09/2006. BUGZILLA, Bugzilla Bug Tracking System. Disponvel em: http://www.bugzilla.org/. Acesso em: 13/09/2006. CHRISSIS, M. B.; KONRAD, M.; SHRUM, S., Knowledge Management of Software Risks, Journal of Universal Computer Science, Volume 9, Number 7, 670-681, 2003.

88

CREATIVE COMMONS, Home Page. Disponvel em: Acesso em: 11/11/2006.

http://creativecommons.org.

DAL MORO, R.; NARDI, J. C.; FALBO, R. A., ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software, Anais da Sesso de Ferramentas do XIX Simpsio Brasileiro de Engenharia de Software SBES2005, Uberlndia - MG, Brasil, Outubro 2005. DAVIS, M., ODONOVAN, W., FRITZ, J. Linux and open source in the academic enterprise. In: Proc. of the 28th SIGUCCS Conference on User Services, Richmond, 2000. ENGELFRIET, A. Choosing a Software License, 2003 .

http://www.iusmentis.com/computerprograms/licenses/pcactive0203/. Capturado em: 13/09/2006. FALBO, R. A. Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software. Tese de Doutorado, COPPE/UFRJ, RJ, Dezembro, 1998. FALBO, R.A.; NATALI, A.C.C.; MIAN, P.G.; BERTOLLO, G.; RUY, F.B. ODE: Ontology-based software Development Environment, IX Congreso Argentino de Ciencias de la Computacin, p. 1124-1135, La Plata, Argentina, outubro 2003. FALBO, R.A., RUY, F.B., PEZZIN, J., DAL MORO R. Ontologias e Ambientes de Desenvolvimento de Software Semnticos. Actas de las IV Jornadas

Iberoamericanas de Ingeniera del Software e Ingeniera Del Conocimiento, JIISIC'2004, Volumen I, pp. 277-292, Madrid, Espaa, Noviembre 2004. FIORIO, G. C., Desenvolvimento de um Portal para o Laboratrio de Engenharia de Software, Projeto de Graduao, Curso de Cincia da Computao, UFES, 2005. FREEBSD, The 4.4BSD Copyright. Disponvel em:

http://www.freebsd.org/copyright/license.html. Acesso em: 13/09/2006. FREE SOFTWARE FOUNDATION, O que software livre?. Disponvel em: http://www.gnu.org/philosophy/free-sw.pt.html. Acesso em: 13/09/2006. FREITAS, A. M.; NARDI, J. C.; FALBO, R. A., ReqODE: Uma Ferramenta de Apoio Engenharia de Requisitos Integrada ao Ambiente ODE, Anais da Sesso de

89

Ferramentas do XX Simpsio Brasileiro de Engenharia de Software SBES2006, Florianpolis- SC, Brasil, Outubro 2006. FUGGETTA, A., Software Process: A Roadmap, In: Proc. of The Future of Software Engineering, ICSE2000, Limerick, Ireland, 2000, pp. 25-34. GPL, GNU General Public License. Disponvel em: http://www.gnu.org/copyleft/gpl.html. Acesso em: 13/09/2006. GRUHN, V., Process-Centered Software Engineering Environments: A Brief History and Future Challenges, In: Annals of Software Engineering 14, 2002, pp. 363-382. HARRISON, W., OSSHER, H., TARR, P. Software Engineering Tools and Environments: A Roadmap. Proceedings of The Future of Software Engineering (ICSE2000). Limerick, Ireland, 2000. HEXSEL, R. A., Software Livre Propostas de Aes do Governo para Incentivar o Uso de Software Livre. Relatrio Tcnico R T -DINF 004/2002, Universidade Federal do Paran, PR, 2002. IEEE Standards Boards, IEEE Std 1219-1998: Standard for Software Maintenance, jun. 1998. ISO/IEC 12207, Information Technology - Software life cycle processes, 1995. ISO/IEC 12207, Information Technology - Software life cycle processes, Amendment 1, 2002. ISO/IEC 12207, Information Technology - Software life cycle processes, Amendment 2, 2004. ISO/IEC 15504 Information Technology Process Assessment Part 1: Concepts ans Vocabulary, 2003. ISO/IEC 15504 Information Technology Process Assessment Part 1: An exemplar Process Assessment Model, 2004. ISO 9000:2000, Sistemas de gesto da qualidade Fundamentos e vocabulrio, 2000. LINUX, The Linux Home Page at Linux Online. Disponvel em: http://www.linux.org/. Acesso em: 13/09/2006.

90

LXR, Mozilla Cross-Reference. Disponvel em: 11/11/2006.

http://lxr.mozilla.org/. Acesso em:

MAIDANTCHIK, C. L. L. Gerncia de Processos de Software para Equipes Geograficamente Dispersas. Tese de Doutorado, COPPE/UFRJ, RJ, Junho, 1999. MIAN, P.G.; NATALI, A. C. C.; FALBO, R. A., Ambientes de Desenvolvimento de Software e o Projeto ADS, Revista Engenharia, Cincia e Tecnologia, Volume 04, Nmero 04, ISSN 1414-8692, pp. 3 - 10, Vitria, Brasil, Julho/Agosto 2001. MOCKUS, A., Fielding, R. T., Herbsleb, J. Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology, v. 11, n. 3, 2002. MUTAFELIJA, B., STROMBERG, H. Systematic Process Improvement Using ISO 9001:2000 And CMMI, Boston, London: Artech House Publishers, 2003. MYSQL, Home Page. Disponvel em: http://www.mysql.com . Acesso em: 13/09/2006. NAKAGAWA, E. Y. Software Livre: Processo e Produto Livres no Desenvolvimento de Aplicaes Web, Exame de Qualificao ao Doutorado, Instituto de Cincias Matemticas e de Computao ICMC/USP, So Carlos, 2002. POSTGRESQL, Home Page. Disponvel em: http://www.postgresql.org . Acesso em: 13/09/2006. PHP, Home Page. Disponvel em: http://www.php.net . Acesso em: 13/09/2006. PERL, Home Page. Disponvel em: http://www.perl.com . Acesso em: 13/09/2006. PFLEEGER, S.L., Software Engineering: Theory and Practice, 2nd Edition, New Jersey: Prentice Hall, 2001. PRESSMAN, R.S., Software Engineering: A Practitioner's Approach, 5th Edition, New York: McGraw-Hill, 2000. PRESSMAN, R. S., Engenharia de Software. 5 edio. Rio de Janeiro: McGrawHill, 2002. RAYMOUND, E., The cathedral and the bazaar. OReilly & Associates, 1999. REIS, C. R., Caracterizao de um Processo de Software para Projetos de Software Livre. Dissertao de Mestrado, ICMC/USP, So Carlos, 2003.

91

REIS, C. R., FORTES, R. P. M., An Overview of the Software Process and Tools in the Mozilla Project. Proceedings of the Open Source Software Development Workshop, p. 155-175, Newcastle Upon Tyne, United Kingdom, 2002. ROCHA, A. R. C.; MALDONADO, J. C.; WEBER K. C. Qualidade de Software: Teoria e Prtica. 1. Edio. Editora Prentice Hall. So Paulo. 2001. SCACCHI, W., Understanding the requirements for developing open source software systems. In: IEE Proceedings Software Engineering, 149(1), p. 24-39, 2002. SCHWAMBACH, M. M., Apoio Automatizado ao Planejamento e Acompanhamento de Projetos de Software, Projeto de Graduao, Curso de Cincia da Computao, UFES, 2002. SEI, CMMI-SE/SW, verso 1.1 Representao em Estgios, 2002. SEI, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1.1: Method Definition Document, CMU/SEI-2001-HB-001, 2001. SILVA B. C. C., FALBO R. A., 2006, Definio de um Processo Padro para Software Livre, SBQS 2006, V Simpsio Brasileiro de Qualidade de Software, Anais do V Simpsio Brasileiro de Qualidade de Software, p. 159-173, Vila Velha, Brasil, Maio 2006. SILVA, J. L., Portal do Projeto ODE Livre, Projeto de Graduao, Curso de Cincia da Computao, UFES, 2007 (em andamento, concluso prevista para Julho de 2007). SOFTEX, O impacto do software livre e de cdigo aberto na indstria de software do Brasil, Softex Campinas, 2005a [on line]. Disponvel: www.softex.br [capturado em Abril 2006]. SOFTEX, MPS.BR Melhoria de Processo do Software Brasileiro: Guia Geral, Verso 1.0, 2005b [on line]. Disponvel: www.softex.br/mpsbr [capturado em Abril 2006]. SOFTEX, MPS.BR Melhoria de Processo do Software Brasileiro: Guia Geral, Verso 1.1, 2006 [on line]. Disponvel: www.softex.br/mpsbr [capturado em Agosto 2006]. SOURCEFORGE, Home Page. Disponvel em: http://sourceforge.net/index.php. Acesso em: 12/11/2006. SUBVERSION, Home Page. Disponvel em: http://subversion.tigris.org/. Acesso em: 13/09/2006.

92

TRAVASSOS, G.H. O Modelo de Integrao de Ferramentas da Estao TABA. Tese de D.Sc., Programa de Engenharia de Sistemas e Computao, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 1994. VIXIE, P., Software Engineering, In: Open sources: Voices of the open source revolution, 1st edition, OReilly & Associates, p. 91100, 1999. WEBER, C. K, ROCHA, A. R; ALVES, A, AYALA, A. M, GONALVES, A, PARET, B, SALVIANO, C; MACHADO, C. F, SCALET, D, PETIT, D, ARAJO, E, BARROSO, M. G, OLIVEIRA, K, OLIVEIRA, L. C. A, AMARAL, M. P, CAMPELO, R. E. C; MACIEL, T., Modelo de Referncia para Melhoria de Processo de Software: uma abordagem brasileira, XXX Conferencia Latinoamericana de Informtica, Arequipa, Peru, 2004. WEBER, K.C., Mudanas na norma ISO 9000, In: Qualidade de Software: Teoria e Prtica, Eds. A.R.C. Rocha, J.C. Maldonado, K. Weber, Prentice Hall, 2001. WIKI, What is Wiki. Disponvel em: http://www.wiki.org/wiki.cgi?WhatIsWiki. Acesso em: 13/09/2006. WIKI-APACHE, Home Page. Disponvel em: http://wiki.apache.org . Acesso em: 13/09/2006. WIKI-LINUX, WIKI Linux-NTFS Home Page. Disponvel em: http://wiki.linux- ntfs.org. Acesso em: 13/09/2006. WIKI-MOZILLA, Home Page. Disponvel em: http://wiki.mozilla.org. Acesso em: 13/09/2006. XAVIER, J.H.F. ISO 9000 aplicada ao software, In: Qualidade e Produtividade em Software, 4 edio renovada, Organizadores:WEBER, K.C., ROCHA, A.R.C. e NASCIMENTO, C.J., Makron Books, 2001.

93