UNIVERSIDADE FEDERAL DE SERGIPE DEPARTAMENTO DE COMPUTAÇÃO PROCC – PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
Disciplina: Engenharia de Software Professor: Rogério P. C. do Nascimento -
[email protected]
Plano de Projeto de Software
Carla Almeida Jenifer Vieira
Aracaju 2010
SUMÁRIO 1. INTRODUÇÃO .................................................... ............................................................................. ..................................................... ............................... ... 3 1.1 Âmbito do Projeto ............................................... ......................................................................... ................................................... ......................... 3 1.2 Funções principais do produto de Software ................................................. ........................................................... .......... 4 1.3 Requisitos comportamentais ou de performance................................................... performance................................................... 4 1.4 Gestão e Restrições Técnicas ...................................................... ............................................................................... ......................... 5 2. ESTIMATIVAS DO PROJETO .................................................. ............................................................................ .................................. ........ 6 2.1 Dados Dad os históricos h istóricos utilizados para as estimativas ................................................. .................................................... ... 6 2.2 Técnicas de estimativas e resultados ................................................................... ................................................................... 6 2.2.1 Técnica de estimativa ........................................ .................................................................. ............................................ .................. 6 2.2.1.1 Resultados ................................................... ............................................................................. ............................................... ..................... 7 2.2.2 Técnica UCP- Use Case Points ................................................... ..................................................................... .................. 8 2.2.3 Resultados ................................................ ............................................................................ ................................................... ....................... 12 2.3 Análise entre as duas Técnicas de Estimativa: ................................................... ................................................... 13 2.4 Recursos do Projeto.................................................. .............................................................................. .......................................... .............. 13 3. ANÁLISE E GESTÃO DE RISCOS ...................................................... ......................................................................... ................... 15 3.1 Riscos do Projeto ................................................... ............................................................................... ............................................. ................. 15 3.1.1 Avaliação Global dos Riscos ................................................................................ 17 3.2 Tabela de riscos..................................................... ............................................................................... ............................................. ................... 18 3.3 Redução Red ução e Gestão do Risco ................................................. ............................................................................ .............................. ... 18 3.4 Gerência de Riscos .................................................. ............................................................................ ........................................... ................. 19 4. PLANEJAMENTO DE TEMPO .......................... ...................................................... ...................................................... ............................ 21 4.1 Conjunto de Tarefas do Projeto.................................................................................... 21 5. ORGANIZAÇÃO DO PESSOAL .................................................. ............................................................................ ............................. ... 27 5.1 Estrutura da Equipe ............................................................... ......................................................................................... ............................. ... 27 5.2 Mecanismos de Comunicação .................................... .............................................................. ........................................ .............. 29 5.3 Uso do Edu-blog como ferramenta de apoio.................................................... ....................................................... ... 29 6.0 PREOCUPAÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW ...................................................... ........................................................................... ..................... 30
2
1. INTRODUÇÃO O objetivo deste documento é definir detalhadamente fatores relevantes de planejamento, execução e acompanhamento do desenvolvimento do Software GEDOC- Process Web. Além disso, expor uma visão geral sobre o sistema para apoio
ao controle e organização de documentos existentes dentro de uma empresa, de maneira que os funcionários e clientes possam gerir os documentos de forma eletrônica, com segurança e garantia do não repúdio das informações contidas em tais documentos. Nesta primeira seção, é descrito as principais funções que o sistema deve certificar como gerir os processos e fluxos das atividades de trabalho; acrescentando informações sobre os requisitos de comportamento e tempo de aplicação, seguindo das restrições técnicas existentes no Projeto.
1.1 Âmbito do Projeto O sistema GEDOC - Process Web tem como meta controlar, analisar e compreender a automação de ciclos e fluxos das atividades de trabalho existentes dentro de uma empresa de forma organizada. Com a utilização da Certificação Digital o sistema será capaz de proporcionar segurança entre as comunicações eletrônicas, além de permitir um armazenamento seguro dos documentos, autoria e até mesmo a data em que foi assinado. Com o auxílio de GED (Gerenciamento Eletrônico de Documentos), o sistema proporcionará um controle da documentação desde sua criação até o seu descarte, sendo arquivada de uma forma digital, garantindo mais segurança, durabilidade do documento, escassez do uso do papel e de espaço físico da empresa. E com o auxílio do Workflow, o sistema proporcionará uma melhor administração sob o fluxo das atividades de trabalho interligadas por setores, onde cada atividade seguirá seu fluxo conforme o andamento específico do processo.
3
1.2 Funções principais do produto de Software O escopo do GEDOC - Process Web é composto das principais funções: Disponibilização eletrônica dos documentos; Organização das informações; Opção de busca e pesquisa por documento; Auxílio as empresas para que haja um ágil controle no fluxo das atividades de trabalho entre funcionários e clientes; Maior segurança e durabilidade da documentação; Economia de espaço físico na empresa; Categorização de acesso de acordo com cada usuário; Restrição a documentos; Geração de backup. ●
●
●
●
●
●
●
●
●
Necessariamente, o sistema permite as seguintes funções ao administrador e aos usuários do sistema:
Administrador: Manter usuários do sistema; Manter as permissões ao sistema; Gerir processos.
●
●
●
Usuários: Gerir documento eletrônico; Pesquisar documento; Gerir atividade de trabalho. ●
●
●
1.3 Requisitos comportamentais ou de performance Sobre os requisitos comportamentais, as funcionalidades são consideradas críticas, através do ponto de vista da importância do correto funcionamento para a completude das atividades disponíveis. Em termos de performance, o software terá que responder adequadamente a certos requisitos, sendo os fundamentais, sobretudo a interface e acessibilidade. Desta 4
forma, é necessário que a interface que o software apresenta seja agradável para o utilizador, além disso, terá que ser composta por um conjunto de opções selecionáveis de modo que a escrita seja minimizada, deve ser também disponibilizado campos para texto, e opções a serem classificadas através de um radio group, tendo como opção Sim ou Não.
1.4 Gestão e Restrições Técnicas Restrições Técnicas:
Falta de capacitação técnica da equipe, sendo necessário um treinamento
específico;
A quantidade dos recursos é limitada;
O hardware pertencente à equipe não é compatível com a tecnologia adotada.
Sendo necessária a compra de novos equipamentos que atendam a necessidade.
Falta de experiência e prática nas ferramentas e métodos utilizados para o
desenvolvimento do software .
Restrições Temporais: O prazo definido pelo cliente é curto para o desenvolvimento da aplicação, com isso será negociado com o cliente o desenvolvimento e entrega de forma incremental, definindo marcos a serem entregues.
5
2. ESTIMATIVAS DO PROJETO A principal vantagem da estimativa é a velocidade para a tomada das decisões durante o período de levantamento da viabilidade de um negócio. A estimativa é essencial para saber lidar com previsões e cronogramas. Se não possuir uma estimativa dificilmente sabe-se o quanto já se caminhou em um projeto e o quanto atrasado ou adiantado o mesmo se encontra. Desta forma, as estimativas do projeto são de fato importantes no sentido em que o gestor terá uma maior percepção da longevidade que o projeto terá, ou seja, o tempo total do projeto. Por sua vez também pode efetuar os cálculos necessários para determinar o tempo de cada fase do projeto, fase de planejamento, requisitos, análisedesign , implementação e testes.
2.1 Dados históricos utilizados para as estimativas No momento não possuímos dados históricos, visto que nenhum membro da equipe contém experiência na realização de projetos de software . 2.2 Técnicas de estimativas e resultados Nesta seção é explicado como realizamos o cálculo do tempo de duração do projeto em dias, através da técnica de estimação Lorenz & Kidd . Outra técnica utilizada é a técnica de Use Case Points (UCP) , escolhida justamente por possibilitar a realização de estimativas de software logo no início dos processos de desenvolvimento. Como especificado, as estimativas são fundamentais para a organização e planejamento de todas as atividades ligadas ao desenvolvimento de software , e isto exige que no início do processo, seja realizada uma estimativa que oriente todo esse controle. 2.2.1 Técnica de estimativa Para realizar a estimativa deste projeto, foi utilizada a técnica de estimação Lorenz & Kidd , que é uma métrica orientada a classes e que se destaca por ser simples
6
e de fácil utilização. Segue os dados necessários para realização da técnica, seguidos dos dados correspondentes ao projeto tratado: 1- Número de Classes Chave: 6 classes. 2- Número de Classes de Suporte: 4 classes, sendo o multiplicador GUI = 2,5. 3- Número de Classes Chaves X Multiplicador (2.5): 6 X 2,5 = 15 Classes de Suporte estimadas. 4- Classes Chaves + Classes Suporte: 21 + 4 = 25 classes no total. 5- Número médio de unidades de trabalho (dias-pessoa) por classe onde a métrica Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe. Em conjunto optamos por escolher 19 dias-pessoa, por questão da pouca prática incluída às ferramentas de trabalho, como por exemplo, o “Microsoft Project 2007”, além da falta de experiência na realização de projetos. 6- Determinar a quantidade de esforço estimada: Sendo assim, o cálculo da quantidade de esforço estimada é: 25 x 19 = 475 dias de trabalho. 7- Tempo Previsto para elaboração do Projeto: Pretende-se obter os dias/meses ocorridos (incluindo os fins de semana), temos que multiplicar os dias de trabalho com os 30 dias corridos e em seguida dividir pelos 22 dias úteis: 475 x 30 = 14250/22 = 647.72 aproximadamente 648 dias corridos; 647.72/30 = 21.59 aproximadamente 22 meses corridos. Pode-se ainda calcular os dias de trabalho por pessoa, sendo assim, temos 4 membros na equipe para o desenvolvimento deste projeto, dividindo 475 dias de trabalho ficará aproximadamente 118.75 dias de trabalho para cada membro da equipe.
2.2.1.1 Resultados Sabendo-se que o total de dias de trabalho é 475, estes dias serão distribuídos de acordo com as seguintes porcentagens de distribuição dos componentes essenciais de um projeto: 1) Planejamento: 2-3% 2) Requisitos – Análise – Design: 40% 3) Geração de Código: 20% 4) Testes: 37-38% 7
Desta forma, os valores calculados neste projeto são: 1) Planejamento: 475 * 3% = 14.25 dias de trabalho 2) Requisitos – Análise – Design: 475 * 40% = 190 dias de trabalho 3) Geração de código: 475 * 20% = 95 dias de trabalho 4) Testes: 475 * 37% = 175,75 dias de trabalho trabalho
2.2.2 Técnica UCP- Use Case Points Técnica criada por Gustav Karner, em 1993, para medir projetos de software orientado a objetos. Este método permite mensurar projetos baseado no modelo de caso de uso o que permite realizar a estimativa logo no início dos projetos, durante o levantamento de requisitos. Além da avaliação do modelo de casos de uso são considerados fatores de complexidade técnica (TCF), cuja finalidade é determinar o grau de complexidade do projeto a ser construído, e fatores ambientais (EF), cuja finalidade é determinar a eficiência do projeto e o nível de experiência dos profissionais relacionados. Os passos para realização da técnica são descritos abaixo: 1) Calcular o UUCP (Unadjusted Use Case Point) : • Relacionar e classificar os atores envolvidos, de acordo com o nível de complexidade representado abaixo: Complexidade Simples
Definição Quando o ator representa um sistema externo que qu e é
Peso 1
acessado através de API ( Apllication Programming Interface ).
Médio
Quando o ator representa um sistema externo, acessado a cessado
2
através de um protocolo de Comunicação (por exemplo: TCP/IP). Completo
Quando o ator interage com o sistema através de uma
3
interface gráfica (GUI).
8
- Atores envolvidos no sistema tratado e peso de complexidade: Ator 1 - Administrador - 3 Ator 2 - Usuário - 3 Ator 3 - Central de Scaneamento - 2 Total de Peso = 8 • Relacionar e classificar os casos de usos, de acordo com o nível de complexidade representado abaixo:
Complexidade
Definição
Peso
Simples
Quando o caso de uso possui 3 ou menos transações,
5
incluindo cenários alternativos, e sua realização deve acontecer menos de 5 objetos (classes de análise). Médio
Quando o caso de uso possui de 4 a 7 transações,
10
incluindo cenários alternativos, e sua realização deve acontecer com 5 a 10 objetos (classes (c lasses de análise). Complexo
Quando o caso de uso possui mais de 7 transações,
15
incluindo cenários alternativos, e sua realização deve acontecer com mais de 10 objetos (classes de d e análise). - Relação e classificação dos casos de usos do sistema tratado: UC0 - 15 / UC1 - 5 / UC2 - 10 / UC3 - 5 / UC4 - 5 / UC5 - 15 / UC6 - 5 / UC7 - 10 / UC8 - 15 / UC9 - 15 / UC10 - 10 / UC11 - 5 / UC12 - 5 / UC13 - 5 / UC14 - 15 / UC15 - 10 / UC16 - 5 / UC17- 5 Total de Peso = 160 • Calcular efetivamente o UUCP, como segue: UUCP = Total de pesos dos atores relacionados + Total de pesos dos casos de uso relacionados. UCCP Total = 8 + 160 = 168 9
2) Calcular o TCF (Technical Complexity Factor ): ): • Atribuir um valor a cada fator numa escala de 0 a 5, onde 0 significa que o fator é irrelevante e 5 significa que é essencial. Se o fator não é importante e não é irrelevante deve-se atribuir valor 3. Código Fator
Descrição do fator
Peso
Valor (Fator)
Resultado (Peso * Fator)
F1
Sistema distribuído
2
3
6
F2
Performance
1
5
5
F3
Eficiência para o
1
5
5
1
3
3
1
3
3
usuário final (online) F4
Processamento interno complexo
F5
Código deve ser reusável
F6
Fácil para instalar
0,5
3
1,5
F7
Fácil para usar
0,5
5
2,5
F8
Portável
2
5
10
F9
Fácil para mudar
1
3
3
F10
Concorrente
1
3
3
F11
Seguro
1
5
5
F12
Fornece acesso direto
1
3
3
para third parties (sistemas/componentes externos) 10
F13
É requerido
1
3
3
treinamento do usuário para usar o software - Multiplicar o Valor(Fator) atribuído pelo respectivo peso (coluna resultado) • Totalizar o resultado da multiplicação ( TFator) = 53 • Calcular o fator de complexidade de acordo com a seguinte formula: TCF = 0.6 + (0.01 * Tfator) = (0.6 + (0.01 * 53)) = (0.6 + (0,53)) = 1,13
3) Calcular o EF (Environmental Factor ) • Atribuir um valor a cada fator numa escala de 0 a 5, onde 0 significa que o fator é irrelevante e 5 significa que é essencial. Se o fator não é importante e não é irrelevante deve-se atribuir valor 3. Código Fator
F1
Descrição do Fator Familiaridade com o processo de
Peso
Valor (Fator)
Desenvolvimento orientado
Resultado (Peso * Fator)
1.5
5
7,5
-1
3
-3
a objetos adotado F2
Colaboradores de meio período
F3
Capacidade de Análise
0,5
5
2,5
F4
Experiência em
0,5
3
1,5
1
3
3
1
5
5
desenvolvimento de aplicações deste gênero F5
Experiência em Orientação a Objetos
F6
Motivação
11
F7
Dificuldade na linguagem de
-1
5
-5
2
5
10
Programação F8
Requisitos Estáveis
- Multiplicar o Valor (Fator) atribuído pelo respectivo peso (coluna resultado) • Totalizar o resultado da multiplicação (EFator) = 21,5 • Calcular o fator de complexidade de acordo com a seguinte formula: EF = 1.4 + (0.03 * EFator) = (1.4 + (0.03 * 21,5)) = (1.4 + (0, 645)) = 2, 045
4) Calcular o UCP (Use Case Points ) • Finalmente calcular o UCP utilizando os cálculos obtidos anteriormente: UCP = UUCP * TCF * EF = 168* 1,13* 2, 045 = 338, 2228 5) Estimar o projeto em horas • Karner sugere a aplicação de 20 horas/homem por ponto de UCP. Estimativa (horas) = UCP * 20, sendo assim, de acordo com os resultados obtidos temos, (338,2228 * 20) = 7764,456. 2.2.3 Resultados UUCP(Unadjusted Use Case Point)
168
TCF (Technical Complexity Factor)
1,13
EF (Environmental Factor)
2, 045
UCP = UUCP * TCF * EF
338, 2228
- Multiplicando o valor de UCP por 20 horas/homens dá um total de 7764,456 horas.
12
2.3 Análise entre as duas Técnicas de Estimativa: - De acordo com a Técnica Lorenz & Lorenz & Kidd, temos: 475 dias de trabalho, sendo 4 membros na equipe, ficando aproximadamente 118.75 dias de trabalho para cada membro da equipe. - Já a Técnica Use Case Points, temos: Multiplicando o valor valor de UCP por por 20 horas/homens dá um total de 7764,456 horas. Desta forma, tem-se 4 pessoas trabalhando trabalhando 4 horas por dia, num total de 475 dias. Então, 4 pessoas * 4 horas * 475 dias = 7600 horas. Havendo uma diferença entre as técnicas de 164,456 horas de trabalho. 2.4 Recursos do Projeto Os recursos utilizados para a elaboração deste projeto são descritos abaixo, onde são classificados como: humanos, software , hardware e bibliográficos. Recursos Humanos: A equipe de desenvolvimento do projeto é formada por quatro membros, sendo eles: Carla Almeida - Engenheira de Software e Testadora de Software. Jacinta - Programadora Sênior de Software. Jenifer Vieira - Analista de Sistemas, Gestora de Projeto e Analista de Qualidade Juracema - Programadora Master de Software. Recursos de Software : Para o desenvolvimento do projeto foram utilizadas as seguintes ferramentas de software : Star UML (Linguagem de Modelagem Unificada), software que modela vários tipos de diagramas; BizAgi Process Modeler , uma ferramenta ferramenta para criação de fluxogramas, fluxogramas, mapas mentais e diagramas em geral; Microsoft Office 2007, processamento de texto para a criação dos documentos disponibilizados; ●
●
●
13
●
Microsoft Project 2007, utilizado para fazer o planejamento de todas as
tarefas do projeto; ●
Mozilla Firefox, browser de Internet.
Recursos Hardware: Os recursos de hardware utilizados para elaboração do projeto foram basicamente os computadores pessoais dos membros da equipe. Mas, para o desenvolvimento do software será necessário a obtenção de computadores com a configuração necessária para as respectivas ferramentas adotadas. Recursos Bibliográficos: Estes são os recursos importantes no caso de dúvidas sobre o tema tratado, os quais foram utilizamos na elaboração deste projeto:
PRESSMAN, Roger S. Engenharia de Software . 6ª ed., Editora Mcgraw Hill.
SUMMERVILLE, Ian. Engenharia de Software . 6ª ed., Editora Addison Wesley.
2006. São Paulo, 2003.
Padrão IEEE Std 1058-1998.
14
3. ANÁLISE E GESTÃO DE RISCOS Os benefícios da combinação da gestão de projetos e da gestão de riscos podem incluir: procedimentos de identificação dos riscos aperfeiçoados, procedimentos de quantificação dos riscos aperfeiçoados, processos de tomada de decisão aperfeiçoados, procedimentos para responder aos riscos aperfeiçoados, maior tolerância à aceitação dos riscos e identificação mais clara dos riscos que cada parte de um contrato irá assumir. Além disso, vale considerar que todos os projetos possuem riscos, podendo citar a alta variação, onde, embora existam aspectos nos projetos que lembrem trabalhos anteriores, cada projeto tem aspecto único e objetivos que o diferem de trabalhos anteriores de forma substancial, assim como fortes desafios para executá-los cada vez mais rapidamente. O processo de identificar e estimar riscos pode ser realizado por uma variedade de técnicas e ferramentas:
Técnicas: dentre as técnicas cita-se, como exemplo, a análise de regressão, sistema especialista e modelos estocásticos. Outras técnicas são: diagrama de influência, simulação de Monte Carlo, PERT , análise de sensibilidade, AHP, fuzzy set approach (FSA), redes neurais, árvore de decisão e análise de árvore de falhas, checklist de riscos, mapa de riscos, diagrama de causa e efeito, técnica Delphi, combinação AHP e árvore de decisão. Ferramentas: como ferramentas, existem no mercado vários softwares que permitem identificar e estimar riscos, alguns deles são o @Risk (Palisade), Crystall Ball (Oracle Corporation), Risk Radar (American Systems Corporation), Clarity (Computer Associates), Risk+ (Deltek), Risk Trak (Risk Services & Technology), sendo que muitas
ferramentas utilizam a simulação de Monte Carlo em sua programação.
3.1 Riscos do Projeto: Para identificar riscos de um projeto faça-se uma simples pergunta: O que pode dar errado e impactar o cronograma, o custo, a performance ou o escopo do projeto? Em seguida pergunte-se o que deve ser feito para evitar esse efeitos. Se não for possível evitá-los, pode-se reduzir os seus impactos? É sempre melhor evitar um risco 15
do que administrá-lo, entretanto isso deve ser feito através de um bom planejamento e não se evitando uma boa oportunidade. Neste intuito, os riscos identificados no projeto tratado se englobam em:
Rotatividade de Pessoal, ou seja, a ausência de um membro da equipe por
motivo de doença, ou por não está disponível em algum momento do projeto, ou ainda por sair da equipe.
Atraso na entrega do Hardware .
O treinamento necessário para a equipe não disponível.
Alteração nos requisitos, exigindo um retrabalho significativo.
Mudança na tecnologia adotada.
Problemas financeiros organizacionais.
Riscos
Projeto
Técnico
Negócio
Comum
Rotatividade
Especial X
de Pessoal Atraso
X
entrega do Hardware
Treinamento Requisitos
X X
Instáveis Mudanças de
X
Tecnologia Problemas
X
financeiros
16
3.1.1 Avaliação Global dos Riscos 1. Os gestores do Software e Cliente dão suporte ao projeto? Sim, o gestor é um dos participantes mais acionado no projeto. 2. Os clientes estão entusiasmados com o projeto e o produto? Sim, os clientes a todo instante possível permanece em contato. 3. Os Engenheiros de Software e os clientes entendem bem os requisitos? Sim, o levantamento e análise dos requisitos foram levantados em conjunto. 4. Os clientes estiveram envolvidos na definição de requisitos? Sim, conforme já mencionado os mesmos foram definidos em conjunto entre os stakeholdrs . 5. As expectativas dos utilizadores são realistas? Sim, visto que a análise do escopo do produto foi bem definida entre todos os stakeholdres envolvidos. 6. O âmbito do Projeto é estável? Não, o âmbito do nosso projeto teve que ser alterado diversas vezes na procura de uma maior viabilidade do produto. 7. Os Engenheiros têm competência requerida? Sim, embora são pouco experientes, os engenheiros de software têm ótima capacidade e competência necessária para a elaboração deste projeto. 8. A equipe de desenvolvimento tem experiência na tecnologia a ser implementada? Pouca experiência, mas todos os membros da equipe estão motivados para aprender.
17
3.2 Tabela de riscos Após identificar os possíveis riscos através de um “brainstorm” com a equipe de projeto, deve-se estimar a probabilidade de ocorrência desses riscos, a tabela abaixo descreve os riscos identificados com a respectiva probabilidade de ocorrência, e o impacto, caso o risco venha a ocorrer no projeto. Risco
Categoria
Probabilidade
Porcentagem
Impacto
Especial
Moderada
70%
Crítico
Negócio
Moderada
30%
Crítico
Comum
Moderada
20%
Tolerável
Projeto
Moderada
80%
Crítico
Técnico
Moderada
40%
Crítico
Negócio
Baixa
90%
Catastrófico
Rotatividade de Pessoal Atraso na entrega do hardware
Treinamento indisponível Alteração nos Requisitos Mudança de Tecnologia Problemas financeiros organizacionais
3.3 Redução e Gestão do Risco Dentre os riscos identificados, elaboraram-se as estratégias para gerenciá-los, conforme a tabela abaixo. Risco Rotatividade de Pessoal
Estratégia Reorganizar a equipe de modo que haja maior sobreposição de trabalho, onde cada membro compreenderá a tarefa dos demais. 18
Atraso na entrega do hardware
Alugar os equipamentos necessários até o momento da entrega dos novos.
Treinamento indisponível
Contratar temporariamente profissionais experientes que atendam a necessidade exigida para a realização do projeto.
Alteração nos requisitos
Extrair ao máximo as informações, incluindo-as no projeto.
Mudança de Tecnologia
Realizar pesquisas e/ou solicitar o auxílio de profissionais sobre as ferramentas apropriadas para o respectivo projeto.
Problemas financeiros
Mostrar para a alta gerência a importante
organizacionais
contribuição do projeto para com os objetivos da empresa.
3.4 Gerência de Riscos Em 1994, a Microsoft criou a Microsoft Solutions Framework (MSF) uma metodologia de gerenciamento de projetos que tem como uma de suas disciplinas o gerenciamento de riscos, este processo é cíclico e composto por seis etapas, nas quais são implementadas no projeto tratado: Etapas Identificar riscos
Descrição Permite que a equipe torne-se consciente de um problema em potencial. Esta etapa deve ser realizada o mais cedo possível e repetida com freqüência ao longo do ciclo de vida do projeto. O objetivo desta etapa é criar uma lista de riscos, que deve ser abrangente e cobrir todas as áreas do projeto. 19
Analisar e priorizar
É o processo de converter os dados, encontrados durante a fase de identificação de riscos, em informações a serem utilizadas pela equipe do projeto para a tomada de decisões. A priorização assegura que a equipe comprometa os recursos do projeto para gerir os riscos mais importantes.
Planejar e agendar
Utilização da informação obtida na análise de riscos para formular estratégias, planos e ações. O agendamento de risco permite que esses
planos
sejam
aprovados
e
incorporados na rotina da equipe. Rastrear e relatar
O
monitoramento
de
risco
permite
a
visibilidade da gestão de riscos, monitora o status dos riscos específicos e os progressos
de seus planos de ação. O relato dos riscos garante que a equipe, patrocinador e outros participantes estejam cientes da situação dos riscos do projeto e dos planos para gerenciálos. Controlar os riscos
É o processo de execução dos planos de ação para os riscos e seus relatórios de status . O controle de riscos também inclui o
processo de controle de mudanças do projeto. Aprender
Formalização
das
lições
aprendidas
e
ferramentas, de forma que o conhecimento seja reutilizável dentro da equipe e empresa.
20
4. PLANEJAMENTO DE TEMPO No planejamento de tempo, são definidas as datas de execução das tarefas e os responsáveis por tais, neste processo designa-se o Diagrama de Gantt, e o responsável pelo planejamento que é o Gestor de Projeto.
4.1 Conjunto de Tarefas do Projeto O modelo de processo de desenvolvimento escolhido, com base no produto apresentado, estrutura organizacional e equipe de trabalho, é neste caso então, indicado a utilização de um “Método Ágil”, acrescentando alguns pontos de uma metodologia “Orientada a planos”. A utilização de um Método Ágil cabe-se ao pequeno número de pessoas envolvidas no projeto, além de ser um projeto não muito duradouro, com baixa criticidade, ou seja, que há compreensão. Com relação à utilização da abordagem orientada a planos, cabe dentro da cultura da equipe, disposta a seguir corretamente uma documentação ou padronização e por maior segurança e validação dos requisitos junto ao cliente. De forma mais específica, identificamos o “Modelo V” como adoção, sendo que este modelo apresenta maior chance de sucesso quando comparado com o modelo em cascata, devido ao desenvolvimento de planos de teste desde as fases iniciais. Além disso, funciona bem para projetos pequenos, onde os requisitos são facilmente entendidos. Junto ao “Modelo V”, abordaríamos o “Método Ágil XP”, que é um processo de desenvolvimento que pode ser usado por equipes pequenas ou médias para desenvolver software de alta qualidade com orçamento e cronograma previsíveis e com o mínimo de dispêndio. Além do XP ser atualmente um dos processos ágeis mais usados na indústria. Dentro do “Modelo V”, seriam as macro-atividades: Levantamento de Requisitos; Planejamento de Teste; Teste de Integração; Implementação; ●
●
●
●
21
Dentro do “Método Ágil”, as macro-atividades seriam: s eriam: ●
Planejamento do Jogo;
●
Pequenas Liberações;
●
Testes de Cliente;
●
Design Simples;
●
Desenvolvimento Dirigido por Testes;
●
Refatoração;
●
Metáfora;
●
Integração Contínua;
●
Propriedade Coletiva;
●
Padrão de Codificação;
●
Ritmo Sustentável;
As boas práticas utilizadas de acordo com o cenário apresentado seriam: ●
Inspeção de requisitos;
●
Gerência de requisitos;
●
Gerência de Qualidade.
Depois de realizada a Estimação do Projeto de Software , a divisão do plano de tarefas pela porcentagem de tempo foi efetuada da seguinte maneira
Tarefas
Porcentagem do Tempo
Dias de Atividade
Planejamento
3%
14.25
Requisitos – Análise –
40 %
190
Geração de código
20 %
95
Manutenção e Testes
37 %
175.75
Desenho
22
4.2 Diagrama de Gantt O diagrama de Gantt é composto pela divisão em tarefas e sub-tarefas das várias fases do projeto, onde estas tarefas possuem uma data de início e conclusão, bem como estão associadas a um ou mais membros da equipe de desenvolvimento do projeto.
Imagem (Parte 1) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projeto.
23
Imagem (Parte 2) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projeto.
24
Imagem (Parte 3) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projeto.
25
Imagem (Parte 4) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projeto.
26
5. ORGANIZAÇÃO DO PESSOAL A equipe do projeto segue uma estrutura descentralizada democrática, pois, apesar de termos um gestor competente responsável pela organização dos trabalhos, as decisões são tomadas em conjunto e em consenso de todos os envolvidos, onde há comunicação. Além disso, esta é a melhor estrutura para problemas complexos e que requerem muita comunicação, produzindo um ambiente melhor e satisfação no trabalho.
5.1 Estrutura da Equipe A equipe é formada por quatro membros, onde no início dos trabalhos foram definidos claramente as funções de cada um, sendo: send o: Nome Carla Almeida
E-mail
[email protected]
Papéis Engenheira
de
Software, e Testadora
de Software. Jenifer Vieira
[email protected]
Analista de Sistemas, Gestora de Projeto e Analista de Qualidade
Juracema Oliveira
[email protected]
Programadora
Master
de Software Jacinta
[email protected]
Programadora Sênior de Software
27
A tabela a seguir mostra a descrição das principais atividades que são atribuídas e executadas pelos membros da equipe.
Papel Gestora de Projeto (GPr)
Descrição Responsável
pelo
Planejamento
e
acompanhamento das atividades. Aloca recursos, dimensiona tarefas e interage com o cliente. Analista de Sistemas (ANS)
Realiza o levantamento e análise de requisitos do software .
Engenheira de Software
Responsável pelo Projeto, pelo design da aplicação e pela implementação do sistema
Testadora
Responsável pela definição do ambiente de testes e planejamento e execução dos casos de testes, bem como o reporte dos erros e defeitos encontrados.
Programadora
Codifica
as
instruções
para
uma
linguagem de computação. Analista de Qualidade
Identifica
e
melhoria
da
gerencia qualidade
iniciativas no
de
âmbito
organizacional, apóia a gerência em atividades de controle de projetos de captação de recursos e eventos; adota e mantém
normas
de
qualidade
da
organização.
28
5.2 Mecanismos de Comunicação O processo de comunicação será feito através de ferramentas como: MSN, Skype, Google Talk, Google Docs . O acompanhamento do projeto ocorrerá semanalmente de forma presencial com todos os os membros da equipe, de forma a acatar e discutir os pontos da situação do projeto, resolver problemas em conjunto e distribuir as tarefas. 5.3 Uso do Edu-blog como ferramenta de apoio Entre as ferramentas de apoio utilizadas, o Edu-blog , foi muito útil, permitindo ao professor disponibilizar todo o material referente à disciplina e de apoio a realização deste projeto, bem como a comunicação entre o docente e todos os seus alunos.
29
6.0 PREOCUPAÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW A equipe faz uso dos itens a seguir durante todo o projeto de forma a garantir e controlar a qualidade do produto de software :
a. Gestão do Projeto de Software – É realizado um acompanhamento constante das atividades desenvolvidas por parte de todos os envolvidos no projeto. b. Revisões Técnicas Formais – As revisões são realizadas por pessoas capacitadas durante todo o ciclo, visando à identificação de erros nas fases iniciais do projeto, onde o custo para a manutenção é menor. c. Gestão de Configuração do Software – Existe um controle a cada versão do software e dos documentos gerados, visando à integridade de ambos ao longo do seu ciclo de vida. d. Métricas de Quantidade – São realizadas medições para verificar o quanto o software atende aos requisitos impostos pelo usuário/cliente. e. Análise de Riscos – Identificação, análise e controle dos riscos, elaborando-se planos de redução e de contingência. f. Testes – São realizados testes dentro de um processo definido, com o objetivo de identificar possíveis erros antes que estes se transformem em defeitos e tornem-se riscos, trazendo prejuízos para a empresa.
30
