1 – Cliente (interno / externo) · Web viewO PMBOK, compilado pela expertise do PMI – Project Management Institute, é a linha mestra que nos conduz ao conhecimento organizado

Terminologia Pesquisa em grupo 1

Sumário

1 – Cliente (interno / externo).................................................................................................22 Fornecedor (interno / externo).............................................................................................23 Cultura Empresarial.............................................................................................................24 Projeto..................................................................................................................................35 Qualidade.............................................................................................................................36 Gestão da qualidade.............................................................................................................47 Benchmarking......................................................................................................................48 Ferramentas da qualidade.....................................................................................................49 Auditoria da qualidade.........................................................................................................410 Software.............................................................................................................................511 Produto de software...........................................................................................................512 Processo de software..........................................................................................................613 Ciclo de vida de software...................................................................................................614 Requisito de software.........................................................................................................615 Verificação de software /...................................................................................................716 Validação de software........................................................................................................715 Verificação de software / Validação de software...............................................................717 Revisão técnica de Software..............................................................................................818 Teste de Software...............................................................................................................819 Gerência de Configuração..................................................................................................820 Garantia da qualidade (QA- Quality Assurance)...............................................................821 PNQ – Prêmio Nacional da qualidade...............................................................................922 PMBOK – Project Management Body ok Knowledge......................................................923 ISO 9000 / ISO 9001..........................................................................................................924 ISO 90003 (ISO 9000-3)..................................................................................................1025 ISO 15504 (SPICE)..........................................................................................................1026 ISO 12207........................................................................................................................1027 ISO 9126 (NBR ISO 13596)............................................................................................1128 SW- CMM........................................................................................................................1129 CMMI...............................................................................................................................1130 PSP – Personal Software Process.....................................................................................1131 TSP – Team Software Process.........................................................................................1132 XP – Extreme Programming............................................................................................1233 UP – Unified Process / RUP – Rational Unified Process................................................12Referências Bibliográficas....................................................................................................13


1 – CLIENTE ( INTERNO / EXTERNO)a) consumidor final, usuário, beneficiário ou segunda parte interessada; b) usuário seguinte da produção ou do serviço; c) em termos amplos, é a organização ou pessoa a quem a organização ou pessoa fornece um produto, serviço ou informação, ou ainda, que seja afetada por um produto, serviço ou processo.O principal cliente de um determinado funcionário pode ser a pessoa da mesa ao lado ou do posto de trabalho seguinte, nesse caso, denominado cliente interno. Cliente ou usuário quando recebe um produto, serviço ou informação em qualquer estágio do processo; processador quando adiciona valor ao produto, serviço ou informação; e fornecedor quando passa adiante o produto, serviço ou informação (ainda que não completo) para um novo cliente ou usuário. Todos em uma organização têm clientes externos e/ou internos, cujas necessidades devem atender, a fim de cumprir sua missão [PRAZERES, 1996].

Cliente – é qualquer pessoa que seja impactada pelo produto ou processo.[JURAN, 1992]

Cliente externo: são impactados pelo produto, mas não são membros da empresa que faz o produto. Os clientes externos incluem aqueles que compram os produtos, os departamentos reguladores do governo e o público (que pode ser impactado devido a produtos inseguros ou a danos ao ambiente). [ JURAN, 1992]

Clientes internos – são impactados pelo produto e são também membros da empresa que o produz. Eles costumam ser chamados de “clientes”, a despeito do fato de não o serem no sentido estrito da palavra. [ JURAN, 1992]

2 FORNECEDOR ( INTERNO / EXTERNO)Externo: Pessoa ou organização que fabrica ou agrega valor a um produto ou presta serviço a uma outra organização (PRAZERES, 1996).Interno: Pessoa ou setor da organização que produz ou agrega valor a um produto ou presta serviço a uma pessoa ou setor da mesma organização (PRAZERES, 1996).

Fornecedor – qualquer um que forneça entradas a um processo. [JURAN, 1992]

3 CULTURA EMPRESARIALÉ o conjunto de premissas fundamentais (inatacáveis e inquestionáveis – pelos seus membros – que definem suas metas e produtos) sobre os produtos que a


organização deve produzir, como faze-lo, onde e para quem (LAUDON & LAUDON, 1999).

4 PROJETO

Unidade gerencial que cobre uma execução de um processo de desenvolvimento de software (PAULA FILHO, 2003).

Um problema com solução programada – uma missão programada para ser executada. [ JURAN, 1992]

Um projeto é um empreendimento temporário com o objetivo de criar um produto ou serviço único. Temporário significa que cada projeto tem um começo e um fim bem definidos. Único significa que o produto ou serviço produzido é de alguma forma diferente de todos os outros produtos ou serviços semelhantes. [PMBOK, 2000]

Esforço temporário e progressivamente elaborado, para produzir um produto, ou serviço único, de acordo com escopo, prazo e custos e política de qualidade definidos em um plano, para satisfazer ou superar as necessidades e expectativas dos cientes. Projetos podem ser uma forma das organizações responderem à requisitos específicos que as operações normais não conseguem atender. São freqüentemente implementados para realizar o plano estratégico das organizações.

