tcc do curso de produção de software livre - ufla 2007

UNIVERSIDADE FEDERAL DE LAVRAS

GERÊNCIA DO DESENVOLVIMENTO DOCOMPONENTE SICE – SISTEMA DECONTROLE DE ESTOQUE DO VIA DIGITAL -UM ESTUDO DE CASO.

JEANNE LOUIZE EMYGDIO

LAVRASMINAS GERAIS - BRASIL

2007



Monografia apresentada ao Departamento deCiência da Computação da UniversidadeFederal de Lavras, como parte das exigênciasdo curso de Pós-Graduação Lato Sensu emProdução de Software Livre, para a obtençãodo título de especialização.

OrientadoraProf. Ângela Maria Alves


2007



Monografia apresentada ao Departamento deCiência da Computação da UniversidadeFederal de Lavras, como parte dasexigências do curso de Pós-GraduaçãoLato Sensu em Produção de SoftwareLivre, para a obtenção do título deespecialização.

APROVADA em 16 de novembro de 2007.

Prof. Ângela Maria Alves – UFLA (Orientadora)

Prof. Clênio Figueiredo Salviano

Prof. Thiago de Souza Rodrigues


Dedico este trabalho à Comunidade Brasileira deSoftware Livre pelo incentivo e coragem na defesa e utilização

deste novo modelo e em especial aos idealizadores doProjeto VIA DIGITAL pela perspicácia em identificar uma solução tão ampla e

geradora de impactos extremamente positivos para a nossa sociedade. Esta iniciativaresgata 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.

AGRADECIMENTOS

À Deus e aos amigos espirituais cuja presença de amparo e inspiração foi constantedurante toda a elaboração deste trabalho.

À minha mãe muito amada, pelo exemplo de coragem e luta para transpor barreiras eprogredir com grande força de vontade e caráter. Agradeço por ter despertado em mim oprazer de aprender, o gosto por estudar e transformar a vida ao meu redor a partir daminha 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émresistente 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 ecompreensivo independente das ausências em vários momentos, das conversasatropeladas ao telefone, dos bate-papos no gmail e skype, dos silêncios. Amo-os decoração.

À minha irmã de coração: a Lili, pelo carinho e dedicação com que me apoiou e cuidounas horas mais difíceis, nos momentos de esgotamento, nas noites longas de silêncio eesforç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. Esperodespertar em você a vontade de aprender, de ensinar e de crescer.

À professora e orientadora Ângela pela oportunidade de participar deste projeto quetantos resultados positivos já trouxe para mim. Pela importante troca de conhecimentosque 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 pelocompanheirismo, humildade, paciência, bom humor e disponibilidade em qualquer horado dia e das noites (que não foram poucas). Foi um prazer ter conhecido cada um devocês.

Ao Prof. Roberto Porto, Gerente de TI da FAI – Faculdade de Administração eInformática pelo apoio nos momentos mais complicados e por me despertar para omundo do Software Livre. Você me ofereceu um grande presente.

E finalmente, às minhas grandes amigas do Centro de Desenvolvimento e Pesquisa daFAI, Darciane, Cláudia e Fernanda, por me apoiarem durante as ausências e porpreencherem os meus dias com alegria, bom humor, disposição para o trabalho e muitacompetência. Sou fã de vocês!

SUMÁRIOIntrodução........................................................................................................................10Capítulo 1 - Gerência de Projetos....................................................................................12

1.1 - Justificativas e Objetivos....................................................................................121.2 – Práticas da gerência de projetos.........................................................................151.3 - As melhores práticas do PMBOK......................................................................18

Capítulo 2 - Processos de Desenvolvimento de Software...............................................202.1 - Objetivos ............................................................................................................202.2 - Rational Unified Process (RUP).........................................................................202.3 - Extreme Programming (XP)...............................................................................23

Capítulo 3 - O fenômeno do Software Livre (SL/CA)....................................................293.1 - Histórico.............................................................................................................293.2 - Modelos de desenvolvimento.............................................................................313.3 - Licenças..............................................................................................................353.4 - Impactos da Tecnologia de Software Livre........................................................37

Capítulo 4 – Via Digital - inteligência na informatização pública..................................404.1 – Motivação, objetivos e oportunidades...............................................................404.2 – Componente de Controle de Estoque (SICE)....................................................43

4.2.1 - Abrangência................................................................................................434.2.2 - Usuários......................................................................................................444.2.3 – Requisitos não funcionais..........................................................................44

4.3 – Aspectos da gerência do SICE: EasyProcess & PMBOK.................................454.3.1 – Identificação do escopo do problema.........................................................46

4.3.1.1 - Aplicação no SICE..............................................................................464.3.1.2 - Áreas equivalentes do PMBOK..........................................................484.3.1.3 - Dificuldades encontradas....................................................................48

4.3.2 – Definição de papéis ...................................................................................494.3.2.1 - Aplicação no SICE..............................................................................504.3.2.2 - Áreas equivalentes do PMBOK..........................................................514.3.2.3 - Dificuldades encontradas....................................................................51

4.3.3 – Conversa com o cliente..............................................................................514.3.3.1 - Aplicação no SICE..............................................................................524.3.3.2 - Áreas equivalentes do PMBOK..........................................................544.3.3.3 - Dificuldades encontradas....................................................................55

4.3.4 – Inicialização...............................................................................................554.3.4.1 - Aplicação no SICE..............................................................................554.3.4.2 - Áreas equivalentes do PMBOK..........................................................564.3.4.3 - Dificuldades encontradas....................................................................56

4.3.5 – Planejamento de releases............................................................................564.3.5.1 - Aplicação no SICE..............................................................................574.3.5.2 - Áreas equivalentes do PMBOK..........................................................574.3.5.3 - Dificuldades encontradas....................................................................57

4.3.6 – Planejamento de iteração............................................................................584.3.6.1 - Aplicação no SICE..............................................................................584.3.6.2 - Áreas equivalentes do PMBOK..........................................................604.3.6.3 - Dificuldades encontradas....................................................................60

4.3.7 – Implementação ..........................................................................................61

4.3.7.1 - Aplicação no SICE..............................................................................624.3.7.2 - Áreas equivalentes do PMBOK..........................................................634.3.7.3 - Dificuldades encontradas....................................................................63

4.3.8 – Reuniões de acompanhamento...................................................................644.3.8.1 - Aplicação no SICE..............................................................................654.3.8.2 - Áreas equivalentes do PMBOK..........................................................664.3.8.3 - Dificuldades encontradas....................................................................66

4.3.9 - Fim da iteração com verificação dos testes de aceitação............................674.3.9.1 - Aplicação no SICE..............................................................................674.3.9.2 - Áreas equivalentes do PMBOK..........................................................684.3.9.3 – Análise final de participação..............................................................68

Conclusões.......................................................................................................................69Referências bibliográficas...............................................................................................72ANEXOS.........................................................................................................................75

ANEXO A – Entrevistas com o cliente......................................................................76ANEXO B – Atas de reuniões....................................................................................81ANEXO C – Ferramental previsto x utilizado no desenvolvimento do SICE............90ANEXO D – Ferramental de apoio ao desenvolvimento do SICE.............................91ANEXO E – Easyprocess em síntese..........................................................................92ANEXO F – Plano de comunicação para o SICE.......................................................94ANEXO G – Análise de riscos para o SICE...............................................................95ANEXO H – Atividades da gerência em detalhes......................................................96ANEXO I – Protótipo do SICE em telas .................................................................106

LISTA DE FIGURASFigura 1: Relacionamento entre engenharia de processo e de produto e o gerenciamento de projeto.........................................................................................................................14Figura 2. Ciclos e Fases do RUP.....................................................................................22Figura 3. Fluxos do RUP.................................................................................................22Figura 4: Estratégias para o VIA DIGITAL....................................................................42Figura 5: Síntese do EasyProcess....................................................................................46Figura 6: Papéis no EasyProcess.....................................................................................50Figura 7: Página inicial do SICE...................................................................................106Figura 8: Página de Cadastro de Tipos de Produtos......................................................106Figura 9: Página de Cadastro de Produtos.....................................................................107

LISTA DE TABELASTabela 1: Sub-áreas da Engenharia de Processo.............................................................13Tabela 2: Sub-áreas da Engenharia de Produto...............................................................13Tabela 3: Sub-áreas da Gerência de Projetos..................................................................14Tabela 4: Principais características do RUP....................................................................21Tabela 5: Fases do RUP...................................................................................................21Tabela 6. Atividades por Fluxos do RUP........................................................................22Tabela 7: Valores de XP..................................................................................................24Tabela 8: Princípios de XP..............................................................................................24Tabela 9: Práticas de XP..................................................................................................25Tabela 10: Fases do XP...................................................................................................26Tabela 11: Etapas do Projeto VIA DIGITAL..................................................................42Tabela 12: Requisitos não funcionais do SICE...............................................................45Tabela 13: Pesquisas iniciais sobre o SICE.....................................................................47Tabela 14: Papéis no EasyProcess...................................................................................49Tabela 15: Papéis no SICE..............................................................................................50Tabela 16: Canais de informações para o SICE..............................................................53Tabela 17: Contatos para o SICE....................................................................................53Tabela 18: Documentos adicionais do SICE...................................................................54Tabela 19: Plano de Release............................................................................................57Tabela 20: Matriz de Competências/Dedicação..............................................................58Tabela 21: Plano de Iterações..........................................................................................59Tabela 22: Alocação de Tarefas para Iteração 1..............................................................59Tabela 23: Cronograma Iteração 1 SICE.........................................................................59Tabela 24: Plano de Release modificado.........................................................................62Tabela 25: Plano de Iterações modificado.......................................................................62Tabela 26: TAT após término da reunião de acompanhamento......................................65

Introdução

Este documento apresenta as experiências obtidas por uma equipe de alunos docurso de Produção de Software com Ênfase em Software Livre da UFLA, em torno dodesenvolvimento do componente SICE - Sistema de Controle de Estoques do ProjetoVIA DIGITAL – uma proposta inovadora para a criação de um serviço auto-sustentávela integrar uma biblioteca de componentes e de software livres voltados à administraçãopública municipal constituindo elo de ligação entre prefeituras, desenvolvedores,empresas, instituições de apoio e universidades, organizados em torno de modelos denegócio e interação baseados em software livre.

O objetivo geral deste estudo foi o de relatar as experiências resultantes daspráticas gerenciais que executei para sustentar o desenvolvimento do componentealiadas às iniciativas para a implementação de um processo de desenvolvimento quegarantisse maior qualidade à fase de produção e ao software em si e que, ao mesmotempo, validasse a metodologia prevista para o desenvolvimento do SICE. Visandoconstruir um referencial da visão gerencial sobre todo os aspectos do desenvolvimentopara futuros colaboradores, acrescentei de forma geral ao relato, as experiências dosdesenvolvedores de acordo os papéis desempenhados, os sucessos e problemasocorridos, as propostas de melhorias e as aquisições pessoais de cada um após aconclusão do trabalho.

Os objetivos específicos foram:

● integrar de forma ativa o Movimento do SL/CA em nosso País através daparticipação em um projeto de grande relevância como o VIA DIGITALoferecendo contribuição de valor;

● compartilhar conhecimentos através do trabalho em conjunto com comunidadesde desenvolvimento já inseridas neste contexto;

● criar contatos com os demais profissionais da área com interesses e motivaçõessemelhantes construindo assim terreno promissor para a realização de iniciativasfuturas 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árioSantarritense – situada em Santa Rita do Sapucaí (ensino desde o nívelfundamental à Especialização), onde atuo;

● incentivar a elaboração de modelos de negócios em Software Livre para oCentro de Desenvolvimento e Pesquisa da FAI - Faculdade de Administração eInformática, mantida pela Fundação Educandário Santarritense, levando emconsideração a sua capacidade de prestação de serviços e sua localizaçãogeográfica;

● perceber novas áreas de interesses de acordo com as habilidades pessoaisvisando novas especializações.

10

O texto que segue possui a seguinte estrutura:

No Capítulo 1, Gerência de projetos, o objetivo é apresentar as justificativas eobjetivos buscados durante a Gerência de projetos, as principais práticas atualmenteexecutadas dentro das organizações de Desenvolvimento de Software aliadas àsmelhores práticas previstas pelo Project Management Body of Knowledge (PMBOK ).

No Capítulo 2, Processos de Desenvolvimento de Software, o objetivo é apresentar aimportância da qualidade do processo e do produto a partir do estudo de dois processosde desenvolvimento mundialmente reconhecidos e utilizados como base para elaboraçãode diversos outros processos, entre eles o EasyProcess – aplicado no estudo de casodeste 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 adinâ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émdas experiências práticas obtidas no decorrer do desenvolvimento do ComponenteSICE.

Finalmente, as conclusões recuperam as principais questões analisadas ao longo dotrabalho e apresentam os valores acadêmicos, pessoais e profissionais agregados após aexecução do projeto bem como suas perspectivas futuras.

11

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 emeletrodomé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 surgimentode exigências cada vez maiores do mercado.

Para garantir a sobrevivência e a competitividade, as empresas devemdesenvolver softwares dentro de prazo e custos determinados, atendendo a padrões dequalidade aceitáveis neste mercado agressivo. É neste contexto que se compreende anecessidade do planejamento e do gerenciamento dos projetos de software, que visamgarantir a melhor utilização possível de investimentos em recursos humanos, recursosde software e hardware além de recursos materiais diversos para a produção de softwareque atenda a objetivos específicos (requisitos especificados pelas organizações queestã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 problemaspara o desenvolvimento de software de pequeno porte), para a fase atual de enfoquesestruturados e metódicos baseados nos princípios da Engenharia buscando disciplinar odesenvolvimento de software, englobando aspectos técnicos e não técnicos, de modo aproduzir software de qualidade, de forma eficaz e dentro de custos aceitáveis. Surgiuentã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 demandaemergente no desenvolvimento de software, como, por exemplo, Engenharia doConhecimento, Engenharia de Requisitos, Arquitetura de Software e SistemasDistribuídos (VASCONCELOS, 2006).

As Organizações de Desenvolvimento de Software (ODS) com o objetivo deminimizar os problemas do desenvolvimento de software, embora geralmente adotemmetodologias 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 apenasaná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 deprodutos e à obtenção de uma certificação.

Investimentos significativos têm sido aplicados no setor de tecnologia da

12

informação na busca da excelência na produção de soluções a partir da utilização daEngenharia de Processo, da Engenharia de Produto e do Gerenciamento de Projeto nasODS.

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 deprocesso. Segundo o Guide to the Software Engineering Body of Knowledge(SWEBOK) da IEEE (IEEE, 2004), a Engenharia de Processo pode ser dividida emquatro á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 processoe mudança

Infra-estrutura do processo; processo de gerenciamentodo ciclo de vida do software; modelos paraimplementação do processo e mudanças; consideraçõespráticas.

Definição do processo Tópicos de modelos de ciclo de vida de software;processos de ciclo de vida de software; notações paradefinição de processos; adaptação e automação deprocessos.

Avaliação do processo Avaliações dos modelos e métodos dos processos.

Medição do produto e doprocesso

Medição do processo; medição do produto de software;qualidade dos resultados medidos; modelos deinformação de softwares; técnicas de medição deprocessos.

A Engenharia de Produto tem por objetivo a construção do produto desoftware, através da combinação de codificação, verificação, testes unitários, testes deintegração e debugação. Segundo o Guide to the Software Engineering Body ofKnowledge (SWEBOK) da IEEE (IEEE, 2004), a Engenharia de Produto pode serdividida em três sub-áreas conforme mostra a Tabela 2: Sub-áreas da Engenharia deProduto.

Tabela 2: Sub-áreas da Engenharia de Produto


Fundamentos da construçãode 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 daconstrução e integração.

13

O Gerenciamento de Projeto tem por objetivo medir, controlar, modificar egerenciar os projetos de software, ou seja, trata do planejamento das atividades voltadasa assegurar que o software seja entregue dentro do prazo e orçamento previstos e deacordo com os requisitos especificados pelas organizações que estão desenvolvendo eadquirindo o software. Segundo o Guide to the Software Engineering Body ofKnowledge (SWEBOK) da IEEE (IEEE, 2004), o Gerenciamento de projetos pode serdividido em seis sub-áreas conforme mostra a Tabela 3: Sub-áreas da Gerência deProjetos.

Tabela 3: Sub-áreas da Gerência de Projetos


Iniciação e definição doescopo

Determinação e negociação de requisitos, análises viáveis eprocessos para revisão de requisitos.

Planejamento do projeto desoftware

Planejamento do processo, determinação de liberações,esforço, cronograma e estimativa de custo, alocação derecursos, gerenciamento de riscos, gerenciamento da qualidadee planejamento do gerenciamento.

Execução do projeto desoftware.

Planos de implementação, gerenciamento de contratos comfornecedores, 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 erevisão e avaliação de performance.

Finalização Encerramento do projeto e das atividades.

Gerenciamento da Engenhariade Software.

Medição de programas, produtos e processos.

A Figura 1: Relacionamento entre engenharia de processo, gerenciamento deprojeto e engenharia do produto mostra o relacionamento entre estes grupos deatividades.

Figura 1: Relacionamento entre engenharia de processo e de produto e o gerenciamento de projetoFonte: Introdução à Engenharia de Software e à Qualidade de Software

14

1.2 – Práticas da gerência de projetos

As atividades mais comuns da gerência de projetos podem variar em função doporte da ODS, do(s) processo(s) de desenvolvimento adotado(s) por ela e do próprioprojeto. Segundo Vasconcelos (VASCONCELOS, 2006), as atividades mais comuns dagerência são:

● Escrever a proposta do projeto: este documento deve conter uma descriçãodetalhada do que se pretende desenvolver, os objetivos e as restrições, um estudode viabilidade, uma análise clara dos riscos do projeto, os recursos humanos,materiais e financeiros necessários à sua execução, o tempo previsto para suaconclusão organizado de acordo com as tarefas a serem realizadas além dosmecanismos de acompanhamento e informação.

● Fazer estimativas do projeto (custo, tempo etc.): o cronograma divide o projetoem 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 fazero melhor uso do pessoal, além da definição das tarefas independentes, o queevita atrasos. A definição de bons cronogramas depende da intuição e daexperiência dos gerentes de projeto, ou seja, não existe uma ciência exata quedetermine a melhor forma de se construir um cronograma.

● Definir marcos de referência (milestones): um marco de referência é um pontofinal, bem definido, de uma etapa ou atividade. A escolha dos marcos dereferência e das suas freqüências de produção está relacionada ao modelo deciclo de vida utilizado no projeto. Por exemplo, num projeto desenvolvidoutilizando 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 dereferência seria o modelo de análise e projeto, o qual seria produzido ao final daetapa de mesmo nome.

Os marcos de referência podem ser também associados à conclusão de umaatividade. Nesse caso, um marco de referência associado a uma atividade daetapa de análise e projeto poderia ser a produção de um diagrama específico domodelo, como, por exemplo, um diagrama de classes, produzido por umaatividade 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 dereferê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ânciaadversa aconteça. O gerenciamento de riscos trata da identificação dos riscos eda preparação de planos para minimizar os seus efeitos no projeto. Riscospodem ser classificados de acordo com vários critérios. Uma possível

15

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 seguintesatividades:

● Identificação dos riscos: identificar os riscos de projeto, produto enegó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 paragerenciar 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 projetoou no produto será reduzido.

● planos de contingência: se o risco surgir, os planos decontingê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 oumais provável. Também avalia se as conseqüências do risco têm semodificado. Cada risco-chave deve ser discutido nas reuniões deprogresso do gerenciamento.

● Fazer o planejamento e o cronograma do projeto: atividade contínua, desde aconcepção inicial do sistema, até a sua entrega. Os planos devem ser revisadosregularmente, à medida que novas informações se tornam disponíveis. Caso sejanecessário, os planos devem ser atualizados. O plano de projeto é um documentoque descreve as atividades, os recursos e o cronograma usados para odesenvolvimento do sistema. As atividades relacionadas ao cronogramaencontram-se citadas acima.

● Selecionar e avaliar pessoal: nem sempre é possível conseguir as pessoas ideaispara trabalharem num projeto devido a limitações, tais como:

● orçamento de projeto pode não permitir o uso de pessoal altamentequalificado 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 podemser usados como forma de treinar o pessoal.

16

Assim, gerentes têm de alocar o pessoal disponível, dentro das restriçõesimpostas. Muitas vezes, também é papel do gerente participar da seleção para acontratação de pessoal para um projeto.

Além das atividades supracitadas, outras ainda são previstas, tais como: fazeracompanhamentos e revisões constantes para garantir o bom andamento do projeto;escrever os relatórios de acompanhamento (por ex.: Status Report) que relatam aossuperiores e clientes a situação atual do projeto, problemas encontrados e mudançasestratégicas; fazer apresentações sobre o projeto.

Atualmente, de acordo com diversas pesquisas realizadas nesta área a maiorcausa de falhas ocorridas em projetos de software são decorrentes de gerência incorretaou mesmo pobre, realizada informalmente, sem métodos ou técnicas. Dentre as maioresdificuldades encontradas no gerenciamento de projetos pode-se citar:

● a ausência de práticas administrativas no desenvolvimento de softwareresultando em atrasos em cronogramas, custo maior do que o esperado epresença de defeitos, ocasionando uma série de inconveniências para os usuáriose enorme perda de tempo e de recursos;

● planejamento (quando ocorre) é feito de forma superficial sem domínio de comoa idéia modelada, pode ser transformada em produto;

● gerentes de projeto desacostumados a estimar, ou realizando estimativas combase em projetos passados nem sempre bem sucedidos;

● falta de conhecimento e recursos por parte das ODSs para realizar boasestimativas de custo, esforço e prazo de software. Estas estimativas requeremum processo ordenado que defina a utilização de métricas de software, método eferramenta de estimativa;

● estimar, medir e controlar um projeto de software é tarefa difícil, pois odesenvolvimento de software é uma atividade criativa e intelectual, com muitasvariáveis envolvidas (como metodologias, modelos de ciclo de vida, técnicas,ferramentas, tecnologia, recursos e atividades diversas). Gerentes inexperientestentam cumprir prazos dando a máxima velocidade na fase inicial e estãodespreparados para os momentos de impasse, quando os ajustes são inevitáveis.

● a dinamicidade do processo de software dificulta também o gerenciamentoefetivo de projetos de software, devido às alterações constantes nos planos deprojetos, redistribuição de atividades, inclusão/exclusão de atividades, adaptaçãode cronogramas, realocação de recursos, novos acordos com os clientes, entregasintermediárias não previstas etc.;

● um projeto de software também deve adaptar-se ao ambiente, dependendo dadisponibilidade de recursos, ferramentas e habilidades do pessoal ou equipe.

O estudo da Gerência de Projetos nos dias atuais não acontece sem umaabordagem ao PMBOK – Project Management Body of Knowledge, criado pelo PMI –Project Management Institute, uma associação de profissionais de gerenciamento deprojetos existente desde 1969 e que foi responsável por elaborar este guia que descrevea somatória de conhecimentos e as melhores práticas dentro da profissão degerenciamento de projetos conforme nos apresenta a próxima seção.

17

1.3 - As melhores práticas do PMBOK

O PMBOK organiza os processos de gerenciamento de projetos em cincogrupos: 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 doprojeto. Os processos de planejamento definem e refinam os objetivos do projetoselecionando as melhores alternativas para realizá-lo. Os processos de execuçãocoordenam pessoas e outros recursos para a realização do projeto, baseando-se noplanejamento. 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. Osprocessos de finalização formalizam o aceite e a finalização do projeto ou de uma fasedo projeto.

Os processos do PMBOK estão organizados por áreas de conhecimento, que sereferem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentrodessas áreas de conhecimento os cinco grupos de processos acima descritos podemocorrer.

Todos os processos descritos a seguir interagem uns com os outros e tambémcom os processos das demais áreas de conhecimento. Cada processo pode: envolveresforço de um ou mais indivíduos ou grupos de indivíduos dependendo dasnecessidades do projeto e geralmente, ocorrer pelo menos uma vez em cada fase doprojeto.

Gerência de integração: A gerência de integração engloba os processos necessáriospara 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 partesinteressadas. Envolve o desenvolvimento e a execução do plano de projeto e o controlegeral das mudanças.

Gerência de escopo de projetos: A gerência do escopo do projeto inclui os processosrequeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somenteo trabalho necessário, para complementar de forma bem sucedida o projeto. Apreocupação fundamental compreende definir e controlar o que está ou não incluído noprojeto.

Gerência de tempo de projetos: A gerência de tempo do projeto objetiva garantir otérmino do projeto no tempo certo. Consiste da definição, ordenação e estimativa deduraçã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 oprojeto seja executado dentro do orçamento aprovado. Consiste no planejamento dosrecursos, estimativa, orçamento e controle de custos.

Gerência de qualidade de projetos: A gerência da qualidade objetiva garantir que oprojeto satisfará as exigências para as quais foi contratado. Consiste de planejamento,

18

garantia e controle de qualidade.

Gerência de recursos humanos de projetos: A gerência de recursos humanos objetivagarantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste deplanejamento 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 objetivoprincipal 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 resultadosde 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 principalobter bens e serviços externos à organização executora. Consiste na seleção defornecedores, planejamento de aquisição, planejamento de solicitação, solicitação depropostas, 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 praticadonas Organizações de Desenvolvimento de Softwares (ODS). A introdução de padrões enormas tem se mostrado complexa demais, além de causar uma sobrecarga de trabalhosignificativa. 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 estabelecernormas e padrões, amadurecer as ODSs e fortalecê-las tornando-as capazes de competirno mercado internacional.

19

Capítulo 2 - Processos de Desenvolvimento de Software

2.1 - Objetivos

Garantir a excelência nos softwares produzidos dentro de prazos e custosmínimos de forma a promover alta competitividade às organizações é o grande desafioatual da indústria nacional de software. Em outras palavras, é preciso promover aqualidade e perseguí-la durante todo o processo de desenvolvimento dos sistemas desoftware, de forma a atender um mercado cada vez mais exigente e complexo.

Neste contexto, torna-se imprescindível o conhecimento e aplicação daEngenharia de Software, cujos fundamentos científicos envolvem o uso de modelosabstratos e precisos que permitem ao engenheiro especificar, projetar, implementar emanter sistemas de software, avaliando e garantido suas qualidades (Leite,2007).

Segundo (Abib,1999) uma das evoluções mais importantes no estudo daQualidade está em notar que a Qualidade do produto é algo bom, mas que a Qualidadedo processo de produção é ainda mais importante. Voltando nossos olhos para odesenvolvimento de software, constatamos então que a avaliação da qualidade de umsoftware está diretamente relacionada com a qualidade dos processos e metodologiasutilizadas para o seu desenvolvimento, o que torna imprescindível a cada organizaçãopreocupada em manter a competitividade, a escolha sensata e adequada do melhorprocesso de desenvolvimento que atenda aos seus objetivos, cultura e projetos.

As próximas seções, baseadas no trabalho do Professor Alexandre Marcos Linsde Vasconcelos (VASCONCELOS,2005), apresentam dois processos dedesenvolvimento de software mundialmente reconhecidos e utilizados na elaboração dediversos outros processos de desenvolvimento de software, entre eles o EasyProcess – oprocesso aplicado no estudo de caso abordado neste trabalho. São eles: Rational UnifiedProcess (RUP) e o Extreme Programming (XP).

2.2 - Rational Unified Process (RUP)

O RUP – Rational Unified Process é um processo de software genérico quefornece uma abordagem disciplinada para assinalar tarefas e responsabilidades dentrodo contexto do projeto, de modo a atender todo o ciclo de desenvolvimento de softwarede alta qualidade. Este processo foi desenvolvido com o propósito de padronizar oprocesso de desenvolvimento de software, e para tanto, utiliza o melhor de váriasté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: ocomportamento/responsabilidades/papel desempenhado por um indivíduo/equipe; a

20

unidade de trabalho desempenhada por um responsável e que produz um resultadosignificante; a peça de informação que é produzida/modifica/usada pelo processo dedesenvolvimento de software; a sequência de atividades que produz um resultado devalor 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 deabstraçã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 Casosde Uso

(funções)

Identificação dos atores, das funcionalidades do sistema e a interação entreos dois, a reunião de todos os casos de usos necessários para a construçãodo sistema denomina-se Modelo de Casos de Uso e orienta todas asatividades do processo de desenvolvimento.

Centrado naArquitetura

(forma)

Visão do projeto como um todo, tornando visível as características maisimportantes. Todo produto tem funções e forma, que devem serbalanceadas para o seu sucesso. No caso de software, funçõescorrespondem a Casos de Uso e a forma à Arquitetura.

Iterativo eIncremental

Organização em ciclos ou mini-projetos que se constituem em iterações(passos no fluxo do desenvolvimento – etapas) que por sua vez, resultamem incrementos (evolução do produto – versões). A cada iteração concluídao desenvolvimento procede para a próxima iteração.

