guia de esw-np1

8/18/2019 Guia de ESW-NP1

1/27


2/27

Guia para estudo de Engenharia de Software II para NP1

2

1.1. Software sem qual idade

Projetos de software difíceis de planejar e controlar;

Custos e prazos não são mantidos;

A funcionalidade dos programas nem sempre resulta conforme

planejado;

Existem muitos defeitos nos sistemas;

A imagem da empresa é denegrida no mercado, como empresa

tecnologicamente atrasada;

1.2. Software com qual idade

Projetos, prazos e custos sob controle;

Satisfação de usuários, com necessidades atendidas na execução de

suas tarefas;

Diminuição de erros nos projetos de software;

Melhoria da posição competitiva da empresa, como instituição capaz

de acompanhar a evolução acelerada da tecnologia de hardware e

de software.

1.3. Normas de Software com qu al idade

Principais normais nacionais e internacionais:

Qualidade do Produto

ISO 9126. Características da qualidade de produtos de software.

NBR 13596 Versão brasileira da ISO 9126.

ISO 12119 Características de qualidade de pacotes de software

(software de prateleira, vendido com um produto

embalado).

ISO 9241 Requisitos ergonômicos para o trabalho em escritório

informatizado.

ISO 14598 Plano para a avaliação de produtos de software.


3/27


3

Qualidade do Processo e Organização

ISO 12207 Software Life Cycle Process. Norma para a qualidade

do processo de desenvolvimento de software.

CMM Capability Maturity Model. Modelo da SEI (Instituto deEngenharia de Software do Departamento de Defesa dos

EEUU) para avaliação da qualidade do processo de

desenvolvimento de software.

SPICE

ISO 15504

Projeto da ISO/IEC para avaliação de processo de

desenvolvimento de software. Ainda não é uma norma

oficial ISO, mas o processo está em andamento.

ISO 9000 Normas e Modelos para a Gestão e Garantia daQualidade.

1.4. Qualidade de Processo - ISO 15504 – SPICE

SPICE - Software Process Improvement and Capability Determination

O resultado do projeto está previsto para ser transformado na norma ISO

5504 -Tecnologia de Informação - Avaliação de Processos de Software.

Este modelo é divido em cinco grandes categorias de processos:

Processos Descrição.

Cliente- Fornecedor Aquisição do software, Gerência das

necessidades do Cliente, Fornecimento do

software, Operação do software, Implementação

de Serviço ao Cliente.

Engenharia Desenvolvimento de requisitos e projeto dosistema, Desenvolvimento de requisitos de

software, Integração e teste de software,

Desenvolvimento do projeto do software,

Integração e teste do sistema, Manutenção do

sistema e do software.


4/27


4

Suporte Desenvolvimento da documentação,

Desempenho da gerência de configuração,

Execução da garantia da qualidade, Verificação

dos produtos de trabalho, Validação dos produtos

de trabalho, Revisões conjuntas, Auditorias,

Resolução de problemas.

Gerência Gerir o projeto, Gerir a qualidade, Gerir riscos,

Gerir subcontratantes.

Organ ização Construção do negócio, Definição do processo,

Melhoramento do processo, Disponibilização de

recursos de treinamento, Disponibilização de

infraestrutura organizacional.

1.5. Estrutura Hierárquica de um Modelo de Qualidade

Observe-se, pela definição, que a entidade mensurável é o atributo. Qualidade da

Subcaracterística é obtida pela consolidação dos atributos e sua consolidação define a

qualidade da característica.

1.6. Qualidade de Software.

Um software de qualidade é fácil de usar, funciona corretamente, é de

fácil manutenção e mantém a integridade dos dados para evitar possíveis

falhas, fora ou não, do seu controle.


5/27


5

Os custos resultantes de defeitos ou erros provocados por falha de

softwares, tanto para as empresas de softwares como para usuários, poderiam

ser catastróficos, bancos poderiam perder milhões de dólares e clientes veriam

seus dinheiros sumirem.

Características de Qualidade

Funcionalidade: Satisfaz às necessidades explícitas e implícitas do

usuário?

Confiabilidade: Durante um período de tempo, funciona de acordo com

as condições pré-estabelecidas?

Usabilidade: É fácil de usar?

Eficiência: Não desperdiça recursos?

Facilidade de Manutenção: É fácil de alterar?

Portabilidade: É facilmente adaptável a diferentes plataformas?

Fatores de qualidade desejados

Eficiência: A facilidade com a qual as operações e informações podem

ser localizadas ou iniciadas.

Robustez: O grau com o qual o software trata dados incorreto de entrada

ou interação inapropriada com o usuário.

Riqueza: O grau em que a inte rface oferece um conjunto rico de

recursos importantes.

Qualidade de Software = Qualidade da Organização

CMM - Capability Maturity Model

BOOSTRAP - European System and Software Iniative - ESSI

Programme.

+

Qualidade do Processo

ISO 9000 - Normas e Modelos para a Gestão e Garantia da

Qualidade

SPICE - ISO 15504 - Software Process Improvement Capability

Determination ISO 12207 - Processos do Ciclo de Vida do Software.

+

Qualidade do Produto


6/27


6