Temporário: pois as nichos e janelas de oportunidade e necessidades são temporárias. As equipes de projetos tem responsabilidades bastante específicas e normalmente são desmontadas ao seu término, sendo que seus integrantes retomam suas atividades na organização ou simplesmente são dispensados. Além disso os projetos têm data certa e aprazada para início e término.

Único: Envolve algo que nunca foi feito antes portanto único. Produtos e serviços da mesma categoria podem ser considerados únicos.

Progressivamente elaborado: Integra os conceitos de temporário e único, ou seja, proceder por etapas e continuar de forma determinada e por incrementos.

5 QUALIDADE Grau de conformidade de um produto com os respectivos requisitos (PAULA FILHO, 2003).


Conformidade às especificações (ou ausência de variações) (LAUDON & LAUDON, 1999).

A palavra tem dois significados principais (1) as características de produto que respondem às necessidades dos clientes e (2) ausência da deficiências. Um termo genérico para cobrir os dois significados é “adequação ao uso” [ JURAN, 1992]

A qualidade pode ter várias definições quando falamos em produtos e serviços de software, porém as que julgo principais são:

Um produto de software deve ser aderente aos requisitos, cumprindo assim com objetivo para o qual foi concebido e adequado ao uso, fácil de usar, flexível e portável para diversos ambientes. Podemos definir ainda que um produto de software com qualidade é aquele que além de atender aos requisitos, é concluído dentro do prazo e custos contratados e portanto com qualidade. Ainda em termos de qualidade podemos aplicar as definições sob várias abordagens:

Abordagem baseada no usuário: adequado ao uso/ou propósitoAbordagem baseada no produto: que cumpre um conjunto mensurável e preciso de características.Abordagem baseada em valor: considera custo e preço, ou seja, o consumidor está disposto a aceitar algo com especificação menor e também com custo menor

O grande desafio reside no fato de conciliar a visão da qualidade de software de quem o produz e dos clientes finais. O entendimento comum da qualidade pode ser beneficiado através de uma eficiente gerência de projetos de software que defina e busque aprovação da “tripla restrição” de escopo, custo e prazo, que consequentemente definirá qualidade, contribuindo para que as espectativas dos clientes possam ser atendidas.

6 GESTÃO DA QUALIDADEConceito que torna a qualidade uma responsabilidade de todos dentro de uma organização (LAUDON & LAUDON, 1999).

A estrutura e o funcionamento do processo de gestão da qualidade envolvem um conjunto de referenciais que direcionam todas as suas ações. Os mais relevantes, é evidente, referem-se à forma como se entende a qualidade, ou seja, o conceito da qualidade adotada em cada organização. [PALADINI, 2004]

7 BENCHMARKINGÉ um processo para medir e comparar produtos e serviços, competências e mais contra aqueles reconhecidos como melhor na classe (BOAR, 2002).


Medir estatisticamente seus produtos e suas atividades e comparar os resultados com seus próprios padrões ou com padrões externos do seu setor de atividades (LAUDON & LAUDON, 1999).

Envolve comparar as práticas reais ou planejadas do projeto com as de outros projetos para gerar idéias de melhoria e fornecer um padrão pelo qual se possa medir o desempenho. Os outros projetos podem estar dentro da organização executora ou fora dela. Podem, ainda, estar dentro da mesma área de aplicação ou em outra área. [PMBOK, 2000].

8 FERRAMENTAS DA QUALIDADEExpressão de uso geral utilizada para designar as ferramentas estatísticas – gráfico de controle, gráficos de dispersão, gráficos de Pareto, histogramas, gráficos de tendências, etc. e as técnicas especificamente aplicadas à qualidade – ciclo PDCA, controle estatístico de processo (CEP), análise do modo e efeitos da falha (FMEA), etc. Por vezes, usa-se esta expressão, inapropriadamente, para designar também metodologias ou programas, tais como: círculos de controle da qualidade (CCQ), plano de sugestões, método de análise e solução de problemas (MASP), just in time, manutenção produtiva total (MPT) e times da qualidade (PRAZERES, 1996).

9 AUDITORIA DA QUALIDADE

Um estudo independente do desempenho da qualidade. [ JURAN, 1992]

Auditoria de qualidade pode ser encarada como um técnica e/ou ferramenta de um processo instituído de garantia de qualidade de um projeto de software. As auditorias de qualidade verificam se os processos definidos para o projeto estão sendo seguidos. Atuam como forte elemento de medição futura de sucessos e insucesos nos projetos na medida em que registram lições aprendidas quando identificam se os processos padrão de qualidade estão sendo seguidos. A auditoria de qualidade também atua como agente para a melhoria do desempenho dos projetos individuais e da organização como um todo, podendo sugerir alterações nos próprios processos.

10 SOFTWAREParte programável de um sistema de informática, juntamente com a documentação associada (PAULA FILHO, 2003).Software não é apenas o programa mas também toda a documentação associada e os dados de configuração necessários para fazer com que esses programas operem corretamente (SOMMERVILLE, 2003).


Instruções (programas de computadores) que quando executadas fornecem a função e o desempenho desejados, estruturas de dados que permitem aos programas manipular adequadamente a informação e documentos que descrevem a operação e o uso dos programas.[PRESSMAN, 2001]

Muita gente associa o termo software aos programas de computador. Na verdade, essa é uma visão muito restritiva.Software não é apenas o programa, mas também toda a documentação associada e os dados de configuração necessários para fazer com que esses programas operem corretamente. [SOMMERVILLE, 2003]

11 PRODUTO DE SOFTWAREConjunto completo de itens de software, com os respectivos procedimentos e documentos que é entregue a um cliente (PAULA FILHO, 2003).

Produto que os engenheiros de software projetam e constroem. Abrangem programas executados em computadores de qualquer tamanho e arquitetura, documentos que incluem formas impressas e virtuais e dados que combinam números e texto, mas também incluem representações da informação em figuras, vídeo e áudio. Do ponto de vista do engenheiro de software, o produto é o conjunto de programas, documentos e dados que compõem um software de computador, mas do ponto de vista do usuário, o produto é a informação resultante, que de algum modo torna melhor o mundo do usuário.[PRESSMAN, 2001]

Produto – a saída de qualquer processo. [ JURAN, 1992]Software – O termo tem vários sentidos: (1) programas de instrução para computadores e (2) informações em geral: relatórios, planos, instruções, conselhos, comandos, etc. [JURAN, 1992]O produto de software é o resultado de um processo.

12 PROCESSO DE SOFTWAREProcesso usado para atividades relacionadas com software, como desenvolvimento, manutenção, aquisição e contratação (PAULA FILHO, 2003).

Um roteiro que o ajuda na criação de um resultado de alta qualidade dentro de um prazo determinado. Uma estrutura comum de processo é estabelecida definindo um número de atividades, que são aplicáveis a todos os projetos de software,


independentemente de seu tamanho ou complexidade. Certo número de conjunto de tarefas, sendo cada conjunto composto por uma coleção de atividades de engenharia de software, marcos de projeto, produtos do trabalho e pontos de garantia de qualidade, permite que as tarefas da estrutura sejam adaptadas às características do projeto de software e às necessidades da equipe de projeto. [PRESSMAN, 2001]

É um conjunto de atividades e resultados associados que geram um produto de software. Há quatro atividades fundamentais no processo de software : especificação, desenvolvimento, validação e evolução. [SOMMERVILLE, 2003].

13 C ICLO DE VIDA DE SOFTWAREConjunto de história de um software, desde a percepção de sua necessidade até sua retirada de operação (PAULA FILHO, 2003).

São as etapas de desenvolvimento do software, por exemplo o ciclo de vida clássico é o modelo de cascata. Neste modelo as etapas são : engenharia de sistemas, análise, projeto, codificação, teste e manutenção. [PRESSMAN, 1995]

Uma seqüência de diferentes atividades executadas durante o desenvolvimento do software. Existem diversos artefatos produzidos tais como código fonte e manuais de usuários. As principais atividades de um ciclo de vida são: Viabilidade, Requisitos, Planejamento do Projeto, Análise e Projeto, Implementação, Testes, Implantação e Manutenção.[ GUSTAFSON, 2003]

O ciclo de vida do projeto serve para definir o início e o fim de um projeto. Por exemplo, quando uma organização identifica uma oportunidade dentro de sua linha de atuação, normalmente ela solicita um estudo de viabilidade para decidir se deve criar um projeto.. O ciclo de vida do projeto determina se o estudo de viabilidade constituirá a primeira fase do projeto ou se deve ser tratado como um projeto à parte. [PMBOK, 2000]

14 REQUISITO DE SOFTWARE- Característica que o software deve possuir para que seja aceito- Expressão documentada dessa característica (PAULA FILHO, 2003)

Descrições que estabelecem detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificação funcional, deve ser preciso. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor de software. Os requisitos de sistema


de software são, freqüentemente, classificados como funcionais ou não funcionais ou como de domínio: Requisitos funcionais: São declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também declarar o que o sistema não deve fazer. Requisitos não funcionais: São restrições sobre os serviços ou as funções oferecidas pelo sistema. Entre elas destacam-se restrições de tempo, restrições sobre o processo de desenvolvimento, padrões, entre outros.Requisitos de domínio: São requisitos que se originam do domínio de aplicação do sistema e que refletem características desse domínio. Podem ser requisitos funcionais ou não funcionais [SOMMERVILLE, 2003]

O grande desafio dos engenheiros de software é compreender a natureza do problema que se pretende resolver especialmente quando trata-se de desenvolvimento de um software novo. As descrições das funções e restrições do sistema são então os requisitos para o sistema. Um documento de requisitos de software devem possuir dois níveis de detalhamento e deve ser apresentado para validação em momentos diferentes. O primeiro nível de requisito deve tratar o problema de uma forma abrangente permitindo que se possa apresentar a forma de atender as necessidades do cliente para resolver seu problema. Uma vez estabelecida a forma macro para solução do problema passa-se ao segundo nível, onde deve haver um detalhamento maior permitindo a validação por parte do cliente.O primeiro nível ou alto nível pode ser definido como requisitos de usuário. O segundo nível, ou seja, o mais detalhado define-se como requisitos de sistema, que são classificados como requisitos funcionais e não funcionais. Os requisitos não funcionais podem ser classificados ainda em requisitos de produtos, organizacionais e externos. Uma descrição ainda mais detalhada deve ser produzida para associar a engenharia de requisitos e as atividades de projeto. Define-se então uma especificação de projeto de software.

15 VERIFICAÇÃO DE SOFTWARE / Processo de avaliar um sistema, produto ou componente para determinar se ele satisfaz os respectivos requisitos (PAULA FILHO, 2003).

16 VALIDAÇÃO DE SOFTWARE

15 VERIFICAÇÃO DE SOFTWARE / VALIDAÇÃO DE SOFTWARETambém conhecido como V&V, são os processos que asseguram que o software cumpra com suas especificações e atenda às necessidades dos clientes que estão pagando por ele. A verificação e validação constituem um processo de ciclo de vida completo, começando com as revisões de requisitos e continuando com as revisões de projeto e as inspeções de código até chegar aos testes de produto. Deve haver atividades de V&V em cada estágio do processo de software. Essas


atividades verificam se os resultados das atividades de processo estão conforme a especificação. A verificação e validação não são a mesma coisa, embora sejam facilmente confundidas. A diferença entre elas é sucintamente expressa por Boehm (1979): Verificação: estamos construindo certo o produto ? Validação: estamos construindo o produto certo ?Essas definições afirmam que o papel da verificação envolve checar se o software cumpre com suas especificações. É preciso verificar se o sistema cumpre com seus requisitos funcionais e não funcionais especificados. A validação é um processo mais genérico. É necessário assegurar que o software atenda às expectativas do cliente, e isso vai além de checar a conformidade do sistema com suas especificações, a fim de mostrar que o software faz o que o cliente espera que faça, exatamente como foi especificado. [SOMMERVILLE, 2003]

17 REVISÃO TÉCNICA DE SOFTWAREObjetivo de avaliar artefatos específicos para verificar se eles estão conformes com os respectivos padrões e especificações e se eventuais modificações nos artefatos foram efetuadas de maneira correta. As revisões técnicas são aplicadas a documentos como a Especificação de Requisitos, a Descrição de Desenho e a Descrição de Testes, com o objetivo principal de verificar a respectiva conformidade a padrões do processo e práticas de preenchimento, assim como seus atributos internos de qualidade, como completude, correção, precisão, consistência, verificação, modificação e rastreabilidade.[ PAULA FILHO, 2003]

18 TESTE DE SOFTWARE

Técnicas do processo de V&V que envolvem executar uma implementação do software com os dados de teste e examinar as saídas e seu comportamento operacional, a fim de verificar se ele está sendo executado conforme o esperado. Os testes são técnicas dinâmicas de verificação e validação porque trabalham com uma representação executável do sistema. [SOMMERVILLE, 2003]

Executar uma implementação do software com os dados de teste e examinar as saídas dele e seu comportamento operacional, para verificar se ele está sendo executado conforme o esperado, Os testes são técnicas dinâmicas de verificação e validação porque trabalham com uma representação executável do sistema. [SOMMERVILLE, 2003]

São fases do projeto de software onde o principal objetivo é encontrar defeitos de acordo com os requisitos definidos. Dependendo do modelo de desenvolvimento adotado os testes podem ser divididos entre o time de desenvolvimento, testadores de unidade, testadores de módulos, testes de integração, testes de interface, teste de estresse e teste de implementação. O número de iterações que uma unidade ou módulo é submetida até


inexistência de defeitos pode ser uma métrica para a qualidade de software do ponto de vista da produção. Independentemente do modelo de desenvolvimento adotado é fundamental que haja um plano de testes para que se possa preparar a infra-estrutura (equipamentos, artefatos de software liberados para testes, banco de dados, etc.) para início e término dos testes e especialmente saber o que deve-se testar.

19 GERÊNCIA DE CONFIGURAÇÃO(Configuration Management – CM) Desenvolvimento e a aplicação de padrões e procedimentos para gerenciar um produto de sistema em desenvolvimento. É necessário gerenciar os sistemas em desenvolvimento porque, à medida que eles se desenvolvem, são criadas muitas versões diferentes do software. Essas versões incorporam propostas de mudanças, correções de defeitos e adaptações para diferentes elementos de hardware e sistemas operacionais. É preciso manter o controle de mudanças que foram implementadas e de como essas mudanças foram incluídas no software. Os procedimentos de gerenciamento de configuração definem como registrar e processar as mudanças propostas para o sistema, como relacioná-las aos componentes de sistema e aos métodos para identificar diferentes versões do sistema. As ferramentas de gerenciamento de configuração são utilizadas para armazenar versões de componentes de sistema, construir sistemas a partir desses componentes e acompanhar os releases das versões de sistema para os clientes. [SOMMERVILLE, 2003]

É o desenvolvimento ou utilização de padrões e procedimentos para gerenciar um produto de software em desenvolvimento. Durante o desenvolvimento de um software, inúmeras versões de componentes e módulos são geradas, em função da própria evolução dos artefagos de software, do modelo de ciclo de vida adotado e das mudanças aprovadas que ocorrem durante o próprio processo de desenvolvimento. A Gerência de Configuração deve ser responsável pelo controle das liberações do time de desenvolvimento para a equipe de qualidade que verifica se os padrões adotados para o projeto estão sendo seguidos. Ferramentas CASE devem apoiar as atividades de gerenciamento de configuração

