projetos de negócios virtuais conceitos de análise de projetos de sistemas prof: thiago pineda

Projetos de Negócios Virtuais Projetos de Negócios Virtuais

Conceitos de Análise de Projetos de Sistemas

Prof: Thiago Pineda

HistóricoHistó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.

CMM e CMMICMM 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.

Níveis CMMNíveis CMM KPA ( Key Process Área )

Áreas Chaves

– 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.

Evolução CMM para CMMIEvolução CMM para CMMI

O Que é PMBOK?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.

O Que é Metodologia?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.

Metodologias de MercadoMetodologias de Mercado

RUP (Rational Unified Process) XP (Extreme Programming) Six Sigma (Implementado pela Motorola)

O que é RUPO 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).

Diferenças RUP vs XPDiferenças RUP vs XP

Métodos ÁgeisRUPXP

DocumentaçõesPráticas

O que são Fases do ProjetoO 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.

Fase ConcepçãoFase 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

Fase de ElaboraçãoFase 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

Fase de ConcepçãoFase 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.)

Fase de TransiçãoFase 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

O que é disciplinaO 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.

RUPRUP

Visão Geral de DicionárioVisão Geral de Dicionário

Modelagem do NegócioModelagem 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.

Modelagem do NegócioModelagem do Negócio

RequisitosRequisitos

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).

RequisitosRequisitos

RequisitosRequisitos

RequisitosRequisitos

RequisitosRequisitos

Matriz de RastreabilidadeMatriz de Rastreabilidade

Estimativa de Software - Estimativa de Software - MétricasMétricasMétrica - é a medida de alguma

propriedade do software ou da sua especificação.

APF (Analise por Pontos de função) UCP (Use Case Point)

Analise e ProjetoAnalise 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).

Analise e ProjetoAnalise e Projeto

Analise e ProjetoAnalise e Projeto

Analise e ProjetoAnalise e Projeto

Analise e ProjetoAnalise e Projeto

ImplementaçãoImplementaçã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.

ImplementaçãoImplementação

ImplementaçãoImplementação

ImplementaçãoImplementação

ImplementaçãoImplementação

TestesTestes

O Processo de teste de softwareesta que baseadas em artefatos de entrada geram artefatos de saída.

TestesTestes

Testes - Testes - Iniciação do Projeto de TesteIniciaçã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

Testes - Testes - Planejamento do Projeto de TestePlanejamento 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 deveregistrar no documento de métricas do projeto de testeas métricas e valores aceitáveis.

Testes - Testes - Projeto e Preparação de ambiente.Projeto e Preparação de ambiente.

- Com base nos documentos analisados cabe ao projetista deteste a preparação dos seguintes documentos: - Caso de Teste - Procedimentos de Teste- Após concluir a tarefa acima o ambiente deve ser configuradoconforme o documento de plano de testes

- O Projetista de teste deve seguiro manual de instalação do produtopara instalar e configurar oSoftware a ser testado.

Testes - Testes - Controle do Projeto de Teste de Software.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 enão realizadas, pendências e outras ocorrências relevantes para o projeto.

- Com as informações recebidas ogerente de teste atualiza o relatóriode progresso do projeto.

Testes -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.

Testes -Testes -

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

PapeisPapeis

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.

Papeis - Analista de NegóciosPapeis - 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.

Papeis - Analista de sistemasPapeis - 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.

Papeis - Integrador de SistemasPapeis - 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.

Papeis - ProgramadorPapeis - 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.

Papeis - DBAPapeis - 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.

Papeis Papeis - Gerente de Controle de Mudanças- 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.

Papeis Papeis - Gerente de Configuração- 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.

Papeis Papeis - Gerente de Implantação- 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.

Papeis Papeis - Gerente de Projetos- 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.

Papeis Papeis - StakeHolders- 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.