Plano de Projeto de Software

Slides:



Advertisements
Apresentações semelhantes
Gerenciamento de Projetos
Advertisements

Ciclo de vida e organização do projeto
Engenharia de Software
Prof.ª Adriana dos Santos Caparróz Carvalho
Engenharia de Software
Planificação do Projecto de SW
Gerenciamento do escopo do projeto
Centrado na arquitetura
Mitos e Problemas Relacionados ao Software
Gerenciamento da Integração
Adélia Barros Requisitos Adélia Barros
O processo de coletar os requisitos (escopo do cliente)
1 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – Noções de Engenharia de Software COINFO – CEFET-PB Noções de Engenharia de Software.
Implementação de Sistemas
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
Principios e Conceitos de Projeto
Engenharia de Software
Organização, Sistemas e Métodos Prof. Luciano Costa.
PLANIFICAÇÃO DE UMA AVALIAÇÃO.
GESTÃO DE PROJETOS Aula 7 1.
Planejamento e controle de Projetos
ANÁLISE DE REQUISITOS DE ENGENHARIA DE SOFTWARE
José Roberto Blaschek Gerência do Escopo José Roberto Blaschek.
Engenharia de Software
Prof.Alfredo Parteli Gomes
Planejamento e Gerenciamento de Projetos
Fundamentos de Engenharia de SW
1 Cap 5 –Planejamento de Projetos de Software Ricardo L Schneider FES.
Fase de Elaboração: Fluxo de Requisitos
Processo Praxis – Fase de Concepção
Projeto: Capacitação em GP
Gerenciamento do Escopo: principais conceitos
Qualidade de Produto de Software
Gerenciamento da Integração
Engenharia de Requisitos
Engenharia de Software
Oficina Mecânica TADS 2011.
Análise e Projeto de Sistemas
REQUIREMENTS DEVELOPMENT DESENVOLVIMENTO DE REQUISITOS
Aula 4: Áreas de Conhecimento em Gerenciamento de Projeto, Escopo
Gerenciamento de Integração.
PSBD II Projeto de Sistemas de Banco de Dados II
Documentação de Software
Gerencia e Planejamento de Projetos
GESTÃO DE PROJETOS DE MANUTENÇÃO
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
Engenharia de Software
Engenharia de Software
GERENCIAMENTO DE PROJETOS DE T.I
Gabriel Bastos Machado
Gestão de Projetos de Software
Modelando Sistemas em UML
TEMA E PROBLEMA.
IEEE Melhores Práticas para Descrições de Projeto de Software (DPS)
Integração.
Planificação do Projecto de SW não é por acaso que é a Aula 13 ;)
Professora: Fabrícia F. de Souza
Aula 02 de Eng. de Requisitos
Gestão de Projetos - aula 5: organização - Profª. Vilma Tupinambá, MsC
Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro.
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
Marketing de Relacionamento
Engenharia de Software
Gerenciamento de riscos
Gerenciamento de Escopo
PRÁTICA PROFISSIONAL E ESTÁGIO SUPERVISIONADO
Engenharia de Software Conceitos e elementos 1. Engenharia   Resolução de problemas através de soluções economicamente viáveis  Motivacão: Limitação.
Gerência de Projetos Gerenciamento de Escopo. Gerenciamento de Escopo do Projeto...inclui os processos necessários para assegurar que o projeto inclui.
CMMI Capability Maturity Model Integration
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

Plano de Projeto de Software Competência: Analisar e Desenvolver o Plano de Projeto

Agenda Plano de Projeto. Definição de Escopo. Estudo de Viabilidade. Recursos. Bibliografia

Plano de Projeto Introdução; Estimativas de Projeto; Riscos do Projeto; Cronograma; Recursos do Projeto; Organização do Pessoal; Mecanismos de Tracking (rastreamento) e controle.

Plano de Projeto I. Introdução Escopo e Propósito do Documento. Objetivos do projeto: Objetivos; Funções Principais; Quesitos de desempenho; Restrições Técnicas e Administrativas.

I. Introdução Escopo do Software A primeira atividade de planejamento do projeto de software é a determinação do escopo do software. A função e o desempenho deve ser avaliada para estabelecer em escopo de projeto que seja não-ambíguo e compreensível à gerencia e aos níveis técnicos. Uma declaração do escopo de software deve ser delimitada.

I. Introdução Escopo do Software. (Definição) O Escopo descreve os dados e o controle a serem processados, a função, o desempenho, as restrições, as interfaces e a confiabilidade. As Funções descritas na declaração de escopo são avaliadas, e em alguns casos refinadas, para fornecer mais detalhes antes do início da estimativa; Como estimativas de custo e o cronograma são orientados funcionalmente, algum grau de decomposição é freqüentemente útil;

I. Introdução Considerações sobre desempenho abrangem requisitos de desempenho e tempo de resposta. Restrições identificam limites colocados no software pelo hardware externo, disponibilidade de memória ou outros sistemas existentes.

I. Introdução Obtenção da informação necessária para o Escopo De certo modo, as coisas estão sempre indefinidas no começo de um projeto de software. Uma necessidade foi definida e metas e objetivos básicos foram enunciados, mas a informação necessária para definir o escopo ainda não foi delineada.

I. Introdução Obtenção da informação necessária para o Escopo A técnica mais comumente usada para vencer a falta de comunicação entre o cliente e o desenvolvedor e iniciar o processo de comunicação é conduzir uma reunião preliminar ou uma entrevista.