20 GARANTIA DA QUALIDADE (QA- QUALITY ASSURANCE)Uso da estatística para estimar a qualidade do software. Executar o código com um pequeno conjunto de casos de testes randômicos dará resultados que podem ser usados para estimar a qualidade. Isso algumas vezes é chamado de prova de software. A média de erros na amostra aleatória pode ser usada como uma estimativa para a média de erros no projeto final.Uma parte importante na obtenção da qualidade é planejar para a qualidade, isto é, planejar as atividades que irão auxiliar na obtenção da qualidade. A IEEE Standards Association desenvolveu um padrão para planos da garantia da qualidade de software incluindo Propósito, Documentos de referência, Gerenciamento, Documentação, Padrões e Métricas, Revisões e Auditoria, Testes, Relatório do Problema, Ferramentas, técnicas e metodologia, Controle de código, Controle dos Meios, Controle de Fornecedor, Registros, Treinamento, Gerenciamento de risco. [GUSTAFSON, 2003]


A garantia da qualidade consiste em todas as atividades planejadas e sistemáticas que são implementadas dentro do sistema de qualidade buscando assegurar que o projeto irá satisfazer os padrões relevantes de qualidade. Deve ser realizada durante todo o projeto. A garantia da qualidade é freqüentemente fornecida pelo Departamento de Garantia da Qualidade ou unidade organizacional similar, embora isso não seja uma exigência. [PMBOK, 200]

21 PNQ – PRÊMIO NACIONAL DA QUALIDADEO PNQ é um reconhecimento à excelência na gestão das organizações sediadas no Brasil. O Prêmio busca promover: entendimento dos requisitos para alcançar a excelência do desempenho e, portanto, a melhoria da competitividade; troca de informações sobre métodos e sistemas de gestão que alcançaram sucesso e sobre os benefícios decorrentes da utilização dessas estratégias. [FPNQ]

O Prêmio Nacional da Qualidade é o reconhecimento público e notório à excelência do desempenho das organizações e busca promover a aplicação do estado da arte da gestão para ao aumento da competitividade das empresas nacionais. As empresas premiadas são consideradas como modelos de organizações competentes e suas estratégias de desempenho para alcançar o sucesso, assim como, os benefícios decorrentes da utilização dessas estratégias são considerados como benchmarking e replicados por outras empresas na busca da melhoria da gestão.

O Prêmio é concedido anualmente pelo Ministério da Ciência e Tecnologia (MCT) a cinco categorias: grandes empresas; médias empresas; pequenas e microempresas; organizações sem fins lucrativos; e organizações da administração pública.

Para a obtenção da premiação, as empresas se submetem a um processo de avaliação da sua gestão, com base na aplicação dos Fundamentos e nos Critérios de Excelência, na avaliação desse Relatório de Gestão por uma Banca de Examinadores, na visita às instalações e no julgamento de uma Banca de Juizes. Ao final do processo, as empresas candidatas recebem um Relatório de Avaliação da sua gestão.

Os conceitos, princípios e valores definidos como essenciais para o exercício da excelência na gestão são apresentados por meio dos seguintes Fundamentos:

Liderança e constância de Propósitos;Visão de Futuro; Responsabilidade Social e Ética; Decisões Baseadas em Fatos; Valorização da Pessoa;


Abordagem por Processos; Foco nos Resultados; Inovação; Agilidade;Aprendizado Organizacional

22 PMBOK – PROJECT MANAGEMENT BODY OK KNOWLEDGEO PMBOK, compilado pela expertise do PMI – Project Management Institute, é a linha mestra que nos conduz ao conhecimento organizado da gerência de projetos. O estudo do PMBOK é fundamental para que os gerentes de projetos possam compreender os ensinamentos e relacionamentos que, através das áreas de conhecimento e de processos preconizados pela metodologia, traduzem os conceitos mais atuais da prática de Gerenciamento de Projetos no mundo. [PMBOK, 2000].

É um guia que representa o somatório do conhecimento dentro da profissão de gerenciamento de projetos, baseado nas contribuições de profissionais e estudantes que o aplicam e desenvolvem. Seu conteúdo é baseado nas melhores práticas em gerencimento projeto o que significa dizer que são aplicadas na maioria dos projetos na maioria das vezes, e que há um consenso amplamente difundido sobre seu valor e utilidade. É um guia geral para que poder ser utilizado em diversas áreas de aplicação, onde sua abrangência e aderência é de responsabiliade do gerente de projetos e do time de projetos. O PMBOK está orientado a processos categorizado em 5 macro-processos (inicição, planejamento, execução, monitoramento e controle e encerramento) que definem 44 processos distribuídos por 9 áreas de conhecimento.

É utilizado pelo PMI como referência para uma estrutura de desenvolvimento profissional que incluem a certificação PMP – Project Management Professional, e credenciamento de Programas Educacionais em Gerenciamento de Projetos.

