tcc ucb nelson barros cavalcante
TRANSCRIPT
Pró Reitoria de Pós Graduação a DistanciaLato Sensu em Desenvolvimento de Sistemas em Software
Livre Trabalho de Conclusão de Curso
Projeto de Fabrica de Software para Desenvolvimento, Implantação e Adaptação de Softwares Livres do IFNMG
Autor: Nelson Barros Cavalcante JuniorOrientador: José Adalberto Facanha Gualeve
Montes Claros – MG2012
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 parcial para obtenção do certificado de
Especialista em Desenvolvimento de Sistemas.
Orientador: José Adalberto Facanha Gualeve
Montes Claros – MG2012
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 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
ResumoEste 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
AbstractThis 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 Software Livre
CEFET 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 Internet Protocol
FTP File Transfer Protocol
SGBD Sistema Gerenciador de Banco de Dados
SGBDOR Sistema Gerenciador de Banco de Dados Objeto-Relacional
SQL Structured Query Language
SIGA Sistema Integrado de Gestão Administrativa
SAGU Sistema aberto de gestão unificada
DGTI 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
Software, no qual podemos vislumbrar quatro escopos distintos, cada escopo
podendo ter atributos similares, mas com intensidade diferentes.(Fernandes e
Teixeira, 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 obter um 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ática, disciplinada, quantificável para o desenvolvimento, operação e
manutenção do software” (TONSIG apud IEEE,2003, pg 48). Uma outra 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 principais componentes da engenharia de software são elencados 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 procedimentos – que possibilita ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base 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: planejamento de projeto, análise de requisitos, codificação e teste. As
ferramentas são usadas como apoio automatizado ou semi-automatizado aos
métodos, como por exemplo: CASEs, CADs ou linguagens de programação
(Pressman, 1995). Por sua vez os procedimentos são o elo de ligação ente métodos
e ferramentas, definem a sequência em que os métodos serão aplicados, 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 de software busca-se organizar de forma coerente
processos de produção de software, e para uma fabrica de software os princípios da
engenharia é um consolidador do tratamento dessa produção visando o
desenvolvimento com eficácia e qualidade. Dentro desse capitulo apresentaremos
os principais conceitos de engenharia 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 processo de desenvolvimento que busca organizar as fases envolvidas na
produção do software. Para SOMMERVILLE (2001) o modelo não é uma descrição
definitiva, mas sim, uma representação abstrata do gerenciamento e
desenvolvimento do software (SOMMERVILLE, 2001). Na visão de Pfleeger (2004),
alguns modelos representam “receitas do caminho que o desenvolvimento de
software deveria seguir e outros são descritos do modo que o desenvolvimento do
software realmente é feito”(PFLEEGER, 2004, p 38).
Quando os modelos envolvidos no desenvolvimento do software são bem
definidos e organizados isso implica em uma maior qualidade aos processos e ao
próprio produto de software.
A seguir, apresentaremos resumidamente algumas das principais propostas de
modelos de desenvolvimento de software utilizadas pelas comunidades de
engenharia de software, e será dividida em duas abordagens a tradicional 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
muito elevados, o desenvolvimento do software era muito mais planejado e
documentado, pois, o acesso a computadores era limitado e não existiam
ferramentas de apoio.
Iremos abordar nesse capitulo três principais modelos de desenvolvimento de
software com o objetivo de exemplificar os modelos tradicionais: o Cascata, 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 feedback 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 por
funcionalidades especificas definidas no início de cada sprint.
Figura - 4 Representação Gráfica do Modelo ScrumFonte: http://scrumemacao.com.br/web/
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 framework 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) é uma
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 <?php e ?> 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çãoGerente de Negócios
Analise das necessidades do negocio.
Gerente de Projeto
Gerenciamento dos riscos e das atividades em desenvolvimento
devendo dimensionar e alocar os recursos necessários para
realização das tarefas de forma satisfatória, além de interagir
com o cliente e o gerente de negócios.Analista de Sistemas
Levantamento de requisitos, análise, definição da arquitetura e
documentação do sistema a ser desenvolvido.
Analista de Qualidade
Revisão dos artefatos gerados, controle de mudanças, bem
como a definição e validação da qualidade e acurácia do
processo utilizado pela fábrica.Engenheiro de
SoftwareImplementação do sistema conforme as especificações e
documentação, seguindo o processo de desenvolvimento
definido.Engenheiro de
TestesDesenvolvimento, validação e execução de testes de software
com o intuito de assegurar a qualidade e acurácia do software
produzidoLí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
Pré Desenvolvimento
Levantar as necessidades do
usuário
Com
itê G
esto
r de
TI Gerente de
Negocio
Relatório de
demandasProjetar a viabilidade das
demandas e prioridades
Gerente de
Projeto
Relatório de
prioridadesLevantamento de requisitos
da demanda
Analista de
Sistemas
Relatório de
requisitos
Desenvolvimento
Definir o BacklogAnalista de
sistema
Lançar as
tarefas as
equipes
responsáveisPlanejar, acompanhar e
motivar a equipe de
desenvolvimento e realizar as
Sprints necessárias
Líder de Equipe
Relatório de
Sprints,
Relatório de
tarefasExecuta testes necessários
para avaliação do código que
está sendo implementado e
validação da funcionalidade
Engenheiro de
Teste
Relatório de
testes e
aprovação da
funcionalidade
PósDesenvolvimento
Documentação
Líder de Equipe
e Analista de
Sistemas
Produção da
documentação
Suporte técnicoEquipe de
desenvolvimento
Relatório de
suporte
CorreçãoEquipe de
desenvolvimento
Relatório de
correções
Controle de versões
Administrador do
Subversion e
Líder de Equipe
Relatório de
versões
Tabela - 2 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:
-----<diretório–base>(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 nesse projeto.
7.2.6 Demandas atuais
A seguir teremos uma tabela com as principais demandas emergenciais parao
inicio da Fabrica de Software no projeto SAGU.
Projeto SAGU – Demandas EmergenciaisDemandas DescriçãoCalendário no oferecimento
de disciplina
Não aparece o calendário do ultimo mês quando a
data final do período não abrange o mês todoAtivar o Botão Excluir do
menu Disciplinas Oferecidas
Quando se pesquisa uma disciplina oferecida não
conseguimos excluí-la pelo botão de exclusão que
aparece na coluna açõesProblema no lançamento de
avaliações para obtenção de
nota
No Sagu os professores podem lançar suas
avaliações para dividirem a nota que eles devem
distribuir. Porém quando se lança varias avaliações o
Sagu trabalha com sistema de média, e em nossos
campus não temos este tipo de sistema.Separar dados de campus Melhorar a integração multi campus de maneira que
um campus não veja e altere as informações de outro
campusAproveitamento de disciplina Aproveitamento de disciplina equivalente de maneira
automática não esta funcionando.Tabela - 3 Demandas Emergenciais
7.2.7 Cronograma
% Atividade
Data
Inicial
2012
Data
Final
2012
Mês
Março
2012
Mês
Abril
2012
Mês
Maio
2012
Mês
Junho
2012
Mês
Julho
2012
Mês
Agosto
2012
Mês
Setembro
2012
Mês
Outubro
2012
Mês
Novembro
2012
Semanas1 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 Fabrica 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 24/06 30/07
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
57/60
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. 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 em:
http://www.sei.cmu.edu/publications/documents/90.reports/90.tr.003.html. 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.
Sourceforge.Net. Postgresql. 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.
60/60
Disponivel em:
http://www.telecom.uff.br/pet/petws/downloads/tutoriais/python/tut_python_2k100127.
pdf. Acessado em 10 de agosto de 2012.
Wikipédia. Kumbia PHP Framework. Disponível em:
http://pt.wikipedia.org/wiki/Kumbia_PHP_Framework. Acessado em 09 agosto de
2012.
Wikipédia. Zend Framework. Disponivel em:
http://pt.wikipedia.org/wiki/Zend_Framework. Acessado em 09 de agosto de 2012.
Wikipédia. Mysql. Disponível em: http://pt.wikipedia.org/wiki/MySQL. Acessado em
11 de agosto de 2012.