O RUP repete uma série de ciclos de evolução durante o processo dedesenvolvimento de um sistema. Cada ciclo termina com uma versão do produto econsiste 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çãoFase de formulação do planejamento do projeto e do escopo; definição de umaarquitetura candidata e seleção das ferramentas para desenvolvimento.

Elaboração

Fase de definição e validação da arquitetura; refinamento da visão docliente/usuário sobre o produto a ser desenvolvido; criação de planos deiteração detalhados para a fase de Construção; refinamento da arquitetura eseleção de componentes.

ConstruçãoFase de implementação propriamente dita abrangendo as atividades essenciaisde gerenciamento de recursos; complemento do desenvolvimento decomponentes e testes; avaliação das versões do produto.

Transição

Fase cujas atividades essenciais envolvem a execução dos planos deimplantação; finalização do material de suporte ao usuário final; criação deversões do produto; obtenção de feedback do usuário; melhoramento doproduto baseado no feedback; disponibilização dos produtos para os usuáriosfinais.

21

Cada fase é dividida em iterações, conforme mostra a Figura 2 - Ciclo e Fases doRUP:

Figura 2. Ciclos e Fases do RUPFonte: Processos de Desenvolvimento de Software 1

Os fluxos do RUP apresentam-se basicamente organizados em dois tipos: Fluxosde Processo e Fluxos de Suporte, conforme mostra a Figura 3. Fluxos do RUP:

Figura 3. Fluxos do RUPFonte: Processos de Desenvolvimento de Software 1

A Tabela 6: Atividades por Fluxos do RUP mostra as atividades previstas paracada fluxo.

Tabela 6. Atividades por Fluxos do RUP

Fluxo Atividade Propósito

De Processo Modelagem denegócios

Diagnóstico da organização (conhecimento dos processos,dinâmica e problemas); identificação de melhorias;proporcionar aos stakeholders uma visão comum daorganização.

Requisitos Especificação clara dos requisitos do sistema; identificação

22

Fluxo Atividade Propósito

de seus limites (restrições); informações para estimação decustos e tempo; criação de protótipos.

Análise e ProjetoTransformar os requisitos em um projeto de sistema; definiruma arquitetura robusta para o sistema; adaptar o projeto parao ambiente de implementação.

ImplementaçãoDefinir a organização do código; implementar classes eobjetos; testar os componentes desenvolvidos; integrar osresultados produzidos em um sistema executável.

Testes

Verificar a integração entre objetos; verificar a integraçãoformal de todos os componentes do software; verificar setodos os requisitos foram corretamente implementados;identificar e garantir que defeitos sejam resolvidos antes daimplantação.

ImplantaçãoProdução de versões do sistema e a entrega do software paraos usuários finais.

De Suporte

Gerenciamentode Configuração e

Mudanças

Controlar as mudanças e manter a integridade dos artefatosdo projeto.

Gerenciamento deProjeto

Fornecer um framework para gerenciamento de projetos desoftware; fornecer guias práticos para planejamento,recrutamento de pessoal, execução e monitoração de projetos;fornecer um framework para o gerenciamento de riscos.

AmbienteFornecer a organização e um ambiente (processos eferramentas) de desenvolvimento do software, que darãosuporte à equipe de desenvolvimento.

2.3 - Extreme Programming (XP)

O Extreme Programming (XP) é um processo ágil de desenvolvimento desoftware que vem se mostrando eficiente em projetos onde os requisitos sãoconstantemente modificados, os ciclos de desenvolvimento são curtos e as equipes queimplementam o projeto são pequenas. Resultou da experiência em um projetodenominado C3 Payroll da empresa Chrysler, cujo sucesso despontou no meioacadê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 eeficiente ao cliente, o XP foi criado considerando que mudanças são inevitáveis edevem 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 doprojeto) cujas características principais foram sintetizadas nas Tabelas 7: Valores de XPe 8: Princípios de XP.

23

Tabela 7: Valores de XP

Valores Descrição

Comunicação Construir entendimento do problema pessoa-a-pessoa com uso mínimode documentação formal e uso máximo de interação “cara-a-cara” entreas pessoas envolvidas no projeto.

Simplicidade Sugerir que cada membro da equipe adote a solução mais fácil quepossa funcionar, criando ambiente cujo custo de mudanças seja baixono futuro.

Feedback Fornecer feedback para programadores através dos casos de testes epara os clientes através dos testes funcionais.

Coragem Ter coragem necessária para que se aplique XP como deve ser aplicadoem atitudes que podem trazer melhorias ao projeto.

Tabela 8: Princípios de XP

Princípios Descrição

Feedbackrápido

Os participantes de um projeto como clientes, programadores egerentes devem estar sempre se comunicando para facilitar oaprendizado coletivo sobre o projeto que está sendo desenvolvido,sanar dúvidas, riscos e problemas de modo a facilitar ações decontingência.

Assumirsimplicidade

Todo problema deve ser tratado para ser resolvido da forma maissimples possível.

Mudançaincremental

As mudanças devem ser incrementais e feitas aos poucos.

Abraçandomudanças

As mudanças devem ser sempre bem-vindas independente do estágiode evolução do projeto.

Trabalho dequalidade

O sistema deve atender aos requisitos do cliente, rodar 100% doscasos de teste e agregar o maior valor possível para o negócio docliente.

O XP possui uma estrutura principal cujo funcionamento pode ser compreendidoatravés do conhecimento de doze práticas que consistem no núcleo principal doprocesso e que foram criadas com base nos ideais pregados pelos valores e princípiosapresentados. 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 doplanejamento

Esta técnica estabelece que os planejamentos de um release e dasiterações devem ser feitos com base nas estórias (casos de usosimplificados) e contar com a colaboração de toda a equipe dedesenvolvimento, inclusive o cliente. Observam-se 2 papéis:• Negócio: pessoas que entendem do negócio e tem capacidade de

24

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áriasiteraçõ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 cujotrabalho está sendo medido e intervém em situações peculiares.

Releasespequenos

Esta técnica estabelece que cada release deve ser tão pequeno quantopossível, contendo os requisitos mais importantes para o negócio.Sugere-se que os releases sejam de curta duração, normalmente de 2 a3 meses.

Metáfora Esta técnica estabelece que deve-se utilizar as metáforas com oobjetivo de oferecer uma visão geral do sistema, em um formatosimples, que possa ser compartilhado por clientes e programadores.

ProjetoSimples

Esta técnica estabelece que devem ser projetadas as funcionalidadesque já foram definidas e não as que poderão ser definidas futuramentee deve ser feito o melhor projeto que possa entregar taisfuncionalidades.

Testesconstantes

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 oque 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 passospara melhorar o projeto do código existente, tornando-o mais simplese melhor estruturado, sem alterar sua funcionalidade.

Programaçãoem pares

Esta técnica estabelece que todo código produzido em XP deve serescrito por um par de programadores com os papéis respectivos decodificaçã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 daequipe tenham conhecimento sobre todas as partes do sistema.

Propriedadecoletiva docódigo

Esta técnica encoraja a equipe inteira a trabalhar mais unida em buscade qualidade no código, fazendo melhorias e refatoramentos emqualquer parte do código a qualquer tempo. É necessário manter opadrão de codificação e realizar todos os testes para que se garanta aqualidade do software em desenvolvimento.

Integraçãocontínua

Esta técnica estabelece que o código das funcionalidadesimplementadas pode ser integrado várias vezes ao dia, desde que nãoexistam erros, quando então deverão ser corrigidos.

Semanaquarenta horas

Esta regra sinaliza a preocupação com desgastes da equipe emperíodos excessivos de trabalho que podem gerar queda da qualidadedo código em virtude do cansaço e insatisfação pelas horas extras.

25

Valores Descrição

Cliente nolocal

Esta técnica estabelece que deve ser incluída na equipe uma pessoa daparte do cliente, que irá usar o sistema, para trabalhar junto com osoutros e responder as perguntas e dúvidas.

Padrões decodificação

Esta regra estabelece a necessidade de se ter padrões de codificaçãopara que as regras de refatoramento e propriedade coletiva do códigosejam aplicadas satisfatoriamente.

O XP atravessa algumas fases durante o seu ciclo de vida que por sua vez sãocompostas de diversas tarefas. A Tabela 10: Fases do XP mostra as principais fases deum projeto utilizando XP de modo a se ter uma idéia de como ele flui ao longo dotempo.

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 osistema irá rodar. Ao se obter um número de estórias suficientes inicia-se aconstrução do primeiro release.

Planejamentoinicial

Esta fase é utilizada para que os clientes concordem em uma data paralançamento do primeiro release. Os programadores juntamente com os clientesescolhem as estórias, identificam quantas podem implementar em umaiteração. Os clientes priorizam as mais importantes e o processo então se repeteaté terminar as iterações do release.

Iterações dorelease

Esta fase compreende o momento de escrita dos casos de teste funcionais e deunidade. Os programadores seguem mais ou menos o seguinte fluxo deatividades na seguinte ordem: escrita dos casos de teste; projeto erefatoramento; codificação; realização de testes e integração.

Manutenção

Esta fase pode ser considerada como uma característica inerente a um projetoXP. Em XP faz-se simultaneamente a produção de novas funcionalidades e amanutenção do sistema em funcionamento através da incorporação de novaspessoas na equipe e do melhoramento do código.

Morte

Esta fase compreende o término de um projeto XP, podendo se dar por duasrazões: cliente satisfeito com o sistema e não enxerga novas funcionalidades ouo projeto tornou-se economicamente inviável devido a dificuldades de seadicionar funcionalidades a baixo custo e alta taxa de erros.

Os papéis envolvidos em XP incluem o gerente, o programador, o cliente, otestador 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 eevolução do processo. O rastreador coleta métricas sobre o que está sendodesenvolvido e confronta com as métricas estimadas verificando possíveisdivergê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

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á sendocompreendido pelas pessoas do projeto.

Alguns fatores, embora constituam fortes indicadores para a não utilização deXP, não constituem seus limites exatos, mas devem ser seriamente considerados duranteuma análise para sua adoção. São eles: a cultura de desenvolvimento de software deuma organização, o tamanho da equipe de desenvolvimento, a tecnologia, a organizaçãodo espaço físico e a disponibilidade do cliente para participação ativa no projeto.

Outro problema encontrado nos ambientes de desenvolvimento de software esinalizados por Gruhn (GRUHN, 2002) reside no fato de que, quando uma ODS optapor utilizar processos de desenvolvimento de software, geralmente trabalha com focoem apenas um processo, o que inviabiliza, por exemplo a execução de projetos cujascaracterí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 desoftware mais flexíveis, que suportem a aplicação de uma grande variedade deprocessos, aumentando assim a produtividade da ODS e a qualidade no processo dedesenvolvimento e do produto gerado. Os Ambientes de Desenvolvimento de Softwarecentrados em Processos, atuam de duas formas: ora parametrizando os principaisprocessos de desenvolvimento de software através da definição de ferramentasadequadas à sua aplicação; ora, partindo de modelos de processos, definindo quaisatividades do desenvolvimento devem ser realizadas, quando e por quem, além de quaisferramentas utilizar e o formato dos documentos a serem criados e/ou manipulados pelaequipe.

A necessidade de investimentos em ferramentas, infra-estrutura e capacitaçãoaumenta a preocupação em relação às formas de obtenção dos recursos financeiros e aoretorno deste investimento. O Software Livre, por suas características, modelos dedesenvolvimentos e pelos impactos econômicos, sociais e tecnológicos que promoverepresenta uma expectativa extremamente positiva sobre este retorno conforme nosapresenta o próximo capítulo.

27

Capítulo 3 - O fenômeno do Software Livre (SL/CA)

Hoje, com o considerável movimento financeiro gerado pela comercialização delicenças e a grande preocupação da comunidade científica em garantir a qualidade dosprodutos de softwares criados, o que capacita as indústrias nacionais a concorrerem nomercado internacional, a filosofia de desenvolvimento de Software Livre, baseada naformação de comunidades informais de desenvolvimento, na distribuição livre deexecutáveis e códigos fonte apoiada por uma licença de distribuição própria que garanteliberdades completamente contraditórias ao que conhecemos até então, tomou aproporção de um fenômeno que desperta o interesse, a polêmica e o debate acirradoentre a área científica, o setor privado, os órgãos governamentais e os profissionaisliberais da área de computação, que buscam compreender os impactos causados por estafilosofia 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 osconceitos e a filosofia que sustentam essa nova realidade, descritos a seguir, tendo comobase o trabalho da Profª Ângela Maria Alves (Alves,2005). Os próximos tópicos irãotratar da História do Software Livre, dos Modelos de Desenvolvimento em fase deelaboração, das Licenças utilizadas, além dos impactos econômicos e sociaisprovenientes de sua adoção.

3.1 - Histórico

Os anos 60 marcaram o início histórico do desenvolvimento de Software Livre apartir da criação do sistema Operacional UNIX. Nesta época não havia a preocupaçãocom direitos autorais e de propriedade por não haver um mercado estruturado para acomercialização de licenças de software. O foco dos fornecedores de tecnologia era ohardware, o que permitia um trabalho colaborativo entre as comunidades dedesenvolvimento, as universidades, instituições de pesquisa e empresas. Os sistemaseram muitas vezes fornecidos como uma parte integrante do hardware.

A interação entre os diversos atores envolvidos na criação do Unix caracterizouhistoricamente a primeira comunidade colaborativa de desenvolvimento. A distribuiçãogratuita do código fonte deste projeto pela AT&T às universidades, fez com que o Unixfosse considerado o primeiro Software Livre no contexto histórico da informática.

Os conceitos sobre os quais o Unix foi desenvolvido: portabilidade, simplicidadee eficiência, são características que justificaram o fato de ter se tornado a base dossistemas operacionais livres mais populares hoje, como o GNU/Linux e os sistemas dalinha Berkley Software Distribution – BSD.

A partir da segunda metade da década de 70, em virtude da evolução daindústria de informática e a dissociação entre o software e o hardware, houve ummovimento 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 primeirasmotivações para um movimento organizado pelo Software Livre.

28

Uma grande e histórica iniciativa ocorreu em 1983, quando Richard Stallman(atual presidente) criou a Free Software Foundation (FSF) que é hoje a principalorganização dedicada à produção e à divulgação do Software Livre, tendo comoobjetivo promover na comunidade de informática o espírito colaborativo que prevaleciaem seus primórdios, onde as informações códigos e métodos de trabalhos eramlivremente compartilhados.

Grandes opiniões aqueciam o discurso de Stallman e pouco a pouco faziamcrescer o Movimento de Software Livre:

“Software proprietário implica numa organização social onde não é permitido às pessoascompartilharem conhecimento, não é permitido ajudar o próximo e incita à competição aoinvés da colaboração.”

“O custo marginal de distribuição e reprodução de software é próximo do zero. Uma vez pagosos custos de desenvolvimento, restringir o acesso ao software traz muito mais malefícios doque benefícios.”

“Como os programas proprietários são fechados é negado às pessoas melhorar suasfuncionalidades de forma a atender a necessidades específicas.”

“É prejudicado o desenvolvimento de software de maneira geral, uma vez que a cada novoprojeto proprietário é necessário redesenvolver várias tecnologias que eventualmente já tenhamsido 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 aintenção de ser um clone do UNIX, mas dessa vez totalmente livre de códigoproprietário (todo o código seria reescrito). De forma visionária, Stallman buscoucolaboradores entre os profissionais da área e divulgou entre os usuários as vantagensprovenientes da utilização de sistemas livres tal como podemos observar em nossarealidade atual.

Em 1991, o Sistema Operacional GNU estava praticamente pronto, no entanto,faltava um componente de suma importância: o núcleo. Paralelamente a estedesenvolvimento, um jovem finlandês de 21 anos de idade, chamado Linus Torvaldsdesenvolveu uma versão inicial de um núcleo de sistema operacional compatível com oUnix. Lançou-o publicamente e com a ajuda da comunidade foram adicionadasfuncionalidades necessárias a um núcleo de uso real.

Com a divulgação dos projetos GNU e Linux em desenvolvimentos paralelos esendo projetos complementares, promoveu-se rapidamente a sua integração, dandoorigem ao primeiro Sistema Operacional totalmente livre para a arquitetura Intel x86: oGNU/Linux. Por sua característica livre, em poucos anos atingiu funcionalidades eestabilidades comparáveis a sistemas operacionais proprietários já consolidados.

Em 1989 a FSF criou a Licença GPL – General Public License que constituiu-seem uma das grandes contribuições do Projeto GNU. Hoje é a licença mais utilizada emprojetos de Software Livre, dando amparo legal e formalizando a ideologia que permeia

29

o movimento.

Novas comunidades de desenvolvimento surgiram durante a criação do SistemaOperacional GNU da FSF e durante o desenvolvimento do Núcleo do Linux. SegundoSilveira, o GNU/Linux baseia-se nos esforços de mais de 400 mil desenvolvedoresespalhados pelos cinco continentes e por mais de 90 países.

“Dificilmente uma empresa privada terá condições de acompanhar o ritmo de inovaçõesincrementais de uma rede tão variada e tão inteligente.” (Silveira, 2005).

Dentro do Movimento de Software Livre é possível encontrar duasdenominaçõ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 esignificam mudanças substantivas na indústria de software, seja do ponto de vista dousuário final, do desenvolvedor de software ou de outros agentes relacionados. Emlinhas gerais Código aberto enfatiza os aspectos do processo e da organização, enquantoSoftware 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 estandoainda em fase de modelagem, nos dá uma idéia do trabalho dos colaboradores e daorganização em si.

3.2 - Modelos de desenvolvimento

Para atribuir credibilidade a um sistema de software leva-se em conta aengenharia utilizada em seu desenvolvimento, o perfil profissional dos líderes edesenvolvedores 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 qualidadedo produto final. Apesar desta descrição nos remeter a idéia do processo de produção desoftware proprietário a realidade atual do processo de desenvolvimento de SoftwareLivre já apresenta grandes características similares que aumentam a credibilidade nestassoluções.

Segundo Alves, Eric Raymon, autor da publicação mais popular sobre SoftwareLivre - o livro The Cathedral and the Bazaar, compara dois estilos opostos dedesenvolvimento de Software Livre, a Catedral, que descreve projetos de SoftwareLivre desenvolvidos por grupos fechados, com pequena abertura para participaçãoexterna; 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 etradicionalista de desenvolvimento. Característico deste tipo de projeto são os longosciclos de desenvolvimento e o grande intervalo de tempo entre lançamentos de versõespúblicas. O GNU Emacs pode ser citado como projetos desenvolvidos neste modelo.

O Bazar por sua vez é descrito como sendo um projeto colaborativo, aberto aponto da promiscuidade – usuários estão livres e são bem-vindos a participar e opinarsobre o desenvolvimento em qualquer fase. Lançamentos ocorrem frequentemente e umgrande número de olhos tem acesso ao código fonte, permitindo que erros e regressões

30

sejam rapidamente avaliados e informados. O Linux e o Fetchmail são exemplos deprojetos desenvolvidos neste modelo.

Raymond cita ainda alguns pontos fundamentais a respeito do desenvolvimentode Software Livre, tais como: a importância de ter muitos usuários com acesso aocódigo fonte do ponto de vista da qualidade; e a prática de oferecer aos usuários aoportunidade de testar freqüentemente os códigos mais recentes. No entanto muitascríticas colocam restrições com relação ao cisma radical do modelo, já que as diferençasentre o Bazar e a Catedral não são tão evidentes; além disso questiona-se o que significafazer disponibilizações freqüentes tendo em visto que o contexto atual do SoftwareLivre é de acesso quase instantâneo do código.

Apesar das críticas, o trabalho de Raymond é importante por ser pioneiro nadescrição da ontologia de projetos de Software Livre, e por incluir conhecimentosoriundos da experiência de Raymond durante o desenvolvimento do Fetchmail.

Diversos questionamentos e análises tem sido feitas ao modelo dedesenvolvimento de Software Livre, dentre as mais relevantes descritas em artigostécnicos citam-se:

● Como Software Livre obtém êxito tendo como base a dificuldade decomunicação existente no desenvolvimento distribuído (tão similar ao SoftwareLivre), 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 trabalhosimultâneo de pessoas sobre o mesmo código?

● Como é possível que desenvolvedores gostem de dar manutenção, ler e estudarcódigo alheio, e trabalhar sem remuneração, já que historicamente têm se aocontrário?

● O que dizer da despreocupação da comunidade Software Livre com relação aoprocesso de software e em particular a inexistência ou desatualização dasferramentas de desenvolvimento?

Algumas conclusões foram obtidas através de estudos de grandes projetos emSoftware 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émde 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 contrariaestudos anteriores, que diz que o ritmo de desenvolvimento diminui a medidaque se tornam mais complexo;

● O núcleo tem alto acoplamento e este cresce exponencialmente à medida que onúcleo cresce, mas o seu desenvolvimento continua normalmente até hoje.

Sobre o Projeto Mozilla:

31

● 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çãodos requisitos de interface e usabilidade;

● O projeto Mozilla usa e oferece uma série de ferramentas para apoiar o processode 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 pessoasque podem integrar o código fonte no repositório central e com isso sugerecomplexidade de gerenciamento muito alta;

● Boa parte dos problemas de gerenciamento é resolvida pelo fato do nome doautor e da alteração estar publicamente vinculados ao código.

Apesar de uma idéia inicialmente caótica no modelo de desenvolvimento deSoftware Livre, um Projeto de Software Livre é uma organização composta por umconjunto de pessoas que usa e desenvolve um único software, contribuindo para umabase comum de código fonte e conhecimento. Este grupo terá à sua disposiçãoferramentas de comunicação e trabalho colaborativo, e um conjunto de experiências eopiniões técnicas que usam para discutir o andamento do projeto.

Esta tríade: software, comunidade e ferramentas são muito bem organizadasconforme as descrições a seguir:

Software: Por definição, o código fonte que o projeto produz é distribuídoatravés de uma licença de Software Livre. Esta base de código é freqüentementemantida em um repositório público de onde qualquer pessoa pode copiá-la. Alteraçõesnesta base são normalmente feitas por um grupo pequeno de pessoas, em muitos casospor uma pessoa só, que é chamada de maintainer ou mantenedor.

A base de código inicial é normalmente escrita por uma pessoa isoladamente, elançada através de uma mensagem enviada para uma lista de discussão ou em umarquivo on-line de projetos, como os sites freshmeat.net ou sourceforge.net. O códigofonte, possivelmente acompanhado de versão pré-compiladas para arquiteturas edistribuições específicas, é normalmente oferecido a um repositório Internet através deWeb ou FTP.

Normalmente o desenvolvimento é feito de forma isolada; cada desenvolvedorcria alterações ao código fonte localmente. Uma vez decidido que a alteração é correta edesejável o processo de integração é iniciado. Se o desenvolvedor tem permissão paraescrever código diretamente no repositório, faz a integração pessoalmente; casocontrá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 elaseja revisada e mesmo reescrita caso necessário; isto ocorre tanto na fase pré-integraçãocomo pós-integração. Este ciclo se repete para cada alteração a ser introduzida na basede código fonte.

Comunidade: As pessoas envolvidas em um projeto podem ter sua participação

32

classificada pelo tipo de papel que exercem:

● Usuários não-participantes: sem interesse em discutir ou ajudar nodesenvolvimento do software; fazem teste funcional do software, mas emgeral não informam erros quando os encontram.

● Usuários participantes: ativamente contribuem para o projeto informandoproblemas e discutindo a funcionalidade desejada. São responsáveis porboa parte do teste funcional, provendo feedback para os autores em relaçãoa regressões e inconsistências.

● Desenvolvedores esporádicos: usuários com conhecimento deprogramação e disposição para alterar código fonte e produzir alterações.Normalmente suas alterações terão caráter localizado, reparando umpequeno defeito ou implementando uma pequena extensão defuncionalidade.

● Desenvolvedores ativos: aqueles que têm responsabilidade por módulos docódigo fonte ou por implementar funcionalidade mais extensa ou maiscomplexa. Entre estes, normalmente figura o autor original comomantenedor central.

É importante observar que esta divisão não e rígida; pessoas podem migrar deum papel para outro conforme escolha e oportunidade pessoal.

Para coordenar o trabalho que realizam, os membros da comunidade de umprojeto utilizam a Internet através de ferramentas simples amplamente disponíveis comoo correio eletrônico, páginas Web, listas de discussão, em conjunto com ferramentas dedesenvolvimento de software, controle de versão e acompanhamento de defeitos.

Comunicação escrita: Os membros da comunidade se comunicamnormalmente através de listas de correio eletrônico, podendo alguns projetos utilizaradicionalmente repositórios públicos de defeitos e formas de comunicação em temporeal. 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 outrosusuá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 daferramenta CVS apesar de suas limitações reconhecidas, a ferramenta aparentementetem uso maciço por ser bastante simples e ter ampla disponibilidade.

Repositório: Um repositório CVS consiste de um conjunto de arquivosmantido em um local central; normalmente é armazenado em um servidorconectado à Internet, que permite acesso anônimo, evitando que usuáriosque queiram acessar o código fonte tenham que se registrar. O repositóriopermite cópia local, integração, geração de versões e geração debranches instáveis e estáveis.

Apoio ao processo de desenvolvimento: podem ser classificadas emFerramentas de Desenvolvimento, Ferramentas de Configuração e compilação(autoheader, autoconf, automake e make), Visualização de código fonte (ViewCVS e

33

CVSWeb), Acompanhamento de defeitos (ou alterações) (Bugzilla e Gnats).

Serviços de hospedagem de projetos: após advento do pioneiro site WebSourceforge.net, conta-se com algumas opções gratuitas para hospedar um projeto deSoftware Livre. Os serviços de hospedagem públicos oferecem interface via Web paramanipulação dos serviços individuais dos projetos.

Outro aspecto importante em relação ao Software Livre reside nas característicasespecíficas que ora aproximam e ora distanciam cada licença de uso existente noMovimento.

3.3 - Licenças

As leis de direitos autorais foram criadas para permitir aos autores explorarcomercialmente suas criações, recompensando-os por seu esforço e estimulando outrasinovações.

Existem basicamente dois tipos de propriedade intelectual: o direito autoral e odireito de patentes.

Os direitos autorais podem ser patrimoniais (copyright), que tratam denegociação da obra, e morais que tratam do direito do autor de ter seu nome ligado aobra. 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 detempo. 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ãopodendo 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 oobjetivo de evitar que desenvolvedores de software proprietário se apropriassem dossoftwares livres (o que protegeu a comunidade), tendo em vista que nos Estados Unidosé legalmente permitido patentear os softwares desenvolvidos. A esse tipo delicenciamento deu-se o nome de copyleft, que obriga os trabalhos derivados de SoftwareLivre a serem Software Livre também.

A GPL foi a primeira licença de Software Livre criada e possui comocaracterísticas básicas a garantia da liberdade de uso, alteração e distribuição desoftwares e a de que qualquer trabalho derivado também seja licenciado sobre asmesmas condições. É um instrumento legal para proteger os direitos e fazer com queoutros não tenham a opção de removê-los. Possui exigências, restrições fundamentais eadicionais.

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 deterceiros;

34

● de distribuir livremente cópias do programa original;

● de distribuir cópias de versões modificadas de forma que toda a comunidadepossa 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 essasliberdades. Essa seria a essência do Software Livre. Sua origem tem motivaçõesideológicas e sua proposta altera substantivamente as condições nas quais um programade 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 chamadosbibliotecas. Não é copyleft. É recomendada para casos específicos em que nãohaja outra alternativa;

● FDL (Free Documentation License): refere-se a liberdade de documentação. Écopyleft. Tem uma estrutura enxuta e simples oposta a GPL, permitindo aredistribuição e uso do programa na forma binária e código fonte com ou semmodificações. Suas únicas restrições são:

● no código fonte deve ser mantido o aviso de copyright originalidentificando o autor;

● na distribuição binária deve se manter o copyright na documentação e onome do autor não pode se utilizado em versões modificadas doprograma.

Por não ter componente filosófico ou social, enquadra-se no movimento docódigo aberto contrariando a FSF que a considera prejudicial por não incentivara 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çãodo código Mozilla (Navegador de Internet).É bem similar à GPL, porém, bemmais orientada a empresas.

● a SCSL (Sun Community Source License) não pode ser considerada como umalicença livre porque não atende diversos pontos fundamentais para o códigoaberto. Dentre os quais a SUN tem controle sobre modificações. Emcontrapartida a comunidade de Software Livre está lançando projetos similaresao da SUN, porém o usuário tem controle completo do desenvolvimento e dapolítica de distribuição.

Licenças como a GNU GPL e BSD podem ser utilizadas, conforme tratadointernacional. Para adequar à legislação brasileira estão sendo utilizadas duas iniciativas