I. Introdução Obtenção da informação necessária para o Escopo A primeira reunião entre o engenheiro de software(analista) e o cliente pode ter ser comparada com a timidez de um primeiro encontro entre dois adolescentes. Por exemplo: Ninguém sabe o que dizer ou perguntar; Ambos estão temerosos de serem mal- interpretados; Ambos estão pensando sobre aonde isso vai levar (Ambos Provavelmente tem expectativas radicalmente diferentes a esse respeito); Ambos desejam terminar rápido; mas ao mesmo tempo, desejam ser bem-sucedidos.

I. Introdução Obtenção da informação necessária para o Escopo Todavia a comunicação precisa ser iniciada. É sugerido que o analista comece perguntando questões de contexto livre, isto é um conjunto de perguntas que levarão ao entendimento básico do Problema, do Pessoal que deseja a solução, da natureza da solução desejada e da efetividade do primeiro encontro propriamente dito.

I. Introdução Obtenção da informação necessária para o Escopo O Primeiro conjunto de questões de contexto livre focaliza o cliente, as metas globais e os benefícios. Por exemplo, o analista poderia perguntar: Quem está por trás da solução desse trabalho? Quem vai usar a solução? Qual será o benefício econômico de uma solução bem-sucedida? Há outra fonte para a solução?

I. Introdução Obtenção da informação necessária para o Escopo O Conjunto de questões a seguir permite ao analista entender melhor o problema e ao cliente verbalizar suas percepções sobre a solução: Como você (cliente) caracteriza uma “boa” saída, gerada por uma solução bem-sucedida? Que(ais) problema(s) a solução vai resolver? Você pode me mostrar (ou descrever) o ambiente no qual a solução será usada? Existem aspectos especiais de desempenho ou de restrições que afetarão o modo pelo qual a solução é abordada?

I. Introdução Obtenção da informação necessária para o Escopo O Conjunto final das questões focaliza a efetividade da reunião. É proposto a seguinte lista(abreviada): Você é a pessoa adequada para responder a essas questões? As respostas são oficiais? As Questões são relevantes ao problema que você tem? Alguém pode dar informação adicional? Eu deveria perguntar-lhe mais alguma coisa? Essas questões e outras vão ajudar a quebrar o gelo e iniciar a comunicação, que é essencial para estabelecer o escopo do projeto.

I. Introdução Obtenção da informação necessária para o Escopo Existe um outro princípio para auxiliar o desenvolvimento do plano de Projeto chamado 5w2h.

I. Introdução 5w2h Por que? (Why?) O quê? (What?) Quando? (When?) Quem? (Who?) Onde? (Where?) Como? (How?) Quanto? (How much?)

I. Introdução Obtenção da informação necessária para o Escopo Por que (Why) o sistema está sendo desenvolvido? A resposta a esta questão permite todas as partes examinar a validade das razões comerciais para o trabalho de software. Dito de outra forma, a razão comercial justifica o gasto de pessoal, o tempo e o dinheiro?

I. Introdução Obtenção da informação necessária para o Escopo O que (What) vai ser feito, quando (When)? As respostas a essas questões ajudam a equipe a estabelecer um cronograma do projeto pela identificação de tarefas-chave do projeto e dos prazos que são exigidos pelo cliente.

I. Introdução Obtenção da informação necessária para o Escopo Quem (Who) é a responsável pela solução? O papel e a responsabilidade de cada membro da equipe de software devem ser definidos. A resposta a essa questão ajuda a conseguir isso.

I. Introdução Obtenção da informação necessária para o Escopo Onde (Where) estão localizados na organização? Nem todos os papéis e responsabilidades situam-se na própria equipe de desenvolvimento de software. O Cliente, usuários e outros interessados também tem responsabilidades.

I. Introdução Obtenção da informação necessária para o Escopo Como (How) o trabalho será conduzido técnica e gerencialmente? Uma vez estabelecido o escopo do produto, uma estratégia gerencial e técnica para o projeto deve ser definida.

I. Introdução Obtenção da informação necessária para o Escopo Quanto (How Much) é necessário de cada recurso? A resposta a essa questão é obtida pelo desenvolvimento de estimativas baseadas nas respostas às questões anteriores.

I. Introdução Viabilidade. Uma vez identificado o escopo (com a concordância do cliente), é razoável perguntar: “Podemos construir um software para satisfazer esse escopo?” O Projeto é exeqüível? Normalmente os engenheiros são pressionados a desconsiderá-las por gerentes ou clientes.

I. Introdução Viabilidade. Nem tudo o que é imaginável é exeqüível. Inclusive o Software. A exeqüibilidade de software tem 4 dimensões sólidas. Tecnológica: O projeto é exeqüível tecnicamente? Está dentro do estado da arte? Os defeitos podem ser reduzidos em um nível que satisfaça as necessidades da aplicação?

I. Introdução Viabilidade. Finança: O projeto é exeqüível financeiramente? O desenvolvimento pode ser completados a um custo que a organização de software, seu cliente ou o mercado pode pagar?

I. Introdução Viabilidade. Tempo: O prazo para o projeto chegar ao mercado vai vencer a concorrência?

I. Introdução Viabilidade. Recursos: A organização tem os recursos necessários para obter sucesso? Em alguns casos existe uma negativa na resposta, uma redução de requisitos pode ser negociada.

I. Introdução Recursos A segunda tarefa de planejamento de software é estimar os recursos necessários para realizar o esforço de desenvolvimento de software.

I. Introdução Recursos Ferramentas de hardware/software: Fornecem a infra-estrutura para apoiar o esforço de desenvolvimento Componentes de Software reusáveis: blocos de construção de software, que podem reduzir dramaticamente os custos de desenvolvimento e acelerar a entrega. Pessoal: Recurso Principal.

I. Introdução Recursos Cada recurso é especificado por quatro características: Descrição do recurso; Declaração de disponibilidade; Época em que o recurso será necessário; Prazo durante o qual o recurso será aplicado.