Gestão


Estou tão corrido e sem tempo que fiz uma grande revisão no meu artigo sobre Gerenciamento de Projetos em 11 de julho (!) e só hoje vou comentar aqui.

Uma grande parte da revisão foi atualizar informações para a quinta edição do PMBOK. Desde o alinhamento com a norma ISO 21500, até as figuras e textos refletindo a incorporação da nova área de conhecimento “Partes Interessadas” e a revisão dos processos de GP, que passaram de 42 para 47.

Outra grande parte foi na última seção, que citava como referencial de organização para guias e boas práticas em gerenciamento de projetos apenas o IPMA, de origem européia (e sua afiliada brasileira ABGP). Agora são citados também o PRINCE2, de origem inglesa, e os métodos e ferramentas ágeis como Scrum, Kanban e Project Model Canvas (este último do brasileiro José Finocchio Júnior).

Confira o artigo atualizado: PMBOK e Gerenciamento de Projetos.

Ainda no assunto de atualização de artigos mas com bem menor abrangência, revisei hoje o artigo sobre criação de arquivos PDF a partir de conteúdo no Windows. Basicamente percorri os sites do Ghostscript e das impressoras PDF avaliadas, verificando suas versões atualizadas e novidades trazidas, como compatibilidade com o Windows 10, por exemplo.

Confira: Gerando PDFs com (ou sem) o Ghostscript.

Depois de uma ampla atualização em maio e de outra, mais leve, em junho, acrescentei agora em meu artigo PMBOK e o gerenciamento de projetos uma importante seção, sobre as Partes interessadas de um projeto.

Conforme citei em maio, esse era um tópico importante que faltava para cobrir os principais aspectos do gerenciamento de projetos.

Espero que o artigo agora esteja bastante completo para uma introdução abrangente, apresentando os conceitos e aspectos fundamentais de gerenciamento de projetos, voltado a iniciantes nesse tema. Ainda assim, o artigo buscou continuar didático, sintético e objetivo, cobrindo todo esse conteúdo em poucos tópicos e páginas de texto.

Segundo a Wikipedia, em 1964 Victor H. Vroom — canadense com PhD pela Universidade de Michigan e atual professor de Organização e Gerenciamento na Escola de Administração da Universidadede Yale, EUA –, desenvolveu a teoria da Expectativa, através de seus estudos das motivações por trás das tomadas de decisão. Sua teoria é relevante para o estudo da motivação em administração e gerenciamento, em especial na gestão de pessoas e talentos.

A Teoria da Expectativa (Expectancy Theory) propõe que uma pessoa decidirá se comportar ou agir de determinada maneira porque é motivada a selecionar um comportamento específico em detrimento de outros, devido ao que ela espera que o resultado do comportamento selecionado seja.

— Oliver, R. Expectancy Theory Predictions of Salesmen’s Performance. Journal of Marketing Research volume 11, p. 243-253, agosto 1974.

Elizeu Araujo, em seu artigo Teorias da Motivação, cita que para Eward Lawler, o modelo de expectativa baseia-se em quatro pressupostos:

  • O Comportamento é determinado por uma combinação de fatores do individuo e do ambiente;
  • Os indivíduos tomam decisões conscientes sobre seu comportamento;
  • Indivíduos distintos têm necessidades, desejos e objetivos diferentes;
  • Os indivíduos decidem entre alternativas de comportamento, baseados em suas expectativas de que um determinado comportamento levará a um resultado desejado.

Segundo Vroom, a motivação do indivíduo para escolher uma das alternativas de comportamento depende de três fatores:

  • Expectativa de resultado do desempenho: Os indivíduos esperam certas consequências ou resultados de seus comportamentos, afetando decisões sobre como se comportam.
  • Instrumentalidade: a percepção de que a obtenção de cada resultado está ligada a uma compensação. Fazendo uma escolha, os indivíduos tendem a escolher o nível de desempenho que pareça ter a máxima probabilidade de obter resultado satisfatório.
  • Valência: o valor que cada indivíduo atribui ao resultado advindo de cada alternativa, o que se refere ao poder de motivar e varia de individuo para individuo. Ex.: para um indivíduo que valoriza o dinheiro e a realização, a transferência para um cargo com salário mais alto e em outra cidade pode ter uma Valência alta, enquanto que para um indivíduo que prioriza suas raízes e seu círculo de relacionamento na cidade atual, esse benefício terá sua Valência reduzida.

Araújo coloca didaticamente esses pressupostos na forma das seguintes reflexões, em que o indivíduo se questiona:

— Se eu fizer isso, qual será o resultado?
— O resultado vale o meu esforço?
— Quais as chances de alcançar o resultado que valha a pena para mim?

Esta teoria motivacional enfatiza a necessidade das organizações em relacionar as recompensas diretamente ao desempenho e em garantir que as recompensas providas são os benefícios merecidos e desejados por aqueles que recebem.

Os gestores de pessoas devem ter isso em mente ao estabelecer metas e recompensas e, desde o início, alinhar as expectativas junto aos talentos que integram e buscam motivar em suas equipes.

Para saber mais:

Cito dois artigos sobre gerenciamento de projetos, com especial enfoque em projetos de tecnologia da informação (TI). Um é mais antigo, mas ainda perfeitamente atual e válido, e o outro bem recente.

Os 7 passos do gerenciamento de projetos
Por Fernando C. Barbi, 2008, em Microsoft TechNet Brasil.

  1. Escolha e adote uma metodologia
  2. Comunique-se: não é só o peixe que morre pela boca !
  3. Defina o escopo do projeto e detalhe as atividades
  4. Conheça os envolvidos e monte seu time
  5. Desenvolva o cronograma junto com quem põe a mão na massa
  6. Monitore os riscos e seja pró-ativo
  7. Formalize o início e o encerramento do projeto

O artigo é aparentemente extenso, mas de leitura fácil e agradável. Barbi conclui assim:

Acima de tudo, gerenciar projetos é planejar e acompanhar a execução com “um olho no peixe e outro gato”. O gerente do projeto deve se manter alerta e flexível com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para não perder o controle. A principal qualidade do gerente de projeto é saber se comunicar bem com todos. Ele é o ponto focal das informações, nele convergem as informações que ele depois deverá processar e divulgar para todo o restante da equipe.

O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, “quando todos empurram na mesma direção, não há carroça que não saia do atoleiro”.

4 dicas para gerenciar o orçamento de projetos de TI
Revise sempre o bugdet e não seja pego de surpresa durante a execução de um projeto.
Por Jason Westland, da CIO/US, 01 de julho de 2011, em Computerworld Brasil.

  1. Preveja o orçamento de forma contínua.
  2. Revise a necessidade de pessoas envolvidas no projeto.
  3. Mantenha a equipe informada.
  4. Gerencie o escopo cuidadosamente.

Conclui o artigo:

O budget deve ser uma parte viva do projeto. Profissionais que observam cautelosamente os orçamentos durante todo o ciclo de vida dos projetos vão manter as partes interessadas e a gestão contentes e assim garantir o sucesso da implementação.

Lendo o artigo CHAOS Report: Métodos Ágeis Aumentam Taxa de Sucesso de Projetos, postado no Blog ScrumHalf em 11/02/2011, obtive os dados do mais recente relatório do Standish Group CHAOS Manifesto 2011, atualizado para dados sobre o sucesso e falha de projetos de TI da pesquisa realizada em 2010.

Em comparação com o relatório CHAOS Manifesto 2010, relatando a pesquisa realizada em 2008, a taxa de projetos rotulados como Sucesso aumentou de 32% para 37% enquanto a taxa de projetos rotulados como Fracasso diminuiu de 24% para 21%. A taxa de projetos com o rótulo de Deficit também reduziu de 44% para 42%.

A taxa de sucesso de 37% é a maior encontrada pelas pesquisas do Standish Group desde 1994.

Segundo o artigo, o Standish Group aponta quatro razões para a melhoria significativa encontrada em 2010 em relação a 2008:

  1. Processos Ágeis: A utilização desses processos cresce a uma taxa de 22% CAGR (Compound annual growth rate). Hoje representam 9% de todos os projetos de TI e são adotados em 29% do desenvolvimento de novas aplicações. O instituto conclui que o crescimento da taxa de sucesso está diretamente relacionado ao aumento da adoção de metodologias ágeis.
  2. Modernização: Esses projetos, que entre outros focam na conversão de código/banco de dados, tem taxa de crescimento anual menor do que a dos processo ágeis. Entretanto tem taxa de projetos rotulados como sucesso maior. O instituto conclui que isso acontece devido ao mecanicismo desses processos e de um ambiente relativamente mais homogêneo de perfil de profissionais.
  3. Pacotes Empresariais: O número de novos projetos de implantação de ERP e CRM diminuiu. Como, segundo o instituto, consistem em projetos de grande risco com resultados questionados, a diminuição de novas implantações contribuiu para aumentar a taxa de projetos rotulados como sucesso.
  4. Processos em Cascata: Consistem nos métodos tradicionais e já representaram quase 50% do número de novas implementações. Como crescem a 1% CAGR, sua utilização relativa diminuiu, contribuindo, assim, positivamente para a taxa de sucesso.