35

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 aslicenças Creative Commons GPL e LGPL como oficiais para todo Software Livredesenvolvido pelo governo.

O próximo tópico apresenta a situação do Software Livre perante a comunidadeempresarial, incluindo os principais motivos que hoje poderiam interferir na escolha dasempresas pelo processo livre de desenvolvimento, tais como: a diferenciaçãocompetitiva, a necessidade de manutenção do segredo do negócio e a questão dasegurança. Problemas solucionáveis através da análise da empresa dos reais valoresinternos que ela possui e que lhe conferem competitividade, independente do softwareou serviços utilizados/comercializados ou prestados; otimizações na metodologia dedesenvolvimento e a necessidade de previsão de erros nos software produzidos. Grandesgigantes do mercado de TI têm adotado o Software Livre garantindo a segurança em seuuso, 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 etécnica do Software Livre. Sobre a sustentabilidade econômica, questiona-se se asliberdades de acesso ao código e de não comercialização de licenças podem viabilizarmodelos de negócios sustentáveis para as empresas fornecedoras. Sobre asustentabilidade do modelo de desenvolvimento, questiona-se se as empresas poderiambasear 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 vezque não há rendas através da comercialização de licenças. A vantagem na opção peloSoftware Livre, neste caso, reside em três importantes fatores:

1. os custos de sua produção (amortizadores) tendem a ser mais baratos devido aogrande reaproveitamento do conhecimento pré-existente e da facilidade deintegração com outros módulos produtos prontos.

2. os custos de distribuição e reprodução (marginais) passaram a ser próximos dozero em função do advento da internet que permite facilidade e rapidez nesteprocesso.

3. uma parte dos financiamentos para produção do Software Livre são assumidospor 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 deinformação, que ao invés de ter um valor comercial em si, tem valor nos benefíciostrazidos 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 funcionalidadese resolver problemas, além de prestar inúmeros serviços relacionados aos softwares quemantém.

Raymond sustenta que na maioria dos casos, não há motivos para manter

36

programas fechados mas descreve três razões pelas quais as empresas poderiam preferirmanter 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 subestimaseus benefícios, ou seja, a maior parte dos resultados supera muitas expectativasiniciais.

2. necessidade de manutenção de segredos de negócio. Esse problema pode serresolvido separando-se o software básico do módulo que contém as regras denegócios.

3. segurança. Essa segurança chamada de obscurantismo é fortemente criticada porespecialistas, porque muitas falhas podem ser descobertas somente no uso eimpede a prevenção de códigos maliciosos ou estruturas camufladas.

Algumas empresas têm contribuindo para aumentar a credibilidade no uso doSoftware Livre, através da criação e participação em diversos projetos relevantes, taiscomo: o sistema Compiere da Compiere Inec, os sistema de arquivos XFS da SGI, StarOffice da Sun e a participação da IBM e Oracle no desenvolvimento do núcleo doLinux. No portal Código Livre há diversos projetos tornados livres, executados porbrasileiros.

Para sustentar o uso empresarial do Software Livre são necessários modelos denegócios viáveis e principalmente rentáveis, já que a venda em si não faz sentido. Asempresas interessadas em atuar neste mercado deverão se reestruturar estrategicamentee encontrar formas criativas e inovadoras que garantam sua sobrevivência, tendo comobase sua experiência de mercado e a inteligência reunida em sua equipe empresarial etecnológica.

Raymond sugere os seguintes modelos para sustentar negócios baseados emSoftware Livre:

● Base para produto proprietário: um Software Livre é utilizado como basepara o desenvolvimento de um produto proprietário com característicasexclusivas. Como é o caso do Mac OS X.

● Prestação de serviços: é o ramo mais utilizado para obtenção de receitas comSoftware 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 deum 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 nodesenvolvimento e correções de novos produtos de software.

● personalização do software, para atender as necessidades específicas de cada

37

usuário, empresa ou instituições diversas (educacionais ou não);

● possibilidade de evitar monopólio, garantindo que o novo software desenvolvidoutilize padrões abertos.

● garantia contra descontinuidade.

O Software Livre é um exemplo notável de organização em grupo. Asexpectativas para seu desenvolvimento futuro são interessantes e percebe-se umatendê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. Estaevolução é resultado de um conjunto heterogêneo de eventos, atores e perspectivas. O processotem por premissa a criação de grandes comunidades de prática, em que há engajamento emtorno de um domínio comum no qual, em alguns casos, ocorre a socialização de conhecimentoe 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 eaçã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úmerasiniciativas tem promovido o uso do Software Livre por um número cada vez crescentede empresas, profissionais liberais e voluntários (pessoas comuns) como ferramentapara “afirmação de nossa cidadania, de nossa inteligência coletiva, de redução: dadependência tecnológica, do pagamento de royalties ao Primeiro Mundo”(IdBrasil,2006), e da miséria, através de oportunidades criativas de compartilhamentodo conhecimento conforme apresenta o próximo capítulo.

38

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 nosserviços que a administração pública lhe presta, esta por sua vez, se vê incapacitada depleitear 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 demonstraramplamente as suas pretensões.

Este contexto onde se destacam a falta de recursos financeiros para a realizaçãode altos investimentos em tecnologia, e a urgência na aquisição de tecnologias de pontaa preços acessíveis e com qualidade suficiente para reverter o estado caótico em que seencontra a administração pública no Brasil, veio de encontro ao aumento dapopularização do software livre no país, amplamente apoiado e incentivado inclusivepelo 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, aSociedade Softex em parceria com o ITI – Instituto Nacional de Tecnologia daInformação realizou em 2004 uma ampla pesquisa sobre a adoção de software livre nasPrefeituras Brasileiras enfocando principalmente as condições de financiamento paraesses processos de informatização, a apuração dos benefícios diretos e indiretos de suaadoção e os arranjos que se mostraram mais eficazes.

Ao todo foram contactadas mais de 5.500 prefeituras sendo 90% delas de pequeno porte, comdificuldades de acesso a programas de financiamento de informatização e todas sujeitas a leisde 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 consumidore produtor de software, o objetivo maior da pesquisa foi o de promover uma reflexãosobre as possibilidades e oportunidades trazidas pelo Software Livre não só para ainformatização da administração pública, mas também para a própria indústria nacionalde software.

Software Livre pertence à indústria de software. Nela se desenvolve e a transforma. Osmodelos de negócios do software livre são os modelos de negócios da indústria de software. OSL/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

observar que o uso de software livre propiciou redução da ilegalidade no uso desoftware, redução de custos, redirecionamento de recursos não gastos com licenças paraa melhoria do parque instalado - melhor aproveitamento de hardwares, maior autonomiatecnológica, maior transparência da gestão, segurança, independência de fornecedores eestabilidade. Uma necessidade fundamental foi detectada por todos os municípios: a daexistência de um repositório comum, de livre acesso às prefeituras onde estivessemdisponíveis informações importantes sobre diversos aspectos da informatização,software livre disponível, avaliação de ferramentas por parte de especialistas, melhorespráticas, fornecedores e profissionais capacitados, etc. (SOFTEX,2005a)

Tal constatação propiciou a oportunidade de criação do projeto VIA DIGITALorientado pelo bem social com base na informatização pública (foco para as pequenasprefeituras) apoiado em duas grandes tendências - a componentização (engenharia desoftware baseada em componentes – ESBC) e o Software Livre.

O projeto, inicialmente denominado FLOPREF (Free/ Livre/ Open Softwarepara prefeituras), tendo como órgão financiador a Financiadora de Estudos eProjetos/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 tornode 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 necessidadescomuns de prefeituras e componentes genéricos para montagem de sistemasmais 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, tantopara funcionários de prefeituras quanto para desenvolvedores, integradores efornecedores de soluções/serviços para o poder público. Incluindo-selicenciamento, direitos autorais, modelos de negócio, modelos e ferramentas dedesenvolvimento de software e gestão de projetos, qualidade de software,

40

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 objetivosapresentados na Tabela 11: Etapas do Projeto VIA DIGITAL.

Tabela 11: Etapas do Projeto VIA DIGITAL

Etapa Atividades Objetivo

Projeto Piloto ● desenvolver e operacionalizar uma metodologiade indução de produção e uso de componentesde software reutilizáveis a partir de umrepositório – a Biblioteca de Componentes;

● seleção dos atores (5 “sistemas” apropriados(prefeituras, empresas, profissionais e agentes)(LUCCA,2005)) e contratação, com recursosaprovados pela FINEP;

● desenvolvimento de software das empresaspara as prefeituras.

Testar umametodologia deindução doprocesso para emseguida expandi-la.

Projeto Expansão

(será definidosomente após aavaliação dosresultados doProjeto Piloto).

● aplicação prática de uma estratégia paralela desensibilização de prefeituras frente ao uso daBiblioteca de Componentes e em relação àsfontes de financiamento público àinformatização;

● desenvolver meios para capacitar as prefeiturasa receber tais recursos em troca de que suacontratação ocorra condicionando a compra adisponibilização do software na Biblioteca deComponentes.

Expandir ametodologiautilizada na fase detestes e apoiar ainformatização deum número muitomaior deprefeituras.

41

Diversos modelos de interação entre as partes envolvidas foram criados eavaliados. Foram formalizados processos de avaliação de processos e de componentes ea conceituação de ecossistemas locais de desenvolvimento. Encontra-se emdesenvolvimento um experimento piloto para a constituição de ecossistemas em cincocidades (Patos-PB, Recreio-MG, Amparo-SP, Santa Clara do Sul-RS e Canela-RS),com o desenvolvimento dos componentes:

● SIAPA - SISTEMA DE ACOMPANHAMENTO DE PROGRAMASASSISTENCIAIS - 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 deuniversidades, a partir da motivação de estudantes de graduação e pós-graduação paraparticiparem do desenvolvimento de requisitos pré-especificados para os componentescitados. Graças a essa estratégia organizada em torno do VIA DIGITAL, fomosconvidados pela Consultora Ângela Maria Alves, também Coordenadora e Professorado curso de Produção de Software com Ênfase em Software Livre da UniversidadeFederal de Lavras (UFLA), a fazermos parte desta história. Nas próximas seções serãodetalhados o componente SICE, escolhido pela equipe da qual fiz parte, e os aspectos desua gerência realizados de forma a aplicar simultaneamente o processo dedesenvolvimento definido para o projeto e os conceitos aprendidos durante o cursosobre a gerência segundo o PMBOK.

4.2 – Componente de Controle de Estoque (SICE)

De acordo com o Documento de Requisitos disponibilizado juntamente com oEdital do projeto (SWFACTORY, 2006), o objetivo deste componente é possibilitar ocontrole da entrada e saída de produtos do almoxarifado, permitindo que estes sejamvinculados ao patrimônio da Prefeitura de Recreio (MG). Para tanto, a qualquermomento são oferecidas informações sobre o estoque do almoxarifado e sobre opatrimônio.

4.2.1 - Abrangência

O sistema deverá permitir o cadastro de todos os produtos (pertencentes aopatrimônio ou não) que possam ficar armazenados no estoque da Prefeitura, sendo estesclassificados através do atributo ’Tipo’ vinculado a cada produto. Estes tipos serãocadastrados previamente pelo usuário e poderão, por exemplo, classificar os produtosem 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 produtosque irão entrar no estoque através da Nota Fiscal de Compra ou através de outracategoria de entrada. Considerando que caso existam produtos na Nota Fiscal que aindanão estejam no sistema, estes deverão ser cadastrados, através do requisito inserirproduto.

Para efetivar a entrada física de produtos no estoque, o responsável pelo estoque,

42

deverá conferir a Nota Fiscal, os dados informados pela digitação e os própriosprodutos, a fim de evitar irregularidades. Uma vez realizada esta verificação o usuáriopoderá informar em qual endereço físico o produto será armazenado no estoque.

O estoque deverá ser dividido fisicamente em “endereços” para facilitar alocalização dos produtos cadastrados.

Toda a saída de produtos do almoxarifado deverá ser autorizada por um usuárioresponsável pelo mesmo.

Em nenhum momento será necessária a circulação de papéis no processo deentrada e saída de produtos do almoxarifado, exceto a nota fiscal.

Uma importante funcionalidade do sistema será a manutenção do estoque doalmoxarifado através do estoque mínimo. Esta funcionalidade irá informar aoresponsável sempre que um determinado produto atingir o estoque mínimo.

O sistema deverá emitir relatórios sobre o estoque, estoque de produto por tipode produto, movimentação de todos os produtos do estoque por período, movimentaçãode produtos do estoque por período e por tipo de produto, movimentação de um produtopor período, produtos que atingiram o estoque mínimo, saída de produtos por tipo eprodutos solicitados pelo responsável pelo setor.

4.2.2 - Usuários

Para operação do sistema os seguintes usuários foram identificados:

● Administrador: capaz de executar todas as funcionalidades do sistema.Principalmente adicionar usuários no sistema e definir seus perfis;

● Digitador: responsável pela alimentação do banco de dados. Realizarátodos os cadastros de produtos, cadastros de fornecedores, cadastro desetores, etc;

● Responsável pelo Almoxarifado: usuário responsável por confirmar aentrada e saída de produtos no almoxarifado. Para esta confirmação omesmo deverá conferir a quantidade dos produtos, junto com as notas einformações de entradas de produtos cadastrados no sistema peloUsuário Digitador;

● Responsável pelo Setor da Prefeitura: responsável por solicitarprodutos junto ao almoxarifado da prefeitura, e confirmar a entrada esaída destes no setor solicitante;

● Gestor: responsável por autorizar ou não a saída de produtos doalmoxarifado para os setores da prefeitura.

4.2.3 – Requisitos não funcionais

A Tabela 12: Requisitos não funcionais do SICE sintetiza os requisitos nãofuncionais definidos o SICE de acordo com o documento de requisitos já referenciadoanteriormente.

Tabela 12: Requisitos não funcionais do SICE

43

Requisito nãofuncional

Descrição

Descrição do componente

documento expondo as propriedades do componente, com o principal objetivode auxiliar os potenciais adquirentes, sejam usuários ou integradores, naavaliação da adequação do componente antes de sua aquisição. Deve seguir osrequisitos de qualidade da descrição de produto da norma NBR ISO/IEC12119.

Documentaçãopara o usuário

O componente admissível para o Via Digital deverá disponibilizar umadocumentação para o usuário, contendo todas as informações necessárias paraa correta utilização do componente Via Digital.A documentação pode ser apresentada na forma impressa, em mídia ou on-line e deve seguir os requisitos de qualidade das normas NBR ISO/IEC 12119e IEEE 1063.

Componente VIA DIGITAL

O componente Via Digital deve seguir os requisitos de qualidade de umproduto de software alinhando-se aos requisitos da Norma NBR ISO/IEC9126-1 e os requisitos para pacote de software da norma NBR ISO/IEC12119.

Requisitos de Instalação.

Tratam das considerações necessárias para a construção do pacote deinstalação do componente de infra-estrutura.

4.3 – Aspectos da gerência do SICE: EasyProcess & PMBOK

Criado em 2004 por uma equipe de alunos da Universidade Federal de CampinaGrande (UFCG), orientados pela Dra. Francilene Procópio Garcia, uma dasresponsáveis pelo Grupo de Pesquisa e Desenvolvimento em Engenharia de Software doDepartamento de Sistemas e Computação da UFCG, o EasyProcess é um processosimplificado baseado nas melhores práticas do RUP, XP e Agile Modeling, que buscaatender a necessidade de se utilizar as melhores práticas para desenvolvimento desoftware no meio acadêmico, que possibilitem maior sucesso na implementação deprojetos oferecidos em algumas disciplinas. Por extensão busca ainda tornar-se umametodologia a ser utilizada pelos alunos da graduação da UFCG e em projetos depequeno e médio porte em empresas.

Conforme o trabalho realizado pela UFCG (UFCG, 2004), o fluxo de trabalhoutilizado nesse processo compreende as seguintes atividades em síntese ilustradas pelaFigura 1. Síntese do EasyProcess e os detalhamentos apresentados nas próximas seções:

44

Figura 5: Síntese do EasyProcessFonte: EasyProcess – Um processo de desenvolvimento de software

4.3.1 – Identificação do escopo do problema

Nesta etapa os desenvolvedores devem se informar sobre o domínio doproblema através de leitura de todos os documentos (se houver) existentes sobre oprojeto proposto tais como: editais, proposta, justificativas, etc.

Para que seja garantida melhor produtividade durante a entrevista inicial com ocliente, deve ser elaborado um roteiro de perguntas que venha a auxiliar a equipe alevantar as informações mais importantes e que representem fatores chave para aaceitação do produto final.

4.3.1.1 - Aplicação no SICE

Conforme citado anteriormente, o Componente SICE tem como cliente aPrefeitura Municipal de Recreio – MG. Todo o contato com este cliente paralevantamento das características e requisitos de software demandados e posteriorelaboração da Especificação de Requisitos, foi realizada pela equipe executora doprojeto aprovado pela FINEP, de acordo com o cronograma físico estabelecido naproposta (FLOPREF, 2004).

No âmbito da minha responsabilidade, vou considerar nesta etapa todo o contatoinicial com a orientadora do TCC para aquisição de informações sobre a proposta doVIA DIGITAL e toda a pesquisa que realizei para conhecimento do projeto em detalhesconforme relato a seguir.

Durante o I ENCONTRO TÉCNICO deste curso de Pós-graduação, realizadoem Novembro de 2005 e, conforme citado anteriormente, época do desenvolvimento doProjeto Piloto do VIA DIGITAL, toda a minha turma foi convidada pela Prof. Ângela aparticipar deste projeto desenvolvendo componentes de acordo com os requisitos jádefinidos pela equipe oficial.

A partir deste convite passei a colher informações sobre o projeto e suaorganização visando detectar roteiros de estudo que viabilizassem o desenvolvimento deum trabalho de conclusão de curso (TCC) aliado à produção técnica de algo que pudesseser realmente agregado como uma contribuição valiosa ao VIA DIGITAL.

45

Realizei um ampla pesquisa através de vários documentos que obtive porintermédio da UFLA, através do ambiente de ensino a distância Moodle e que relacionona Tabela 13: Pesquisas iniciais sobre o SICE a seguir:

Tabela 13: Pesquisas iniciais sobre o SICE

Documento Objetivo

Proposta do VIA DIGITAL Proposta completa do VIA DIGITAL aprovada pela FINEP(FLOPREF, 2004).

Sistema de Gestão Municipal –SGM

Divulgar o Sistema de Gestão Municipal – SGM a serdesenvolvido para integrar os principais processos de umaprefeitura em uma única ferramenta de TI. A SERPRO seráa responsável pelo processamento centralizado de dados eirá certificar empresas para prestação de serviços locais paraas prefeituras que precisarem. Detalha os objetivosprincipais do sistema, arquitetura, subsistemas e atividadesa serem prestadas pelas empresas certificadas(DORNELLES, 2004).

Soluções SERPRO para GestãoMunicipal.

Mesmo objetivo do documento anterior porém com maioresdetalhes (SERPRO, 2004).

Projeto FLOPREF BrasilInformatizado.

Apresenta a importância da informatização daadministração pública, o estágio atual da informatizaçãopública no Brasil, o SL como alternativa (impactoseconômicos, tecnológicos e sociais), as principais barreiras,os objetivos do projeto, sua estratégia, principais impactosesperados (tecnológicos, econômicos e sociais), as fases desua execução e os meios de se obter maiores informações(LUCCA, 2005).

Via Digital – Caminhointeligente para informatizaçãopública.

Apresentação do Projeto VIA DIGITAL em inglês(LUCCA, 2005a).

EasyProcess – Um processo dedesenvolvimento de software.

Descreve em detalhes todas as etapas deste processo dedesenvolvimento de software, bem como artefatos a seremgerados e papéis a serem definidos (UFCG,2004).

Componentes OOS VIADIGITAL.

Apresenta os objetivos do desenvolvimento de componentese suas características como: arquitetura, tecnologia, padrãode documentação e modelo de distribuição (UFCG, 2006).

ANEXO I – ArcabouçoArquitetural

Detalha a arquitetura em camadas sob a qual o componentedeverá ser construído (UFLA, 2006)

ANEXO IV – Tecnologias Detalha as tecnologias requeridas para a construção decomponentes VIA DIGITAL (UFLA, 2006a).

Sistema de Controle de Estoques– Documento de Requisitos

Documento de requisitos do Sistema de Controle deEstoque para a Prefeitura Municipal de Recreio – MG.Versão 2.0 (SWFACTORY, 2006).

Portal do VIA DIGITAL Portal de informações detalhadas sobre o projeto e seuacompanhamento. Disponibiliza acesso ao repositório decomponentes (VIADIGITAL, 2007).

46

Foi um período longo de leitura e conhecimento do projeto em si. Por váriasvezes discuti com a Prof. Ângela as possibilidades de estudo e desenvolvimento práticode temas que viessem também de encontro ao meu desejo de me aprofundar na área degerência de projetos. No período de abril a julho de 2006 conversamos sobre apossibilidade de estudar a metodologia utilizada no projeto, os critérios deadmissibilidade de componentes, o acompanhamento a campo do trabalho prático daequipe do VIA DIGITAL, enfim, várias foram as alternativas. Em paralelo entrei emcontato com o colega de turma Roberto Rocha que também havia se interessado emparticipar do projeto e estava procurando alguém que quisesse cuidar da documentação,testes ou gerência na equipe que ele estava montando. Como nossos interesses secompletavam contactamos a Prof. Ângela novamente e juntos percebemos que seriainteressante o trabalho conjunto e a união de nossos objetivos.

4.3.1.2 - Áreas equivalentes do PMBOK

A área do conhecimento da Gerência de Projetos correspondente a esta etapa é aGerência de Escopo do Projeto.

4.3.1.3 - Dificuldades encontradas

As principais dificuldades experimentadas nesta fase foram:● encontrar um tema para desenvolvimento do TCC que gerasse um

resultado de qualidade suficiente para ser admitido como contribuição devalor ao Projeto VIA DIGITAL e que ao mesmo tempo me permitisseadquirir experiência prática na gestão de projetos e/ou na execução demetodologias/processos de desenvolvimento;

● cursar as demais disciplinas do curso, realizando as provas, atividades etrabalhos em grupo solicitados ao mesmo tempo em que estudava a vastadocumentação do VIA DIGITAL, somando-se ainda as atividadesprofissionais intensas ocorridas neste mesmo período;

● problemas de saúde que me impediram de participar do II EncontroTécnico em junho e em Novembro de 2006. Mesmo assim um escopopara o desenvolvimento do TCC foi definido com a Prof. Ângela esubmetido para a UFLA. Decidi trancar minha matrícula no curso parafinalizar as disciplinas que restavam e ter condições de me dedicarexclusivamente ao trabalho de conclusão.

4.3.2 – Definição de papéis

Ao organizar uma equipe de desenvolvimento de software deve também serorganizada uma divisão de tarefas entre seus membros de forma que cada um assumaum determinado papel no desenvolvimento. Por papel compreende-se um conjunto deresponsabilidades que determinem qual será o comportamento de uma pessoa durante oprocesso. Deverá ser alocado de acordo com as necessidades do projeto, levando emconsideração as habilidades e características de personalidade das pessoas envolvidas.

É essencial que todos os papéis estejam presentes na equipe para evitar o

47

esquecimento de etapas importantes do processo, ou mesmo a sua realização de formanão satisfatória. Cada pessoa alocada para um projeto pode desempenhar vários papéissimultaneamente. Ao gerente, porém, cabe a responsabilidade de evitar o acúmulo depapéis que resultem em uma sobrecarga de tarefa que possa comprometer a realizaçãodo projeto.

O EasyProcess prevê a definição de 5 papéis conforme identifica a Tabela 14:Papéis no EasyProcess e ilustra a Figura 6: Papéis no Easyprocess, a seguir:

Tabela 14: Papéis no EasyProcess

Papel Responsabilidades

Cliente definir as funcionalidades do sistema e priorizá-las; ajudar a elaborar o planode releases; explicitar os testes de aceitação e ser ativo no processo dedesenvolvimento do sistema.

Usuário ajudar a definir os testes de aceitação e avaliar continuamente a interface dosistema.

Gerente conduzir os planejamentos e ações dos desenvolvedores; elaborar o plano dedesenvolvimento (release e iteração); avaliar sistematicamente os riscosdescobertos; coletar e analisar métricas; alocar testadores; gerenciarconfigurações; presidir as reuniões de acompanhamento; resolver conflitosinternos e tornar acessível a documentação do projeto.

Desenvolvedor levantar os requisitos funcionais e não funcionais junto ao cliente; auxiliar ogerente na elaboração de um plano de desenvolvimento; gerar testes deunidade; manter a integração contínua de código.

Testador efetuar revisões e elaborar testes sobre o código de outro desenvolvedor alémde gerar testes de aceitação.

48

Figura 6: Papéis no EasyProcessFonte: EasyProcess – Um processo de desenvolvimento de software


Durante a disciplina de Engenharia de Software para Software Livre 3realizamos em grupo um trabalho prático para o desenvolvimento do Sistema deControle de Alterações em Artefatos – SICAA. Esta experiência foi muito rica emoportunidades de aquisição de conhecimentos e habilidades pessoais relacionados àquestões técnicas, administrativas e de relacionamento inter-pessoal que acabaram porpromover a criação de laços de confiabilidade e respeito muito grande entre algunsalunos que trabalharam diretamente comigo, sendo eles: Roberto Ribeiro Rocha, JulianoOrtigoso Gaspar e Cláudio Luís Pozzebon.

Com a possibilidade de desenvolvermos um novo projeto nos mesmos moldesdo SICAA, porém voltado para um âmbito bem maior, a partir da minha união inicialcom o Roberto Rocha (citado na fase anterior) e da divulgação do que pretendíamosfazer, a equipe acabou se reunindo novamente, agora com maior segurança emtrabalharmos juntos e com maior certeza de que tínhamos condições de gerarmos umresultado muito positivo para o que fora proposto.

Desta forma, identificamos claramente os papéis que deveriam existir durante odesenvolvimento do SICE e os responsáveis por cada um como mostra a Tabela 15:Papéis no SICE, a seguir:

Tabela 15: Papéis no SICE

Papel Responsável

Cliente Prof. Ângela Alves

Gerente e Testadora Jeanne Louize Emygdio

Desenvolvedor da Camada de Apresentação Cláudio Luiz Pozzebon

Desenvolvedor da Camada de Aplicação e Integrador Roberto Ribeiro Rocha

Desenvolvedor da Camada de Persistência Juliano Ortigoso GasparA Prof. Ângela Alves foi definida como nosso cliente por ser o elo de ligação

49

entre a nossa equipe e a equipe do VIA DIGITAL, além de ser a transmissora de todasas informações que necessitávamos para o desenvolvimento e a elaboração do TCC.

Acumulei o papel de testadora em virtude de não participar das tarefas deimplementação (conforme previsto no processo) e de estar em constante contato com osdocumentos oficiais do projeto para realizar o controle do escopo.

O Roberto Rocha acumulou a tarefa de integração dos artefatos produzidos nasdemais camadas em virtude da sua experiência prática com as tecnologias e padrõesestabelecidos para o projeto.

Particularmente, cada desenvolvedor deveria aplicar testes unitários nosartefatos que produzisse (quando coubesse).


As áreas do conhecimento da Gerência de Projetos correspondentes a esta etapasão: a Gerência de Escopo do Projeto (onde se define o Gerente do Projeto) e a Gerênciados Recursos Humanos do Projeto.


Nesta etapa foi sinalizado entre a equipe a dificuldade que teríamos paraconciliar nossas atividades profissionais com o período de desenvolvimento do projeto eo de escrita do TCC.

4.3.3 – Conversa com o cliente

A partir da conversa com o cliente, após uma identificação do escopo doproblema, um artefato contendo a visão sobre os processos de negócios do cliente deveser gerado. Esta conversa deve ser entre o cliente e a equipe de desenvolvimento,apoiada pelo roteiro de perguntas que deverá ser elaborado antes da conversa para que aequipe entenda o escopo do problema

Durante a entrevista os desenvolvedores devem primar por tornar a reuniãoprodutiva através da utilização de uma linguagem simples e do emprego de analogias.Deverá informar ao cliente o seu papel e agendar reuniões periódicas com o cliente.

Ao final da entrevista a equipe deverá ter uma idéia bem definida do escopo doproblema; conhecer o perfil dos usuários do sistema e suas necessidades; saber quaissão os requisitos funcionais e não-funcionais do sistema além de listar todos os riscosdo projeto.

Em seguida deverá ser elaborado pelos desenvolvedores um documento devisão, contendo as idéias gerais sobre o que o sistema se propões a fazer de forma quepossa apoiar os processos de negócios do cliente. Este documento serve para avaliar se aequipe de desenvolvimento entendeu corretamente o domínio do problema descrito pelocliente; garantir oficialmente os termos de contrato entre o cliente e o desenvolvedor,após sua assinatura; sinalizar se houve mudanças muito grandes no projeto durante o