Fatores e Métricas de qualidade de software de McCall (1977)

Critérios Ergonômicos de Scapin e Bastien (1993)

ISO 9126 Qualidade de Produtos de Software

ISO 9241 – Requisitos ergonômicos para o trabalho de escritório com

terminais de computadores capaz de acompanhar a evolução

acelerada da tecnologia de hardware e de software.

1.7. Qualidade no Desenvolvimento de Software.

Para ajudar nessa questão, a International Organization Standardization

(ISO) e a International Electrotechnical Comission (IEC) se uniram para editar

normas internacionais conjuntas.

A norma internacional ISO/IEC define qualidade de software como “ A

totalidade de características de um produto de software que lhe confere a

capacidade de satisfazer necessidades explícitas e implícitas”.

1.8. Modelos de Qualidade Software.

CMMI (Capabil ibit y Maturity Model Integrat ion )

Práticas necessárias à maturidade do processo de desenvolvimento

de software.

Níveis variam de 0 (inicial) até 5 (em otimização).

MPS.BR (Melhor ia de Processo s do Software Brasi leiro)

Modelo voltado para a realidade do mercado de pequenas empresas

de desenvolvimentos de software no Brasil.

Baseado nas normas ISO/IEC 12207 e 15504 e compatível com o

CMMi. Apoiado pelo Ministério de Ciência e Tecnologia, FINEP e Banco

Interativo de Desenvolvimento.

Níveis variam de A (em otimização) até G (parcialmente gerenciado).

MPT.BR (Melhor ia d o Processo de Teste Brasi leiro)

Modelo para apoiar organizações por meio do desenvolvimento da

disciplina de testes.

Baseados em diversos outros modelos, tais como CMMi e MPS.BR.


7/27


7

Níveis variam de 1 (parcialmente gerenciado) até 5 (automação e

otimização).

ISO 9001:2008

Pertencente à família ISO 9001 (gestão de qualidade para qualquer

organização).

Estabelece os requisitos para um sistema de gestão da qualidade.

Padronização de todos os processos-chave, que afetam o produto e

o cliente.

Garantir a rastreabilidade do processo e fornecer meios apropriados

de ações corretivas.

ISO 9001:2008

Pertencente à família ISO 9001 (gestão de qualidade para qualquer

organização).

Estabelece os requisitos para um sistema de gestão da qualidade.

Padronização de todos os processos-chave, que afetam o produto e

o cliente.

Garantir a rastreabilidade do processo e fornecer meios apropriadosde ações corretivas.

ISO/IEC 9126

Norma para qualidade de produto de software.

Propõe atributos de qualidade distribuídos em seis características.


8/27


8

ISO/IEC 12207

Estabelece uma estrutura comum para os processos de ciclo de vida

do software.

Visa ajudar a organização a compreender todos os componentes

presentes na aquisição e fornecimento de software.

Processos d i vi d id os em t r ê s ca tego r i as : fundamentais,

apoio e organizacionais.

ISO/IEC 15504

Conhecida como SPICE, define o processo de desenvolvimento de

software, sendo uma evolução da ISO/IEC 12207.

Possui níveis de capacidade, assim como o CMMI

1.9. O que é Produto de Software?

P ro d u to d e S o f tw a re é o c o n j u n to d e p ro g ra m a s d e

c o m p u t a d o r , procedimentos, documentação e dados associados que

compõe o software.

1.10. O que é Processo de Software?

É um conjunto de tarefas requeridas para construir um software de

qualidade.

Qual idade do Processo

A qualidade de processo é garantir que as tarefas que envolve o passo a

passo de como desenvolver um bom software estejam sendo seguidas.

1. Def inição d e Pad rões d e p ro c es s o , o “como” e “quando” as

revisões d o processo devem ser real izadas.

2. Mon itoração do p roc esso de desen volv imen to p ara assegur ar qu e

os padrões estão sendo segu ido s.

3. Relato do Proc esso de So ftware p ara a Gerência de pr ojeto

Normas q ue def inem a Qual idade do Processo de Software.

• ISO 9000 – 9001

• ISO 12207

• CMMI • PSP


9/27


9

• SPICE

• MPSBr

1.11. O que é CASE (Computer Aided Software Engeneering ).

Sistemas de software que se destinam a fornecer apoio automatizado

para as atividades de desenvolvimento de software.

Sistemas CASE são usados frequentemente para apoiar um método

específico

Upper-CASE

Ferramentas para apoiar as atividades iniciais de processo de requisitos

e de projeto;

Lower-CASE

Ferramentas para apoiar as atividades finais tais como programação,

debugging e teste.

1.12. Quais são os desafios-chave enfrentados pela engenharia de

software?

Heterogeneidade

Sistemas de software devem ser capaz de lidar com diferentes

plataformas de hardware e ambientes de execução;

Entrega

O sistema deve ser entregue ao cliente no menor tempo possível, com o

menor custo possível;

Con fiança

O usuário deve poder justificadamente depositar sua confiança no

sistema

Escala

O sistema deve funcionar adequadamente mesmo quando um grande

úmero de usuários o está usando

2.1. CICLO DE VIDA DO SOFTWARE

Um software possui um ciclo de vida relativamente curto, se nao sofrer

implementações (correções e/ou melhorias), em torno de 5 ANOS.


10/27


10

2.2. Fases do ciclo de um SW

Fonte: Sakamoto, L.: 2014.

Fase I Concepção Nascimento do Sw

Fase II Construção Analise e programação

Fase III Implantação Testes e disponibilização aos usuários

justes Ajustes pós-implantação

Fase IV Maturidade Utilização plena

Fase V Declínio Dificuldades de uso

Manutenção Tentativa de sobrevivências (ajuste e

melhorias)

Morte Parada definitiva do uso


1. Estudo Inicial:

1. Estudo de viabilidade ou levantamento de requisitos.

2. Entrevistas com usuários a fim de identificar as suas

necessidades.3. Após as entrevistas, definem-se as funções requisitadas e

elaboração de um Plano de trabalho, com limitações de prazo,

recursos humanos, orçamento, custos/benefícios das funções a

serem automatizadas.

2. Análise

1. Transforma as informações obtidas no estudo inicial em uma

especificação estrutura das necessidades dos usuários.


11/27


11

2. Nesta fase o ambiente do usuário e modelado através de

diagramas:

1. DFD – Diagrama de Fluxo de Dados

2. MER – Modelos entidade-relacionamento

3. UML – Análise Orientada a Objetos

3. Pode ser desenvolvido um modelo protótipo

3. Projeto

1. Determina as tarefas, provenientes da especificação, que cada

pessoa envolvida deverá executar.

2. Detalhamento de cada módulo do sistema e refinamento dos

diagramas criados na fase de análise.

3. O produto final e a especificação do projeto que visa relatar o

impacto do projeto interno no ambiente operacional.

4. É analisada/contemplada a arquitetura de Hw, configuração de

rede, capacidade do servidor, dimensionamento do banco de

dados e Estação de Trabalho.

4. Implementação

1. Codificação e integração de todas as funcionalidades requisitadas

pelo usuário (fase inicial) e registrado no documento de

especificações do sistema (fase projeto), através de linguagem de

programação.

2. Nesta fase, um teste inicial deve ser feito pelo programador a fim

de eliminar erros, e pelo analista com o propósito de verificar se o

programa executa conforme especificação.

5. Teste

1. A partir da especificação estruturada do sistema (gerada na fasede análise) começa a atividade de geração de casos de Teste de

Aceite.

2. Após a codificação, cada módulo será testado individualmente,

bem como sua integração com o sistema.

3. Gera-se um Plano de Testes onde se estabelece a pessoa/grupo

responsável por testar o sistema e se define procedimentos

padrões, verificando-se os possíveis erros e comparando osresultados obtidos com os esperados.


12/27


12

4. Efetuam-se Testes de Desempenho (tempo de resposta),

Testes de Vias Normais (consistência das entradas) e ao final

elabora-se o relatório com os resultados obtidos.

5. Nesta fase é importante a participação do USUARIO FINAL, paraassegurar o comprometimento.

6. Documentação

1. Consolidam-se documentos do sistema produzidos ao longo do

desenvolvimento e geram-se documentos detalhando as

funcionalidades e interação do usuário com o sistema:

1. Manual de instalação

2. Manual do usuário, a partir da especificação estruturada do

sistema (gerada na fase de análise) começa a atividade de

geração de casos de Teste de Aceito.

2. Esta documentação deverá basear-se em todo o material já

escrito.

7. Instalação

1. Entrega do sistema e documentação.

2. Dependendo da situação de entrega da infraestrutura poderá ser

gradual.

3. Treinamento.



13/27


13

Esta figura justifica o esforço no sentido de melhoria da qualidade de

produto de software e, de certa forma, sumariza diversos conceitos utilizados

no modelo SQuaRE.

Devemos analisar dois sentidos da influencia:

Situação projeta novo status;

Depende de: define o desdobramento de requisitos esclarecer

contextos de uso, usuário, tarefa, equipamento, ambiente.

Refere-se à orientações para qualidade.

2.1. Modelo SQuaRE para especificação e avaliação da qualidade de

produto de software.

Trata da qualidade de produto de software segundo a abordagem do

novo modelo que está sendo desenvolvido pela ISO/IEC que revisa as normas

existentes e cria novas normas.

Novo modelo reforça a questão de requisitos de qualidade de software,

destacando o conceito de qualidade em uso e a derivação de necessidades

para requisitos de qualidade.

Esta visão facilita o entendimento da necessidade de ampliar a eficácia

das soluções de software para problemas e oportunidades empresariais.

3.0 Capability Maturity Model (CMM).

O Modelo de Maturidade de Capacidade para Software (CMM) foi

desenvolvido pelo Instituto de Engenharia de Software (SEI). Ele descreve os

princípios e práticas relacionados à maturidade do processo de software, e seu

objetivo é ajudar as organizações a melhorarem seus processos de software

em termos de um caminho evolutivo que vai de ad hoc e processos caóticos aprocessos de software maduros e disciplinados.

O CMM é organizado em cinco níveis de maturidade. Um nível de

maturidade é uma base evolucionária bem definida direcionada a obter um

processo de software maduro. Cada nível de maturidade fornece uma camada

como base para um processo de melhora contínuo.

3.1. Os Cinco Níveis de Maturidade.


14/27


14

As seguintes caracterizações dos cinco níveis de maturidade destacam

as mudanças do processo primário feitas em cada nível (Paulk, 1994).

1. Inicial: O processo de software é caracterizado como ad hoc e,

ocasionalmente caótico mesmo. Poucos processos são definidos e o

sucesso depende de esforços individuais e heroicos.

2. Reproduzível: Os processos de administração do projeto básico são

estabelecidos para trilhar custo, cronograma e funcionalidade. A

disciplina de processo necessária é estabelecida para se repetir

sucessos anteriores em projetos com aplicações similares.

3. Definido: O processo de software para as atividades de

administração e engenharia é documentado, padronizado e integrado

num processo de software padrão para a organização. Todos os

projetos usam uma versão aprovada e feita sob medida do processo

de software padrão da organização para desenvolvimento e

manutenção de software.

4. Gerenciado: Medidas detalhadas do processo de software e da

qualidade do produto são coletadas. Ambos, o processo de software e

o produto, são entendidos e controlados quantitativamente.

5. Otimizado: Um processo de melhora contínuo é capacitado por

retorno quantitativo do processo e das ideias e tecnologias

inovadoras.

3.2. Áreas-Chave de Processo

Exceto para o nível 1, cada nível de maturidade é decomposto em várias

áreas-chave de processo que indicam as áreas que uma organização deveria

enfocar para melhorar seu processo de software. Cada área-chave deprocesso (KPA) identifica um grupo de atividades relacionadas que, quando

realizadas coletivamente, atingem um conjunto de objetivos considerados

importantes para a melhoria da capacidade do processo.

Por definição, não existem áreas-chaves de processo para o nível 1.

As áreas-chave de processo para o nível 2 enfocam os interesses

relacionados ao estabelecimento de controle básico de administração de

projeto.


15/27


15

As áreas-chave de processo para o nível 3 enfocam os problemas

organizacionais e de projeto, como a organização estabelece uma

infraestrutura que institucionaliza uma engenharia de software efetiva e

uma administração de processos em todos os projetos.

As áreas-chave de processo para o nível 4 enfocam em estabelecer

um entendimento quantitativo de ambos, o processo de software e o produto

sendo construído.

As áreas-chave de processo para o nível 5 cobrem os problemas

que ambos, organização e projetos, devem endereçar para implementar

uma melhora contínua e mensurável do processo de software.

A tabela abaixo mostra todas as áreas-chave de processo para

cada nível de maturidade:

Nível de Maturidade reas-Chave de Processo

1. Inicial Não possui áreas-chave de processo.

2. Reproduzível Administração dos Requisitos, Planejamento de

Projeto de Software, Acompanhamento de Projeto de

Software, Gerenciamento de Subcontrato de

Software, Garantia de Qualidade de Software e

Gerenciamento de Configuração de Software.

3. Definido Foco no Processo da Organização, Definição do

Processo da Organização, Programa de Treinamento,

Administração de Software Integrado, Engenharia de

Produto de Software e Revisões.

4. Gerenciado Gerenciamento da Qualidade de Software e

Gerenciamento Quantitativo do Processo.

5. Otimizado Prevenção de Defeito, Gerenciamento de Mudança

de Tecnologia e Gerenciamento de Mudança no

Processo.


16/27


16

Por conveniência, cada uma dessas áreas-chave de processo é

organizada por características comuns, que são atributos que indicam

quando a implemen tação e institucionalização de uma área-chave de

processo é efetiva, reproduzível e durável. São elas: Compromisso a

Realizar, Habilidade para Realizar, Atividades Realizadas, Medição e Análise

e Verificação da Implementação (Paulk, 1994).

Cada área-chave de processo é descrita em termos de práticas chave

que contribuem para satisfazer seus objetivos. As práticas chave descrevem a

infraestrutura e as atividades que contribuem para a implementação e

institucionalização efetiva da área-chave de processo.

A adoção da metodologia CMMI como ferramenta no gerenciamento de

projetos de Software é muito comentada e requisitada.

CMMI é uma metodologia criada pela SEI (Software Engineering

Institute) para ser um guia destinado a melhorar os processos organizacionais

e a habilidade desses em gerenciar o desenvolvimento, a aquisição e a

manutenção de produtos e serviços. O CMMI organiza as práticas, que já são

consideradas efetivas, em uma estrutura que visa auxiliar a organização a

estabelecer prioridades para melhoria e também fornece um guia para a

implementação dessas melhorias.

O primeiro passo a ser dado é a identificação, por meio de um método

definido pelo SEI (SCAMPI – SEI Members of the Assessment Method

Integrated Team, 2001) e conduzido por um avaliador credenciado, do estágio

em que a empresa se encontra no presente; uma vez que este denota um nível

de maturidade a ser alcançado pelas empresas, visando ajudá-las no

desenvolvimento e manutenção dos projetos de software, como também

melhorar a capacidade de seus processos.

Após a verificação do estágio da empresa, verifica-se qual a próxima

etapa a ser alcançada e quais as competências que devem ser adquiridas

neste processo. Esta fase é importante, pois permite alcançar o sucesso e,

consequentemente, melhoria na qualidade dos serviços e produtos fornecidos

pela área de tecnologia da Empresa.


17/27


17

3.3. O CMMI está dividido em cinco estágios:

1. Realização – Estágio inicial

2. Gerenciado – Gerenciamento de requisitos, planejamento de projeto,

monitoramento e controle de projeto, gerenciamento de fornecedores, mediçãoe análise, garantia da qualidade do processo e do produto, gerenciamento de

configuração;

3. Definido – Desenvolvimento de requisitos, solução técnica, integração

do produto, verificação e validação, foco no processo organizacional, definição

do processo organizacional, treinamento organizacional, gerenciamento de

riscos, gerenciamento integrado do projeto, análise da decisão e resolução;

4. Quantitativamente – Gerenciamento quantitativo do projeto,

performance do processo organizacional;

5. Otimização – Análise causal e resolução, inovação organizacional e

implantação.

A tendência atual é de que o modelo CMM seja substituído

g r a d a t i v a m e n t e pelo CMMI.

3.4. CONSIDERAÇÕES SOBRE O CMM

3.4.1. Origem do CMM O CMM teve origem durante na década de 1980 como um modelo para

avaliação de risco na contratação de empresas de software pela Força Aérea

Norte-Americana, que desejava ser capaz de avaliar os processos de

desenvolvimento utilizados pelas empresas que concorriam em licitações,

como indicação da previsibilidade da qualidade, custos e prazos nos projetos

contratados.

Para desenvolver este modelo, a Força Aérea constituiu, junto à

Carnegie-Mellon University, o SEI (Software Engineering Inst i tute ), o qual,

além de ser o responsável pela evolução do CMM, realiza diversas outras

pesquisas em Engenharia de Software.

O líder do projeto que veio a resultar no CMM foi Watts Humphrey,

anteriormente responsável por todo o desenvolvimento de software da IBM,

onde aplicou pela primeira vez os conceitos tradicionais de qualidade,

largamente conhecidos e utilizados em manufatura, no desenvolvimento e

manutenção de software. Neste trabalho, Humphrey baseou-se na sua

experiência anterior como engenheiro de hardware.


18/27


18

Embora, o CMM tenha surgido no contexto de grandes empresas de

desenvolvimento de software contratadas pelas Forças Armadas dos EUA para

projetos militares, tem-se verificado que seus princípios são válidos para todo

tipo de projetos de software.

Isto não é de se estranhar, já que o CMM nada mais é que a aplicação

dos princípios da Qualidade Total e do Gerenciamento de Projetos ao mundo

do software. Assim, o CMM tem sido usado com sucesso, na íntegra ou

adaptado, nos mais variados tipos de empresas, grandes e pequenas, em

várias áreas de atuação.

3.4.2. CMMi

O CMMI é o mais recente modelo de maturidade para desenvolvimento

de software do SEI (Software Engineering Institute - Carnegie Mellon University

- EUA), um dos maiores influenciadores em gestão de processos de software

em todo o mundo.

Derivado principalmente dos modelos SW-CMM (CMM for Software,

voltado ao desenvolvimento de software básico, ou de infraestrutura) e SE-

CMM (CMM for Systems Engineering, voltado ao desenvolvimento de

aplicações de software), o CMMI surgiu da percepção de que software básico e

aplicações são desenvolvidos em contextos integrados. Além disso, o novo

modelo reforça aspectos relacionados à gestão de fornecedores e poderá

assimilar outros processos futuramente.

Até presente momento, são quatro as disciplinas incorporadas ao

CMMI: Systems Engineering (SE) , Softw are Engin eering (SW), Integrated

Produc t and Process Development (IPPD) e Supp l ier Sourcing (SS).

3.4.3. Finalidade do CMMI

O projeto CMMI foi desenvolvido para:

Definir um ponto inicial para modelos integrados;

Aprimorar as melhores praticas para a criação de modelos baseados

em lições aprendidas;

Estabelecer um framework que possibilite a integração futura de

novos modelos;

Criação de uma forma associada de avaliação de desempenho e

treinamento de produtos;


19/27


19

Esforço conjunto (mais de 100 profissionais de aproximadamente 30

empresas envolvidas):

Indústria;

Governo;

Instituto de Engenharia de Software (SEI).

3.4.4. Benefícios

3.4.4.1. Benefícios trazidas pelo cmmi no negócio

As vantagens esperadas no negócio:

Redução substancial em integração de sistemas e tempo de teste

com maior probabilidade de sucesso;

Causa integração de, integração entre, várias funções

desenvolvidas;

Estende os ben e f íc i os do CM M-SW pa r a to do o p ro je to

e/ou organização;

Emprega o princípio da engenharia de sistemas no desenvolvimento

de software;

Acrescenta e aprimora SE em programas existentes;

Acrescenta e aprimora SE em programas existentes;

Alavancagem no processo de melhoria do investimento.

3.4.4.2. Benefícios técnicos trazidos pelo CMMI no negócio

Os benefícios trazidos pelo CMMI, visam o crescimento do foco e

consistência em:

requisitos de desenvolvimento e administração;

design e desenvolvimento de sistemas; integração de sistemas;

administração de riscos;

métricas e análises;

outras atividades relacionadas a engenharia.

3.4.4.3. Alguns pontos a serem trabalhados para a obtenção do CMMI

No nível 2 é preciso trabalhar pontos como Gestão de Requisitos, de

Acordo com Fornecedores e de Configuração, Planejamento e Monitoramento

de Projetos, Medição e Análise.


20/27


20

No nível 3, os quesitos a serem trabalhados são, entre outros, Solução

Técnica, Integração do Produto, Verificação e Validação, Definição de

Processos Organizacionais, Gestão de Riscos, Análise de Decisões e

Resolução.

Já nos níveis 4 e 5, respectivamente, trabalhamos pontos como

Performance de Processos Organizacionais e Gestão Quantitativa de Projetos,

Inovação e Análise de Causas e Resolução.

3.4.4.4. Etapas das avaliações para o CMMI

A primeira etapa de avaliação para o CMMI é o treinamento da equipe

de avaliação, que poderá ser composta somente por profissionais da

consultoria ou da consultoria e dos clientes.

A segunda etapa é o planejamento da avaliação, onde diversos aspectos

são contemplados, como logística e estabelecimento de expectativas.

A terceira etapa é a execução da avaliação, quando o diagnóstico

propriamente dito é realizado. Tipicamente ocorrem de 5 (cinco) à 10 (dez) dias

consecutivos de visitas ao cliente, quando o planejamento da avaliação é posto

em prática. Entrevistas, revisão de documentos e atividades de consenso da

equipe de avaliação são realizadas nesta etapa.

Por último vem a reportagem dos resultados, que ocorre no último dia de

avaliação, em uma sessão onde comparecem todos os participantes e

eventuais convidados. Ela é seguida por uma sessão executiva, onde são

discutidos os principais aspectos levantados durante a avaliação.

3.4.4.3. CONCLUSÃO

O CMMI (Capability Maturity Model Integration), representa umaevolução do modelo SW-CMM.

Apesar de todo o sucesso de uso do modelo CMM no mundo, existe a

tendência de que ele seja substituído gradativamente pelo CMMI.


21/27


21

Muito embora esteja fortemente fundamentado em software, o CMMI

contempla desenvolvimento multidisciplinar, cobrindo outras áreas do

desenvolvimento de sistemas.

4.1. O Modelo McCall

Qualidade de software é um tema que vem sendo abordado e evoluído

há muito tempo em engenharia e arquitetura de software, tanto em relação à

qualidade do processo (da concepção à construção e à manutenção) quanto

em relação à qualidade do produto, o software em si.

Nas décadas de 70 a 90, organizações internacionais de normatização e

padronização — como ISO/IEC, ANSI, IEEE e outros — definiram qualidade

de produto como:

A totalidade dos recursos, aspectos e características de um produto ou

serviço que suportam a sua capacidade de sat is fazer os requis i tos dados, as

expectat ivas e as neces sid ades exp lícit as e implícit as .

Em seu estudo sobre qualidade de software, Software Quality:

Definitions and Strategic Issues o pesquisador, Ronan Fitzpatrick propõe uma

visão mais moderna e ousada de qualidade do produto de software, definindo

assim (Fitzpatrick, 1996).

Qualidade de software é a medida em que um conjunto definido pela

indústria de características desejáveis são incorporadas em um produto, de

modo a aprimorar seu desempenh o durante sua existência.

O Modelo de Qualidade de Software proposto por James A. McCall e

outros, em 1977, foi um dos primeiros largamente difundidos neste campo. Ele

organiza os critérios de qualidade de software em três pontos de vista, a saber:

Operação: características relativas ao uso doproduto.

Revisão: capacidade do produto sermodificado e evoluído.

Transição: adaptabilidade a novos ediferentes ambientes.

http://www.comp.dit.ie/rfitzpatrick/papers/quality01.pdfhttp://www.comp.dit.ie/rfitzpatrick/papers/quality01.pdfhttp://blog.mhavila.com.br/2010/06/20/modelo-de-qualidade-de-software-de-mccall/%23Ref1http://blog.mhavila.com.br/2010/06/20/modelo-de-qualidade-de-software-de-mccall/%23Ref1http://blog.mhavila.com.br/wp-content/photos/orig_McCall.pnghttp://blog.mhavila.com.br/wp-content/photos/orig_McCall.pnghttp://blog.mhavila.com.br/wp-content/photos/orig_McCall.pnghttp://blog.mhavila.com.br/wp-content/photos/orig_McCall.pnghttp://blog.mhavila.com.br/wp-content/photos/orig_McCall.pnghttp://blog.mhavila.com.br/wp-content/photos/orig_McCall.pnghttp://blog.mhavila.com.br/2010/06/20/modelo-de-qualidade-de-software-de-mccall/%23Ref1http://blog.mhavila.com.br/2010/06/20/modelo-de-qualidade-de-software-de-mccall/%23Ref1http://www.comp.dit.ie/rfitzpatrick/papers/quality01.pdfhttp://www.comp.dit.ie/rfitzpatrick/papers/quality01.pdf


