Fatores Críticos de Sucesso (Fabricação de Software)

Apresentação em tema: "Fatores Críticos de Sucesso (Fabricação de Software)"— Transcrição da apresentação:

1 Fatores Críticos de Sucesso (Fabricação de Software)
Visão de Negócio (direção, gestão, administração) Clientes Pessoas (CHA) Qualidade Processos Gestão de Projetos Infra-estrutura TI/comunicação

2 Processos de Engenharia de Software
MSF – Microsoft Solutions Framework Fases: visão, planejamento, estabilização e instalação Disciplinas: projeto, riscos e competência Mais ágil e menos formal que o RUP RUP – Rational Unified Process Desenvolvido pela Rational (hoje da IBM) Processo mais utilizado atualmente XP – Extreme Programming Atividades: planejamento, projeto, codificação e teste Gera sensação de produtividade constante

3 Sobre Engenharia de Software
Qual a melhor forma de obter requisitos? Informal, fluxos de dados, DER ou casos de uso O que é mais importante para o cliente? saber logo se o projeto é viável e factível ou começar a ver telas do software funcionando O que é mais fácil gerenciar? 6 projetos de 30 dias ou 1 projeto de 6 meses Qual construção durará mais tempo? Uma feita com base na expertise de um mestre de obras especialista ou Uma feita com projeto estrutural considerando as necessidades atuais e futuras do prédio

4 RUP – Pilares Estratégicos
Dirigido por casos de uso Centrado em arquitetura Iterativo e incremental Fases e iterações Guia Arquitetura Dirige Casos de Uso

5 RUP – Fases e Objetivos Concepção Elaboração Construção Transição
Escopo e viabilidade Elaboração Factibilidade e arquitetura básica Construção Desenvolvimento gerando versão-beta Transição Testes de aceitação e entrega do produto Implantação (fase não coberta pelo RUP) Disciplinas: levantamento, capacitação, operacionalização, desativação, gestão de pessoas e de projeto.

6 RUP – Iterações São mini-projetos com objetivos: Vantagens:
Integração de middleware, versão-alfa, casos de uso ... versão-beta e produto Vantagens: Redução de riscos Percepção antecipada Quebra da complexidade Facilitação do gerenciamento Trabalho com parte dos requisitos Construção de builds executáveis Evolução incremental do sistema pela evolução iterativa e incremental de seus componentes

7 Evolução do projeto Fonte: BOEHM, Barry. Software Engineering Economics. New Jersey: Prentice Hall, 1981.

8 XP = Extreme Programming
Atividades (disciplinas e tarefas): Planejamento Planejar o que vai ser feito Projeto Projetar como será feito Codificação Implementar o que está definido Testes Testar e entregar o que foi implementado

9 Papéis do XP Programador: Cliente: Testador: Executor de testes
Planeja, projeta e codifica códigos Cliente: Conta as estórias dos requisitos e aprova os testes Testador: Executor de testes Rastreador: Procura problemas Treinador: Treina os usuários Consultor: Definidor de requisitos Chefe: Gerente do projeto

10 Comparativo de Disciplinas
Disciplinas x Metodologias Cascata MSF RUP XP Modelagem do negócio  Requisitos Análise Projeto Implementação Teste Distribuição (instalação) Configuração e mudanças Gestão de projeto Ambiente

11 Descrição da Estratégia Indicadores Estratégicos
Modelagem do Negócio Descrição da Estratégia Visão de Negócio Objetivos e Metas Estratégicos Indicadores Estratégicos De Desempenho Realidade Atual Engenharia de Processos Métricas Táticas e Operacionais Processos (o quê, quando, porquê) ‘ Papéis e Responsabilidades Informações (entrada e saída)

12 Requisitos: Uma questão de comunicação?

13 Requisitos Para que servem os requisitos?
Acordo entre os desenvolvedores e o cliente sobre o que deve ser feito Definir as fronteiras do sistema Elucidar os riscos do projeto Subsidiar a estimativa de esforços Subsidiar o planejamento do projeto Subsidiar o estudo de retorno Tangibilizar os benefícios do sistema Facilitar a gestão do escopo do sistema

14 Tipos de requisitos - FURPS+
Funcionality: Funcionalidade Usability: Usabilidade Reliability: Confiabilidade Performance Desempenho Suportability: Suportabilidade +: Restrições de projeto Requisitos de: implementação, físicos e interface

15 Análise Déc. Análise Abordagens Ferramentas 60 Tradicional Funcional
Textos e Fluxogramas 70 Estruturada Dados Diagrama de Fluxo de Dados (DFD) Diagrama de Estrutura de Dados (Modelo Conceitual) Mini-especificações e Normalização Dicionário de Dados 80 Essencial Controle Lista de Eventos e DFD Diagrama Entidade-Relacionamento (DER) Diagrama de Transição de Estados (DTE) 90 Orientada a Objetos Todos os aspectos do negócio e do sistema Equivalentes aos anteriores Modelos de casos de uso, análise e projeto Modelos de distribuição, implementação e de testes Diagramas de seqüência, estado, atividades...

16 Análise e projeto Prova de conceito arquitetural
Definir uma arquitetura candidata Refinar a arquitetura Analisar o comportamento Projetar componentes Projetar o banco de dados

17 Gestão de Projetos PMI – Project Management Institute:
Project Management Body of Knowledge (PMBOK) Prince2 – Metodologia do governo inglês: Adotada em vários países europeus TenSetp Processo de uma multinacional americana que é representante do PMI Agile Resultante de um manifesto feito por 17 especialistas em Fevereiro de 2001 em Utah – USA ISO 10006: A International Standards Organization tomou o PMI como base e fez uma simplificação

18 Testes Conceito: É a execução controlada do software visando revelar falhas (bugs). Falha: Desvio de comportamento Erro: Origem da falha Testes não provam que o software está livre de falhas. Eles minimizam este risco e aumentam a confiança. Agregam valor ao produto. São partes integrantes da qualidade.

19 Níveis de testes Quanto às pessoas: Quanto a granularidade:
Desenvolvedores Testes independentes Entidades verificadoras e certificadoras Profissionais chaves do cliente Quanto a granularidade: Testes de unidade (desenvolvedores) Testes de integração (ambos) Testes de sistema (ambos) Testes de aceitação (cliente)

20 Tipos de testes Quanto à visão do sistema:
Caixa preta (por fora do sistema) Caixa branca (por dentro do sistema) Quanto às dimensões da qualidade: Dimensão Unidade Integração Sistema ● Funcionalidade  ● Usabilidade ● Confiabilidade ● Performance ● Suportabilidade

21 Referências Obrigado! Livros: Sites: Disponível em:
DeMARCO, Tom. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989. FROTA, Álvaro. O Barato Sai Caro!, Qualitymark, SP, 1999. JACOBSON, Ivar; et al. The Unified Software Development Process. Massachusetts: 2001. KERZNER, Harold PhD. Strategic Planning for Project Management Using a Project Management Maturity Model; John Wiley & Sons, Inc., New York, 2001. LARMAN, Craig. Utilizando UML e padrões: uma introdução a análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2000. MCMENAMIN, Stephen & PALMER, John. Análise essencial de sistemas. São Paulo : McGraw-Hill, 1991. PMBOK 2004 – Project Management Body of Knowledge, PMI – Project Management Institute. YOURDON, Edward. Análise estruturada moderna. Rio de Janeiro: Campus, 1992. Sites: e Disponível em: