A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

1 Metodologia de Gestão de Projetos Definir o escopo de um projeto e a gerência de seus requisitos.

Apresentações semelhantes


Apresentação em tema: "1 Metodologia de Gestão de Projetos Definir o escopo de um projeto e a gerência de seus requisitos."— Transcrição da apresentação:

1 1 Metodologia de Gestão de Projetos Definir o escopo de um projeto e a gerência de seus requisitos

2 2 / 57 Definir o escopo de um projeto n Produto: Documento pode se chamar Proposta de Projeto, Visão Geral do Projeto, Anteprojeto, Estudo Preliminar... n Modo de fazer: Estabelecer com o cliente quais os requisitos do projeto que resolvem o problema ou aproveitam a oportunidade n Meta: Obter aprovação preliminar do documento pela gerência superior e uso de recursos para fazer o plano completo n Equipe: normalmente só o gerente do futuro projeto com os clientes.

3 3 / 57 Definir o escopo de um projeto n Cinco componentes do documento –Problema ou oportunidade –Objetivo Geral do Projeto –Objetivos Específicos do Projeto –Critérios de Sucesso –Pressupostos, Riscos e Obstáculos

4 4 / 57 Definir o escopo de um projeto n Problema ou oportunidade –Conhecimento da área onde o projeto será desenvolvido –Requisitos do cliente –Interesses da corporação –Requisitos mandatórios –Condições de satisfação do cliente

5 5 / 57 Definir o escopo de um projeto n Problema ou oportunidade n Exemplo –Laptop de US$100 – Nicolas Negroponte (MIT) –Presidência da República no Brasil – OK –30 dias para montar grupo de trabalho etc –3 anos depois, o que aconteceu? –Programa "Um computador por Aluno"

6 6 / 57 Definir o escopo de um projeto n Laptop de US$100 –Quem vai distribuir as máquinas? –Suporte técnico? –Treinamento de professores? –Geração de conteúdo? –Reposição? –Controles? –Verba para os N x US$100? –etc

7 7 / 57 Definir o escopo de um projeto n Laptop de US$100 –Após quase um ano do início do leilão, Governo espera distribuir notebooks para escolas em 2010, mas não promete que chegarão para início do ano letivo. –A notícia de que o resultado dos testes sairá em 15 dias vem a público quase um ano após a realização do leilão, que ocorreu em 17/12/2008.

8 8 / 57 Exemplo n O processo licitatório foi vencido pela Comsat, fornecedora dos laptops da indiana Encore, que ofereceu cada notebook por R$500. n Após três meses paralisado, por determinação do Tribunal de Contas da União (TCU) para investigar supostas irregularidades, o leilão foi retomado em março/2009. n No mesmo mês, o Instituto Nacional de Metrologia, Normalização e Qualidade Industrial (InMetro) deu início a testes dos equipamentos e o resultado, negativo, foi divulgado em setembro.

9 9 / 57 Exemplo n Com isso, a segunda colocada do leilão, Digibrás, passou à primeira colocação, com uma oferta final de ,00 reais, o equivalente a um custo de R$550 por laptop. n Este valor foi apresentado em 02/10/2009. Os testes de aderência desses equipamentos ficaram marcados para 13/10/09. O leilão prevê a compra de 150 mil laptops educacionais. Em 14/12/09 a empresa foi classificada para a entrega dos laptops. n A vitória da Digibrás foi divulgada pelo FNDE. Nada mais havendo a declarar, foi encerrada a sessão no dia 23 de dezembro de 2009, cuja ata foi lavrada e assinada pelo Pregoeiro e Equipe de Apoio. Você teria previsto que o projeto passaria por tudo isso?

10 10 / 57

11 No fim das contas, computadores não vão salvar a educação 11 / 57 Idealizado em 2005 pelo pesquisador Richard Negroponte, o computador educacional OLPC XO-1 foi criado com a nobre intenção de levar a tal da revolução digital a salas de aula de países pobres ao redor do mundo. Mas, distribuído desde 2008 e com 2,5 milhões de unidades espalhadas em 42 países, ele parece não ter efeito revolucionário na educação dos locais em que está presente, pelo menos na opinião do Banco Interamericano de Desenvolvimento (BID).

12 No fim das contas, computadores não vão salvar a educação 12 / 57 n De acordo com a instituição, o computador não melhorou o desempenho dos estudantes das escolas públicas do Peru, país que tem uma das educações mais deficientes do subcontinente. n No levantamento, foram pesquisados os resultados de alunos de 319 escolas do país. Os números mostram que o uso do OLPC não representou qualquer melhora nos índices de aprendizado de línguas ou matemática em relação às crianças que dispunham de uma educação convencional, com lousas tradicionais e giz.

