TCC do curso de Produção de Software Livre - UFLA 2007

200 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
200
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

TCC do curso de Produção de Software Livre - UFLA 2007

  1. 1. UNIVERSIDADE FEDERAL DE LAVRAS GERÊNCIA DO DESENVOLVIMENTO DO COMPONENTE SICE – SISTEMA DE CONTROLE DE ESTOQUE DO VIA DIGITAL - UM ESTUDO DE CASO. JEANNE LOUIZE EMYGDIO LAVRAS MINAS GERAIS - BRASIL 2007
  2. 2. JEANNE LOUIZE EMYGDIO GERÊNCIA DO DESENVOLVIMENTO DO COMPONENTE SICE – SISTEMA DE CONTROLE DE ESTOQUE DO VIA DIGITAL - UM ESTUDO DE CASO. Monografia apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras, como parte das exigências do curso de Pós-Graduação Lato Sensu em Produção de Software Livre, para a obtenção do título de especialização. Orientadora Prof. Ângela Maria Alves LAVRAS MINAS GERAIS - BRASIL 2007
  3. 3. JEANNE LOUIZE EMYGDIO GERÊNCIA DO DESENVOLVIMENTO DO COMPONENTE SICE – SISTEMA DE CONTROLE DE ESTOQUE DO VIA DIGITAL - UM ESTUDO DE CASO. Monografia apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras, como parte das exigências do curso de Pós-Graduação Lato Sensu em Produção de Software Livre, para a obtenção do título de especialização. APROVADA em 16 de novembro de 2007. Prof. Ângela Maria Alves – UFLA (Orientadora) Prof. Clênio Figueiredo Salviano Prof. Thiago de Souza Rodrigues LAVRAS MINAS GERAIS - BRASIL
  4. 4. Dedico este trabalho à Comunidade Brasileira de Software Livre pelo incentivo e coragem na defesa e utilização deste novo modelo e em especial aos idealizadores do Projeto VIA DIGITAL pela perspicácia em identificar uma solução tão ampla e geradora de impactos extremamente positivos para a nossa sociedade. Esta iniciativa resgata a confiança na capacidade de cada brasileiro como instrumento imprescindível na construção de um país mais digno e de oportunidades mais justas.
  5. 5. AGRADECIMENTOS À Deus e aos amigos espirituais cuja presença de amparo e inspiração foi constante durante toda a elaboração deste trabalho. À minha mãe muito amada, pelo exemplo de coragem e luta para transpor barreiras e progredir com grande força de vontade e caráter. Agradeço por ter despertado em mim o prazer de aprender, o gosto por estudar e transformar a vida ao meu redor a partir da minha transformação pessoal. À Vovó Sebastiana, que do seu jeito simples soube me orientar com bons conselhos, com alegria, com força e que agora marca nossas vidas com a sua presença frágil, porém resistente e perseverante. Obrigada por tudo o que fez por mim. Te amo! Aos meus amores de BH (Papai, Lisa, Lú, Seppe, Tia Anézia) pelo apoio carinhoso e compreensivo independente das ausências em vários momentos, das conversas atropeladas ao telefone, dos bate-papos no gmail e skype, dos silêncios. Amo-os de coração. À minha irmã de coração: a Lili, pelo carinho e dedicação com que me apoiou e cuidou nas horas mais difíceis, nos momentos de esgotamento, nas noites longas de silêncio e esforço, nos finais de semana comprometidos. Sua amabilidade é um convite à pacificação do meu espírito e um presente na minha vida. À Lê, pela sua doçura e alegria irreverente nos momentos mais inesperados. Espero despertar em você a vontade de aprender, de ensinar e de crescer. À professora e orientadora Ângela pela oportunidade de participar deste projeto que tantos resultados positivos já trouxe para mim. Pela importante troca de conhecimentos que realizou conosco, por sua paciência e compreensão em vários momentos. Aos colegas de curso pelo auxílio, em especial ao Roberto, ao Juliano e ao Cláudio pelo companheirismo, humildade, paciência, bom humor e disponibilidade em qualquer hora do dia e das noites (que não foram poucas). Foi um prazer ter conhecido cada um de vocês. Ao Prof. Roberto Porto, Gerente de TI da FAI – Faculdade de Administração e Informática pelo apoio nos momentos mais complicados e por me despertar para o mundo do Software Livre. Você me ofereceu um grande presente. E finalmente, às minhas grandes amigas do Centro de Desenvolvimento e Pesquisa da FAI, Darciane, Cláudia e Fernanda, por me apoiarem durante as ausências e por preencherem os meus dias com alegria, bom humor, disposição para o trabalho e muita competência. Sou fã de vocês!
  6. 6. SUMÁRIO Introdução........................................................................................................................10 Capítulo 1 - Gerência de Projetos....................................................................................12 1.1 - Justificativas e Objetivos....................................................................................12 1.2 – Práticas da gerência de projetos.........................................................................15 1.3 - As melhores práticas do PMBOK......................................................................18 Capítulo 2 - Processos de Desenvolvimento de Software...............................................20 2.1 - Objetivos ............................................................................................................20 2.2 - Rational Unified Process (RUP).........................................................................20 2.3 - Extreme Programming (XP)...............................................................................23 Capítulo 3 - O fenômeno do Software Livre (SL/CA)....................................................29 3.1 - Histórico.............................................................................................................29 3.2 - Modelos de desenvolvimento.............................................................................31 3.3 - Licenças..............................................................................................................35 3.4 - Impactos da Tecnologia de Software Livre........................................................37 Capítulo 4 – Via Digital - inteligência na informatização pública..................................40 4.1 – Motivação, objetivos e oportunidades...............................................................40 4.2 – Componente de Controle de Estoque (SICE)....................................................43 4.2.1 - Abrangência................................................................................................43 4.2.2 - Usuários......................................................................................................44 4.2.3 – Requisitos não funcionais..........................................................................44 4.3 – Aspectos da gerência do SICE: EasyProcess & PMBOK.................................45 4.3.1 – Identificação do escopo do problema.........................................................46 4.3.1.1 - Aplicação no SICE..............................................................................46 4.3.1.2 - Áreas equivalentes do PMBOK..........................................................48 4.3.1.3 - Dificuldades encontradas....................................................................48 4.3.2 – Definição de papéis ...................................................................................49 4.3.2.1 - Aplicação no SICE..............................................................................50 4.3.2.2 - Áreas equivalentes do PMBOK..........................................................51 4.3.2.3 - Dificuldades encontradas....................................................................51 4.3.3 – Conversa com o cliente..............................................................................51 4.3.3.1 - Aplicação no SICE..............................................................................52 4.3.3.2 - Áreas equivalentes do PMBOK..........................................................54 4.3.3.3 - Dificuldades encontradas....................................................................55 4.3.4 – Inicialização...............................................................................................55 4.3.4.1 - Aplicação no SICE..............................................................................55 4.3.4.2 - Áreas equivalentes do PMBOK..........................................................56 4.3.4.3 - Dificuldades encontradas....................................................................56 4.3.5 – Planejamento de releases............................................................................56 4.3.5.1 - Aplicação no SICE..............................................................................57 4.3.5.2 - Áreas equivalentes do PMBOK..........................................................57 4.3.5.3 - Dificuldades encontradas....................................................................57 4.3.6 – Planejamento de iteração............................................................................58 4.3.6.1 - Aplicação no SICE..............................................................................58 4.3.6.2 - Áreas equivalentes do PMBOK..........................................................60 4.3.6.3 - Dificuldades encontradas....................................................................60 4.3.7 – Implementação ..........................................................................................61
  7. 7. 4.3.7.1 - Aplicação no SICE..............................................................................62 4.3.7.2 - Áreas equivalentes do PMBOK..........................................................63 4.3.7.3 - Dificuldades encontradas....................................................................63 4.3.8 – Reuniões de acompanhamento...................................................................64 4.3.8.1 - Aplicação no SICE..............................................................................65 4.3.8.2 - Áreas equivalentes do PMBOK..........................................................66 4.3.8.3 - Dificuldades encontradas....................................................................66 4.3.9 - Fim da iteração com verificação dos testes de aceitação............................67 4.3.9.1 - Aplicação no SICE..............................................................................67 4.3.9.2 - Áreas equivalentes do PMBOK..........................................................68 4.3.9.3 – Análise final de participação..............................................................68 Conclusões.......................................................................................................................69 Referências bibliográficas...............................................................................................72 ANEXOS.........................................................................................................................75 ANEXO A – Entrevistas com o cliente......................................................................76 ANEXO B – Atas de reuniões....................................................................................81 ANEXO C – Ferramental previsto x utilizado no desenvolvimento do SICE............90 ANEXO D – Ferramental de apoio ao desenvolvimento do SICE.............................91 ANEXO E – Easyprocess em síntese..........................................................................92 ANEXO F – Plano de comunicação para o SICE.......................................................94 ANEXO G – Análise de riscos para o SICE...............................................................95 ANEXO H – Atividades da gerência em detalhes......................................................96 ANEXO I – Protótipo do SICE em telas .................................................................106
  8. 8. LISTA DE FIGURAS Figura 1: Relacionamento entre engenharia de processo e de produto e o gerenciamento de projeto.........................................................................................................................14 Figura 2. Ciclos e Fases do RUP.....................................................................................22 Figura 3. Fluxos do RUP.................................................................................................22 Figura 4: Estratégias para o VIA DIGITAL....................................................................42 Figura 5: Síntese do EasyProcess....................................................................................46 Figura 6: Papéis no EasyProcess.....................................................................................50 Figura 7: Página inicial do SICE...................................................................................106 Figura 8: Página de Cadastro de Tipos de Produtos......................................................106 Figura 9: Página de Cadastro de Produtos.....................................................................107
  9. 9. LISTA DE TABELAS Tabela 1: Sub-áreas da Engenharia de Processo.............................................................13 Tabela 2: Sub-áreas da Engenharia de Produto...............................................................13 Tabela 3: Sub-áreas da Gerência de Projetos..................................................................14 Tabela 4: Principais características do RUP....................................................................21 Tabela 5: Fases do RUP...................................................................................................21 Tabela 6. Atividades por Fluxos do RUP........................................................................22 Tabela 7: Valores de XP..................................................................................................24 Tabela 8: Princípios de XP..............................................................................................24 Tabela 9: Práticas de XP..................................................................................................25 Tabela 10: Fases do XP...................................................................................................26 Tabela 11: Etapas do Projeto VIA DIGITAL..................................................................42 Tabela 12: Requisitos não funcionais do SICE...............................................................45 Tabela 13: Pesquisas iniciais sobre o SICE.....................................................................47 Tabela 14: Papéis no EasyProcess...................................................................................49 Tabela 15: Papéis no SICE..............................................................................................50 Tabela 16: Canais de informações para o SICE..............................................................53 Tabela 17: Contatos para o SICE....................................................................................53 Tabela 18: Documentos adicionais do SICE...................................................................54 Tabela 19: Plano de Release............................................................................................57 Tabela 20: Matriz de Competências/Dedicação..............................................................58 Tabela 21: Plano de Iterações..........................................................................................59 Tabela 22: Alocação de Tarefas para Iteração 1..............................................................59 Tabela 23: Cronograma Iteração 1 SICE.........................................................................59 Tabela 24: Plano de Release modificado.........................................................................62 Tabela 25: Plano de Iterações modificado.......................................................................62 Tabela 26: TAT após término da reunião de acompanhamento......................................65
  10. 10. Introdução Este documento apresenta as experiências obtidas por uma equipe de alunos do curso de Produção de Software com Ênfase em Software Livre da UFLA, em torno do desenvolvimento do componente SICE - Sistema de Controle de Estoques do Projeto VIA DIGITAL – uma proposta inovadora para a criação de um serviço auto-sustentável a integrar uma biblioteca de componentes e de software livres voltados à administração pública municipal constituindo elo de ligação entre prefeituras, desenvolvedores, empresas, instituições de apoio e universidades, organizados em torno de modelos de negócio e interação baseados em software livre. O objetivo geral deste estudo foi o de relatar as experiências resultantes das práticas gerenciais que executei para sustentar o desenvolvimento do componente aliadas às iniciativas para a implementação de um processo de desenvolvimento que garantisse maior qualidade à fase de produção e ao software em si e que, ao mesmo tempo, validasse a metodologia prevista para o desenvolvimento do SICE. Visando construir um referencial da visão gerencial sobre todo os aspectos do desenvolvimento para futuros colaboradores, acrescentei de forma geral ao relato, as experiências dos desenvolvedores de acordo os papéis desempenhados, os sucessos e problemas ocorridos, as propostas de melhorias e as aquisições pessoais de cada um após a conclusão do trabalho. Os objetivos específicos foram: ● integrar de forma ativa o Movimento do SL/CA em nosso País através da participação em um projeto de grande relevância como o VIA DIGITAL oferecendo contribuição de valor; ● compartilhar conhecimentos através do trabalho em conjunto com comunidades de desenvolvimento já inseridas neste contexto; ● criar contatos com os demais profissionais da área com interesses e motivações semelhantes construindo assim terreno promissor para a realização de iniciativas futuras que beneficiem diversos segmentos onde for possível a nossa atuação; ● incentivar o uso e implantação de SL/CA na FES – Fundação Educandário Santarritense – situada em Santa Rita do Sapucaí (ensino desde o nível fundamental à Especialização), onde atuo; ● incentivar a elaboração de modelos de negócios em Software Livre para o Centro de Desenvolvimento e Pesquisa da FAI - Faculdade de Administração e Informática, mantida pela Fundação Educandário Santarritense, levando em consideração a sua capacidade de prestação de serviços e sua localização geográfica; ● perceber novas áreas de interesses de acordo com as habilidades pessoais visando novas especializações. 10
  11. 11. O texto que segue possui a seguinte estrutura: No Capítulo 1, Gerência de projetos, o objetivo é apresentar as justificativas e objetivos buscados durante a Gerência de projetos, as principais práticas atualmente executadas dentro das organizações de Desenvolvimento de Software aliadas às melhores práticas previstas pelo Project Management Body of Knowledge (PMBOK ). No Capítulo 2, Processos de Desenvolvimento de Software, o objetivo é apresentar a importância da qualidade do processo e do produto a partir do estudo de dois processos de desenvolvimento mundialmente reconhecidos e utilizados como base para elaboração de diversos outros processos, entre eles o EasyProcess – aplicado no estudo de caso deste trabalho. São eles: O Rational Unified Process (RUP) e o Extreme Programming (XP). No Capítulo 3, O fenômeno do Software Livre (SL/CA), o objetivo é apresentar a dinâmica do Software Livre abordando seus aspectos mais importantes como: histórico, modelos de desenvolvimento, licenças de uso além dos impactos econômicos, tecnológicos, sociais e políticos provenientes da sua implantação e utilização. No Capítulo 4, Via Digital – inteligência na informatização pública, o objetivo é apresentar os motivações, os objetivos e as oportunidades agregadas a este projeto além das experiências práticas obtidas no decorrer do desenvolvimento do Componente SICE. Finalmente, as conclusões recuperam as principais questões analisadas ao longo do trabalho e apresentam os valores acadêmicos, pessoais e profissionais agregados após a execução do projeto bem como suas perspectivas futuras. 11
  12. 12. Capítulo 1 - Gerência de Projetos 1.1 - Justificativas e Objetivos Um crescimento progressivo pode ser observado na indústria de software atual. Os sistemas de software praticamente já fazem parte da vida de todas as pessoas, podendo ser encontrados em diversas atividades cotidianas como nos caixas eletrônicos, caixas de supermercados, terminais de consultas de preços, embutidos em eletrodomésticos ou telefones celulares e agora até mesmo em nossos aparelhos de TV. Tal crescimento resulta em um aumento da complexidade do software e no surgimento de exigências cada vez maiores do mercado. Para garantir a sobrevivência e a competitividade, as empresas devem desenvolver softwares dentro de prazo e custos determinados, atendendo a padrões de qualidade aceitáveis neste mercado agressivo. É neste contexto que se compreende a necessidade do planejamento e do gerenciamento dos projetos de software, que visam garantir a melhor utilização possível de investimentos em recursos humanos, recursos de software e hardware além de recursos materiais diversos para a produção de software que atenda a objetivos específicos (requisitos especificados pelas organizações que estão desenvolvendo e adquirindo o software) evitando desperdícios múltiplos. Ao longo da história, o desenvolvimento de software passou da fase artesanal (definição simples de requisitos e implementação, sem representar grandes problemas para o desenvolvimento de software de pequeno porte), para a fase atual de enfoques estruturados e metódicos baseados nos princípios da Engenharia buscando disciplinar o desenvolvimento de software, englobando aspectos técnicos e não técnicos, de modo a produzir software de qualidade, de forma eficaz e dentro de custos aceitáveis. Surgiu então o termo “Engenharia de Software” que mais tarde foi apoiado pela criação de sub- áreas também necessárias para atender da melhor maneira possível a demanda emergente no desenvolvimento de software, como, por exemplo, Engenharia do Conhecimento, Engenharia de Requisitos, Arquitetura de Software e Sistemas Distribuídos (VASCONCELOS, 2006). As Organizações de Desenvolvimento de Software (ODS) com o objetivo de minimizar os problemas do desenvolvimento de software, embora geralmente adotem metodologias de desenvolvimento, não consideram os aspectos tecnológicos, contextuais e organizacionais que existem dentro de um processo de software, desprezando-os em função de métodos que observam apenas análise/projeto/implementação. Esta atitude tem limitado as ODSs no que diz respeito à tomada de decisões, ao estabelecimento e arquivamento de metas organizacionais, à determinação de pontos para melhoria, à estipulação de prazos para a entrega de produtos e à obtenção de uma certificação. Investimentos significativos têm sido aplicados no setor de tecnologia da 12
  13. 13. informação na busca da excelência na produção de soluções a partir da utilização da Engenharia de Processo, da Engenharia de Produto e do Gerenciamento de Projeto nas ODS. A Engenharia de Processo abrange a definição, implementação, análise, medição (avaliação), gerenciamento, mudança e a melhoria da própria engenharia de processo. Segundo o Guide to the Software Engineering Body of Knowledge (SWEBOK) da IEEE (IEEE, 2004), a Engenharia de Processo pode ser dividida em quatro áreas conforme mostra a Tabela 1: Sub-áreas da Engenharia de Processo. Tabela 1: Sub-áreas da Engenharia de Processo Sub-área Tópicos tratados Implementação do processo e mudança Infra-estrutura do processo; processo de gerenciamento do ciclo de vida do software; modelos para implementação do processo e mudanças; considerações práticas. Definição do processo Tópicos de modelos de ciclo de vida de software; processos de ciclo de vida de software; notações para definição de processos; adaptação e automação de processos. Avaliação do processo Avaliações dos modelos e métodos dos processos. Medição do produto e do processo Medição do processo; medição do produto de software; qualidade dos resultados medidos; modelos de informação de softwares; técnicas de medição de processos. A Engenharia de Produto tem por objetivo a construção do produto de software, através da combinação de codificação, verificação, testes unitários, testes de integração e debugação. Segundo o Guide to the Software Engineering Body of Knowledge (SWEBOK) da IEEE (IEEE, 2004), a Engenharia de Produto pode ser dividida em três sub-áreas conforme mostra a Tabela 2: Sub-áreas da Engenharia de Produto. Tabela 2: Sub-áreas da Engenharia de Produto Sub-área Tópicos tratados Fundamentos da construção de software Minimização da complexidade; antecipação das mudanças; construção para verificação; padrões para construção. Gerenciamento da construção Modelos de construção; planejamento da construção; medição da construção. Considerações práticas Projeto de construção; linguagens de construção; codificação, testes de construção, reuso, qualidade da construção e integração. 13
  14. 14. O Gerenciamento de Projeto tem por objetivo medir, controlar, modificar e gerenciar os projetos de software, ou seja, trata do planejamento das atividades voltadas a assegurar que o software seja entregue dentro do prazo e orçamento previstos e de acordo com os requisitos especificados pelas organizações que estão desenvolvendo e adquirindo o software. Segundo o Guide to the Software Engineering Body of Knowledge (SWEBOK) da IEEE (IEEE, 2004), o Gerenciamento de projetos pode ser dividido em seis sub-áreas conforme mostra a Tabela 3: Sub-áreas da Gerência de Projetos. Tabela 3: Sub-áreas da Gerência de Projetos Sub-área Tópicos tratados Iniciação e definição do escopo Determinação e negociação de requisitos, análises viáveis e processos para revisão de requisitos. Planejamento do projeto de software Planejamento do processo, determinação de liberações, esforço, cronograma e estimativa de custo, alocação de recursos, gerenciamento de riscos, gerenciamento da qualidade e planejamento do gerenciamento. Execução do projeto de software. Planos de implementação, gerenciamento de contratos com fornecedores, implementação de processos de medição, processos de monitoramento, processos de controle e feedback. Revisão e Avaliação Inclui os tópicos de determinação da satisfação dos requisitos e revisão e avaliação de performance. Finalização Encerramento do projeto e das atividades. Gerenciamento da Engenharia de Software. Medição de programas, produtos e processos. A Figura 1: Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto mostra o relacionamento entre estes grupos de atividades. Figura 1: Relacionamento entre engenharia de processo e de produto e o gerenciamento de projeto Fonte: Introdução à Engenharia de Software e à Qualidade de Software 14
  15. 15. 1.2 – Práticas da gerência de projetos As atividades mais comuns da gerência de projetos podem variar em função do porte da ODS, do(s) processo(s) de desenvolvimento adotado(s) por ela e do próprio projeto. Segundo Vasconcelos (VASCONCELOS, 2006), as atividades mais comuns da gerência são: ● Escrever a proposta do projeto: este documento deve conter uma descrição detalhada do que se pretende desenvolver, os objetivos e as restrições, um estudo de viabilidade, uma análise clara dos riscos do projeto, os recursos humanos, materiais e financeiros necessários à sua execução, o tempo previsto para sua conclusão organizado de acordo com as tarefas a serem realizadas além dos mecanismos de acompanhamento e informação. ● Fazer estimativas do projeto (custo, tempo etc.): o cronograma divide o projeto em tarefas e estima o tempo e os recursos requeridos para completar cada tarefa. Sempre que possível, devem ser definidas tarefas concorrentes de modo a fazer o melhor uso do pessoal, além da definição das tarefas independentes, o que evita atrasos. A definição de bons cronogramas depende da intuição e da experiência dos gerentes de projeto, ou seja, não existe uma ciência exata que determine a melhor forma de se construir um cronograma. ● Definir marcos de referência (milestones): um marco de referência é um ponto final, bem definido, de uma etapa ou atividade. A escolha dos marcos de referência e das suas freqüências de produção está relacionada ao modelo de ciclo de vida utilizado no projeto. Por exemplo, num projeto desenvolvido utilizando o ciclo de vida em cascata, ao final de cada etapa de desenvolvimento, pode haver um marco de referência. Nesse caso, um possível marco de referência seria o modelo de análise e projeto, o qual seria produzido ao final da etapa de mesmo nome. Os marcos de referência podem ser também associados à conclusão de uma atividade. Nesse caso, um marco de referência associado a uma atividade da etapa de análise e projeto poderia ser a produção de um diagrama específico do modelo, como, por exemplo, um diagrama de classes, produzido por uma atividade associada a essa etapa de desenvolvimento. Por outro lado, um produto a ser entregue ao cliente (“deliverable”) diferencia- se do marco de referência justamente pelo fato de que nem todos os marcos de referência são entregues ao cliente. Ou seja, produtos são marcos de referência, mas marcos de referência não são necessariamente produtos. ● Analisar os riscos: um risco é uma probabilidade de que alguma circunstância adversa aconteça. O gerenciamento de riscos trata da identificação dos riscos e da preparação de planos para minimizar os seus efeitos no projeto. Riscos podem ser classificados de acordo com vários critérios. Uma possível 15
  16. 16. classificação seria: ● Riscos de projeto: afetam cronogramas ou recursos; ● Riscos de produto: afetam a qualidade ou desempenho do software que é desenvolvido; ● Riscos de negócio: afetam a organização que está desenvolvendo ou adquirindo o software. O processo de gerenciamento de riscos pode ser dividido nas seguintes atividades: ● Identificação dos riscos: identificar os riscos de projeto, produto e negócio. Esses riscos podem estar associados à escolha da tecnologia, das pessoas, mudanças de requisitos, estimativas do projeto etc.; ● Análise dos riscos: avaliar a probabilidade (por exemplo: muito baixa, baixa, moderada, alta ou muito alta.) e as conseqüências (por exemplo: catastrófica, séria, tolerável ou insignificante) dos riscos; ● Planejamento dos riscos: preparar planos, definindo estratégias para gerenciar os riscos. As estratégias podem ser: ● estratégias para evitar o risco: a probabilidade de que o risco surja é reduzida. ● estratégias para minimizar o risco: o impacto do risco no projeto ou no produto será reduzido. ● planos de contingência: se o risco surgir, os planos de contingência tratarão aquele risco; ● Monitoramento dos riscos: monitorar os riscos ao longo do projeto, identificando regularmente para decidir se ele está se tornando menos ou mais provável. Também avalia se as conseqüências do risco têm se modificado. Cada risco-chave deve ser discutido nas reuniões de progresso do gerenciamento. ● Fazer o planejamento e o cronograma do projeto: atividade contínua, desde a concepção inicial do sistema, até a sua entrega. Os planos devem ser revisados regularmente, à medida que novas informações se tornam disponíveis. Caso seja necessário, os planos devem ser atualizados. O plano de projeto é um documento que descreve as atividades, os recursos e o cronograma usados para o desenvolvimento do sistema. As atividades relacionadas ao cronograma encontram-se citadas acima. ● Selecionar e avaliar pessoal: nem sempre é possível conseguir as pessoas ideais para trabalharem num projeto devido a limitações, tais como: ● orçamento de projeto pode não permitir o uso de pessoal altamente qualificado e, conseqüentemente, bem pago; ● pessoal com experiência apropriada pode não estar disponível; ● pode fazer parte da política da organização desenvolver as habilidades dos empregados durante um projeto de software. Ou seja, projetos podem ser usados como forma de treinar o pessoal. 16
  17. 17. Assim, gerentes têm de alocar o pessoal disponível, dentro das restrições impostas. Muitas vezes, também é papel do gerente participar da seleção para a contratação de pessoal para um projeto. Além das atividades supracitadas, outras ainda são previstas, tais como: fazer acompanhamentos e revisões constantes para garantir o bom andamento do projeto; escrever os relatórios de acompanhamento (por ex.: Status Report) que relatam aos superiores e clientes a situação atual do projeto, problemas encontrados e mudanças estratégicas; fazer apresentações sobre o projeto. Atualmente, de acordo com diversas pesquisas realizadas nesta área a maior causa de falhas ocorridas em projetos de software são decorrentes de gerência incorreta ou mesmo pobre, realizada informalmente, sem métodos ou técnicas. Dentre as maiores dificuldades encontradas no gerenciamento de projetos pode-se citar: ● a ausência de práticas administrativas no desenvolvimento de software resultando em atrasos em cronogramas, custo maior do que o esperado e presença de defeitos, ocasionando uma série de inconveniências para os usuários e enorme perda de tempo e de recursos; ● planejamento (quando ocorre) é feito de forma superficial sem domínio de como a idéia modelada, pode ser transformada em produto; ● gerentes de projeto desacostumados a estimar, ou realizando estimativas com base em projetos passados nem sempre bem sucedidos; ● falta de conhecimento e recursos por parte das ODSs para realizar boas estimativas de custo, esforço e prazo de software. Estas estimativas requerem um processo ordenado que defina a utilização de métricas de software, método e ferramenta de estimativa; ● estimar, medir e controlar um projeto de software é tarefa difícil, pois o desenvolvimento de software é uma atividade criativa e intelectual, com muitas variáveis envolvidas (como metodologias, modelos de ciclo de vida, técnicas, ferramentas, tecnologia, recursos e atividades diversas). Gerentes inexperientes tentam cumprir prazos dando a máxima velocidade na fase inicial e estão despreparados para os momentos de impasse, quando os ajustes são inevitáveis. ● a dinamicidade do processo de software dificulta também o gerenciamento efetivo de projetos de software, devido às alterações constantes nos planos de projetos, redistribuição de atividades, inclusão/exclusão de atividades, adaptação de cronogramas, realocação de recursos, novos acordos com os clientes, entregas intermediárias não previstas etc.; ● um projeto de software também deve adaptar-se ao ambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades do pessoal ou equipe. O estudo da Gerência de Projetos nos dias atuais não acontece sem uma abordagem ao PMBOK – Project Management Body of Knowledge, criado pelo PMI – Project Management Institute, uma associação de profissionais de gerenciamento de projetos existente desde 1969 e que foi responsável por elaborar este guia que descreve a somatória de conhecimentos e as melhores práticas dentro da profissão de gerenciamento de projetos conforme nos apresenta a próxima seção. 17
  18. 18. 1.3 - As melhores práticas do PMBOK O PMBOK organiza os processos de gerenciamento de projetos em cinco grupos: processos de inicialização, processos de planejamento, processos de execução, processos de controle e processos de encerramento (PMIMG,2002). Os processos de inicialização autorizam o início do projeto ou de uma fase do projeto. Os processos de planejamento definem e refinam os objetivos do projeto selecionando as melhores alternativas para realizá-lo. Os processos de execução coordenam pessoas e outros recursos para a realização do projeto, baseando-se no planejamento. Os processos de controle monitoram e medem o progresso do que está sendo executado, com o intuito de tomar ações corretivas, quando necessárias. Os processos de finalização formalizam o aceite e a finalização do projeto ou de uma fase do projeto. Os processos do PMBOK estão organizados por áreas de conhecimento, que se referem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentro dessas áreas de conhecimento os cinco grupos de processos acima descritos podem ocorrer. Todos os processos descritos a seguir interagem uns com os outros e também com os processos das demais áreas de conhecimento. Cada processo pode: envolver esforço de um ou mais indivíduos ou grupos de indivíduos dependendo das necessidades do projeto e geralmente, ocorrer pelo menos uma vez em cada fase do projeto. Gerência de integração: A gerência de integração engloba os processos necessários para garantir que os vários elementos de um projeto sejam propriamente coordenados. Objetiva realizar as negociações dos conflitos entre objetivos e alternativas do projeto, com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a execução do plano de projeto e o controle geral das mudanças. Gerência de escopo de projetos: A gerência do escopo do projeto inclui os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário, para complementar de forma bem sucedida o projeto. A preocupação fundamental compreende definir e controlar o que está ou não incluído no projeto. Gerência de tempo de projetos: A gerência de tempo do projeto objetiva garantir o término do projeto no tempo certo. Consiste da definição, ordenação e estimativa de duração das atividades, e de elaboração e controle de cronogramas. Gerência de custos de projetos: A gerência de custo tem por objetivo garantir que o projeto seja executado dentro do orçamento aprovado. Consiste no planejamento dos recursos, estimativa, orçamento e controle de custos. Gerência de qualidade de projetos: A gerência da qualidade objetiva garantir que o projeto satisfará as exigências para as quais foi contratado. Consiste de planejamento, 18
  19. 19. garantia e controle de qualidade. Gerência de recursos humanos de projetos: A gerência de recursos humanos objetiva garantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste de planejamento organizacional, alocação de pessoal e definição de equipe. Gerência de comunicação de projetos: A gerência de comunicação tem por objetivo principal garantir a geração adequada e apropriada, coleta, disseminação, armazenamento e disponibilização da informação. Gerência de riscos de projetos: A gerência de risco objetiva maximizar os resultados de ocorrências positivas e minimizar as conseqüências de ocorrências negativas. Consiste de identificação, quantificação, tratamento e controle dos riscos do projeto. Gerência de aquisição de projetos: A gerência de aquisição tem por objetivo principal obter bens e serviços externos à organização executora. Consiste na seleção de fornecedores, planejamento de aquisição, planejamento de solicitação, solicitação de propostas, e administração e encerramento de contratos. Embora o sucesso ou fracasso de um projeto esteja diretamente relacionado à gerência estabelecida, o gerenciamento de software ainda é pouco abordado e praticado nas Organizações de Desenvolvimento de Softwares (ODS). A introdução de padrões e normas tem se mostrado complexa demais, além de causar uma sobrecarga de trabalho significativa. Porém, dentro da realidade atual da indústria de software nacional, observa-se uma busca crescente pela qualidade dos produtos e serviços oferecidos, através da adoção de processos de desenvolvimento que visam, além de estabelecer normas e padrões, amadurecer as ODSs e fortalecê-las tornando-as capazes de competir no mercado internacional. 19
  20. 20. Capítulo 2 - Processos de Desenvolvimento de Software 2.1 - Objetivos Garantir a excelência nos softwares produzidos dentro de prazos e custos mínimos de forma a promover alta competitividade às organizações é o grande desafio atual da indústria nacional de software. Em outras palavras, é preciso promover a qualidade e perseguí-la durante todo o processo de desenvolvimento dos sistemas de software, de forma a atender um mercado cada vez mais exigente e complexo. Neste contexto, torna-se imprescindível o conhecimento e aplicação da Engenharia de Software, cujos fundamentos científicos envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantido suas qualidades (Leite,2007). Segundo (Abib,1999) uma das evoluções mais importantes no estudo da Qualidade está em notar que a Qualidade do produto é algo bom, mas que a Qualidade do processo de produção é ainda mais importante. Voltando nossos olhos para o desenvolvimento de software, constatamos então que a avaliação da qualidade de um software está diretamente relacionada com a qualidade dos processos e metodologias utilizadas para o seu desenvolvimento, o que torna imprescindível a cada organização preocupada em manter a competitividade, a escolha sensata e adequada do melhor processo de desenvolvimento que atenda aos seus objetivos, cultura e projetos. As próximas seções, baseadas no trabalho do Professor Alexandre Marcos Lins de Vasconcelos (VASCONCELOS,2005), apresentam dois processos de desenvolvimento de software mundialmente reconhecidos e utilizados na elaboração de diversos outros processos de desenvolvimento de software, entre eles o EasyProcess – o processo aplicado no estudo de caso abordado neste trabalho. São eles: Rational Unified Process (RUP) e o Extreme Programming (XP). 2.2 - Rational Unified Process (RUP) O RUP – Rational Unified Process é um processo de software genérico que fornece uma abordagem disciplinada para assinalar tarefas e responsabilidades dentro do contexto do projeto, de modo a atender todo o ciclo de desenvolvimento de software de alta qualidade. Este processo foi desenvolvido com o propósito de padronizar o processo de desenvolvimento de software, e para tanto, utiliza o melhor de várias técnicas de desenvolvimento de software e a UML – Unified Modeling Language, podendo ser utilizado em uma grande faixa de projetos e organizações. Através dos conceitos “Responsável”, “Atividade”, “Artefato”, “Fluxo” e “Subfluxo” é possível compreender, respectivamente, no contexto do projeto: o comportamento/responsabilidades/papel desempenhado por um indivíduo/equipe; a 20
  21. 21. unidade de trabalho desempenhada por um responsável e que produz um resultado significante; a peça de informação que é produzida/modifica/usada pelo processo de desenvolvimento de software; a sequência de atividades que produz um resultado de valor observável, e por fim, o agrupamento de atividades, responsáveis envolvidos, artefatos de entrada e artefatos produzidos, utilizados para fornecer um alto nível de abstração e para estruturar um fluxo. A Tabela 4 mostra as principais características do RUP. Tabela 4: Principais características do RUP Característica Descrição Dirigido a Casos de Uso (funções) Identificação dos atores, das funcionalidades do sistema e a interação entre os dois, a reunião de todos os casos de usos necessários para a construção do sistema denomina-se Modelo de Casos de Uso e orienta todas as atividades do processo de desenvolvimento. Centrado na Arquitetura (forma) Visão do projeto como um todo, tornando visível as características mais importantes. Todo produto tem funções e forma, que devem ser balanceadas para o seu sucesso. No caso de software, funções correspondem a Casos de Uso e a forma à Arquitetura. Iterativo e Incremental Organização em ciclos ou mini-projetos que se constituem em iterações (passos no fluxo do desenvolvimento – etapas) que por sua vez, resultam em incrementos (evolução do produto – versões). A cada iteração concluída o desenvolvimento procede para a próxima iteração. O RUP repete uma série de ciclos de evolução durante o processo de desenvolvimento de um sistema. Cada ciclo termina com uma versão do produto e consiste de quatro fases cujas características principais são relacionadas na Tabela 5: Fases do RUP. Tabela 5: Fases do RUP Fase Característica Concepção Fase de formulação do planejamento do projeto e do escopo; definição de uma arquitetura candidata e seleção das ferramentas para desenvolvimento. Elaboração Fase de definição e validação da arquitetura; refinamento da visão do cliente/usuário sobre o produto a ser desenvolvido; criação de planos de iteração detalhados para a fase de Construção; refinamento da arquitetura e seleção de componentes. Construção Fase de implementação propriamente dita abrangendo as atividades essenciais de gerenciamento de recursos; complemento do desenvolvimento de componentes e testes; avaliação das versões do produto. Transição Fase cujas atividades essenciais envolvem a execução dos planos de implantação; finalização do material de suporte ao usuário final; criação de versões do produto; obtenção de feedback do usuário; melhoramento do produto baseado no feedback; disponibilização dos produtos para os usuários finais. 21
  22. 22. Cada fase é dividida em iterações, conforme mostra a Figura 2 - Ciclo e Fases do RUP: Figura 2. Ciclos e Fases do RUP Fonte: Processos de Desenvolvimento de Software 1 Os fluxos do RUP apresentam-se basicamente organizados em dois tipos: Fluxos de Processo e Fluxos de Suporte, conforme mostra a Figura 3. Fluxos do RUP: Figura 3. Fluxos do RUP Fonte: Processos de Desenvolvimento de Software 1 A Tabela 6: Atividades por Fluxos do RUP mostra as atividades previstas para cada fluxo. Tabela 6. Atividades por Fluxos do RUP Fluxo Atividade Propósito De Processo Modelagem de negócios Diagnóstico da organização (conhecimento dos processos, dinâmica e problemas); identificação de melhorias; proporcionar aos stakeholders uma visão comum da organização. Requisitos Especificação clara dos requisitos do sistema; identificação 22
  23. 23. Fluxo Atividade Propósito de seus limites (restrições); informações para estimação de custos e tempo; criação de protótipos. Análise e Projeto Transformar os requisitos em um projeto de sistema; definir uma arquitetura robusta para o sistema; adaptar o projeto para o ambiente de implementação. Implementação Definir a organização do código; implementar classes e objetos; testar os componentes desenvolvidos; integrar os resultados produzidos em um sistema executável. Testes Verificar a integração entre objetos; verificar a integração formal de todos os componentes do software; verificar se todos os requisitos foram corretamente implementados; identificar e garantir que defeitos sejam resolvidos antes da implantação. Implantação Produção de versões do sistema e a entrega do software para os usuários finais. De Suporte Gerenciamento de Configuração e Mudanças Controlar as mudanças e manter a integridade dos artefatos do projeto. Gerenciamento de Projeto Fornecer um framework para gerenciamento de projetos de software; fornecer guias práticos para planejamento, recrutamento de pessoal, execução e monitoração de projetos; fornecer um framework para o gerenciamento de riscos. Ambiente Fornecer a organização e um ambiente (processos e ferramentas) de desenvolvimento do software, que darão suporte à equipe de desenvolvimento. 2.3 - Extreme Programming (XP) O Extreme Programming (XP) é um processo ágil de desenvolvimento de software que vem se mostrando eficiente em projetos onde os requisitos são constantemente modificados, os ciclos de desenvolvimento são curtos e as equipes que implementam o projeto são pequenas. Resultou da experiência em um projeto denominado C3 Payroll da empresa Chrysler, cujo sucesso despontou no meio acadêmico e empresarial, tornando-se alvo de inúmeras pesquisas e discussões. Baseado em práticas que objetivam entregar funcionalidades de forma rápida e eficiente ao cliente, o XP foi criado considerando que mudanças são inevitáveis e devem ser incorporadas constantemente, para tanto utiliza-se dos seguintes valores (norteadores das pessoas envolvidas no desenvolvimento de software) e princípios (subsídios para escolha de alternativas de solução de problemas durante o curso do projeto) cujas características principais foram sintetizadas nas Tabelas 7: Valores de XP e 8: Princípios de XP. 23
  24. 24. Tabela 7: Valores de XP Valores Descrição Comunicação Construir entendimento do problema pessoa-a-pessoa com uso mínimo de documentação formal e uso máximo de interação “cara-a-cara” entre as pessoas envolvidas no projeto. Simplicidade Sugerir que cada membro da equipe adote a solução mais fácil que possa funcionar, criando ambiente cujo custo de mudanças seja baixo no futuro. Feedback Fornecer feedback para programadores através dos casos de testes e para os clientes através dos testes funcionais. Coragem Ter coragem necessária para que se aplique XP como deve ser aplicado em atitudes que podem trazer melhorias ao projeto. Tabela 8: Princípios de XP Princípios Descrição Feedback rápido Os participantes de um projeto como clientes, programadores e gerentes devem estar sempre se comunicando para facilitar o aprendizado coletivo sobre o projeto que está sendo desenvolvido, sanar dúvidas, riscos e problemas de modo a facilitar ações de contingência. Assumir simplicidade Todo problema deve ser tratado para ser resolvido da forma mais simples possível. Mudança incremental As mudanças devem ser incrementais e feitas aos poucos. Abraçando mudanças As mudanças devem ser sempre bem-vindas independente do estágio de evolução do projeto. Trabalho de qualidade O sistema deve atender aos requisitos do cliente, rodar 100% dos casos de teste e agregar o maior valor possível para o negócio do cliente. O XP possui uma estrutura principal cujo funcionamento pode ser compreendido através do conhecimento de doze práticas que consistem no núcleo principal do processo e que foram criadas com base nos ideais pregados pelos valores e princípios apresentados. A Tabela 9: Práticas de XP mostra em síntese as práticas de XP. Tabela 9: Práticas de XP Valores Descrição O jogo do planejamento Esta técnica estabelece que os planejamentos de um release e das iterações devem ser feitos com base nas estórias (casos de uso simplificados) e contar com a colaboração de toda a equipe de desenvolvimento, inclusive o cliente. Observam-se 2 papéis: • Negócio: pessoas que entendem do negócio e tem capacidade de 24
  25. 25. Valores Descrição priorizar o desenvolvimento das funcionalidades; • Técnico: desenvolvedores que irão estimar esforço e riscos. No final de um release refaz-se o ciclo. Um release consiste de várias iterações e, em cada iteração, vários casos de uso são implementados. O Gerente facilita a coleta de métricas, divulga-as àqueles cujo trabalho está sendo medido e intervém em situações peculiares. Releases pequenos Esta técnica estabelece que cada release deve ser tão pequeno quanto possível, contendo os requisitos mais importantes para o negócio. Sugere-se que os releases sejam de curta duração, normalmente de 2 a 3 meses. Metáfora Esta técnica estabelece que deve-se utilizar as metáforas com o objetivo de oferecer uma visão geral do sistema, em um formato simples, que possa ser compartilhado por clientes e programadores. Projeto Simples Esta técnica estabelece que devem ser projetadas as funcionalidades que já foram definidas e não as que poderão ser definidas futuramente e deve ser feito o melhor projeto que possa entregar tais funcionalidades. Testes constantes Esta técnica estabelece a forma de aplicação dos testes em XP. Existem 2 tipos de teste: teste de unidade (feitos para verificar tudo o que possa dar errado) e teste funcional (utilizados para verificação, junto ao cliente, do sistema como um todo). Refatoramento Esta técnica estabelece que devem ser aplicados uma série de passos para melhorar o projeto do código existente, tornando-o mais simples e melhor estruturado, sem alterar sua funcionalidade. Programação em pares Esta técnica estabelece que todo código produzido em XP deve ser escrito por um par de programadores com os papéis respectivos de codificação/lógica de programação e otimização do código produzido. As duplas e os papéis são trocados para que todos os membros da equipe tenham conhecimento sobre todas as partes do sistema. Propriedade coletiva do código Esta técnica encoraja a equipe inteira a trabalhar mais unida em busca de qualidade no código, fazendo melhorias e refatoramentos em qualquer parte do código a qualquer tempo. É necessário manter o padrão de codificação e realizar todos os testes para que se garanta a qualidade do software em desenvolvimento. Integração contínua Esta técnica estabelece que o código das funcionalidades implementadas pode ser integrado várias vezes ao dia, desde que não existam erros, quando então deverão ser corrigidos. Semana quarenta horas Esta regra sinaliza a preocupação com desgastes da equipe em períodos excessivos de trabalho que podem gerar queda da qualidade do código em virtude do cansaço e insatisfação pelas horas extras. 25
  26. 26. Valores Descrição Cliente no local Esta técnica estabelece que deve ser incluída na equipe uma pessoa da parte do cliente, que irá usar o sistema, para trabalhar junto com os outros e responder as perguntas e dúvidas. Padrões de codificação Esta regra estabelece a necessidade de se ter padrões de codificação para que as regras de refatoramento e propriedade coletiva do código sejam aplicadas satisfatoriamente. O XP atravessa algumas fases durante o seu ciclo de vida que por sua vez são compostas de diversas tarefas. A Tabela 10: Fases do XP mostra as principais fases de um projeto utilizando XP de modo a se ter uma idéia de como ele flui ao longo do tempo. Tabela 10: Fases do XP Fase Característica Exploração Compreende o levantamento de possíveis soluções e sua viabilidade; elaboração de arquiteturas considerando todo o ambiente tecnológico onde o sistema irá rodar. Ao se obter um número de estórias suficientes inicia-se a construção do primeiro release. Planejamento inicial Esta fase é utilizada para que os clientes concordem em uma data para lançamento do primeiro release. Os programadores juntamente com os clientes escolhem as estórias, identificam quantas podem implementar em uma iteração. Os clientes priorizam as mais importantes e o processo então se repete até terminar as iterações do release. Iterações do release Esta fase compreende o momento de escrita dos casos de teste funcionais e de unidade. Os programadores seguem mais ou menos o seguinte fluxo de atividades na seguinte ordem: escrita dos casos de teste; projeto e refatoramento; codificação; realização de testes e integração. Manutenção Esta fase pode ser considerada como uma característica inerente a um projeto XP. Em XP faz-se simultaneamente a produção de novas funcionalidades e a manutenção do sistema em funcionamento através da incorporação de novas pessoas na equipe e do melhoramento do código. Morte Esta fase compreende o término de um projeto XP, podendo se dar por duas razões: cliente satisfeito com o sistema e não enxerga novas funcionalidades ou o projeto tornou-se economicamente inviável devido a dificuldades de se adicionar funcionalidades a baixo custo e alta taxa de erros. Os papéis envolvidos em XP incluem o gerente, o programador, o cliente, o testador e o consultor com as seguintes atribuições: ● A gerência em XP é dividida em dois papéis: o treinador (coach) e o rastreador (tracker). O treinador se preocupa principalmente com a execução técnica e evolução do processo. O rastreador coleta métricas sobre o que está sendo desenvolvido e confronta com as métricas estimadas verificando possíveis divergências; ● O programador ocupa o principal papel em XP, analisando, projetando, testando, codificando e integrando o sistema, além de estimar a dificuldade dos casos de 26
  27. 27. uso e fazer alterações nessas estimativas, caso necessário; ● O cliente escolhe o que vai agregar valor ao seu negócio, prioriza e define com a ajuda dos testadores os testes funcionais; ● O testador auxilia o cliente na definição e escrita dos testes funcionais; ● O consultor se apresenta em situações complexas por possuir nível de conhecimento superior em determinado assunto que não está sendo compreendido pelas pessoas do projeto. Alguns fatores, embora constituam fortes indicadores para a não utilização de XP, não constituem seus limites exatos, mas devem ser seriamente considerados durante uma análise para sua adoção. São eles: a cultura de desenvolvimento de software de uma organização, o tamanho da equipe de desenvolvimento, a tecnologia, a organização do espaço físico e a disponibilidade do cliente para participação ativa no projeto. Outro problema encontrado nos ambientes de desenvolvimento de software e sinalizados por Gruhn (GRUHN, 2002) reside no fato de que, quando uma ODS opta por utilizar processos de desenvolvimento de software, geralmente trabalha com foco em apenas um processo, o que inviabiliza, por exemplo a execução de projetos cujas características não se adaptem às práticas previstas no processo adotado pela ODS. Gruhn sinaliza a importância do conhecimento de ambientes de desenvolvimento de software mais flexíveis, que suportem a aplicação de uma grande variedade de processos, aumentando assim a produtividade da ODS e a qualidade no processo de desenvolvimento e do produto gerado. Os Ambientes de Desenvolvimento de Software centrados em Processos, atuam de duas formas: ora parametrizando os principais processos de desenvolvimento de software através da definição de ferramentas adequadas à sua aplicação; ora, partindo de modelos de processos, definindo quais atividades do desenvolvimento devem ser realizadas, quando e por quem, além de quais ferramentas utilizar e o formato dos documentos a serem criados e/ou manipulados pela equipe. A necessidade de investimentos em ferramentas, infra-estrutura e capacitação aumenta a preocupação em relação às formas de obtenção dos recursos financeiros e ao retorno deste investimento. O Software Livre, por suas características, modelos de desenvolvimentos e pelos impactos econômicos, sociais e tecnológicos que promove representa uma expectativa extremamente positiva sobre este retorno conforme nos apresenta o próximo capítulo. 27
  28. 28. Capítulo 3 - O fenômeno do Software Livre (SL/CA) Hoje, com o considerável movimento financeiro gerado pela comercialização de licenças e a grande preocupação da comunidade científica em garantir a qualidade dos produtos de softwares criados, o que capacita as indústrias nacionais a concorrerem no mercado internacional, a filosofia de desenvolvimento de Software Livre, baseada na formação de comunidades informais de desenvolvimento, na distribuição livre de executáveis e códigos fonte apoiada por uma licença de distribuição própria que garante liberdades completamente contraditórias ao que conhecemos até então, tomou a proporção de um fenômeno que desperta o interesse, a polêmica e o debate acirrado entre a área científica, o setor privado, os órgãos governamentais e os profissionais liberais da área de computação, que buscam compreender os impactos causados por esta filosofia no campo científico, social, econômico e profissional no País e no mundo. Para se compreender o que significa Software Livre é preciso conhecer os conceitos e a filosofia que sustentam essa nova realidade, descritos a seguir, tendo como base o trabalho da Profª Ângela Maria Alves (Alves,2005). Os próximos tópicos irão tratar da História do Software Livre, dos Modelos de Desenvolvimento em fase de elaboração, das Licenças utilizadas, além dos impactos econômicos e sociais provenientes de sua adoção. 3.1 - Histórico Os anos 60 marcaram o início histórico do desenvolvimento de Software Livre a partir da criação do sistema Operacional UNIX. Nesta época não havia a preocupação com direitos autorais e de propriedade por não haver um mercado estruturado para a comercialização de licenças de software. O foco dos fornecedores de tecnologia era o hardware, o que permitia um trabalho colaborativo entre as comunidades de desenvolvimento, as universidades, instituições de pesquisa e empresas. Os sistemas eram muitas vezes fornecidos como uma parte integrante do hardware. A interação entre os diversos atores envolvidos na criação do Unix caracterizou historicamente a primeira comunidade colaborativa de desenvolvimento. A distribuição gratuita do código fonte deste projeto pela AT&T às universidades, fez com que o Unix fosse considerado o primeiro Software Livre no contexto histórico da informática. Os conceitos sobre os quais o Unix foi desenvolvido: portabilidade, simplicidade e eficiência, são características que justificaram o fato de ter se tornado a base dos sistemas operacionais livres mais populares hoje, como o GNU/Linux e os sistemas da linha Berkley Software Distribution – BSD. A partir da segunda metade da década de 70, em virtude da evolução da indústria de informática e a dissociação entre o software e o hardware, houve um movimento progressivo de fechamento dos códigos, sendo que no início dos anos 80, salvo algumas exceções, praticamente todo o software era fechado e proprietário. Quando a comercialização de licenças começou a tomar corpo, gerou as primeiras motivações para um movimento organizado pelo Software Livre. 28
  29. 29. Uma grande e histórica iniciativa ocorreu em 1983, quando Richard Stallman (atual presidente) criou a Free Software Foundation (FSF) que é hoje a principal organização dedicada à produção e à divulgação do Software Livre, tendo como objetivo promover na comunidade de informática o espírito colaborativo que prevalecia em seus primórdios, onde as informações códigos e métodos de trabalhos eram livremente compartilhados. Grandes opiniões aqueciam o discurso de Stallman e pouco a pouco faziam crescer o Movimento de Software Livre: “Software proprietário implica numa organização social onde não é permitido às pessoas compartilharem conhecimento, não é permitido ajudar o próximo e incita à competição ao invés da colaboração.” “O custo marginal de distribuição e reprodução de software é próximo do zero. Uma vez pagos os custos de desenvolvimento, restringir o acesso ao software traz muito mais malefícios do que benefícios.” “Como os programas proprietários são fechados é negado às pessoas melhorar suas funcionalidades de forma a atender a necessidades específicas.” “É prejudicado o desenvolvimento de software de maneira geral, uma vez que a cada novo projeto proprietário é necessário redesenvolver várias tecnologias que eventualmente já tenham sido criadas e estão inacessíveis por serem fechadas.” “Fechar o software é negar o acesso à informação e ao conhecimento, elementos sem os quais é impossível construir uma sociedade justa e democrática.” (Alves (Alves,2005) apud Stallman [STA1999]). O esforço inicial de Stallman, era o de criar um Sistema Operacional completo, cujo nome seria GNU (Gnu is Not UNIX – Gnu não é UNIX). Esse sistema tinha a intenção de ser um clone do UNIX, mas dessa vez totalmente livre de código proprietário (todo o código seria reescrito). De forma visionária, Stallman buscou colaboradores entre os profissionais da área e divulgou entre os usuários as vantagens provenientes da utilização de sistemas livres tal como podemos observar em nossa realidade atual. Em 1991, o Sistema Operacional GNU estava praticamente pronto, no entanto, faltava um componente de suma importância: o núcleo. Paralelamente a este desenvolvimento, um jovem finlandês de 21 anos de idade, chamado Linus Torvalds desenvolveu uma versão inicial de um núcleo de sistema operacional compatível com o Unix. Lançou-o publicamente e com a ajuda da comunidade foram adicionadas funcionalidades necessárias a um núcleo de uso real. Com a divulgação dos projetos GNU e Linux em desenvolvimentos paralelos e sendo projetos complementares, promoveu-se rapidamente a sua integração, dando origem ao primeiro Sistema Operacional totalmente livre para a arquitetura Intel x86: o GNU/Linux. Por sua característica livre, em poucos anos atingiu funcionalidades e estabilidades comparáveis a sistemas operacionais proprietários já consolidados. Em 1989 a FSF criou a Licença GPL – General Public License que constituiu-se em uma das grandes contribuições do Projeto GNU. Hoje é a licença mais utilizada em projetos de Software Livre, dando amparo legal e formalizando a ideologia que permeia 29
  30. 30. o movimento. Novas comunidades de desenvolvimento surgiram durante a criação do Sistema Operacional GNU da FSF e durante o desenvolvimento do Núcleo do Linux. Segundo Silveira, o GNU/Linux baseia-se nos esforços de mais de 400 mil desenvolvedores espalhados pelos cinco continentes e por mais de 90 países. “Dificilmente uma empresa privada terá condições de acompanhar o ritmo de inovações incrementais de uma rede tão variada e tão inteligente.” (Silveira, 2005). Dentro do Movimento de Software Livre é possível encontrar duas denominações para os softwares desenvolvidos: Software Livre (SL) e Código aberto (CA). Ambos são traduções diretas dos termos utilizados em inglês: “free software” e “open source software”. Ambas as denominações contêm similaridades e diferenças e significam mudanças substantivas na indústria de software, seja do ponto de vista do usuário final, do desenvolvedor de software ou de outros agentes relacionados. Em linhas gerais Código aberto enfatiza os aspectos do processo e da organização, enquanto Software Livre enfatiza os aspectos de livre redistribuição e troca de conhecimento. Para facilitar a compreensão do desenvolvimento de Software Livre é imprescindível se conhecer o seu modelo de desenvolvimento, que mesmo estando ainda em fase de modelagem, nos dá uma idéia do trabalho dos colaboradores e da organização em si. 3.2 - Modelos de desenvolvimento Para atribuir credibilidade a um sistema de software leva-se em conta a engenharia utilizada em seu desenvolvimento, o perfil profissional dos líderes e desenvolvedores envolvidos além da tecnologia utilizada para a sua implementação. Métricas de qualidade são aplicadas sobre todos os processos para mensurar a qualidade do produto final. Apesar desta descrição nos remeter a idéia do processo de produção de software proprietário a realidade atual do processo de desenvolvimento de Software Livre já apresenta grandes características similares que aumentam a credibilidade nestas soluções. Segundo Alves, Eric Raymon, autor da publicação mais popular sobre Software Livre - o livro The Cathedral and the Bazaar, compara dois estilos opostos de desenvolvimento de Software Livre, a Catedral, que descreve projetos de Software Livre desenvolvidos por grupos fechados, com pequena abertura para participação externa; e o Bazar, que descreve projetos desenvolvidos de forma mais transparente, abertos à participação de qualquer desenvolvedor que tenha interesse. A Catedral é tratada por Raymond como uma forma conservadora e tradicionalista de desenvolvimento. Característico deste tipo de projeto são os longos ciclos de desenvolvimento e o grande intervalo de tempo entre lançamentos de versões públicas. O GNU Emacs pode ser citado como projetos desenvolvidos neste modelo. O Bazar por sua vez é descrito como sendo um projeto colaborativo, aberto a ponto da promiscuidade – usuários estão livres e são bem-vindos a participar e opinar sobre o desenvolvimento em qualquer fase. Lançamentos ocorrem frequentemente e um grande número de olhos tem acesso ao código fonte, permitindo que erros e regressões 30
  31. 31. sejam rapidamente avaliados e informados. O Linux e o Fetchmail são exemplos de projetos desenvolvidos neste modelo. Raymond cita ainda alguns pontos fundamentais a respeito do desenvolvimento de Software Livre, tais como: a importância de ter muitos usuários com acesso ao código fonte do ponto de vista da qualidade; e a prática de oferecer aos usuários a oportunidade de testar freqüentemente os códigos mais recentes. No entanto muitas críticas colocam restrições com relação ao cisma radical do modelo, já que as diferenças entre o Bazar e a Catedral não são tão evidentes; além disso questiona-se o que significa fazer disponibilizações freqüentes tendo em visto que o contexto atual do Software Livre é de acesso quase instantâneo do código. Apesar das críticas, o trabalho de Raymond é importante por ser pioneiro na descrição da ontologia de projetos de Software Livre, e por incluir conhecimentos oriundos da experiência de Raymond durante o desenvolvimento do Fetchmail. Diversos questionamentos e análises tem sido feitas ao modelo de desenvolvimento de Software Livre, dentre as mais relevantes descritas em artigos técnicos citam-se: ● Como Software Livre obtém êxito tendo como base a dificuldade de comunicação existente no desenvolvimento distribuído (tão similar ao Software Livre), e que acarreta defeitos, problemas de integração, falta de coordenação, custos elevados e eficiência baixa? ● Como obter confiabilidade, tendo como base a ineficiência do trabalho simultâneo de pessoas sobre o mesmo código? ● Como é possível que desenvolvedores gostem de dar manutenção, ler e estudar código alheio, e trabalhar sem remuneração, já que historicamente têm se ao contrário? ● O que dizer da despreocupação da comunidade Software Livre com relação ao processo de software e em particular a inexistência ou desatualização das ferramentas de desenvolvimento? Algumas conclusões foram obtidas através de estudos de grandes projetos em Software Livre como o caso do Núcleo Linux, do Projeto Mozilla e do Free BSD. Sobre o núcleo do Linux: ● A evolução parece ser não direcionada e não existe planejamento top down além de um consenso interno de que as descrições devem ser técnicas e excelentes; ● O crescimento do Linux é linear e não mostra sinais de redução, o que contraria estudos anteriores, que diz que o ritmo de desenvolvimento diminui a medida que se tornam mais complexo; ● O núcleo tem alto acoplamento e este cresce exponencialmente à medida que o núcleo cresce, mas o seu desenvolvimento continua normalmente até hoje. Sobre o Projeto Mozilla: 31
  32. 32. ● São descritos os mecanismos de revisão e aprovação formal de alterações, o que é raramente encontrado de maneira tão formal em outros projetos; ● Por causa do produto final ser para usuário final, há problemas de determinação dos requisitos de interface e usabilidade; ● O projeto Mozilla usa e oferece uma série de ferramentas para apoiar o processo de desenvolvimento de software, das quais se destaca: Bonsai, Bugzilla e LXR. Sobre o Free BSD: ● O diferencial do processo é sua grande escala: ele possuí mais de 200 pessoas que podem integrar o código fonte no repositório central e com isso sugere complexidade de gerenciamento muito alta; ● Boa parte dos problemas de gerenciamento é resolvida pelo fato do nome do autor e da alteração estar publicamente vinculados ao código. Apesar de uma idéia inicialmente caótica no modelo de desenvolvimento de Software Livre, um Projeto de Software Livre é uma organização composta por um conjunto de pessoas que usa e desenvolve um único software, contribuindo para uma base comum de código fonte e conhecimento. Este grupo terá à sua disposição ferramentas de comunicação e trabalho colaborativo, e um conjunto de experiências e opiniões técnicas que usam para discutir o andamento do projeto. Esta tríade: software, comunidade e ferramentas são muito bem organizadas conforme as descrições a seguir: Software: Por definição, o código fonte que o projeto produz é distribuído através de uma licença de Software Livre. Esta base de código é freqüentemente mantida em um repositório público de onde qualquer pessoa pode copiá-la. Alterações nesta base são normalmente feitas por um grupo pequeno de pessoas, em muitos casos por uma pessoa só, que é chamada de maintainer ou mantenedor. A base de código inicial é normalmente escrita por uma pessoa isoladamente, e lançada através de uma mensagem enviada para uma lista de discussão ou em um arquivo on-line de projetos, como os sites freshmeat.net ou sourceforge.net. O código fonte, possivelmente acompanhado de versão pré-compiladas para arquiteturas e distribuições específicas, é normalmente oferecido a um repositório Internet através de Web ou FTP. Normalmente o desenvolvimento é feito de forma isolada; cada desenvolvedor cria alterações ao código fonte localmente. Uma vez decidido que a alteração é correta e desejável o processo de integração é iniciado. Se o desenvolvedor tem permissão para escrever código diretamente no repositório, faz a integração pessoalmente; caso contrário envia sua alteração para outro que tem autoridade o suficiente para integrá-la. Durante este processo, é comum que diversas pessoas discutam a alteração e que ela seja revisada e mesmo reescrita caso necessário; isto ocorre tanto na fase pré-integração como pós-integração. Este ciclo se repete para cada alteração a ser introduzida na base de código fonte. Comunidade: As pessoas envolvidas em um projeto podem ter sua participação 32
  33. 33. classificada pelo tipo de papel que exercem: ● Usuários não-participantes: sem interesse em discutir ou ajudar no desenvolvimento do software; fazem teste funcional do software, mas em geral não informam erros quando os encontram. ● Usuários participantes: ativamente contribuem para o projeto informando problemas e discutindo a funcionalidade desejada. São responsáveis por boa parte do teste funcional, provendo feedback para os autores em relação a regressões e inconsistências. ● Desenvolvedores esporádicos: usuários com conhecimento de programação e disposição para alterar código fonte e produzir alterações. Normalmente suas alterações terão caráter localizado, reparando um pequeno defeito ou implementando uma pequena extensão de funcionalidade. ● Desenvolvedores ativos: aqueles que têm responsabilidade por módulos do código fonte ou por implementar funcionalidade mais extensa ou mais complexa. Entre estes, normalmente figura o autor original como mantenedor central. É importante observar que esta divisão não e rígida; pessoas podem migrar de um papel para outro conforme escolha e oportunidade pessoal. Para coordenar o trabalho que realizam, os membros da comunidade de um projeto utilizam a Internet através de ferramentas simples amplamente disponíveis como o correio eletrônico, páginas Web, listas de discussão, em conjunto com ferramentas de desenvolvimento de software, controle de versão e acompanhamento de defeitos. Comunicação escrita: Os membros da comunidade se comunicam normalmente através de listas de correio eletrônico, podendo alguns projetos utilizar adicionalmente repositórios públicos de defeitos e formas de comunicação em tempo real. Em geral, usuários participantes usam estes veículos para comunicar experiências, problemas e solicitações. Também fazem suporte de primeira ordem, ajudando outros usuários com problemas comuns. Gerência do código-fonte: Para armazenar a base de código do projeto, normalmente é usada uma ferramenta de controle de versões. É freqüente o uso da ferramenta CVS apesar de suas limitações reconhecidas, a ferramenta aparentemente tem uso maciço por ser bastante simples e ter ampla disponibilidade. Repositório: Um repositório CVS consiste de um conjunto de arquivos mantido em um local central; normalmente é armazenado em um servidor conectado à Internet, que permite acesso anônimo, evitando que usuários que queiram acessar o código fonte tenham que se registrar. O repositório permite cópia local, integração, geração de versões e geração de branches instáveis e estáveis. Apoio ao processo de desenvolvimento: podem ser classificadas em Ferramentas de Desenvolvimento, Ferramentas de Configuração e compilação (autoheader, autoconf, automake e make), Visualização de código fonte (ViewCVS e 33
  34. 34. CVSWeb), Acompanhamento de defeitos (ou alterações) (Bugzilla e Gnats). Serviços de hospedagem de projetos: após advento do pioneiro site Web Sourceforge.net, conta-se com algumas opções gratuitas para hospedar um projeto de Software Livre. Os serviços de hospedagem públicos oferecem interface via Web para manipulação dos serviços individuais dos projetos. Outro aspecto importante em relação ao Software Livre reside nas características específicas que ora aproximam e ora distanciam cada licença de uso existente no Movimento. 3.3 - Licenças As leis de direitos autorais foram criadas para permitir aos autores explorar comercialmente suas criações, recompensando-os por seu esforço e estimulando outras inovações. Existem basicamente dois tipos de propriedade intelectual: o direito autoral e o direito de patentes. Os direitos autorais podem ser patrimoniais (copyright), que tratam de negociação da obra, e morais que tratam do direito do autor de ter seu nome ligado a obra. São inalienáveis e irrenunciáveis. O direito à patente é a concessão pelo Estado de um monopólio de exploração, de uma invenção ou de um novo processo de produção, por um determinado período de tempo. Após esse período as especificações tornam-se públicas. No Domínio Público, o autor renuncia aos seus direitos patrimoniais, não podendo tomar qualquer decisão, ou impor qualquer restrição quanto ao seu uso, produção de cópias e distribuição. Em 1989 foi criada pela FSF, a GNU GPL (General Public License), com o objetivo de evitar que desenvolvedores de software proprietário se apropriassem dos softwares livres (o que protegeu a comunidade), tendo em vista que nos Estados Unidos é legalmente permitido patentear os softwares desenvolvidos. A esse tipo de licenciamento deu-se o nome de copyleft, que obriga os trabalhos derivados de Software Livre a serem Software Livre também. A GPL foi a primeira licença de Software Livre criada e possui como características básicas a garantia da liberdade de uso, alteração e distribuição de softwares e a de que qualquer trabalho derivado também seja licenciado sobre as mesmas condições. É um instrumento legal para proteger os direitos e fazer com que outros não tenham a opção de removê-los. Possui exigências, restrições fundamentais e adicionais. Em termos gerais e GPL baseia-se em 4 liberdades: ● de executar o programa; ● de estudar seu funcionamento e adaptá-lo para as suas necessidades ou de terceiros; 34
  35. 35. ● de distribuir livremente cópias do programa original; ● de distribuir cópias de versões modificadas de forma que toda a comunidade possa se beneficiar das melhorias introduzidas. E abrange 2 restrições fundamentais: ● todos os trabalhos derivados devem necessariamente estar licenciados pela GPL; ● não é permitida a alteração das condições da licença. Um software então, é considerado “livre” se os usuários dispõem de todas essas liberdades. Essa seria a essência do Software Livre. Sua origem tem motivações ideológicas e sua proposta altera substantivamente as condições nas quais um programa de computador pode ser desenvolvido e, mais que isso, utilizado (SOFTEX,2005). Além da GPL, a FSF mantém mais duas licenças: ● LGPL (Lesser General Public): criada para uso com componentes chamados bibliotecas. Não é copyleft. É recomendada para casos específicos em que não haja outra alternativa; ● FDL (Free Documentation License): refere-se a liberdade de documentação. É copyleft. Tem uma estrutura enxuta e simples oposta a GPL, permitindo a redistribuição e uso do programa na forma binária e código fonte com ou sem modificações. Suas únicas restrições são: ● no código fonte deve ser mantido o aviso de copyright original identificando o autor; ● na distribuição binária deve se manter o copyright na documentação e o nome do autor não pode se utilizado em versões modificadas do programa. Por não ter componente filosófico ou social, enquadra-se no movimento do código aberto contrariando a FSF que a considera prejudicial por não incentivar a produção de mais Software Livre. Existem ainda duas outras licenças em uso em se tratando de Software Livre: ● a MPL (Mozilla Public License) foi elaborada pela NetScape para a distribuição do código Mozilla (Navegador de Internet).É bem similar à GPL, porém, bem mais orientada a empresas. ● a SCSL (Sun Community Source License) não pode ser considerada como uma licença livre porque não atende diversos pontos fundamentais para o código aberto. Dentre os quais a SUN tem controle sobre modificações. Em contrapartida a comunidade de Software Livre está lançando projetos similares ao da SUN, porém o usuário tem controle completo do desenvolvimento e da política de distribuição. Licenças como a GNU GPL e BSD podem ser utilizadas, conforme tratado internacional. Para adequar à legislação brasileira estão sendo utilizadas duas iniciativas 35
  36. 36. de construção de licenças, sendo a primeira a criação da LPG – Licença Pública Geral (adaptação da GNU GPL) e a segunda iniciativa criada em dezembro de 2003, adota as licenças Creative Commons GPL e LGPL como oficiais para todo Software Livre desenvolvido pelo governo. O próximo tópico apresenta a situação do Software Livre perante a comunidade empresarial, incluindo os principais motivos que hoje poderiam interferir na escolha das empresas pelo processo livre de desenvolvimento, tais como: a diferenciação competitiva, a necessidade de manutenção do segredo do negócio e a questão da segurança. Problemas solucionáveis através da análise da empresa dos reais valores internos que ela possui e que lhe conferem competitividade, independente do software ou serviços utilizados/comercializados ou prestados; otimizações na metodologia de desenvolvimento e a necessidade de previsão de erros nos software produzidos. Grandes gigantes do mercado de TI têm adotado o Software Livre garantindo a segurança em seu uso, como é o caso da Silicon Graphics, a IBM, a Oracle e a Sun Microsystems. 3.4 - Impactos da Tecnologia de Software Livre No meio empresarial persiste a dúvida sobre a sustentabilidade econômica e técnica do Software Livre. Sobre a sustentabilidade econômica, questiona-se se as liberdades de acesso ao código e de não comercialização de licenças podem viabilizar modelos de negócios sustentáveis para as empresas fornecedoras. Sobre a sustentabilidade do modelo de desenvolvimento, questiona-se se as empresas poderiam basear seus negócios neste tipo de software sem enfrentar problemas de continuidade, evolução e suporte. Outra questão gira em torno do financiamento de seu desenvolvimento, uma vez que não há rendas através da comercialização de licenças. A vantagem na opção pelo Software Livre, neste caso, reside em três importantes fatores: 1. os custos de sua produção (amortizadores) tendem a ser mais baratos devido ao grande reaproveitamento do conhecimento pré-existente e da facilidade de integração com outros módulos produtos prontos. 2. os custos de distribuição e reprodução (marginais) passaram a ser próximos do zero em função do advento da internet que permite facilidade e rapidez neste processo. 3. uma parte dos financiamentos para produção do Software Livre são assumidos por pessoas físicas e os motivos para isso podem ser diversão, uso profissional, reconhecimento, aprendizagem técnica e por motivos ideológicos. O software, neste modelo de desenvolvimento é visto como um bem de informação, que ao invés de ter um valor comercial em si, tem valor nos benefícios trazidos com a sua utilização. Desta forma, um software sob uma licença livre pode ser útil para várias empresas ou indivíduos, que podem melhorar, adicionar funcionalidades e resolver problemas, além de prestar inúmeros serviços relacionados aos softwares que mantém. Raymond sustenta que na maioria dos casos, não há motivos para manter 36
  37. 37. programas fechados mas descreve três razões pelas quais as empresas poderiam preferir manter seus códigos desta forma: 1. o software talvez seja um fator de diferenciação competitiva da empresa. Raymond sustenta que a maioria das empresas que toma essa decisão subestima seus benefícios, ou seja, a maior parte dos resultados supera muitas expectativas iniciais. 2. necessidade de manutenção de segredos de negócio. Esse problema pode ser resolvido separando-se o software básico do módulo que contém as regras de negócios. 3. segurança. Essa segurança chamada de obscurantismo é fortemente criticada por especialistas, porque muitas falhas podem ser descobertas somente no uso e impede a prevenção de códigos maliciosos ou estruturas camufladas. Algumas empresas têm contribuindo para aumentar a credibilidade no uso do Software Livre, através da criação e participação em diversos projetos relevantes, tais como: o sistema Compiere da Compiere Inec, os sistema de arquivos XFS da SGI, Star Office da Sun e a participação da IBM e Oracle no desenvolvimento do núcleo do Linux. No portal Código Livre há diversos projetos tornados livres, executados por brasileiros. Para sustentar o uso empresarial do Software Livre são necessários modelos de negócios viáveis e principalmente rentáveis, já que a venda em si não faz sentido. As empresas interessadas em atuar neste mercado deverão se reestruturar estrategicamente e encontrar formas criativas e inovadoras que garantam sua sobrevivência, tendo como base sua experiência de mercado e a inteligência reunida em sua equipe empresarial e tecnológica. Raymond sugere os seguintes modelos para sustentar negócios baseados em Software Livre: ● Base para produto proprietário: um Software Livre é utilizado como base para o desenvolvimento de um produto proprietário com características exclusivas. Como é o caso do Mac OS X. ● Prestação de serviços: é o ramo mais utilizado para obtenção de receitas com Software Livre. Dentre as opções citam-se: alterações em programas existentes, consultorias e treinamentos. ● Venda de acessórios: livros, revistas, apostilas e conjuntos de software. ● Uso embarcado do Software Livre: evitando gastos com desenvolvimento de um novo sistema para o hardware. Além da redução dos custos (grande motivador para o uso do Software Livre), outros benefícios podem ser obtidos a partir de sua adoção: ● maior qualidade, estabilidade, desempenho, segurança e rapidez no desenvolvimento e correções de novos produtos de software. ● personalização do software, para atender as necessidades específicas de cada 37
  38. 38. usuário, empresa ou instituições diversas (educacionais ou não); ● possibilidade de evitar monopólio, garantindo que o novo software desenvolvido utilize padrões abertos. ● garantia contra descontinuidade. O Software Livre é um exemplo notável de organização em grupo. As expectativas para seu desenvolvimento futuro são interessantes e percebe-se uma tendência de aumento em seu uso e do reconhecimento de sua estabilidade e segurança. No entanto, todas essas questões são desconhecidas pelo público empresarial e até mesmo por grande parte dos gestores de TI. “Os mais de 20 anos de evolução permitiram ao SL/CA avançar em diversos aspectos: técnico, político-estratégico, adequação às necessidades dos usuários, qualidade, segurança, etc. Esta evolução é resultado de um conjunto heterogêneo de eventos, atores e perspectivas. O processo tem por premissa a criação de grandes comunidades de prática, em que há engajamento em torno de um domínio comum no qual, em alguns casos, ocorre a socialização de conhecimento e de práticas. Esta dinâmica envolve o desenvolvimento de software (e de material relacionado, como documentação), difusão, estímulo e apoio ao uso de SL/CA, que chega até uma visão e ação empresarial, que encontra no SL/CA uma importante opção de crescimento.” (Softex, 2005). No Brasil, a partir do incentivo e exemplo do Governo Federal, inúmeras iniciativas tem promovido o uso do Software Livre por um número cada vez crescente de empresas, profissionais liberais e voluntários (pessoas comuns) como ferramenta para “afirmação de nossa cidadania, de nossa inteligência coletiva, de redução: da dependência tecnológica, do pagamento de royalties ao Primeiro Mundo” (IdBrasil,2006), e da miséria, através de oportunidades criativas de compartilhamento do conhecimento conforme apresenta o próximo capítulo. 38
  39. 39. Capítulo 4 – Via Digital - inteligência na informatização pública 4.1 – Motivação, objetivos e oportunidades O retrato atual das Prefeituras Brasileiras apresenta uma realidade irônica: enquanto a população demanda de forma crescente mais qualidade e transparência nos serviços que a administração pública lhe presta, esta por sua vez, se vê incapacitada de pleitear financiamentos oficiais para informatização e para obras e ações necessárias, exatamente por não possuir recursos tecnológicos que a auxiliem a demonstrar amplamente as suas pretensões. Este contexto onde se destacam a falta de recursos financeiros para a realização de altos investimentos em tecnologia, e a urgência na aquisição de tecnologias de ponta a preços acessíveis e com qualidade suficiente para reverter o estado caótico em que se encontra a administração pública no Brasil, veio de encontro ao aumento da popularização do software livre no país, amplamente apoiado e incentivado inclusive pelo próprio Governo Federal através de vários programas e projetos implementados em âmbito nacional. Tais circunstâncias aliadas à profissionalização do SL/CA, apontaram- no como uma alternativa muito promissora para solucionar os problemas detectados. Com vistas a analisar os resultados obtidos a partir dessa informatização, a Sociedade Softex em parceria com o ITI – Instituto Nacional de Tecnologia da Informação realizou em 2004 uma ampla pesquisa sobre a adoção de software livre nas Prefeituras Brasileiras enfocando principalmente as condições de financiamento para esses processos de informatização, a apuração dos benefícios diretos e indiretos de sua adoção e os arranjos que se mostraram mais eficazes. Ao todo foram contactadas mais de 5.500 prefeituras sendo 90% delas de pequeno porte, com dificuldades de acesso a programas de financiamento de informatização e todas sujeitas a leis de licitações e responsabilidade fiscal que induzem ao uso de software proprietário (SOFTEX, 2005). Levando-se em consideração que o Brasil possui um forte mercado consumidor e produtor de software, o objetivo maior da pesquisa foi o de promover uma reflexão sobre as possibilidades e oportunidades trazidas pelo Software Livre não só para a informatização da administração pública, mas também para a própria indústria nacional de software. Software Livre pertence à indústria de software. Nela se desenvolve e a transforma. Os modelos de negócios do software livre são os modelos de negócios da indústria de software. O SL/CA tem, assim, poder de modificar padrões de concorrência dentro da própria indústria, e é exatamente isso que vem fazendo. (SOFTEX,2005a) A partir dos resultados obtidos em uma amostra de 13 municípios, pode-se 39
  40. 40. observar que o uso de software livre propiciou redução da ilegalidade no uso de software, redução de custos, redirecionamento de recursos não gastos com licenças para a melhoria do parque instalado - melhor aproveitamento de hardwares, maior autonomia tecnológica, maior transparência da gestão, segurança, independência de fornecedores e estabilidade. Uma necessidade fundamental foi detectada por todos os municípios: a da existência de um repositório comum, de livre acesso às prefeituras onde estivessem disponíveis informações importantes sobre diversos aspectos da informatização, software livre disponível, avaliação de ferramentas por parte de especialistas, melhores práticas, fornecedores e profissionais capacitados, etc. (SOFTEX,2005a) Tal constatação propiciou a oportunidade de criação do projeto VIA DIGITAL orientado pelo bem social com base na informatização pública (foco para as pequenas prefeituras) apoiado em duas grandes tendências - a componentização (engenharia de software baseada em componentes – ESBC) e o Software Livre. O projeto, inicialmente denominado FLOPREF (Free/ Livre/ Open Software para prefeituras), tendo como órgão financiador a Financiadora de Estudos e Projetos/Fundo Nacional de Desenvolvimento Científico e Tecnológico (FINEP/ FNDCT) (VIADIGITAL, 2007), foi idealizado pelo Agente Softex de Florianópolis ( GeNESS ) da Universidade Federal de Santa Catarina ( UFSC ) em parceria com: ● o Agente Softex de Campina Grande ( CGSOFT ) da Universidade Federal de Campina Grande ( UFCG ), Paraíba; ● o Observatório Digital da Sociedade Softex, Campinas-SP; ● o Centro de Pesquisas Renato Archer/MCT ( CenPRA ), Campinas-SP e ● a empresa OpenS Tecnologia, Florianópolis – SC. Sua característica inovadora reside na proposta de criação de um serviço auto- sustentável que integre uma biblioteca de componentes e de software livres voltados à administração pública municipal constituindo elo de ligação entre prefeituras, desenvolvedores, empresas, instituições de apoio e universidades, organizados em torno de modelos de negócio e interação baseados em software livre. A biblioteca de componentes será ponto de referência: ● para abastecer empresas com software livre pré-formatado para necessidades comuns de prefeituras e componentes genéricos para montagem de sistemas mais específicos, de acordo com características próprias dos municípios; ● para busca e difusão de informações sobre a dinâmica do software livre, tanto para funcionários de prefeituras quanto para desenvolvedores, integradores e fornecedores de soluções/serviços para o poder público. Incluindo-se licenciamento, direitos autorais, modelos de negócio, modelos e ferramentas de desenvolvimento de software e gestão de projetos, qualidade de software, 40
  41. 41. capacitação e financiamentos. A Figura 4: Estratégias para o VIA DIGITAL ilustra a organização proposta. Figura 4: Estratégias para o VIA DIGITAL. Fonte: Projeto FLOPREF Brasil Informatizado A execução do projeto foi planejada em duas etapas com atividades e objetivos apresentados na Tabela 11: Etapas do Projeto VIA DIGITAL. Tabela 11: Etapas do Projeto VIA DIGITAL Etapa Atividades Objetivo Projeto Piloto ● desenvolver e operacionalizar uma metodologia de indução de produção e uso de componentes de software reutilizáveis a partir de um repositório – a Biblioteca de Componentes; ● seleção dos atores (5 “sistemas” apropriados (prefeituras, empresas, profissionais e agentes) (LUCCA,2005)) e contratação, com recursos aprovados pela FINEP; ● desenvolvimento de software das empresas para as prefeituras. Testar uma metodologia de indução do processo para em seguida expandi-la. Projeto Expansão (será definido somente após a avaliação dos resultados do Projeto Piloto). ● aplicação prática de uma estratégia paralela de sensibilização de prefeituras frente ao uso da Biblioteca de Componentes e em relação às fontes de financiamento público à informatização; ● desenvolver meios para capacitar as prefeituras a receber tais recursos em troca de que sua contratação ocorra condicionando a compra a disponibilização do software na Biblioteca de Componentes. Expandir a metodologia utilizada na fase de testes e apoiar a informatização de um número muito maior de prefeituras. 41
  42. 42. Diversos modelos de interação entre as partes envolvidas foram criados e avaliados. Foram formalizados processos de avaliação de processos e de componentes e a conceituação de ecossistemas locais de desenvolvimento. Encontra-se em desenvolvimento um experimento piloto para a constituição de ecossistemas em cinco cidades (Patos-PB, Recreio-MG, Amparo-SP, Santa Clara do Sul-RS e Canela-RS), com o desenvolvimento dos componentes: ● SIAPA - SISTEMA DE ACOMPANHAMENTO DE PROGRAMAS ASSISTENCIAIS - Canela (RS); ● SINFRA - SISTEMA DE INFRA-ESTRUTURA - Patos (PB); ● SICE - SISTEMA DE CONTROLE DE ESTOQUE - Recreio (MG); ● SIPAF - SISTEMA DE PLANEJAMENTO E ACOMPANHAMENTO DE FROTA - Amparo (SP). Paralelamente tem sido realizados experimentos com o envolvimento de universidades, a partir da motivação de estudantes de graduação e pós-graduação para participarem do desenvolvimento de requisitos pré-especificados para os componentes citados. Graças a essa estratégia organizada em torno do VIA DIGITAL, fomos convidados pela Consultora Ângela Maria Alves, também Coordenadora e Professora do curso de Produção de Software com Ênfase em Software Livre da Universidade Federal de Lavras (UFLA), a fazermos parte desta história. Nas próximas seções serão detalhados o componente SICE, escolhido pela equipe da qual fiz parte, e os aspectos de sua gerência realizados de forma a aplicar simultaneamente o processo de desenvolvimento definido para o projeto e os conceitos aprendidos durante o curso sobre a gerência segundo o PMBOK. 4.2 – Componente de Controle de Estoque (SICE) De acordo com o Documento de Requisitos disponibilizado juntamente com o Edital do projeto (SWFACTORY, 2006), o objetivo deste componente é possibilitar o controle da entrada e saída de produtos do almoxarifado, permitindo que estes sejam vinculados ao patrimônio da Prefeitura de Recreio (MG). Para tanto, a qualquer momento são oferecidas informações sobre o estoque do almoxarifado e sobre o patrimônio. 4.2.1 - Abrangência O sistema deverá permitir o cadastro de todos os produtos (pertencentes ao patrimônio ou não) que possam ficar armazenados no estoque da Prefeitura, sendo estes classificados através do atributo ’Tipo’ vinculado a cada produto. Estes tipos serão cadastrados previamente pelo usuário e poderão, por exemplo, classificar os produtos em bens móveis, bens imóveis, bens de natureza industrial, entre outros. Após o cadastro do produto, o usuário digitador poderá cadastrar os produtos que irão entrar no estoque através da Nota Fiscal de Compra ou através de outra categoria de entrada. Considerando que caso existam produtos na Nota Fiscal que ainda não estejam no sistema, estes deverão ser cadastrados, através do requisito inserir produto. Para efetivar a entrada física de produtos no estoque, o responsável pelo estoque, 42

×