SIDEP

Sistema de Depreciação

Plano de Projeto

Alunos:

Diovane Monteiro

        Helena Penha

        Kathlen Maduro

        Renan Reis

Professor:

        Rogério P.C. Nascimento

Conteúdo

1.0 Introdução        3

1.1 Escopo do Projeto        3

1.2 Funções principais do produto de software        3

1.2.1 Requisitos Não Atendidos (Fora do Escopo)        3

1.3 Requisitos comportamentais ou de desempenho        4

1.4 Gestão e Restrições Técnicas        4

2.0 ESTIMATIVAS DO PROJETO        4

2.1 Técnicas de estimação e resultados        4

2.1.1 Técnica de estimação        5

2.2 Resultados        5

2.3 Recursos do projeto        5

3.0 ANÁLISE E GESTÃO DE RISCOS        5

3.1 Riscos do projeto        5

3.2 Tabela de riscos        5

3.3 Redução e Gestão do Risco        6

4.0 PLANEJAMENTO TEMPORAL        6

4.1 Conjunto de Tarefas do Projecto        7

4.2 Diagrama de Gantt        7

5.0 ORGANIZAÇÃO DO PESSOAL        7

5.1 Estrutura da equipe        7

5.2 Mecanismos de comunicação        8

5.3 Uso do Edu-blog como ferramenta de apoio        8

6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A        9

QUALIDADE DO PRODUTO DE SW        9

1.0 Introdução

A perspectiva do produto de software SIDEP - Sistema de Depreciação é gerenciar numa visão contábil, de maneira simples e eficaz, o patrimônio contábil da instituição.

As principais funcionalidades que o sistema deverá atender são: Gerenciamento de Usuário, Depreciação de Bens, Geração de Relatórios e Sincronização dos bens com o SIE(Sistema de Informações para o Ensino).

1.1 Âmbito do Projeto

Este projeto visa desenvolver um sistema web que tem como objetivo realizar a depreciação dos bens patrimoniais de uma organização. A depreciação é um fenômeno contábil que expressa a perda do valor que os ativos imobilizados utilizados na empresa sofrem no tempo. Entende-se por ativos imobilizados os ativos de natureza permanente e que se destinam as operações de negócio, como máquinas, veículos, móveis, imóveis e instalações. Conceitualmente,  a depreciação consiste como sendo a diminuição do valor dos bens que integram o ativo permanente, em decorrência do desgaste, perda de utilidade, ação da natureza ou obsolescência normal.

        Bens que podem ser depreciados:

1. Os bens imóveis utilizados como estabelecimento da administração.
2. Os bens móveis utilizados nas atividades operacionais, instalados em estabelecimento da empresa.
3. Os veículos do tipo caminhão, caminhonete de cabine simples ou utilitários utilizados no transporte de mercadorias e produtos adquiridos para revenda.
4. Os veículos utlizados no transporte coletivo dos empregados.
5. Projetos florestais destinados a exploração dos respectivos frutos.

Bens que não podem ser depreciados:

1. Terrenos, exceto os melhoramentos.
2. Prédios construções que não produzam rendimentos ou que sejam destinados a revenda.
3. Bens que normalmente aumentam o valor com o tempo, como obras de arte e antiguidades.
4. Bens que sejam registradas quotas de exaustão(Em termos contábeis, exaustão se relaciona com a perda dos bens ou direitos do ativo, ao longo do tempo, decorrentes de exploração, extração ou aproveitamento) como florestas destinadas ao corte e jazidas minerais.

Os bens móveis, imóveis e semoventes estão sujeitos a depreciação conforme a expectativa de vida útil de cada bem. A taxa de depreciação e os prazos de vida útil de cada bem foram fixadas nas Instruções Normativas SRF nºs. 162/98 e 130/99.  

Tabela 1 - Taxas de depreciação

        A perspectiva do produto de software SIDEP - Sistema de Depreciação é gerenciar numa visão contábil, de maneira simples e eficaz o patrimônio contábil da instituição.

O  SIDEP tem como meta principal realizar a depreciação dos ativos imobilizados da organização, mantendo um histórico das depreciações bem como prover o cálculo da depreciação de modo retroativo para corrigir os valores do patrimônio adquirido antes da implantação deste sistema.

1.2 Funções principais do produto de software

O software deve possuir as seguintes funcionalidades:

Tabela 2 - Principais funcionalidades

1.2.1 Requisitos Não Atendidos (Fora do Escopo)

        O sistema não fará o gerenciamento patrimonial da instituição. Por exemplo: tombamentos, transferências entre outros. Pois o mesmo já é realizado através do sistema SIE e não alterará a base de dados do mesmo.

1.3 Requisitos comportamentais ou de desempenho

Tabela 3 - Requisitos Comportamentais

1.4 Gestão e Restrições Técnicas

Tabela 4 - Restrições Técnicas

2.0 ESTIMATIVAS DO PROJETO

As estimativas do projeto são importantes pois proporcionarão ao gestor uma maior percepção da duração que o projeto terá, ou seja, o tempo total do projeto. Na estimativa serão efetuados os cálculos necessários para determinar o tempo de cada fase do projeto, planejamento, requisitos, análise, projeto, implementação e testes.

2.1 Técnicas de estimativa e resultados

Nesta seção será apresentado o cálculo para estimativa da duração total do projeto em dias. Para encontrar esse tempo é necessário aplicar uma técnica de estimativa e neste caso iremos utilizar a métrica adotada pela Lacertae Software, Lorenz & Kidd.

2.1.1 Técnica de estimativa

Para este projeto utilizaremos a técnica de estimativa definida pela Lacertae Software, técnica essa que é a Lorenz & Kidd. Trata-se de uma métrica orientada a classes, a qual se destaca por ser simples e fácil de utilizar. A utilização da métrica de Lorenz & Kidd consiste em:

1. Determinar a quantidade de classes chaves do projeto.
2. Encontrar o número de classes de suporte, para isso temos que identificar o tipo de Interface do Produto e usar o multiplicador(conforme a tabela abaixo) correspondente para calcular o número de  classes de suporte.

Tabela 5 - Relaçào entre tipo de interface e multiplicadores

3. Multiplicar a quantidade de classes chave pelo multiplicador para obter uma estimativa do número de classes de suporte.
4. Em seguida, calcula-se a quantidade total de classes, somando o nº de classes chave com o nº de classes de suporte.
5. Multiplica-se a quantidade total de classes pelo número médio de unidades de trabalho (dias-pessoa) por classe. Escolher um número entre 15-20 dias-pessoa por classe.
6. Determinar a quantidade do esforço estimada.
7. Calcular o tempo previsto para elaboração do projeto.

2.2 Resultados

        Resultados obtidos pela aplicação da técnica de Lorenz & Kidd:

1. O número de classes do projeto é 8.
2. Nosso projeto utilizará interface GUI, dessa forma o fator multiplicador será 2,5. O número de classes de suporte = número de classes chave x multiplicador, dessa forma,8 x 2,5 = 20 classes de suporte.
3. O total de classes do projeto será número de classes chave + número de classes de suporte = 8 + 20 = 28 classes.
4. Escolhemos o número médio de unidades de trabalho(dias-pessoa) = 17 dias-pessoa.
5. O cálculo do esforço estimado ficou da seguinte forma: 28 classes x 17 dias-pessoa = 476 dias de trabalho.
6. Considerando 3 pessoas envolvidas no projeto e 22 dias úteis de trabalho por mês => 476/3 = 158,68 dias, aproximadamente 7,2 meses

2.3 Recursos do projeto

O Projeto contará com 4 pessoas exercendo diversos papéis no projeto. Não serão utilizados recursos de software.

3.0 ANÁLISE E GESTÃO DE RISCOS

3.1 Riscos do projeto

Nesta seção serão mostrados os riscos identificados que precisam ser monitorados durante o projeto.

3.2 Tabela de riscos

Tabela com os riscos identificados e classificados conforme sua probabilidade de ocorrência e impacto esperado.

Tabela 6 - Riscos do Projeto

3.3 Redução e Gestão do Risco

        Foram selecionados os seguintes riscos de maior importância para as atividades de redução, supervisão e gestão de riscos:

1. A tecnologia ser muito nova e os membros não terem treinamento.

        Probabilidade: 80%        Impacto: Catastrófico

        Descrição: Todos os integrantes não possuem experiência na tecnologia adotada pela Lacertae SW para desenvolver o projeto.

        Estratégia de redução: Promover plano de estudos introdutórios da tecnologia.

        Plano de Contigência: Investir em treinamento na tecnologia adotada e criar uma atividade no cronograma para estudos da tecnologia e ferramentas.

        Responsável: Diovane Monteiro (10/11/2011)

2. Prazo de entrega não ser cumprido

        Probabilidade: 50%        Impacto: Catastrófico

        Descrição: Prazo estimado do projeto (7 meses) é maior que o prazo disponível para desenvolvimento do projeto (4 meses).

        Estratégia de redução: Realizar acompanhamento e controle do andamento do projeto com ajuda de ferramentas e priorizar atividades que sejam mais importantes para o atendimento dos requisitos do usuário.

        Plano de Contigência: No caso de o prazo disponível não ser suficiente, o software deverá ser entregue com as funcionalidades mais importantes como a depreciação de bens e inventário

Responsável: Diovane Monteiro (10/11/2011)        