13 No fim das contas, computadores não vão salvar a educação 13 / 57 n Além disso, os OLPC não representaram ganhos de atenção e aumento de tempo dedicado a tarefas escolares dentro ou fora de sala de aula. n Mesmo carregados com 200 livros, também não aumentaram os índices de leitura: em média, cada criança leu apenas cinco livros em casa nos últimos 15 meses. n Foi sugerido que o uso de computadores iria aumentar a motivação dos alunos, mas os resultados nos apontam em outra direção, diz o relatório do Banco.

14 No fim das contas, computadores não vão salvar a educação 14 / 57 n Os resultados foram similares a levantamentos feitos por outras instituições a respeito do uso de computadores em sala de aula. Desde 2007 o estado norte-americano do Maine adotou a política de um laptop por aluno, e até agora os estudantes não apresentaram diferenças notáveis de desempenho. n A constatação mais notável dos levantamentos sobre o uso de computadores em sala de aula foi feita em 2010 pelo governo de um estado australiano, que constatou que liderança é crucial no uso de tecnologias em salas de aula. n Ou seja, para terem sucesso em sala de aula, alunos equipados com computadores precisam, olha só, de bons professores.

15 15 / 57 Definir o escopo de um projeto n Objetivo Geral do Projeto Ser claro quanto ao alvo Estabelecer indicadores de progresso Estabelecer realisticamente o que pode ser feito com os recursos disponíveis Estabelecer quando o objetivo pode ser atingido - duração do projeto

16 16 / 57 Definir o escopo de um projeto n Objetivo Geral do Projeto –Características da sentença definidora do objetivo: 1. Uma saída / produto - o que vai ser obtido 2. Um prazo - uma data em que deve estar concluído / atingido 3. Uma medida - a métrica que vai determinar o sucesso 4. Uma ação - como o objetivo vai ser atingido

17 17 / 57 Definir o escopo de um projeto n Objetivos Específicos do Projeto –Estabelecer o mais detalhadamente possível quais são os objetivos específicos –É uma abertura do objetivo geral em itens que caracterizam aspectos que devem ser atingidos pelo projeto para que o objetivo geral seja cumprido.

18 18 / 57 Definir o escopo de um projeto n Critérios de Sucesso –Objetivo do critério de sucesso - o que deve acontecer para nós e o cliente dizermos que o projeto foi um sucesso? –Devemos partir das Condições de Satisfação que definirão, de modo geral, as bases de um critério de sucesso –O critério de satisfação do cliente e da equipe do projeto precisam ser ajustadas e isso não é necessariamente fácil –Mensurabilidade.

19 19 / 57 Definir o escopo de um projeto n Critérios de Sucesso Expressos em termos de aumento de margens, lucros crescentes, redução de tempo de produção, melhoria de produtividade, diminuição de custo de fabricação, sempre em valores tangíveis para a empresa.

20 20 / 57 Definir o escopo de um projeto n Critérios de Sucesso Se não for possível usar aquele critério: Alternativa é ter algo quantificável sobre o efeito do projeto, uma qualidade do produto entregue como ganho de eficiência ou eficácia, redução de índice de erros, tempo de resposta no atendimento, algum impacto positivo na qualidade ou satisfação do cliente.

21 21 / 57 Definir o escopo de um projeto n Pressupostos, Riscos e Obstáculos –Tecnológicos –Meio ambiente –Interpessoais –Culturais –Relações de causa e efeito

22 22 / 57 Definir o escopo de um projeto n Adendos ao documento proposto –Análise de risco –Riscos Financeiros –Estudos de Viabilidade –Análise de Custo e Benefício - as dificuldades ou vantagens causadas pelos intangíveis –Análise de ponto de equilíbrio: breakeven point –Retorno de Investimento

23 23 / 57 Definir o escopo de um projeto Análise de Custo e Benefício 1. Definir o problema com clareza 2. Descrever as condições de contorno do problema - o que é e o que não é o escopo do problema 3. Descrever as características e funcionalidades de uma boa solução 4. Identificar soluções alternativas 5. Ordenar soluções alternativas 6. Estabelecer recomendações com o raciocínio que orientou as suas escolhas 7. Prover uma estimativa do tempo e dos custos esperados

24 24 / 57 Definir o escopo de um projeto Aprovação da proposta - critérios n Qual a importância do problema para a empresa? n Quanto o projeto está relacionado com os fatores críticos de sucesso da empresa? n O objetivo geral está relacionado diretamente com o problema?