23 ISO 9000 / ISO 9001A ISO 9000 é uma série de 4 normas internacionais para “Gestão da Qualidade” e “Garantia da Qualidade”. Ela não é destinada a um “produto” nem para alguma indústria específica. Tem como objetivo orientar a implantação de sistemas de qualidade nas organizações. As regras e os padrões da Gestão da Qualidade e Garantia da Qualidade são complementares aos padrões do produto, e são implantados para melhorar a sua qualidade, com impacto na funcionalidade do Sistema da Qualidade. A série é composta das seguintes normas:ISO 9000 - Fundamentos e vocabulárioISO 9001 - Sistemas de gerenciamento da qualidade - requisitos


ISO 9004 - Sistemas de gerenciamento da qualidade - guia para melhoramento da performanceISO 19011 - Auditorias internas da qualidade e ambientalA série ISO 9000 foi adotada no Brasil, palavra por palavra pela ABNT com o nome de NBR 9000.

[OLIVEIRA, 2001]

A primeira versão de normas da Família ISO 9000 foi editada em 1987; a segunda, em 1994; e a terceira, em 2000. Cada nova edição é antecedida de análises críticas, estudos aprofundados e criteriosos, tendo em vista a melhoria contínua da capacidade de atender requisitos. Por exemplo, as NBR ISO 9001 / 9002 / 9003: 1994 deram origem a NBR ISO 9001: 2000.Fonte : Boletim Qualidade - ANO III - Número 98 - Dezembro de 2004

24 ISO 90003 (ISO 9000-3)Esta norma trata do desenvolvimento de software, baseada na ISO 9001, sendo perfeitamente aplicada com excelentes resultados em empresas de desenvolvimento de software. O foco está na documentação do sistema da qualidade, estabelecendo uma visão da empresa em relação aos interesses e necessidades dos clientes, resultando em melhor qualidade. [CORTÊS,]

25 ISO 15504 (SPICE)Criado em 1993, o projeto SPICE, acrônimo para Software Process Improvement and Capability dEtermination com o objetivo de produzir um relatório que fosse ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específicos que a ISO 9001. O SPICE passou a ser um modelo mais genérico com uma organização estruturada de processos que permite a utilização dos demais modelos como referência. Uma das inovações do SPICE é a sua organização em duas dimensões, a de processos e a de capacidade de processo . Essa arquitetura de duas dimensões, juntamente com os mecanismos de pontuação propostos, permite a criação de perfis de capacidade muito significativos e interessantes. O SPICE, como a maioria dos outros modelos, pode ser usado para a realização de avaliações com dois objetivos, a melhoria de processos e a determinação da capacidade dos processos de uma organização.[CORTES, 2001]

O comitê de Engenharia de Software da ISO (International Standards Organization) em 1991 aprovou a realização de estudos para analisar as necessidades e os requisitos de um padrão para avaliação de processos de software. O resultado do estudo concluiu que havia um consenso internacional sobre a necessidade e requisitos para um padrão de avaliação de processo. Formou-se um equipe com dedicação exclusiva em quatro centros técnicos de desenvolvimento: Inglaterra, Austrália, EUA e Canadá. Em 1993 foi lançado o projeto SPICE com objetivo de gerar normas


para avaliação de processos, visando a melhoria contínua do processo . O SPICE é um framework para avaliação de processos de software, que harmoniza os diversos modelos nos quais ele se baseia (SW-CMM, Trillium, Software Techbonology Diagnostic (STD) e Bootstrap). O objetivo principal é que os modelos de software criados e que venham a ser criados possam ser definidos como modelos compatíveis a esse framework, permitindo a comparação. O projeto SPICE definiu a norma ISSO/IEC 15504. A norma ISO 15504 (SPICE), organiza seu trabalho segundo o que está descrito na norma ISO 12207.

A avaliação dos processos de software têm como propósito:

entender os estados dos processos de uma organização para sua melhoria. determinar a adequação dos processos de uma organização para um requisito ou classe

de requisitos.determinar a adequação dos processos de uma outra organização para um contrato ou classe de contratos.

26 ISO 12207É uma norma que formaliza a arquitetura do ciclo de vida do software, que é um assunto de

Engenharia de Software e também em qualquer estudo sobre Qualidade do Processo de Software.

Detalha os processos envolvidos no ciclo de vida do software e estão divididos em três classes:

Processos Fundamentais (aquisição, fornecimento, desenvolvimento, operação, manutenção)

Processos de Apoio (documentação, gerência de configuração, garantia da qualidade, verificação, validação, revisão conjunta, auditoria, resolução de problemas)

Processos Organizacionais (gerência, infra-estrutura, melhoria e treinamento)

É uma norma internacional que descreve em detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de software. A principal finalidade desta norma é servir de referência para os demais padrões que venham a surgir. Lançada em agosto de 1995, ela é citada em quase todos os trabalhos relacionados à Engenharia de Software desde então, inclusive aqueles relativos à qualidade.

27 ISO 9126 (NBR ISO 13596)Norma que se apresenta em seis características subdivididas em subcaracterísticas

que descrevem a qualidade de software. São aplicáveis à qualquer tipo de software. Esta voltada para pessoas relacionadas à aquisição, desenvolvimento, uso, avaliação, suporte, manutenção ou auditoria de software.