50

processo; levar o desenvolvedor a pensar no sistema como um todo, inserido no cenáriode negócios do cliente, antes de começar a desenvolvê-lo, evitando alteraçõesconstantes e minimizando alguns tipos de riscos; avaliar se o desenvolvimento doprojeto é viável.

Deve abranger:● os principais termos envolvidos no escopo do problema (glossário);● os problemas a serem resolvidos e como eles afetam o processo de

negócios do cliente;● a identificação dos usuários e os demais envolvidos no projeto além de

suas necessidades;● as características do produto;● os requisitos funcionais e os não-funcionais;● as limitações do projeto.


Após a leitura de toda a documentação obtida sobre o projeto e oestabelecimento da equipe executora, organizei um questionário inicial de contato com aÂngela visando criar oficialmente um vínculo permanente com ela até o final doprojeto, esclarecer as condições de trabalho da nossa equipe e seu relacionamento com aequipe oficial do VIA DIGITAL. Foram levantadas as seguintes questões:

1. Quem é o Gerente do VIA DIGITAL em âmbito geral? Preciso ter contato com ele parame situar no projeto e orientar a equipe.

2. Já existe algum desenvolvimento em andamento para este componente? 3. Todos os formulários a serem utilizados já se encontram no formato ideal no documento

da Metodologia?4. Vamos realizar todas as tarefas previstas no documento de Requisitos ou alguma já foi

realizada?5. Teremos um ambiente disponível para controle do cronograma (dotproject, por

exemplo)? 6. No anexo II - Tecnologia li a informação sobre a distribuição de um CD por parte do

via digital com todos os SL necessários ao desenvolvimento, como podemos ter acessoa ele?

7. No documento Componente OOS do Via Digital faz-se uma referência ao Mysql comoSGBD, isto vale apenas para este componente? O nosso permanece com Postgres,conforme Anexo II - Tecnologia? Após diversos contatos, relacionados no ANEXO A – Entrevistas com o cliente,

ANEXO B – Atas de reuniões e ANEXO H – Atividades da gerência em detalhes,foram obtidas as seguintes informações:Sobre o andamento do VIA DIGITAL: existe desenvolvimento paralelo de várioscomponentes para o projeto, porém independente dessa situação, poderíamos trabalharlivremente buscando sempre seguir todas as documentações oficiais, para não fugirmosdo seu escopo. A idéia é a de construir uma biblioteca de componentes reutilizáveis (ede qualidade), para tanto os melhores seriam aprovados de acordo com critérios deadmissibilidade pré-estabelecidos;Sobre o portal do projeto e documentações: todas as informações referentes constamem Edital próprio (e atualizado) que seria repassado por ela à nossa equipe. Outrasinformações poderiam ser obtidas através do portal oficial do projeto VIA DIGITAL

51

(VIADIGITAL, 2007). As dúvidas deveriam ser retiradas diretamente com ela. ATabela 16: Canais de informações para o SICE enumera alguns repositórios deinformações sobre o projeto:

Tabela 16: Canais de informações para o SICE

Objetivo Link

Portal do VIA DIGITAL http://www.viadigital.ufsc.br/

Acesso ao repositório do VIA DIGITAL paraupload de versões

www.repositorio.viadigital.org.br

Download dos documentos de especificação http://www.swfactory.com.br/Recreio.zip

Sobre contato com a equipe oficial do VIADIGITAL: teríamos contato com o PMIdo Projeto, Sr. Adler Diniz para termos conhecimento de sua metodologia de trabalhovisando transferência de tecnologias e conhecimentos. Não seríamos obrigados a seguirsua metodologia na íntegra e no âmbito do nosso trabalho, poderíamos escolher qualferramental metodológico e técnico iríamos utilizar e nomear gerente próprio paraorientar nossas atividades. A Tabela 17: Contatos para o SICE define os contatos para oprojeto.

Tabela 17: Contatos para o SICE

Contato Formasde acesso

Referências

Ângela Maria Alves (orientadora do TCC e contato com a equipe do VIA DIGITAL

MSN [email protected]

Skype angela.m.alves

E_mails [email protected]@cenpra.gov.br

Adler Diniz de Souza (PMI do Projeto: suporte metodológico)

MSN [email protected]

Skype adlerdiniz

Weslei Marinho – suporte técnico ao desenvolvimento (ferramentas, ambiente, etc.)

E_mail [email protected]

A Prof. Ângela ficou responsável por nos apresentar ao Sr. Adler e por solicitara volta do Repositório do VIA DIGITAL ao ar para que pudéssemos utilizar oudisponibilizar o antigo ambiente do dotproject que utilizamos na disciplina deEngenharia de Software 3 para organizarmos nosso cronograma.

Sobre as tarefas a serem realizadas: partiríamos diretamente para a implementação apartir dos casos de uso que selecionássemos entre os definidos na Especificação deRequisitos. O objetivo seria executar o processo de desenvolvimento e criticá-logerando um histórico base para escrita do TCC;Sobre ferramental a ser utilizado: embora no portal do VIA DIGITAL pudesse serencontrado todo o ferramental sugerido para o projeto, inclusive com links paradownloads, poderíamos escolher ferramental próprio para o desenvolvimento, porémmantendo a premissa de utilizar apenas Software Livre.

Todas as demais informações esperadas para esta fase já se encontravam

52

http://www.viadigital.ufsc.br/

mailto:[email protected]





http://www.swfactory.com.br/Recreio.zip

http://www.repositorio.viadigital.org.br/

definidas nos documentos repassados à nossa equipe pela Prof. Ângela e relacionadosna Tabela 18: Documentos adicionais do SICE, a seguir:

Tabela 18: Documentos adicionais do SICE

Documento Objetivo

Utilizando CVS.odt Tutorial para uso do CVS do Via Digital

CVS_Campina Grande.odt Discussão sobre uso do CVS do Via Digital

Revisão 04.07.06.zip Edital do projeto contendo os documentos:• Anexo I Projeto Básico ver 2.2• Anexo II Projeto Executivo 2.2• Anexo III Arquitetura ver 2.6• Anexo IV Tecnologia ver 2.5• Anexo V Avaliação Componentes ver 1.0• Anexo VI Minuta Contrato ver 2.3• Anexo VII Proposta Comercial ver 2.1• Anexo VIII Declarações • Anexo IX Aceite dos produtos ver 2.3• Carta Convite Componente ver 07

Recreio.zip (link para download) Especificação de requisitos contendo:• Casos de Uso;• Diagramas de Caso de Uso;• Documento de Requisitos (OLIVEIRA, 2006);• Matriz de rastreabilidade bidirecional;• Workflows.

Para facilitar a disseminação de informações sobre o SICE e mesmo oandamento do nosso trabalho, as decisões tomadas, as premissas, os problemas e tudo oque fosse relevante para o uso durante o desenvolvimento, foi instalada uma ferramentade edição colaborativa em Software Livre denominada PMWIKI, que para a equipeficou conhecida simplesmente como Wiki.

Elaborei 2 atas de reuniões referentes aos dias 21/08/06 e 22/08/06 que podemser consultadas no ANEXO B – Atas de reuniões. As atas e todos os documentosrecebidos pela Ângela também foram organizados e publicados no Wiki.


As áreas do conhecimento da Gerência de Projetos correspondentes a esta etapasão: a Gerência de Integração e da Qualidade (considerando todo o conteúdo dasinformações dos documentos do Edital). A Gerência das Comunicações ficoucaracterizadas pelas ações para disseminação de informações entre a equipe.


A principal dificuldade experimentadas nesta fase foi a disponibilidade daequipe para leitura e discussão sobre os documentos recebidos em virtude das atividadesprofissionais realizadas no mesmo período.

53

4.3.4 – Inicialização

O objetivo desta fase é:● identificar as funcionalidades do sistema por meio da especificação das User

Stories, que deverão ser realizadas pelo cliente;● obter uma descrição do sistema em alto nível a partir do projeto arquitetural que

deverá ser elaborado pela equipe de desenvolvimento. O projeto arquiteturalmostra a estrutura do sistema e as dependências existentes entre seuscomponentes;

● obter do cliente a aprovação do projeto arquitetural;● obter a definição da estrutura de algum banco de dados envolvido a partir da

construção de um modelo lógico de dados pela equipe de desenvolvimento.A importância desta fase reside no fato de que um projeto arquitetural

consistente e um modelo lógico bem definido acomodam mudanças facilmente,reduzindo atividades trabalhosas.


Os objetivos desta fase foram contemplados através do conteúdo dosdocumentos recebidos via orientadora: Anexo I Projeto Básico, Anexo II ProjetoExecutivo, Anexo III Arquitetura, Anexo IV Tecnologias, Anexo V Avaliação deComponentes e a Especificação de Requisitos completa descrita na Tabela 18:Documentos adicionais do SICE apresentada na etapa anterior.

Sob a nossa responsabilidade ficou a elaboração do Modelo Lógico dos dados,que restringimos aos requisitos que iríamos desenvolver. O Modelo foi elaborado peloJuliano e revisado por mim, podendo ser consultado diretamente em seu trabalho deconclusão de curso (GASPAR,2006).

Durante a leitura dos documentos recebidos via orientadora, toda a equipe sefocou nos Anexos III – Arquitetura e IV – Tecnologias em virtude do vasto ferramentalproposto. Conversamos muito sobre cada tecnologia e sobre a arquitetura propostabuscando compreender a utilização de cada ferramenta dentro de cada camada previstapor um dos padrões que também deveria ser adotado no projeto.

Em reunião com o Juliano, elaboramos uma tabela com as tecnologias sugeridaspor camada para que todos identificassem quais teriam condições de usar, e ao final doprojeto conseguíssemos construir um registro do que realmente utilizamos. O resultadofinal desta iniciativa pode ser consultado no ANEXO C – Ferramental previsto xutilizado no desenvolvimento do SICE e ANEXO D – Ferramental de apoio aodesenvolvimento do SICE.

Outra iniciativa ocorrida nesta fase foi a elaboração de um resumo de toda ametodologia a ser aplicada durante a execução do projeto, de modo a facilitar oentendimento da equipe sobre o processo, as vantagens de sua aplicação, as atividadesque teriam que fazer (antes mesmo do início da implementação) além de tornar menoscansativa a reunião que tivemos sobre ele. O resumo elaborado pode ser consultado noANEXO E - Easyprocess em síntese.


As áreas do conhecimento da Gerência de Projetos correspondentes a esta etapa

54

são: a Gerência de Integração e da Qualidade (considerando todo o conteúdo dasinformações dos documentos do Edital, destacando a metodologia de desenvolvimento(processo)). A Gerência das Comunicações ficou caracterizada pelas ações paradisseminação de informações entre a equipe pelos diversos canais de comunicação alémdas reuniões para discussão de tecnologias e processo de desenvolvimento.


As principais dificuldades experimentadas nesta fase foram:● o desconhecimento das tecnologias e de sua aplicação de acordo com as

camadas onde se relacionavam. Houve uma troca proveitosa deconhecimentos entre os membros da equipe sobre padrão MVC (Model –View – Controller);

● os problemas técnicos ocorridos na organização dos ambientes dedesenvolvimento de todos os membros da equipe;

● as dificuldades em motivar a equipe a utilizar o processo dedesenvolvimento e entender as vantagens de seu uso. Fizemos umareunião para discussão do processo, mas senti a equipe bem reservada emrelação ao que discutíamos.

4.3.5 – Planejamento de releases

Concluídas as atividades de inicialização, deve ser iniciado o planejamento doprojeto. Primeiramente a equipe deve estar ciente do tempo disponível para odesenvolvimento do projeto, e a partir de então, com o cliente, definir o número dereleases e de iterações necessárias para a conclusão do mesmo.

As User Stories devem ser alocadas nos releases e em seguida nas iterações,considerando-se a priorização sugerida pelo cliente, que deverá ser alertado pelosdesenvolvedores, sobre quais User Stories devem ser implementadas primeiro,considerando-se fatores técnicos que possam por exemplo representar riscos para oprojeto. Uma observação importante é a de que a alocação de User Stories deve ser feitaapenas para o próximo release, pois o surgimento de mudanças e novos requisitos podeinvalidar um planejamento de atividades ainda distantes.


Em virtude do tempo disponível para elaboração do TCC, decidimos em reuniãoescolher os requisitos mais simples para que pudéssemos executar todas as etapas doprocesso de desenvolvimento pelo menos duas vezes.

Desta forma os Requisitos Funcionais escolhidos foram RF13 – Inserir Tipo deProduto e RF9 – Inserir Produto. O Roberto Rocha pretendia ainda desenvolver o RF51– Relatório/Listagem dos produtos (por tipo de produtos), mas preferimos deixá-lo paraplanejamento após a implementação dos dois requisitos anteriormente selecionados casoainda houvesse tempo hábil. O detalhamento dos requisitos podem ser consultados noDocumento de Requisitos (OLIVEIRA, 2006), Documento de Caso de Uso: DCU 13(OLIVEIRA, 2006a) e Documento de Caso de Uso: DCU 09 (OLIVEIRA, 2006b). Osdiagramas de caso de uso podem ser encontrados em um arquivo próprio do Judecontendo todos os diagramas especificados para o componente (SWFACTORY, 2006).

55

A Tabela 19: Plano de Release mostra o planejamento realizado nesta fase paraconstrução dos Requisitos Funcionais selecionados.

Tabela 19: Plano de Release

Release Período Requisitos Funcionais

Release 1 1 a 15 de setembro de 2006 RF13 e RF09

Ainda nesta fase o Juliano elaborou Modelo Físico dos dados que foi validadopor mim podendo ser consultado diretamente em seu trabalho de conclusão de curso(GASPAR,2006).

Todas as decisões tomadas e artefatos desenvolvidos foram publicadas no Wiki.


As áreas do conhecimento da Gerência de Projetos correspondentes a esta etapasão: a Gerência do Tempo do Projeto (considerando a seleção dos User Stories a seremdesenvolvidos e o sequenciamento entre eles). A Gerência das Comunicações ficoucaracterizada pela reunião de planejamento do release e as ações para disseminação deinformações entre a equipe através do Wiki.


A única dificuldade encontrada nesta etapa foi convencer o Roberto Rocha sobreos requisitos possíveis de serem desenvolvidos dentro do prazo que dispúnhamos paradefinição do período do release.

4.3.6 – Planejamento de iteração

Todas as User Stories devem ser divididas em tarefas. Cada tarefa deverá seralocada nas iterações do release. O EasyProcess sugere fazer uso da tabela de alocaçãode tarefas (TAT) para listar todas as tarefas da iteração, especificando o tempo dedesenvolvimento e o responsável por cada uma delas, levando em consideração ashabilidades de cada um e o seu tempo de dedicação ao projeto.

Para completar o planejamento da iteração, os testes de aceitação das UserStories deverão ser definidos com o cliente (plano de testes). Cada User Story deve terpelo menos um teste de aceitação.

Durante todo o planejamento, tanto dos releases quanto das iterações, os riscosdevem ser identificados e analisados.

O tempo sugerido pelo Easyprocess para planejamento é de até 2horas. O temposugerido para cada release é de 1 mês contendo 2 iterações.


Após o término da reunião de Planejamento de Release e Iterações obtiveinformações que, acrescidas às coletadas nas fases anteriores me permitiram organizar amatriz de competências e dedicação representada pela Tabela 20: Matriz deCompetências/Dedicação.

Tabela 20: Matriz de Competências/Dedicação

56

Recurso Competências Dedicação(Horas/semana)

Cláudio - HTML, XHTML- CSS- JSP- Javascript

5

Jeanne - Habilidade gerencial- Facilidade de comunicação e organização- Testadora- Dotproject / PMBOK

10

Juliano - Modelagem de dados- Dbdesigner- DIA- Mysql

10

Roberto - J2SE- Webwork- Eclipse- Padrão MVC

10

Elaboramos em equipe o Plano de Iterações e a Alocação de tarefas para aIteração 1 conforme mostram a Tabela 21: Plano de Iterações e a Tabela 22: Alocaçãode Tarefas para a Iteração 1 a seguir:

Tabela 21: Plano de Iterações

Release 1: 01/09/06 a 15/09/06

Iterações Período Requisitos Funcionais

Iteração 1 01 a 08/09 RF09

Iteração 2 09 a 15/09 RF13

Tabela 22: Alocação de Tarefas para Iteração 1

TAT – Iteração 1

Tarefa Descrição Responsável Estimativa(horas)

Tempo real(horas)

Status

T1 Modelagem física Juliano 1,5

T2 Elaboração dos casos de testesunitários

Juliano 1

T3 Elaboração dos casos de testes deaceitação

Jeanne 1

T4 Implementação da Interface gráfica Cláudio 2


Roberto 1

T6 Implementação das classes deaplicação

Roberto 2,5

T7 Implementação da interface para Juliano 1

57


classes de banco

T8 Implementação das classes de banco Juliano 1

T9 Aplicação de testes unitários nasclasses de banco

Juliano 1

T10 Aplicação de de testes unitários nasclasses de aplicação

Roberto 1

T11 Integração Roberto 4

T12 Aplicação de testes de aceitação Jeanne 2

T13 Validação da interface gráfica Jeanne 1

Total de horas previstas 20

Com base na Tabela de Alocação de Tarefas (TAT) foi elaborado o cronogramainicial de atividades da equipe conforme mostra a Tabela 23: Cronograma Iteração 1SICE a seguir:

Tabela 23: Cronograma Iteração 1 SICE

Tarefa 01 02 03 04 05 06 07 08 Responsável

T1 --- Juliano

T2 --- Juliano

T7 --- Juliano

T8 --- Juliano

T9 --- Juliano

T3 --- Jeanne

T4 --- Cláudio

T13 --- Jeanne

T5 --- Roberto

T6 --- --- Roberto

T10 --- Roberto

T11 --- --- Roberto

T12 --- Jeanne

Em virtude do grande volume de informações referentes ao projeto decidielaborar o Plano de Comunicação constante no ANEXO F - Plano de comunicação parao SICE.

Ao longo das fases anteriores e como resultado de nossas reuniões, trocas dee_mails e contatos via Skype foi possível detectar vários riscos para o projeto e aspossíveis soluções para cada um deles. O levantamento realizado e a análise de cadarisco pode ser consultado no ANEXO G – Análise de riscos para o SICE.

58


As áreas do conhecimento da Gerência de Projetos correspondentes às atividadesrealizadas nesta etapa são: a Gerência do Tempo, a Gerência de Recursos Humanos, aGerência das comunicações e a Gerência dos Riscos do Projeto.


Esta etapa teve uma importância especial para a equipe porque todas asatividades previstas até então deveriam estar concluídas para que pudéssemos nosconcentrar apenas nos problemas que surgissem durante a implementação. Porém,várias dificuldades foram experimentadas:

● o Cláudio teve restrições em utilizar apenas SL para o desenvolvimentoem virtude de já possuir experiência em ferramentas proprietárias e dotempo para escrita do TCC. Discutimos entre a equipe e concluímos quea premissa de desenvolvimento apenas com SL deveria ser mantida aomáximo. O Cláudio aceitou o desafio. Os detalhes destas discussõespodem ser consultados na Ata do dia 29/08/06 no ANEXO B – Atas dereuniões;

● várias dúvidas foram levantadas em relação aos padrões paraimplementação previstos no Easyprocess. O Roberto se reuniu com aequipe para discutir o que cada padrão exigia e como se daria suaaplicação no SICE;

● o grande volume de informações gerados pela equipe representou paramim grande dificuldade tendo em vista as atividades previstas para mimno cronograma e as minhas atividades profissionais no período;

● as ferramentas do VIA DIGITAL para controle de cronograma e deversões não foram disponibilizadas em tempo hábil. O Cláudio instalou odotproject no servidor onde havia instalado o Wiki e eu organizei astarefas por lá para que a equipe fizesse os logs diários;

● dificuldade em obter a disponibilidade semanal da equipe para o projetoem virtude de suas atividades profissionais no período. Só consegui obterestas informações durante a reunião para planejamento do release e dasiterações;

● detectamos que os documentos disponibilizados no Edital ainda nãoestavam 100% concluídos. O Guia de Estilos ainda não havia sido feito eo Cláudio teve que tentar se aproximar ao máximo possível doselementos previstos em imagem no documento Anexo III – Arquiteturas.Solicitei à equipe do VIA DIGITAL porém até a conclusão do projetonão recebemos o documento. Posteriormente soubemos através da Prof.Ângela que os Editais ainda não haviam sido publicados.

4.3.7 – Implementação

Durante a fase de implementação deverá ser considerado o uso das seguintestécnicas:

Propriedade coletiva de código: habilidade de qualquer membro da equipe poder alterar

59

o código elaborado por outros membros durante o desenvolvimento. Toda a equipe éresponsável por ele. Para que funcione é imprescindível que haja um controle contínuo eeficiente de versões, para que se controle quem está alterando cada trecho de código emdeterminado momento, evitando conflitos.

Uso de padrões: uma vez que o Easyprocess sugere a propriedade coletiva de código,deve-se considerar a necessidade de geração de um código limpo (sem linhas de códigodesnecessárias, repetição de trechos de código, com implementação de funcionalidadesnão condizentes com as User Stories). Sugere-se aplicar ao projeto as práticas de DesignSimples(melhor código possível, de fácil entendimento e com comentários essenciais,etc.), Padrões de codificação (identação, nomeação de métodos e variáveis, etc.),Padrões de Projeto (soluções previamente pensadas por grandes projetistas daOrientação a Objetos facilitando a reutilização de micro-arquiteturas de classes, objetose suas funcionalidades) e Refatoramento (pequena modificação no código visandomelhorar qualidades não funcionais).

Releases pequenos: visando garantir maior interação com o cliente e a redução doimpacto das mudanças de requisitos, bem como sobre os erros de implementação. Acada finalização de iteração sugere-se um novo encontro com o cliente do projeto.

Integração contínua: o processo propõe que a integração dos módulos gerados dosistema seja feita de forma contínua, com o apoio de alguma ferramenta de controle deversão. Tal prática beneficia a equipe principalmente em relação à falta de horárioscomuns de trabalho entre os membros. O gerenciamento do progresso através da coletade métricas com a geração de um Big Chart é feita de forma consistente e simplesdevido à integração.

Programação em pares: antes de ser aplicada deve-se analisar escopo, tempo ehabilidades da equipe.


Durante esta etapa ocorreram duas mudanças importantes que resultaram nareorganização do Plano de Release, Plano de Iterações e Cronograma.

A UFLA alterou o prazo de entrega do TCC e como ainda estávamos com osproblemas detectados na etapa anterior, achamos melhor replanejar.

O Juliano, revisando os Requisitos Funcionais detectou que a ordem previstapela equipe deveria ser alterada em razão da dependência entre os requisitos.

O Plano de Release e o Plano de Iterações atualizados são exibidos a seguir deacordo com a Tabela 24: Plano de Release modificado e Tabela 25: Plano de Iteraçõesmodificado. A organização das atividades no cronograma permaneceu inalterada mesmotendo sido alterada a ordem de implementação dos requisitos. A alteração consistiuapenas nos dias previstos de acordo com o calendário.

Tabela 24: Plano de Release modificado

Release Período Requisitos Funcionais

Release 1 4 a 17 de setembro de 2006 RF13 e RF09

Tabela 25: Plano de Iterações modificado

60

Release 1: 01/09/06 a 17/09/06

Iterações Período Requisitos Funcionais

Iteração 1 (I1) 04 a 09/09 RF13

Iteração 2 (I2) 10 a 17/09 RF09

Seguem observações quanto à observância das técnicas previstas para esta fase:Propriedade coletiva de código e Refatoramento: consideramos que as atividades deintegração feitas pelo Roberto contemplaram ambas as técnicas a partir da substituiçãoda taginput pela taglib visando facilitar o uso do Webwork. O Juliano e o Cláudiotambém disponibilizaram seus códigos para que todos os demais opinassem emelhorassem o que quisessem.Uso de padrões: foram aplicados no projeto o padrão MVC para desenvolvimento emcamadas; DAO (Data Access Objects) - abstraem e encapsulam todo tipo de acesso afonte de dados; DTO /VO (Value Objects) - objetos de transferência de dados;FACADES - fachadas para simplificação das interfaces; CSS (Cascading Style Sheets) -linguagem de estilo utilizada para definição de apresentação de documentos) evalidadores Javascript. Maiores detalhes sobre os padrões e a implementação podem serconsultados nos TCCs do Roberto (ROCHA, 2006), do Juliano (GASPAR, 2006) e doCláudio (POZZEBON, 2007).Releases pequenos: o próprio planejamento de release que fizemos já atendeu a estatécnica pelo número reduzido de requisitos escolhidos para implementação.Integração contínua: só não foi melhor atendida porque não conseguimos o CVSfuncionando em tempo hábil. Mas houve integração realizada pelo Roberto.Programação em pares e Construção do BIG CHART: não foram realizadas em virtudedo tempo e distribuição geográfica da equipe.

Houve a sugestão de uso de três ferramentas: Subversion (SVN) em substtiuiçãoao CVS por ser uma evolução dele; Tags Webwork em substituição ao Struts portambém ser uma evolução dele e Pamela Call Recorder, um pacote do Skype paragravação da reuniões e discussões da equipe facilitando assim a recuperação futura deinformações importantes para o projeto.

Os artefatos e tarefas realizadas neste período por toda a equipe, bem comotodos os problemas experimentados podem ser consultados na Ata de reunião do dia13/09/06 no ANEXO B – Atas de reuniões. Esta etapa foi muito rica em experiênciastécnicas e inter-relacionais para toda a equipe. Houve um grande empenho de todos paraque o desenvolvimento acontecesse dentro do período previsto e de acordo com osEditais. Todos os desenvolvedores sinalizaram aspectos positivos da participação noprojeto em termos profissionais, pessoais e acadêmicos.


As áreas do conhecimento da Gerência de Projetos correspondentes às atividadesrealizadas nesta etapa são: a Gerência da Integração, a Gerência do Tempo e a Gerênciadas comunicações.

61


As dificuldades encontradas nesta etapa foram:● os ambientes de desenvolvimento ainda não estavam totalmente

funcionais, ocorreram diversos problemas de configuração e de uso dasferramentas em virtude da pouca experiência com elas aliado ao temporestrito para estudar melhores configurações; diversas dúvidas sobre qualferramenta escolher;

● contato rápido com PMI do VIA DIGITAL trouxe informaçõescontrárias ao que havíamos estudado sobre o Easyprocess. Tenteicontactá-lo para discutirmos mas não foi possível. Decidimos manter asatividades dentro da metodologia que já havíamos estudado e planejado;

● Dotproject não foi disponibilizado para a nossa equipe pelo Weslei. OCláudio instalou uma versão no mesmo servidor do Wiki e eu organizeio cronograma lá para a equipe logar. Registrei o projeto no Repositóriodo VIA DIGITAL mas conseguimos a aprovação somente após otérmino do prazo de conclusão da primeira iteração;

● disponibilidade da equipe para o Projeto em virtude das atividadesprofissionais e a necessidade de dedicação à família;

● o CVS do VIA DIGITAL não foi disponibilizado para a equipe o quecomplicou a tarefa de integração. O Roberto disponibilizou o Subversion(SVN) instalado em sua máquina para acessarmos via TortoiseSVN;

● os documentos disponibilizados pela equipe do VIA DIGITAL ainda nãoestavam concluídos, possuíam comentários e o Guia de Estilos não foilocalizado.

4.3.8 – Reuniões de acompanhamento

Reuniões de acompanhamento deverão ser realizadas semanalmente, sob acoordenação do gerente do projeto e com participação de toda a equipe dedesenvolvimento com o objetivo de analisar os resultados obtidos durante a semana;levantar dados para a construção do Big Chart; revisar e/ou concluir a TAT; revisar,analisar e encontrar soluções para os riscos; identificar as mudanças e levantar anecessidade de refatoramento de código.

O Big Chart representa uma análise quantitativa do andamento do projeto apartir do recolhimento de métricas definidas pelo gerente de projeto de acordo com ospontos principais a serem analisados (por exemplo: número de classes existentes,número de linhas de código, etc.). Seu uso pode ser muito útil para o gerente quepossuir uma percepção aguçada diante das relações existentes entre os dados expostosno Big Chart.

Os riscos são situações indesejáveis que ocorrem durante o processo dedesenvolvimento e sua análise é uma metodologia proposta para reduzir estas situaçõesatravés de uma constante verificação do estado do projeto. Semanalmente, para cadarisco levantado o gerente aloca um responsável por eliminá-lo, dentro de uma prioridadee de tempo dentro do projeto. Assim que o risco for eliminado, a solução proposta écolocada na tabela de riscos para que se mantenha um repositório de soluções. O tempoprevisto para levantamento dos riscos e das medidas para solucioná-los deve girar em

