Projetos de Negócios Virtuais

Apresentação em tema: "Projetos de Negócios Virtuais"— Transcrição da apresentação:

1 Projetos de Negócios Virtuais
Conceitos de Análise de Projetos de Sistemas Prof: Thiago Pineda

2 Histórico Estudos realizados pelo Standish Group em 1994, nos Estados Unidos, relataram que 31% dos projetos seriam cancelados antes de sequer serem completados. Resultados adicionais indicaram que 52,7% dos projetos iriam custar 189% de sua estimativa original. Milhares de equipes no mundo que desenvolvem software, embora trabalhando em diferentes industrias e falando e escrevendo em diferentes línguas, têm os mesmos objetivos: desenvolver softwares de qualidade - em tempo e dentro do orçamento - que satisfaçam as reais necessidades dos clientes. Vários padrões, largamente adotados pelo mundo, em diversas áreas, que não propriamente desenvolvimento de software, tem sido escolhidos por organizações com diferentes objetivos. A seguir apresentamos o Modelo de Capacitação de Maturidade (Capability Maturity Model - CMM), as normas da Organização de Padronização Internacional (International Organization for Standardization - ISO) e o Processo Unificado da Rational (Rational Unified Process - RUP), de grande aceitação em nível internacional e que foram utilizados como referência para a elaboração deste documento.

3 CMM e CMMI Modelo de Capacitação de Maturidade (Capability Maturity Model - CMM), liberado em 1993, pelo SEI(Software Engineering Institute). O CMM surgiu como um padrão efetivo da indústria para gerar um processo de qualificação de software. Mais profundo e mais compreensível que os padrões ISO 9000,. O ponto central do CMM é obter como resultado o Gerenciamento de Requisitos. O objetivo deste modelo é que o processo de software possa ser repetido, controlado e medido. Apesar dos debates sobre vantagens e desvantagens do CMM, ele tem sido usado há tempo suficiente para que muitas companhias possam verificar o aumento da qualidade de seus produtos e a diminuição de seus custos de produção. Numa era de crescente aumento de competitividade, qualquer melhora na produtividade do software não pode ser ignorada. Com o objetivo de estabelecer uma compreensão comum entre clientes e a equipe de desenvolvimento de software sobre a necessidade dos clientes,o CMM leva a organização em direção a uma visão integrada onde as necessidades técnicas devem ser mantidas consistentes com as atividades desenvolvidas e com o planejamento do projeto. Para efetuar este processo, os requisitos do software devem ser documentados e revistos pelos gerentes de software e grupos afetados, incluindo representantes dos clientes e da comunidade de usuários. São cinco os níveis em que uma organização pode ser classificada: inicial, processos podem ser repetidos, processos estão definidos e documentados, gerenciamento é baseado em métricas e, por último, processos são otimizados. Tabela a seguir descreve, na primeira coluna, cada nível do CMM e, na segunda, o que será aferido para que a companhia seja aprovada naquele nível.

4 Níveis CMM KPA ( Key Process Área ) Áreas Chaves Nível 1: Inicial
São grupos de atividades relacionadas que, em conjunto, satisfazem metas relevantes à melhoria do processo. Cada nível de maturidade define um conjunto de áreas chave que devem ser executadas para que a empresa se qualifique naquele nível. Por exemplo: se uma empresa não possuir um Programa de Treinamento, a mesma não pode ser considerada uma empresa CMM nível 3. Mas ainda não basta possuir programas de treinamento. Todo o processo tem que estar documentado, padronizado e integrado. Nível 1: Inicial As qualidades alcançadas pelo software, os processos e o conhecimento pertencem às pessoas e não ao projeto; Nível 2: Repetitivo As atividades, medições, pontos de verificação estão definidos; É possível medir qualidade, custo e cronograma; Existem mecanismos formais para a correção de desvios; Os processos pertencem aos projetos e não às pessoas; Nível 3: Definido Os processos utilizados estão estabelecidos e padronizados em toda a organização; Como estão estáveis, os processos podem ser medidos quantitativamente; Os processos pertencem agora à organização e não aos projetos; Nível 4: Gerenciado Medidas de qualidade e produtividade são coletadas em todos os projetos; Como há histórico de medições, pode-se estabelecer o controle estatástico de processos; Nível 5: Otimizado A organização está engajada na melhoria contínua de seus processos; Como já se mediu e comparou as variações, pode-se melhorar seus processos; Os níveis do CMM são ordenados porque as práticas estabelecidas no nível anterior servem de base e fundamento para as práticas dos níveis seguintes. Um dos objetivos e benefícios principais do CMM é proporcionar a visibilidade apropriada do processo de desenvolvimento, tanto para o corpo técnico quanto para o corpo gerencial.

5 Evolução CMM para CMMI

6 O Que é PMBOK? Significa Project Management Body of Knowledge
Compilado pela PMI - Project Management Institute PMBOK é alinha mestra que nos conduz ao conhecimento organizado do gerenciamento de projetos O Estudo do PMBOK é Essencial para Gerentes de Projetos. Certificação PMP (Project management Professional) Hoje Contamos com Aproximadamente 46 mil profissionais certificados como PMP em todo o mundo.

7 O Que é Metodologia? Metodologia significa, o estudo dos caminhos, dos instrumentos usados para se fazer pesquisa, os quais respondem o como Fazê-la de forma eficiente.

8 Metodologias de Mercado
RUP (Rational Unified Process) XP (Extreme Programming) Six Sigma (Implementado pela Motorola)

9 O que é RUP Os padrões CMM, descritos, especificam detalhadamente O QUÊ deve ser feito. O mercado, muitas vezes, se perguntou COMO fazê-lo. Uma das empresas que se habilitou a responder esta questão foi a Rational Software Corporation que desenvolveu, com esta finalidade, o processo de engenharia de software Rational Unified Process (RUP).

10 Diferenças RUP vs XP Métodos Ágeis Práticas Documentações XP RUP

11 O que são Fases do Projeto
É o espaço de tempo entre dois marcos significativos do projeto, durante o qual objetivos são atingidos, artefatos elaborados e decisões sobre passar ou não para a próxima fase são tomadas.

12 Fase Concepção A fase de Concepção tem um foco nos riscos de negócios ou requisitos que possam inviabilizar o projeto. Esta fase é mais importante em projetos novos e mais simples em projetos de melhoria de sistemas já existentes. Porém, o foco é sempre na garantia que o projeto é viável e vale a pena ser feito. Alguns dos principais objetivos desta fase estão listados abaixo: Definir o escopo e não-escopo do projeto e os critérios de aceitação Identificar os casos de uso críticos do sistema (os cenários que definem a funcionalidade principal do sistema e influenciam as principais decisões de projeto) Estimar superficialmente os custos e cronograma de todo o projeto Estimar riscos

13 Fase de Elaboração O principal objetivo da fase de Elaboração é definir uma arquitetura que ofereça uma base estável para Análise e Projeto e Implementação. A arquitetura é desenvolvida a partir dos requisitos mais relevantes e da análise de riscos. Seguem abaixo os principais objetivos desta fase: Definir e validar um baseline da arquitetura (a validação acontece através da implementação da arquitetura) Definir um baseline do Documento de Visão Definir um plano detalhado para a fase de Construção

14 Fase de Concepção Nesta fase, todo o restante do sistema deve ser implementado e integrado em um produto. Enquanto as fases de Concepção e Elaboração têm um perfil de pesquisa, esta fase é focada em produção de software em escala. Seus principais objetivos são: Minimizar custos de desenvolvimento, evitando retrabalho Conseguir um produto com boa qualidade de forma eficiente Produzir versões o mais rápido possível (versões alfa, beta, etc.)

15 Fase de Transição O principal objetivo desta fase é instalar o software no ambiente do usuário. Esta fase se inicia quando o software está maduro o suficiente para ser colocado em produção. A fase de Transição tem os seguintes objetivos: Executar beta testes para validar o sistema em relação às expectativas do usuário Colocar o sistema em produção em paralelo com o eventual sistema legado sendo substituído Conversão de base de dados Treinamento de usuários

16 O que é disciplina As disciplinas compreendem uma seqüência de atividades que produzem um resultado de valor concreto. Cada disciplina descreve suas atividades, a iteração entre os diferentes papéis da equipe e os artefatos produzidos no decorrer das atividades.

17 RUP

18 Visão Geral de Dicionário

19 Modelagem do Negócio Esse fluxo permite que os processos da organização sejam documentados de forma clara, propiciando um entendimento comum dos usuários, clientes e desenvolvedores sobre os procedimentos e os responsáveis de cada processo. Além disto, permite um melhor entendimento dos problemas da organização, permitindo identificar oportunidades de melhorias do processo da organização. O fluxo de atividades contém uma única atividade de avaliação do processo atual através da definição das regras de negócios da instituição.

