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


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


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


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


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


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


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


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.


• 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


• 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.


atividades.

Cenário Principal (cp): Consulta da lista de atividades.

Passos:


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.


atividades.

Cenário Principal (cp): Alteração do status da atividade.

Passos:


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:



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:



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:



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:



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:



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:



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:



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


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


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


Executadas por Área


Executadas por Tipo

Gráfico de Horas Executadas por

Empresa/Mês


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.

sistema de suporte À gestÃo de atividades e …

Documents