62

torno de 15 a 20 minutos, de acordo com o EasyProcess.A partir da análise feita sobre os resultados da semana o gerente é capaz de

identificar os pontos nos quais o projeto está caminhando bem, e aqueles onde existamfalhas, podendo assim, buscar soluções para melhorar os resultados futuramenteobtidos.

O tempo recomendado pelo EasyProcess para realização das reuniões é de 1hora e 30 minutos.


A reunião foi uma experiência importante para todos. Ouvir os progressos e osproblemas de cada um enriquece o profissional que consegue aprender desta forma.

O tempo total da reunião foi de 3h14min. Todos os membros da equipeestiveram presentes e relataram suas realizações, os problemas que experimentaram e otempo gasto em cada tarefa. Ao final de cada relato fiz uma breve análise dos problemasque detectava em relação ao alinhamento no processo e solicitava a resolução dastarefas que ficaram pendentes. Fiz ainda análise de risco.

Forneci algumas informações adicionais sobre o andamento dos contatos com aequipe do VIA DIGITAL para acesso ao Repositório.

Detectei que todos utilizaram apenas ferramentas livres para o desenvolvimento.

Todos estes detalhes podem ser consultados na Ata do dia 13/09/07 no ANEXOB – Atas de reuniões conforme já citado anteriormente.

A Tabela 26: TAT após o término da reunião de acompanhamento ilustra asituação do desenvolvimento detectada ao final da reunião.

Tabela 26: TAT após término da reunião de acompanhamento


Tarefa Descrição Responsável Estimativa(horas)

Tempo real(horas)

Status

T1 Modelagem física Juliano 1,5 2 C


Juliano 1 - P

T3 Elaboração dos casos de testes deaceitação

Jeanne 1 - P

T4 Implementação da Interface gráfica Cláudio 2 2 C


Roberto 1 - P

T6 Implementação das classes deaplicação

Roberto 2,5 2 C

63


T7 Implementação da interface paraclasses de banco

Juliano 1 ? ?

T8 Implementação das classes de banco Juliano 1 ? C

T9 Aplicação de testes unitários nasclasses de banco

Juliano 1 ? C

T10 Aplicação de de testes unitários nasclasses de aplicação

Roberto 1 - P

T11 Integração Roberto 4 3,5 C

T12 Aplicação de testes de aceitação Jeanne 2 - P

T13 Validação da interface gráfica Jeanne 1 2 C

Total de horas previstas 20 11,5


As áreas do conhecimento da Gerência de Projetos correspondentes às atividadesrealizadas nesta etapa são a Gerência da Integração, a Gerência de Tempo e a Gerênciade Riscos do Projeto.


As dificuldades experimentadas durante a reunião foram:● problemas de comunicação pelo tipo de link à internet; VOIP fica lento

quando há mais de uma pessoa utilizando simultaneamente;desconhecimento de pacotes do Skype para gravação das nossasconversas (Pamela Call Recorder); grande variação no tempo deassimilação das informações por cada membro da equipe fez com quediscutíssemos os mesmos assuntos por várias vezes; dispersões emfunção de ocorrências familiares; velocidade de digitação também afetouo tempo da reunião;

● detectar os problemas na execução do processo e saber colocar isso paraa equipe de modo a motivá-los a fazer com mais atenção durante apróxima iteração. Relembrei a todos da necessidade de teremos foco nãosó na prática técnica mas também no processo já que é esse um dostópicos mais abordados atualmente quando se fala em qualidade:qualidade do produto e do processo. Informei que os problemas deimplantação de processos são normais no início e tendem a diminuir como tempo. Elogiei a iniciativa de todos consultarem a documentaçãodurante o desenvolvimento;

● problemas no acompanhamento do cronograma e a falta de logsacabaram por contribuir para os furos detectados no processo. Sem logsa equipe não acompanha a finalização de uma tarefa, o prazo para iniciara outra, etc. Posteriormente detectei que a geração do cronograma em 3lugares diferentes pode ter afetado o acompanhamento da equipe (Wiki,

64

dotproject e Repositório do VIA DIGITAL).● os problemas ocorridos no processo e acompanhamento do cronograma

favoreceram a construção de artefatos que não foram previstos e a nãoconstrução de artefatos previstos por todos nós (em conjunto); um dosdesenvolvedores chegou mesmo durante a reunião a sugerir a construçãode artefatos que não faziam parte da iteração (havia outro “processo”mental sendo executado em paralelo;

● não previ no cronograma tempo para realização das tarefas da gerência eisso tornou muito difícil disponibilizar informações para a equipe emtempo hábil, estar com eles para solucionar problemas, intermediarcontato com a equipe do VIA DIGITAL, acompanhar o andamento docronograma e do processo, analisar riscos e tomar decisões;

● passei por problemas sérios de saúde em família e não foi possívelacompanhar o andamento do projeto de forma contínua depois destareunião.

4.3.9 - Fim da iteração com verificação dos testes de aceitação

Ao final da iteração deve ser considerada a execução de:

1. Testes de unidade: escritos antes da construção do código e responsáveis pelavalidação das menores partes do sistema, ou seja, os métodos, classes ou atétrechos de códigos confusos. Devem ser realizados continuamente;

2. Revisão de código: cada testador revisa o código gerado por outro membro daequipe (reforça a idéia de propriedade coletiva de código). Esta técnica auxiliana melhoria da qualidade e da funcionalidade do código através de revisõesinternas. Cabe ao gerente determinar o momento mais adequado para a equipeefetuar a revisão de código.

3. Testes de aceitação: cenários que devem ser suportados pelo software. Conjuntode situações definidas pelo cliente sobre como medir o sucesso do projeto. Aduração destes testes é variável de acordo com o escopo do problema.Uma User Story só é considerada implementada quando for submetida a todas

as baterias de testes, passando com sucesso.


Não foi possível a realização completa desta etapa do processo em virtude dosproblemas pessoais que tive e que comprometeram o andamento das atividades finais daequipe. Soma-se à esta situação a aproximação do término do prazo para a escrita doTCC e portanto o término também do prazo disponível para o desenvolvimento.

Os testes realizados que tive conhecimento a partir da reunião deacompanhamento foram os de unidade realizados pelo Juliano com base em sua práticaprofissional (portanto sem elaboração de um plano de testes) e os testes de integraçãorealizados pelo Roberto nas mesmas condições do Juliano.

O componente final do SICE foi disponibilizado pelo Roberto para download noSubversion Google Code, no endereço http://sice.googlecode.com/svn/trunk/sice/.

65

http://sice.googlecode.com/svn/trunk/sice/

http://sice.googlecode.com/svn/trunk/sice/


As áreas do conhecimento da Gerência de Projetos correspondentes às atividadesrealizadas nesta etapa são: a Gerência da Integração e, quando a iteração for a últimaprevista para todo o projeto, a Gerências de Aquisição (Encerramento de contrato) eGerência de Comunicação (Encerramento Administrativo).

4.3.9.3 – Análise final de participação

As atividades que realizei no projeto compreenderam: definição do tema a serestudado no meu TCC e auxílio com sugestão aos demais colegas de equipe em funçãodas experiências que estávamos tendo; atividades da Gerência de Comunicação;familiarização com o processo de desenvolvimento e nivelamento da equipe sobre ele;estudo dos documentos dos editais – atividades da Gerência de escopo; experiência comnovas tecnologias; planejamento e direção de reuniões; elaboração das atas; análises derisco; acompanhamentos diversos do andamento, tanto via e_mail quanto por todos oscanais de comunicação utilizados; validações de artefatos produzidos; planejamentos dereleases e iterações; organização de cronogramas e auxílio à equipe na utilização dodotproject e Repositório do VIA DIGITAL.

Considero muito positiva a minha participação no projeto. Procurei acompanharao máximo possível o andamento das atividades, dedicando um total de 71h09mincomprovadas através do ANEXO H – Atividades da gerência em detalhes. Forammuitas madrugadas de trabalho muito válido ao lado de pessoas realmente interessadas ecomprometidas. Mas confirmei na prática a sobrecarga de tarefas para implementaçãode processos de desenvolvimento.

Procurei manter o escopo do trabalho e direcionar a equipe para um trabalhocoeso desde o início, através de reuniões de nivelamento no processo e escopo.

Senti dificuldades em manter os registros das atividades em dia. Foi um trabalhocansativo e descobri a necessidade de maior disciplina neste tipo de responsabilidade.

Mesmo não participando da implementação procurei aprender com a experiênciaprática da equipe e auxiliar nos problemas de forma que as atividades não ficassemparadas. Em suma foi uma experiência ao mesmo tempo desafiadora e agregadora devaliosos conhecimentos e vivências.

66

Conclusões

Este trabalho apresentou o relato das experiências resultantes das práticasgerenciais executadas durante o desenvolvimento do componente SICE, e das práticasexecutadas na implementação e validação do Processo de DesenvolvimentoeasYProcess, a partir das quais foi possível constatar que o sucesso no desenvolvimentode um projeto depende do comprometimento da gerência em:

● conhecer as melhores práticas da gerência de projetos atualmente utilizadasaplicando-as adequadamente com o apoio de ferramentas tecnológicas quefacilitem a gestão e a sinalização de aspectos cruciais durante odesenvolvimento, tais como riscos, custos e marcos do projeto;

● de acordo com as necessidades do projeto, envolver o esforço de mais de umindivíduo evitando a sobrecarga de tarefas para apenas um gerente. Cada área dagerência de projetos exige muita dedicação e controle para fornecer asinformações necessárias ao bom andamento do projeto até a sua conclusão;

● conhecer o domínio do problema o mais cedo possível, explorando todo ouniverso de informações em torno do negócio onde se irá trabalhar, selecionandocriteriosamente as informações de real valor que possam contribuir para oandamento eficiente do projeto. A criação de uma base de conhecimentos sobreo projeto a ser implementado poderá ser muito útil para nortear a equipe duranteo desenvolvimento;

● conhecer as principais metodologias de desenvolvimento de software atualmenteutilizadas e ser capaz de, após detectar todas as características do projeto,selecionar a metodologia mais adequada; analisar as necessidades ou não deadaptação (inclusão, alteração ou eliminação de artefatos, fluxos e processos)para o projeto; planejar as atividades a serem realizadas por toda a equipeseguindo os fluxos e etapas previstas na metodologia e por fim acompanhar aimplantação corrigindo desvios e dirimindo dúvidas. O gerente deve preparartoda a estrutura para implantação da metodologia previamente ao mesmo tempoem que se capacita para orientar a equipe com segurança;

● formalizar os contatos e estabelecer vínculos com os profissionais e/ou clientesenvolvidos em um projeto o quanto antes para dirimir dúvidas resultantes doestudo do domínio do problema, conhecer toda a infra-estrutura disponibilizadapor eles para uso (se houver) além de “sentir” as expectativas reais dos clientessobre o projeto. É preciso conhecer em profundidade o terreno onde irá pisar,para então poder caminhar com segurança;

● pesquisar relatos de experiências de outros profissionais em situações similares,afinal, nenhum trabalho realmente parte do zero, muitas dificuldades análogas jáforam vivenciadas e há inúmeras contribuições importantes publicadas no meioacadêmico e científico que podem facilitar consideravelmente a complexidadedas tarefas;

67

● conhecer as ferramentas de desenvolvimento o quanto antes, instalá-las e testá-las tendo o cuidado de elaborar ao mesmo tempo os tutoriais de instalação, que,futuramente minimizarão o tempo a ser dispendido quando da entrada de novosmembros à equipe;

● avaliar constantemente a comunicação e o planejamento do projeto de forma atomar as decisões corretas nos momentos cruciais. Uma comunicação falha ouem excesso pode comprometer de forma irreversível o andamento e a conclusãode um projeto.

Gerir projetos por si só já representa tarefa extremamente complexa. Gerirprojetos em SL e coordenar simultaneamente a implantação de processos dedesenvolvimento, com todas as suas características particulares, exige disciplina,comprometimento, estudo, gosto pela pesquisa, tempo, remuneração e motivação paravencer os inúmeros desafios apresentados ao longo deste documento, como os decomunicação, de relacionamento inter-pessoal, de gestão do tempo e da qualidade, degestão de competências e da motivação constante da equipe na busca pelo sucesso doprojeto.

Conhecer o projeto VIA DIGITAL e fazer parte de sua equipe executoracontribuiu para aumentar a percepção de perspectivas de crescimento da indústrianacional de software a partir das novas oportunidades de organização de modelos denegócios em torno de projetos em SL tão inovadores e extremamente inteligentes comoeste, situando-nos como atores ativos deste processo cujas contribuições pessoais nãodeverão parar por aqui.

Na esfera acadêmica o trabalho consolidou todo o conhecimento adquirido aolongo do curso a partir do momento em que foi possível perceber, além do referencialteórico utilizado na elaboração deste documento, a aplicação de conceitos estudados emtodas as disciplinas do curso, comprovadas por todo o registro de atividades quetambém o compõem. A aplicação dos conceitos estudados nas disciplinas de Introduçãoao SL/CA e Empreendedorismo foram cruciais para a percepção de todas aspossibilidades provenientes da participação de um projeto tão relevante para o nossopaís e para o Movimento de SL como é o VIA DIGITAL.

Na esfera pessoal e profissional o trabalho constituiu um desafio que juntamentecom todos os outros desenvolvidos durante o curso, trouxe novas possibilidades para aminha vida profissional além de todos os aspectos positivos relacionados a seguir:

● participação em um projeto real de grande impacto para a sociedade brasileira epara a consolidação do Movimento de Software Livre no País;

● experiência em desenvolvimento de software livre e implantação de processosde desenvolvimento de software para equipes geograficamente distribuídas;

● experiência na gerência de projetos com equipes geograficamente distribuídasutilizando apenas ferramentas livres;

● experiência em ferramentas livres que já tem trazido melhorias na realização dasminhas atividades profissionais;

68

● maior conhecimento de padrões para desenvolvimento de software;● contato com profissionais experientes na área e com membros da equipe oficial

do VIA DIGITAL;● elaboração de um referencial histórico de todas as atividades realizadas,

sucessos, erros, e problemas ocorridos durante a nossa experiência de forma acompensar a falta de registro nas ferramentas oficiais do projeto por razões jácitadas ao longo deste trabalho;

● desenvolvimento de opinião crítica sobre os impactos econômicos, tecnológicose políticos da utilização de Software Livre tornando-me assim um agentecapacitado a influenciar mudanças em todos os meios onde atuo;

● oportunidade de apresentar meu trabalho no VIII Congresso de Qualidade naProdução de Software e em outros eventos da área;

● criação de laços de amizade com grandes profissionais participantes deste curso.

Duas perspectivas futuras foram descobertas:● divulgar o projeto VIA DIGITAL e motivar a participação de outras pessoas;

● contribuir como for possível para a continuidade do trabalho que iniciamos.

Uma importante meta foi estabelecida:

● obter uma certificação em Gerência de Projetos pelo PMI – ProjectManagement Institute.

Em virtude de todas as informações obtidas e apresentadas ao longo desteestudo, das perspectivas futuras e dos resultados relacionados, considero o Projeto VIADIGITAL uma oportunidade imperdível para referenciar os profissionais de Tecnologiada Informação inseridos em sua execução pela dimensão de conhecimentos que devemser desenvolvidos nestes profissionais, conforme foi possível constatar nas diversasexperiências práticas que ele proporcionou a toda a nossa equipe.

O futuro promissor deste projeto depende exclusivamente do despertar deinteligências colaborativas, dinâmicas e transformadoras, restritas apenas aos limites dacriatividade humana.

Estes novos tempos, com ares de “conspiração universal”, desafiamnosso potencial para superar velhos limites, para superar o medo e ainércia; para atingirmos níveis de realização, de plenitude de ação, deliberdade, de aproximação e contato humano, de colaboração e decompartilhamento. É o momento participarmos ativamente dasdiscussões em torno destas revoluções e encontrarmos a nossa maneirade colaborarmos para a construção de uma nova realidade, sendosujeitos de nossa própria educação (Silva,2001).

69

Referências bibliográficasABIB, Janaina Cintra. Qualidade de Software. Setembro de 1999.

ALVES, Ângela Maria. Introdução à Produção de Software: Software Livre / CódigoAberto (SL/CA). Lavras: UFLA/FAEPE, 2005.

LUCCA, José Eduardo De. Projeto FLOPREF Brasil Informatizado. Santa Catarina:UFSC, 2005. Disponível em:http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=229. Últimoacesso em: 27 out 2007.

LUCCA, José Eduardo De. VIA DIGITAL – Caminho inteligente para a informatizaçãopública. Santa Catarina: UFSC/geNESS, 2005. Disponível em:http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=230. Útimoacesso em: 27 out 2007.

DORNELLES, Alexandre. Sistema de Gestão Municipal – SGM. Dezembro de 2004.Disponível em: http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=226. Último acesso em 27 out de 2007.

FLOPREF. Free/Livre/Open Software para Prefeituras. Santa Catarina: UFSC, 2004.Disponível em: http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=228. Último acesso em: 27 out 2007.

GASPAR, Juliano Ortigoso. Persistência de Dados em Componente do VIA DIGITAL.Lavras: UFLA/FAEPE, 2006.

GRUHN, Volker. Process-Centered Software Engineering Environments - A BriefHistory and Future Challenges. Annals of Software Engineering 14, 363–382, 2002.

IDBRASIL. Ministério das Comunicações. Inclusão Digital é sinônimo de SoftwareLivre. Brasília, 2006. Disponível em:http://www.idbrasil.gov.br/docs_telecentro/docs_telecentro/sw_livre. Último acesso em:

26/09/2007.

IEEE. Guide to the Software Engineering Body of Knowledge – SWEBOK, 2004.Disponível em http://www.swebok.org. Último acesso em: Setembro de 2007.

LEITE, Jair Cavalcanti. Página de Engenharia de Software. Disponível emhttp://www.dimap.ufrn.br/~jair/ES/. Último acesso em 26/09/2007.

LUCCA, José Carlos de. Projeto FLOPREF Brasil Informatizado. Santa Catarina:UFSC, 2005.

OLIVEIRA, Janaina Faria de. Documento de requisitos - versão 4.0. Lavras:UFLA/SWFactory, 2006.

OLIVEIRA, Janaina Faria de. Documento de Caso de Uso: DCU 13. Lavras:UFLA/SWFactory, 2006.

70

http://www.dimap.ufrn.br/~jair/ES/

http://www.dimap.ufrn.br/~jair/ES/

http://www.swebok.org/

http://www.idbrasil.gov.br/docs_telecentro/docs_telecentro/sw_livre

http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=228






OLIVEIRA, Janaina Faria de. Documento de Caso de Uso: DCU 09. Lavras:UFLA/SWFactory, 2006.

PMIMG. Project Management Institute Brazil Minas Gerais Chapter. Tradução livre doPMBOK 2000, V 1.0. 2002.

POZZEBON, Cláudio Luiz. Aspectos de Implementação da Interface Gráfica docomponente SICE do Via Digital. Lavras: UFLA/FAEPE, 2007.

ROCHA, Roberto Ribeiro. Aspectos do desenvolvimento inicial de um software livre decontrole de estoque utilizando o framework Webwork. Lavras: UFLA/FAEPE, 2006.

SERPRO. Soluções SERPRO para Gestão Municipal. 2004. Disponível em:http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=227. Últimoacesso em: 27 out de 2007.

SILVA, Mozart Linhares da (org). Novas Tecnologias – Educação e Sociedade na erada informação. Belo Horizonte. 2001.

SILVEIRA, Sérgio Amadeu da. Inclusão digital, software livre e globalização contra-hegemônica. Brasília. 2005. Disponível em:http://www.softwarelivre.gov.br/softwarelivre/artigos/artigo_02. Último acesso:26/09/2007.

SOFTEX. SOFTEX/UNICAMP/MTC, O Impacto do Software Livre e de CódigoAberto na Indústria de Software do Brasil. Abril de 2005. O Software Livre nasprefeituras brasileiras. Abril de 2005.

SOFTEX. O Software Livre nas Prefeituras Brasileiras: novas alternativas para ainformatização da administração pública. Softex, Campinas. 2005.

SOUZA, Adler Diniz... [et al.]. Escritório de gerenciamento de projetos: umaabordagem para gerência de múltiplos projetos, dispersos geograficamente, no âmbitodo programa via digital. Disponível em:http://www.swfactory.com.br/principal/arquivos/arquivo_02.pdf. Último acesso em: 18ago 2007.

SWFACTORY. Sistema de Controle de estoque – Documento de requisitos, versão 2.0.Lavras, 2006. Disponível em:http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=456. Últimoacesso em: 27 out 2007.

SWFACTORY. Sistema de Controle de estoque – Documento de requisitos, versão 4.0.Lavras, 2006.

UFCG, Universidade Federal de Campina Grande. Programa Especial de TreinamentoPET – EASYPROCESS – Um processo de desenvolvimento de Software. CampinaGrande, 2004. Disponível em:http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=232. Últimoacesso em: 27 out 2007.

71



http://www.swfactory.com.br/principal/arquivos/arquivo_02.pdf



http://www.softex.br/cgi/cgilua.exe/sys/start.htm?infoid=5565&sid=37

http://www.softex.br/cgi/cgilua.exe/sys/start.htm?infoid=5565&sid=37

http://www.meulugar.org.br/meulugar/arquivos/inclusao_digital.pdf


UFCG, Universidade Federal de Campina Grande. Componentes OOS VIA DIGITAL –Padronização. Campina Grande: UFCG, 2006. Disponível em:http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=233. Últimoacesso em: 27 out 2007.

UFLA, Universidade Federal de Lavras. Anexo I: Arcabouço Arquitetural. Lavras:UFLA, 2006. Disponível em:http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=234. Últimoacesso em: 27 out 2007.

UFLA, Universidade Federal de Lavras. Anexo II: Tecnologias. Lavras: UFLA, 2006.Disponível em: http://www.ead.swquality.com.br/moodle/psl/mod/resource/view.php?id=235. Último acesso em: 27 out 2007.

VASCONCELOS, Alexandre Marcos Lins de. Processos de Desenvolvimento deSoftware 1. Lavras: UFLA, 2005.

VASCONCELOS, Alexandre Marcos Lins de ... [et al.]. Introdução à Engenharia deSoftware e Qualidade de Software. Lavras: UFLA, 2006.

VIADIGITAL. Disponível em www.viadigital.org.br. Último acesso em: 18 out 2007.

72

http://www.viadigital.org.br/





ANEXOS

73

ANEXO A – Entrevistas com o cliente17/08/06 – Contato com a Prof. Ângela via e_mail sobreo projeto.

Prof. Ângela, conforme contatos anteriores, eu, o RobertoRocha, o Cláudio e o Juliano montamos uma equipe paradesenvolvermos algumas funcionalidades do componenteSICE do Via Digital como estudo de caso para o nossoTCC.

Realizei uma leitura no documento da Metodologia deDesenvolvimento - EasyProcess e já identifiquei as tarefasque devem ser realizadas para a implementação dosrequisitos. Lí também o Anexo I - Arquitetura, Anexo II -Tecnologia, a Especificação de Requisitos e o ComponenteOOS do Via Digital.Precisamos de orientações para o planejamento do nossotrabalho:

• Quem é o Gerente deste projeto em âmbito geral?Preciso ter contato com ele para me situar noprojeto e orientar a equipe

• Já existe algum desenvolvimento em andamentopara este componente?

• Todos os formulários a serem utilizados já seencontram no formato ideal neste documento daMetodologia?

• Vamos realizar todas as tarefas previstas nodocumento ou alguma já foi realizada?

• Teremos um ambiente disponível para controle docronograma (dotproject, por exemplo)?

• No anexo II - Tecnologia li a informação sobre adistribuição de um CD por parte do via digitalcom todos os SL necessários ao desenvolvimento,como podemos ter acesso a ele?

• No documento Componente OOS do Via Digital

faz-se uma referência ao Mysql como SGBD, istovale apenas para este componente? O nossopermanece com Postgres, conforme Anexo II -Tecnologia?

Aguardo seu retorno urgente para darmos início nestetrabalho, ok? Obrigada pela atenção. Jeanne (Obs.: e_mailcom cópia para a equipe.)

20/08/06 e 21/08 – Contatos com a Prof. Ângela viae_mail

Prof. Ângela, bom dia! respondendo às suas questões(enviadas por ela no dia 20/08):1ª) Jeanne: quem é o Gerente deste projeto em âmbitogeral? Preciso ter contato com ele para me situar no projetoe orientar a equipe.

Ângela (20/08): Acho que não entendi a questão. Vocêquer saber quem é o gerente de desenvolvimento doscomponentes do Via?

Jeanne (21/08): Exatamente. Se vamos fazer parte de umprojeto que já está em andamento, teremos que ter contatocom o(s) gerente(s) para sabermos o que já foi feito e o queestá pendente. Informações gerais sobre odesenvolvimento, procedimentos, acesso ao CVS, etc.Concorda?

2ª) Jeanne: Já existe algum desenvolvimento em andamento para este componente?

Ângela (20:08): Já existem componentes desenvolvidos(depositados no repositório) e em desenvolvimento.

Jeanne (21/08): Eu entrei no site do Via Digital, mas estátudo tão parado por lá que até achei que o projeto ainda nãohavia começado. Onde posso consultar as tarefas emandamento, as concluídas, não encontrei nada por lá? Nãohá tarefas registradas! O endereço do site onde entrei é:

http://150.162.66.229/ (Repositório do Via Digital)

3ª) Jeanne: Todos os formulários a serem utilizados já seencontram no formato ideal neste documento daMetodologia? Ângela (20/08): Veja bem, os formulários sãoconsiderados suficientes para o uso do grupo que fará oacompanhamento da licitação, aquisição, desenvolvimentoe recebimento dos componentes. Eu disse suficiente. Vocêspodem (e devem ) e serão muito bem vindas, todas assugestões de melhorias.

Jeanne (21/08): Parece que já está tudo tão definido, seráque se utilizarmos outros formulários e procedimentos nãoiremos atrapalhar a dinâmica do processo já emandamento?

4ª) Jeanne: Vamos realizar todas as tarefas previstas nodocumento ou alguma já foi realizada?Ângela (20/08): Acho que não entendi.

Jeanne (21/08): Seguindo o documento da Metodologiaencontrei diversas tarefas a serem realizadas, desde aentrevista com o cliente até os testes finais doscomponentes. Em que nível iremos atuar? A entrevistacom o cliente já foi realizada tendo em vista que aespecificação de requisitos se encontra disponível. Os UseCase já foram feitos, a modelagem do banco também,então vamos entrar direto na implementação? É issomesmo?

5ª) Jeanne: Teremos um ambiente disponível para controledo cronograma (dotproject, por exemplo)?

Ângela (20/08): Vocês usaram este ambiente em algummódulo? Qual? Se necessário para o trabalho de vocês euprovidenciou o ambiente.

74

http://150.162.66.229/

Jeanne (21/08): Ângela, como está sendo controlado issono Via Digital? Lá tem um controle de tarefas, será que nãopoderíamos utilizar por lá mesmo? Quem pode liberarnossos acessos para que eu gere o cronograma deatividades? Se conseguirmos usar por lá, talvez não vamosprecisar do dotproject.

6ª) Jeanne: No anexo II - Tecnologia li a informação sobrea distribuição de um CD por parte do via digital com todosos SL necessários ao desenvolvimento, como podemos teracesso a ele?

Ângela (20/08): Não é necessário a utilização do CD.Todas as ferramentas estão disponíveis no site do ViaDigital.

Jeanne (21/08): Ângela, sinceramente, acho que estou como endereço errado do Via Digital. Encontrei apenas umGuia para execução de práticas que informa os links dasferramentas, é isso mesmo? Tem um link denominado"Como usar" mas não tem nada!

7ª) Jeanne: No documento Componente OOS do ViaDigital faz-se uma referência ao Mysql como SGBD, istovale apenas para este componente? O nosso permanececom Postgres, conforme Anexo II – Tecnologia?

Ângela (20/08): O componente de vocês deve seguir,rigorosamente, a tecnologia definida no edital e seusanexos.

Jeanne (21/08): Aproveitando a referência aosdocumentos, os obrigatórios para leitura e conhecimento doprojeto são: Metodologia de Desenvolvimento -(EasyProcess), Anexo I - Arquitetura, Anexo II -Tecnologia, Especificação de Requisitos do SICE e oComponente OOS do Via Digital? Mais algumadocumentação?Observação importante: o e_mail informado no Moodlepela Edvânia para contato com você é o e_mail doCENPRA, você respondeu neste do terra, qual devemosutilizar? Ângela, me desculpe se as perguntas são muito

básicas, mas temos dúvidas quanto à forma de trabalho emgeral, pois vamos trabalhar com equipes que já estão noprocesso que ainda não conhecemos. Por isso precisamosmuito da sua orientação. Ou iremos trabalhar à parte e onosso desenvolvimento será avaliado para integraçãoposterior? Se for assim, como iremos acompanhar aaplicação do EasyProcess? Aguardamos retorno urgente,pois segundo nosso cronograma, só temos setembro paraescrever o documento (que aliás é um artigo???, pensei queseria uma monografia?). Outra dúvida: qual será a data dopróximo encontro presencial? Será na primeira semana denovembro mesmo? Gostaria de agendar uma reunião viaskype com você e com o restante da equipe para sanarmosestas dúvidas todas e iniciarmos o trabalho...estamosaflitos...Obrigada pela atenção. Um abraço, Jeanne.

21/08/06 – Contato com Ângela sobre providências paranossa equipe

Prof. Ângela, bom dia!!! conforme conversamos ontem,seguem as providências sob sua responsabilidade em nossoapoio:

1. Contato com Wesley para solicitar seu apoio ànossa equipe;

2. Contato com Adler para solicitar transferência detecnologia e conhecimentos à nossa equipe(material de metodologia e processos);

3. Disponibilizar Edital Oficial do Projeto para anossa equipe;

4. Agilizar a volta do repositório do Projeto ViaDigital no ar para que possamos acessar;

5. Disponibilizar ambiente do dotproject paracontrole do cronograma e rede de tarefas.

Anexei também a ata que elaborei sobre a reunião deontem, pretendo utilizá-la como Anexo no meu TCC, seráválida? Poderia dar uma olhadinha por favor? Olhando oPMBOK, na parte que trata de Gerência de Comunicação

ela se encaixa, não? Vou gerar o esqueleto da minhamonografia e lhe passar para avaliação, hoje à noite. Muitoobrigada, viu? Abraços, Jeanne.

04/09/06 - Contato PMI do VIA DIGITAL – Adler Diniz Horário: 22:32 às 23:06

Jeanne diz: Boa noite Adler. Tudo bem? Sou da equipe doPSL, turma de 2005. A Ângela te falou que eu ia entrar emcontato com vc?

Adler diz: boa noite. sim..ela comentou comigo que opessoal do PSL entraria em contato..q vcs trabalhariamnum dos projetos do via digital..

Jeanne diz: Isso.

Adler diz:jeane..anote meu email.. eu to entrando numareuniào agora ( por mais estranho que pareca a essa hora danoite.. rsrsrs) [email protected]. amanha eu estareiausente o dia todo...me mande um email e vamosinteragindo via email..quarta estarei online..pode ser?podecontar comigo p/ o que precisarem, e na verdade eu tbprecisarei contar com vcs... rsrs

Jeanne diz:oi. Vou estourar meu cronograma...mas...podeser...Obrigada pela disponibilidade, vamos precisar do seuapoio sim. Apenas para adiantar...preciso dos padrões paraconstrução da interface gráfica, eles não constam nodocumento de Arqutetura - Anexo IV do Edital

Adler diz:a angela te passou os editais ? isso.. te passoagora..1 min

Jeanne diz:Se puder me enviar...Mas lá nãoconsta...Preciso das cores, fontes, etc. Não tem lá. Se puderme adiantar isso vai liberar o trabalho da minha equipeaqui, ok?

Adler diz:lá não tem?

Jeanne diz: Não. Só tem um print de um componentedesenvolvido, mas não especifica nada em relação apadrões

75


Adler diz: vou verificar com angela então..

Jeanne diz:Já pedi a ela. Porém não obtive retorno ainda

Adler diz: na verdade nosso papel é cuidar da gerência, nãodefiniremos padrões de interface..vamos tentar marcar umaaudio p/ quarta feira vc pode? ser p/ 18h??

Jeanne diz: posso. Não, tem que ser por volta das 19:30 oumais. Estou na estrada às 18h. Vc pode? Via skype? Ou poraqui mesmo?

Adler diz: pode ser..combinado..via skype...adlerdiniz

Jeanne diz: Combinado então, Obrigada.

Jeanne diz: Adler, tem um link no Anexo III Arquiteturaque deveria tratar isso, mas não sei o nome do projeto norepositório:http://repositorio.viadigital.org.br/projects/<NomeCurtoDoProjeto>. Poderia me dizer? Quem sabe não acho por lá.trecho do anexo: Detalhes sobre tipos de fontes, definiçãoprecisa de cores e dimensões das áreas estãodisponibilizadas às empresas licitantes através de aplicaçãoexemplo emhttp://repositorio.viadigital.org.br/projects/<NomeCurtoDoProjeto>.

Adler diz: Jeane...eu ainda não tenho esses detalhes...oseditais vão começar a ser divulgados agora...eu ainda nãotenho essas informações...

Jeanne diz: Estamos um tanto apavorados aqui por causado TCC

Adler diz: take easy... vamos resolvendo..

Jeanne diz: Amanhã vou entrar em contato com a Ângelanovamente e ver se ela sabe. Assim já adianto, é que nossoprazo é realmente muito curto.

Adler diz: sim..é curto mesmo... mas seria superinteressante que vcs começassem a seguir o processo quedefinimos..

Jeanne diz: o Easyprocess? Vamos seguir.

Adler diz: por isso mesmo que quero conversar contigoamanhã...não..

Jeanne diz: ai...não o que?

Adler diz: definimos outro processo... que usa algunsartefatos do Easyprocess.. mas não o Easyprocess... masfica calma..preciso verificar direitinho com a Ângela emqual processo vcs trabalharão..

Jeanne diz: Ai caramba... já doutrinei a equipe noEasyprocess porque a Ângela me disse que seria ele.Tomara que não mude muito o processo, porque está difícilsegurar o pessoal para não desenvolver sem seguir asetapas previstas.

Adler diz: sim mas isso é essencial..pense que esse projetodeverá ser implantado em outras prefeituras..e ele precisade documentação p/ isso...essa é a parte mais difícil doprojeto..convencer os desenvolvedores.. é umdesafio..rsrs...

Jeanne diz: estou preocupada...de verdade...Amanhã vcvai estar ausente, né? Aliás, estou atrapalhando a suareunião, me desculpa. É desespero de causa msm.

Adler diz: estarei ausente..estou no skype...

04/09/06 - Contato da Prof. Ângela com Sr. De Lucca sobre Guia de Estilos.

Oi DeLucca, enviei uma mensagem para você na sextafeira sobre esta questão.Tenho um pessoal de Lavras que está desenvolvendo ocomponente SICE seguindo criteriosamente o edital. Noanexo III, tem um item que cuida da especificação dastelas. Este item tem um link para o local onde estão estasespecificações. O Link não está preenchido com umendereço real. Você poderia verificar qual é esteendereço, por favor?

22/08/06 a 04/09/06 - Contato do Wesley e Prof. Ângela

sobre ambiente de gerência do projeto.

(22/08/06) - Prezado Weslei, boa tarde! conforme contatoda Profª. Ângela, estou entrando em contato para sabersobre a disponibilização do dotproject para a minha equipeutilizar durante o desenvolvimento do SICE para TCC daturma PSL105. A partir de quando o ambiente estarádisponível? Qual link, usuários e senhas de acesso?Aguardo retorno. Cordialmente, Jeanne PSL105.

(23/08/06) - Oi Jeanne. Bom dia. Eu já fiz a solicitação dodotProject para que vocês possam usá-lo. Será utilizado umdotProject do Via Digital mesmo. Assim que eu receber asinformações de acesso estarei disponibilizando para vocês.Atenciosamente, Weslei.

(23/08/06) - Muito obrigada Wesley. Estamos nosinteirando sobre as informações disponíveis do Via Digitalpara iniciarmos o planejamento das atividades. Agradeçoseu apoio e fico no aguardo das suas instruções.Cordialmente, Jeanne PSL105.

(27/08/06) – Weslei, já tem alguma informação para anossa equipe? Pretendemos iniciar o desenvolvimento naprimeira semana de setembro, portanto temos que planejartodas as tarefas no ambiente nesta semana que se iniciaamanhã, ok? Aguardo retorno breve. Obrigada pelaatenção.

(28/08/06) - Oi Jeanne. A informação que tenho é que odotProject será instalado no final desta semana que se iniciahoje. Qualquer informação mais nova que eu receber eurepasso a vocês. Quem está instalando é o pessoalresponsável pela infra-estrutura do Via Digital naUniversidade Federal de Santa Catarina. Atenciosamente,Weslei.

(28/08/06) - Wesley, não tem como adiantar esta tarefanão? A equipe vai iniciar o desenvolvimento na semanaque vem, vou precisar do ambiente para divulgar a eles ocronograma de atividades, e no final de semana vai ficarmuito em cima. Se for possível agilizar será ótimo.

76

http://repositorio.viadigital.org.br/projects/

Senão,darei um jeitinho aqui, ok? Obrigada pelo apoio.Jeanne. PS. Preciso saber qual a versão do CVS que aequipe vai usar para disponibilizar os componentes.

(28/08/06) - Estou enviando um email ao responsávelsolicitando um "adiantamento" na instalação e a versão doCVS... Assim que eu receber algo de volta teretorno...Atenciosamente, Weslei.

(28/08/06) - Muito obrigada de novo Weslei. Vou precisartambém da versão do dotproject. Abraços, Jeanne.

(31/08/06) – Contactei a Prof. Ângela via e_mail e disseque o ambiente para utilização do CVS e dotproject aindanão havia sido disponibilizado. Ela me perguntou se euhavia contactado o Wesley. Eu disse que sim, e que elehavia me dito que o pessoal só iria fazer isso neste próximofinal de semana. Pedi-a para cobrá-lo também para nosajudar pois havíamos elaborado um cronograma para operíodo de 1 a 15 de setembro, ficando os próximos 15 diaspara escrita do TCC. Se o ambiente não fosse organizadoem tempo hábil teríamos um atraso no cronograma.

(04/09/06) – Weslei: Oi Jeanne, o pessoal da administraçãodo Via Digital não irá disponibilizar o dotProject. Elessugeriram utilizar as ferramentas de gerência de projeto dopróprio GForge.... (No projeto dentro do Repositório doVia Digital é só ir na aba Tarefas... Por lá dá pra criartarefas, atribuí-las, gerar gráficos de Gantt, etc...) Quanto aversão do CVS é a v 1.12...

12 e 13/09/06 - Contato com a Prof. Ângela sobre acessoao Repositório do VIA DIGITAL.

(Jeanne) Prezados Prof. Ângela e Weslei, efetuei o cadastrodo nosso projeto no repositório do VIA DIGITAL no dia04/09 e recebi no ato do cadastro um e_mail solicitandoque eu aguardasse 72 para confirmação, porém até hojenada. Montamos um ambiente à parte para que as nossastarefas não ficassem pendentes em função destes impasses,mas gostaríamos de conhecer o ambiente e utilizar o CVSde lá. Será que vocês não poderiam nos dar uma força não?

Estou percebendo que a idéia de acompanharmos o pessoaldo VIA trabalhando não vai vingar... não conseguimos teracesso a nada! Aguardo uma posição pois tenho reuniãocom a minha equipe hoje e gostaria de levar pelo menosuma boa notícia a eles...Jeanne.

(Ângela) Prezados Wesley, Savi e Delucca, algumaprovidência já foi tomada com relação a questãocolocada pela Jeanne? Grata, Ângela.

(De Lucca) Prezados, as reclamações da Jeanne fazemsentido no que diz respeito ao prazo deresposta. O que posso dizer é que, após uma invasão aosite ocorrida nomês passado, estamos trabalhando para que não hajanenhuma (se forpossível) falha que venha a prejudicar o andamento dosprojetoshospedados no repositório após a entrada em produção.Todos os nossos esforços, neste momento, estão focadosnisto. Por outro lado, não tínhamos conhecimento deque haveria atividade (comoa inclusão de novos projetos neste período), o que fezcom que a equipenão estivesse atenta às requisições que chegaram nasemana passada, fatoagravado pelo recesso que houve aqui na UFSC (quintae sexta-feira). O prazo de 72 horas é importante paraavaliarmos as intenções do proponente do projeto edevemos interagir com o mesmo para verificar isso.Espero que a Jeanne reconsidere a afirmação de que"não vai vingar" e que nos ajude a que vingue! DeLucca.

(Administrador do repositório) Uma lista de correio serácriada em Repositório Via Digital de 6 a 24 horas e vocêserá o administrador da lista. Esta lista é: [email protected]. Asinformações de sua lista de correio estão em:http://listas.repositorio.viadigital.org.br/mailman/listinfo

/sice-psl105-commits. Os administradores de listapodem ser encontradosem:http://listas.repositorio.viadigital.org.br/mailman/admin/sice-psl105-commits . A senha de sua lista é:6a3cd5ab35def2ee.Você deveria alterá-la assim quepossível. -- a equipe do Repositório Via Digital.

(Administrador do repositório) O registro do seu projetopara o Repositório Via Digital foi aprovado. NomeCompleto do Projeto: SICE - Sistema de Controle deEstoques Nome-chave do Projeto: sice-psl105 ServidorCVS: cvs.sice-psl105.repositorio.viadigital.org.brServidor Web/Shell: sice-psl105.repositorio.viadigital.org.br. Seu DNS irá demorarem torno de um dia para ficar disponível em nosso site.Enquanto aguarda pela resolução do seu DNS, você podetentar acessar o shell em shell.repositorio.viadigital.org.bre apontar o CVS para cvs.repositorio.viadigital.org.br. Sedepois de 6 horas suas contas de shell/CVS continuarema não funcionar, por favorabra uma solicitação de suporte para que nós possamosdar uma olhada no problema.Por favor note que todas as contas de shell/CVS sãofechadas para telnet e funcionam apenas com SSH1.

Seu web site é acessível através da sua conta de shell. Porfavor leia a documentação do site (veja o link abaixo)sobre o uso desejado, serviços disponíveis, e layout dediretórios da conta. Se visitar suaprópria página de projeto no Repositório Via Digitalenquanto conectado, você irá encontrar funçõesadicionais no menu chamado 'Administração do Projeto'.Nós sugerimos que você visite agora o Repositório ViaDigital e crie (ou revise) uma descrição pública para oseu projeto. Isso pode ser feito visitando a páginado seu projeto enquanto logado, e selecionando'Administração do Projeto' a partir dos menusa sua esquerda (ou visitandohttp://repositorio.viadigital.org.br/project/admin/?

77

http://repositorio.viadigital.org.br/project/admin/?group_id=32

http://cvs.repositorio.viadigital.org.br/

http://shell.repositorio.viadigital.org.br/

http://sice-psl105.repositorio.viadigital.org.br/

http://sice-psl105.repositorio.viadigital.org.br/

http://cvs.sice-psl105.repositorio.viadigital.org.br/

http://listas.repositorio.viadigital.org.br/mailman/admin/sice-psl105-commits



http://listas.repositorio.viadigital.org.br/mailman/listinfo/sice-psl105-commits





group_id=32 depois do login).

Seu projeto também não irá aparecer na Árvore deSoftwares do Repositório (listaprincipal de projetos hospedados no Repositório ViaDigital que oferece grande flexibilidade para navegação epesquisa) até que você o categorize nas telas deadministração do projeto. Só assim as pessoas poderãoencontrar o seu projeto. Faça isso agora. Visite seuprojeto enquanto estiver conectado e selecione'Administrador do Projeto' nos menus. Aproveite paraconhecer o sistema e, por favor, informe outras pessoassobre o Repositório Via Digital. Deixe-nos saber se háalguma coisa que podemos fazer para ajudá-lo. -- aequipe do Repositório Via Digital.

(Jeanne) Sr. De Lucca, bom dia! Não quis ser negativaquando disse "que não ia vingar", principalmente porquenão disse em relação ao projeto como um todo, mas simem relação ao trabalho com a minha equipe em virtude doprazo que temos para a elaboração do TCC para a UFLA.Vou tentar lhe explicar os motivos da minha decepção emrápidas palavras para não lhe tomar muito tempo (apósleitura final descobri que ficou grande mesmo...medesculpe): No final de agosto eu havia entrado emcontato com o Weslei solicitando a disponibilização dodotproject para utilizarmos. Aguardei um bom tempo pelaresposta, cobrei dele novamente, então ele me informouque a equipe do VIA DIGITAL ia montar o ambientepara a minha equipe naquele final de semana (o primeirode setembro se não me engano). Ficamos aguardando,mas já em reunião interna, discutindo o Processo de

Desenvolvimento a ser utilizado, e realizando as tarefasiniciais (definição de papéis, planejamento dos releases eiterações, TAT, cronograma, instalação do dotproject (emcaso de não conseguirmos o do repositório).

Passado o final de semana, nada do Weslei e nada doambiente montado. Cobrei novamente e então recebi anotícia de que o ambiente não seria montado e quedeveríamos usar o Repositório próprio do projeto que jápossuía ferramentas para o que estávamos precisandofazer.... Cadastrei o Projeto no VIA, e o resto o Sr. já sabe.Em paralelo, tive contato com o PMI do VIA, que me disseque o processo a ser utilizado não era o que fomosorientado a usar (EasyProcess), mas sim uma derivaçãodele. Bem, estamos com o tempo contado, e fazer umaequipe aceitar as regras de um processo dedesenvolvimento já foi por si só tarefa complicada (pois opessoal quer é colocar a mão na massa a todo custo).Mesmo assim, agendei uma reunião com o Adler paraconhecer as mudanças e derivações que vocês vão utilizare...nada...ele não apareceu...

Sei que a organização de um projeto deste porte requertempo para montagem da infra-estrutura, disseminação deinformações e preparo de todo o "arsenal" para que tudofuncione da melhor maneira possível. Sei também quetodos os profissionais envolvidos devem estarsobrecarregados, o que é normal. Mas infelizmente fiqueicom a impressão de que não iríamos conseguir "fazerparte" deste todo, sobre o qual foi criada uma grandeexpectativa pela Profª Ângela na UFLA e sobre o qualgostaríamos de deixar a nossa contribuição. E para ajudar,

aliado a estes fatos, no meu ambiente de trabalho estouvivenciando a mesma situação em relação a participaçãoem um outro projeto de SL amplamente divulgado na mídiae que simplesmente "não deixa os desenvolvedoresexternos fazerem parte do time de colaboradores",simplesmente não conseguimos cooperar com eles demaneira nenhuma, e isso se somou ao que eu senti emrelação ao VIA. Bem, temos um prazo a cumprir e vamostentar nos adequar ao que foi solicitado da melhor maneiraque pudermos. Agradeço o auxílio que vocês puderem nosdispensar e também me coloco à disposição (acredito queos demais membros da minha equipe também), paracooperar com o projeto após o fim do nosso curso, que seráagora em novembro. Deixo aqui os meus votos de muitosucesso para a equipe do VIA DIGITAL, neste projeto degrande importância para o momento que o SL vive emnosso país. Um grande abraço, Jeanne Louize EmygdioAnalista de Sistemas Centro de Desenvolvimento ePesquisa Fac. Administração e Informática – SRS.

19/09/06 – Contato com o Weslei para acesso ao CVS

(Jeanne) Weslei, poderia me informar as senhas paraacesso ao CVS do Repositório do VIA DIGITAL? É umpouco urgente, ok? Obrigada, Jeanne.

(Weslei) Oi Jeanne, o usuário e senha para acessar o cvssão os que você utiliza para logar no site:http://repositorio.viadigital.org.br/. Caso tenha problemasno acesso, favor me contatar... Atenciosamente, Weslei.

(Jeanne) Obrigada Weslei, vou tentar lá, ok? Jeanne.

78

http://repositorio.viadigital.org.br/

http://repositorio.viadigital.org.br/

http://repositorio.viadigital.org.br/project/admin/?group_id=32

ANEXO B – Atas de reuniões

ATA DE 21/08/06

Horário início: 20h Horário término: 22h Local/meio: Skype

Participantes: Profª. Ângela Maria Alves, Jeanne L. Emygdio e Juliano O. GasparAssunto :Levantamento de informações gerais sobre o TCC e o componente SICE

do Via Digital, objeto de trabalho da equipe

RESUMO DA REUNIÃO

A troca de informações com a Profª Ângela foi orientada pelo último e_mail enviadopela Jeanne para resolução de diversas dúvidas, tendo também sido repassado a todos osintegrantes da equipe. As principais informações obtidas na reunião de ontem,organizadas por assunto seguem abaixo:

Sobre contato com o Gerente do Via Digital

A Profª. Ângela vai nos contactar com o PMI responsável pelo projeto ViaDigital para que possamos ter conhecimento de sua metodologia de trabalho com oobjetivo de transferência de tecnologia e conhecimentos. Ela deixou bem claro que nãoseremos obrigados a seguir toda a metodologia de trabalho do PMI, mesmo porque nãoteremos tempo hábil para isso, mas que este contato será enriquecedor para nossabagagem profissional.

No âmbito do nosso trabalho, poderemos escolher qual ferramentalmetodológico e técnico iremos utilizar e nomear gerente próprio para orientar nossasatividades.

Sobre andamento do Via Digital

Já existem componentes em desenvolvimento, e até mesmo outras equipespodem estar trabalhando no mesmo componente que escolhemos, o que não deverálimitar o nosso trabalho. O objetivo é disponibilizarmos ao final o nossodesenvolvimento para os futuros desenvolvedores terem ao seu dispor componentes aserem avaliados e escolhidos de acordo com a necessidade e qualidade de cada um.

Conforme a Profª Ângela, podemos trabalhar livremente, independente dequalquer trabalho que esteja sendo feito em paralelo, porém seguindo as documentaçõesoficiais do projeto, para não fugirmos do seu escopo.

Sobre o portal do Projeto e documentações

Conforme orientações da Profª. Ângela, todas as informações referentes aoprojeto devem ser encontradas no Edital do projeto (o qual ela irá nos remeter) e no sitewww.viadigital.org.br. Algumas informações disponíveis no moodle estãodesatualizadas. As dúvidas provenientes da leitura do Edital deverão ser resolvidas coma Ângela e apenas com ela.

79

http://www.viadigital.org.br/

Sobre o formulários e metodologiaPoderão ser utilizados outros além ou em substituição aos indicados, porém o

uso deverá ser justificado. Não seremos obrigados a utilizar toda a metodologia eprocessos definidos pelo PMI, conforme citação anterior.

Sobre as tarefas a serem realizadasNo Edital do Projeto Via Digital encontram-se a Especificação de Requisitos e

todos os casos de uso a serem implementados. Nossas atividades deverão partir diretopara a implementação. Devemos escolher poucos casos de uso apenas para realizarmoso processo do desenvolvimento, criticá-lo e termos base para a redação do TCC.

Sobre ambiente para controle de cronogramasNo site do Projeto Via Digital foi indicado o Xplanner, porém como já

conhecemos o dotproject, sugeria a Profª. Ângela que nos disponibilizasse o ambienteda UFLA que utilizamos na disciplina de Engenharia de Software 3 para montarmosnossa rede de tarefas. Ela nos disse que poderíamos inclusive fazer um comparativoentre as duas ferramentas no TCC. Cabe-nos escolher todo o ferramental para nossodesenvolvimento.

Sobre CD com as ferramentas

No site do Projeto Via Digital, link http://www.viadigital.org.br/index.php?option=com_content&task=view&id=20&Itemid=11 encontra-se listado todo oferramental indicado para o desenvolvimento e os respectivos links para download.Portanto não será necessário o uso do CD.

Sobre suporte metodológico e técnico à equipe

● Adler/PMI – irá nos explicar metodologia e processos empregados nodesenvolvimento do Via Digital

● Wesley/Suporte ao desenvolvimento – irá nos auxiliar em dúvidas técnicas sobreo desenvolvimento, ferramentas, ambiente, etc.

Ao final da reunião listamos algumas providências a serem tomadas pela Profª Ângelaem apoio ao nosso trabalho:

1. Contato com Wesley para solicitar seu apoio à nossa equipe;2. Contato com Adler para solicitar transferência de tecnologia e conhecimentos à

nossa equipe (material de metodologia e processos);3. Disponibilizar Edital Oficial do Projeto para a nossa equipe;4. Agilizar a volta do repositório do Projeto Via Digital no ar para que possamos

acessar;5. Disponibilizar ambiente do dotproject para controle do cronograma e rede de

tarefas.

O trabalho final a ser entregue como TCC é uma monografia, que deverá seguir asnormas disponíveis no moodle.

Santa Rita do Sapucaí, 22 de agosto de 2006.Jeanne Louize Emygdio / Gerente da equipe

80

http://www.viadigital.org.br/index.php?option=com_content&task=view&id=20&Itemid=11

http://www.viadigital.org.br/index.php?option=com_content&task=view&id=20&Itemid=11

ATA DE 22/08/06

Horário início: 20h Horário término: 22:40h Local/meio: Skype

Participantes : Jeanne Louize Emygdio, Juliano Ortigoso Gaspar e Roberto RochaAssunto : Troca de impressões sobre os documentos passados pela Ângela.

RESUMO DA REUNIÃO

Neste dia não conseguimos realizar uma reunião formal para discussão dosdocumentos em função da quantidade disponibilizada pela Ângela durante o dia por e-mail e da indisponibilidade da equipe para leitura destes materiais durante o período detrabalho. Apenas o Roberto Rocha havia conseguido ler o material. A Jeanne e o Julianofizeram a leitura e foram trocando impressões superficiais sobre o conteúdo dosdocumentos.

Listagem dos documentos repassados pela orientadora:

Documento Objetivo

Utilizando CVS.odt Tutorial para uso do CVS do Via Digital

CVS_Campina Grande.odt Discussão sobre uso do CVS do Via Digital

Revisão 04.07.06.zip Edital do projeto contendo os documentos:• Anexo I Projeto Básico ver 2.2• Anexo II Projeto Executivo 2.2• Anexo III Arquitetura ver 2.6• Anexo IV Tecnologia ver 2.5• Anexo V Avaliação Componentes ver 1.0• Anexo VI Minuta Contrato ver 2.3• Anexo VII Proposta Comercial ver 2.1• Anexo VIII Declarações • Anexo IX Aceite dos produtos ver 2.3• Carta Convite Componente ver 07

Recreio.zip (link para download)

Especificação de requisitos contendo:• Casos de Uso;• Diagramas de Caso de Uso• Documento de Requisitos• Matriz de rastreabilidade bidirecional• Workflows

Informações adicionais passadas pela orientadora

E_mail de contato com Weslei para dúvidas sobre ambiente do Via Digital:[email protected]. Link para download dos documentos de especificação:http://www.swfactory.com.br/Recreio.zip

Santa Rita do Sapucaí, 28 de agosto de 2006.Jeanne Louize Emygdio/Gerente da equipe

81

http://www.swfactory.com.br/Recreio.zip


ATA DE 29/08/06

Horário início: 19:15h Horário término: 23:50h Local/meio: SkypeParticipantes : Jeanne Louize Emygdio, Juliano Ortigoso Gaspar e Cláudio PozzebonAssunto : Dúvidas gerais sobre desenvolvimento da interface gráfica

RESUMO DA REUNIÃO

Motivações para a reuniãoDurante o dia, eu o Roberto e o Juliano conversamos via e_mail sobre a questão

levantada pelo Juliano em relação ao Cláudio preferir desenvolver as interfaces gráficasutilizando o Dreamweaver e por ser esta ferramenta do tipo proprietária o que fere apremissa inicial do projeto. Questionou ainda se o código gerado por ela seria 100%portável para IE e Firefox.

Concordei com ele e indiquei três ferramentas para testes pelo Cláudio: Amaya,NVU e Pspad. Informei ainda que o Amaya foi indicado pela equipe de webdesign daFAI (empresa onde trabalho) em virtude de comportar algumas regras dedesenvolvimento e validação da W3C que facilitam a portabilidade para IE e MozillaFirefox. Lancei o desafio ao Cláudio de implantar a ferramenta e usá-la durante odesenvolvimento pois ela poderia agregar mais valor ao projeto. Informei também osendereços dos sites para baixar as ferramentas:

● Home page do Amaya: http://www.w3.org/Amaya/ ● Home page do NVU: http://www.nvu.com/index.php● Home page do PSPad: http://www.pspad.com/

Juliano sugeriu ainda testes com o BlueFish e o Quanta+. O Roberto disse que oEclipse poderia também ser utilizado mas a geração do código deveria ser manualmente(sem uso de componentes visuais para auxiliar.

A reuniãoA reunião ocorrida via skype teve o acompanhamento meu e do Juliano (este por

voz) e o objetivo era auxiliar o Cláudio em suas dúvidas sobre o que discutimos duranteo dia e ouvir as suas razões para a escolha da ferramenta de desenvolvimento.

O primeiro ponto levantado por ele foi a inexistência de ferramentas emSoftware Livre no mesmo nível do Dreamweaver. Perguntei a ele se ele havia lido oretorno da equipe sobre o e_mail do Juliano. Ele disse que sim. Orientei-o a instalar asferramentas que levantamos e fazer uma análise crítica sobre o que será capaz de fazercom elas. Ele informou que a melhor das ferramentas citadas é o Quanta, e que nãogostaria de utilizar o Amaya.

Sobre a questão da portabilidade do código ficou preocupado em como testardurante o desenvolvimento, pois queria desenvolver utilizando apenas o ambienteWindows. Orientei-o a utilizar os padrões da W3C que favorecem a portabilidade daspáginas, e fiquei de trazer uma implementação que a minha equipe de trabalho usa na

82

http://www.pspad.com/

http://www.nvu.com/index.php

http://www.w3.org/Amaya/

FAI para portar o site para o Ópera, Firefox e IE. Informei-o de que na página da W3Chá links para validação dos padrões utilizados no portal que construímos. Caso existamerros de padrão ele acusa e não libera a utilização do selo de qualidade. Ele me passoudois artigos informando sobre o IE e a sua falta de padrões. Me disse que existe umaextensão para o Firefox que valida os padrões da W3C e que ele ganha muito tempocom isso.

Ele reafirmou que não queria utilizar ambiente Linux para o desenvolvimentoem virtude do pouco tempo que dispúnhamos para a implementação e a redação doTCC. Relembrei-o de que a proposta é desenvolvermos tudo em SL, até mesmo paracomprovar a viabilidade de um desenvolvimento de qualidade usando SL. Perguntei sehavia problema em relação à montagem do ambiente e ele novamente levantou aquestão de como testar a portabilidade. Combinei com ele que eu me encarregava destestestes no IE enquanto ele desenvolvia no Linux.

Levantou a necessidade de um guia de estilo para o desenvolvimento daspáginas. Verificamos no documento Anexo III – Arquiteturas e detectamos um linkquebrado que deveria direcionar para o Guia de estilos que precisávamos. Fiquei deentrar em contato com a Ângela para conseguirmos o documento e retornar a ele o maisrápido possível.

Portanto as decisões tomadas foram:1. Cláudio deveria utilizar apenas Software Livre;2. Deveria instalar as ferramentas sugeridas pela equipe, testá-las e avaliar de

forma crítica o que seria capaz de fazer com cada uma delas para ter condiçõesde optar pela que pudesse dar melhor resultado;

3. Jeanne faria os testes de portabilidade no navegador Internet Explorer para que oCláudio não saísse do ambiente livre de desenvolvimento.

4. Jeanne deveria procurar a Ângela e obter o Guia de Estilos para o projeto.

Santa Rita do Sapucaí, 29 de agosto de 2006.

Jeanne Louize EmygdioGerente da equipe

83

ATA DE 13/09/06

Tempo previsto: 1:30h Horário início: 21:02h Horário término: 00:16h Local/meio: SkypeParticipantes : Jeanne Louize Emygdio, Juliano Ortigoso Gaspar e Cláudio Luiz Pozzebon Assunto : Reunião de acompanhamento – final I1

Objetivos : Avaliar sistematicamente os resultados obtidos (produção e situações vivenciadas no período)

Gerar artefatos : BIG CHART, TAT, Análise de riscoAvaliar : necessidade de refatoramento de código, uso do wiki, dotproject e metodologia

Relato de realizações do Juliano

Realizações: 1) Montagem do ambiente de desenvolvimento (Java Development Kit, Eclipse, Java, Hibernate); 2) Elaborou Modelo de Entidade eRelacionamento na ferramenta DIA; 3) Elaborou Diagrama de Classes (análise) na ferramenta DBDesigner; 4) Gerou script paracriação do banco no Postgresql utilizando a ferramenta DBDesigner2pg; 5) Executou o script criando o banco e as tabelas físicasutilizando a ferramenta PGAdmin; 6) Modelou Diagrama de Classes (projeto) para projetar as VOs e DAOs selecionadas utilizando aferramenta ARGOUML; 7) Criação das VOs (com atributos e métodos previstos no Diagrama de classe (projeto)); 8) Criou DAOspara inclusão, alteração, exclusão e consulta; 9) Criou classes para testes unitários de inclusão e reaproveitou o código para alteração,exclusão e consultas); 10) Aplicou testes unitários baseados em sua experiência prática (tentou alterar dados que não existiam, tentouinserir sem preenchimento de campos obrigatórios e tentou quebrar chave primária)