3. Resquisitos mudarem

        Probabilidade: 90%        Impacto: Catastrófico

        Descrição: Mudanças constantes no cálculo da depreciação e no escopo inicial do projeto podem atrasar o projeto devido ao replanejamento das atividades necessárias para adequar o projeto aos novos requisitos

Etratégia de redução: Realizar reuniões periódicas com o cliente para esclarecer requisitos e regras de negócio conforme o projeto é desenvolvido.

Plano de Contigência: Adequar e replanejar atividades para atender e acomodar as mudanças nos requisitos.

Responsável: Renan Reis (10/11/2011)

4. Falha na integração com os demais sistemas        

Probabilidade: 50%        Impacto: Catastrófico

        Descrição: O sistema deverá interagir com a mesma base de dados utilizada pelo SIE. Isto poderá ocasionar falhas se o sistema não tratar estes dados de forma adequada.

Estratégia de redução: Realizar levantamento e análise da documentação disponível sobre o SIE e seu modelo de dados

Plano de Contigência: No caso de falhas ocorridas durante a execução do sistema, deverá ser utilizado um mecanismo de recuperação de falhas mantendo a integridade do banco de dados da aplicação.

Responsável: Renan Reis (10/11/2011)        

5. Há risco de um membro se ausentar antes do final do projeto        

Probabilidade: 60%        Impacto: Crítico        

Descrição: Um dos integrantes está gestante e há o risco dela se ausentar durante a execuçaão do projeto.

Estratégia de redução: Distribuição das atividades do membro em questão para os demais da equipe e treinamento de possíveis substitos e sua função.

Plano de Contigência: No caso do afastamento deste membro da equipe, todas suas tarefas deverão ser redistribuidas e replanejadas.

Responsável: Kathlen Maduro (10/11/2011)

Status: Risco ocorreu de fato. Atividades do membro em questão foram redistribuídas para os demais da equipe.

6. Membros trabalhando somente em parte do tempo        

Probabilidade: 90%        Impacto: Crítico        

Descrição: Os integrantes da equipe não tem disponibilidade de trabalhar em tempo integral na execução do projeto.

Estratégia de redução: Planejar atividades de forma que os integrantes possam completa-las no prazo estimado de acordo sua disponibilidade

Plano de Contigência: Incentivar o empenho da equipe em finais de semana, feriados e folgas.

Responsável: Kathlen Maduro (10/11/2011)        

4.0 PLANEJAMENTO TEMPORAL

4.1 Conjunto de Tarefas do Projeto

O projeto utiliza o processo OpenUp(Processo Unificado Aberto), uma metodologia livre de ferramentas e de baixo formalismo que pode ser estendido a uma variada gama de tipos de projetos e não apenas desenvolvimento de software. Foi criado a partir da parceria IBM-Eclipe  sendo uma versão simplificada do RUP, tem como fases: Concepção, Elaboração, Construção e Transição.

A ferramenta de gestão de cronograma foi utilizado o OpenProject:

4.2 Diagrama de Gantt

Figura 1 - Diagrama de Gantt

5.0 ORGANIZAÇÃO DO PESSOAL

5.1 Estrutura da equipe

A equipe inicialmente era formada por quatro membros, com a seguinte distribuição de papéis:

Com a saída de um membro por licença maternidade, obtivemos a seguinte re-distribuição:

Descrição das Responsabilidades:

• Analista  - Definir a visão geral dos requisitos, detalhar e documentar requisitos,
• Arquiteto - Analisar os reuisitos estruturais, Projetar e desenvolver a arquitetura do software,
• Desenvolvedor – Projetar solução, Planejar Testes e Construir.
• Gerente de Projeto: Planejar iterações, Desenvolver Plano de Projetos e Listar Riscos.
• Testador: Criar Casos de Teste, Implementar e Executar Testes.

5.2 Mecanismos de comunicação

A comunicação entre os integrantes da equipe será feita por meio de correio eletrônico, GTalk e/ou telefones celulares. O acompanhamento do projeto será feito semanalmente com reuniões presenciais ou a distância através de ferramentas de colaboração como Skype ou Google Docs e para registrar todas as dúvidas levantadas durante as reuniões e decisões de projeto utilizaremos o Google Groups como ferramenta de grupo de discussão.

5.3 Uso do Edu-blog como ferramenta de apoio

O Edu-blog foi utilizado como um repositório de conhecimento sobre o assunto de gerência de projetos auxiliando na elaboração do plano de projeto ao termos que utilizar o processo openUp e práticas do PMI.

6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW

Atividades de teste serão aplicadas ao final do desenvolvimento para assegurar que todas as funcionalidades do sistema são atendidas conforme foram especificadas.

Será feito acompanhamento contínuo do trabalho desenvolvido por todos os participantes do projeto.

Serão aplicadas revisões técnicas, análise e controle contínuo de riscos e as documentações do projeto e do produto serão geradas.