25 25 / 57 Definir o escopo de um projeto Aprovação da proposta - critérios n Os objetivos específicos são representações claras do objetivo geral? n Há suficiente valor para o negócio como medido pelos critérios de sucesso para garantir recursos para este projeto? n Está claramente estabelecida a relação entre os critérios de sucesso e os objetivos?

26 26 / 57 Definir o escopo de um projeto Aprovação da proposta - critérios n Os riscos são elevados em relação aos benefícios para o negócio da empresa neste projeto? n A gerência superior da empresa pode reduzir riscos identificados? n Admitindo aprovada a proposta, fazer o planejamento detalhado n O primeiro passo é definir as atividades do projeto.

27 27 / 57 Gerência de requisitos n Conceituação n Requisitos funcionais n Requisitos não funcionais n Requisitos inversos n Restrições de projeto e de implementação n Requisitos não técnicos n Ambiguidade na definição dos requisitos n Questões úteis

28 28 / 57 Gerência de requisitos Conceituação n Requisito é uma condição ou capacitação necessária a um usuário / cliente / mercado para solucionar um problema ou alcançar um objetivo. n É uma condição ou capacitação que um produto ou serviço precisa atender ou ter para satisfazer um contrato, padrão, especificação ou outro documento formalmente estabelecido. OK

29 29 / 57 Gerência de requisitos Conceituação n Requisito é uma função, restrição ou outra propriedade que precisa ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do futuro sistema. n A importância dos requisitos –O que está contratado –O que o cliente / mercado precisa –O que deve ser obedecido –O que é essencial no fornecimento

30 30 / 57 Gerência de requisitos Conceituação n Aos requisitos estão associados os principais problemas do desenvolvimento de projetos. n Quando não refletem as reais necessidades dos usuários, estão incompletos e /ou inconsistentes, haverá mudanças em requisitos já acordados e a dificuldade para conseguir um entendimento comum entre usuários e executores são as principais dificuldades relatadas, provocando retrabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes.

31 31 / 57 Regras de negócio n São as decisões que regem uma organização, compreendidas por políticas recomendadas e obrigatórias que governam a interação entre empregados, clientes, fornecedores e sistemas automatizados. n Expressões em diferentes níveis –Informal ou textual Todo cliente deve que ter mais de 18 anos. –Técnico Idade.cliente >= 18

32 32 / 57 Requisitos funcionais n Requisitos funcionais especificam o que o produto deve ser capaz de executar n Podem ser definidos: –do ponto de vista dinâmico: comportamento quando executado em circunstâncias determinadas –do ponto de vista estático: funções desempenhadas por cada entidade e a maneira como elas interagem

33 33 / 57 Requisitos funcionais n É importante ressaltar que os requisitos descrevem o que o produto deve fazer - e também o que ele não deve fazer - sem dizer o como fazer. n Quando o requisito é expresso em termos do seu comportamento, este item deve ser possível de ser percebido por um observador externo ao ambiente.

34 34 / 57 Requisitos não funcionais n precisão n confiabilidade n segurança n desempenho n rentabilidade n manutenabilidade n disponibilidade n recuperabilidade n proteção n usabilidade

35 35 / 57 Serviços na nuvem exigem cuidados extras perante a lei n Planos de continuidade do negócio. n Legislação do país sede do servidor do serviço. n A preocupação que a computação em nuvem traz é a exposição inevitável de dados sensíveis no caso de a empresa acabar sendo investigada por um motivo qualquer. n A infraestrutura está fora do controle da empresa, ela não tem como questionar a Justiça. E, com ordem judicial, a empresa terceira entregará os dados sem resistência.

36 36 / 57 O integrador contrata serviços de outros fornecedores n A quantidade de partes é muito importante porque normalmente há mais do que um envolvido. n Pode ser uma boa solução num primeiro momento, com potencial para se transformar em uma enorme dor de cabeça se houver a necessidade de um questionamento jurídico por quebra de contrato.

37 37 / 57 O integrador contrata serviços de outros fornecedores n Preocupações na hora de assinar os contratos: –onde estão os fornecedores; –que atividades vão realizar; –que tratamento darão aos dados da empresa; –que nível de controle os clientes terão sobre seus dados; –como será possível acessar os dados em caso de falência do fornecedor, ou suspensão de serviço, por atraso de pagamento, ou exigência judicial, como no caso do Wikileaks.

38 38 / 57 Requisitos inversos n Significam o que o produto não deve fazer n A questão da ambiguidade das funcionalidades n A questão dos limites e a importância de não se deixar uma expectativa falsa sobre o que o produto vai fazer.

39 39 / 57 Restrições de projeto e de implementação n São condições que limitam como o produto poderá ser implementado n Representam condições que deverão ser obedecidas pelos projetistas e na implementação do projeto n Estas restrições podem ser de limitações do tempo, espaço, custo, ambiental, equipamento, processos, legislação, ética, tecnologia etc