As características da Qualidade de Software segundo a ISSO/IEC 9126 são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade, portabilidade.

28 SW- CMM O SW-CMM cobre práticas para planejar, gerenciar e manter processos de

desenvolvimento e gerenciamento de software. Quando tais práticas são seguidas rotineiramente, as organizações capacitam-se a um melhor controle dos custos, prazos, produtividade e qualidade dos projetos de software. O SW-CMM não define um método e


sim um modelo que precisa ser estudado, compreendido e implementado de acordo com as características de cada organização. O SW-CMM não diz como fazer mas sim o quê fazer. O SW-CMM propõe uma evolução através de níveis de maturidade de capacitação.

Nível 1 (Inicial): O processo de desenvolvimento é uma caixa preta, ou seja, nebuloso. Não há gerência de requisitos e o cliente só avalia o produto final na entrega do mesmo.Nível 2 (Repetitivo): Possuem controle básico de gerência de desenvolvimento de software.Nível 3 (Definido): Inclui processos de engenharia e gerência de software. Gerentes e técnicos conhecem seus papéis e responsabilidades. Os processos são estáveis e repetíveis.Nível 4 (Gerenciado): Processos são medidos e controlados quantitativamente. O cliente passa a ter um entendimento quantitativo do risco do projeto antes do mesmo iniciar. Os gerentes são capazes de predizer resultados, portanto inferem menor variabilidade nos processos.Nível 5 (Otimizado): Foco na melhoria do processo. Tenta-se de maneira contínua e controlada novas maneiras de se construir software. Clientes e a organização trabalham juntos para fortalecer seu relacionamento

29 CMMICMMI (Capability Maturity Model Integration), desenvolvido pelo Software Engineering Institute (SEI), com o objetivo de melhoria nos processos de software. Através da avaliação das áreas chaves do desenvolvimento de software para otimizar e garantir a qualidade em todo o projeto. Este modelo exige, mais que melhoria dos processos e procedimentos envolvidos, a melhoria nas etapas de desenvolvimento e execução.

O CMMI(Capability Maturity Model Integration) que é um framework focado no processo de desenvolvimento de software. Ele foi desenvolvido através de observações das melhores práticas nas organizações de software e reflete uma coletânea de experiências e expectativas de muitas delas. Embora este modelo seja completo e abrangente, segundo o SEI/CMU (Software Engineering Institute/ Carnegie Mellon University), a preocupação dele está em descrever o quê uma organização em certo nível de maturidade deve praticar. O CMMI não orienta como a empresa deve implementar suas áreas de processo para atingir os níveis de excelência propostos pelo modelo. [AGNOL, 2004]

É um conjunto de processo e ferramentas padronizadas que suportam projetos de desenvolvimento de sistemas criado pela SEI – Software Engineering Institute. É uma evolução do SW-CMM. O principal objetivo e disponibilizar uma linha de base processual


buscando uma prática de melhoria contínua de processos e a correta gestão das atividades de aquisição, desenvolvimento e manutenção de produtos e serviços de software.

CMMI - Process Areas x Maturity level


30 PSP – PERSONAL SOFTWARE PROCESSO modelo de melhoria de processos individual, o Personal Software Process (PSP), tem como finalidade à melhoria no trabalho pessoal, com métricas, disciplina nos processos, estimativa, planejamento do trabalho e gerenciamento da qualidade. (HUMPHREY, 1999)

31 TSP – TEAM SOFTWARE PROCESSDesenvolvido pela SEI, o TSP (Team Software Process) apresenta métodos para estruturar as mudanças necessárias para os times e desenvolver os projetos com alta qualidade. Sendo um modelo de organização de times, propõe estabelecer papéis, elaborar, projetar, planejar, seguir o projeto e relatar o seu progresso, servindo com um guia para o gerenciamento de equipes de desenvolvimento de software. (HUMPRHEY, 1999).

O objetivo do TSP é criar um ambiente de trabalho em equipe que suporte o trabalho individual disciplinado e mantenha-o direcionado à equipe. A metodologia TSP conduz o desenvolvimento de software através de vários ciclos rápidos até atingir o produto final. Cada ciclo guia a equipe através de sete passos: lançamento, estratégia, planejamento, requisitos, projeto, implementação, teste e postmortem. Em cada ciclo os desenvolvedores repetem os mesmos passos (Figura 1) e aumentam o produto construído no ciclo anterior.

[AGNOL, 2004]

32 XP – EXTREME PROGRAMMINGExtreme Programming => Processo de desenvolvimento de software para: Projetos cujos requisitos são vagos e mudam com freqüência; Desenvolvimento de sistemas orientados a objeto; Equipes pequenas, preferencialmente até 12 desenvolvedores; Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo.Existe uma categoria de processos de desenvolvimento conhecida como Processos Ágeis de Desenvolvimento dentro da qual o XP e outros processos de encaixam. O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software.[ TELES, 2004]


