Your SlideShare is downloading. ×
CMM, CMMI e Ferramentas Case
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

CMM, CMMI e Ferramentas Case

3,450
views

Published on

Apresentação da disciplina TAPR na FATEC-SP - 1º Semestre/2009

Apresentação da disciplina TAPR na FATEC-SP - 1º Semestre/2009

Published in: Technology, Business

1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,450
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
1
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Adriano Edgar Fábio Fernando Luciana Nichols Seminário disciplina TAPR – FATEC SP – Profº Paulo Bernice
  • 2.
    • CMM e CMMI
    • Ferramentas CASE – Conceitos e histórico
    • Ferramentas CASE – Classificação
    • Ferramentas CASE – Exemplos
    • Geradores de Programa
    • Ferramentas CASE Open Source
    • Qualidade de Programa
  • 3.
    • Capability Maturity Model ( CMM ), também conhecido como Software CMM ( SW-CMM ) pode ser definido como sendo uma soma de "melhores práticas" para diagnóstico e avaliação de maturidade do desenvolvimento de softwares em uma organização.
    • O "CMM" não deve ser entendido como sendo uma metodologia, pois o "CMM" não diz exatamente como fazer, mas sim o que deve ser feito (melhores práticas).
  • 4.
    • O CMM descreve os estágios de maturidade através dos quais organizações passam enquanto evoluem o seu ciclo de desenvolvimento de software, através de avaliação contínua, identificação de problemas e ações corretivas dentro de uma estratégia de melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade:
      • Inicial
      • Repetível
      • Definido
      • Gerenciado
      • Otimizado
  • 5.
    • Inicial
      • A organização geralmente não dispõe de um ambiente estável. O sucesso nestas organizações depende da competência e heroísmo dos seus funcionários e não no uso de processos estruturados.
    • Repetitivo
      • No nível 2 de maturidade, o desenvolvimento do software é repetido.
      • A organização já utiliza ferramentas de Gerência de Projetos para mapear o projeto de software.
    • Definido
      • A organização possui um conjunto de processos padrões, os quais são a base do nível 3. Estes estão estabelecidos e são melhorados periodicamente. Estes processos padrões são usados para estabelecer uma consistência dentro da organização.
  • 6.
    • Gerenciado
      • Utilizando métricas precisas, o gerenciamento pode efetivamente controlar os esforços para desenvolvimento de software. Em particular, o gerenciamento pode identificar caminhos para ajustar e adaptar o processo para projetos particulares sem perda de métricas de qualidade ou desvios das especificações.
    • Otimizado
      • O nível de maturidade 5 foca no contínuo progresso do desempenho dos processos através de melhorias de inovação tecnológica e incremental. Objetivos de melhoria quantitativa dos processos para a organização são estabelecidos, continuamente revisados, refletindo as mudanças nos objetivos da organização, e usando critérios de melhoria na gerência de processos .
  • 7.
    • O CMMI (Capability Maturity Model Integration) é um conjunto de práticas de gerenciamento e de melhoria da qualidade a serem aplicadas criteriosamente no processo de desenvolvimento de software.
    • O modelo CMMI foi concebido especificamente para organizações que desenvolvem softwares, mas em seu nível de maturidade 2 o foco é a gestão de projetos, o que pode fazer com que seus conceitos possam ser facilmente aplicados em outros tipos de organização que trabalham orientadas a projetos.
  • 8.
    • O nível 2 do CMMI está dividido em sete áreas de processos chave:
      • Gerência de requisitos (REQM);
      • Planejamento de projetos (PP);
      • Acompanhamento de projetos (PMC);
      • Garantia de qualidade do processo e do produto (PPQA);
      • Medição e análise (MA);
      • Gerência de configuração (CM);
      • Gerenciamento de acordos com fornecedores (SAM).
  • 9.  
  • 10.
    • No início da Análise de Sistemas e da programação, tínhamos as seguintes características:
      • Poucas regras.
      • Regras não bem definidas.
      • Métodos ineficientes.
      • Alta freqüência de erros.
  • 11.
    • Década de 1960 : Primeiros processadores de textos para documentação de projetos.
    • Década de 1970 : Evolução dos meios gráficos e da programação estruturada.
    • Década de 1980 : Primeiras ferramentas de análise estruturada.
    • Década de 1990 : Geração de código.
  • 12. 1960 1970 1980 1990 Ferramentas de Desenvolvimento Ambientes Integrados de Modelagem Visual Ferramentas de Representação de Diagramas Ferramentas RAD Editores de Texto Compiladores Interpretadores Linkers DFDs ERs Esquemas de BDs Documentação Geração de código Realização de Testes Gestão de Projetos Integração Modelagem O-O Regras de negócio
  • 13.
    • C omputer- A ided S oftware E ngineering (“Engenharia de Software Auxiliada por Computador ”)
    • Termo originalmente criado pela companhia Nastec, em 1982.
    • Primeiros produtos comercializados:
      • GraphiText - Nastec
      • Excelerator - Intersolve
      • AD Cycle - IBM
  • 14.
    • São ferramentas que auxiliam no desenvolvimento de software ou no gerenciamento do projeto.
    • Seu maior propósito é diminuir o custo e o tempo de desenvolvimento e aumentar a qualidade de software.
  • 15.
    • Por volta dos anos 1990
    • Causa?
      • Declínio dos mainframes
    • Conseqüências
      • Disseminação de diversas ferramentas
      • Domínio do mercado Pela Computer Associates
  • 16.
    • Características que propiciaram o ápice.
      • Aperfeiçoamento dos geradores de código.
      • Conceito de re-usabilidade implementado.
      • Surgem as ferramentas CASE Integradas.
      • Melhoria na interface.
      • Ferramentas abrangiam todo ciclo de vida.
  • 17.
    • Primeira forma
      • 4 tipos
    • Segunda forma
      • 2 tipos
  • 18.
    • UPPER CASE (ou Back End)
      • Geram código automaticamente
      • Fase de concepção do software (análise e especificação e/ou modelação de requisitos)
    • LOWER CASE (ou Front End)
      • Fase de implementação (edição e compilação de código e de testes)
  • 19.
    • I-CASE ( Integrated CASE)
      • Upper e Lower CASE simultaneamente (relacionam entre si)
    • Best In Class
      • I-Case + ferramentas externas
      • Kit de ferramentas
  • 20.
    • Orientadas à função
      • Baseiam-se nas funcionalidades das ferramentas
    • Orientadas à atividade
      • I-CASE e Best in Class (specs, modelagem, implementação)
  • 21.  
  • 22.
    • Necessidade: múltiplas ferramentas CASE existentes que atendem a processos isolados sem integração
    • Conjunto de ferramentas capazes de agir de forma combinada
      • Informações
      • Dados
      • Serviços
      • Suporta todas etapas de desenvolvimento
  • 23.
    • Benefícios e Características
      • Facilidade na troca de informações
      • Garantia de qualidade
      • Atualização de documentos
      • Controle de versão
      • Aumento no controle do projeto
      • Redução de esforço
      • Melhoria na cooperação entre membros de um projeto
      • Métricas de desenvolvimento
  • 24.
    • Níveis de integração
      • Plataforma
      • Dados
          • Arquivos compartilhados
          • Estrutura de dados compartilhadas
          • Repositório compartilhado
      • Apresentação
          • Sistema de janela
          • Comando
          • Interação
      • Controle
  • 25.
    • Dificuldades de integração
      • Heterogeneidade
      • Ferramentas externas
      • Abstração de dados
      • Distribuição
  • 26.
    • Diminuição de Erros
    • Agilidade de desenvolvimento
    • Estímulo para novas metodologias
    • Redução de custos na manutenção
    • Aumento de produtividade
    • Possibilitar a Reengenharia e Engenharia Reversa
  • 27.
    • Falta de conhecimento de metodologias
    • Necessidade de treinamento intensivo dos profissionais
    • Alto custo por licença
    • Incompatibilidade de ferramentas.
  • 28.
    • I-CASE
    • Modelagem estruturada + UML
    • Aumento da produtividade
    • Gera scripts em SQL
    • Gera códigos em: Delphi, VB
    • Automatização da documentação
    • Aumento da interação com o usuário na definição do sistema
  • 29.  
  • 30.
    • Ferramenta de modelagem de dados, para ambiente Client/Server, Web e Datawarehouse
    • Modelagem de Banco de Dados através do Modelo Entidade-Relacionamento
    • Permite a construção do modelo lógico e físico
    • Documentação de sistemas já implantados
    • Manutenção de banco de dados em produção
    • Facilidade de uso
  • 31.  
  • 32.  
  • 33.  
  • 34.  
  • 35. Geradores de Programas
    • Automatiza a geração de código
    • Diminui a quantidade de erros
    • Aumento de produtividade
    • Exemplos: Genexus
      • Gerador de programas e de objetos de banco de dados
      • Tradução para linguagens do mercado: Visual Basic, Java, C#
      • Possui um módulo de gerenciamento de banco de dados e suporta os seguintes SGBD: Access, SQL Server, Oracle, DB2 entre outros
  • 36.  
  • 37.  
  • 38.  
  • 39.
    • É uma solução às altas licenças?
    • Podem substituir uma solução comercial?
  • 40. MySQL Workbench
    • Criação e edição visual da base de dados
    • Forward Engineering/Engenharia Reversa
    • Documentação
  • 41. MySQL Workbench Plataformas suportadas: Windows, Linux e MacOSX
  • 42. Umbrello UML Modeller
    • Ferramenta de modelagem UML
    • Engenharia Reversa
    • Possui interface simples e intuitiva
    • É utilizado para modelar o KDE
    • Plataformas suportadas: Linux, Solaris e BSD
    • É capaz de gerar código fonte em diversas linguagens
      • (declaração de classes, métodos e atributos), com suporte à geração de código para ActionScript, Ada, C++, CORBA IDL, Java™, JavaScript, PHP, Perl, Python, SQL e Esquema XML
  • 43. Umbrello UML Modeller
  • 44. ArgoUML
    • Ferramenta de modelagem UML
    • Possui uma interface bem completa
    • É pouco intuitivo
    • Engenharia Reversa (Java)
    • Geração de código: Java, PHP, Python, C++ e C#
    • Plataformas suportadas: Qualquer plataforma com JVM
  • 45. ArgoUML
  • 46.
    •  
    • 17 Projetos em andamento no SourceForge
    • 12 em fase de planejamento
    • 5 já possuem ferramentas disponíveis
    • 11 para Windows
    • 15 para Unix/Linux
  • 47. Exemplos Fast Case UMLObject Modeller for Linux Voodoo Thorn xFig DIA kUML ArgoUML UML Sculptor Poseidon
  • 48. Qualidade de Software X Qualidade de Programa
    • É comum confundirmos qualidade de software com qualidade de programa, mas é importante saber que elas possuem características distintas.
    • A qualidade do software diz respeito a aspectos mais globais de um software, na seu conformidade a requisitos pré-estabelecidos pelo usuário, não tratando de aspectos mais próximos à programação e sim de aspectos como funcionalidade, confiabilidade, usabilidade etc.
    • A qualidade de programa trata de como o código de um programa pode se tornar mais eficiente, com diversas diretrizes para tornar o software mais versátil, documentado, seguro e compreensível.
  • 49. Diretrizes da qualidade de programa
    • Nomes de variáveis e funções
      • Variáveis – Sempre use nomes significativos para suas variáveis, preferindo sempre substantivos para nomes de variáveis.
      • F unções - O nome da função deve dizer a operação que a função realiza, dê preferência a utilização de verbos para nomes de funções. Exemplo: calculaSomaSalario()
    • Identação
      • Deve mostrar bem a estrutura do código
      • Um código mal estruturado o torna confuso e favorece a ocorrência de erros
  • 50.  
  • 51. Sem identação...
    • <table border = &quot;0&quot; width =&quot;120%&quot;>
    • <tr><td><font face = &quot;Papyrus&quot; size = &quot;2&quot; ><a href = &quot;princ.html&quot; target = &quot;princ&quot;><img src = &quot;icone.jpg&quot; width=&quot;20&quot; height = &quot;20&quot;> Home</a></font></td></tr><tr><td>
    • <font face = &quot;Papyrus&quot; size = &quot;2&quot; ><div id=&quot;camada1&quot; > <a href=&quot;#&quot; onclick=&quot;abre_camada2();&quot; > <img src = &quot;icone.jpg&quot; width=&quot;20&quot; height = &quot;20&quot;> Principal </a> </div><div id=&quot;camada2&quot; style=&quot;display:none“> <ul type=&quot;square“> <li><a href=&quot;hist.html&quot; target = &quot;princ&quot;> A História </a> <li><a href=&quot;tec.html&quot; target = &quot;princ&quot;> Tecnologia </a> </ul></div></font></tr></td>
    • </table>
  • 52. Com identação
    • <table border = &quot;0&quot; width =&quot;120%&quot;>
    • <tr><td><font face = &quot;Papyrus&quot; size = &quot;2&quot; ><a href = &quot;princ.html&quot; target = &quot;princ&quot;><img src = &quot;icone.jpg&quot; width=&quot;20&quot; height = &quot;20&quot;> Home</a></font></td></tr>
    • <tr><td>
    • <font face = &quot;Papyrus&quot; size = &quot;2&quot; >
    • <div id=&quot;camada1&quot; >
    • <a href=&quot;#&quot; onclick=&quot;abre_camada2();&quot; > <img src = &quot;icone.jpg&quot; width=&quot;20&quot; height = &quot;20&quot;> Principal </a>
    • </div>
    • <div id=&quot;camada2&quot; style=&quot;display:none&quot;>
    • <ul type=&quot;square&quot;>
    • <li><a href=&quot;hist.html&quot; target = &quot;princ&quot;> A História </a>
    • <li><a href=&quot;tec.html&quot; target = &quot;princ&quot;> Tecnologia </a>
    • </ul>
    • </div>
    • </font>
    • </tr></td>
    • </table>
  • 53. Diretrizes da qualidade de programa
    • Evite usar comandos de desvio incondicional
      • GOTO BREAK CONTINUE RETURN terminando repetição (com exceção de quando for necessário)
      • O uso desses comandos dificulta a análise do código.
    • Utilização de constantes
      • A criação de constantes permite uma manutenção mais fácil caso certos parâmetros precisem ser mudados. Devem estar em letras maiúsculas.
        • #include <iostream.h> #include <conio.h> //apenas usada para getch(); segura a tela #define TAM 10 //10 é o numero de elementos do vetor void main(){  int vetor[TAM];  int cont;    for(cont=0; cont<TAM; cont++){      cout<<&quot;Digite os valores &quot;;      cin>>vetor[cont];    }    for(cont=0;cont<TAM;cont++)      cout<<endl<<vetor[cont];    getch(); }
  • 54. Diretrizes da qualidade de programa
    • Divisão em funções e módulos
    • As funções devem ser simples, não deve ser necessário analisar mais nada para
    • entende-la.
    • Coesão
      • Um módulo é coeso se realizar uma única tarefa bem especificada.
    • Acoplamento
      • Diz respeito ao grau de dependência entre os módulos.
  • 55. Diretrizes da qualidade de programa
    • Usar listas de verificação
    • Conduzir revisões de código
    • Compor testes de unidade
      • Testes positivos
      • Testes negativos
      • Testes de estresse
      • Testes de falha de injeção
    • Usar ferramentas de análise de código
    • Não use linguagem inapropriada no código-fonte
  • 56. Diretrizes da qualidade de programa
    • Percorrer todos os caminhos do código com um depurador
    • Evitar recursos não especificados
    • Refatorar
      • Refatoração (do inglês Refactoring) é o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.
      • Refatorar ajuda na melhora e no entendimento do código, conseqüentemente também ajuda no processo de depuração, pois é muito mais rápido e fácil encontrar uma falha num código claro e fácil de entender.
  • 57. Fatores Externos ao código
    • Eficiência
      • Bom uso dos recursos computacionais
    • Escalabilidade
      • O programa não pode se comportar de maneira inadequada em ambientes heterogêneos e complexos.
    • A Documentação do código deve cobrir:
      • Plataforma de desenvolvimento.
      • Descrição da representação dos dados (Estruturas de dados)
      • Divisão lógica do programa: módulos, classes, métodos e funções.
      • Descrição de cada módulo, classe, método e função.
      • Descrição dos algoritmos implementados.
      • Descrição dos testes realizados e dos resultados obtidos.
  • 58. ?