2. Micro Biografia Ciências da Computação , UNASP – 2005 Pós e Gestão de Projetos, USP/IPT – 2006 MBA em Tecnologia de Software, USP/Poli – 2012(Cursando) Trabalhei em grandes empresas: Borland, TempoAssist, Magna Sistema Grande Clientes: IBM, Prodesp, Unisys, Natura, Coca-Cola, Gol Linhas Aéreas, Marcos Domingues Abril/2011
3. Agenda Arquitetura X Engenharia de Software Processos de Desenvolvimento Metodologias Gestão de Configuração e Mudança Garantia de Qualidade/Maturidade Marcos Domingues Abril/2011
4. Arquitetura de Software Arquitetura de Software são as visões desenvolvidas para atender a atributos de qualidade. Visão de Banco de Dados Visão de Camadas Visão de Negócio Visão Organizacional Visão Organizacional estático Visão Funcional dinâmico Marcos Domingues Abril/2011
5. Arquitetura de Software Quais os itens de qualidade devem ser considerado? Organização Desempenho Portabilidade Confiabilidade Disponibilidade Etc. Marcos Domingues Abril/2011
6. Arquitetura de Software O projeto arquitetural pode determinar o sucesso do projeto de software O entendimento da arquitetura pelo engenheiro pode ajudá-lo a tomar decisões sobre alternativas do projeto. Marcos Domingues Abril/2011
7. Engenharia É a aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento, operações e manutenção de Software (IEEE 610.12) Marcos Domingues Abril/2011
8. Engenharia de Software Qualidade do Software Produtividade Controle sobre o desenvolvimento(Prazo, Custo, Escopo, Níveis de Qualidade) Marcos Domingues Abril/2011
9. Engenharia Na engenharia de software, você desenvolve as seguintes disciplinas: Requisitos Projeto(Analise e Design) Implementação/Desenvolvimento Teste Implantação Manutenção Gestão de Projetos Gestão de Configuração e Mudança ETC Marcos Domingues Abril/2011
10. Ciclo de Vida O Ciclo de Vida é a alma do desenvolvimento, com ele é possível planejar e controlar as atividades a serem feitas. Cascata Espiral Protótipo Processo unificado Marcos Domingues Abril/2011
16. eXtremeProgram (XP) Projeto Simples Processo em espiral Programação em Par Refatoração Continua Programação Orientada a Teste Cliente próximo da equipe de desenvolvimento Marcos Domingues Abril/2011
18. Gestão de Configuração e Mudança(SCM) Sua responsabilidade primordial é controlar mudanças. Porém, o SCM também é responsável pela identificação de SCIs individuais e várias versões do software, pela auditoria da configuração da software para garantir que ele foi adequadamente desenvolvido e pela comunicação de todas as mudanças aplicadas na configuração. Marcos Domingues Abril/2011
19. Gestão de Configuração Gerenciar a evolução do software através da solicitação formal de mudanças. Os motivos e origens da mudança pode ser os mais variados possíveis e em épocas diferentes na vida de um software Conjunto de atividades que acompanha o projeto do inicio até a faze de manutenção. Marcos Domingues Abril/2011
20. Gestão de Configuração Identificar todos os Itens do Projeto Gerenciar as modificações Facilitar a construção de diferentes verões do projeto Garantir a qualidade durante toda a evolução do Software Marcos Domingues Abril/2011
21. Ferramentas de Controle de Versão CVS (Open Source) SVN/SubVersion (OpenSource) StrarTeam(Borland) ClearCase(IBM) SourceSafe/TeamFoundation System (Microsoft) GIT (Open Source) Marcos Domingues Abril/2011
22. Gestão de Mudança O que pode acontecer se as mudanças não forem controladas: Aumento do custo do projeto; Atrasos em entregas planejadas; Impacto em outros objetos de configuração; Degradação da qualidade do software; Retrabalho. Marcos Domingues Abril/2011
23. Gestão de Mudança O que o controle de mudanças pode me informar: O que aconteceu ? Quem fez ? Quando aconteceu ? O que mais será afetado ? Marcos Domingues Abril/2011
24. Ferramentas para Gestão de Mudança Mantis (OpenSource) Bugzzila (OpenSource) Trac (OpenSource) RedMine(OpenSource) ClearQuest(IBM) StarTeam(IBM) TeamFoundation System (Microsoft) Marcos Domingues Abril/2011
25. Garantia de Qualidade/Maturidade o planejamento do projeto e o acompanhamento de resultados; o uso dos métodos e ferramentas padronizadas na organização; a adoção de Revisões Técnicas Formais; o estabelecimento e a monitoração de estratégias de testes; a revisão dos artefatos produzidos pelo processo de desenvolvimento; a busca de conformidade com os padrões de desenvolvimento de software; a implantação de medições associadas a projeto, processo e produto; a utilização de mecanismos adequados de armazenamento e recuperação de dados relativos a projetos, processos e produtos; e a busca de uma melhoria contínua no processo de desenvolvimento de software. Marcos Domingues Abril/2011
26. Verificação e Validação Verificação Estamos a construir certo o produto? Software tem de cumprir especificação. Validação Estamos a construir o produto certo? Software tem de fazer o que utilizador quer. Marcos Domingues Abril/2011
29. criado pela SEI (Software EngineeringInstitute) na CarnegieMellonUniversity
30. Solicitado pelo departamento de defesa dos EUA que necessitava de um modelo para avaliar os seus fornecedores de software. Capacitação das empresas classificadas em 5 níveis Ultima versão 2010 – 1.3 http://www.sei.cmu.edu/library/books.cfm Marcos Domingues Abril/2011
32. CMMI NÍVEL 2: GERENCIADO Gestão de Requisitos Planejamento de Projeto Monitoramento e Controle de Projeto Gestão de Acordo com Fornecedores Medição e Análise Garantia da Qualidade de Processo e Produto Gestão de Configuração NÍVEL 3: DEFINIDO Desenvolvimento de Requisitos Solução Técnica Integração de Produto Verificação Validação Foco no Processo Organizacional Definição do Processo Organizacional + IPPD Treinamento Organizacional Gestão Integrada de Projeto + IPPD Gestão de Risco Análise de Decisão Marcos Domingues Abril/2011
33. CMMI NÍVEL 4: GERENCIADO QUANTITATIVAMENTE Desempenho do Processo Organizacional Gestão Quantitativa de Projeto NÍVEL 5: EM OTIMIZAÇÃO Inovação Organizacional Análise de Causa e Solução de Problemas Marcos Domingues Abril/2011
34. Maturidade MPS.BR Iniciativa brasileira para melhorar a qualidade de Software http://www.softex.br/mpsbr/_home/default.asp Marcos Domingues Abril/2011
35. Maturidade MPS.BR A (Em Otimização) B (Gerenciado Quantitativamente) C (Definido D (Largamente Definido) E (Parcialmente Definido) F (Gerenciado) G (Parcialmente Gerenciado) Marcos Domingues Abril/2011
36. Maturidade MPS.BR A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e avaliação adequada às micros, pequenas e médias empresas. Marcos Domingues Abril/2011