Estes dados me permitem autalizar o gráfico do artigo Sucessos e falhas em projetos de TI, postado exatamente um ano atrás. Agora ele fica assim:

No campo da Modernização, o Standish Group disponibiliza, na área de Amostra de Pesquisas (requer registro gratuito), o relatório NonStop Modernization (abril 2011) em que lista as prioridades de investimento em TI para 2011, The Standish Group’s annual Top 10 Areas of IT Investiments:

  1. Modernização de aplicações (SOA, BPM, etc.)
  2. Upgrade de infraestrutura (hardware, software)
  3. Melhoria da segurança
  4. Computação em nuvem (SaaS, Utility Computing)
  5. Desenvolvimento de novas aplicações
  6. Capacitação da equipe
  7. Disponibilidade de aplicações e sistemas
  8. Conformidade e governança
  9. Consolidação e otimização
  10. Presença web e comércio eletrônico

E destaca os Três Conceitos e Seis Passos para a Modernização Contínua:

Conceitos:

  1. Compreender seu projeto de modernização e o ambiente deste: a organização deve dominar o projeto de evolução que vai executar, compreender seus custos, riscos e benefícios, as diferentes opções e suas implicações, e deve ter um plano claro para seguir e guiar sua condução.
  2. Refatorar: Standish Group estima que cerca de 80% dos recursos e funcionalidades de uma típica aplicação missão-crítica não são usados; deve-se, portanto, remover as partes não utilizadas antes de se migrar programas, evitando esforço inútil.
  3. Modernizar a infraestrutura: atualizar hardware defasado e proprietário para sistemas blade comuns, aumentando a consolidação e trazendo mais simplicidade e flexibilidade.

Passos:

  1. Modernize o banco de dados
  2. Modernize a experiência do usuário
  3. Modernize a aplicação
  4. Modernize a disponibilidade
  5. Modernize a segurança
  6. Modernize a operação

Quanto aos processos ágeis, é interessante citar que o Manifesto Ágil completou 10 anos em 2011. Para abordar os desafios encarados por desenvolvedores de software, um grupo inicial de 17 metodologistas formou a Agile Alliance, em fevereiro de 2001. Este grupo formulou um manifesto para encorajar melhores maneiras de se desenvolver software, e baseado nesse manifesto definiu quatro valores e doze princípios que formam os fundamentos do movimento ágil.

Os quatro Valores do Manifesto Ágil:

  • Indivíduos e interações acima de processos e ferramentas;
  • Software funcionando acima de documentação abrangente;
  • Colaboração com o cliente acima de negociação de contrato;
  • Responder a mudança acima de seguir um plano.

Dentre as metodologias ágeis, o Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.

Para saber mais sobre o manifesto ágil e scrum:

Aproveitando o assunto de projetos, também atualizei meu artigo introdutório PMBOK e Gerenciamento de Projetos, um dos mais acessados e citados do meu site, refinando as seções sobre o gerente de projetos e suas habilidades interpessoais, e também aquela sobre a instituição IPMA com sua filosofia e certificações.

Para saber mais:

Sua empresa quer ou precisa elaborar uma política de segurança da informação, mas não sabe nem por onde começar? Eis aqui algumas dicas.


Créditos da figura: ISACA, 2009, An Introduction to the Business Model for Information Security (PDF).

Uma política de segurança da informação em geral é composta de diretrizes, normas e procedimentos que visam garantir confidencialidade, integridade e disponibilidade da informação (documental) que é produzida, recebida, utilizada, processada, armazenada e descartada por uma instituição. A gestão da segurança da informação envolve pessoas, processos, tecnologia e ambiente.

Deve também, idealmente, instituir um grupo ou comitê formal e permanente para centralizar o gerenciamento e orientação das atividades relativas a segurança da informação na organização. Para maximizar a autonomia e eficácia desse comitê gestor de segurança da informação, este deve estar ligado ao mais alto nível hierárquico de gestão da organização, como sua presidência ou comitê estratégico/executivo.

Não existe um modelo padrão de política de segurança da informação, porque esta tem que refletir os valores e a cultura da organização a qual se aplica, e levar em conta o negócio e o contexto em que ela está inserida. Ou seja, a política de SI deve ser construída sob medida para cada organização.

As normas ABNT e ISO/IEC relativas a segurança da informação fornecem conceitos e fundamentos essenciais que podem e devem embasar uma boa política de segurança da informação.

Mas a partir daí, as diretrizes, normas e políticas deve ser construídas em resposta a questões essenciais, como:

  • Quais são os ativos e as informações de valor para a organização e seu negócio e que devem ser protegidos?
  • Quais são os riscos aos quais a organização e suas informações estão submetidas, quais deles devem ser abordados e mitigados, e quais serão simplesmente aceitos?
  • Quais são os aspectos e parâmetros relevantes para se definir o balanceamento entre: investimentos em segurança da informação versus valor dos ativos a serem protegidos e riscos de perdas envolvidos; ativos e serviços a serem protegidos versus vulnerabilidades e aspectos mais críticos a serem abordados na sua segurança; conveniência e facilidades versus proteção e controle.

O Sans Institute disponibiliza em seu portal uma série de documentos (PDF, em inglês) úteis para auxiliar na composição de uma política de segurança da informação, com foco em tecnologia da informação (TI):

Principais Normas ABNT NBR e ISO/IEC aplicáveis:

Outras referências úteis:

Mauro Segura é líder de marketing e comunicação da IBM Brasil e blogueiro. Estudioso do tema redes sociais nas empresas, ele aborda frequentemente o assunto em seu blog AQO – A Quinta Onda – Comunicação e Comportamento na Era da Sociedade Digital.

Sua visão pessoal a respeito dos executivos não blogarem é tão simplista e direta que ele até se desculpa se decepciona alguém: — Os executivos não blogam porque eles têm coisas mais importantes para fazer. Tão simples quanto isso.

Em junho do ano ano passado, o site norte-americano UBERCEO — que cobre a “vida” dos CEOs, Chief Executive Officers de empresas — afirmou que a maioria dos 100 principais executivos do planeta não frequenta rotineiramente as redes sociais.

Segundo a pesquisa do UBERCEO, os principais motivos são os riscos que as redes podem trazer para a reputação da empresa, pelo vazamento de informações estratégicas, pela falta de conhecimento em como lidar com as redes e pela paranoica percepção de que o acesso livre às redes gera improdutividade do funcionário.

UBERCEO pesquisou comunidades como Facebook, Twitter, LinkedIn e Wikipedia. O resultado é que apenas 2 CEOs tinham contas no Twitter, 13 deles tinham perfis no LinkedIn, 81% não tinham página pessoal no Facebook e nenhum deles tinha um blog.

O próprio Mauro Segura fez uma pesquisa junto a CEOs de algumas empresas — divulgada também na revista Época Negócios de novembro 2010 (ano 4, número 45) — e apontou Dez motivos por que os executivos não blogam:

  1. Falta de tempo.
  2. Medo de entrar em discussões polêmicas.
  3. Percepção de que não é relevante.
  4. Insegurança de até onde vai a conversa.
  5. Insegurança para escrever.
  6. Risco de imagem.
  7. Vazamento de informação.
  8. Medo de dizer que não deu certo.
  9. Imagem perante os colegas executivos.
  10. A comunidade não está preparada.

Observando a lista de motivos, eu ousaria complementar a constatação de Mauro Segura. Com tantos receios e desconhecimento apontados pelos executivos ante às mídias sociais da internet, seu potencial e seus impactos, eles realmente não priorizam tempo a elas.

Recentemente, Mauro Segura abordou outros aspectos do tema em seu artigo CEOs perdem tempo nas redes sociais, 2010-12-07, que comenta uma matéria de Lucy Kellaway em sua coluna do Financial Times, reproduzida no jornal brasileiro Valor Econômico. O mote aí foi a pronta interação do presidente da Starbucks no Reino Unido, Darcy Willson-Rymer, com um consumidor no Twitter.

Seja como for, creio que as empresas brasileiras ainda estão muito longe de aproveitarem ampla e plenamente o potencial das redes sociais não só como elemento integrador e propulsor da comunicação interna, mas também como um canal mais direto e intimista com seus consumidores, parceiros e sociedade em geral.

Na era da internet, essa é uma fronteira à parte a ser galgada pelas instituições.

Para saber mais, no blog A Quinta Onda, por Mauro Segura:

O arquiteto, urbanista e professor Lúcio Costa (1902-1998), pioneiro da arquitetura modernista no Brasil, ficou conhecido mundialmente pelo projeto do Plano Piloto de Brasília. Contudo, cito o ilustre brasileiro em uma frase atribuída a ele, que para mim resume a razão de ser do gerenciamento de projetos:

“A única coisa do planejamento é que as coisas nunca ocorrem como foram planejadas.”

— Lúcio Costa

É consenso cada vez mais difundido que sem planejamento e sem monitoramento vem o descontrole. Empreitadas importantes e/ou grandes estão fadadas ao fracasso se não houver, além da execução em si, planejamento (antes) e controle (durante). Planejamento, execução, monitoramento e controle são elementos essenciais do gerenciamento de projetos.

Mas por que o gerenciamento de projetos, o planejamento e o controle são realmente necessários, e não apenas fazer-se o que precisa ser feito (a execução)? É exatamente porque, como bem disse Lúcio Costa, as coisas nunca ocorrem como foram planejadas. A vida, as pessoas, a sociedade, o mercado, o ambiente são cheios de incertezas e imprevistos, falhas e mudanças.

É possível saber exatamente quanto tempo cada pessoa tem de vida? Quando ficará doente? Quando conhecerá um grande amor? Quando mudará de emprego? Não. E quando choverá? E a chuva causará algum prejuízo? Quando será a próxima recessão econômica? E a próxima onda de prosperidade? Quando a bolsa de valores vai subir ou descer?

Além disso, pessoas são subjetivas, manhosas e — verdade seja dita — imperfeitas. E únicas: cada um tem sua personalidade, suas qualidades, defeitos, forças, fraquezas, crenças, medos, interesses, objetivos. Pessoas mudam de ideia, de opinião, de expectativa, até de humor, a todo momento.

Isso sem falar nos desafios da comunicação. A transmissão de ideias, conhecimentos e informações é uma arte. Veja a grande lição que traz a brincadeira do “telefone sem fio”. Passe uma simples frase por diversas pessoas e veja como ela pode se distorcer rapidamente.

Uma pessoa pode pensar uma coisa, falar outra e ainda ser compreendida de uma terceira forma diferente. Já viu aquela famosa tirinha de humor sobre as idiossincrasias de comunicação no desenvolvimento de software?

“A comunicação não é aquilo que falamos. A comunicação
é aquilo que é percebido, aquilo que é decodificado pelas outras pessoas”.

Reinaldo Passadori

Se não houver planejamento e controle, os riscos e incertezas, os eventos imprevistos e as falhas vão ocorrendo a cada dia, levando ao gradativo desvio de rota e ao insucesso.

Gerenciamento de projetos existe para traçar, divulgar, monitorar e corrigir a rota dos projetos, tratando questões, riscos, incertezas, imprevistos, falhas e mudanças que surgem, sempre mantendo as partes interessadas informadas e gerenciando suas expectativas, de forma a garantir que cada projeto (uma tarefa ou empreitada a realizar) seja cumprido e atinja seu objetivo com sucesso.

Para saber mais:

Lendo no blog da consultora Patrícia Inêz, PMP, o artigo Venkatraman e os Projetos de Implantação de ERP, aprendi mais um pouco sobre alinhamento estratégico em TI.

O Modelo de Alinhamento Estratégico de TI proposto por Henderson e Venkatraman (1993) correlaciona os benefícios obtidos pelo uso de tecnologia da informação, com o grau de transformações ocasionados nos negócios da organização.

Gráfico de benefícios vs transformação TI, Henderson e Venkatraman (1993)

Existem os níveis de impacto evolucionário, que trazem melhoria e integração dos processos internos existentes, e os níveis considerados revolucionários, isto é, aqueles que implicam desde uma efetiva reengenharia até chegarem a impactar a redefinição do escopo dos negócios ou da atuação da organização (empresa ou instituição) em questão.

Referências principais:

Agora vou me debruçar a aprender mais a respeito:

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 satisfazer os requisitos dados, as expectativas e as necessidades explícitas e implícitas.

Em seu estudo sobre qualidade de software, Software Quality: Definitions and Strategic Issues (PDF, abril 1996), o pesquisador Ronan Fitzpatrick propõe uma visão mais moderna e ousada de qualidade do produto de software, definindo assim:

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 desempenho 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 do produto.
  • Revisão: capacidade do produto ser modificado e evoluído.
  • Transição: adaptabilidade a novos e diferentes ambientes.

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 Portabilidade
Confiabilidade 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 pelo usuá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 para qualidade de produtos comerciais de prateleira (Commercial Off-The-Shelf – COTS), e ISO/IEC 2506n, SQuaRE Common 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) Confiabilidade Correçã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.

Para saber mais:

Próxima página »