20 Modelagem do Negócio

21 Requisitos O principal objetivo da disciplina de Requisitos é guiar os desenvolvedores de maneira a obter um sistema adequado às necessidades dos clientes e usuários. Para isto, é preciso levantar e descrever os requisitos do sistema, isto é, as funcionalidades e características que o sistema deve apresentar. A disciplina de Requisitos é executada em três atividades. Em Analisar o Problema, o principal objetivo é entender o problema e as necessidades que motivam a criação do sistema. O principal artefato produzido é o Documento de Visão. Na atividade Definir o Sistema, é feito um levantamento dos casos de uso do sistema e especificações suplementares. A atividade final Refinar o Sistema especifica os casos de uso em termos de fluxo de eventos. Observe que estas atividades são repetidas a cada iteração e que algumas atividades nem sempre são executadas (depende da fase do projeto). Também não se trabalha com todos os casos de uso em uma única iteração, mas com um subconjunto a cada iteração (a metodologia é iterativa e incremental).

22 Requisitos

23 Requisitos

24 Requisitos

25 Requisitos

26 Matriz de Rastreabilidade

27 Estimativa de Software - Métricas
Métrica - é a medida de alguma propriedade do software ou da sua especificação. APF (Analise por Pontos de função) UCP (Use Case Point)

28 Analise e Projeto O principal objetivo da disciplina de Análise e Projeto é traduzir os requisitos do sistema (o que o sistema deve fazer) numa especificação de como implementá-lo. As especificações de requisitos em termos de casos de uso são transformadas em soluções orientadas a objetos. O fluxo de atividades de Análise e Projeto descreve dois contextos. O primeiro contexto é executado em qualquer fase. Analisar Casos de Uso cria as primeiras classes e diagramas do sistema. A atividade Projetar Sistema refina o modelo de análise gerado na atividade anterior incorporando elementos de projeto (novas classes, detalhamento dos atributos e métodos, definição de subsistemas e elementos da arquitetura) e define as tabelas do banco de dados. O segundo contexto trata das atividades relacionadas com o projeto da arquitetura. A atividade Projetar Arquitetura é executada durante a fase de Elaboração e quando for necessário implantar ajustes na arquitetura (independente da fase).

29 Analise e Projeto

30 Analise e Projeto

31 Analise e Projeto

32 Analise e Projeto

33 Implementação A disciplina de Implementação define atividades e passos a serem seguidos com o objetivo de criar, testar e manter, da forma mais efetiva possível, os componentes que implementam os requisitos do sistema. É responsabilidade desta disciplina construir os casos de uso que respeitam os requisitos funcionais e não-funcionais do sistema. A atividade Estruturar o Modelo de Implementação descreve em detalhes a estrutura do ambiente de desenvolvimento. Implementar Componentes trata das atividades de programação de casos de uso e testes. Sistemas de médio e grande porte possuem vários subsistemas que devem ser integrados isoladamente antes da integração do sistema completo (atividade Integrar Subsistemas). A última atividade faz a integração dos diversos subsistemas no sistema final. Como uma iteração pode produzir diversos builds antes do release ao seu final, o fluxo de atividades registra um loop de volta à Implementar Componentes.

34 Implementação

35 Implementação

36 Implementação

37 Implementação

38 Testes O Processo de teste de software esta que baseadas em artefatos de entrada geram artefatos de saída.

39 Testes

40 Testes - Iniciação do Projeto de Teste
- A atividade de iniciação começa com o cadastro de registro de sistema - Solicitação de Teste de um sistema a área técnica - Gerente de Teste deve avaliar a Solicitação de Testes

41 Testes - Planejamento do Projeto de Teste
- Uma das tarefas da atividade de planejamento é a elaboração do plano de testes - No plano de teste deve conter: - Escopo do teste - Cronograma - Recursos Humanos - Recursos de Hardware - Recursos de Software - Gerente de Teste deve registrar no documento de métricas do projeto de teste as métricas e valores aceitáveis.

42 Testes - Projeto e Preparação de ambiente.
- Com base nos documentos analisados cabe ao projetista de teste a preparação dos seguintes documentos: - Caso de Teste - Procedimentos de Teste - Após concluir a tarefa acima o ambiente deve ser configurado conforme o documento de plano de testes - O Projetista de teste deve seguir o manual de instalação do produto para instalar e configurar o Software a ser testado.

