Pró Reitoria de Pós Graduação a Distancia Lato Sensu em Desenvolvimento de Sistemas em Software Livre Trabalho de Conclusão de d e Curso
Projeto de Fabrica de Software para Desenvolvimento, Implantação e Adaptação de Softwares Livres do IFNMG
Autor: Nelson Barros Cavalcante Junior Orientador: José Adalberto Facanha Gualeve
Montes Claros – MG 2012
Nelson Barros Cavalcante Junior
Projeto de Fabrica de Software para Desenvolvimento, Implantação e Adaptação de Softwares Livres do IFNMG
Monografia apresentada ao programa de Pós-Graduação Lato Sensu em Desenvolvimento de Sistemas em Software Livre da Universidade Católica de Brasília Virtual, como requisito
parci rcial
para
obtenção
do
certificado
de
Especialista em Desenvolvimento de Sistemas. Sistemas.
Orientador: José Adalberto Facanha Gualeve
Montes Claros – MG 2012
Nelson Barros Cavalcante Junior
Projeto de Fabrica de Software para Desenvolvimento, Implantação e Adaptação de Softwares Livres do IFNMG
Monografia apresentada ao programa de Pós-Graduação Lato Sensu em Desenvolvimento de Sistemas em Software Livre da Universidade Católica de Brasília Virtual, como requisito
parci rcial
para
obtenção
do
certificado
de
Especialista em Desenvolvimento de Sistemas. Sistemas.
Orientador: José Adalberto Facanha Gualeve
Montes Claros – MG 2012
Monografia de autoria de Nelson Barros Cavalcante Junior, intitulada “PROJETO DE FABRICA DE SOFTWARE PARA DESENVOLVIMENTO, IMPLANTAÇÃO E ADAPTAÇÃO DE SOFTWARES LIVRES DO IFNMG”, apresentada como requisito parcial para obtenção do certificado de Especialista em Desenvolvimento de Sistemas em Software Livre da Universidade Católica de Brasília Virtual, 04 de outubro de 2012, defendida e/ou aprovada pela banca examinadora abaixo assinada:
________________________ ____________________________________ _________________ _____ Prof. Mestre. José Adalberto Adalberto Facanha Gualeve Orientador Desenvolvimento de Sistemas em Software Livre/Pós- Graduação Lato Sensu – UCB Virtual
________________________ ____________________________________ _________________ _____ Prof. Especialista. Weslley Rodrigues Sepulvida Desenvolvimento de Sistemas em Software Livre/Pós- Graduação Lato Sensu – UCB Virtual
Resumo Este trabalho descreve um projeto de fabrica de software, visando o desenvolvimento, implantação e adaptação de softwares livres em uma instituição de ensino superior e técnico da rede federal. Para esse projeto usamos os principais conceitos de fabrica de software com as melhores praticas da engenharia de software, buscando adaptar uma metodologia ágil de desenvolvimento a SCRUM ao contesto do ambiente de desenvolvimento já existente na instituição e com isso criar um modelo de fabrica que atenda as necessidades de um desenvolvimento rápido e distribuído de softwares para a instituição. Palavras-chave: Fabrica de Software, Desenvolvimento, Software Livre, Engenharia de Software, Metodologia Agíl, SCRUM, Distribuído
Abstract This paper describes a project produces software for the development, deployment and adaptation of open source software in an institution of higher education and federal network technician. For this project we used the key concepts of software manufactures with the best practices of software engineering, trying to adapt an agile methodology SCRUM development to contest the development environment existing in the institution and thereby create a model that meets the manufactures needs of rapid development and distributed software to the institution. Keywords: Of Software Manufactures, Software Development, Open Source, Software Engineering, Agile, SCRUM, Distributed
Lista de Figuras Figura - 1 Escopo de fornecimento da fabrica de software.......................................................17 Figura - 2 Modelo em Cascata..................................................................................................20 Figura - 3 Representação Gráfica do Modelo Espiral ..............................................................22 Figura - 4 Representação Gráfica do Modelo Scrum................................................................25 Figura - 5 Organograma da DGTI do IFNMG..........................................................................40 Figura - 6 Estrutura organizacional para o modelo proposto....................................................40 Figura - 7 Estrutura Organizacional de Decisões e Processos..................................................41 Figura - 8 Visão geral do processo SCRUM no modelo proposto............................................45 Figura - 9 Arquitetura em camada MVC..................................................................................53
Lista de tabelas Tabela - 1 Perfis funcionais......................................................................................................42 Tabela - 2 Atividades do Plano de Processos...........................................................................49 Tabela - 3 Demandas Emergenciais.........................................................................................56 Tabela - 4 Cronograma.............................................................................................................57
Lista de Siglas IFNMG
Instituto Federal de Educação, Ciência e Tecnologia do Norte de Minas Gerais
SL CEFET
Software Livre
Centro Federal de Educação Tecnológica
EAF
Escola Agrotécnica Federal
SLA
Service Level Agreement
IEEE
Institute of Electrical and Electronics Engineers
SEI
Software Engineering Institute
CAD
Computer-Aided Design
FDD
Featuredriven Development
GNU
Gnu's Not Unix
GPL
General Public License
SIGP
Sistema de Gerenciamento de Projetos
LGPL
Library General Public Licence
LDAP
Lightweight Directory Access Protocol
HTTP
Hypertext Transfer Protocol
SSH
Secure Shell
CVS
Concurrent Version System
SVN
Subversion
CPU
Central Processing Unit
TCP
Transmission Control Protocol
IP FTP SGBD SGBDOR
Internet Protocol File Transfer Protocol
Sistema Gerenciador de Banco de Dados Sistema Gerenciador de Banco de Dados Objeto-Relacional
SQL
Structured Query Language
SIGA
Sistema Integrado de Gestão Administrativa
SAGU DGTI
Sistema aberto de gestão unificada Diretoria de Gestão de Tecnologia da Informação
Sumário 1 Introdução.......................................................................................................................................12 2 Justificativa.....................................................................................................................................13 3 Publico Alvo...................................................................................................................................13 4 Objetivos.........................................................................................................................................13 4.1 Objetivo geral.........................................................................................................................13 4.2 Objetivos Específicos.............................................................................................................14 5 Referencial Teórico.........................................................................................................................14 5.1 Fabrica de Software................................................................................................................14 5.2 Engenharia de Software..........................................................................................................17 5.3 Modelos e Processos Metodológicos de Desenvolvimento....................................................19 5.3.1 Modelo Tradicional.........................................................................................................19 5.3.2 Modelo Cascata ..............................................................................................................20 5.3.3 Prototipação ...................................................................................................................21 5.3.4 Modelo Espiral ...............................................................................................................22 5.3.5 Metodologias Ágeis........................................................................................................23 5.3.6 Extreme Programming (XP) ..........................................................................................24 5.3.7 Featuredriven Development (FDD) ...............................................................................24 5.3.8 Scrum..............................................................................................................................25 5.4 Ferramentas de Apoio e Desenvolvimento.............................................................................26 5.4.1 Gestão de Projetos...........................................................................................................26 5.4.1.1 DotProject................................................................................................................26 5.4.1.2 R/Open ....................................................................................................................27 5.4.1.3 Redmine...................................................................................................................28 5.4.2 Controle de Versões.........................................................................................................29 5.4.2.1 Bazaar......................................................................................................................29 5.4.2.2 Mercurial.................................................................................................................30 5.4.2.3 Subversion...............................................................................................................30 5.4.3 Desenvolvimento e Testes...............................................................................................30 5.4.3.1 Framework KumbiaPHP........................................................................................31 5.4.3.2 Framework Zend.....................................................................................................31 5.4.3.3 Framework Miolo....................................................................................................31 5.4.3.4 Linguagem de Programação Java............................................................................32 5.4.3.5 Linguagem de Programação ASP............................................................................34
5.4.3.6 Linguagem de Programação PHP............................................................................34 5.4.3.7 Banco de Dados Mysql............................................................................................35 5.4.3.8 Banco de Dados Postgresql.....................................................................................35 6 Metodologia....................................................................................................................................36 7 Modelo Proposto............................................................................................................................37 7.1 Descrição Geral do Modelo Proposto ...................................................................................38 7.2 Detalhamento do Modelo Proposto........................................................................................39 7.2.1 Estrutura organizacional..................................................................................................39 7.2.1.1 Estrutura organizacional Atual................................................................................40 7.2.1.2 Estrutura organizacional para modelo proposto......................................................40 7.2.2 Perfis funcionais..............................................................................................................42 7.2.3 Metodologia de desenvolvimento de software................................................................43 7.2.4 Material de instrumentação.............................................................................................46 7.2.4.1 Ferramentas de desenvolvimento............................................................................47 7.2.4.2 Ferramentas de gerenciamento de projetos.............................................................47 7.2.4.3 Ferramenta de repositório e controle de versão.......................................................48 7.2.4.4 Ferramentas para comunicação...............................................................................48 7.2.4.5 Sistema gerenciador de banco de dados..................................................................48 7.2.5 Plano de Processos..........................................................................................................48 Fase 1 – Processo de recebimento de serviço ......................................................................50 Fase 2 – Processo de entrada da demanda nas equipes de desenvolvimento.......................50 Fase 3 – Processo de produção.............................................................................................50 Fase 4 – Encerramento do processo.....................................................................................51 Fase 5 – Satisfação do usuário.............................................................................................52 Boas praticas na produção de Software................................................................................52 7.2.6 Demandas atuais.............................................................................................................56 7.2.7 Cronograma.....................................................................................................................57
12/60
1
Introdução O software Livre vem ganhando cada vez mais destaque e importância, não
somente nas empresas particulares mas também nos setores públicos em geral. Isso se deve pela possibilidade de menores custos de implantação e manutenção bem como servir de alternativa que pode trazer maior liberdade de escolha e flexibilidade no desenvolvimento das aplicações. No Brasil, Recife foi a primeira cidade a aprovar uma lei de uso preferencial do software livre, a Lei n° 16.639/2001, de autoria do ex-secretario de Desenvolvimento Econômico, Waldemar Borges. A partir de então o uso de software livre em repartições publicas tem se tornando crescente nos últimos anos. Nessa mesma perspectiva o governo federal começa a priorizar o software livre em suas repartições e como incentivo ao desenvolvimento e disseminação do SL surge a partir de 2007 alguns sites governamentais como o Portal do Software Publico, Software Livre no Governo do Brasil e outros. O Instituto Federal de Educação, Ciência e Tecnologia do Norte de Minas Gerais (IFNMG) foi criado em 29 de dezembro de 2008 , pela Lei nº 11.892, através da integração do Centro Federal de Educação Tecnológica (Cefet) de Januária e da Escola Agrotécnica Federal de Salinas (EAF), instituições com mais de 50 anos de experiência na oferta da educação profissional. Atualmente, agrega sete campi – Campus Almenara, Campus Araçuaí, Campus Arinos, Campus Januária, Campus Montes Claros, Campus Pirapora e Campus Salinas – e a Reitoria, sediada em Montes Claros. Com essa visão de instituições federeis, como IFNMG, estão aderirem ao software livre e com isso juntando esforços para construir uma equipe que possa desenvolver, adaptar e implantar softwares livres que são necessários a instituição. Essa perspectiva de uso de software livre no Instituto Federal vem desde sua formação uma vez que se via a necessidade de informatização dos seus setores e processos e o governo nos seus treinamentos incentivou o uso do sistema SIGA que era custeado por bolsas federais porem ainda não esta muito avançado.
13/60
Em 2008 a utilização de software livres veio a se intensificar e fortalecer uma vez que o governo federal publicou a instrução normativa 04 que normatizou as contratações de TI nas instituições federais onde deve se dar prioridade ao software livre. A partir de então o IFNMG vem discutindo a possibilidade de construção de uma Fabrica de Software em suas dependências visando assim a produção e adquação de softwares livres para as redes federais de educação.
2
Justificativa O projeto a ser desenvolvido se justifica pela necessidade da criação de uma
Fabrica de Softwares no IFNMG, para adequação de softwares livres em uso na instituição e desenvolvimento de novos softwares que atendam as demandas dos diversos setores. Unindo essa perspectiva e o os conhecimento adquiridos nessa pós de Desenvolvimento de Software Livre buscamos criar esse projeto para ser implementado no Instituto Federal de Educação, Ciência e Tecnologia do Norte de Minas Gerais.
3
Publico Alvo
O publico alvo para o qual se teve a concepção desse projeto é a comunidade acadêmica do Instituto Federal do Norte de Minas Gerias, a qual faz parte dos negócios acadêmicos do IFNMG. A comunidade acadêmica é divida em funcionários, discentes e docentes bem como aqueles que utilizam de algum modo a instituição.
4
Objetivos
4.1 Objetivo geral Esse projeto tem por objetivo a construção de um modelo de Fabrica de Software de Desenvolvimento, Adequação e Implantação de Software Livre, para
14/60
atender o IFNMG na adequação de softwares livres já implantados e desenvolvimento de novas demandas de software que supra as necessidades dos diversos setores da instituição.
4.2 Objetivos Específicos Para se chegar ao atendimento do objetivo geral proposto por esse projeto será necessário o atendimento dos seguintes objetivos específicos: •
Levantar referenciais teóricos sobre a concepção e desenvolvimento de uma fabrica de software;
•
Analisar diferentes processos e métodos de desenvolvimento de software em especifico o software livre, identificando suas principais características, artefatos, casos indicados, vantagens e desvantagens;
•
Definir a partir do levantamento e das conclusões obtidas dessa analise, o modelo adequado de fabrica de software que atenda todas as necessidades do IFNMG.
•
Criar processos e regras no modelo proposto de fabrica de software para corrigir erros, adequar e desenvolver novas funcionalidades nos softwares existentes na instituição bem como criar outras aplicações necessárias.
5
Referencial Teórico 5.1 Fabrica de Software A expressão Fábrica de Software surgiu em meados da década de 80, tendo seu
começo no brasil na década de 90 em empresas de prestação de serviços em tecnologia da informação. Uma definição adequada para essa expressão é a dada por Fernandes e Teixeira (2011):
15/60 Um processo estruturado, controlado e melhorado de forma contínua, considerando abordagens de engenharia industrial, orientado para o atendimento a múltiplas demandas de natureza e escopo distintas, visando à geração de produtos de software, conforme os requerimentos documentados dos usuários e/ou clientes, da forma mais produtiva e econômica possível.(Fernandes e Teixeira, 2011).
Para Fernandes e Teixeira (2011), uma Fabrica de software deve possuir os seguintes atributos básicos (independentemente de seu escopo de fornecimento): •
Deve haver um processo definido e padrão para o desenvolvimento do produto de software;
•
A Fábrica deve ter forte gerenciamento da interface com o usuário e/ou cliente, tanto no sentido de recebimento de solicitações, como de entrega dos produtos solicitados;
•
A entrada para a Fábrica (a ordem de serviço ou solicitação de serviço) deve ser padronizada;
•
As estimativas de prazo e custo devem ser baseadas na capacidade real de atendimento da Fábrica a determinada demanda;
•
•
Deve haver métodos padrões de estimativas baseados no histórico; A Fábrica deve ter, de preferência, tempos padrões de atendimento já estabelecidos de acordo com o domínio da aplicação, da plataforma tecnológica e do tamanho da demanda (programa e/ou projeto);
•
Os perfis de recursos humanos devem ser controlados e estar alinhado ao tipo de demanda (natureza e complexidade) da Fábrica;
•
A Fábrica deve ter rigoroso controle dos recursos em termos de sua alocação, disponibilidade, necessidade futura e produtividade;
•
A Fábrica deve ter um processo para o planejamento e controle da produção;
•
A Fábrica deve ter o controle do status das múltiplas demandas em seu
16/60
processo e permitir rastreamento dessas demandas; •
A Fábrica deve controlar todos os itens de software (documentos, métodos, procedimentos, ferramentas e código), criando uma biblioteca de itens;
•
A Fábrica deve ter o absoluto controle do andamento da execução de cada demanda;
•
Os produtos de software devem ser construídos de acordo com métodos, técnicas e ferramentas padronizadas;
•
A Fábrica pode ter processos distintos para o atendimento a demanda de naturezas diferentes;
•
Todos os recursos humanos devem estar aptos e treinados para as tarefas de desenvolvimento de software e para operar processos operacionais e de gestão;
•
A Fábrica deve ter processos de atendimento ( help desk ) para os usuários e/ou clientes;
•
A Fábrica deve ter mecanismos que garantam a qualidade do produto de software, conforme requerimentos do usuário e/ou cliente;
•
A Fábrica deve ter mecanismos de apuração, apropriação e controle de custos;
•
A Fábrica deve ter mecanismos de medições de atributos de sua operação, tais como: tempos médios de atendimento, densidade de defeitos dos produtos, eficiência de remoção de defeitos e exatidão das estimativas;
•
A Fábrica tem que ter absoluto controle sobre os níveis de serviço (SLA) acordados com seus usuários e/ou clientes;
•
A Fábrica tem que melhorar seus processos de forma contínua, visando ao aumento de sua produtividade e à redução de seus custos
17/60
de operação; e •
O ambiente de hardware e software da Fábrica deve ser estável e estar alinhado com as necessidades de seus usuários e/ou clientes.
A figura abaixo nos mostra o escopo de fornecimento de uma Fábrica de qual podem podemos os vislum vislumbra brarr quatr quatro o escopo escoposs distin distintos tos,, cada cada escopo escopo Software, no qual poden podendo do ter atribu atributos tos simila similares res,, mas com intens intensida idade de difere diferente ntes.( s.(Fer Fernan nande dess e Teixeira, 2011). 2011).
Figura - 1
Escopo de fornecimento da fabrica de software Fonte: (Fernandes, 2004)
Com essa perspectiva da Fábrica de Software veremos a seguir as boas praticas da arquitetura e engenharia de software que são componentes importantes na produção de software.
5.2 Engenharia de Software No desenvolvimento as boas praticas de engenharia de software é essencial para se se obter um produto produto de software que atenda todos os requisitos do negocio. Podemos entender por engenharia de software como define a IEEE ( Institute of Electrical and Electronics Engineers): “engenharia de software se trata da aplicação
sistem sistemáti ática, ca, discip disciplin linada ada,, quantif quantificá icáve vell para para o desen desenvo volvim lviment ento, o, operaç operação ão e manu manute tenç nção ão do softw softwar are” e” (TON (TONSIG SIG apud apud IEEE IEEE,2 ,200 003, 3, pg 48). 48). Uma Uma outr outra a boa boa definição é a da SEI ( Software Engineering Institute), que expressa a engenharia de software como: “uma forma de engenharia que aplica os princípios da Ciência de
18/60
Computação e Matemática para alcançar soluções com melhor custo benefício para o problema do software”. (SEI, 1990, p 10). Os princi principai paiss compon componen entes tes da engenh engenhari aria a de software são são elenca elencados dos por por Pressman, em um conjunto de elementos fundamentais:
A engenharia de software é um rebento da engenharia de sistemas e de hardware. Ela abrange um conjunto de três elementos fundamentais - métodos, ferramentas e proce procedi dimen mento toss – que que poss possib ibililitita a ao gere gerent nte e o cont control role e do proc proces esso so de desenvolvime desenvolvimento nto do software e ofere oferece ce ao prof profis issi siona onall uma uma base base para para a construção de software de alta qualidade produtivamente. (PRESSMAN, 1995, p. 31).
Os métodos englobam “como fazer” para construir o software, envolvem tarefas como: como: planej planejame amento nto de projet projeto, o, anális análise e de requis requisito itos, s, codif codifica icaçã ção o e teste. teste. As ferram ferrament entas as são usadas usadas como como apoio apoio automa automatiz tizado ado ou semi-a semi-auto utomat matiza izado do aos métod métodos, os, como como por exemp exemplo: lo: CASEs, CADs CADs ou ling lingua uage gens ns de prog progra rama maçã ção o (Pressman, 1995). Por sua vez os procedimentos são o elo de ligação ente métodos e ferram ferrament entas, as, defin definem em a sequên sequência cia em que os método métodoss serão serão aplica aplicado dos, s, os produtos a serem entregues, os controles de qualidade e os macros de referência para a avaliação, possibilitando o desenvolvimento integral do software. Através do uso da engenharia engenharia de software busca-se organizar organizar de forma coerente processos de produção de software, e para uma fabrica de software os princípios da enge engenh nhar aria ia é um cons consol olid idad ador or do trat tratam amen ento to dess dessa a prod produç ução ão visa visand ndo o o desenvolvimento com eficácia e qualidade. Dentro desse capitulo apresentaremos os princi principai paiss concei conceitos tos de engenh engenhari aria a de software e os principais modelos e metodologias para desenvolvimento e gerenciamento de projetos em uma fabrica de software.
19/60
5.3 Modelos e Processos Metodológicos de Desenvolvimento Um modelo de desenvolvimento nada mais é que uma representação abstrata do proces processo so de desenv desenvolv olvime imento nto que busca busca organi organiza zarr as fases fases envolv envolvida idass na produção do software. Para SOMMERVILLE (2001) o modelo não é uma descrição definitiva iva,
mas
sim,
uma
representação
abstrata
do
geren renciamento
e
desenvolvimento do software (SOMMERVILLE, 2001). Na visão de Pfleeger (2004), alguns alguns modelo modeloss repres represent entam am “receit “receitas as do caminh caminho o que o desenv desenvolv olvime imento nto de software deveria seguir e outros são descritos do modo que o desenvolvimento do software realmente é feito”(PFLEEGER, 2004, p 38). Quando Quando os modelo modeloss envolv envolvido idoss no desenv desenvolv olvime imento nto do softwa software re são bem bem definidos e organizados isso implica em uma maior qualidade aos processos e ao próprio produto de software. A seguir, seguir, apresentaremos resumidamente algumas das principais propostas de mode modelo loss de dese desenv nvolv olvim imen ento to de soft softwa ware re util utiliz izad adas as pela pelass comu comuni nida dade dess de engen engenhar haria ia de softw software are,, e será será dividi dividida da em duas duas aborda abordagen genss a tradic tradicion ional al ou clássica e a ágil.
5.3.1
Modelo Tradicional
Esse modelo referencia a primeira família de modelos de desenvolvimento de software. Como o próprio nome diz é um modelo mais conservador o primeiro a ser criado pela engenharia de software numa época em que o desenvolvimento era “baseado apenas em terminais burros e mainframes” (SOARES apud ROYCE, 2004, p 2). Devido nessa época os custos de alteração e manutenção de software serem muit muito o elev elevad ados os,, o dese desenv nvolv olvim imen ento to do softw softwar are e era era muit muito o mais mais plan planej ejad ado o e docu docume ment ntad ado, o, pois pois,, o aces acesso so a comp comput utad ador ores es era era limi limita tado do e não não exis existitiam am ferramentas de apoio. Iremos abordar nesse capitulo três principais modelos de desenvolvimento de softwa software re com com o objeti objetivo vo de exemp exemplif lifica icarr os modelo modeloss tradic tradicion ionais ais:: o Cascat Cascata, a, a Prototipação e o Espiral.
20/60
5.3.2
Modelo Cascata
Entre os modelos de engenharia de software o modelo cascata – também chamado de modelo sequencial linear e ciclo de vida clássico – continua sendo um modelo bastante utilizado para a engenharia de software, apesar de ser relativamente antigo. Basicamente um modelo de desenvolvimento em cascata resume-se em um modelo sequencial de desenvolvimento, com fases bem definidas, sendo comum as fases de: análise, projeto, codificação, teste e manutenção. O modelo em cascata também reconhecido como modelo linear as atividades do processo de desenvolvimento são estruturados em uma cascata onde a saída de uma etapa é a entrada para a próxima etapa como mostra na figura abaixo.
Figura - 2
Modelo em Cascata.
Fonte: PRESSMAN (2010).
Podemos resumir as atividades de cada parte da cascata apresentada acima como:
21/60 •
Primeira etapa Comunicação: iniciação do projeto e levantamento de requisitos.
•
Segunda etapa Planejamento (Análise): é quando se faz as estimativas, cronogramas e monitoramento.
•
Terceira etapa Modelagem: são feitas as especificações técnicas do software a analise e o projeto.
•
Quarta etapa Construção: a solução é codificada em uma linguagem de programação e é feito os testes.
•
Última etapa Implantação: é uma das fases genéricas, de correção e onde poderão ser feitas mudanças.
5.3.3
Prototipação
A prototipação se baseia na ideia de criação de protótipos, “que inicialmente cuida apenas das características de interface com o usuário, resguardando-se para uma segunda etapa procedimentos internos de manipulação de dados”. (TONSIG, 2003, p 62). O protótipo é um esboço do produto final, ele pode ser também representado no papel. Em outras etapas do desenvolvimento do protótipo pode-se desenvolver algumas funcionalidades como relatórios e módulos. Uma das características da prototipação é a participação ativa do usuário na criação do protótipo buscando uma melhor integração entre usuários e desenvolvedores visando chegar em uma melhor qualidade de software. Pressman, afirma que após o protótipo atender a todos os requisitos propostos pelo usuário: “ele será [...] descartado (pelo menos em parte) e o software real será projetado, levando-se em conta a qualidade e a manutenibilidade.” (PRESSMAN. 1995, p 38). O protótipo, depois de analisado e visto atender parcialmente ou totalmente os requisitos do projeto do software o mesmo é descartado e o software real passa a ser projetado a partir do protótipo.
22/60
5.3.4
Modelo Espiral
Modelo criado pelo Dr. Berry Boehm em 1986, nele é aglutinado os melhores elementos de seus antecessores acrescentando a análise de risco. Sua representação é dada por uma espiral onde cada ciclo representa uma fase do processo, sendo o clico divido em etapas. É definido como um modelo iterativo. Os requisitos são definidos no projeto inicial e são aprimorados a cada iteração (PFLEEGER, 2004).
Figura - 3
Representação Gráfica do Modelo Espiral Fonte: Tonsig (2003).
A abordagem tradicional considera quatro etapas fundamentais, como pode ser observado na Figura 5, onde cada etapa é representada por um quadrante do ciclo:
1. Planejamento: determinação dos objetivos, alternativas e restrições. 2. Análise dos riscos: análise de alternativas e identificação/resolução dos riscos. 3. Engenharia: desenvolvimento do produto no "nível seguinte".
23/60 4. Avaliação feita pelo cliente: avaliação dos resultados da engenharia. (PRESSMAN, 1995, p38).
O modelo espiral foi desenvolvido para lidar melhor com requisitos incertos ou sujeitos a alterações. Esse modelo é tido como uma abordagem mais realista para desenvolvimento de sistemas e de software de grande porte (TONSIG, 2003).
5.3.5
Metodologias Ágeis
“As metodologias ágeis surgiram com a proposta de aumentar o enfoque nas pessoas e não nos processos. Além disso, existe a preocupação em gastar menos tempo com documentação e mais tempo com a resolução do problema”. (SOARES, 2004, p 2). Diferentemente da metodologia tradicional a ágil tem uma menor preocupação com documentação, negociação de contrato e planejamento valorizando mais os indivíduos do negocio (profissionais e usuários) e a comunicação entre eles. No intuito de uma formalização dessa metodologia foi criado o manifesto ágil no qual aparece quatro conceitos que definem uma metodologia ágil (BENK et al, 2001): •
Individuo e interação ao invés de processo e ferramentas.
•
Software executável ao invés de documentação.
•
Colaboração do cliente ao invés de negociação de contrato.
•
Respostas rápidas as mudanças ao invés de seguir planos.
A aplicação dessa metodologia na sua grande maioria aparece mais em pequenas e medias empresas com equipes de trabalho pouco numerosas e com uma hierarquia bem definida. Apresentaremos a seguir uma breve descrição das mais conhecidas metodologias ágeis da atualidade.
24/60
5.3.6
Extreme Programming (XP)
A Extreme Programming foi projetada para equipes pequenas com até 10 desenvolvedores, trabalhando em interações curtas, com requisitos vagos em constante mudança. Kent Beck foi o idealizador desse modelo na década de 90. Na sua estrutura possui quatro valores principais: comunicação, simplicidade, feedback e coragem (BECK, 2004). A comunicação tem como objetivo manter o bom relacionamento do gerente de projeto com seus clientes e desenvolvedores, a simplicidade refere-se ao sistema sem funcionalidades desnecessárias com código auto-explicativo, o f eedback esta relacionado ao faro do programador possuir constantemente informações de avaliação do seu trabalho e a coragem que é necessária ter para a implantação dos três valores anteriores. Algumas boas praticas são elencadas por Beck e entre as principais estão: cliente presente, jogo de planejamento ( planning game), realeses curtos (small releases),
desenvolvimento
guiado
pelo
teste
( test driven development ),
programação em par ( pair programming ) , interação contínua (continuous intergration), refatoração (refatoring ), reuniões curtas e de pé ( stand-up meeting ) e
ritmo sustentável (susteainable pace). (BECK, 2004). A XP tem revolucionado o mercado de desenvolvimento de software, através dos seus conjuntos de práticas e valores, que incentivam um desenvolvimento ágil, com qualidade e continuo aprimoramento do projeto e da implantação do código.
5.3.7
Featuredriven Development (FDD)
É uma metodologia ágil que surgiu em 1997 quando Peter Coad e Jeff De Luca foram contratados para salvar um projeto bancário em Singapura e utilizaram essa metodologia para gerenciamento e desenvolvimento de software (RETAMAL, 2008). A FDD é uma metodologia muito objetiva, possuindo apenas duas fases: •
Concepção e Planejamento: Pensar um pouco antes de fazer (geralmente de 1 a2 semanas);
25/60 •
Construção: Fazer de forma interativa (geralmente em interações de 2 semanas).
Essa metodologia dispõe de cinco processos bem definidos que são: desenvolver um modelo abrangente, construir uma lista de funcionalidades, planejar por funcionalidades, detalhar por funcionalidades e construir por funcionalidades. (RETAMAL, 2008). O FDD é uma metodologia que pode ser aplicada a projetos em iniciação, a atualização de códigos existente, a criação de uma segunda versão, ou ainda à substituição de um sistema inteiro ou em partes. Essa metodologia possui características especificas para desenvolver sistemas críticos.
5.3.8
Scrum
O Scrum foi formalizado no artigo “The New Product Development Game” escrito em 1986 por Hirotaka Taleuchi e Ikujiro Nonaka publicado pela revista “Harvad Business Review” .
O seus princípios são semelhante a metodologia XP com equipes pequenas, requisitos instáveis, e iterações curtas. O desenvolvimento é divido em sprint (similares as iterações do XP) geralmente possuem de duas a quatro semanas, onde se divide o grupo de desenvolvedores em equipes pequenas e multifuncionais (analistas,
programadores,
testadores,
etc)
que
são
responsáveis
funcionalidades especificas definidas no início de cada sprint .
Figura - 4
Representação Gráfica do Modelo Scrum Fonte: http://scrumemacao.com.br/web/
por
26/60
Na figura acima podemos observar um sprint , desde o inicio quando se encontra em reserva (backlog ), passando pelo processo de produção, até tornar-se um produto finalizado para a entrega ( finish features – funcionalidade terminada). Também podemos observar a iterações diárias e semanais. O Scrum é um Modelo da Metodologia Ágil que tem tido grande aceitação nos últimos anos e ajuda para um desenvolvimento rápido e com qualidade.
5.4 Ferramentas de Apoio e Desenvolvimento Para uma boa produção de software desde sua concepção até a entrega, a engenharia de software se apoia em ferramentas de gerenciamento, controle, integração e produção para uma melhor qualidade do produto de software. E com essa perspectiva iremos abordar as principais ferramentas utilizadas na engenharia de softwares livres.
5.4.1
Gestão de Projetos
De acordo com Alcides Pietro, “gerenciar, administrar, coordenar ou gerir um projeto é a aplicação de técnicas, conhecimentos e habilidades para garantir que um projeto tenha sucesso. E gerenciar um projeto envolve desde iniciá-lo até finalizá-lo, passando pelas etapas de planejamento, execução e atividades de controle”. (Pietro) Com vistas ao gerenciamento de projetos apresentaremos três ferramentas de apoio ao desenvolvimento de software livre.
5.4.1.1 DotProject O dotProject é um sistema de gerenciamento de projetos baseado em software livre, com um conjunto de funcionalidades e características para implementação em ambientes corporativos, atendendo a diversas necessidades de gerentes e
27/60
Escritórios de Projetos. É uma ferramenta web, multiplataforma, escrito em PHP e utiliza banco de dados MySQL. Sua distribuição se dá sob a licença “GNU-GPL”, significando que seus usuários detêm o poder de copiá-lo gratuitamente da internet, fazer sua instalação, executar alterações para melhorá-lo e até mesmo distribuí-lo novamente, desde que a licença GNU-GPL seja mantida. O dotProject vem se caracterizando como uma opção interessante para instituições que necessitam de um sistema de gerenciamento de projetos (SIGP) e consideram a utilização de um software livre para esta finalidade. No Brasil, o dotProject possui uma comunidade bastante ativa, que se organiza por meio deste site e de uma lista de discussão de suporte técnico, acessível em http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/dotproject-br .
5.4.1.2 R/Open O R/Open é um software para gerenciamento de requisitos e atividades relacionadas ao desenvolvimento de projetos de TI baseando-se em conceitos de metodologias ágeis, como Open UP e Scrum. Toda a teoria para especificação de requisitos presente na ferramenta foi baseada em estudos realizados pelo consultor Paulo Vasconcellos e pelos membros da lista de discussão de AN-BR, cujos participantes são, em sua maioria, participantes dos cursos ministrados pelo Paulo. O R/Open é um software web desenvolvido em PHP e com banco de dados mySQL. Sua distribuição está sob a licença LGPL e pode ser copiado, distribuído e alterado, desde que respeite as condições impostas na licença.
28/60
5.4.1.3 Redmine Redmine é uma aplicação web de gerenciamento flexível de projetos. Escrita
usando o f r amework Ruby on Rails, ela é independente de plataforma e independente de banco de dados. Redmine é uma ferramenta open source distribuída sob licença GNU General Public License v2 (GPL).
Os recursos principais do Redmine são: •
Suporte a múltiplos projetos;
•
Controle de acesso flexível;
•
Gerenciamento de Bugs flexível;
•
Gráfico de Gantt e calendário;
•
Gerenciamento de notícias, arquivos e documentos;
•
Notificações por Feeds e e-mail;
•
Wiki do projeto;
•
Fórum do projeto;
•
Gerenciamento da linha do tempo;
•
Customização de campos para bugs, tarefas, projetos e usuários;
•
Integração com repositórios de código (SVN, CVS, Git, Mercurial, Bazaar e Darcs);
•
Criação de Bugs via email;
•
Suporte múltiplo de autenticação via LDAP;
•
Registro de usuários através de formulário;
•
Suporte a inúmeras linguagens inclusive português do Brasil;
29/60
5.4.2
Controle de Versões
Muitos problemas de desenvolvimento de software são causados por falta de controle de versão. Em uma equipe de produção, muitos problemas podem ocorrer, dependendo do tamanho e do conhecimento da equipe. Veja um elenco desses problemas: •
Sobrescrita de código por acidente;
•
Dificuldades em saber quais as alterações, por quem e quando foram efetuadas;
•
Dificuldade em recuperar o código de uma versão anterior que esteja em produção;
•
Dificuldade de manutenção de variações do sistema.
Falaremos aqui, de ferramentas de controle de versões, open-source.
5.4.2.1 Bazaar O Bazaar (ou bzr) é um sistema de controle de versão distribuída que se concentra na facilidade de uso e em ter um modelo de dados flexível. Ele é um projeto GNU oficial, e é o sistema de controle de versão nativo para o site de hospedagem de projetos de softwares livres, Launchpad.net. O Bazaar faz um controle de versão distribuída completo: todo trabalho toma lugar em árvores de versões (branches), e todo desenvolvedor, tipicamente, tem uma cópia completa do histórico das árvores. Essas árvores podem ser integradas a outras de uma forma descentralizada, mas o Bazaar pode também ser configurado para trabalhar de uma forma centralizada. O Bazaar teve início com o código baseado no GNU Arch, mas foi reescrito a partir do zero e agora não possui relação direta com ele.
30/60
5.4.2.2 Mercurial O Mercurial é um sistema de controle de versão distribuída que oferece, entre outras coisas, "indexação cruzada completa de arquivos e conjuntos de alterações (changesets); Protocolos HTTP e de sincronização SSH eficientes em respeito ao uso de largura de banda (bandwidth) e CPU; integração (merging) arbitrária entre as árvores de versões de desenvolvedores; interface web independente integrada; portabilidade para: UNIX, MacOS X, e Windows" e mais (a lista de recursos anterior foi parafraseada do web site do Mercurial).
5.4.2.3 Subversion Subversion, portanto, é uma ferramenta open-source de controle de versões que
segue a licença de software livre nos moldes da licença Apache/BSD. O projeto do Subversion iniciou em 2000 com a ideia de se construir um CVS melhor, isto é, mantendo o mesmo modelo de trabalho, mas consertando as falhas e limitações que o CVS apresentava. Desde então, vem atraindo uma comunidade cada vez maior de colaboradores e usuários.
5.4.3
Desenvolvimento e Testes
Como ferramentas de desenvolvimento e teste de software entenda-se, as ferramentas que serão responsáveis pela codificação e teste de erros na programação do software bem como as ferramentas geradoras de relatórios do software em produção.
Nesse contexto estaremos vendo algumas das principais ferramentas de codificação, teste e geração de relatorias disponíveis no mercado de desenvolvimento de softwares livres.
31/60
5.4.3.1 Framework KumbiaPHP KumbiaPHP é um framework para aplicações web livre escrito em PHP5. Tem como princípios as práticas de desenvolvimento Web como DRY e KISS para softwares comerciais e educacionais. Kumbia promove rapidez e eficiência na
criação e manutenção de aplicações web, substituindo tarefas repetitivas de codificação pelo poder e controle.
5.4.3.2 Framework Zend Zend Framework foi concebido no início de 2005 enquanto muitos novos frameworks, tais como Ruby on Rails e Spring Frammework estavam ganhando
popularidade na comunidade web development . ZF foi publicamente anunciado pela primeira vez na Zenb Conference. Ao mesmo tempo, nenhum framework amplamente usado tem sido disponibilizado para a comunidade PHP para preencher completamente necessidades de desenvolvimento web similares. Os projetistas do Zend Framework buscaram combinar características de uso final e rapid application development (RAD) desses novos frameworks com a simplicidade, abertura e
praticidade do mundo real que é altamente valorizada na comunidade PHP.
5.4.3.3 Framework Miolo O MIOLO é um Framework escrito em PHP utilizando apenas conceitos de POO e que oferece uma grande gama de funções para otimizar e agilizar o processo de criação de sistemas. O mapeamento de necessidades, definição de funcionalidades e a metodologia utilizada no desenvolvimento do MIOLO se basearam na experiência adquirida durante a criação do SAGU. Dentre as característica importantes implementadas, está a utilização do conceito de modularização. Nessa sistemática, o processo de criação de um novo módulo para um sistema ou mesmo a integração de módulos/sistemas distintos,
32/60
torna-se uma tarefa muito simples. Isso possibilita inclusive que, utilizando a mesma senha e de acordo com os direitos de acesso, um usuário possa interagir em diferentes sistemas no mesmo ambiente de produção. Essa estrutura permite um grande
reaproveitamento
de
funcionalidades,
contribuindo
inclusive
para
padronização do código. Além disso, o MIOLO possibilita a independência das equipes durante o desenvolvimento de um sistema. A equipe envolvida com a criação da estrutura de Base de Dados não precisa, obrigatoriamente manter um vínculo com a equipe que projeta a interface do sistema. Isso permite que o potencial dos colaboradores envolvidos seja melhor aproveitado, além de facilitar a integração de novas pessoas ao projeto. Característica relevante também, está no fato do MIOLO tratar, de forma transparente, das conexões a Bases de Dados. Dessa forma, por exemplo, é fácil implementar soluções distribuídas, inclusive em diferentes posições geográficas do globo. Outras características: geração e apresentação das páginas utilizando o conceito de temas, o que facilita a mudança e criação de novas interfaces para os usuários. Automatização do processo de criação e validação de formulários para entrada de dados, montagem automática listagens e controle relacionados, controle das conexões e abstração da Base de Dados, controle de erros, validação de usuários e controle dos direitos de acesso.
5.4.3.4 Linguagem de Programação Java. Java é uma linguagem de programação e uma plataforma de computação lançada pela primeira vez pela Sun Microsystems em 1995. É a tecnologia que capacita muitos programas da mais alta qualidade, como utilitários, jogos e aplicativos corporativos, entre muitos outros, por exemplo. O Java é executado em mais de 850 milhões de computadores pessoais e em bilhões de dispositivos em todo o mundo, inclusive telefones celulares e dispositivos de televisão.
33/60
A linguagem Java foi projetada tendo em vista os seguintes objetivos: •
Orientação a objeto – Baseado no modelo de Simulação
•
Portabilidade – Independência de plataforma – “escreva uma vez, execute
em qualquer lugar” (“write once, run anywhere” ) •
Recursos de Rede – Possui extensa biblioteca de rotinas que facilitam a
cooperação com protocolos TCP/IP, como HTTP e FTP •
Segurança – Pode executar programas via rede com restrições de
execução Além disso, podem-se destacar outras vantagens apresentadas pela linguagem: •
Sintaxe similar a C/C++
•
Facilidades de Internacionalização – Suporta nativamente caracteres
Unicode •
Simplicidade na especificação, tanto da linguagem como do “ambiente” de
execução (JVM) •
É distribuída com um vasto conjunto de bibliotecas (ou APIs)
•
Possui facilidades para criação de programas distribuídos e multitarefa
(múltiplas linhas de execução num mesmo programa) •
Desalocação de memória automática por processo de coletor de lixo
•
Carga Dinâmica de Código – Programas em Java são formados por uma
coleção de classes armazenadas independentemente e que podem ser carregadas no momento de utilização A Sun disponibiliza a maioria das distribuições Java gratuitamente e obtém receita com programas mais especializados como o Java Enterprise System. Em 13 de novembro de 2006, a Sun liberou partes do Java como software livre, sob a licença GNU General Public License. A liberação completa do código fonte sob a GPL ocorreu em maio de 2007.
34/60
5.4.3.5 Linguagem de Programação Python Python é uma linguagem de programação interpretada, de código fonte aberto e disponível para vários sistemas operacionais. Ser uma linguagem interpretada significa dizer que ao se escrever um programa, este não será compilado (traduzido para uma linguagem de máquina), mas sim lido por um outro programa (chamado de interpretador) que traduzirá para a máquina o que seu programa quer dizer. O interpretador para Python é interativo, ou seja, é possível executá-lo sem fornecer um script (programa) para ele. Ao invés disso, o interpretador disponibilizará uma interface interativa onde é possível inserir os comandos desejados um por um e ver o efeito de cada um deles.
5.4.3.6 Linguagem de Programação PHP PHP (um acrônimo recursivo para PHP: Hypertext Preprocessor ) é u m a linguagem de script open source de uso geral, muito utilizada e especialmente guarnecida para o desenvolvimento de aplicações Web embutido dentro do HTML. Ao invés de muitos comandos para mostrar HTML (como visto em C ou Perl), páginas PHP contém HTML juntamente com códigos que fazem "alguma coisa" (neste caso, mostra "Olá, Eu sou um script PHP!") O código PHP é delimitado por tags iniciais e finais que lhe permitem pular pra dentro e pra fora do
"modo PHP". O que distingui o PHP de algo como Javascript no lado do cliente é que o código é executado no servidor, gerando HTML que é então enviado para o cliente. O cliente receberia os resultados da execução desse script , mas não saberia como é o código fonte. Você pode inclusive configurar seu servidor para processar todos os seus arquivos HTML como PHP, e então não haverá nenhum modo dos usuários descobrirem que se você usa essa linguagem ou não. A melhor coisa em usar PHP está no fato de ele ser extremamente simples para um iniciante, mas oferece muitos recursos para o programador profissional. Não se
35/60
preocupe em ler as longas listas de funções do PHP. Você pode pular essa parte (por enquanto) e começar a escrever scripts em poucas horas.
5.4.3.7 Banco de Dados Mysql O MySQL foi criado na Suécia por dois suecos e um finlandês: David Axmark, Allan Larsson e Michael Monty Windenius, que têm trabalhado juntos desde a década de
1980. Hoje seu
desenvolvimento e manutenção empregam
aproximadamente 400 profissionais no mundo inteiro, e mais de mil contribuem testando o software, integrando-o a outros produtos, e escrevendo a respeito dele. No dia 16 de Janeiro de 2008, a MySQL AB, desenvolvedora do MySQL foi adquirida pela Sun Microsystems, por US$ 1 bilhão, um preço jamais visto no setor de licenças livres. No dia 20 de Abril de 2009, foi anunciado que a Oracle compraria a Sun Microsystems e todos o seus produtos, incluindo o MySQL. Após investigações da Comissão Europeia sobre a aquisição para evitar formação de monopólios no mercado a compra foi autorizada e hoje a Sun faz parte da Oracle. O sucesso do MySQL deve-se em grande medida à fácil integração com o PHP incluído, quase que obrigatoriamente, nos pacotes de hospedagem de sites da Internet oferecidos atualmente. O MySQL hoje suporta Unicecode, Full Text Indexes , replicação, Hot Backup, GIS, OLAP e muitos outros recursos de banco de dados.
5.4.3.8 Banco de Dados Postgresql O PostgreSQL é um sistema gerenciador de banco de dados objeto relacional (SGBDOR), baseado no POSTGRES Versão 4.2 desenvolvido pelo Departamento de Ciência da Computação da Universidade da Califórnia em Berkeley. O POSTGRES, foi pioneiro em vários conceitos que somente se tornaram disponíveis muito mais tarde em alguns sistemas de banco de dados comerciais.
36/60
O PostgreSQL é um descendente de código fonte aberto deste código original de Berkeley. É suportada grande parte do padrão SQL:2003, além de serem oferecidas muitas funcionalidades modernas, como: • comandos complexos • chaves estrangeiras • gatilhos • visões • integridade transacional • controle de simultaneidade multiversão Além disso, o PostgreSQL pode ser estendido pelo usuário de muitas maneiras como, por exemplo, adicionando novos: • tipos de dado • funções • operadores • funções de agregação • métodos de índice • linguagens procedurais Devido à sua licença liberal, o PostgreSQL pode ser utilizado, modificado e distribuído por qualquer pessoa para qualquer finalidade, seja privada, comercial ou acadêmica, livre de encargos.
6
Metodologia A metodologia usada para a concepção desse projeto se alicerçará com o
referencial teórico aqui apresentado buscando o apoio nas melhores teorias e praticas que se aplicam no desenvolvimento de software livre através de uma fabrica de software. Buscaremos também nessas teorias o que melhor se adaptará as
37/60
necessidade do IFNMG, uma vez que já possui um ambiente de Tecnologia de Informação com suas próprias praticas. Na construção desse projeto de fabrica de software para desenvolvimento, implantação e adequação de software livre iremos desenvolver a partir dos próximos capítulos o modelo proposto para a implantação dessa fabrica de software no IFNMG. Trabalharemos uma nova metodologia com base em outras de maneira a melhor atender as necessidades do instituto em relação ao softwares já existentes e as demandas que surgiram.
7
Modelo Proposto O modelo que será proposto nesse capitulo buscará adequar as teorias e praticas
de engenharia de software em conjunto as teorias e praticas de uma fabrica de software no desenvolvimento, implantação e adequação de softwares em uma instituição de ensino médio técnico e superior da esfera federal. Esse modelo terá como objetivo inicial a adequação, aprimoramento e a criação de novas funcionalidades de softwares livres já em uso na instituição entre esses softwares estão: •
Gnuteca: Sistema para automação de todos os processos de uma biblioteca, independente do tamanho de seu acervo ou da quantidade de usuários.
•
SIGA-ADM (Sistema Integrado de Gestão Administrativa): Sistema para gestão administrativa de instituições publicas desenvolvido de forma colaborativa por várias instituições federais do Brasil.
•
SAGU (Sistema aberto de gestão unificada): uma solução criada para auxiliar no gerenciamento de instituições de Ensino Fundamental, Médio, Superior e Pós.
Apos o objetivo inicial alcançado o projeto se ampliará para o desenvolvimento de novas soluções de software para o atendimento de outras exigências do negocio e para tanto esse modelo proposto já constará de tudo que for necessário para essa
38/60
etapa de desenvolvimento de novas soluções. No modelo aqui proposto teremos um projeto de fabrica de software o qual terá por objetivo principal o desenvolvimento, implantação e adequação de softwares livres com base no desenvolvimento distribuído e uso de metodologias ágeis de forma a facilitar e agilizar as tarefas no desenvolvimento e adequação das soluções no entanto lançaremos mão das exigência das metodologias tradicionais no que diz respeito a documentação para que os softwares desenvolvido e/ou adequados não se tornem algo de difícil entendimento para outros desenvolvedores.
7.1 Descrição Geral do Modelo Proposto O modelo que será aqui apresenta tem como proposta um projeto de fábrica de software para atender as demandas internas do IFNMG com uma metodologia eficiente e ágil orientada ao negócio da instituição. Esse modelo consisti em adotar um processo de desenvolvimento de software baseado em componentes com métodos para avaliar o progresso, técnicas para acompanhar o andamento das atividades e ferramentas para otimizar a construção dos artefatos, tendo produtos desenvolvidos
com
qualidade
em
um
tempo
reduzido.
Visando
esse
desenvolvimento de qualidade e com tempo reduzido estaremos adaptando os principais pontos de uma metodologia de desenvolvimento ágil com a qualidade de documentação de uma metodologia de desenvolvimento tradicional bem como o uso dos atributos oriundos de uma fabrica formando uma nova metodologia a ser usada no projeto em questão. Com vistas a essa nova metodologia e os atributos vindos de uma fabrica de software, teremos alguns pontos importantes a seguir no desenvolvimento desse modelo proposto, que serão elencados a seguir: •
Estrutura organizacional: será analisada a estrutura existente e as mudanças para a adaptação a um modelo de fabrica de software.
•
Perfis funcionais: será descrito as funções necessárias ao desenvolvimento
39/60
de software bem como suas atribuições. •
Metodologia de desenvolvimento de software: será apresentada a metodologia a ser usada na fabrica.
•
Material de instrumentação: estaremos descrevendo as ferramentas que serão usadas em todos os processos de desenvolvimento de software bem como os treinamentos adquiridos e a serem adquiridos para das ferramentas e softwares em uso.
•
Plano de Processos: será definido e descrito as atividades para o desenvolvimento de cada processo aplicado a esse projeto de fabrica de software.
•
Demandas atuais: será descrito as demandas atuais de urgência e os procedimentos para atendê-las.
•
Cronograma: será apresentado um cronograma a ser seguido para a implantação da fabrica de software.
Nos próximos subcapítulos iremos descrever de forma detalhada aquilo que apresentamos de maneira geral nesse subcapítulo 7.1.
7.2 Detalhamento do Modelo Proposto Estaremos vendo agora com mais detalhes o modelo de Fabrica de Software proposto nesse projeto, para tanto iniciaremos fazendo um estudo da estrutura organizacional existente na Diretoria de Tecnologia da Informação do IFNMG, a qual apresentaremos uma nova estrutura juntamente com a inserção da estrutura para a implantação da Fabrica.
7.2.1
Estrutura organizacional
Apresentaremos agora a estrutura organizacional da Diretoria de Gestão de
40/60
Tecnologia de Informação (DGTI) do IFNMG e logo a seguir apresentaremos o modelo de estrutura organizacional necessário para a implantação da Fabrica de Software.
7.2.1.1 Estrutura organizacional Atual
Figura - 5
Organograma da DGTI do IFNMG
Fonte: Adaptado do regimento Geral do IFNMG. Na estrutura organizacional atual da DGTI estaremos apenas criando uma estrutura interna ao Núcleo de Projetos e Desenvolvimento de Sistema que esta subordinada a Coordenação de Sistemas de Informação de maneira a não mexer com a estrutura atual, pois é uma estrutura organizacional já aprovada no Regimento Geral da instituição. Nessa estrutura interna estaremos propondo um modelo organizacional para a Fabrica de Software a ser implantada.
7.2.1.2 Estrutura organizacional para modelo proposto
Figura - 6
Estrutura organizacional para o modelo proposto
41/60
A estrutura organizacional apresenta acima, para o modelo de fabrica de software, levou em consideração o reduzida numero de pessoal na TI do IFNMG buscando assim dividi-la em equipes responsáveis por cada software existente na instituição e que possuem uma prioridade alta nas suas demandas além de serem os principais softwares do negocio. Essas mesmas equipes ficaram responsáveis também pelo desenvolvimento de novos softwares ao passo que as demandas urgentes forem resolvidas. No ente da estrutura organizacional da figura 6 “Equipe de Desenvolvimento de Novos Software” apresentaremos outra estrutura organizacional interna a fabrica de software de maneira a mostrar as hierarquias de decisões e as etapas dos processo.
Figura - 7
Estrutura Organizacional de Decisões e Processos
Na estrutura mostrada na figura 7 temos um plano hierárquico de tomada de decisões, os entes externos que influenciam nas tomadas de decisões e os processos exigidos para cada parte do desenvolvimento do software. No topo da hierarquia está o Comitê Gestor de TI, que é formado por integrantes das próreitorias, diretorias e câmpus, ela é responsável para definir as prioridades das demandas da Fabrica de Software. No meio da produção temos os processos de pré-desenvolvimento (analise do negocio, gerenciamento de projetos, controle de mudanças e garantia de qualidade), o desenvolvimento (requisitos, projetos de arquitetura, construção, teste e implantação) e pós-desenvolvimento (suporte
42/60
técnico, infraestrutura, correção e controle de versões).
7.2.2
Perfis funcionais
Os perfis funcionais são a classificação das funções e a descrição das responsabilidades de cada função existente na organização da Fabrica de Software. A seguir apresentaremos uma tabela coma a classificação das funções e a descrição das responsabilidades de cada uma delas.
Perfil Funcional Descrição Gerente de Analise das necessidades do negocio. Negócios Gerente de
Gerenciamento dos riscos e das atividades em desenvolvimento
Projeto
devendo dimensionar e alocar os recursos necessários para realização das tarefas de forma satisfatória, além de interagir
Analista de Sistemas
com o cliente e o gerente de negócios. Levantamento de requisitos, análise, definição da arquitetura e documentação do sistema a ser desenvolvido.
Analista de
Revisão dos artefatos gerados, controle de mudanças, bem
Qualidade
como a definição e validação da qualidade e acurácia do
Engenheiro de
processo utilizado pela fábrica. Implementação do sistema conforme as especificações e
Software
documentação, seguindo o processo de desenvolvimento
Engenheiro de
definido. Desenvolvimento, validação e execução de testes de software
Testes
com o intuito de assegurar a qualidade e acurácia do software
produzido Líder de Equipe Coordenação e atribuição de tarefas dentro de um grupo específico, relatando periodicamente ao gerente de projetos o andamento das atividades. Tabela - 1 Perfis funcionais
43/60
É importante ressaltar que mais de uma função pode ser executada por uma mesma pessoa, possibilitando que a Fabrica aconteça mesmo com um numero limitado de integrantes.
7.2.3
Metodologia de desenvolvimento de software
Após o estudo feito e apresentado no referencial teórico desse trabalho especificaremos aqui a metodologia de desenvolvimento de software que melhor se adequará as necessidades e implantação da Fabrica de Software no IFNMG, lembrando que essa metodologia se aplicará ao desenvolvimento, adequação e implantação de software livre em um ambiente distribuído de desenvolvimento. Nessa perspectiva para um melhor atendimento as necessidades do IFNMG, construiremos uma metodologia de desenvolvimento que abranja os principais pontos do desenvolvimento ágil usados no SCRUM e as técnicas de documentações usadas no desenvolvimento tradicional. Visamos com essa metodologia atingir através do desenvolvimento ágil as principais demandas de caráter emergencial com rapidez e qualidade e por sua vez com o uso das técnicas de documentação, documentar todo o processo de desenvolvimento uma vez que se trata de uma instituição publica que necessita dos registros de sua atividades para que novos servidores possam continuar os processos sem nenhum prejuízo pela falta de documentação dos produtos existentes na instituição oriundos da Fabrica de Software. Estaremos agora descrevendo algumas politicas que definiram as diretrizes básicas a serem seguidas por todos os projetos da Fabrica de Software. Essas politicas serão voltadas para o desenvolvimento de software com características open source, desenvolvimento distribuído e descentralizado: •
Para novos softwares a serem criados o desenvolvimento será modular facilitando o desenvolvimento concorrente;
•
O desenvolvimento será fechado a instituição até que o software ganhe
44/60
consistência para depois ser liberado a comunidade externa; •
•
Quaisquer adequações do produto será interativa e incremental; A revisão e inspeção do código deveram serem realizadas pelo líder de equipe;
•
Os requisitos serão oriundos da necessidade do negocio. O usuários do negocio com os analistas de requisitos, coletivamente, definiram as funcionalidades do software e o comitê gestor analisará a viabilidade e definirá as demandas emergenciais.
•
Ferramentas de controle de versão e comunicação serão necessárias para a boa comunicação entre a equipe. O projeto deve ter um repositório gerenciado para armazenamento de documentação e código fonte;
•
A forma de comunicação principal será assíncrona uma vez que a equipe estará geograficamente distribuída;
•
A informação será compartilhada a través de ferramentas de gerenciamento de projetos com uso de listas de discursarão, fóruns, wikis, reportagem de erros, solicitação de novos requisitos e etc;
•
A liderança será centralizada na reitoria do instituto;
A partir dessas diretrizes iremos agora desenvolver a metodologia proposta para a Fabrica de Software. Com o uso das principais técnicas da metodologia ágil SCRUM iremos definir alguns conceitos usados no modelo proposto e relacioná-los com os perfis funcionais da fabrica: •
Demandas: são os serviços e tarefas requisitadas pelos usuários e participantes do negocio via ferramenta de gerencia de projeto, através de fóruns, relatórios ou pedidos.
•
Analista de demandas (gerente de negócios, gerente de projetos e analista de sistemas): é responsável pela busca ou recepção de demandas analise dos requisitos e produção de relatórios de demandas a serem
45/60
apresentados ao comitê gestor. •
Comitê gestor (analise de sistemas e analise de qualidade): avalia a viabilidade das demandas e elenca as prioridades.
•
Equipes de desenvolvimento (engenheiros de software, engenheiros de teste e líder de equipes): nesta faze o produto estará sendo implementado por cada equipe a que corresponde a tarefa, para tanto é necessário a existência do líder de equipe para estar junto ao desenvolvimento nas tarefas de planejamento, acompanhamento e motivação da equipe.
•
Backlog: nome dado as tarefas e serviços pendentes.
•
Sprint: são as atividades a serem desenvolvidas em um período de tempo de funcionamento da Fabrica.
Para melhor entendermos o funcionamento dessa metodologia segue na figura abaixo o fluxo do processo SCRUM para o modelo aqui apresentado.
Figura - 8
Visão geral do processo SCRUM no modelo proposto
A metodologia aqui proposta tem como base principal a metodologia ágil SCRUM, através do usuário do negocio obtêm-se a demanda ( Product Backlo) que é registrada em uma ferramenta de gerencia de projetos, após registrada a demanda
46/60
um analista as analisa e produz relatórios para ser apresentados ao Comitê Gestor de TI, o comitê verifica a viabilidade e elenca as prioridades, essas prioridades são encaminhadas para o sprint de planejamento, a qual definirá o prazo de entrega da funcionalidade e a divisão das demandas para depois serem encaminhadas as equipes de desenvolvimento correspondente aquela demanda. Nesse ponto começa o carro chefe da SCRUM, as sprint’s diárias e a sprint do mês tempo limite para execução da tarefa apresentado na figura 8 (o tempo limite é definido na sprint de planejamento. Após o desenvolvimento da tarefa no tempo limite a nova funcionalidade e encaminhada para a sprint de planejamento para uma avaliação e aprovação para ser implementada, depois de aprovada os lideres de equipes se encarregaram no desenvolvimento da documentação a partir dos dados obtidos nas ferramentas de apoio usadas no desenvolvimento da demanda. Depois de conhecido a metodologia proposta para esse modelo de Fabrica de Software, iremos conhecer os materiais de instrumentações que serão utilizados na produção pelas equipes da Fabrica.
7.2.4
Material de instrumentação
Estaremos agora apresentando os materiais de instrumentação que serão usados no modelo proposto de Fabrica de Software, esse materiais foram escolhidos levando em consideração o referencial teórico desse trabalho, o ambiente distribuído, o uso de softwares livres para a produção de softwares livres, a existência de softwares já em uso para desenvolvimento pela equipe de TI do instituto e as soluções de softwares livres que são usados no negocio do IFNMG na atualidade (SIGA, GNUTECA, SAGU e etc.). As tecnologias que serão empregadas pela fábrica foram definidas com base as necessidades já apresentadas e de acordo com as categorias: •
Ferramentas de desenvolvimento;
•
Ferramentas de gerenciamento de projetos;
•
Ferramenta de repositório e controle de versão;
•
Ferramentas para comunicação entre os participantes e disseminação do
47/60
conhecimento; e •
Sistema gerenciador de banco de dados.
7.2.4.1 Ferramentas de desenvolvimento Devido a maioria dos softwares usados pela instituição serem web e a internet ser umas das tecnologias que mais ganhou força nos últimos anos em relação ao desenvolvimento de aplicações para pequenas, media e grandes empresas optou-se pelo uso da linguagem PHP, por ser uma linguagem open source e de fácil uso e de grande utilização por desenvolvedores web, nos fornecendo assim um vasto numero de tutoriais, manuais e fóruns de discussões dessa linguagem. Para apoio dessa linguagem e objetivando o desenvolvimento orientado a objetos usaremos o Framework MIOLO, também por ser a base de todos sistemas mais utilizados no IFNMG no momento, como o Sistema Acadêmico SAGU, o administrativo SIGA-ADM e o de gerenciamento de Biblioteca o GNUTECA. E como ambiente de desenvolvimento será usado o NetBeans um IDE integrado gratuito e de código aberto para desenvolvedores de software, de facil instalação, uso e muiti plataforma podendo ser executado no Windows, Linux, Solaris e MacOS.
7.2.4.2 Ferramentas de gerenciamento de projetos Como ferramenta de gerencia de projetos estaremos utilizando o Redmine uma aplicação web de gerenciamento flexível de projetos, que é independente de plataforma e independente de banco de dados e já é utilizada no departamento de TI do instituto. Essa ferramenta nos auxiliará em
gerenciamento de Bugs, notícias, arquivos,
documentos, linha do tempo de todos os projetos; criação de fóruns de discussão, wiks, tarefas; além de ter uma grande integração com os principais repositórios e
controladores de versão.
48/60
7.2.4.3 Ferramenta de repositório e controle de versão A ferramenta escolhida para repositório e controle de versão é o Subversion, que é uma ferramenta de controle de versão muito poderosa que permite, além do desenvolvimento colaborativo a partir de um repositório único, possibilita armazenamento de logs e geração de estatísticas diversas e sua licença é open source nos moldes da licença Apache/BSD.
7.2.4.4 Ferramentas para comunicação Para a comunicação será utilizado o além do próprio Redmine com seus fóruns e salas de vídeo conferencia, o e-mail institucional e o mensageiro instantâneo Spark. Com essas ferramentas poderemos realizar as comunicações necessárias e as reuniões de sprint.
7.2.4.5 Sistema gerenciador de banco de dados O SGBD escolhido será o PostgreSQL um sistema gerenciador de banco de dados
objeto-relacional
(SGBDOR),
de
licença
livre
e
que
suporta
o
desenvolvimento de aplicações de grande porte. E um dos motivos também por essa escolha esta na questão de que os sistemas SAGU, SIGA-ADM e GNUTECA principais sistemas da instituição são modelados com esse banco de dados.
7.2.5
Plano de Processos
No plano de processos estaremos detalhando cada fase da metodologia, mostrando o fluxo das atividades a serem desenvolvidas, os artefatos que devem ser produzidos e seus perfis funcionais responsáveis pela geração de tais materiais . A seguir teremos uma tabela que nos mostrará as atividades definidas no plano de processo:
49/60
Atividades Responsável Artefato Levantar as necessidades do I de T Gerente de Relatório usuário Projetar a viabilidade das
Pré
Desenvolvimento demandas e prioridades Levantamento de requisitos da demanda
Analista
Definir o Backlog
Planejar,
Desenvolvimento
motivar
equipe
desenvolvimento e realizar as
as as
Sprints,
Líder de Equipe
Executa testes necessários para avaliação do código que Engenheiro
Relatório
de
tarefas Relatório
de
de testes
está sendo implementado e Teste
e
aprovação da
validação da funcionalidade
funcionalidade Líder de Equipe Produção da
Documentação
e
Suporte técnico
Desenvolvimento
requisitos Lançar
responsáveis Relatório de
Sprints necessárias
Pós
prioridades Relatório de
equipes
e de
demandas Relatório de
de tarefas
sistema
acompanhar a
e d Negocio r o t s Gerente de e G Projeto ê t i m Analista de o C Sistemas
Correção
Sistemas Equipe
de documentação de Relatório
de
desenvolvimento suporte Equipe de Relatório
de
desenvolvimento correções Administrador do Relatório de
Controle de versões
Tabela - 2
Analista
Subversion
e versões
Líder de Equipe Atividades do Plano de Processos
50/60
A partir da tabela de atividades montadas apresentaremos agora o detalhamento do plano de processo de desenvolvimento para a Fabrica de Software. O processo será detalhado com informações suficientes para uma boa compreensão das de suas fase que será dividido em cinco fases:
Fase 1 – Processo de recebimento de serviço •
O usuário solicita a demanda ( Backlog ) pelo Redmine ou via Gerente de Negócio.
•
A demanda é submetida ao Comitê Gestor de TI que avalia a viabilidade e define as prioridades.
Fase 2 – Processo de entrada da demanda nas equipes de desenvolvimento •
É feita uma Sprint de Planejamento com gestores do projeto, analistas e
equipes para divisão das demandas e definição de tempo para a realização. •
Cada líder de equipe se reunião com sua equipe para definir as Sprints
diárias e a Sprint semanal, quinzenal ou mensal. •
A equipe verifica se a possibilidade de desmembrar a demanda em
pequenas tarefas. •
É realizado o primeiro Sprint da equipe onde será definindo a meta a ser
alcançado no tempo pré-determinado (semana, quinzena ou mês), de posse da meta o líder de equipe começa organizar as tarefas no ambiente de desenvolvimento estabelecendo o que cada desenvolvedor irá realizar visando sempre as qualidades individuais de cada um.
Fase 3 – Processo de produção •
A demanda definida pelo usuário, e pertencente à meta do Sprint é
51/60
atualizada nos sistemas de gerenciamento de projetos e disponibilizada no ambiente de desenvolvimento para cada equipe. •
Cada equipe começa o desenvolvimento da funcionalidade visando sua
meta, nesse ponto o líder de equipe fica responsável
de acompanhar o
desenvolvimento do projeto diariamente através de relatórios das Sprints diárias que deverão conter as seguintes perguntas: O que tem conseguido realizar desde a última Sprint diária? - O que vai ser Pronto até a próxima Sprint diária? Quais são os obstáculos que estão no seu caminho? •
A demanda é desenvolvida de acordo com as Sprint de planejamento
realizadas e as ferramentas de desenvolvimento existente na Fabrica de Software. •
Após a demanda ser implementada deverá ser disponibilizada para o
usuário na base teste onde o mesmo testará se a funcionalidade lhe atende ou o erro que tinha foi corrigido, além do usuário o gerente de teste testará a nova funcionalidade.
Fase 4 – Encerramento do processo •
Após finalizar o processo de teste da nova funcionalidade essa é
submetida a ultima Sprint de planejamento que avaliará o seu desenvolvimento e se é possível melhoria em nível de código, feito essa analise o produto é liberado ao usuário final e encerrado no ambiente de desenvolvimento. •
Nesse momento o líder de equipe com auxilio de um analista de sistema
começa a construção da documentação daquela funcionalidade ou correção através de relatórios tirado do ambiente de desenvolvimento e as diversas ferramenta utilizadas desde a criação da demanda ao encerramento da mesma.
52/60
Fase 5 – Satisfação do usuário •
O Líder de Equipe juntamente com o Gerente de Negócios estarão em
contado regularmente com o usuário após a implantação da funcionalidade verificando possíveis falhas e se está atendendo a necessidade do usuário. As cinco fases descritas acima representa o processo de desenvolvimento detalhado na fabrica de Software, desde a entrada da demanda, a produção até a entrega ao usuário final verificando a sua satisfação pelo produto final. Continuando o plano de processo iremos agora descrever algumas boas praticas de programação web, que as equipes de desenvolvimento deverão seguir, para termos uma boa padronização nos códigos e demais tarefas executada na produção.
Boas praticas na produção de Software Como boas devemos entender alguns padrões que deve ser seguido para que aja uma certo tipo de organização na estrutura do produto criado, aqui estaremos elencando
algumas
padronizações
que
deveram
ser
seguidas
pelos
desenvolvedores e mostrando que algumas ferramentas já escolhidas para o desenvolvimento já possui padrões que deveram ser seguido pelas equipes. Importante no desenvolvimento web é saber como é arquitetura de desenvolvimento a ser usada e como a Fabrica de Software se propôs a utiliza o framework
MIOLO que adota a arquitetura em camadas implementando o padrão
MVC (Model-View-Controller ) como podemos verifica na figura 9.
53/60
Figura - 9
Arquitetura em camada MVC.
A estrutura de diretórios no desenvolvimento de sistemas também será utilizada a de padrão do
framework MIOLO
que segue a seguinte estrutura:
-----(p.ex. /usr/local/miolo25) | +--- classes |
+--- contrib
|
+--- database
|
+--- doc
|
+--- etc
|
+--- extensions
|
+--- ezpdf
|
+--- flow
|
+--- model
|
+--- persistence
|
+--- pslib
|
+--- security
|
+--- services
|
+--- ui
|
+----+--- controls
|
+----+--- painter
|
+----+--- report
|
+----+--- themes
|
|
+--- miolo
|
|
+--- kenobi
|
|
+--- clean
|
|
+--- .....
|
+--- utils
54/60 | +--- docs +--- etc |
+--- miolo.conf
|
+--- mkrono.conf
+--- html |
+--- downloads
|
+--- images
|
+--- reports
|
+--- scripts
+--- locale +--- modules |
+--- admin
|
+--- modulo1
|
+--- modulo2
|
+--- ....
+--- var +--- db +--- log +--- report +--- trace
classes – contém as classes que formam o kernel do MIOLO classes/contrib – classes de terceiros, que podem ser usadas no framework.
classes/database – classes que implementam o acesso a banco de dados (a camada DAO – Data Acess Objects).
classes/doc – classes para geração da documentação. classes/extensions – classes que estendem a funcionalidade do framework, por herança ou composição de componentes existentes, mas que não fazem ainda parte do “core” do Miolo.
classes/etc – arquivos auxiliares, como o autoload.xml que define a localização dos arquivos que implementam as classes.
classes/ezpdf – classes da biblioteca ezPDF, para geração de arquivos PDF.
classes/flow – classes relacionadas ao fluxo de execução de uma requisição.
classes/model – classes relacionadas à camada Business.
55/60
classes/persistence – classes que implementam o mecanismo de persistência de objetos em bancos de dados.
classes/pslib – classes utilizadas para geração de arquivos PostScript. classes/security – classes relacionadas às tarefas de segurança (autenticação, autorização, criptografia, etc).
classes/services – classes utilitárias e de serviços gerais. classes/ui – classes relacionadas à interface com o usuário (controles, renderização html, relatórios em pdf).
classes/util – classes utilitárias. modules – contém um subdiretório para cada módulo do sistema. Cada módulo possui uma estrutura de diretórios pré-definida.
var/db – contém um banco de dados Sqlite para armazenamento de dados relativos à execução das aplicações.
var/log – contém os arquivos de logs gerados pelo MIOLO e pelos sistemas.
var/report – contém os arquivos PDF gerados pelas rotinas de reports. var/trace – contém os arquivos usados no processo de debug da aplicação.
locale – contém o sistema usado para internacionalização. etc/miolo.conf – arquivo principal de configuração do MIOLO. html – contém as páginas do sistema, bem como os subdiretórios para imagens, scripts e temas. Deve ser o único diretório visível via Web.
docs – textos de documentação.
Importante como boa pratica desenvolvimento esta a indentação dos códigos que deverá seguir o critério de 4 espaços por nível. As nomenclaturas de variáveis, classe, funções e objetos deverão seguir o padrão do framework MIOLO. A cada código acrescenta do ou modificado em uma aplicação em funcionamento deverá constar um comentário padrão que será: /** @ifnmg modificado/adicionado em “Data/hora” por “nome do desenvolvedor” um breve comentário sobre o que a
56/60 modificação/acréscimo faz**/. Essas são as praticas a serem usadas pelos desenvolvedores da Fabrica de Software proposta
7.2.6
nesse projeto.
Demandas atuais
A seguir teremos uma tabela com as principais demandas emergenciais parao inicio da Fabrica de Software no projeto SAGU.
Projeto SAGU – Demandas Emergenciais Demandas Descrição Calendário no oferecimento Não aparece o calendário do ultimo mês quando a de disciplina data final do período não abrange o mês todo Ativar o Botão Excluir do Quando se pesquisa uma disciplina oferecida não menu Disciplinas Oferecidas conseguimos excluí-la pelo botão de exclusão que aparece na coluna ações Problema no lançamento de No Sagu os professores podem lançar suas avaliações para obtenção de avaliações para dividirem a nota que eles devem nota
distribuir. Porém quando se lança varias avaliações o Sagu trabalha com sistema de média, e em nossos
Separar dados de campus
campus não temos este tipo de sistema. Melhorar a integração multi campus de maneira que um campus não veja e altere as informações de outro
campus Aproveitamento de disciplina Aproveitamento de disciplina equivalente de maneira automática não esta funcionando. Tabela - 3 Demandas Emergenciais
7.2.7
Cronograma Data
%
Atividade
Inicial 2012
Data
Mês
Mês
Mês
Mês
Mês
Final Março
Abril
Maio
Junho
Julho
2012
2012
2012
2012
2012
2012
Mês
Mês
Mês
Mês
Agosto Setembro Outubro Novembro 2012
2012
2012
2012
Semanas 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
100 Processo de concepção da Fabric a de Software
01/03
31/03
100 1º Etapa treinamento ( NetBeans, PHP, PostgreSQL) 23/04
28/04
100 2º Etapa treinamento ( Framework Miolo)
14/05
19/05
100 3º Etapa treinamento (Subversion, Redmine, Ireport ) 11/06
16/06
100 Pesquisa de bibliográficas de embasamento teórico
30/07
24/06
100 Produção do Projeto Fabrica de Software 50 Reuniões de Analise do Projeto 0
Implantação da Fabrica de Software
0
Inicio das atividades na Fabrica de Software
Legenda: Planejamento a nível imaginário
Atividades Executadas
Atividades a serem executadas
Inicio das atividades na Fabrica
Tabela - 4 Cronograma
5 7 / 6 0
58/60
8
Referencias Bibliográficas
Administrador
do
site
dotproject.
O
que
é
dotProject.
Disponível
em:
http://www.dotproject.com.br/o-que-e. Acesso em 08 agosto 2012.
BECK, Kent; FOWLER, Martin. Planning Extreme Programming. Reading, Estados Unidos: Addison Wesley, 2001, 190 p. BECK, Kent. Programação Extrema (XP) explicada: acolha as mudanças. In: Porto Alegre: Bookman, 2004. CARVALHO, Carlos A. De S. O uso dos Software Livres em Instituições Públicas
Municipais. Faculdade de Jaguariúna, 2005. Fernandes, Aguinaldo A. Teixeira, Descartes de S. Fábrica de Software. São Paulo: Atlas S. A., 2011. Oracle.
O
que
é
o
Java.
http://www.java.com/pt_BR/download/faq/whatis_java.xml
Disponível
em:
Acessado em 10 de
58/60
8
Referencias Bibliográficas
Administrador
do
site
dotproject.
O
que
é
dotProject.
Disponível
em:
http://www.dotproject.com.br/o-que-e. Acesso em 08 agosto 2012.
BECK, Kent; FOWLER, Martin. Planning Extreme Programming. Reading, Estados Unidos: Addison Wesley, 2001, 190 p. BECK, Kent. Programação Extrema (XP) explicada: acolha as mudanças. In: Porto Alegre: Bookman, 2004. CARVALHO, Carlos A. De S. O uso dos Software Livres em Instituições Públicas
Municipais. Faculdade de Jaguariúna, 2005. Fernandes, Aguinaldo A. Teixeira, Descartes de S. Fábrica de Software. São Paulo: Atlas S. A., 2011.
O
Oracle.
que
é
o
Java.
Disponível
em:
http://www.java.com/pt_BR/download/faq/whatis_java.xml. Acessado em 10 de agosto de 2012. PFLEEGER, Shari Lawrence. Engenharia de Software: teoria a prática. São Paulo: Prentice Hall, 2004. 535p. Pietro,
Alcides.
Gestão
de
Projetos.
Disponível
em:
http://www.miniwebcursos.com.br/curso_aprender/modulos/aula_4/artigos/gestao_pr ojeto.pdf . Acesso em 10 agosto 2012. Portal
do
Software
Publico.
O
que
é
o
SPB?
http://www.softwarepublico.gov.br /O_que_e_o_SPB. Acessado em 11 de agosto de 2012. Powered by Redmine © 2006-2012 Jean-Philippe Lang. Redmine. Disponível em: http://www.redmine.org/. Acessado 11 de agosto 2012. PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995. 1056 p. PRESSMAN, Roger S. Engenharia de Software, Sexta Edição. Editora
59/60
MCGrawHill: Porto Alegre, 2010. REMATAL, Adail Muniz. Feature-Driven Development: Descrição dos Processos.
[S.l], 2008. Disponível em: http://www.heptagon.com.br/fdd-estrutura. Acesso em 09 agosto 2012. SOARES, Michel S. Comparação Entre Metodologias Ágeis e Tradicionais para
o Desenvolvimento de Software. Revista de Ciência da Computação, Lavras, v. 3, n. 1, p 8-13, nov. 2004. SOFTWARE ENGINEERING INSTITUTE: SEI Report on Undergraduate Software Engineering
Education
(CMU/SEI-90-TR-003).
1990.
Disponível
http://www.sei.cmu.edu/publications/documents/90.reports/90.tr.003.html.
em: Acesso
em: 14 de agosto 2012.
SOLIS - Cooperativa de Soluções Livres. MIOLO - Framework para Desenvolvimento
de
Sistemas
em
PHP
com
POO.
Disponível
em:
http://www.solis.org.br/projetos/miolo. Acessado em 09 de agosto de 2012. SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003. 592 p.
Postgresql.
Sourceforge.Net.
Disponivel
em:
http://pgdocptbr.sourceforge.net/pg80/preface.html. Acessado em 11 de agosto de 2012. Targettrust. Java – Linguagem de Programação (Parte 1). Disponível em: http://www.targettrust.com.br/blog/java-linguagem-de-programacao-parte-1/. Acessado em 10 de agosto de 2012. The
PHP
Group.
O
que
é
PHP?
Disponível
em:
http://www.php.net/manual/pt_BR/intro-whatis.php. Acessado em 10 de agosto de 2012. TONSIG, Sérgio Luiz. Engenharia de software: análise e projeto de sistemas. São Paulo: Futura, 2003. 351 p. Universidade Federal Fluminense – PET-Tele. Tutorial de Introdução ao Python.