É uma metodologia para desenvolvimento de software focada nos times de desenvolvimento e está voltada para a satisfação do cliente, entregando artefatos de software que o ele necessita e quando necessita. É composto por um conjuto de processos desburocratizados e pode ser adaptado em pequenas e médias organizações produtoras de software. Gerentes, clientes finais e desenvolvedores fazem parte do time de projeto dedicados à entregar os produtos de software com qualidade. O XP melhora os projetos de software usanso quatro vertentes essenciais: comunicação, simplicidade, feedback e coragem.

O XP mantém o desenho de software simples e claro e prevê a entrega dos artefatos de o mais cedo possível e proceder então as modificações necessárias. Deve ser usado quando os usuários não sabem exatamente o que querem ou não tem o problema claramente definido. As práticas definidas pelo XP são voltadas para mitigar os riscos inerentes à própria metodologia e aumentar a probabilidade de sucesso dos projetos. O XP tem seu melhor desempenho em equipes de 2 a 12 pessoas. O XP define quatro processos simplificados para desenvolvimento de software que seguem as seguintes regras e práticas:

PlanejamentoDesignCodificaçãoTestes

33 UP – UNIFIED PROCESS / RUP – RATIONAL UNIFIED PROCESS

UP – Unified Process / RUP – Rational Unified Process => Processo de Engenharia de Software. Ele fornece uma abordagem disciplinada para seguir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Seu objetivo é assegurar a produção de software de alta qualidade que satisfaça as necessidades de seus usuários finais dentro de prazo e orçamento previsíveis. O RUP captura muitas das melhores práticas no desenvolvimento moderno de software de forma satisfatória para uma grande faixa de projetos e organizações. Em particular, cobre seis práticas importantes de software. Desenvolver software iterativamente Gerenciar exigências Usar arquiteturas baseadas em componente Modelar visualmente o software Verificar continuamente a qualidade do software Controlar mudanças no software

[KRUCHTEN,2003]

A UP é um processo de desenvolvimento de software com alguns diferenciais:

Ciclo de vida Iterativo: as atividades de requerimentos, análise, design, construção e testes se repetem (4 a 6 iterações).

Utiliza a UML para definição da arquitetura: através de diagramas UML, são definidos modelos que compõem a arquitetura do sistema.


Baseados em Casos de Uso: capturam requerimentos funcionais do sistema do ponto de vista dos usuários.

É um processo parametrizável: de acordo com as necessidades do projeto

O RUP é uma versão especializada da UP, com elementos adicionais. É um produto desenvolvido e mantido pela Rational Software, com suite de produtos de desenvolvimento de software com documentação, exemplos e templates.

Fases propostas pelo RUP: Concepção, Elaboração, Construção e Transição. O RUP e orientado em casos de uso e centrado na arquitetura, é iterativo e incremental. O RUP considera os fluxos de trabalho de Análise e Design como únicos


REFERÊNCIAS B IBLIOGRÁFICASAgnol, Samuel Dall, Herbert, Juliana Silva. Utilização do TSP para a Gerência de Equipes Nível 2 do CMMI. Artigo . VI Simpósio Internacional de Melhoria de Processos de Software – SIMPROS. 2004.

BOAR, B. Tecnologia da informação: a arte do planejamento estratégico. 2.ed. São Paulo: Berkeley, 2002.

CÔRTES, Mario Lúcio, CHIOSSI, Thelma C. dos Santos, Modelos de qualidade de software Unicamp Técnicos & Científicos. 2001

GUSTAFSON, David A., Engenharia de Software, Edt. Bookman, 2003

HUMPHREY, Watts S. Pathways to Process Maturity: The Personal Software Process and Team Software Process. SEI Interactive, 1999

JURAN, J.M. A qualidade desde o projeto – os novos passos para o planejamento da qualidade em produtos e serviços. Tradução. Nivaldo Montiguelli Jr. São Paulo. Thomson Pioneira. 1992. (8-9).

KRUCHTEN, Philippe, Introdução ao RUP, Edt. Ciência Moderna, 2003

LAUDON, J. P.; LAUDON, K. C. Sistemas de informação. 4.ed. Rio de Janeiro: LTC, 1999.

OLIVEIRA, Marcos IMPLANTANDO A ISO 9001:2000 EM PEQUENAS E MÉDIAS EMPRESAS. Salvador. Editora QUALITAS. 2001.

PALADINI, Edson Pacheco. Gestão da Qualidade: teoria e prática. São Paulo. Atlas. 2004.

PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 2.ed. Rio de Janeiro: LTC, 2003.

PMBOK - Project Management Body of Knowledge – versão Belo Horizonte, 28 de Maio de 2000

PRAZERES, P. M. Dicionário de termos da qualidade. São Paulo: Atlas, 1996

PRESSMAN, Roger S. Engenharia de software. Tradução José Carlos Barbosa dos Santos. São Paulo. Makron Books, 1995.

PRESSMAN, Roger S., Engenharia de Software, Edt. Makron Books, 2001

SOMMERVILLE, Ian. Engenharia de Software. Tradução André Maurício de Andrade Ribeirto. São Paulo: Addison Wesley, 2003.

TELES, Vinícius Manhães, Extreme Programming,Edt. NOVATEC, 2004

Documents

1 – Cliente (interno / externo) · Web viewO PMBOK, compilado pela expertise do PMI – Project Management Institute, é a linha mestra que nos conduz ao conhecimento organizado