43 Testes - Controle do Projeto de Teste de Software.
- Cabe ao Gerente de Testes no final de cada tarefa, solicitar reuniao de acompanhamento. - Cada participante da equipe de teste deve repassar para o gerente de teste o resumo de cada atividade realizada e não realizadas, pendências e outras ocorrências relevantes para o projeto. - Com as informações recebidas o gerente de teste atualiza o relatório de progresso do projeto.

44 Testes - Com base nos casos de testes e procedimentos de teste, o analista de teste realiza os testes. Caso seja encontrada alguma falha, esta deve ser registrada no sistema de registro de testes. O Resultado do teste fica armazenado no documento de Relatório de Resultado dos testes.

45 Testes - Para formalizar o encerramento do projeto de teste, é realizada uma reunião com a participação do solicitante. O Relatório de resultado de testes é entregue ao solicitante.

46 Papeis Definição do comportamento e responsabilidades de um indivíduo,ou grupo de indivíduos trabalhando juntos como uma equipe, no contexto de uma organização de engenharia de software.

47 Papeis - Analista de Negócios
O analista de negócios lidera e coordena a modelagem dos processos e o levantamento das regras de negócio relevantes para o projeto, mapeando a organização para a qual o sistema está sendo desenvolvido.

48 Papeis - Analista de sistemas
O analista de sistemas lidera e coordena o levantamento de requisitos e a modelagem e especificação de casos de uso, identificando as funcionalidades e delimitando as fronteiras do sistema. É responsável, também, por definir as responsabilidades, operações e atributos das classes e módulos do sistema, determinando como estes serão ajustados às características da plataforma de desenvolvimento utilizada para o projeto.

49 Papeis - Integrador de Sistemas
O integrador é responsável pelo planejamento das integrações do projeto e pela integração propriamente dita dos componentes, implementados pelos programadores, em seus respectivos subsistemas e sistemas.

50 Papeis - Programador O programador é responsável pela implementação e teste dos componentes de acordo com os padrões estabelecidos para o projeto, de modo que possam ser integrados em subsistemas maiores. Quando houver a necessidade de implementação de componentes para a execução de testes específicos, o programador também é responsável pela implementação destes componentes pela execução de seus respectivos testes. O programador é responsável, também, pelo desenvolvimento dos instaladores do sistema.

51 Papeis - DBA O projetista de banco de dados define as tabelas, índices, views, constraints, triggers, stored procedures, schemas, ou outras construções específicas de bancos de dados necessárias ao armazenamento, obtenção e exclusão de dados ou objetos persistentes.

52 Papeis - Gerente de Controle de Mudanças
O comitê de controle de mudanças (CCM) monitora o processo de controle das mudanças ao longo do projeto. Este comitê deve ser formado por representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. Em projetos pequenos, uma única pessoa, como o gerente do projeto ou o arquiteto de software, pode desempenhar este papel.

53 Papeis - Gerente de Configuração
O gerente de configuração é responsável pela disponibilização da infra-estrutura geral de configuração e mudanças do projeto para a equipe de desenvolvimento. A disciplina Configuração e Mudanças (CM) dá suporte às atividades de desenvolvimento, garantindo que os desenvolvedores e integradores tenham áreas de trabalho apropriadas para compilar e testar seus respectivos trabalhos, e que todos os artefatos do projeto estejam disponíveis quando necessários. O gerente de configuração é responsável pela elaboração do Plano de Gerência de Configuração e por relatar estatísticas de progresso das Requisições de Mudança do projeto. O gerente de configuração, também, é responsável pelo estabelecimento das baselines do projeto e pela criação da unidade de implantação, contendo os artefatos devidos em suas versões corretas.

54 Papeis - Gerente de Implantação
O gerente de implantação é responsável pelo planejamento da transição do produto para os usuários. Estas tarefas são documentadas no Plano de Implantação.

55 Papeis - Gerente de Projetos
O gerente de projeto aloca recursos, define prioridades, coordena as interações com os clientes e usuários, e de maneira geral, tenta manter a equipe do projeto com foco nos objetivos certos. O gerente de projeto estabelece uma série de práticas para garantir a integridade e a qualidade dos artefatos do projeto.

56 Papeis - StakeHolders Os stakeholders são os interessados no projeto. Representam toda e qualquer pessoa que de alguma forma é impactada pelo projeto em si, ou por seus resultados e conseqüências. Os stakeholders não se restringem apenas aos usuários do sistema, mas incluem também os clientes (gestores, patrocinadores etc.), a equipe de desenvolvimento, entre outros.