Problemas: Diversos travamentos no DIA, problemas na atualização de status de componentes do ARGO quando alterna entre diagramas;detectou conflito entre o IPTABLES instalado em sua máquina e o Postgresql, além de problemas na configuração do Postgresql.

Análise da gerência:1. A organização do ambiente de desenvolvimento ocorreu após o término do prazo previsto (31/08/06);2. Construiu artefatos que não faziam parte desta iteração (prevemos apenas inclusão);3. Não fez plano de testes unitários. Os testes aplicados foram baseados em sua experiência prática (poderia ter usado os Use Cases para gerar);4. Postou resultados no Wiki;5. Consultou documentação durante o desenvolvimento;6. Utilizou apenas ferramentas livres para o desenvolvimento.

Solicitações da gerência:1. Elaborar os planos de testes, tanto para realizarmos a tarefa como para assimilarmos a necessidade do planejamento antes do desenvolvimento.

84

Relato de realizações do Cláudio

Realizações: 1) Desenvolveu as interfaces gráficas para RF09 e RF13 utilizando XHTML, CSS (para definição do layout da camada deapresentação) e Javascript (para fazer validação dos formulários); 2) Validou o que construiu de acordo com as premissas doArcabouço Arquitetural considerando também a compatibilidade com os navegadores indicados; 3) Passou os artefatos gerados para oRoberto validar e integrar.

Problemas: Problemas na escolha das ferramentas, problemas com o ambiente (eclipse não funcionou).

Análise da gerência:1. Ainda se encontrava com problemas no ambiente de desenvolvimento após o término do prazo previsto (31/08/06);2. Desenvolveu artefatos que não faziam parte da iteração;3. Seguiu Arcabouço Arquitetural para validar as páginas que construiu;4. Não seguiu o cronograma e não fez log no dotproject;5. Aplicou CSS e validação Javascript nas páginas que criou;6. Passou os artefatos para o Roberto integrar e validar antes da minha validação (não seguiu o planejamento);7. Utilizou apenas ferramentas livres para o desenvolvimento.

Solicitações da gerência:1. Ficar atento às ferramentas de comunicação para não ignorar o processo na próxima iteração.

Relato de realizações do Roberto

Realizações: 1) Configuração do ambiente de desenvolvimento (instalação e configuração do Java SDK, Eclipse e Postgresql; 2) Gerou um projetono Webwork para teste da ferramenta com Tomcat; 3) Integrou os artefatos desenvolvidos pelo Juliano e Cláudio; 4) Realizou testesapós a integração

Problemas: Problemas na escolha e instalação do SO, problemas com a conexão web; problemas com pacotes desatualizados na distribuição doSO além de falhas em sua configuração; dificuldade na integração das actions porque exigiu estudo do webwork para entender comofunciona o processo de criação de actions nele.

Análise da gerência:1. Ainda se encontrava com problemas no ambiente de desenvolvimento após o término do prazo previsto (31/08/06);2. Consultou documento de requisitos antes da implementação;3. Não seguiu o cronograma e não fez log no dotproject (no momento da reunião detectou que tinha que fazer os casos de testes);4. Realizou tarefas que não foram planejadas (projeto básico no webwork);5. Utilizou apenas ferramentas livres para o desenvolvimento.

85

Solicitações da gerência:

1. Ficar atento às ferramentas de comunicação para não ignorar o processo na próxima iteração;2. Elaborar os planos de testes, tanto para realizarmos a tarefa como para assimilarmos a necessidade do planejamento antes do desenvolvimento.

Relato de realizações da Jeanne

Realizações: 1) Diversos contatos com a Prof. Ângela e Weslei para tentar resolver os problemas de acesso ao VIA DIGITAL e localizar o Guia deEstilos; 2) Organização do cronograma no dotproject disponibilizado pelo Cláudio; 3) Publicação de informações no Wiki; 4) Contatocom PMI para alinhamento quanto ao processo; 5) Acompanhamento via skype e e_mail do andamento das atividades e tentativas deauxiliar na resolução de problemas dos desenvolvedores; 6) Planejamento da reunião de acompanhamento para fechamento daprimeira iteração; 7) Registro do projeto no Gforge e contatos com a equipe para aceitação do registro; 8) Organização do cronogramano Repositório do VIA DIGITAL; 9) Presidi a reunião de acompanhamento para fechamento da iteração.

Problemas: Não previ no cronograma um período para as atividades da gerência e foi difícil disponibilizar informações para a equipe e ao mesmotempo estar com eles para tentar ajudar nos problemas, buscar soluções com a equipe externa e ainda manter a comunicaçãofuncionando sem parar (controlando para não gerar informações em excesso para a equipe). Não elaborei os planos de testes deaceitação porque simplesmente não deu tempo.

Análise da gerência:1. Não previ no cronograma tempo para realização das tarefas da gerência;2. Não elaborei o Plano de testes de aceitação;3. Não apliquei os Testes de aceitação;4. Não acompanhei a utilização do dotproject para evitar os problemas que detectei com os desenvolvedores.

Pendências detectadas:● Plano de testes das classes de aplicação;● Teste unitários das classes de banco;● Validação da interface;● Construção do Plano de testes de aceitação;● Aplicação dos Testes de aceitação.

Solicitações da gerência:1. Pedi que todos listassem os conhecimentos adquiridos durante o projeto para construir a matriz da evolução da equipe, só que para isso

precisaria de mais de uma iteração para detectar aquisição de maturidade no processo por parte de todos.

86

Informações passadas à equipe:

1. Registro do projeto no Repositório do VIA foi aprovado, novo cronograma já organizado lá. A equipe pode acessar e logar o que fez;2. Guia de Estilos não foi encontrado. Acho que ainda não foi feito mesmo;

Riscos detectados:

1. Para seguirmos o processo como deve ser e contando os atrasos e os problemas não será possível fechar até o dia 17. Sugeri para o TCCconsiderarmos o primeiro prazo até 17/09 pois seria uma experiência real para contarmos. Tentamos fazer o máximo e depois estendemos oprazo. Temos todos que correr até o dia 17. Isso pq eles acabaram fazendo os dois requisitos na mesma iteração.

Informações adicionais:

1. Combinei com o Cláudio que ele me mandaria as telas para validação no dia seguinte;2. Roberto me pediu modelos de planos de testes, fiquei de passar os do SICAA também no dia seguinte;3. Comentei que os furos no processo são normais no início da implantação até que todos estejam inteirados do assunto, mas que saber que todos

consultaram a documentação durante o desenvolvimento já foi um ganho, isso além do comprometimento de cada um e o interesse em conhecero processo, entender onde errou e se propor a acertar da próxima vez.

Santa Rita do Sapucaí, 30 de outubro de 2007.

Jeanne Louize Emygdio

Gerente da equipe

87

ANEXO C – Ferramental previsto x utilizado no desenvolvimento do SICE

Camada Tecnologia sugerida Finalidade Tecnologia utilizada

Apresentação Html 4.1 ou XHTML 1.1 linguagem para formatação e apresentação das informações aos usuários. XHTML 1.1

--- Editor de HTML auxilia na produção de código HTML. Quanta Plus 3.5 (comsuporte à CSS).

Javascript 1.5 linguagem de programação utilizada, principalmente, para validação de formulários web. Javascript 1.5

JavaServerPages (JSP) J2EE1.4

A tecnologia JSP fornece um meio simples de criação de conteúdo dinâmico em páginas web.

J2EE - Especificação da SUN que provê WebServices, gerenciamento de modelo de componentes eAPI´s de comunicação.

JavaServerPages (JSP)J2EE 1.4

Navegadores IE 5+ e Mozilla Firefox 1.3+

Ferramentas para navegação na web. Navegadores IE 6 eMozilla Firefox 1.5 eKonqueror 3.5

Aplicação Java (J2SE JDK) 5+ (SUN) Linguagem de programação. J2SE JDK 1.5

Struts 1.1 + Framework para implementação do padrão MVC WebWork 2.2.4

Apache Tomcat 5 + (obrigatório)

Servidor de aplicações. Apache Tomcat 5.5.15

Dados Hibernate 3+ Framework para persistência de objetos Java em bancos de dados relacionais. Hibernate 3.1.3

PostGresql +8 (obrigatório) Sistema de Banco de Dados Relacional. PostgreSql 8.1.2-1

88

ANEXO D – Ferramental de apoio ao desenvolvimento do SICE

Tecnologia sugerida Descrição Tecnologia utilizada

Apache Ant 1.6+ Ferramenta de apoio aos processos de distribuição e empacotamento de aplicações. Apache Ant 1.6.5

--- IDE de desenvolvimento. Eclipse 3.1.2

Ferramenta para planejamento e acompanhamento das tarefas do projeto DotProject 2.0.4

CVS do Via Digital Ferramenta de controle de versão dos arquivos criados, utilizados, modificados no projeto. CVS 1.12TortoiseSvn 1.3.2

--- Ferramenta de banco de dados para explorar, gerenciar, executar queries e visualizar informações, dobanco de dados.

PgAdmin 1.2.2

Ferramenta CASE para elaboração de Diagramas (MER) DIA 0.95

--- Ferramentas Case para elaboração de diagramas UML Dbdesigner 4.0.5.4 e ArgoUML0.22

Ferramenta para geração de scripts de criação das tabelas para PortgreSql DBDesigner2pg

--- Ferramentas de comunicação remota. Skype 2.5 e MSN 7.0

--- Editor de textos Open Office 2.0, BrOffice2.0

Ferramenta de edição colaborativa para disseminação de informações via site PmWiki 2.1.26Site do Via Digital

89

ANEXO E – Easyprocess em síntese

Atividade Ocorrência no projeto

Definição de papéis Jeanne Louize Emygdio

Claudio

Roberto Rocha

Juliano

Gerência do projeto e testes

Camada de Apresentação

Camada de Aplicação e Integração

Camada de Dados

Conversa com o cliente Esta tarefa foi realizada entre a contratante, da parte do Via Digital e oPMI. Nossa equipe teve acesso a Edital de contratação dos serviços,Proposta Comercial, Minuta do Contrato, Declarações, Carta convitecomponente e aceite dos produtos.

Inicialização Esta tarefa foi realizada pela equipe de desenvolvimento gerenciada peloPMI contratado. Nossa equipe recebeu via orientadora os documentosProjeto Básico, Projeto Executivo, Arquitetura, Tecnologias, Avaliação deComponentes e a Especificação de Requisitos contemplando Use Stories.Sob nossa responsabilidade ficou a definição do modelo lógico dos dados.

Planejamento de releases(Tempo previsto: 2 horas)

(Exemplo à pág. 44 -tabela)

Tempo previsto para cadarelease: 1 mês contendo 2

iterações (orientaçãoEasyprocess – pág.29)

Tarefas a serem realizadas:1. Definição do período completo do desenvolvimento2. Definir o número de releases e iterações necessárias3. Alocar User Stories para cada release4. Planejamento do release5. Dividir as User Stories do release em tarefas;6. Alocar as tarefas nas iterações deste release;7. Planejamento de Iteração;8. Especificação dos testes de aceitação das User Stories com o

cliente (plano de testes);9. Especificação do tempo de desenvolvimento e o tempo de cada

tarefa.

Planejamento de iteração(Exemplo à pág. 45 –

tabela)

1. Construção do TAT – Tabela de alocação de tarefas2. Especificação dos testes de aceitação

Implementação Considerações importantes:• Propriedade coletiva de código;• Padrões de codificação;• Releases pequenos;• Integração contínua;• Programação em pares (analisar escopo, tempo e habilidades)

Reuniões deacompanhamento

Semanalmente comparticipação de toda a

equipe (orientaçãoEasyProcess – pág. 34)

Coordenação do gerente:1. Análise dos resultados obtidos;2. Construção do Big Chart;3. TAT – Tabela de alocação de tarefas4. Análise de risco5. Identificação de mudanças6. Levantamento da necessidade de refatoramento de código.

Fim da iteração comverificação dos testes de

aceitação

Devem ser considerados:1. Testes de unidade: devem ser escritos antes da construção do

código;

90

Atividade Ocorrência no projeto

2. Revisão de código: cada testador revisa o código gerado por outromembro da equipe (propriedade coletiva de código)

3. Testes de aceitação: cenários que devem ser suportados pelosoftware.

Uma User Story só é considerada implementada quando for submetida atodas as baterias de testes, passando com sucesso.

Sugestão: leitura dos exemplos de aplicação do Processo de Desenvolvimento a partir da página 39 dodocumento “Metodologia de Desenvolvimento”. Leitura do Anexo II “Projeto Executivo” paraconhecimento da solicitação do cliente em relação ao Processo de Desenvolvimento.

ANEXO F – Plano de comunicação para o SICE

Visando facilitar a disseminação de informações importantes do projeto para anossa equipe e desta forma proporcionar instrumentos de apoio durante odesenvolvimento decidi elaborar um plano de comunicações que, por ser uma atividadeda gerência de comunicação, necessita da formalização do uso de algumas ferramentas ede sua finalidade dentro do projeto conforme a tabela abaixo:

91

Ferramenta Objetivos no projeto

Wiki colaborativo Repositório das informações necessárias para o bom andamentodo projeto. Endereço: http://www.eiqconsultoria.com.br/psl-tcc/

Gerenciador de e_mail meio de comunicação diária que deverá ser utilizado para:• troca das últimas orientações recebidas do orientador do

projeto ou equipe de suporte técnico do Via Digital;• contato com o orientador do projeto em nível acadêmico;• orientações do gerente do projeto; agendamento de

reuniões; divulgação de atualização de informações norepositório;

• adiantamento de assuntos e/ou problemas a seremtratados nas reuniões noturnas.

Skype

Ferramenta para comunicação remota. Será utilizada para:• realização das reuniões da equipe;• resolução de dúvidas durante o andamento do projeto; • auxílio na redação das atas das reuniões.

Atas das reuniões Documento formal para registro dos principais tópicos tratadosnas reuniões da equipe.

Documento de decisões de projeto

Síntese formal das decisões a serem respeitadas durante odesenvolvimento do projeto.

O plano foi elaborado de forma enxuta para evitar a geração excessiva deinformações e prejudicar o andamento do projeto.

Segue abaixo uma relação dos meios de contato entre a nossa equipe:

Contatos da equipe E_mail MSN Skype

Cláudio Luiz Pozzebon [email protected] [email protected] claudiopozzebon

Jeanne Louize Emygdio [email protected] [email protected] jeanne_mg

Juliano Ortigoso Gaspar [email protected] [email protected] julianogaspar

Roberto Ribeiro Rocha [email protected] [email protected] roberto_rrocha

92

http://www.eiqconsultoria.com.br/psl-tcc/

ANEXO G – Análise de riscos para o SICE

Risco Prioridade Responsável Solução

Volume de informações Alta Jeanne Elaboração de um plano de comunicação para a equipe, explicação a todos como tudo deveria funcionar.Juntamente com o Cláudio organizei um Wiki para o SICE visando concentrar todas as informações emum único local de fácil acesso da equipe.

Falta de domínio e experiência no Easyprocess.

Alta Jeanne Estudo, elaboração de uma síntese do processo para a equipe e reunião para explicação e nivelamento.

Falta de domínio do ferramental

Alta Todos Manter a premissa de desenvolver utilizando apenas SL até o limite, quando não for possível aguardarmais deve-se utilizar uma solução proprietária e registrar uma justificativa plausível.

Falta de domínio nos padrões propostos

Alta Roberto Sugeri ao Roberto que se reunisse com a equipe de desenvolvedores antes do período de implementaçãopara discutirem juntos todos os padrões que deveriam ser utilizados. A TAT foi elaborada em conjuntopara que todos discutissem cada tarefa que deveria ser realizada, o porque e em qual ordem (seguindoMVC). Foi uma ótima troca de conhecimentos.

Atraso na disponibilizaçãode acesso à equipe aosambiente do VIA DIGITAL

Alta Ângela Disponibilização do cronograma inicial no Wiki do SICE. Posteriormente o Cláudio instalou o dotprojectno mesmo servidor do Wiki e o cronograma foi refeito para acompanhamento e registro de log de toda aequipe. Decidi que independente da data de liberação do ambiente do VIA DIGITAL e mesmo que aequipe não acompanhasse o uso deste ambiente eu faria testes para aquisição de conhecimentos.

Dificuldade em implantar o processo com a equipe

Alta Jeanne Acompanhamento constante sobre o andamento das atividades de acordo com o cronograma estabelecido.Devo estar presente o máximo de período possível para contato com a equipe.

Disponibilidade da equipe para o trabalho, alocação geográfica, acesso à internet

Alta Todos Todos os membros da equipe deveria tentar manter contato os demais pelo menos através de e_mail (oulogs no dotproject), comunicando problemas, atrasos, fim de tarefas, etc. Avisar com antecedência asnecessidades de ausências.

Tempo para redação do TCC

Média Todos Reduzimos o número de requisitos a serem implementados de forma a executar o processo pelo menos 2vezes.

Assimilação de conhecimentos

Alta Todos Leitura de todo o material publicado no Wiki e contato constante com a equipe.

93

ANEXO H – Atividades da gerência em detalhes.

Data Tempogasto

Tipo Atividades

17/04/06 2:19 TCC 21:18 às 23:37 – Contato inicial com a Ângela sobre as possibilidades para o meu TCC. Passei meu relatório das atividades da gerência doSICAA para ela analisar se haveria nele conteúdo suficiente para o TCC. Um idéia da Ângela foi que eu avaliasse a metodologia utilizada parao Via e fizesse o TCC sobre esta experiência inclusive participando das reuniões com a equipe do VIA DIGITAL, através do Skype.21:46 às 23:00 - Contato com Roberto Rocha sobre as possibilidades para o TCC discutidas em paralelo com a Ângela. //Origem: logs do skype

24/04/06 0:07 TCC Contato com a Ângela para saber o resultado da sua avaliação sobre os documentos que enviei em 17/04. //Origem: logs do skype

04/07/06 0:04 TCC 12:21 às 12:25 - Contato com a Ângela para saber o resultado da sua avaliação sobre os documentos que enviei em 17/04. Ela me informouque deles realmente dava para retirarmos um TCC, mas queria reler e agendar outro dia para me passar suas sugestões. Me pediu para cobrá-lasobre este assunto. //Origem: logs do skype

05/07/06 4:15 TCC 14:41 às 18:22 - Contato com Roberto Rocha via Skype: conversamos sobre as definições do TCC. Ele me disse que havia conversado com oMarvin e o Cláudio e que eles haviam concordado em desenvolverem para o VIA DIGITAL. Me convidou para fazer parte da equipe edesenvolver algo relacionado à documentação, testes ou gerência se me interessasse. Eu disse a ele que estava em paralelo tentando conversarcom a Ângela e que a idéia dele me interessava muito. Disse que tentaria unir a minha idéia inicial (e discutida com a Ângela) à proposta dele.Conversei em paralelo com a Ângela e discutimos esta nova possibilidade. Ela aprovou na hora.O Roberto me disse que pretendiam iniciar o desenvolvimento em julho, que iria testar o CVS e criar um projeto inicial . Me comprometi apedir à Ângela que liberasse novamente o dotproject para uso da equipe. O Roberto me disse que eu deveria ver primeiro se o VIA DIGITAL jánão possuía um ambiente similar ao do dotproject pois poderíamos usá-lo ao invés de termos que registrar nossas tarefas em ambiente distintodo VIA. Discutirmos o documento de pré-projeto e trocamos documentos para fecharmos a idéia do TCC.14:44 – Cobrei da Ângela via Skype o retorno que ela me solicitou em 05/07. Não obtive resposta.18:56 – Postei o pré-projeto no moodle e informei-a sobre isso para que ela analisasse a proposta que enviei. //Origem: logs do skype

12/07/06 0:15 Comunicação Roberto informou que contactou o Juliano para cuidar da parte do Banco de Dados e ele aceitou. //Origem: e_mails

17/08/06 1:51 Familiarizaçãocom o projeto

e com oprocesso de

desenvolvimento

20:59 às 21:35 –Elaboração de e_mail para a Ângela (com cópia para a equipe) solicitando diversas informações sobre o SICE. Solicitei apoioa ela via Skype para retirarmos dúvidas sobre o projeto. O conteúdo do e_mail e os retornos recebidos encontram-se registrados no documentoENTRV_SICE.odt, e servirão ao projeto como registro de entrevistas com o o cliente.22:32 às 22:50 - Contato com o Cláudio via e_mail para troca de informações sobre os documentos do VIA DIGITAL para iniciarmos asatividades em equipe. Enviei os arquivos Metodologia de desenvolvimento.pdf, Anexo_1_-_Arquitetura.doc, Anexo_2_-_Tecnologia.doc eFLOPREF-SICE-Documento Requisitos_02.doc. Pedi a ele que lesse os documentos para começar a se familiarizar com o projeto e que meinformasse sua disponibilidade para o projeto. //Origem: logs do skype, entrevistas com o cliente e e_mails


Enquanto aguardava retorno da Ângela, enviei e_mail à equipe repassando materiais de leitura obrigatória para nivelarmos o conhecimentosobre o trabalho a ser feito. Solicitei a cada um a disponibilidade semanal para o projeto visando formalizar o cronograma de atividades.

94

Data Tempogasto

Tipo Atividades

e com oprocesso de

desenvolvimento

Documentos enviados: Metodologia de desenvolvimento .pdf; Anexo 1 – Arquitetura.doc; Anexo 2 – Tecnologia.doc; FLOPREF – SICE –Documento de requisitos – versão 2.doc. //Origem: e_mails


e com oprocesso de

desenvolvimento

Recebimento de e_mail de resposta da Ângela em relação ao e_mail que enviei em 17/08. O conteúdo do e_mail e os retornos recebidosencontram-se registrados no documento ENTREV_SICE.odt. Houve acompanhamento da equipe. //Origem: entrevistas com o cliente


e TCC.

Envio de outro email para a Ângela em resposta ao que ela solicitou em 20/08. Solicitei encontro via Skype para o período da noite (20h) paraagilizarmos a compreensão sobre o projeto e o TCC. Informei a equipe sobre este agendamento e solicitei a todos que comparecessem.Em contato com a equipe durante o dia sobre as questões levantadas fiquei sabendo através do Juliano que no último encontro presencial aÂngela informou que o desenvolvimento não partiria do zero, já que havia outras equipes desenvolvendo os mesmo componentes e quepoderíamos ter conflitos para integração no ambiente do VIA DIGITAL. Sinalizou ainda que o ambiente lá parecia abandonado (eu e oRoberto concordamos). Juliano espera que possamos desenvolver do zero para não somarmos às dificuldades que já detectamos a de ter quecompreender código alheio.20:00 às 22:00 – Reunião com Juliano e Ângela via Skype para levantamento de informações gerais sobre o TCC e sobre o componente SICE,objeto de estudo da equipe. Foi elaborada uma ata com todos os tópicos discutidos.22:03 às 22:52 – Contato com Roberto Rocha sobre a reunião. Ele tentou participar mas teve problemas com o Skype.Recebi e_mail do Cláudio informando sua disponibilidade diária para o projeto, mas que estava com muitos projetos profissionais emandamento e que haveria dias em que não seria possível atuar no SICE.Enviei e_mail para a Ângela com as providências que ela deveria tomar (conforme ata respectiva) para nos auxiliar. //Origem: ATA210806

22/08/06 1:00 Familiarizaçãocom o Projetoe Ambiente

Recebi e_mail da Ângela informando e_mail do Wesley para contactarmos em caso de dúvidas e/ou problemas no ambiente dedesenvolvimento tanto no VIA DIGITAL quanto no dotproject na UFSC (ele ficou com a responsabilidade de criar uma área para nós por lá).Pediu que eu repassasse à equipe o que fiz prontamente. Solicitei a ela envio do Edital atualizado para utilizarmos em reunião à noite (toda aequipe). Elaborei a ata da reunião de 21/08/06 e passei e_mail à equipe para revisão antes de publicação no Wiki do projeto. Juliano sugeriu pequenasalterações via e_mail.Recebi da Ângela, via e_mail :

● um tutorial para acesso ao CVS além de informações importantes para acesso ao CVS de Campina Grande. Elaborei um documentopara o Cláudio postar no Wiki do projeto.

● diversos documentos para estudo pela equipe (ver relação na ata do dia). Repassei tudo à equipe.21:13 às 21:22 - Contato com o Juliano sobre o andamento do estudo sobre a documentação passada pela Ângela. //Origem: ATA220806

95

Data Tempogasto

Tipo Atividades

23/08/06 2:50 Familiarizaçãocom o Projeto.