40 40 / 57 Requisitos não técnicos n Acordos n Condições contratuais n Representam limitações para a gerência do projeto, como prazo, recursos humanos e orçamento do projeto, datas, legislação, etc.

41 41 / 57 Ambiguidade na definição dos requisitos n Requisitos incompletos n Palavras de significado impreciso n Custo da ambiguidade (exemplo para SW) –Requisitos 1 –Projeto 3-6 –Fabricação 10 –Testes de desenvolvimento –Testes de aceitação –Operação –Fonte: Barry Bohem - Software Engineering Economics

42 42 / 57 Boas práticas Documentar n Uma vez compreendidos, analisados e aceitos, os requisitos devem ser documentados com um nível de detalhamento adequado, produzindo a especificação. n São boas práticas da documentação de requisitos a adoção de formulários adequados para coleta de dados e registro da especificação dos requisitos; n a identificação das fontes de informação; n a atribuição de um rótulo para todos os requisitos e o registro das regras de negócio.

43 43 / 57 Boas práticas Validar n Após terem sido documentados, é necessário que os requisitos sejam cuidadosamente validados, principalmente quanto à consistência e a completude. n Esta atividade visa identificar problemas nos requisitos, antes do início da construção. n A importância desta atividade é caracterizada pelo fato de que a correção de um erro nesta fase possui um custo muito inferior do que a correção nas fases mais adiantadas do processo de desenvolvimento.

44 44 / 57 Boas práticas Na validação dos requisitos podem ser utilizadas técnicas para inspeção e revisão da especificação de requisitos; redigidos casos de testes a partir dos requisitos e definidos os critérios de aceitação do produto. prazo? custo? qualidade?

45 45 / 57 Boas práticas Seleção de um modelo de ciclo de vida apropriado, Elaboração do plano do projeto com base nos requisitos - é comum começarem sem sequer terem escopo definido; Renegociação dos compromissos tão logo se perceba que eles não possam ser cumpridos, Gerenciamento dos riscos associados a requisitos e a criação de condições para que os requisitos possam ser rastreados ao longo do projeto.

46 46 / 57 Questões Úteis n Quem é o cliente? n O que uma solução muito bem-sucedida significa para este cliente? n Qual é a razão real para desejar solucionar este problema? n Devemos usar uma equipe de projeto com quais características? n Qual o prazo que temos para fazer o projeto? n Onde mais pode ser obtida solução para este problema?

47 47 / 57 Questões Úteis n Podemos copiar algo existente? n Que problemas este produto resolve? n Que problemas este produto pode criar? n Que ambiente este produto provavelmente encontrará? n Qual o grau de precisão necessário ou desejado ao produto? n Quais os aspectos relevantes do problema a resolver? n Quem são as pessoas certas para responder as perguntas?

48 48 / 57 Questões Úteis n As respostas dadas são oficiais? n Os requisitos estão sendo documentados e obtidas as aprovações de quem os forneceu? n É possível ver o local onde se processam as ações do processo? n Existe algo mais que possa ser perguntado para esclarecer o funcionamento do processo e evitar ambiguidades? n Há incoerências entre as respostas?

49 49 / 57 Questões Úteis n Quais os outros processos que se relacionam com esse? n Como este processo é relacionado com outros? n Quais os resultados do projeto que são fundamentais para sua avaliação positiva? n Quais os indicadores do processo? n Quais os produtos intermediários do processo?

50 50 / 57 Qualidade na indústria n A melhoria da qualidade de produtos e processos, em todo o mundo, tem decorrido da adoção de normas e padrões de referência que, garantido a confiabilidade do produto adquirido, têm protegido mercados, assim como o consumidor final, de fraudes ou danos de naturezas diversas. n O sucesso das normas ISO é o seu melhor exemplo.

51 51 / 57 Metodologias... SMART n Specific (específico) n Mesurable (mensurável) n Achievable (alcançável) n Realistic (realista) n Time bound (limitado pelo tempo)

52 Por que fazer um protótipo para o produto a prover? Uma experiência dos anos 70...

53 53 / 57 Como o cliente explicou... Como o líder de projeto entendeu... Como ficou o projeto...

54 54 / 57 Como foi construído Como o consultor de negócios o descreveu

55 55 / 57 Como o projeto foi documentado Funcionalidades implantadas... O que foi cobrado do cliente

56 56 / 57 Como foi mantido...

57 57 / 57 O que o cliente queria!


Carregar ppt "1 Metodologia de Gestão de Projetos Definir o escopo de um projeto e a gerência de seus requisitos."

Apresentações semelhantes


Anúncios Google