SISTEMA DE SUPORTE À GESTÃO DE ATIVIDADES E …
Transcript of SISTEMA DE SUPORTE À GESTÃO DE ATIVIDADES E …
FERNANDO AUGUSTO PEREIRA DA FONSECA
SISTEMA DE SUPORTE À GESTÃO DE ATIVIDADES E INTEGRAÇÃO DE
EQUIPES PARA EMPRESAS DE DESENVOLVIMENTO DE SOFTWARE
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciências da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Ciências da Computação.
Orientador: Prof. Dr. Oscar Ciro López.
Florianópolis
2009
FERNANDO AUGUSTO PEREIRA DA FONSECA
SISTEMA DE SUPORTE À GESTÃO DE ATIVIDADES E INTEGRAÇÃO DE
EQUIPES PARA EMPRESAS DE DESENVOLVIMENTO DE SOFTWARE
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Ciências da Computação e aprovado em sua forma final pelo Curso de Graduação em Ciências da Computação da Universidade do Sul de Santa Catarina.
Florianópolis, 08 de julho de 2009.
______________________________________________________ Professor e orientador Maria Inês, Dr. Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Oscar Ciro López, Dr. Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Marcelo Medeiros, Msc. Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Rafael Orivaldo Lessa, Esp. Universidade do Sul de Santa Catarina
AGRADECIMENTOS
Agradeço àquela que caminha ao meu lado desbravando aquilo que chamamos de
vida. Michele meu amor, vencemos mais uma. Muito obrigado!
“Muito do que chamamos gerenciamento consiste em dificultar o trabalho das
pessoas” (Peter Drucker).
RESUMO
O presente estudo monográfico constitui-se em uma proposta de sistema gestor para projetos e
equipes de desenvolvimento de software. Traz como eixo central a seguinte questão: É
possível criar um sistema que aborde as necessidades estratégicas, táticas e operacionais de
gestão de projetos de micro e pequenas empresas desenvolvedoras de softwares? A origem da
proposta baseia-se na experiência do autor no setor de desenvolvimento de software que
identificou uma carência de softwares gestores que atendam às necessidades desse,
principalmente no caso das micro e pequenas empresas. Através da construção de um cenário
com os principais envolvidos numa empresa de desenvolvimento de software e suas
necessidades de controle e gestão sobre os processos, foi elaborado um projeto de software
utilizando a abordagem por Casos de Uso, que foram codificados e validados, utilizando
tecnologias de código-livre e baseadas em ambiente web. Como resultado final obteve-se uma
ferramenta completamente operacional batizada pelo autor de RoadMap.
Palavras-chave: Gestão de Projetos, Empresas de Software.
ABSTRACT
This monographic study is a draft system for managing projects and teams of software
development. It brings the following question: Is it possible to create a system that meets the
needs strategic, tactical and operational of management projects of micro and small
companies of software development? The origin of the proposal is based on the author's
experience in the field of developing software that identified a lack of manager softwares that
meet the needs, particularly in the case of micro and small companies. Through the
construction of a scenario with the main actors involved in the software development and
their need for control and management of processes, a project was developed using a software
approach to Use Cases, which were consolidated and validated using technologies code-free
and web-based environment. As a final result obtained is a fully operational tool named
RoadMap by the author.
Keywords: Project Management, Software Companies.
LISTA DE ILUSTRAÇÕES
Figura 1. Processos de planejamento de projeto atendidos pelo trabalho ................................24 Figura 2. Atores envolvidos no Sistema RoadMap ..................................................................31 Figura 3. Casos de uso envolvidos no Sistema RoadMap........................................................32 Figura 4. Modelo de Estados das Atividades ...........................................................................36 Figura 5. Arquitetura Física do Sistema RoadMap ..................................................................43 Figura 6. Modelo de Navegação do Sistema ............................................................................57 Figura 7. Tela de Login ............................................................................................................58 Figura 8. Menu Principal ..........................................................................................................59 Figura 9. Lista de Atividades....................................................................................................60 Figura 10. Detalhe das colunas da Lista de Atividades Fonte: Autor ......................................61 Figura 11. Detalhe do timer de execução de atividades Fonte: Autor......................................61 Figura 12. Detalhe do status 'Em Execução' na Lista de Atividades Fonte: Autor ..................61 Figura 13. Detalhe dos filtros na Lista de Atividades Fonte: Autor.........................................62 Figura 14. Formulário de Inclusão/Edição de Atividades ........................................................62 Figura 15. Lista de Executores de uma Atividade....................................................................63 Figura 16. Formulário de Inclusão/Edição de Executor de uma Atividade..............................64 Figura 17. Formulário de Apontamento de Progresso..............................................................64 Figura 18. Formulário de Conclusão/Paralisação/Cancelamento/Reabertura de uma Atividade..................................................................................................................................................65 Figura 19. Lista de Execuções..................................................................................................66 Figura 20. Formulário de Inclusão/Edição de Execução..........................................................67 Figura 21. Tela de Resumo de Horas Executadas ....................................................................67 Figura 22. Lista de Tipos de Atividades...................................................................................68 Figura 23. Formulário de Inclusão/Edição de Tipos de Atividades .........................................69 Figura 24. Lista de Empresas ...................................................................................................70 Figura 25. Formulário de Inclusão/Edição de Empresas..........................................................70 Figura 26. Lista de Áreas..........................................................................................................71 Figura 27. Formulário de Inclusão/Edição de Áreas ................................................................72 Figura 28. Lista de Recursos ....................................................................................................73 Figura 29. Formulário de Inclusão/Edição de Recursos...........................................................74 Figura 30. Formulário de Alteração de Senha..........................................................................74 Figura 31. Menu de Gráficos Gerenciais..................................................................................75 Figura 32. Gráfico Percentual de Horas Executadas por Empresa...........................................76 Figura 33. Gráfico Percentual de Horas Executadas por Área .................................................77 Figura 34. Gráfico Percentual de Horas Executadas por Tipo .................................................78 Figura 35. Gráfico de Horas Executadas por Empresa/Mês.....................................................79
SUMÁRIO
1 INTRODUÇÃO..............................................................................................................................10 1.1 PROBLEMATIZAÇÃO ......................................................................................................................10 1.2 OBJETIVOS .....................................................................................................................................13 1.2.1 Objetivos Gerais.......................................................................................................................13 1.2.2 Objetivos Específicos ...............................................................................................................13 1.3 JUSTIFICATIVA...............................................................................................................................13 1.4 METODOLOGIA UTILIZADA ............................................................................................................14 1.5 ESTRUTURA DO TRABALHO...........................................................................................................17
2 REVISÃO BIBLIOGRÁFICA .....................................................................................................19 2.1 GERENCIAMENTO DE PROJETOS ....................................................................................................19 2.2 ENGENHARIA DE SOFTWARE .........................................................................................................25
3 SISTEMA ROADMAP DE GESTÃO DE EQUIPES E PROJETOS.......................................28 3.1 RELAÇÃO DAS NECESSIDADES E STAKEHOLDERS..........................................................................28 3.1.1 Diretor de Desenvolvimento....................................................................................................28 3.1.2 Gerente de Projetos..................................................................................................................29 3.1.3 Equipe de Desenvolvimento ....................................................................................................29 3.2 CARACTERÍSTICAS DO SISTEMA ....................................................................................................30 3.2.1 Baseado em Ambiente WEB ...................................................................................................30 3.2.2 Gerenciamento de Projetos, Sub-Projetos e Atividades .......................................................30 3.2.3 Indicadores Gerenciais ............................................................................................................30 3.3 CASOS DE USO DO SISTEMA ...........................................................................................................31 3.3.1 Caso de Uso: Consultar Atividades e Projetos ......................................................................32 3.3.2 Caso de Uso: Executar Atividades..........................................................................................33 3.3.3 Caso de Uso: Apontar Progresso ............................................................................................33 3.3.4 Caso de Uso: Gerenciar atividades.........................................................................................34 3.3.5 Caso de Uso: Alterar o status das Atividades........................................................................35 3.3.6 Caso de Uso: Designar executores e estimar esforço ............................................................37 3.3.7 Caso de Uso: Manter Cadastro de Tipos de Atividades .......................................................37 3.3.8 Caso de Uso: Empresas ...........................................................................................................38 3.3.9 Caso de Uso: Manter Cadastro de Áreas...............................................................................38 3.3.10 Caso de Uso: Manter Cadastro de Tipos de Recursos..........................................................38 3.3.11 Caso de Uso: Consultar Gráficos de Desempenho................................................................39 3.4 ARQUITETURA E FERRAMENTAS UTILIZADAS ...............................................................................40 3.4.1 Linguagem de Programação PHP ..........................................................................................40 3.4.2 Banco de Dados MySQL .........................................................................................................41 3.4.3 Framework MorphpWeb ........................................................................................................41 3.4.4 UML (Unified Modeling Language).......................................................................................42 3.4.5 Arquitetura Física....................................................................................................................42 3.5 HISTÓRICO DO DESENVOLVIMENTO ..............................................................................................43 3.6 DESCRIÇÃO DA ITERAÇÃO DO PACOTE 2 - FUNCIONALIDADES BÁSICAS DE GESTÃO DAS
ATIVIDADES ...........................................................................................................................................46 3.6.1 Detalhamento da Modelagem .................................................................................................46 3.6.1.1 Caso de Uso Consultar Projetos e Atividades.........................................................................46 3.6.1.2 Caso de Uso Gerenciar Atividades .........................................................................................48 3.6.1.3 Caso de Uso Alterar Status da Atividade................................................................................51 3.6.2 Implementação da Funcionalidade ........................................................................................52 3.6.3 Testes e Correções....................................................................................................................52 3.6.3.1 Caso de Teste Consulta da Lista de Atividades ......................................................................53
3.6.3.2 Caso de Teste Aplicação de Filtro na Lista de Atividades......................................................53 3.6.3.3 Caso de Teste Detalhar uma Atividade...................................................................................54 3.6.3.4 Caso de Teste Inclusão de uma Nova Atividade.....................................................................54 3.6.3.5 Caso de Teste Edição de uma Atividade.................................................................................54 3.6.3.6 Caso de Teste Exclusão de uma Atividade .............................................................................55 3.6.3.7 Caso de Teste Dados informados na inclusão da atividade são inválidos ..............................55 3.6.3.8 Caso de Teste Dados informados na edição da atividade são inválidos .................................55 3.7 O SISTEMA ROADMAP....................................................................................................................57 3.7.1 Modelo de Navegação do Sistema RoadMap.........................................................................57 3.7.2 Telas do Sistema RoadMap.....................................................................................................58 3.7.2.1 Tela de Login ..........................................................................................................................58 3.7.2.2 Menu Principal........................................................................................................................59 3.7.2.3 Lista de Atividades .................................................................................................................60 3.7.2.4 Formulário de Inclusão/Edição de Atividades ........................................................................62 3.7.2.5 Lista de Executores de uma Atividade....................................................................................63 3.7.2.6 Formulário de Inclusão/Edição de Executor de uma Atividade..............................................63 3.7.2.7 Formulário de Apontamento de Progresso..............................................................................64 3.7.2.8 Formulário de Conclusão/Paralisação/Cancelamento/Reabertura de uma Atividade.............64 3.7.2.9 Lista de Execuções..................................................................................................................65 3.7.2.10 Formulário de Inclusão/Edição de Execução........................................................................66 3.7.2.11 Tela de Resumo de Horas Executadas ..................................................................................67 3.7.2.12 Lista de Tipos de Atividades.................................................................................................68 3.7.2.13 Formulário de Inclusão/Edição de Tipos de Atividades .......................................................68 3.7.2.14 Lista de Empresas .................................................................................................................69 3.7.2.15 Formulário de Inclusão/Edição de Empresas........................................................................70 3.7.2.16 Lista de Áreas .......................................................................................................................71 3.7.2.17 Formulário de Inclusão/Edição de Áreas ..............................................................................71 3.7.2.18 Lista de Recursos ..................................................................................................................72 3.7.2.19 Formulário de Inclusão/Edição de Recursos.........................................................................73 3.7.2.20 Formulário de Alteração de Senha........................................................................................74 3.7.2.21 Menu de Gráficos Gerenciais................................................................................................75 3.7.2.22 Gráfico Percentual de Horas Executadas por Empresa.........................................................76 3.7.2.23 Gráfico Percentual de Horas Executadas por Área...............................................................77 3.7.2.24 Gráfico Percentual de Horas Executadas por Tipo ...............................................................78 3.7.2.25 Gráfico de Horas Executadas por Empresa/Mês...................................................................79 3.8 VALIDAÇÃO ...................................................................................................................................80
4 CONCLUSÃO................................................................................................................................81
REFERÊNCIAS ...................................................................................................................................83
10
1 INTRODUÇÃO
Neste capítulo serão abordados alguns aspectos que caracterizam e justificam o
trabalho realizado. Previamente, o contexto do trabalho é apresentado para que se tenha um
entendimento mais preciso do porquê da especificação e desenvolvimento de um sistema de
suporte à gestão de atividades e integração de equipes para empresas de desenvolvimento de
software.
Uma descrição prévia dos objetivos do trabalho e a metodologia usada para a
execução do mesmo também estarão contempladas.
1.1 PROBLEMATIZAÇÃO
O processo atual de desenvolvimento de software é uma atividade complexa que
envolve inúmeros fatores que não raramente tornam difícil o controle dos processos. Mesmo
com a existência de várias metodologias específicas para a área, o que ainda se vê é uma
desorganização e informalidade nos processos. Paula Filho (2003, p.13) salienta que “os
projetos não são definidos com clareza, as pessoas não recebem o treinamento necessário, as
ferramentas não ajudam realmente a resolver problemas e os procedimentos e padrões,
quando existem, são definidos e seguidos de forma burocrática”.
A dificuldade do processo provém da própria complexidade do software, onde
segundo Paula Filho (2003, p.16) “mesmo pequenos sistemas têm uma enorme
complexidade”. Paula Filho (2003, p.16) ainda completa, “cada linha de código é como se
fosse uma peça móvel de um mecanismo: pode abrigar um defeito fatal para o sistema”.
De acordo com Bezzera (2002, p.21):
A complexidade corresponde à sobreposição das complexidades relativas ao desenvolvimento dos seus componentes: software, hardware, procedimentos, etc. Isso se reflete no alto número de projetos de software que não chegam ao fim, ou extrapolam recursos de tempo e de dinheiro alocados.
11
Martins (2006, p.34) é enfático quando diz que “muitos projetos para
desenvolvimento de software falham devido a falta de planejamento ou do controle durante a
execução dos trabalhos”.
Não é difícil observar que boa parte dos problemas no desenvolvimento de
software são causados na fase de planejamento ou durante o controle das atividades.
Estatisticamente os dados referentes aos resultados dos projetos de
desenvolvimento de sistemas já foram levantados pelo Standish Group em seu relatório Chaos
publicado em 1994 (STANDISH, 2008). Segundo este relatório:
• Porcentagem de projetos que terminam dentro do prazo estimado: 10%;
• Porcentagem de projetos que são descontinuados antes de chegarem ao
fim: 25%;
• Porcentagem de projetos acima do custo esperado: 60%;
• Atraso médio nos projetos: 1 ano;
O SEI (Software Engineering Institute) em 1993 observou que a causa dos
problemas que afligem as empresas de desenvolvimento de software está enraizada na própria
cultura gerencial, conforme Paulk (1993) “as organizações precisam vencer o seu buraco
negro que é o seu estilo de gerenciar de maneira informal, sem métodos e sem técnicas”.
Estas necessidades de melhoria no processo de gestão e controle não são
exclusividade das grandes empresas. Para se manterem competitivas as micro e pequenas
empresas também devem adotar modelos de gerenciamento de suas equipes e processos.
Inclusive Johannesen (2004) ressalta que são justamente as empresas de pequeno porte que
mais necessitam formalizar seus procedimentos de gestão e controle de projetos.
No Brasil, conforme pesquisa de 2005 do Ministério da Ciência e Tecnologia que
avalia as características das empresas de software brasileiras, 77% das empresas de software
são representadas por micro (até 9 funcionários) e pequenas (de 10 a 49 funcionários), ou seja,
a melhoria de qualidade do software nacional passa necessariamente pelo amadurecimento
desta massa de empresas de pequeno porte (MPS.BR, 2006).
Apesar do quadro desalentador iniciativas estão sendo tomadas pelas empresas
visando fornecer sistemas com maior qualidade, para assim assegurar a competitividade e
sobrevivência da organização (INTHURN, 2001, p.3).
12
Uma das saídas propostas é a adoção de ferramentas que auxiliem as empresas de
desenvolvimento de software na integração do trabalho em equipe e no gerenciamento do
andamento do projeto (BEZERRA, 2002, p.38). Segundo Paula Filho (2003, p.61) o retorno
da adoção dessas ferramentas é na ordem de 1.300 vezes o valor investido.
Porém não é a simples adesão de uma ferramenta que irá resolver os problemas de
desenvolvimento de software de uma empresa. Sobre este assunto Conallen (2003, p.103)
alerta: “Se você está procurando uma receita pronta para o sucesso, esqueça”. A perícia e a
capacidade de todos envolvidos no projeto refletem diretamente no andamento do projeto,
mas a combinação de um processo robusto com uma equipe competente pode fazer com que o
desenvolvimento seja repetitivo e confiável (CONALLEN, 2003, p.103).
Inthurn (2001, p.11) cita três elementos fundamentais ao processo de
desenvolvimento de software:
• Métodos;
• Procedimentos;
• Ferramentas;
Vê-se, portanto, que a adoção de ferramentas de gestão não é algo que resolva de
forma individual os problemas relativos ao desenvolvimento de software, nem são garantia
que assegurem uma melhor qualidade dos produtos construídos pela equipe, porém a adoção
destas é uma prática indispensável para a implantação de um processo de desenvolvimento
mais maduro.
Estas ferramentas já estão disponíveis aos gestores das empresas, porém nem
sempre as ferramentas possuem o escopo e a dimensão apropriada para atender a cada caso
apresentado nas empresas (QUADROS, 2002, p.220).
Independente do modelo utilizado para melhorar os processos, uma das
necessidades fundamentais para sua implantação é suportá-lo por um software específico que
auxilie na administração e gerencia dos processos, não apenas como uma ferramenta gestora
de atividades, mas sim como uma ferramenta que aborde as necessidades estratégicas, táticas
e operacionais da empresa, possuindo funcionalidades que integrem as equipes e traga
benefícios diretos à todos os níveis hierárquicos da empresa.
É possível criar um sistema que aborde as necessidades estratégicas, táticas e
operacionais de gestão de projetos de micro e pequenas empresas desenvolvedoras de
softwares?
13
1.2 OBJETIVOS
1.2.1 Objetivos Gerais
Desenvolver um sistema para micro e pequenas empresas desenvolvedoras de
softwares com o objetivo de dar suporte estratégico, tático e operacional aos processos de
gestão de projetos de desenvolvimento de software.
1.2.2 Objetivos Específicos
• Modelar o sistema utilizando metodologia específica para a indústria de
software.
• Desenvolver o sistema em ambiente web.
• Permitir a possibilidade de resolver o problema de falta de visibilidade nos
processos de desenvolvimento.
1.3 JUSTIFICATIVA
Tendo mais de 10 anos de experiência no setor de desenvolvimento de software,
trabalhando sempre em empresas de pequeno porte, participando de maneira direta nos
processos de coordenação e controle de equipes de desenvolvedores, o autor pode afirmar que
há uma carência de softwares gestores que atendam às necessidades das MPEs de software.
14
Dentre os problemas dessas empresas Roullier (2001) elenca:
• A dinamicidade do processo dificulta o gerenciamento;
• Alterações constantes no projeto;
• Redistribuição de atividades;
• Adaptação de cronogramas;
• Realocação de recursos;
• Novos acordos com clientes;
• Entregas intermediárias não previstas.
Diferentemente das empresas de médio e grande porte, as micro e pequenas
empresas de software necessitam de uma ferramenta que contemplem suas características
específicas: comunicação simples, processos instáveis, necessidade de agilidade,
inexperiência na área de engenharia de software, recursos limitados, etc (WEBER, 2005).
Assim há um nicho específico para um sistema que traga os benefícios
estratégicos, táticos e operacionais para empresas de pequeno e médio porte que ainda não
estejam com seus processos num nível desejável de maturidade.
Além disso, há a questão profissional. Independente dos cursos de pós-graduação
e das certificações existentes na área de gestão de equipes e projetos, o confecção de um
sistema focado na liderança e gestão de equipes que atenda a todos os níveis de uma empresa
de desenvolvimento de software poderia abrir muitas portas, além de ser um diferencial
exclusivo frente a outros profissionais.
1.4 METODOLOGIA UTILIZADA
O trabalho de conclusão de curso foi realizado através da descrição e análise dos
processos relativos ao assunto abordado, antecedendo ao desenvolvimento de um software
que solucione o problema levantado.
15
Conforme Severino (2002) a preparação metodológica de um trabalho científico
supõe uma seqüência de 5 etapas:
• Determinação do tema-problema do trabalho;
• Levantamento da bibliografia referente a esse tema;
• Leitura e documentação dessa bibliografia após seleção;
• Construção lógica do trabalho;
• Redação do texto.
Tomando como base as etapas citadas por Severino, o acadêmico dividiu e
organizou seu trabalho da seguinte forma:
Etapa I – Conceituação do problema
Nesta etapa o acadêmico delineou a introdução da monografia. Barros (2000)
afirma que “a introdução justifica o tema, explicita o objetivo, clarifica os temos utilizados,
faz-se uma exposição metodológica, situa-se no tempo e espaço o tema-problema estudado”.
Etapa II – Levantamento e estudo bibliográfico
Nesta etapa o acadêmico realizou estudos teóricos através de pesquisa de pesquisa
bibliográfica e documental, como livros, textos científicos, periódicos e sites da internet.
Andrade (1998) divide a pesquisa bibliográfica em escolha e delimitação do tema,
coleta de dados, localização das informações, documentação dos dados, seleção do material,
plano de trabalho, redação das partes, leitura crítica e organização da bibliografia.
Segundo Rauen (2002) as informações contidas em determinada obra
bibliográfica podem ser primárias ou secundárias.
As informações primárias advém do texto original, baseado em pesquisa ou fruto
da criatividade, compreendendo monografias, relatórios, ensaios, dissertações, testes, livros,
periódicos científicos, entre outros.
As informações secundárias são consideradas de segunda mão, isto é, retiradas de
outras fontes. Compreendem as obas de referencias, como enciclopédias, dicionários,
anuários, livros bibliográficos, etc.
16
Rauen (2002) salienta que se deve evitar buscar informações em fontes
secundárias para textos científicos.
Etapa III – Construção e organização lógica do trabalho
Nesta etapa o acadêmico analisou o problema proposto construindo o trabalho a
partir da contribuição teórica do material bibliográfico levantado na etapa anterior.
Para Barros (2000) “na construção de um trabalho científico, algumas questões
prévias devem ser levadas em conta pelo estudioso, ou seja, atentar para a necessidade de
planejá-lo e ordená-lo com base em uma estrutura lógica de pensamento e apresentação”.
O acadêmico utilizou nesta etapa uma estrutura de construção baseada nos
processos de desenvolvimento de sistemas utilizados atualmente. Segundo Leme Filho (2003)
os macro-processos são independentes de metodologia, logo todas as metodologias de uma
forma ou outra abordam os mesmos processos, apenas utilizam um enfoque diferenciado.
Para Leme Filho (2003) tais processos são:
• Analise;
• Projeto;
• Construção;
• Homologação;
• Implantação;
• Manutenção;
Por se tratar de um sistema que propõe o desenvolvimento da solução, o trabalho
não entrou no mérito dos processos de implantação e manutenção.
Durante a analise foi elaborado uma proposta de solução que envolva aspectos de
negócio e aspectos técnicos (LEME FILHO, 2003).
No projeto do sistema houve a adequação das funcionalidades levantadas na
analise com o ambiente técnico do sistema (LEME FILHO, 2003). Segundo Bezzera (2005)
“na fase de projeto determina-se como o sistema funcionará para atender aos requisitos
levantados na análise”. A solução foi descrita através da UML (Unified Modeling Language),
definida por Conallen (2003) como “uma notação para descrever visualmente os modelos de
sistemas de software”.
17
Após analisado e projetado, o sistema será codificado na fase de construção
conforme a especificação criada (LEME FILHO, 2003).
Para finalizar o sistema, este passa por um processo de homologação, com a
organização de um conjunto de testes que serão aplicados ao sistema para verificar sua
qualidade e alinhamento com a especificação inicial.
Etapa IV – Redação do texto
Nesta etapa o acadêmico redigiu o conteúdo levantado, estudado e organizado nas
etapas anteriores, respeitando o formato científico necessário para a monografia.
Rauen (2002) aponta as seguintes características do texto científico:
• É técnico;
• Aborda as ciências;
• Objetiva comprovar verdades científicas;
• Transmite mensagem racional;
• Emprega palavras como simples instrumento de transmissão de idéias –
valor denotativo;
• Usa o nível padrão culto de linguagem; e
• Pressupõe o estilo técnico – denotação, objetividade, simplicidade,
formalização precisão, clareza, coerência e harmonia.
1.5 ESTRUTURA DO TRABALHO
O desenvolvimento do trabalho foi organizado em quatro capítulos, sendo o
primeiro constituído por essa introdução. O segundo capítulo aborda os principais temas
envolvidos no processo de modelagem e desenvolvimento da solução, sendo utilizado como
base teórica para embasamento das funcionalidades implementadas.
No terceiro capítulo buscou-se compreender como se caracteriza a solução
desenvolvida para os objetivos apresentados no primeiro capítulo, através do levantamento
18
das necessidades dos principais envolvidos na problemática, concepção das características
fundamentais do sistema proposto e elaboração de um modelo baseado em casos de uso para
compreender a interação entre os usuários e o sistema. No presente item ainda pretende-se
expor as interfaces desenvolvidas para o sistema bem como o procedimento de teste e
correção realizados.
Já o quarto capítulo é formado pelas considerações finais deste estudo,
evidenciando os resultados analíticos e reflexivos obtidos pelo processo de estudo e
desenvolvimento da solução proposta.
19
2 REVISÃO BIBLIOGRÁFICA
2.1 GERENCIAMENTO DE PROJETOS
Dentre as diversas atividades desenvolvidas por uma empresa, com relação a sua
natureza Menezes (2007) as divide em dois tipos: Atividades Rotineiras, que procuram manter
um procedimento rígido para atingir um resultado padrão, e Projetos, que são pouco ou quase
nada rotineiras, buscando um resultado inovador.
Segundo Martins (2006) “genericamente projeto significa empreendimento, e
como tal é um trabalho que visa a criação de um produto ou a execução de um serviço
específico, temporário, não repetitivo e que envolve um certo grau de incerteza na
realização.”
Muitos processos operacionais das empresas possuem similaridades com os
projetos, mas estes se diferem por serem temporários e únicos (XAVIER, 2005).
A definição de um projeto é clara quando menciona ter um início e fim bem
definidos. Isto nos leva a identificar um Ciclo de Vida para os projetos. O ciclo de vida típico
de um projeto seria o seguinte: Concepção, Planejamento, Execução e Fechamento
(MENEZES, 2007).
Independente do autor todas as definições de gerenciamento de projetos
convergem para um mesmo conceito, estabelecendo que uma solução de suporte aos
processos de desenvolvimento deverá abordar o gerenciamento de projeto como ponto base de
trabalho.
Além das questões finitas que são abordadas nos projetos, processos rotineiros
demandam um esforço considerável para as empresas. No caso das MPEs de software, muitas
atividades rotineiras são sobrecarregadas em pessoas que participam de projetos, gerando uma
evidente interferência na capacidade produtiva. Uma solução que realize a gestão e controle
de projetos para MPEs deverá de alguma forma ser capaz de avaliar a interferência das
atividades rotineiras na equipe.
20
Vários autores dividem e nomeiam as possíveis etapas do ciclo de vida de um
projeto de formas diferentes. O chamado "ciclo de vida típico" mostrado acima, por exemplo,
é chamado por Martins (2006) como Conceituação, Desenvolvimento, Realização e
Finalização. Se forem considerados os projetos de desenvolvimento de softwares, outros
autores dividem determinadas etapas em sub-etapas menores e específicas da indústria de
software, como Bezerra (2002) que subdivide a etapa de execução em implementação e testes.
Neste caso Xavier (2005) salienta que "a definição das fases do ciclo de vida de
um projeto está diretamente ligada ao tipo de produto a ser gerado. Não existe uma única
melhor maneira para definir um ciclo de vida ideal do projeto".
As sub-etapas devem determinar claramente o que será elaborado e quem o irá
fazê-lo para que o resultado da etapa seja atingido (PMBOK, 2004).
A equipe de gerência de projeto é sempre responsável pela escolha daquilo que é
mais apropriado para um projeto específico (PMBOK, 2004).
Diante desta situação considera-se portanto que a solução deverá ser capaz de
atender a uma estrutura de projeto com etapas e sub-etapas livremente definidas, podendo
assim contemplar as mais diversas necessidades envolvidas na gestão do projeto.
Gerência de Projetos é a aplicação de conhecimentos, habilidades e técnicas para
projetar atividades que visem atingir os requerimentos do projeto (PMBOK, 2004), incluindo
o planejamento, organização, supervisão e controle de todos os aspectos do Projeto, em um
processo contínuo, para alcançar seus objetivos (NBR ISO 10006).
É fundamental que o acompanhamento das atividades de um projeto possa gerar
indicadores de qualidade, tempo e custo. Uma solução de suporte deverá ser capaz de realizar
verificações de cumprimentos de objetivos e requisitos, acompanhar o progresso do
desenvolvimento e do e o atendimento ao orçamento, para assim apresentar informações
estratégicas que possam auxiliar gestores e diretores na antecipação de ações visando alinhar
aquilo que foi previsto para o projeto com aquilo que está sendo executado.
Segundo Kronmeyer (2003) “a estratégia de mudança e inovação das
organizações é implementada através de projetos, a capacidade de implementar projetos com
taxa de sucesso maior que seus concorrentes pode ser considerada uma competência essencial
de uma organização”.
Xavier (2005) agrupa os projetos sob o conceito de programa, e o define como
“um grupo de projetos gerenciados de forma coordenada, visando obter benefícios difíceis de
serem alcançados quando gerenciados isoladamente”.
21
Além de agrupar os projetos, para um melhor gerenciamento podemos subdividi-
los em subprojetos (XAVIER, 2005).
Para Martins (2006) os projetos envolvem três áreas de atuação: engenharia,
suprimentos e obras.
A engenharia contempla as funções de especificação do produto ou serviço a ser
produzido pelo projeto.
Suprimentos consiste nas funções de compras e contratações necessárias para a
produção do produto ou execução do serviço resultante.
Obras está associada às atividades de criação/desenvolvimento do produto ou
execução do serviço.
Xavier (2005) define as partes interessadas no projeto de stakeholders. “São
pessoas, grupo de pessoas e organizações que estão ativamente envolvidas no projeto ou,
então, cujos interesses possam ser afetados de forma positiva ou negativa como resultado da
execução ou conclusão do projeto”.
Para Xavier (2005) os principais stakehoders são:
• Gerente do Projeto: Pessoa responsável pelo gerenciamento o projeto.
• Cliente: Pessoas ou organização que solicitou ou contratou o produto ou
serviço do projeto.
• Membros da equipe: Pessoas que compõem a equipe do projeto.
• Organização executora: Empresa em que o projeto está sendo executado.
• Patrocinador (sponsor): Pessoa ou grupo, dentro ou fora da organização
executora, que provê recursos financeiros e/ou apoio institucional para a
execução do projeto.
• Usuário: Pessoa ou organização que irá utilizar o produto ou serviço do
projeto.
Uma das entidades internacionais que congrega os profissionais de áreas
relacionadas à Gerência de Projetos é o Project Management Institute (PMI). Foi fundado em
1969 nos Estados Unidos e hoje está presente em todo o mundo, incluindo no Brasil. Sua
missão é promover o profissionalismo e desenvolver o "estado-de-arte" na gestão de projetos
promovendo aos seus associados serviços e produtos e estabelecendo a aceitação do
gerenciamento de projetos como uma disciplina e uma profissão (PMBOK, 2004).
22
Segundo Xavier "uma das grandes contribuições do PMI, para a divulgação das
boas práticas de gerenciamento de projetos, foi a publicação de um documento denominado A
Guide to the Project Management Body of Knowledge (conhecido pelo acrônimo de
PMBOK)". Xavier coloca o PMBOK como a "principal fonte de informações para as
empresas melhorarem os seus processos de gerenciamento".
O PMBOK sugere um conjunto de processos que devem ser executados durante o
gerenciamento do projeto. Estes processos são separados por área, tendo processos para
gerenciamento de escopo, tempo, custo recursos humanos, comunicações, riscos, aquisições e
qualidade, além de um conjunto específico de processos que integram estas áreas (PMBOK,
2004).
Para um melhor entendimento das referidas áreas, segue uma descrição geral de
algumas delas, as quais estarão sendo utilizadas neste trabalho:
• Gerenciamento de Integração do Projeto: descreve os processos
necessários para assegurar que os vários elementos do projeto sejam
adequadamente coordenados. Consiste na elaboração do plano do projeto,
na execução do plano do projeto e no controle integrado de alterações.
• Gerenciamento do Escopo do Projeto: descreve os processos necessários
para assegurar que o projeto inclua todas as atividades necessárias, e
somente estas, garantindo assim que o mesmo seja finalizado com sucesso.
Consiste na iniciação, no planejamento do escopo, definição do escopo, na
verificação do escopo e no controle das alterações do escopo.
• Gerenciamento do Tempo do Projeto: descreve os processos necessários
para assegurar a conclusão do projeto dentro do prazo previsto. Consiste
na definição das atividades, no sequenciamento das atividades, na
estimativa de duração das atividades, na elaboração do cronograma, e no
controle do cronograma.
Este trabalho não abordará as áreas de qualidade, contratação e riscos, limitando-
se ma área de custos a apresentar o total de horas gastas por tipo de atividade e recurso, não
trabalhando diretamente com os processos de orçamento dos projetos.
Os processos da gerência de projeto do PMBOK são uma série de ações que
produzem algum resultado. O PMBOK identifica 39 processos típicos normalmente
23
necessários para o gerenciamento da maioria dos projetos. Estes processos estão distribuídos
nos cinco grupos (Iniciação, Planejamento, Execução, Controle, e Encerramento).
Um grupo pode conter um ou mais processos. Estes processos são iterativos,
podendo ser executados várias vezes em todo o ciclo de vida do projeto.
• Processo de Iniciação: O processo de iniciação se refere à autorização do
projeto ou fase.
• Processo de Planejamento: O processo de planejamento se refere à
definição e refinamento dos objetivos e seleção da melhor das alternativas
de ação para alcançar os objetivos que o projeto estiver comprometido em
atender.
• Processo de Execução: O processo de execução preocupa-se em
coordenar pessoas e outros recursos para realizar o plano.
• Processo de Controle: O processo de controle assegura que os objetivos
do projeto estejam sendo atingidos, através do monitoramento regular do
seu progresso para identificar variações do plano e, portanto, ações
corretivas podem ser tomadas quando necessárias.
• Processo de Encerramento: O processo de encerramento formaliza a
aceitação do projeto ou fase e encerra-o de forma organizada.
Com relação aos processos de Planejamento, o foco deste trabalho será baseado
nos processos da figura 1.
24
Figura 1. Processos de planejamento de projeto atendidos pelo trabalho Fonte: Autor, baseado no “Grupo de processos de planejamento” (PMBOK, 2004, p.47)
Pelo PMBOK se colocar como um guia, este se concentra em expor o apenas "o
que é necessário para a gestão de projetos" e não o "como". No caso dos processos de gestão
de desenvolvimento de software este papel deve ser assumido pela metodologia (XAVIER,
2005).
Por se tratar de uma referência mundial de boas práticas de gerência e projetos, a
solução atenderá aos requisitos do PMBOK.
Além do PMBOK outra fonte de diretrizes para gerenciamento de projetos é a
norma NBR ISO 10006. “Esta Norma fornece diretrizes sobre os elementos do sistema da
qualidade, conceitos e práticas para os quais a implementação é importante, e tem impacto, na
25
obtenção da qualidade no gerenciamento de Projetos (NBR ISO 10006)”. Neste estudo o autor
não abordará questões relativas à NBR ISSO 10006.
O enfoque de projetos é fundamentado como uma premissa necessária para a
conduta do desenvolvimento de software na organização. O processo evolutivo do software
normalmente implica em atividades de manutenção com poucos limites definidos, sem clareza
de contexto, prazos, objetivos, etc. Sob o enfoque de projetos, podemos estabelecer
empreendimentos temporários, com objetivo único, quebrando o ciclo sem fim do
desenvolvimento de software.
2.2 ENGENHARIA DE SOFTWARE
Atualmente desenvolver softwares com qualidade tem sido um grande desafio
para o mercado. Atender aos requisitos de sistema, estimar custos e recursos e cumprir prazos
não são atividades tão simples para a indústria de software.
Impulsionado pela necessidade de produzir software mais rapidamente com
qualidade e produtividade a indústria de software tem disponibilizado com grande velocidade
novos métodos, ferramentas e modelos de desenvolvimento.
“A Engenharia de Software trata-se de uma área do conhecimento da informática
voltada para a especificação, desenvolvimento e manutenção de sistemas de software
aplicando tecnologias e práticas da Ciência da Computação, Gerência de Projetos, dentre
diversas outras disciplinas, objetivando organização, produtividade e qualidade (REZENDE,
1999)”.
Rezende (1999) resume o conceito da Engenharia de Software afirmando que
“também pode ser encarada como uma metodologia de desenvolvimento e manutenção de
sistemas”. O autor complementa indicando que “a Engenharia de Software é um tema
relativamente novo que ainda causa muitas discordâncias de conceito”.
Os objetivos da Engenharia de Software são o aprimoramento da qualidade dos
produtos de software e o aumento da produtividade dos engenheiros de software, além do
atendimento aos requisitos de eficácia e eficiência, ou seja, efetividade (MAFFEO,1992).
Jalote (2007) enfatiza a questão da busca pela alta qualidade do software a baixo custo.
26
Para Sommerville (1992) a engenharia de software envolve questões técnicas e
não técnicas, tais como especificação do conhecimento, técnicas de projeto e implementação,
conhecimentos dos fatores humanos pelo engenheiro de software e ainda, gestão de projetos.
Pressman (2002) apóia a Engenharia de Software numa tríplice formada de
métodos, ferramentas e procedimentos. Os métodos são os modelos para a construção de
software, as ferramentas fornecem apoio automatizado ou semi-automatizado aos métodos e
os procedimentos definem a seqüência de métodos a serem aplicados para a construção do
software. Estes três componentes fornecem ao desenvolvedor uma estrutura básica para
controlar e gerenciar o processo de desenvolvimento do software e para construir software de
qualidade de forma eficiente.
Por se tratar de um trabalho focado nos processos de gestão do desenvolvimento
de software, o autor não se aprofundará no estudo de todas as áreas de conhecimento da
Engenharia de Software, limitando-se aos temas diretamente relacionados com o trabalho ou
referências relativas a importância da gestão por projetos para a Engenharia de Software.
Paula Filho (2003) conceitua o software como um produto industrial, e como tal
possui um ciclo de vida produtivo. Paula Filho (2003) divide este ciclo de vida em 4 fases
principais, e ressalta que tais fases sofrem divisões e subdivisões conceituais dentro da
Engenharia de Software. Estas fases são:
• Concepção a partir da percepção de uma necessidade.
• Desenvolvimento do software, transformando-o em um conjunto de itens
que serão entregues a um cliente.
• Operação do software, sendo usado dentro de algum processo de negócio e
sujeito a atividades de manutenção.
• Retirada de operação ao final de sua vida útil.
Algumas definições de Engenharia de Software omitem questões relativas à
gestão do processo, porém para Pressman (2002) os aspectos gerenciais do desenvolvimento
devem receber uma atenção cada vez maior.
O trabalho parte do princípio citado por Pressman, que a gestão dos processos de
desenvolvimento fazem parte da engenharia, logo procura através da gestão de projetos
agregar qualidade ao software produzido.
27
Ao englobar as vertentes tecnológicas e gerenciais do processo de
desenvolvimento de software, a engenharia de software aponta para a necessidade de uma
abordagem conjunta. Essa atitude permitiria um aprimoramento equilibrado dos
conhecimentos e métodos inerentes a atividades dessa disciplina, além de proporcionar uma
segmentação indispensável para o tratamento preciso e claro dos aspectos particulares de cada
vertente (REZENDE, 1999).
Rezende (1999) elenca 4 fundamentos que são a base da Engenharia de Software:
Ciência da computação, administração de projetos, comunicação e técnicas de soluções de
problemas.
A Engenharia de Software pode ser dividida áreas de conhecimento (SWEBOK,
2004):
• Requisitos de Software
• Projeto de Software
• Construção de Software
• Teste de Software
• Manutenção de software
• Gerência de Configuração de Software
• Gerência de Engenharia de Software
• Processos de Engenharia de Software
• Ferramentas e Métodos de Engenharia de Software
• Qualidade de Software
Neste capítulo buscou-se apresentar a teoria que embasa o modelo de negócio da
solução proposta, possibilitando a modelagem, o desenvolvimento e a validação do sistema,
reduzindo problemas de especificação ainda na fase de planejamento possibilitando ao autor
alcançar os objetivos propostos no início deste trabalho.
28
3 SISTEMA ROADMAP DE GESTÃO DE EQUIPES E PROJETOS
O RoadMap é um sistema de gestão de equipes e projetos para empresas
desenvolvedoras de software, com foco nas micro e pequenas empresas brasileiras.
3.1 RELAÇÃO DAS NECESSIDADES E STAKEHOLDERS
O Sistema RoadMap busca atender as necessidade principais de três stakeholders
envolvidos no processo de desenvolvimento de software:
• Diretor de Desenvolvimento
• Gerente de Projeto
• Equipe de Desenvolvimento
3.1.1 Diretor de Desenvolvimento
Numa empresa de desenvolvimento de software o papel de Diretor de
Desenvolvimento está no topo da cadeia hierárquica. Sua autoridade advém do seu cargo,
tendo responsabilidade final sobre o sucesso do projeto. Apóia o Gerente de Projeto e a
Equipe de Desenvolvimento frente à empresa.
O Sistema RoadMap busca atender a necessidade do Diretor de Desenvolvimento
em dar visibilidade a empresa sobre o andamento dos projetos e auxiliá-lo na monitoração de
prioridades estratégicas dos projetos.
29
3.1.2 Gerente de Projetos
O Gerente de Projetos é responsável por planejar, gerenciar e controlar os projetos
que estão sob sua responsabilidade. Exerce o papel de liderança direta sobre a equipe de
desenvolvimento, tendo poderes de decisão e habilidades de comunicação, negociação e
solução de conflitos.
Para conduzir um projeto ao sucesso é importante que o Gerente de Projetos possa
controlar e monitorar o escopo, os prazos e os custos do projeto, além dos recursos
envolvidos.
O Sistema RoadMap busca atender à necessidade do Gerente de Projetos em obter
informações sobre o progresso dos projetos, atividades e pessoas envolvidas, oferecendo um
conjunto de informações claras sobre o andamento dos projetos para facilitar a tomada de
decisões.
O Sistema RoadMap não atenderá diretamente as necessidades de gestão de custos
do projeto, por entender que a elaboração, manutenção e acompanhamento de cronogramas
vai além do escopo proposto incialmente.
3.1.3 Equipe de Desenvolvimento
Composta pelas pessoas que executam as atividades de desenvolvimento. Pode ser
composta por analistas, programadores, testadores, etc.
É importante que o plano de ação, da atividade designada à Equipe de
Desenvolvimento, esteja claro e acessível, indicando “quem” deverá fazer “o que” e
“quando”, conforme as designações do Gerente de Projetos.
O Sistema RoadMap busca atender a necessidade da Equipe de Desenvolvimento
oferecendo informações sobre pendências e demandas, possibilitando o planejamento
individual das execuções e controle dos progressos.
30
3.2 CARACTERÍSTICAS DO SISTEMA
As seguintes seções descrevem as principais características que o Sistema
RoadMap possui para atender as necessidades acima citadas.
3.2.1 Baseado em Ambiente WEB
Para atender os objetivos de integração e visibilidade dos projetos, é importante
que o sistema seja facilmente acessível aos stakeholders. Ao optar pelo ambiente web dá-se
ao sistema a capacidade de ser acessível em qualquer computador com acesso a internet, sem
a necessidade de instalação de softwares adicionais.
3.2.2 Gerenciamento de Projetos, Sub-Projetos e Atividades
Os Sistema RoadMap possui a capacidade de gerenciar todo o ciclo de vida de um
projeto software através do gerenciamento de projetos, sub-projetos e atividades. Através de
um interface única o Sistema RoadMap é capaz de dar visibilidade completa sobre o
andamento de todos os projetos da empresa, progressos, prazos, responsáveis, etc.
3.2.3 Indicadores Gerenciais
Os Sistema RoadMap gera gráficos de acompanhamento dos projetos, podendo
estratificar as informações relativas as atividades executadas por cliente, área, tipo e executor,
31
dando informações estratégicas importantes que auxiliam nas tomadas de decisões por parte
de Gerentes de Projetos e Diretores de Desenvolvimento.
3.3 CASOS DE USO DO SISTEMA
“Um caso de uso captura um contrato entre os stakeholders de um sistema sobre
seu comportamento” (COCKBURN, 2008).
Segundo Cockburn (2008) os Casos de Uso podem possuir vários níveis de
detalhamento. O nível mais alto e abstrato é considerado por Cockburn como ideal para
descrever o escopo do sistema e dar visibilidade ao leitor de como os atores alcançam seus
objetivos no sistema. O autor utilizou este nível, chamado por Cockburn de nível-resumo,
para descrever as funcionalidades e requisitos do sistema.
A figura 2 mostra os principais atores envolvidos no Sistema RoadMap, utilizando
a notação UML.
Membro de Equipe Responsáv el Administrador Diretor
Figura 2. Atores envolvidos no Sistema RoadMap Fonte: Autor
A figura 3 mostra os principais casos de uso envolvidos no Sistema RoadMap,
utilizando a notação UML.
32
Membro de Equipe
Executar ativ idades
Apontar progresso
Consultar projetos e ativ idades
Responsável
Gerenciar ativ idades
Alterar o status das ativ idades
Designar executores e estimar esforço
Administrador
Manter o cadastro de Tipos de Ativ idades
Manter o cadastro de Empresas
Manter o cadastro de Áreas
Manter o cadastro de Recursos
Diretor
Consultar gráficos de desempenho
Figura 3. Casos de uso envolvidos no Sistema RoadMap Fonte: Autor
3.3.1 Caso de Uso: Consultar Atividades e Projetos
Ator Primário: Membro de Equipe.
Interesses:
• Todos os usuários: Acompanhar as atividades.
Descrição:
Os usuários do sistema podem consultar as atividades cadastradas no sistema,
podendo filtrar os dados com base em vários parâmetros.
33
3.3.2 Caso de Uso: Executar Atividades
Ator Primário: Membro de Equipe.
Interesses:
• Membro de Equipe: Informar em tempo real qual atividade está sendo
executada.
• Responsável: Acompanhar em tempo real as atividades que estão sendo
executadas.
Descrição:
Um Membro de Equipe poderá selecionar uma das atividades designadas a ele e
iniciar sua execução. Esta execução dispara um cronômetro que contará em tempo real a
quantidade de horas que está sendo utilizada para a execução da atividade.
Da mesma forma que o usuário iniciou a execução de uma atividade ele poderá
interromper esta execução. Ao fazer isso o cronômetro irá fechar a execução e atualizar o
tempo utilizado na atividade, ajustando o progresso real da atividade.
3.3.3 Caso de Uso: Apontar Progresso
Ator Primário: Membro de Equipe.
Interesses:
• Membro de Equipe: Informar a estimativa de progresso da atividade,
independente do progresso real calculado com base nas horas executadas.
• Responsável: Avaliar potenciais atrasos e ociosidades na equipe.
Descrição:
Um Membro de Equipe pode assinalar manualmente o progresso de uma
atividade.
34
3.3.4 Caso de Uso: Gerenciar atividades
Ator Primário: Responsável.
Interesses:
• Responsável e Administrador: Realizar a manutenção das atividades
(inclusão, edição e exclusão), gerenciando suas prioridades e cronogramas.
• Diretor: Acompanhar o andamento dos projetos (prazos, previsões,
progressos, prioridades, etc).
Descrição:
O gerenciamento das atividades se dá através de uma tela principal apresentando
todas as atividades cadastradas, podendo o usuário optar por diversos filtros para limitar a
quantidade de atividades mostradas.
As atividades poderão ser cadastradas de forma hierárquica, compondo projetos
com subprojetos e atividades. A geração da codificação da EDT (Estrutura de Divisão de
Trabalho) será feita de forma automática, através do incremento seqüencial da codificação de
cada atividade e sub-atividade.
Não há distinção para o sistema entre uma atividade e um projeto, mas para
facilitar a construção da estrutura o usuário pode cadastrar a atividade como abstrata. Neste
conceito a atividade não poderá possuir executores diretos e nem ser executada, mas sim
servirá de base para possuir atividades que, estas sim, poderão ser executadas.
Toda atividade possuirá um Dono. O Dono da atividade é um usuário com
privilégios de alteração da atividade.
Para estratificar futuramente as informações sobre as atividades, estas podem ser
cadastradas segundo uma área, um tipo e uma empresa.
Há um controle de privilégio de alteração e execução das atividades. Segundo este
controle uma atividade pode ser classificada entre privadas, restritas ou públicas:
• As atividades privadas só podem ser gerenciadas pelo Dono da Atividade e
executadas pelos seus executores.
• As atividades restritas podem ser gerenciadas por qualquer executor da
atividade.
35
• As atividades públicas podem ser gerenciadas e executadas por qualquer
usuário do sistema.
3.3.5 Caso de Uso: Alterar o status das Atividades
Ator Primário: Responsável.
Interesses:
• Responsável e Administrador: Atualizar o status atual das atividades.
• Diretor: Acompanhar o status das atividades e projetos.
Descrição:
Conforme privilégio do usuário, este pode alterar o status de uma atividade da
seguinte forma:
• Concluir: Altera o status de uma atividade para “Concluída”,
automaticamente apontando o progresso de todas as atividades e sub-
atividades para 100%.
• Paralisar: Altera o status de uma atividade para “Paralisada”.
• Cancelar: Altera o status de uma atividade para “Cancelada”.
• Reabrir: Altera o status de uma atividade para “Em Andamento”.
O sistema segue o modelo de estados indicado no diagrama abaixo:
36
início
fim
Em Aguardo
Em Execução
Em AndamentoParalisada
Cancelada Concluída
incluir nova atividade
executar
parar execuçãoexecutar
paralisar
reabrir
cancelarreabrir
concluir
Figura 4. Modelo de Estados das Atividades Fonte: Autor
Quando uma atividades que possui sub-atividades, seu status está diretamente
associado aos status das suas sub-atividades, por exemplo: Para concluir uma atividade pai
deve-se concluir todas suas sub-atividades.
37
3.3.6 Caso de Uso: Designar executores e estimar esforço
Ator Primário: Responsável.
Interesses:
• Responsável e Administrador: Montar uma equipe para executar uma
atividade e cadastrar o tempo estimado de esforço para cada executor.
• Diretor: Acompanhar a distribuição de atividades entre os colaboradores
da empresa e o monitorar a carga de trabalho exigida para cada membro.
Descrição:
O usuário com privilégio de alteração da atividade pode montar uma equipe de
executores para atividade, estabelecendo uma estimativa de esforço em horas para cada
executor.
3.3.7 Caso de Uso: Manter Cadastro de Tipos de Atividades
Ator Primário: Administrador.
Interesses:
• Administrador: Consultar, incluir, editar e excluir tipos de atividades.
Descrição:
O administrador do sistema pode manter o cadastro de tipos de atividades através
de operações de inclusão, edição e exclusão.
38
3.3.8 Caso de Uso: Empresas
Ator Primário: Administrador.
Interesses:
• Administrador: Consultar, incluir, editar e excluir empresas.
Descrição:
O administrador do sistema pode manter o cadastro de empresas através de
operações de inclusão, edição e exclusão.
3.3.9 Caso de Uso: Manter Cadastro de Áreas
Ator Primário: Administrador.
Interesses:
• Administrador: Consultar, incluir, editar e excluir áreas.
Descrição:
O administrador do sistema pode manter o cadastro de áreas através de operações
de inclusão, edição e exclusão.
3.3.10 Caso de Uso: Manter Cadastro de Tipos de Recursos
Ator Primário: Administrador.
Interesses:
• Administrador: Consultar, incluir, editar e excluir recursos.
• Todos: Alterar a senha de acesso.
39
Descrição:
O administrador do sistema pode manter o cadastro de recursos através de
operações de inclusão, edição e exclusão.
A edição da própria senha de acesso é permitida à qualquer usuário ativo, porém
alterar a senha de outros usuário só é permitido ao Administrador do sistema.
3.3.11 Caso de Uso: Consultar Gráficos de Desempenho
Ator Primário: Diretor.
Interesses:
• Diretor: Obter informações estratégicas sobre o tempo gasto na execução
das atividades.
Descrição:
O diretor poderá consultar os gráficos gerados pelo sistema para obter
informações sobre:
• Número de horas executadas por empresa, podendo filtrar por data, tipo,
área e executor.
• Número de horas executadas por tipo de atividade, podendo filtrar por
data, empresa, área e executor.
• Número de horas executadas por área, podendo filtrar por data, tipo,
empresa e executor.
• Quantidade de horas executadas por mês por empresa, podendo filtrar por
data, tipo, área e executor.
40
3.4 ARQUITETURA E FERRAMENTAS UTILIZADAS
A seção a seguir lista as principais tecnologias utilizadas no processo de
desenvolvimento do sistema RoadMap.
3.4.1 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 embútivel dentro do HTML (PHP.net, 2009).
O PHP é um módulo oficial do servidor HTTP Apache, o líder de mercado de
servidores Web livres que constitui aproximadamente 55 por cento da World Wide Web.
Assim como o servidor Apache, o PHP é compatível com várias plataformas, o que significa
que ele executa em seu formato original em várias versões do UNIX e do Windows
(Converse, 2004).
O autor optou por esta linguagem por dois motivos:
• Experiência: O autor possui cerca de 10 anos de experiência profissional
programando na linguagem.
• Custo: Por se tratar de uma tecnologia gratuita, seu uso diminui o custo no
desenvolvimento da solução.
41
3.4.2 Banco de Dados MySQL
O MySQL é um sistema de gerenciamento de banco de dados que utiliza a
linguagem SQL (Structured Query Language - Linguagem de Consulta Estruturada) como
interface (MySQL.com, 2009).
É atualmente o banco de dados open source mais popular do mundo, devido ao
seu desempenho, confiabilidade e facilidade de uso.
MySQL funciona em mais de 20 plataformas incluindo Linux, Windows, OS / X,
HP-UX, AIX, Netware, dando-lhe o tipo de flexibilidade que o coloca no comando.
Este banco de dados foi escolhido pelo autor pelos mesmos motivos com os quais
foi escolhida a linguagem PHP: Experiência e custo.
3.4.3 Framework MorphpWeb
Segundo FAYAD (1999), "Framework é um conjunto de classes que colaboram
para realizar uma responsabilidade para um domínio de um subsistema da aplicação".
Os frameworks são utilizados para aumentar a produtividade através da
reutilização de funcionalidades.
O MorphpWeb é um framework para linguagem PHP que foi desenvolvido há
cerca de 3 anos pelo autor. Neste período várias aplicações profissionais foram desenvolvidas
em sua plataforma, o que auxiliou na melhoria da robustez e confiabilidade desta.
O framework MorphpWeb tem sua arquitetura baseada em dois conceitos:
Componentização e Orientação à Eventos.
A componentização permite que aplicações possam ser confeccionadas a partir de
componentes pré-construídos ao invés de desenvolve-las a partir do zero. Maximiza a
reutilização aumentando assim a produtividade do desenvolvimento (Pressman, 2000).
A orientação à eventos consiste em uma coleção de ações que podem ser
detectadas por um módulo chamado Gerenciador de Eventos. Estas ações podem ser do
usuário sobre os dispositivos de entrada (clicar no mouse ou digitar algo, por exemplo),
também podem ser sinais do hardware ou do software. Cada ação é associada a uma rotina, no
42
caso do MorphpWeb a um método de classe, que é disparado quando seu evento ocorre. Este
método torna o código fonte final bastante flexível e organizado (SWEBOK, 2004).
O autor optou por utilizar o framework MorphpWeb para agilizar o processo de
desenvolvimento da solução.
3.4.4 UML (Unified Modeling Language)
Segundo Martins (2006). “O Unified Modeling Language (UML) é uma
linguagem padrão para documentar projetos de software“.
A UML é uma união de diversas notações preexistentes, com alguns elementos
removidos e outros adicionados com o objetivo de torná-la mais expressiva (BEZERRA,
2003).
Apresentada como uma linguagem visual, é constituída de elementos gráficos
(visuais) utilizados na modelagem que permitem expressar diversas perspectivas de um
sistema (CARDOSO, 2003).
O autor optou por utilizar UML devido sua experiência profissional como
Analista de Requisitos utilizando esta tecnologia.
3.4.5 Arquitetura Física
A Arquitetura Física descreve os componentes de hardware e software e sua
interação com outros elementos de suporte ao processamento. Representa a configuração e a
arquitetura de um sistema em que estarão ligados seus respectivos componentes.
43
Computador do Usuário
Browser
Serv idor
PHP
MySQL
Web Serv er
MorphpWeb
Sistema RoadMap
HTTP
Figura 5. Arquitetura Física do Sistema RoadMap Fonte: Autor
3.5 HISTÓRICO DO DESENVOLVIMENTO
Para desenvolver o sistema RoadMap o autor utilizou o conceito de
desenvolvimento iterativo.
No desenvolvimento iterativo o objetivo é conduzir o projeto em ondas, ou seja,
em iterações. Cada iteração é tratada de forma tradicional, alguns requisitos e riscos mais
críticos são abordados, há um pouco de análise, implementação, testes e implantação. Depois
há outra iteração, onde novos requisitos são trabalhados, outros riscos são mitigados, há mais
análise, implementação, testes e implantação, até que o produto seja concluído (MARTINS,
2006).
As funcionalidades propostas foram divididas em pacotes onde o
desenvolvimento de cada pacote se deu em uma iteração específica. Este empacotamento foi
realizado com base nos Casos de Uso mapeados, definindo os escopos funcionais dos pacotes
da seguinte forma:
44
Pacote 1 - Cadastros Básicos
Este pacote possui as funcionalidades básicas necessárias para as outras
funcionalidades do sistema, ou seja, os demais pacotes são dependentes da implementação
deste pacote.
Este pacote também inclui as rotinas de validação de acesso do usuário e
segurança.
Os Casos de Uso contidos neste pacote são:
• Manter cadastro de Empresas
• Manter cadastro de Recursos
• Manter cadastro de Tipos de Atividades
• Manter cadastro de Áreas.
Pacote 2 - Funcionalidades Básicas de Gestão das Atividades
Este pacote possui as funcionalidades iniciais de gestão das atividades e projetos,
ainda não considerando detalhes referentes aos membros das equipes que executam as
atividades.
Os Casos de Uso contidos neste pacote são:
• Consultar Projetos e Atividades
• Gerenciar Atividades
• Alterar o status das Atividades
Pacote 3 - Funcionalidades Avançadas de Gestão das Atividades
Este pacote é uma evolução das funcionalidades relativas a gestão das Atividades.
Ele adiciona a capacidade do sistema de gerir tempos, esforço e equipe.
45
Os Casos de Uso contidos neste pacote são:
• Designar executores e estimar esforço
• Executar Atividades
• Apontar progresso
Pacote 4 - Gráficos Gerenciais
Este pacote adiciona ao sistema um conjunto de gráficos gerenciais. Este pacote
possui apenas um Caso de Uso: Consultar gráficos de desempenho.
O autor não utilizou nenhuma metodologia formal, pois não há no mercado
metodologias específicas para o desenvolvimento de um sistema de forma individual, com
uma pessoa assumindo todos os papeis do processo de desenvolvimento. Portanto para
organizar o trabalho o autor utilizou sua própria experiência em engenharia de software,
adaptando o processo de desenvolvimento iterativo vivido em sua experiência profissional
com equipes para o desenvolvimento individual de um sistema.
Modelos completos com inúmeras atividades para cada iteração foram
simplificados. Para cada pacote o autor realizou uma iteração composta pelas seguintes
atividades:
1. Detalhamento da modelagem
2. Implementação da funcionalidade
3. Testes e correções
Para exemplificar o processo o autor descreve no tópico 3.6 cada uma das
iterações envolvidas no desenvolvimento do Pacote 2 - Funcionalidades Básicas de Gestão
das Atividades.
46
3.6 DESCRIÇÃO DA ITERAÇÃO DO PACOTE 2 - FUNCIONALIDADES
BÁSICAS DE GESTÃO DAS ATIVIDADES
3.6.1 Detalhamento da Modelagem
Nesta atividade o autor detalhou cada um dos casos de uso envolvidos no pacote,
descrevendo atores, pré-condições, pós-condições e cenários.
O autor baseou a escrita e estruturação dos Casos de Uso nas práticas e modelos
recomendados por Cockburn (2008). Para Cockburn “Casos de Uso são fundamentalmente
uma forma textual, embora possam ser escritos usando fluxogramas, diagramas de seqüência,
redes petri ou linguagens de programação. Sob circunstâncias normais, eles servem como um
meio de comunicação entre uma pessoa e outra, muitas vezes entre pessoas sem treinamento
especial. Portanto, texto simples é, geralmente, a melhor escolha”.
3.6.1.1 Caso de Uso Consultar Projetos e Atividades
Ator Principal: Membro de Equipe.
Pré-condição: Usuário logado no sistema e com permissão de acesso às
atividades.
Cenário Principal (cp): Consulta da lista de atividades.
Passos:
1. Usuário clica no ícone Atividades na Tela Principal do sistema.
2. Sistema mostra a lista de atividades em forma de árvore hierárquica.
47
Colunas da lista:
o Nome: Nome dado a Atividade.
o EDT: Estrutura de Divisão de Trabalho. Códigos utilizados para
definir a estrutura hierárquica das Atividades.
o Tipo: Tipo de Atividade.
o Área: Área da Atividade.
o Status: Status atual da Atividade.
o Prioridade: Prioridade da Atividade.
o Início: Início previsto para a Atividade.
o Término: Término previsto para a Atividade.
o Progresso Apontado: Percentual de conclusão da Atividade
apontado manualmente pelos seus executores.
o Progresso Real: Percentual de conclusão da Atividade baseado
em quantas horas foram previstas para sua execução e quantas
horas foram efetivamente executadas.
o Progresso Esperado: Percentual de conclusão esperado para a
Atividade, baseado nas datas de início e término previstas em
comparação com a data atual.
o Horas-Homem Previstas: Somatório de todas as horas previstas
de execução para cada executor da Atividade.
o Horas-Homem Executadas: Somatório de todas as horas
executadas de cada executor da Atividade.
o Privilégio: Determina o grau de rigidez na edição e execução da
Atividade.
o Dono: Usuário que possui maiores privilégios na Atividade.
Cenário Alternativo (a1): Aplicação de filtro na lista.
Passos:
2.1. Usuário informa um ou mais parâmetros de pesquisa.
Parâmetros disponíveis:
o Por tipo de atividade;
o Por área;
o Por empresa;
o Por status;
48
o Especiais (abertas, fechadas, pendências e minhas pendências).
2.2. Usuário clica no botão Atualizar.
2.3. Sistema atualiza a lista de atividades com base nos parâmetros
informados.
Cenário Alternativo (a2): Detalhes de uma atividade.
Passos:
2.1. Usuário seleciona uma atividade da lista e clica no ícone Detalhar.
2.2. Sistema mostra os detalhes da Atividade.
3.6.1.2 Caso de Uso Gerenciar Atividades
Ator Principal: Responsável.
Pré-condição: Usuário logado no sistema e com permissão de acesso às
atividades.
Cenário Principal (cp): Consulta da lista de atividades.
Passos:
1. Usuário clica no ícone Atividades na Tela Principal do sistema.
2. Sistema mostra a lista de atividades em forma de árvore hierárquica,
disponibilizando ao usuário opções para incluir, editar e excluir Atividades.
Cenário Alternativo (a1): Inclusão de uma nova atividade.
Passos:
2.1. Usuário clica no ícone incluir.
2.2. Sistema mostra o formulário de inclusão de nova atividade.
Campos disponíveis:
o Abstrata: Campo de checagem. Uma atividade marcada como
Abstrata não pode ser executada, sendo utilizada como Atividade
Pai de outras Atividades.
49
o Nome: Campo textual obrigatório. Nome que identifica a
Atividade.
o Atividade Pai: Campo de seleção. Se a Atividade for uma sub-
atividade, deve-se aqui selecionar qual a Atividade Pai possui a
Atividade.
o Dono da Atividade: Campo de seleção obrigatório. Usuário do
sistema que possuirá maiores responsabilidades e privilégios sob a
Atividade, como edição, inclusão de executores e alteração de
status.
o Área: Campo tipo seleção obrigatório. Área da Atividade. As
opções são baseadas nas Áreas cadastradas no sistema.
o Empresa: Campo tipo seleção obrigatório. Empresa que demandou
a Atividade. As opções são baseadas nas Empresas cadastradas no
sistema.
o Tipo: Campo tipo seleção obrigatório. Tipo da Atividade. As
opções são baseadas nos Tipos de Atividades cadastrados no
sistema.
o Privilégio: Campo tipo seleção obrigatório. Privilégio de alteração
e execução da Atividade.
o Prioridade: Campo tipo seleção obrigatório. Determina o nível de
importância e urgência que a Atividade possui. As opções
disponíveis são: Muito Alta, Alta, Moderada, Baixa e Muito Baixa.
o Data de Início: Campo tipo calendário obrigatório. Data prevista
para o início da Atividade.
o Data de Término: Campo tipo calendário obrigatório. Data
prevista para o término da Atividade.
o Descrição: Campo textual grande. Descrições mais detalhadas da
Atividade e outras informações relevantes.
2.3. Usuário preenche os campos e clica no botão Salvar.
2.4. Sistema valida e salva os dados
Retorna ao passo 2.
50
Cenário alternativo (a2): Edição de uma atividade.
Passos:
2.1. Usuário seleciona uma atividade da lista e clica no ícone Editar.
2.2. Sistema mostra o formulário de edição de atividade. Os campos
disponíveis são os mesmos do formulário de inclusão de nova atividade.
2.3. Usuário altera os dados da Atividade e clica no botão Salvar.
2.4. Sistema valida e salva os dados.
Retorna ao passo 2.
Cenário alternativo (a3): Exclusão de uma atividade.
Passos:
2.1. Usuário seleciona uma atividade da lista e clica no ícone Excluir.
2.2. Sistema solicita confirmação da exclusão da atividade.
2.3. Usuário confirma a exclusão.
2.4. Sistema exclui a atividade.
Retorna ao passo 2.
Cenário de exceção (e1): Dados informados na inclusão da atividade no cenário
(a1) são inválidos.
Passos:
2.3.1. Sistema constata que os dados informados não são válidos.
Dados inválidos:
o Campos obrigatórios não informados.
o Data de término inferior a data de início.
o Data de início e/ou término incompatíveis com as datas de início e
término da atividade pai.
2.3.2. Sistema notifica o usuário sobre o problema
Retorna ao passo 2.2 do cenário (a1).
Cenário de exceção (e2): Dados informados na edição da atividade no cenário
(a2) são inválidos.
Passos:
2.3.1. Sistema constata que os dados informados não são válidos. Os dados
inválidos são os mesmos do cenário (e1).
51
2.3.2. Sistema notifica o usuário sobre o problema
Retorna ao passo 2.2 do cenário (a2).
3.6.1.3 Caso de Uso Alterar Status da Atividade
Ator Principal: Responsável.
Pré-condição: Usuário logado no sistema e com permissão de acesso às
atividades.
Cenário Principal (cp): Alteração do status da atividade.
Passos:
1. Usuário clica no ícone Atividades na Tela Principal do sistema.
2. Sistema mostra a lista de atividades em forma de árvore hierárquica.
3. Usuário seleciona uma atividade da lista e clica em um dos ícones de
alteração de status.
Alterações possíveis de status:
o Concluir;
o Paralisar;
o Cancelar;
o Reabrir.
4. Sistema mostra o formulário de alteração de status de atividade. Este
formulário possui um único campo textual para comentários.
5. Usuário informa ou não um comentário e clica no botão Salvar.
6. Sistema altera o status da atividade conforme operação selecionada no
passo (3).
Retorna ao passo 2.
52
3.6.2 Implementação da Funcionalidade
Nesta atividade o autor alterou o banco de dados conforme o diagrama de
entidade-relacionamento, e codificou as classes projetadas.
O autor utilizou várias boas práticas de Engenharia de Software para codificar
com qualidade o sistema. Dentre as inúmeras boas práticas cita-se as indicadas por Quadros
(2002):
• Reaproveitamento de código;
• Documentação do código
• Padronização de nomenclatura e estilo de codificação;
• Modularização;
• Programação defensiva;
3.6.3 Testes e Correções
Um Plano de Teste foi criado com base nos cenários elaborados no detalhamento
dos casos de uso. Estes cenários adaptados para teste foram chamados de Casos de Teste.
Após executar o Plano de Teste todas as falhas encontradas entravam num Plano
de Correção.
O Plano de Correção foi tratado como uma mini-iteração, ou seja, com atividades
de modelagem, codificação e teste, neste caso uma revisão e atualização da modelagem,
correção do código-fonte e execução completa do Plano de Teste.
O Plano de Teste deste trabalho cobriu apenas testes de aceitação, não realizando
testes mais completos de estresse, desempenho, segurança, etc.
O teste de aceitação é realizado com o propósito de avaliar a qualidade externa do
produto e, na medida do possível, também a qualidade em uso (KOSCIANSKI, 2007).
53
Segundo Inthurn (2001) uma das atividades mais relevantes e pertinentes ao teste
é o projeto de casos de teste. Nesta atividade concentra-se um conjunto de técnicas, critérios e
métodos para elaborar casos de teste que forneçam ao projetista de software uma abordagem
sistemática e teoricamente fundamentada.
Não é objetivo deste trabalho se aprofundar nos projeto dos casos de teste. Estes
deveriam ser construídos abordando casos funcionais, de estrutura, de erros e combinações
destes (INTHURN, 2001). O autor limitou-se a projetar e executar casos de teste funcionais
que validassem a proposta do sistema.
3.6.3.1 Caso de Teste Consulta da Lista de Atividades
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3.6.3.2 Caso de Teste Aplicação de Filtro na Lista de Atividades
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3. Informar um ou mais parâmetros de pesquisa.
4. Clicar no botão Atualizar
5. Sistema atualizará a lista de atividades com base nos parâmetros
informados.
54
3.6.3.3 Caso de Teste Detalhar uma Atividade
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3. Selecionar uma atividade da lista e clica no ícone Detalhar.
4. Sistema mostrará os detalhes da Atividade.
3.6.3.4 Caso de Teste Inclusão de uma Nova Atividade
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3. Clicar no ícone incluir
4. Sistema mostrará o formulário de inclusão de nova atividade.
5. Preencher os campos e clicar no botão Salvar.
6. Sistema validará e salvará os dados.
3.6.3.5 Caso de Teste Edição de uma Atividade
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3. Selecionar uma atividade da lista e clicar no ícone Editar.
4. Sistema mostrará o formulário de edição de atividade.
5. Alterar os dados da Atividade e clicar no botão Salvar.
6. Sistema validará e salvará os dados.
55
3.6.3.6 Caso de Teste Exclusão de uma Atividade
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3. Selecionar uma atividade da lista e clicar no ícone Excluir.
4. Sistema solicitará confirmação da exclusão da atividade.
5. Confirmar a exclusão.
6. Sistema excluirá a atividade.
3.6.3.7 Caso de Teste Dados informados na inclusão da atividade são inválidos
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3. Clicar no ícone incluir.
4. Sistema mostrará o formulário de inclusão de nova atividade.
5. Preencher de forma INVÁLIDA os campos e clicar no botão Salvar.
6. Sistema constatará que os dados informados não são válidos.
7. Sistema notificará o usuário sobre o problema.
3.6.3.8 Caso de Teste Dados informados na edição da atividade são inválidos
Passos:
1. Clicar no ícone Atividades na Tela Principal do sistema.
2. Sistema mostrará a lista de atividades em forma de árvore hierárquica.
3. Selecionar uma atividade da lista e clicar no ícone Editar.
56
4. Sistema mostrará o formulário de edição de atividade.
5. Preencher de forma INVÁLIDA os campos e clicar no botão Salvar.
6. Sistema constatará que os dados informados não são válidos.
7. Sistema notificará o usuário sobre o problema.
57
3.7 O SISTEMA ROADMAP
Nesta seção o autor apresenta o resultado final do processo de desenvolvimento.
3.7.1 Modelo de Navegação do Sistema RoadMap
Tela de Login
Menu Principal
Lista de Ativ idades
Lista de Execuções
Lista de Tipos de Ativ idades
Lista de Empresas
Lista de Áreas
Lista de Recursos
Gráficos Gerenciais
Formulário de Inclusão de
Ativ idade
Formulário de Edição de Ativ idade
Tela de Detalhes de uma Ativ idade
Lista de Executores de uma Ativ idade
Formulário de Inclusão de
Executor
Formulário de Edição de Executor
Formulário de Apontamento de
Progresso
Formulário de Conclusão de
Ativ idade
Formulário de Paralisação de
Ativ idade
Formulário de Cancelamento de
Ativ idade
Formulário de Reabertura de
Ativ idade
Formulário de Inclusão de Execução
Formulário de Edição de Execução
Resumo de Horas Executadas
Formulário de Inclusão de Tipo de
Ativ idade
Formulário de Edição de Tipo de
Ativ idade
Formulário de Inclusão de
Empresa
Formulário de Edição de Empresa
Formulário de Inclusão de Área
Formulário de Edição de Área
Gráfico Percentual de Horas
Executadas por Empresa
Gráfico Percentual de Horas
Executadas por Área
Gráfico Percentual de Horas
Executadas por Tipo
Gráfico de Horas Executadas por
Empresa/Mês
Formulário de Inclusão de
Recurso
Formulário de Edição de
Recurso
Formulário de Alteração de
Senha
Figura 6. Modelo de Navegação do Sistema Fonte: Autor
58
3.7.2 Telas do Sistema RoadMap
3.7.2.1 Tela de Login
A “Tela de Login” é o primeiro contato do usuário com o sistema RoadMap.
Através da informação de um login e senha válidos o usuário obtém acesso ao sistema.
Figura 7. Tela de Login Fonte: Autor
59
3.7.2.2 Menu Principal
Após o acesso ao sistema é apresentado ao usuário o “Menu Principal” da
aplicação. É através dele que o usuário tem acesso às funcionalidades do sistema.
Figura 8. Menu Principal Fonte: Autor
60
3.7.2.3 Lista de Atividades
A “Lista de Atividades” é a tela principal do sistema RoadMap. Nela o usuário
pode acompanhar o andamento de todos os projetos da empresa.
Figura 9. Lista de Atividades Fonte: Autor
Na listagem principal o usuário acompanha de forma amigável uma série de
informações sobre cada projeto e atividade. Através das colunas Progresso Apontado,
Progresso Real e Progresso Esperado o Gerente de Projetos responsável pode antecipar
decisões de replanejamento com base no progresso de execução da atividade. Outro dado
importante é o acompanhamento das horas previstas e realizadas para cada atividade.
61
Figura 10. Detalhe das colunas da Lista de Atividades Fonte: Autor
Para facilitar o apontamento de horas e o acompanhamento online da execução
das atividades o sistema RoadMap conta com um timer, bastando ao usuário selecionar uma
atividade da Lista de Atividade e clicar no botão “Executar”. O timer continua seu
funcionamento mesmo se o usuário fechar a janela ou o sistema.
Figura 11. Detalhe do timer de execução de atividades Fonte: Autor
As atividades que estão sendo executadas através do timer são assinaladas com
status “Em Execução”, podendo ser acompanhadas na Lista de Atividades.
Figura 12. Detalhe do status 'Em Execução' na Lista de Atividades Fonte: Autor
62
A “Lista de Atividades” pode ser filtrada e reordenada de várias maneiras, o que
auxilia o usuário a visualizar exatamente aquilo que deseja.
Figura 13. Detalhe dos filtros na Lista de Atividades Fonte: Autor
3.7.2.4 Formulário de Inclusão/Edição de Atividades
Nesta tela o usuário alimenta os dados das atividades.
Figura 14. Formulário de Inclusão/Edição de Atividades Fonte: Autor
63
3.7.2.5 Lista de Executores de uma Atividade
A Lista de Executores é uma tela que deve ser aberta por atividade. Nela o usuário
tem uma visão detalhada das pessoas envolvidas na atividade e o progresso de conclusão de
cada uma.
Figura 15. Lista de Executores de uma Atividade Fonte: Autor
3.7.2.6 Formulário de Inclusão/Edição de Executor de uma Atividade
Ao cadastrar um executor para uma determinada atividade pode-se informar um
número de horas-homem estimadas para seu término. É com base nesta estimativa e nos dados
coletados através do timer e do apontamento de progresso que o sistema RoadMap pode
apresentar informações sobre o andamento da atividade, podendo assim prever atrasos e a
necessidade de replanejamentos.
64
Figura 16. Formulário de Inclusão/Edição de Executor de uma Atividade Fonte: Autor
3.7.2.7 Formulário de Apontamento de Progresso
Caso o usuário seja um dos executores de uma determinada atividade ele pode
apontar o progresso de conclusão desta atividade.
Figura 17. Formulário de Apontamento de Progresso Fonte: Autor
3.7.2.8 Formulário de Conclusão/Paralisação/Cancelamento/Reabertura de uma Atividade
Por padrão cada alteração de status de uma atividade é acompanhada de um
formulário para inclusão de comentários. Caso a atividade esteja sendo cancelada ou
paralisada, o preenchimento do comentário é obrigatório.
65
Figura 18. Formulário de Conclusão/Paralisação/Cancelamento/Reabertura de uma Atividade Fonte: Autor
3.7.2.9 Lista de Execuções
Na “Lista de Execuções” o usuário pode visualizar de forma detalhada as
execuções de cada atividade. Estas execuções são alimentadas através do timer ou cadastradas
de forma manual.
Nos filtros disponíveis nesta tela o usuário poderá filtrar os dados das execuções
por data, atividade, executor e empresa, ou então realizar uma combinação destes filtros.
66
Figura 19. Lista de Execuções Fonte: Autor
3.7.2.10 Formulário de Inclusão/Edição de Execução
Incluir manualmente uma execução é uma forma alternativa de apontar as horas
executadas em uma atividade.
67
Figura 20. Formulário de Inclusão/Edição de Execução Fonte: Autor
3.7.2.11 Tela de Resumo de Horas Executadas
Após aplicar os filtros necessários na “Lista de Execuções” o usuário pode acessar
a tela de “Resumo de Horas Executadas”. As informações contidas no resumo respeitarão o
filtro aplicado.
As informações das horas vêem consolidadas por dia e mês, fechando as
informações com o total de horas executadas no período.
Figura 21. Tela de Resumo de Horas Executadas Fonte: Autor
68
3.7.2.12 Lista de Tipos de Atividades
Lista dos tipos de atividades cadastradas.
Figura 22. Lista de Tipos de Atividades Fonte: Autor
3.7.2.13 Formulário de Inclusão/Edição de Tipos de Atividades
Formulário utilizado para a inclusão e edição de tipos de atividades. Para facilitar
a visualização das atividades pelo seu tipo na “Lista de Atividades”, pode-se selecionar uma
cor para o tipo de atividade.
69
Figura 23. Formulário de Inclusão/Edição de Tipos de Atividades Fonte: Autor
3.7.2.14 Lista de Empresas
Lista das empresas cadastradas.
70
Figura 24. Lista de Empresas Fonte: Autor
3.7.2.15 Formulário de Inclusão/Edição de Empresas
Formulário utilizado para a inclusão e edição de empresas.
Figura 25. Formulário de Inclusão/Edição de Empresas Fonte: Autor
71
3.7.2.16 Lista de Áreas
Lista das áreas cadastradas.
Figura 26. Lista de Áreas Fonte: Autor
3.7.2.17 Formulário de Inclusão/Edição de Áreas
Formulário utilizado para a inclusão e edição de áreas. Para facilitar a visualização
das atividades pela sua área na “Lista de Atividades”, pode-se selecionar uma cor para cada
área.
72
Figura 27. Formulário de Inclusão/Edição de Áreas Fonte: Autor
3.7.2.18 Lista de Recursos
Lista de recursos humanos cadastrados.
73
Figura 28. Lista de Recursos Fonte: Autor
3.7.2.19 Formulário de Inclusão/Edição de Recursos
Formulário utilizado para a inclusão e edição de recursos.
74
Figura 29. Formulário de Inclusão/Edição de Recursos Fonte: Autor
3.7.2.20 Formulário de Alteração de Senha
Formulário utilizado para alteração da senha de acesso de um recurso.
Figura 30. Formulário de Alteração de Senha Fonte: Autor
75
3.7.2.21 Menu de Gráficos Gerenciais
Tela de acesso aos gráficos gerenciais disponíveis no sistema.
Figura 31. Menu de Gráficos Gerenciais Fonte: Autor
76
3.7.2.22 Gráfico Percentual de Horas Executadas por Empresa
O gráfico apresenta uma estatística em forma de gráfico de “pizza” da quantidade
de horas executadas por empresa, podendo o usuário filtrar os dados por data, recurso, área e
tipo de atividade.
Figura 32. Gráfico Percentual de Horas Executadas por Empresa Fonte: Autor
77
3.7.2.23 Gráfico Percentual de Horas Executadas por Área
Similar ao gráfico anterior, este gráfico apresenta o mesmo tipo de informação,
porém estratificada por área, apresentando filtros por data, recurso, empresa e tipo de
atividade.
Figura 33. Gráfico Percentual de Horas Executadas por Área Fonte: Autor
78
3.7.2.24 Gráfico Percentual de Horas Executadas por Tipo
Utilizando o mesmo conceito dos gráficos anteriores, este gráfico apresenta os
dados de execução por tipo de atividade, podendo ser filtrados por data, recurso, área e
empresa.
Figura 34. Gráfico Percentual de Horas Executadas por Tipo Fonte: Autor
79
3.7.2.25 Gráfico de Horas Executadas por Empresa/Mês
O gráfico de horas executadas por empresa/mês apresenta os dados em forma de
gráfico de linha, mostrando a evolução das horas executadas ao longo dos meses em cada
cliente.
Os dados podem ser filtrados por data, recurso, área e tipo de atividade.
Figura 35. Gráfico de Horas Executadas por Empresa/Mês Fonte: Autor
80
3.8 VALIDAÇÃO
As técnicas de verificação de validação são fundamentais para identificar se um
software possui defeitos e está de acordo com o especificado.
As atividades de validação constituem um processo iniciado com as revisões dos
requisitos, passando pelas revisões da análise e do projeto do software e as inspeções do
código até chegar aos testes (Sommerville, 2003).
Os testes realizados no sistema utilizam técnicas dinâmicas de verificação e
validação, ou seja, dependem da execução do sistema. Conforme Koscianski (2007) estes
testes abrangem os documentos de especificação, os diagramas de análise e projeto e o
próprio código fonte.
Por ter sido construído abordando um processo iterativo, testes foram realizados
conforme o modelo indicado no tópico 3.6.3 em cada iteração. Para validação final todos os
testes foram realizados em uma última atividade de validação, buscando obter o mesmo
resultado das etapas de teste realizadas em cada iteração.
Esta verificação final apenas valida o modelo proposto do RoadMap, não
validando o sistema como ferramenta, carecendo de um processo de implantação e revisão por
parte de usuários em ambiente de produção real, para só assim verificar se o sistema
realmente atende as necessidades levantadas no tópico 3.1. Esta última etapa não está no
escopo deste trabalho.
81
4 CONCLUSÃO
Este trabalho foi motivado pelo desafio de solucionar problemas de gestão
vivenciados pelo autor em seus 10 anos de experiência no setor de desenvolvimento de
software. Para isso foi proposta e desenvolvida uma ferramenta de gestão com enfoque tanto
nos processos operacionais quanto nos processos estratégicos deste setor.
O sistema desenvolvido, apesar de básico, comporta uma série de funcionalidades
que atendem ao objetivo geral proposto no escopo do trabalho.
Nos processos operacionais, normalmente vinculados aos programadores e
analista da empresa, o sistema oferece funcionalidades que auxiliam ao membro da equipe no
controle de suas demandas diárias de trabalho, além de tornar pública as informações
relacionadas as suas atividades.
Para os gestores, o sistema organiza os projetos e as equipes e gera informações
de monitoramento dos trabalhos, podendo até antecipar possíveis atrasos e sobrecargas de
trabalho.
Na área de gráficos do sistema, os diretores podem encontrar informações
consolidadas sobre a concentração de esforços de sua empresa. Informações de cunho
estratégico como “qual cliente gera maior esforço para a equipe?” ou “qual é o tipo de
atividade mais é executada pela equipe?” podem auxiliar a direção da empresa de várias
formas, desde apoiar a renegociação e contratos até justificar a contratação de novos
profissionais.
Durante a modelagem o autor orientou-se pelo projeto e detalhamento de Casos de
Uso, que auxiliou no entendimento da solução, no fluxo de instruções da programação, no
design das interfaces e nos casos de teste. A técnica mostrou-se bastante eficiente, pois com
pouco esforço de escrita obteve-se um documento de qualidade que foi muito útil durante
todas as fases do processo de desenvolvimento.
As opções de tecnologia utilizadas no trabalho facilitaram o trabalho de
codificação, já que eram de domínio do autor. Ao utilizar o framework desenvolvido pelo
autor e baseado no ambiente web, o MorphpWeb, o sistema agregou as vantagens dos
sistemas desenvolvidos neste ambiente com características de sistemas desktop. O resultado
final do sistema mostrou-se ter ótima usabilidade e design agradável e ergonômico. O
desenvolvimento do sistema auxiliou na evolução do framework, que ao final do projeto
contava com mais componentes e funcionalidades.
82
A interface final do sistema possui os controles necessários para dar uma ampla
visibilidade de “quem está fazendo o que e quando”. Em tempo real é possível visualizar o
progresso das atividades e acompanhar os cronogramas. Por ser baseado em ambiente web
estas informações são facilmente visíveis em para qualquer usuário através de um computador
conectado à internet.
É importante salientar que não era objetivo deste trabalho cobrir todos os
processos de gestão nem todas as necessidades de uma empresa desenvolvedora de software,
mas sim desenvolver um sistema que, apesar de básico, fosse útil a empresa, atendendo aos
objetivos iniciais propostos.
A aplicação prática do sistema RoadMap em uma empresa de desenvolvimento de
software de pequeno ou médio porte encaminha a validação do mesmo, podendo demonstrar
os resultados alcançados e permitir uma análise crítica do sistema.
83
REFERÊNCIAS
ANDRADE, Maria Margarida de. Introdução à metodologia do trabalho científico. 3ª Ed., São Paulo: Editora Atlas, 1998.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, NBR ISO 10006: Gestão da Qualidade – Diretrizes para a qualidade no gerenciamento de projetos. Rio de Janeiro, 2000.
BARROS, Aidil Jesus da Silveira. Fundamentos de metodologia científica. 2ª Ed., São Paulo: Earsin Maron Books, 2000.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Campus, 2002.
CARDOSO, Caíque. UML na Prática: do problema ao sistema. Rio de Janeiro: Ed. Ciência Moderna, 2003.
COCKBURN, Alistair. Escrevendo Casos de Uso Eficazes. Porto Alegre: Bookman, 2008.
CONALLEN, Jim. Desenvolvimento de aplicações Web com UML. 2ª Ed., Rio de Janeiro: Campus, 2003.
CONVERSE, Tim. PHP, a Bíblia. 3ª Ed. Rio de Janeiro: Campus. 2004.
FAYAD, Mohamed E. Building Application Frameworks: Object-oriented Foundations of Framework Design. New Jersey, USA: Wiley Computer Publishing, 1999.
INTHURN, Cândida. Qualidade & teste de software. Florianópolis: Visual Books, 2001.
JALOTE, Pankaj. An Integrated Approach to Software Engineering. 3ª Ed. New York - USA : Springer, 2005.
JOHANNESEN, Rune Toalango. Software Engineering in the Small: Is Chaos Likely to Fall?. 2004. Disponível em: <http://tolango.com/msc/in-the-small.pdf>. Acesso em 29 ago 2008.
KOSCIANSKI, André. Qualidade de Software. 2ª Ed. São Paulo: Novatec, 2007.
LEME FILHO, Trajano. Metodologia de Desenvolvimento de Sistemas. Rio de Janeiro: Axcel Books, 2003.
MAFFEO, Bruno. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Campus. 1992.
MARTINS, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. 3ª Ed, Rio de Janeiro: Brasport, 2006.
MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral v.1.1. 2006. Disponível em: <http://www.softex.br>. Acesso em 17 ago 2008.
84
MySQL.com (Site Oficial). Disponível em: <http://www.mysql.com>. Acesso em 02 abr 2009.
PAULK, M. & Curtis, B. & Crissis, M & Weber. Capability Maturity Model for Software, Version 1.1. Technical report CMU/SEI-93-TR-24, Software Engineering Institute, 1993.
PHP.net (Site Oficial). Disponível em: <http://www.php.net>. Acesso em 28 mar 2009.
PMI, Project Management Institute. PMBOK (Project Management Body of Knowledge Guide). USA: PMI, 2004.
PRESSMAN, Roger S.. Engenharia de Software. 5ª Ed. Rio de Janeiro: McGraw-Hill, 2002.
QUADROS, Moacir. Gerência de Projetos de Software – Técnicas e Ferramentas. Florianópolis: Visual Books, 2002.
Qualidade e Produtividade no Setor de Software Brasileiro, Pesquisa de 2005. Disponível em: <www.mct.gov.br/upd_blob/0003/3662.pdf>. Acessado em 09 set 2008.
RAUEN, Fábio José. Roteiros de investigação científica. Tubarão: Editora Unisul, 2002
RAUEN, Fábio José. Roteiros de pesquisa. Rio do Sul: Nova Era, 2006.
REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informação. 1ª Ed., Rio de Janeiro: Brasport, 1999.
ROULLIER, Ana Cristina. Gerenciamento de Projetos de Software para Empresas de Pequeno Porte. 2001. Tese de Doutorado, UFPE.
SEVERINO, Antônio Joaquim. Metodologia do trabalho científico. 22ª Ed., São Paulo: Cortez, 2002.
SOARES, António Lucas. Introdução, Identificação e Análise em Engenharia de Requisitos. 2005.
SOMMERVILLE, Ian. Engenharia de Software. 6ª Ed. São Paulo: Perarson, 2003.
SPÍNOLA, Rodrigo Oliveira. Engenharia de Software – Introdução a Engenharia de Requisitos. Engenharia de Software Magazine, Rio de Janeiro, 1ª Edição de 2007.
Standish Group: The Chaos Report. Disponível em: <www.standishgroup.com/sample_research>. Acesso em 06 set 2008.
SWEBOK. Guide to the Software Engineering Body of Knowlegment. 2004. Disponível em: <http://www.swebok.org/pdfformat.html>. Acesso em 10 set 2008.
XAVIER, Carlos Magno da Silva. Metodologia de gerenciamento de projetos. Rio de Janeiro: Brasport, 2005.
WEBER, Sérgio. Um estudo de Caso para Modelagem de Processos em Micro e Pequenas Empresas de Software. 2002. Monografia, INE/UFSC. Florianópolis, 2002.