Contato via e_mail durante o dia para agendarmos reunião da noite.20:00 às 22:40 - Reunião via Skype entre Juliano, Roberto e eu sobre os documentos passados pela Ângela. Impressões registradas na ata destadata. //Origem: ATA230806

24/08/06 4:28 Familiarizaçãocom o Projetoe Tecnologias

00:25 às 01:21 – Contato com o Cláudio via e_mail discutindo tecnologias selecionadas.10:18 às 11:00– Contato via e_mail com Roberto e Juliano discutindo sobre tecnologias selecionadas.20:14 às 2026 – Roberto via skype informou que não iria participar da reunião por que ainda estava no serviço.21:00 às 23:14 - Contato com Juliano via Skype:

● Informei que não tive tempo de elaborar a ata da reunião do dia 23 acrescentando as discussões do dia 24. Disse que pretendia conferiros itens de tecnologia previstos e o que definimos para não ficar nada para trás.

● Juliano informou que estava lendo a especificação de requisitos e que estava gostando muito do nível do documento. Disse tambémque havia baixado o hibernate e estava lendo o tutorial para entendê-o e fazê-lo funcionar em sua máquina.

● Fizemos uma conferência sobre as tecnologias, montei uma tabela e fomos conferindo item por item via Skype, organizadas porcamada da aplicação. Eu dizia ao Juliano as ferramentas sugeridas e versão e ele orientava dentro das que conhecia, qual poderíamosutilizar e quais as versões. Tivemos dúvidas em várias tecnologias porque não possuíamos conhecimento prático sobre elas, entãoresolvemos levantar o que fosse possível e depois conferir com o Roberto Rocha.

● Premissa sinalizada: A apresentação das informações nas páginas deve utilizar a biblioteca de tags oferecida pelo framework Struts,evitando, ao máximo, a presença de código Java em páginas JSP. Pendente conferência com o Roberto.

● Em virtude das minhas dúvidas sobre as tecnologias e para que cada uma servia o Juliano me deu uma aula de padrão MVC e dasrespectivas ferramentas aplicadas em cada camada.

23:28 às 23:52 - Contato com Cláudio via Skype, ele me disse que estava com diversos problemas no seu PC e mal conseguimos conversar. Elaborei um documento com as tecnologias e enviei para a equipe por e_mail solicitando que todos conferissem para que eu pudesse gerar a atada reunião deste dia. Informei que precisaria de tempo para ler com calma o material enviado pela Ângela e sugeri que nos reuníssemos nosábado (26/08). //Origem: e_mails e logs do skype

25/08/06 0:30 Tecnologias 9:32 às 11:31 / 14:23 às 16:15 - Troca de e_mails com a equipe discutindo tecnologias. //Origem: e_mails

27/08/06 6:00 Processo 2h - Elaborei um documento de resumo da metodologia a ser adotada no desenvolvimento e enviei à equipe para leitura e discussão. Informeia eles sobre o tema do meu TCC e que precisaria da ajuda de todos para a execução do processo de forma que ao final do nosso trabalho eutivesse conteúdo para redigir meu trabalho. //Origem: Easyprocess em síntese4h – Reunião para nivelamento sobre o processo.

28/08/06 2:42 Validação deBD e

Planejamento

Juliano enviou via e_mail com os documentos SICE_2_ScriptBD.txt (script do banco) e a imagem sice2.png com a modelagem do banco paraque eu validasse. Informou que havia modelado usando o DBDesigner e que havia tentado usar um script linux (dbdesigner2pg) que convertia oscript gerado pelo dbdesigner para utilizar diretamente no PostgreSQL. Porém, não conseguiu rodá-lo (alega não ter encontrado o xsltproc).Gastou meia hora na atividade (contando com a tentativa frustrada de usar o dbdesigner2pg).20:55 às 23:37

● Revisei a modelagem do Banco de dados feita pelo Juliano.

96

Data Tempogasto

Tipo Atividades

● Reunião com a equipe para definirmos o Planejamento de releases (item 4 do RESUMO_EASY.odt em diante); Planejamento daiteração (construção da Tabela de alocação de tarefas) e definição do cronograma a partir das disponibilidades diárias de cadaintegrante e do prazo para conclusão do TCC definido pela UFLA. Definimos que o Roberto iria orientar uma reunião sobre ospadrões de codificação antes do início da implementação, por ser ele a pessoa mais capacitada neste aspecto dentro da equipe.

Origem: ATA280806

29/08/06 5:26 Tecnologias 40 min - Discussão via e_mail sobre tecnologias e as restrições relacionadas no Edital em relação à parte do Cláudio.11min – Contato com Roberto sobre o andamento das atividades. Ele informou que não poderia participar nesta noite. Informei-o de que euestava atualizando as atas de reuniões. Combinamos de nos falar no dia seguinte.4:35min – Reunião via skype com o Cláudio para resolução de problemas em relação à escolha das ferramentas de desenvolvimento. Oconteúdo desta reunião encontra-se na ata respectiva. //Origem: ATA290806

30/08/06 1:05 Comunicação Enviei e_mail à equipe com o planejamento de atividades (30/08 e 31/08) que se segue. O ambiente do VIA DIGITAL ainda não estápronto para a equipe utilizar. Informei que a partir do dia 01/09 iniciam-se as atividades de implementação.Atividades previstas para 30/08:

● Jeanne - elaboração do cronograma com tarefas e responsáveis. Envio a equipe e publicação no Wiki;● Roberto, Juliano e Cláudio - reunião sobre os itens propostos no documento EasyProcess - fase de implementação (padrões de projeto,

etc.). O Roberto será o responsável pela orientação desta reunião conforme combinamos na de segunda-feira (28/09); sugeri a ele quelistasse antes da reunião os padrões que precisaria que a equipe seguisse e que observasse também os demais itens desta etapa nodocumento que enviei (caso a discussão sobre processo seja rápida, Roberto, Juliano e Cláudio poderiam discutir tecnologias e iniciarmontagem do ambiente.)

● Juliano - registro das decisões da reunião para transmitir à Jeanne.Atividades previstas para 31/08:

● Roberto, Juliano e Cláudio: montagem do ambiente para desenvolvimento e conferência do cronograma e atividades a seremrealizadas na sexta-feira.

● Jeanne: atualização do wiki e acompanhamento das atividades.1h: Elaboração do plano de comunicação para o projeto e envio por e_mail à equipe para que eles opinassem. No mesmo e_mail disse aoCláudio que gostaria de trocar algumas idéias para saber se eu mesma poderia cuidar das atualizações do wiki evitando sobrecarga de tarefaspara ele. Solicitei a versão e o endereço do Wiki para atualizar o documento de tecnologias.0:05 - Recebi e_mail do Cláudio questionando sobre a Licença do Eclipse e que havia descoberto uma ferramenta com a mesma licença dele(Eclipse) que parecia ser melhor que as atuais em SL. Passou o link e disse que havia plugins dela para o Eclipse.Origem: Plano de comunicação e e_mails

31/08/06 0:30 Comunicaçãoe

acompanhamento

Enviei e_mail à equipe informando que não consegui realizar as atividades que previ para mim na noite anterior porque tive problemasfamiliares. Como ninguém havia me enviado e_mail do resultado da reunião, pedi que entrassem em contato para dizer se ela aconteceu.Recebi via e_mail um resumo do andamento das atividades do Cláudio conforme segue:

● Informou que quanto à preparação do ambiente para desenvolvimento já estava quase terminando (rodando

97

Data Tempogasto

Tipo Atividades

eclipse +plugins aptana, que considerou ser melhor que o quanta/blue fish....), hoje quer ver seconsegue emular o IE no linux e terminar de instalar o restante dos softwares que utilizará. Perguntou quais os softwares necessitariapara rodar a aplicação e novamente questionou sobre o Guia de Estilos.

Juliano também retornou informando que eles fizeram a reunião e que mandariam o log do skype para mim.20:39 às 20:57 – Contato com a Ângela via Skype.

● Informei-a que estou orientando o trabalho do Cláudio, que na nossa equipe é o responsável pela interface gráfica do componente.Solicitei a ele que lesse os Editais do projeto e o Anexo III – Arquitetura onde encontraria informações sobre os padrões de interface.Porém, detectamos que o Anexo III faz referência a um Guia de Estilos que não existia. Perguntei a ela onde poderíamos encontrareste documento. Ela me disse que precisaria entrar em contato com o pessoal de CG e SC e que me retornar ia no dia seguinte.

● Conversamos sobre disponibilização do CVS e dotproject conforme registrado no documento Entrev_SICE.odt;● Disse a ela que estávamos decididos a desenvolver utilizando apenas ferramentas livres e que tivemos problemas para convencer o

Cláudio, que só trabalhava com ferramentas proprietárias. Disse que orientei-o a utilizar uma ferramenta nova (SL) pois seria umdesafio interessante e manteríamos o foco na premissa citada. Ela concordou que o relato desta experiência seria muito interessante eaté o mais importante, e que não precisaríamos fazer tudo 100% perfeito. //Origem: Logs do skype, e_mails e entrevistas com o cliente

01/09/06 1.20 Acompanhamento

Início das atividades de implementação e dos problemas e dúvidas também:● Cláudio enviou e_mail ao Juliano e Roberto com dúvidas sobre quais os plugins do Eclipse deveria usar para desenvolver

jsp(xhtml/css/html) e taglibs; de onde baixar e como instalar;● Juliano informou que usava GEF, HtmlEditor e o plugin do Tomcat (Sysdeo), mas que o Roberto poderia orientá-lo melhor; disse

ainda que estava com problemas de visualização das tarefas no dotproject;● retornei o e_mail informando que estava configurando o ambiente e que iria verificar as permissões dele;● Roberto retornou ao Cláudio dizendo que usava o plugin de javascript JSEclipse e que precisava verificar a licença. Disse que a equipe

que trabalhava com ele usava também o WTP do Eclipse;● Cláudio retornou ainda com dúvidas sobre instalação dos plugins. Pediu ao Roberto se havia um documento de instalação e se

poderiam conversar à noite;● Roberto retornou informando que: o JSEclipse, tem um .zip que deverá ser descompactado dentro do diretório do eclipse. Já o WTP,

tem um pacote chamado WTP All In One, que inclui o eclipse já com o WTP e todas as suas dependências. O que deverá facilitarmuito a instalação. Disse que não poderia entrar à noite e provavelmente nem no dia seguinte em função de suas atividadesprofissionais. //Origem: e_mails

02/09/06 2:35 Tecnologias eMontagem decronograma

22:15 às 00:50 – O ambiente previsto para instalação e configuração pelo Wesley não foi organizado em tempo hábil. O Cláudio montoudotproject por sua conta em máquina própria e disponibilizou para nosso uso. Organização do cronograma no dotproject (passei por muitosproblemas de configuração no ambiente instalado pelo Cláudio, não foi possível criar as dependências entre as tarefas e a visualização delasestava com problemas também). //Origem: Logs do skype

03/09/06 1:15 Comunicaçãoe Montagem

Contato com a Ângela para saber se ela teve retorno sobre o Guia de Estilos solicitado pelo Cláudio. Ela me disse que havia mandadomensagens para a equipe de CG e SC mas que não havia conseguido retorno ainda, e que iria refazer o pedido no dia seguinte. Solicitei uma

98

Data Tempogasto

Tipo Atividades

de cronograma forma de contato com o PMI do VIA e que ela me apresentasse a ele para que eu pudesse contactá-lo. Ela me passou seu msn.Organizei dotproject até às 01:50. Enviei e_mail à equipe solicitando que revisassem o cronograma da iteração 1 no dotproject e que eu haviaalterado o prazo de início das atividades para dia 4 em função do alongamento do prazo pela UFLA e pelos atrasos neste início de organizaçãodas atividades, problemas pessoais, etc. Informei que para que não ficássemos prejudicados, organizei as iterações da seguinte forma:

04/09 a 09/09 - Iteração 1 – RF9 e 10/09 a 17/09 - Iteração 2 – RF13Informei que ainda poderíamos concluir antes do prazo e assim implementarmos o relatório que o Roberto queria. Informei que no próximo diaentrar ia na parte da tarde. //Origem: Logs do skype e e_mails

04/09/06 1:40 Comunicação Contato via e_mail da equipe em relação ao cronograma organizado:● Juliano sugeriu trocarmos a ordem de implementação dos requisitos em função das dependências entre eles. Informou que iria viajar e

que tentaria trabalhar mesmo assim. Perguntou ao Cláudio se ele teria como publicar o que ele mandasse no Wiki.● Roberto retornou se desculpando pela ausência por motivo de trabalho durante o final de semana. Concordou com o Juliano sobre o

cronograma e que nesta semana estaria mais presente, que ficaria mais tempo on-line no Skype se inteirando do que estavaacontecendo e lendo os e_mails que trocamos neste período;

● Cláudio retornou ao Juliano dizendo que publicaria tudo o que ele precisasse e me questionando novamente sobre o Guia de Estilos.Primeiro contato via MSN com o PMI do VIA DIGITAL, Sr. Adler. O resultado deste contato encontra-se registrado no documentoENTRV_SICE.odt.Contato com o Cláudio informando que ainda não havia retorno da Ângela sobre o Guia de estilos.Recebi e_mail da Ângela sobre seu contato com Sr. De Lucca em relação às nossas necessidades.Recebi e_mail do Wesley informando que a equipe de administração do VIA DIGITAL não iria disponibilizar o dotproject e quedeveríamos utilizar o próprio ambiente do VIA DIGITAL para isso.Fiz registro do nosso projeto no ambiente do VIA DIGITAL. //Origem: Logs do MSN, logs do skype e entrevistas com o cliente

05/09/06 1:00 Comunicação Discutimos via e_mail as impressões sobre o posicionamento do PMI do Via e decidimos nos reunir todos com ele e colocar nossa situaçãoatual. //Origem: e_mails

06/09/06 5:30 Comunicaçãoe

Acompanhamento

Divulgação de informações no Wiki. Organização de todo o ambiente com informações importantes para a equipe. Roberto me contactou neste período e informou que estava fazendo testes no Webwork e que o ambiente estava dando certo, tudo funcionando.Juliano enviou e_mail à equipe com os seguintes arquivos anexos: Diagrama de classes (VO e DAO) do Tipo de Produto e o projeto java quecriou contemplando: VOs, DAOs, teste unitário e os arquivos de configuração (lib, xml etc.). Disse que pelo tempo não havia ficado muitobom, mas que iria refatorar. Abriu a criticas e sugestões.Cláudio enviou um e_mail do esquema das div's do SICE, para visualização em 800x600 informando que e a única div que terá layout fluido(aumenta de acordo com o conteúdo) será a div colunacentro, as outras serão fixas. Abriu a críticas e sugestões. //Origem: e_mails

07/09/06 0:31 Acompanhamento

00:03 às 00:34 - Contato com Roberto via Skype sobre o andamento das atividades:● Ele me disse que estava com muitas responsabilidades no serviço e que estava difícil trabalhar no projeto. Estava monitorando um

sistema em um momento crítico de carga de um SGBD com informações de 3 anos, e que por isso estava afastado das atividades doprojeto. Disse que estava criando um projeto de exemplo para preparar o ambiente do webwork. Me passou o endereço do servidor que

99

Data Tempogasto

Tipo Atividades

estava montando para testar o funcionamento do projeto e me explicou o que havia feito até então.● Informei-o sobre a publicação constante de informações no Wiki do projeto. Perguntei se ele já havia iniciado alguma tarefa prevista

no cronograma que definimos. Ele me perguntou se eu havia agendado reunião para o dia seguinte, eu novamente perguntei a ele sehavia visto o cronograma que organizei no dotproject. Ele disse que havia visto só nos primeiros dias e que depois não. Pedi a ele queantes de começar a trabalhar no projeto no dia seguinte que entrasse no dot e relembrasse as tarefas. Disse a ele que havia reuniãoprevista para hoje com o Adler, mas que ele não apareceu.

● Roberto disse que o esqueleto de projeto que montou no Webwork comportaria as partes desenvolvidas pelo Juliano e Cláudio, e emseguida ele acertaria os nomes dos campos do SGBD e faria as chamadas para testarmos. Percebi claramente que ele estavadesenvolvendo o projeto completamente à parte do que estávamos planejando. //Origem: e_mails


Como ainda não havíamos conseguido o Guia de Estilos para o componente o Cláudio estava pesquisando vários modelos para validação dosformulários e dos menus que estava desenvolvendo para opinarmos. Passou os seguintes links: Validar formulários: http://www.dhtmlgoodies.com/scripts/dhtml-form-validation/dhtml-form-validation.htmlMenu: 01- http://www.dhtmlgoodies.com/scripts/slidedown-menu2/slidedown-menu2.html02- http://www.dhtmlgoodies.com/scripts/slidedown-menu2/slidedown-menu2-d2.html03- http://www.dhtmlgoodies.com/scripts/single-level-menu/single-level-menu.htmlJuliano enviou e_mail à equipe perguntando sobre o andamento do desenvolvimento e o aproveitamento do que já produzira para o projeto.Origem: e_mails


Publicação de diversos documentos no wiki do projeto.Roberto escolheu o link 2 para validação de menu que o Cláudio havia passado em 08/09/06.Roberto enviou e_mail ao Juliano dizendo que ainda não havia integrado a parte que ele desenvolveu. Solicitou ao Cláudio a situação final dastelas para integrar.Já estávamos com o cronograma estourado aqui.Cláudio retornou e_mail perguntando ao Roberto como seriam feitos os testes da camada deapresentação, pois não conseguiu rodar todo o ambiente para o componente na sua máquina, eisso poderia atrasar ainda mais o projeto. Perguntou se poderia fazer testes direto do ambiente de desenvolvimento do Roberto e se fossepossível como mandaria os arquivos para ele. //Origem: e_mails


Roberto retornou ao Cláudio informando que a validação dos JavaScript deveria ser feita no ambiente próprio em que ele desenvolveu e quedepois ele integraria tudo e a equipe deveria baixar o projeto integrado, compilar, e ter o tomcatpara testar integrado.Disponibilizou seu ambiente de desenvolvimento para testes também, mas reafirmou que seria bom cada um ter seuambiente, para ter certeza que ambiente dele não estava viciado e garantir a autonomia de cada um.Neste período ainda não tínhamos o CVS do VIA DIGITAL disponibilizado para nossa equipe. O Roberto então disponibilizou oSubVersion da máquina dele. Me questionou sobre a disponibilização do CVS para o nosso trabalho.

100

http://www.dhtmlgoodies.com/scripts/single-level-menu/single-level-menu.html

http://www.dhtmlgoodies.com/scripts/slidedown-menu2/slidedown-menu2-d2.html

http://www.dhtmlgoodies.com/scripts/slidedown-menu2/slidedown-menu2.html

http://www.dhtmlgoodies.com/scripts/dhtml-form-validation/dhtml-form-validation.html

Data Tempogasto

Tipo Atividades

O Cláudio ainda enviou outro e_mail perguntando ao Roberto se ele já havia definido quais seriam as tags do webwork a serem utilizadas esolicitou envio delas a ele, além de dicas para instalar no ambiente e testar. //Origem: e_mails

12/09/06 5:02 Acompanhamento e

Planejamentode cronograma

Roberto retornou ao Cláudio informando que não seria ele quem definiria as tags a serem utilizadas, e que o WebWork possuía um conjunto detags que encapsulam os elementos da tela (botão, caixa de texto, label, combo, etc), que poderiam ou não serem usadas, mas que ajudam muito,evitando colocar código java na página. Enviou 2 exemplos de implementação para auxílio ao Cláudio: //label com caixa de texto. O conteudo de yourName vai para o servidor<ww:textfield label="Your Name" name="yourName"></ww:textfield>//imprime o conteúdo da variável yourName<ww:property value="yourName" />Disse ao Cláudio que era necessário, ver a importância de uso dos elementos na página e verqual é a tag correspondente. Feito isso o Cláudio deveria passar a ele os nomes que utilizasse nos elementos da tela para mapear no código. Envio de e_mail à equipe para agendamento da reunião de acompanhamento (final de iteração), todos deveriam comparecer para: discutirmos oandamento das atividades; completarmos a TAT - Tabela de alocação de tarefas; fazermos uma análise de riscos em virtude de problemas emudanças, entre outros fatores; levantarmos as necessidades de refatoramento de código; gerarmos o Big Chart e discutirmos dúvidas eproblemas gerais.Solicitei que planejassem o que precisariam dizer na reunião para aproveitarmos melhor o tempo em que estivéssemos juntos. Informei quehavia publicado diversas informações importantes no WIKI do projeto, e pedi a todos que dessem uma conferida por lá. Sobre o VIA DIGITAL relatei que (como eles já sabiam) havia cadastrado o SICE como um projeto no GForge para utilizarmos o CVS, Redede tarefas e os recursos disponíveis para o VIA DIGITAL. No momento do cadastro, havia recebido uma mensagem solicitando que euaguardasse retorno em 72 horas. Isso havia sido no dia 04/09, e até a presente data não havia obtido retorno. Disse que havia enviado umamensagem para a Ângela cobrando mais apoio, porém, que independente deles, devíamos manter o uso do TortoiseSVN do Roberto e odotproject que o Cláudio havia instalado para nós. Disse que sabia que as condições eram difíceis, mas estávamos por nossa conta mesmo eiríamos fazer o que fosse possível para concluir o que planejamos. Pedi que qualquer problema no horário agendado fosse comunicado emtempo e que aguardava retorno de todos.Enviei e_mail para Ângela cobrando mais apoio à equipe. Os contatos encontram-se registrados no documento de entrevistas.Ainda nesta data recebemos da equipe do VIA DIGITAL o endereço para uma lista de discussão para a equipe do SICE e as formas de acesso,além da aprovação do registro do projeto no ambiente. Repassei e_mails à equipe.Trabalhei no Repositório do VIA DIGITAL testando os acessos, conhecendo o ambiente e definindo o cronograma das próximas atividadespara que a equipe registrasse os logs de desenvolvimento. //Origem: e_mails e entrevistas com o cliente

13/09/06 4:31 1:08 – Cadastro de atividades no Repositório do VIA DIGITAL e conhecimento da ferramenta.21:02 às 00:16 – Reunião de acompanhamento (final da primeira iteração). Resultados na ata correspondente. (Simultâneo) 22:07 às 22:15 - Contato com Juliano via Skype:

● sinalizamos a dificuldade de comunicação via Skype, a dificuldade da conversa fluir com os integrantes da equipe e a falta de recursospara gravar as reuniões por voz. Lembramos que os mesmos problemas aconteceram quando fizemos o trabalho da Ana Rouillerutilizando MSN para as reuniões.

101

Data Tempogasto

Tipo Atividades

(Simultâneo) 22:34 às 22:35 – Contato com Roberto via Skype:● ele informou que estava lendo os logs do Cláudio sobre os problemas que ele estava tendo.

00:16 às 00:25 – Auxiliei o Cláudio a registrar os logs das tarefas no VIA e organizamos informações no Wiki.

Enviei e_mail de retorno ao Sr. De Lucca. //Origem: ATA130906, logs do skype e entrevistas com o cliente


Cláudio enviou e_mail informando que das atividades previstas (wiki, jsps e logs no via), só havia feito até o momento a publicação dedocumentos para download no wiki. À tarde enviou os jsps desenvolvidos.De 14/09 a 17/09 - Viajei para BH por problemas de saúde em família. Não pude acompanhar o andamento do projeto nestes dias e tivemosum atraso na segunda iteração. //Origem: e_mails

18/09/06 1:30 Tecnologias eAcompanhame

nto

Enviei um e_mail à equipe informando o motivo da minha ausência e solicitando a todos informações sobre o andamento das tarefas.Tentei configurar meu servidor linux para executar a aplicação, sem obter sucesso. A interface foi validada nesta primeira etapa através deimagens.Juliano me disse o repositório do VIA DIGITAL ficou fora do ar durante todo o fim de semana e que ainda permanecia. //Origem: e_mails


Comunicação,Validação eTecnologias

Enviei tutorial de acesso ao CVS recebido da Ângela para o Roberto Rocha porque o Cláudio ainda não havia disponibilizado o tutorial noWiki do projeto e o Roberto estava com problemas em acessar o CVS.Estabeleci contato via e_mail com o Wesley solicitando a senha de acesso ao CVS do repositório do VIA DIGITAL; ele retornou nesta mesmadata o endereço do site e a forma de acesso.23:11 às 01:06 - Contato com Cláudio via Skype:

● Informei-o sobre os meus problemas em relação à montagem do ambiente para testes;● Enviei a ele os documentos do edital para publicação no Wiki pois pretendia usar as imagens do Wiki como anexos do meu TCC;● Pedi a ele que me enviasse as telas por e_mail para que eu pudesse validar as imagens até conseguir finalizar a montagem do

ambiente. Depois desta validação entregaríamos para o Roberto integrar e fecharíamos a primeira iteração. Recebi do Cláudio as telasdo SICE para validação da interface. Revisei-as e publiquei um checklist no Wiki do projeto.

Origem: e_mails, logs do skype e entrevistas com o cliente

20/09/06 1:00 Validação Validação da interface gráfica de acordo com os documentos base do Edital e Especificação de Requisitos. Registro de logs no Repositório doVIA DIGITAL. Gerei checklist para Cláudio e disponibilizei no Wiki. //Origem: e_mails e repositório do VIA DIGITAL

21/09/06 0:15 Validação Cláudio enviou correções nos itens que apontei no checklist de validação da interface gráfica enviado em 20/09/06. //Origem: e_mails

23/09/06 0:15 Validação Cláudio enviou outro retorno das correções que ainda apontei após a última correção da interface. Postou também no wiki. //Origem: e_mails


Estava em BH novamente com problemas de saúde em família. Validei as últimas correções do Cláudio e postei no Wiki. Enviei e_mail àequipe relatando o motivo da minha nova ausência e solicitando informações sobre o andamento do projeto, já que eu possuía apenasinformações do Cláudio e queria rodar o processo ainda uma vez mais. //Origem: e_mails

27/09/06 0:15 TCC Claudio enviou um esboço da sua monografia para opinarmos. //Origem: e_mails

102

Data Tempogasto

Tipo Atividades


A comunicação com a equipe foi ficando cada vez mais espaçada em virtude da proximidade do encontro para defesa do TCC.● Constatei que não seria possível rodarmos o processo mais uma vez e sugeri iniciarmos a elaboração do TCC tendo em vista a falta de

retorno da equipe sobre o andamento do projeto e o tempo limite para entrega do TCC na UFLA. Sugeri ao Cláudio que enviasse oesboço da sua monografia para a Ângela;

● Roberto informou ao Juliano que estava quase terminando a integração do Tipo de Produto e do Produto. Segundo ele faltava apenascriar as tabelas e terminar a implementação. Relatou que estava com problemas na máquina. Ele não registrou informação nenhumasobre o andamento do trabalho nem no Wiki, nem no dotproject. //Origem: e_mails

29/09/06 0:15 Comunicação ● Juliano sugeriu que o desenvolvimento fosse continuado até a conclusão da próxima iteração, e que ele, o Roberto e o Cláudio secomprometeriam em anotar as atividades realizadas e o tempo gasto. //Origem: e_mails

02/10/06 2:06 Acompanhamento e TCC.

22:12 às 00:18 - Contato com o Cláudio sobre a ausência do Juliano e Roberto e o aperto do prazo para escrita do TCC. Trocamos idéias sobreo TCC. //Origem: e_mails

03/10/06 0:33 TCC 22:19 às 22:42 - Contato com a Ângela via Skype para informá-la da situação atual do nosso TCC. Informei-a das dificuldades pessoais queestive passando (problemas de saúde em família), e que por causa disso e dos demais problemas do projeto só havíamos conseguido rodar oprocesso apenas uma vez, e que iríamos redigir o TCC assim mesmo. Disse a ela do meu receio em relação ao tempo. Ela me disse para tentarfinalizar e se não desse, para apresentar no próximo encontro. //Origem: e_mails


Roberto informou que sobre a implementação já havia conseguido integrar quase tudo com a parte do Cláudio. Pediu ao Juliano se poderia enviar a parte da implementação da tabela de produto (classes, xml e scripts do banco). Juliano disse ao Roberto que gostaria de agendar com ele um tempo para resolver alguns problemas que estava tendo com o Hibernate e pediuao Cláudio para que enviasse o que havia desenvolvido para ele ver. //Origem: e_mails

30/10/06 0:09 TCC 22:31 às 22:40-Recebi do Roberto via Skype seu TCC para criticar. Após esta data os contatos com a equipe foram apenas sobre o TCC.Origem: e_mails

103

ANEXO I – Protótipo do SICE em telas

Figura 7: Página inicial do SICE

Figura 8: Página de Cadastro de Tipos de Produtos

104

Figura 9: Página de Cadastro de Produtos

105

tcc do curso de produção de software livre - ufla 2007

Technology