22/27


22

Os critérios de qualidade elencados no Modelo de McCall em cada ponto de

vista estão listados na tabela a seguir.

Operação Revisão Transição

Correção Manutenibilidade PortabilidadeConfiabilidade Flexibilidade Reusabilidade

Eficiência Testabilidade Interoperabilidade

Integridade

Usabilidade

Atualmente existem outros modelos de avaliação da qualidade do

produto de software, em especial o padrão internacional de engenharia de

software ISO/IEC 9126, que trata da Qualidade do Produto. A norma se divide

em quatro partes, sendo a primeira uma visão geral do modelo de qualidade, e

as outras três, os grupos de métricas definidas para este modelo:

Parte 1: Modelo de qualidade.

Parte 2: Métricas externas.

Parte 3: Métricas internas.

Parte 4: Métricas de qualidade em uso.

Qualidade externa diz respeito ao produto final como percebido pelousuário, enquanto qualidade interna se refere à estrutura e às características

do produto em seu projeto e construção.

Mais recentemente, desde 2005, as normas ISO/IEC 9126 e a série

ISO/IEC 14598, de avaliação de produto de software, tem sido integradas na

nova Série de normas ISO/IEC 25000 – Software Engineering — Software

product Quality Requirements and Evaluation (SQuaRE), que tem seu

núcleo principal composto por cinco divisões: ISO/IEC 2500n – Divisão Gestão da Qualidade;

ISO/IEC 2501n – Divisão Modelo de Qualidade;

ISO/IEC 2502n – Divisão Medição da Qualidade;

ISO/IEC 2503n – Divisão Requisitos de Qualidade;

ISO/IEC 2504n – Divisão Avaliação da Qualidade.

Além deste núcleo principal, o SQuaRE contempla extensões, que

tratam de temas específicos, como ISO/IEC 25051, SQuaRE Requisitos paraqualidade de produtos comerciais de prateleira (Commercial Off-The-Shelf –


23/27


23

COTS), e ISO/IEC 2506n, SQuaRE Com mon Industry Format (CIF) para

usabilidade.

Os critérios de qualidade no Modelo de McCall são muito similares aos

preconizados por outros modelos para classificação de atributos de qualidade

de software, como o FURPS+ (Robert Grady e Deborah Caswell, HP, 1987-

1992) e o da própria ISO/IEC 9126, quanto a requisitos não funcionais:

FURPS+ ISO 9126 McCall

Functionality (Funcionalidade) Funcionalidade - (n/a, funcional)

Usability (Usabilidade) Usabilidade Usabilidade (Operação)

Reliability (Confiabilidade) ConfiabilidadeCorreção,Confiabilidade,

Integridade (Operação)

Performance (Desempenho) Eficiência Eficiência (Operação)

Supportability

(Suportabilidade)Manutenibilidade

Manutenibilidade,

Flexibilidade,

Testabilidade (Revisão)

+ (outros requisitos/restrições) Portabilidade

Portabilidade,Interoperabilidade,

Reusabilidade

(Transição)

.

Vale ressaltar que qualidade do software, abordada aqui, se entende por

Qualidade do produto de software em si, o que é distinto de qualidade do

processo de software, que diz respeito à qualidade das atividades e forma

pelas quais se produz software.

Em 1977, McCall propôs um modelo para a avaliação da qualidade de

software. Esse modelo envolve um conjunto de três fatores que avalia o

software com relação a três pontos de vista distintos.I - Com relação ao uso

do produto (Características Operacionais).

* Corretude → Medida na qual o software satisfaz as especif icações e objetivos

visados pelo cliente.


24/27


24

* Confiabilidade → À medida que se pode esperar que um programa

execute sua função pretendida com a precisão exigida.

* Eficiência → É a quantidade de recursos computacionais e de código

exigida para que um programa execute sua função, com total precisão,

visando realizar a operação de forma 100% segura.

* Integridade → Medida na qual, controla-se o acesso ao software e aos

dados, bloqueando assim o acesso de pessoas não autorizadas, para que

não ocorra perda de dados ou de código.

* Usuabilidade → Mede a facilidade para a utilização do software.

II - Com relação a alteração do produto (Habilidade para ser alterado).

* Manutenção → O esforço exigido para localizar e reparar erros em um

programa.

* Flexibilidade → O esforço utilizado para realizar uma alteração no

software, isto é, qual o grau de facilidade que o sw oferece para a sua

alteração, de forma rápida e eficaz?

* Testabilidade → São todos os recursos utilizados, no teste do software,

isto é, o esforço exigido para testar um programa a fim de garantir que ele

execute a função pretendida.

III - Transição do produto (Adaptabilidade a novos ambientes).

* Portabilidade → Mede a facilidade com que um produto pode ser movido

para outra plataforma, ou software.

* Reusabilidade → Medida na qual o software, ou parte dele, poder ser

reusado em outros softwares, em outras palavras, o código do sw deve ser

reaproveitável.


25/27


25

* Interoperabilidade → O software é capaz de ser acoplado ao outro

5.0. Referências Bibliográficas

Aurélio. F. B. H., Novo Dicionário da Língua Portuguesa, editora Nova

Fronteira, 1986.

Berard, E., Metrics for Object-Oriented Software Engineering, an Internet

posting on comp.software-eng, 1995.

Boehm, B., Software Engineering Economics, Prentice-Hall, 1981.

Bueno, C. F. S.; Campelo, G. B.; Departamento de Informática, Universidade

Federal de Pernambuco, Recife,

http://www.cin.ufpe.br/~qualisoft/documentos/diversos/quality.doc; Acessado

em 27/03/2015.

CMMI (Capability Maturity Model Integration),

http://www.devmedia.com.br/cmmi-capability-maturity-model-integration, Acessado em 27/03/2015.

Centro de Estudos e Sistemas Avançados do Recife - CESAR, Informática

Brasileira em Análise - ano 1, número 2, junho de 1997.

Chidamber, S. R., e Kemerer, C. F.; A Metrics for Object-Oriented Disign,

IEEE Trans. Software Engineering, vol. 20, número 6, pg. 476-493, 1994.

Davis, A. et al., Identifying and Measuring Quality in a Software

Requirements Specification, Proc. 1st Intl. Software Metric Symposium, IEEE,

Baltimore, MD, pg. 141-152, 1993.

http://www.cin.ufpe.br/~qualisoft/documentos/diversos/quality.doc%3Bhttp://www.cin.ufpe.br/~qualisoft/documentos/diversos/quality.doc%3Bhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530%23ixzz3VcPlFcUJhttp://www.cin.ufpe.br/~qualisoft/documentos/diversos/quality.doc%3Bhttp://www.cin.ufpe.br/~qualisoft/documentos/diversos/quality.doc%3B


26/27


26

Fitzpatrick, R.; Software quality definitions and strategic issues, TechnicalPaper, Staffordshire University, 1996.

Grady, R., Caswell, D.; Software Metrics: Establishing a Company-wide

Program. Prentice Hall, p. 159, 1987.

Grady, R.; Practical Software Metrics for Project Management and Process

Improvement . Prentice Hall, p. 32, 1992.

http://www.esicenter.unisinos.br/index.php?pg=frm_vernoticia.php?idnt=50,

Acessado em 27/03/2015.

http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1061&p

ag, Acessado em 27/03/2015.

http://kplus.cosmo.com.br/materia.asp?co=30&rv=Vivencia, Acessado em

27/03/2015.

http://www.dromostg.com.br/CMMI.PDF, Acessado em 27/03/2015.

http://blog.mhavila.com.br/2010/06/20/modelo-de-qualidade-de-software-de-mccall/

Humphrey, W. S.; Managing the Software Process, Addison-Wesley, 1989.

Humphrey, W. S.; The Personal Software: Process Overview, Practice and

Results, Carnegie Mellon University Pittsburgh, PA 15213.

Lorenz, M., e Kidd, J.; Object-Oriented Software Metrics, Prentice-Hall, 1994.

John A. McDermid, Software Engineer’s Reference Book, Butterworth-

Heinemann, 1994.

Meyer, B., Object-oriented Software Construction, Prentice-Hall, 1988.

http://www.esicenter.unisinos.br/index.php?pg=frm_vernoticia.php%3Fidnt%3D50http://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1061&phttp://kplus.cosmo.com.br/materia.asp?co=30&rv=Vivenciahttp://www.dromostg.com.br/CMMI.PDFhttp://blog.mhavila.com.br/2010/06/20/modelo-de-qualidade-de-software-de-http://blog.mhavila.com.br/2010/06/20/modelo-de-qualidade-de-software-de-http://www.dromostg.com.br/CMMI.PDFhttp://kplus.cosmo.com.br/materia.asp?co=30&rv=Vivenciahttp://www.timaster.com.br/revista/materias/main_materia.asp?codigo=1061&phttp://www.esicenter.unisinos.br/index.php?pg=frm_vernoticia.php%3Fidnt%3D50


27/27


Paulk, M. C.; A comparison of ISO9001 and the Capability Maturity Model

for Software, Technical Report, 1994.

Pressman, R. S.; Software Engineering: A Practitioner’s Approach, terceira

edição, McGrawHill, 1995.

Pressman R. S.; Pressman, Software Engineering: A Practitioner’s

Approach, quarta edição, McGrawHill, 1997.

Pressman, Roger. S.; Engenharia de Softw are: conceitos de qualidade .7

ed. Porto Alegre: AMGH,2011.

Sakamoto, L.; Engenharia de Software II – Universidade Paulista UNIP, 2014.

SEI Software Engineering Institute, http://www.sei.com.

Shneiderman, B., Software Psychology: Human Factors in Computer and

Information Systems, Winthrop Publishers, 1980.

Sommerville, I.; Software Engineering, Addison-Wesley, 1992.

Sommerville, I.; Engenharia de Software, 8ª. edição. Capítulo 1. 1993.

Wirfs-Brock, R., Wilkerson, B., e Weiner, L.; Designing Object-Oriented

Software, Prentice-Hall, 1990.
http://www.sei.com/http://www.sei.com/

guia de esw-np1

Documents