TI - Conhecimentos Específicos - Engenharia da Computação - Concursos

8/6/2019 TI - Conhecimentos Especficos - Engenharia da Computao - Concursos

1/420


2/420

2.1 O que Processo de Software

Um processo de software pode ser definido como um conjunto coerente de atividades,

polticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessrios

para conceber, desenvolver, dispor e manter um produto de software (FUGGETTA, 2000).

Um processo eficaz deve, claramente, considerar as relaes entre as atividades, os

artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessrios e

a habilidade, o treinamento e a motivao do pessoal envolvido (FALBO, 1998).

A escolha de um modelo de ciclo de vida (ou modelo de processo) o ponto de

partida para a definio de um processo de desenvolvimento de software. Um modelo de

ciclo de vida organiza as macro-atividades bsicas, estabelecendo precedncia edependncia entre as mesmas (FALBO, 1998).

Processos de software definem o conjunto de atividades conduzidas no contexto do

projeto, tais como anlise de requisitos, projeto, codificao, teste, instalao etc, os

recursos (software, hardware e pessoas) necessrios e os procedimentos a serem adotados

na realizao de cada uma das atividades. Sendo que essas atividades so compostas por

outras atividades e podem se comunicar entre si e operam sobre artefatos de entrada para

produzir artefatos de sada (FALBO, 1998) (GRUHN, 2002).

Outra questo que envolve a elaborao de um processo de software a sua

adequao ao domnio de aplicao e ao projeto. A cada projeto, o processo de software

deve ser ajustado s especificidades da aplicao, tecnologia a ser utilizada na sua

construo, grupo de desenvolvimento e usurios finais (FALBO, 1998).

2.2 Nveis de Processo de Software

Apesar de cada projeto ter suas caractersticas prprias, possvel estabelecer

conjuntos de ativos de processo (sub-processos, atividades, sub-atividades, artefatos,

recursos e procedimentos) comuns para toda a organizao. Esses conjuntos constituem os

chamados processos padro de uma organizao. A partir deles, outros processos, ainda

padro, podem ser especializados, levando-se em considerao caractersticas como tipos


3/420

de software, paradigmas ou domnios de aplicao. Finalmente, para cada projeto, pode-se

instanciar um processo padro, especializado ou no, buscando atender s suas

caractersticas prprias, definindo os chamados processos de projeto (ROCHA et al., 2001)

(BERTOLLO et al., 2006).

Esse modelo de definio de processos em nveis adotado no Laboratrio de

Engenharia de Software (LabES) da UFES, como mostra a Figura 2.1. Os processos padro

para o desenvolvimento e manuteno de software do LabES so definidos tomando por

base modelos e normas de qualidade, principalmente as normas ISO/IEC 12207 (ISO/IEC,

1998) e IEEE 1219 (IEEE, 1998) e o modelo MPS.BR (SOFTEX, 2006).

Figura 2.1 Modelo para Definio de Processos em Nveis

A partir deles so especializados outros processos padro de desenvolvimento e

manuteno, tais como os Processos Especializados para o Desenvolvimento Orientado a

Objetos (PPELabESOO) e para o Desenvolvimento segundo o Paradigma Estruturado

(PPELabES-Est). Esses processos podem ser recursivamente especializados, criando outros

nveis na hierarquia. Por exemplo, conforme discutido no captulo 4 deste trabalho, a partir

dos processos especializados para desenvolvimento e manuteno orientados a objetos,

foram definidos processos especializados para desenvolvimento e manuteno de Software

Livre no LabES, considerando a heterogeneidade dos grupos de trabalho, caractersticas do

Processo Padro

Especializao

Normas e Modelos deQualidade,

Cultura Organizacional

Tipo de Software,Domnio do Problema,

Paradigma eTecnologia de

Desenvolvimento

Particularidades doProjeto, Modelo deCiclo de Vida (ou

Modelo de Processo)

Processo Especializado 1 Processo Especializado n

Processo de Projeto mProcesso de Projeto 1

PPLabES

Instanciao

Definio

ISO/IEC 12207,IEEE 1219, MPS.BR

PPELabES-OOPPELabES-Est


4/420

desenvolvimento de software com equipes geograficamente dispersas e prticas aplicadas a

projetos de Software Livre bem sucedidos.

2.3 Qualidade de Processo de Software

Quando se produz um software, assim como qualquer outro produto, desejvel que

o mesmo possua elevada qualidade, que seja produzido de forma otimizada e dentro dos

prazos estabelecidos previamente. No desenvolvimento de software, uma das principais

maneiras de se garantir tais caractersticas para o produto final atravs de um processo de

software de qualidade. Ou seja, se um produto de software foi desenvolvido seguindo um

processo de qualidade, as chances do mesmo ser um produto de qualidade so maiores.

Alm disso, para que a organizao que produz software tenha sua qualidadereconhecida em todo o mundo, seus processos devem respeitar padres de qualidade

definidos pela comunidade de software.

Desde a dcada de 1980, iniciaram-se esforos para melhoria de processos de

software, com o objetivo de melhorar a qualidade, aumentar a produtividade e diminuir os

custos. Diferentes modelos so utilizados dependendo do mercado alvo das organizaes de

software (ROCHA et al., 2001). As principais normas e modelos de qualidade difundidos

atualmente so: ISO 9000 (ISO, 2000), ISO/IEC 12207 (ISO/IEC, 2008), ISO/IEC 15504

(ISO/IEC, 2003), CMMI (SEI, 2006) e MPS.BR (SOFTEX, 2007), sucintamente

apresentados na seqncia.

2.3.1 ISO 9000:2000

As normas da famlia NBR ISO 9000:2000 (ISO, 2000) foram desenvolvidas para

apoiar organizaes de todos os tipos e tamanhos (no s as de software), na

implementao e operao de sistemas de gesto da qualidade eficazes.

A norma ISO 9000 descreve os fundamentos de sistemas de gesto da qualidade, que

constituem o objeto da famlia NBR ISO 9000, e define os termos a ela relacionados (ISO,

2000).


5/420

A famlia NBR ISO 9000 composta de uma srie de normas, sendo a ISO 9001 a

mais completa, abrangendo todo o ciclo de vida de um produto ou servio, cobrindo os

requisitos para a garantia da qualidade em projetos, desenvolvimento, produo, instalao

e servios associados (MUTAFELIJA et al., 2003).

A ISO 9000:2000 baseada em um conjunto de princpios de gerenciamento de

qualidade, definidos a partir da experincia de vrias organizaes (ISO, 2000):

Princpio 1 - Foco no cliente: Dado que as organizaes dependem de seus

clientes, recomendvel que atendam s suas necessidade atuais e futuras e

aos seus requisitos e procurem exceder as suas expectativas.

Princpio 2 -Liderana: Lderes estabelecem a unidade de propsito e o rumo

da organizao. Convm que criem e mantenham um ambiente onde as

pessoas estejam totalmente envolvidas no propsito de atingir os objetivos da

organizao.

Princpio 3 - Envolvimento de pessoas: Pessoas de todos os nveis so a

essncia de uma organizao. Seu envolvimento possibilita o aproveitamento

de suas habilidades por toda a organizao.

Princpio 4 - Abordagem de processo: Um resultado desejado alcanado

mais eficientemente quando suas atividades e recursos so gerenciados comoum processo.

Princpio 5 - Abordagem sistmica para a gesto: Identificar, entender e

gerenciar os processos inter-relacionados como um sistema contribui para a

eficcia e eficincia da organizao no sentido desta atingir os seus objetivos.

Princpio 6 - Melhoria contnua: Convm que a melhoria contnua do

desempenho global da organizao seja seu objetivo permanente.

Princpio 7 - Abordagem factual para tomada de deciso: Decises eficazes

so baseadas na anlise de dados e informaes.

Princpio 8 - Benefcios mtuos nas relaes com os fornecedores: Pelo fato

de organizao e fornecedores serem interdependentes, uma relao de

benefcios mtuos aumenta a capacidade de ambos em agregar valor.


6/420

Para que as organizaes funcionem de forma eficaz, elas tm que identificar e

gerenciar processos inter-relacionados e interativos. Freqentemente, a sada de um

processo resultar diretamente na entrada do processo seguinte. A identificao sistemtica

e a gesto dos processos empregados na organizao e, particularmente, as interaes entre

tais processos so conhecidos como abordagem de processos. Assim, a inteno desta

norma encorajar a adoo da abordagem de processo para a gerncia da qualidade em

uma organizao (ISO, 2000).

2.3.2 ISO/IEC 12207

Ver na Norma ISO/IEC 12207:2008 as seguintes sees:

Seo 1 (pgs 1 e 2)

Seo 5 (pgs 9 a 18)

2.3.3 ISO/IEC 15504

A norma internacional ISO/IEC 15504 (ISO/IEC, 2003) estabelece uma estrutura paraa avaliao de processos. Essa estrutura pode ser usada por organizaes envolvidas com

planejamento, gerenciamento, monitorao, controle e melhoria de aquisio,

fornecimento, desenvolvimento, operao, evoluo e suporte de software. So propsitos

dessa norma:

ajudar organizaes a compreender o estado de seus prprios processos com

vistas melhoria;

ajudar organizaes a determinar a adequao de seus processos para umrequisito particular ou classe de requisitos;

ajudar organizaes a determinar a adequao de processos de uma outra

organizao para um contrato particular ou classe de contratos.


7/420

A norma consiste das seguintes partes, sob o ttulo geral Tecnologia de Informao

Avaliao de Processo de Software (ISO/IEC, 2003):

Parte 1: Conceitos e vocabulrio (informativo): prov uma introduo geral

aos conceitos de avaliao de processos e um glossrio de termos relacionadosa avaliao.

Parte 2: Realizando uma avaliao (normativa): define os requisitos mnimos

para a realizao de uma avaliao.

Um modelo de referncia para processos e capacidade de processos

Parte 3: Guia para a realizao de avaliaes (informativa): prov orientaes

para interpretar os requisitos para a realizao de uma avaliao.

Parte 4: Guia para uso na melhoria de processo e na determinao da

capacidade de processo (informativa): identifica a avaliao de processo como

uma atividade que pode ser realizada tanto como parte de uma iniciativa de

melhoria de processo quanto parte de uma abordagem de determinao da

capacidade.

Parte 5: Um Exemplo de modelo de avaliao de processo baseado na

ISO/IEC 12207 e suas Emendas 1 e 2 (informativa): contm um exemplo de

modelo de avaliao de processo que baseado no modelo de processo de

referncia definido na ISO/IEC 12207.

A parte 5 da norma ISO/IEC 15504 desperta maior interesse para os interessados na

definio de processo, por oferecer um modelo de referncia disposto a guiar a definio de

um processo de software de qualidade. De fato, o objetivo dessa parte da ISO/IEC 15504

definir um exemplo de um Modelo de Avaliao de Processo que satisfaz os requisitos da

ISO/IEC 15504-2 e que apia a realizao de uma avaliao, provendo indicadores para

guiar a interpretao dos propsitos de processo, conforme definidos na ISO/IEC 12207, e

dos atributos de processo definidos ISO/IEC 15504-2.

O Modelo de Avaliao de Processo nesta parte da ISO/IEC 15504 dirigido a

patrocinadores de avaliaes e avaliadores competentes que desejem escolher um modelo

para avaliao, seja para determinao da capacidade seja para melhoria de processo.


8/420

Adicionalmente, esse modelo pode ser til para os desenvolvedores de modelos de

avaliao, provendo exemplos de boas prticas de gerncia e engenharia de software.

2.3.4 CMMI

O projeto CMMI (Capability Maturity Model Integration) (SEI, 2006) foi

concebido para solucionar o problema do uso de mltiplos modelos de maturidade de

capacitao, tendo como foco trs modelos principais: SW-CMM (Capability Maturity

Model for Software), SECM (System Engineering Capability Model) e IPD-CMM

( Integrated Product Development Capability Maturity Model) (CHRISSIS et al., 2003).

um projeto patrocinado pelo Departamento de Defesa Americano, em conjunto com a

indstria, por meio do Comit de Engenharia de Sistemas na Associao Industrial de

Defesa Nacional, e o Instituto de Engenharia de Software (Software Engineering Institute

SEI). O projeto CMMI envolveu um grande nmero de pessoas de diferentes organizaes

de todo o mundo, interessadas nos benefcios do desenvolvimento de uma estrutura

integrada em prol da melhoria de processos.

Apesar de prover um novo modelo, o CMMI procura preservar ao mximo os

investimentos feitos em melhoria de processos baseadas no SW-CMM.

O objetivo do CMMI fornecer direcionamentos para melhorar os processos deuma organizao e sua capacidade de gerenciar o desenvolvimento, aquisio e manuteno

de produtos e servios. O CMMI prov abordagens comprovadas em uma estrutura que

ajuda organizaes a avaliar sua maturidade ou capacidade em determinada rea de

processo, estabelecer prioridades para melhoria e implementar essas melhorias.

bom lembrar que o CMMI direcionado para a melhoria de processos de

organizaes de qualquer tipo. Alm disso, como outros modelos de maturidade de

capacitao, os modelos do CMMI fornecem orientaes a serem utilizadas no

desenvolvimento de processos. Ou seja, esses modelos no so processos ou descries de

processos. Os processos reais utilizados em uma organizao dependem de vrios fatores,

incluindo domnio de aplicao e tamanho e estrutura da organizao. Assim, normalmente,

as reas de processo do modelo CMMI no podem ser mapeadas uma a uma em processos

utilizados em uma organizao (SEI, 2006).


9/420

O CMMI tem duas representaes: em estgio e contnua. Ambas as representaes

contm reas de processo comuns. Porm, na representao em estgio, as reas de

processo esto agrupadas em nveis de maturidade e na representao contnua, a mesma

rea de processo est dividida em categorias.

A representao contnua permite selecionar a seqncia de melhorias que melhor

atende aos objetivos de negcio e reduz as reas de risco da organizao. Tambm permite

comparaes entre organizaes em uma rea de processo pela comparao de resultados

utilizando estgios equivalentes (SEI, 2006).

A representao em estgios oferece uma seqncia comprovada de melhorias,

comeando com prticas bsicas de gerncia e progredindo por um caminho pr-definido e

comprovado de nveis sucessivos, cada um servindo de base para o prximo. Alm disso,

permite comparaes entre organizaes pelo uso de nveis de maturidade (SEI, 2006).Mesmo no sendo objetivo principal da representao contnua a classificao em

um determinado nvel de maturidade, e sim o desenvolvimento de determinadas reas de

processos, um determinado nvel de maturidade pode ser atingido por quem usa a

representao contnua, se todas as reas de processo relevantes para tal nvel tiverem

atingido a capacidade mnima para o nvel de maturidade.

Os componentes do Modelo CMMI incluem nveis de maturidade (Maturity Levels),

reas de processo ( Process Areas - PAs), metas genricas (Generic Goals - GG), metas

especficas (Specific Goals - SG), prticas genricas (Generic Practices - GP) e prticas

especficas (Specific Practices - SP), como ilustra a Figura 2.4.

Uma rea de processo um grupo de prticas relacionadas em uma rea que,

quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas

importantes para trazer uma melhoria significativa naquela rea. As reas de processos do

CMMI so as mesmas para ambas as representaes (contnua e em estgios). Na

representao em estgios, as reas de processo esto organizadas por nveis de maturidade.

As metas especficas se aplicam a uma rea de processo e contemplam

caractersticas nicas que descrevem o que deve ser implementado para satisfazer tal rea.

Metas especficas so componentes exigidos do modelo e so utilizadas nas avaliaes para

auxiliar a determinar se a rea de processo est sendo satisfeita.


10/420

Prticas especficas so atividades consideradas importantes na satisfao de suas

metas especficas associadas. Descrevem atividades focadas no atendimento de metas

especficas de uma rea de processo. As prticas especficas so componentes esperados do

modelo.

As metas genricas so chamadas de genricas, pois a mesma declarao de meta

encontrada em diversas reas de processos. Na representao em estgios, cada rea de

processo tem somente uma meta genrica. A satisfao de uma meta genrica em uma rea

de processo significa um controle melhorado do planejamento e implementao dos

processos associados com aquela rea de processo, indicando, portanto, se esses processos

parecem ser eficientes, repetveis e durveis. As metas genricas so componentes exigidos

do modelo e so utilizadas em avaliaes para determinar a satisfao de uma rea de

processo.As prticas genricas oferecem uma institucionalizao que garante que os

processos associados com a rea de processo em questo sero eficientes, repetveis e

durveis. As prticas genricas so categorizadas pelas metas genricas e caractersticas

comuns e so componentes esperados em modelos CMMI.

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Caractersticas Comuns

Process Area 1 Process Area n

Ability

Implementation

Verifying

to Perform

Commitment Directing

Implementation

Specific Goals

Implementation

Specific Practices

Nveis de Maturidade

Prticas Genricas

Metas Genricas

rea de Processo 2rea de Processo 1 rea de Processo n

Habilitao ImplementationVerificao daCompromissoImplementao

Metas Especficas

Implementao

Prticas Especficas

Figura 2.4 Componentes do Modelo CMMI.


11/420

O nvel de maturidade de uma organizao uma maneira de prever o futuro

desempenho da mesma dentro de dada disciplina ou conjunto delas. A experincia mostra

que as organizaes funcionam melhor quando concentram seus esforos de melhoria de

processos em um nmero controlado de reas de processos que exigem esforo cada vez

mais sofisticado medida que a organizao melhora.

Cada nvel de maturidade, alm de representar uma etapa evolucionria definida da

melhoria de processos, estabiliza uma parte importante dos processos da organizao.

Nos modelos CMMI com representao em estgios, existem cinco nveis de

maturidade, cada um representando uma camada da base da melhoria de processos,

definidos pelos nmeros de 1 a 5. A Tabela 2.1 apresenta as reas de processo do CMMI

para Desenvolvimento, organizados em nveis de maturidade.

Tabela 2.1 Nveis de Maturidade e reas de Processos do CMMI-Dev.

Nvel rea de Processo

Inovao Organizacional5 (mais alto)

Anlise de Causas e Resoluo de ProblemasDesempenho do Processo Organizacional

4Gerncia Quantitativa de ProjetoAnlise de DecisoGerncia de Riscos

Gerncia Integrada de ProjetoTreinamento OrganizacionalDefinio do Processo OrganizacionalFoco no Processo OrganizacionalValidaoVerificaoIntegrao de ProdutoSoluo Tcnica

3

Desenvolvimento de RequisitosMedio e Anlise

Gerncia de ConfiguraoGarantia da Qualidade de Processo e ProdutoGerncia de Acordo com FornecedoresMonitoramento e Controle de ProjetoPlanejamento de Projeto

2

Gerncia de Requisitos


12/420

2.3.5 MPS.BR

Ver no Guia Geral do MPS.BR as seguintes sees:

Seo 2 (pgs 5 e 6) Seo 3 (pg 7)

Seo 6 (pgs 12 e 13)

Seo 7 (pgs 14 e 15)

Seo 8 (pgs 15, 16 (apenas dois primeiros pargrafos) e 21).


13/420

Gerenciamento de Projetosna Engenharia de Software


14/420

1. Introduo

Ao analisarmos as diferentes referncias relativas a gerenciamento de projetos

de software, verificamos que h diferentes vises sobre como estes projetos devem ser

gerenciados e estas so centradas em alguns modelos. Assim no basta apenas avaliarmos asvises de diferentes autores sobre o assunto, mas tambm os diferentes modelos propostos

pelas principais instituies que propem modelos na rea, o PMI Project Management

Institute, o SEI Software Engineering Institute e ISO International Standards

Organization, alm de um modelo comercial amplamente difundido, o RUP IBM Rational

Unified Process.

Ao nos determos sobre os diferentes modelos, verificamos que o

gerenciamento de projetos constitui-se em uma tarefa de fundamental importncia no

processo de desenvolvimento de software. O gerenciamento de projeto, no entanto, no

visto como uma etapa clssica do processo de desenvolvimento, uma vez que ele acompanha

a todas as etapas tradicionais: Concepo, Anlise, Projeto, Desenvolvimento, Testes e

Manuteno.

Segundo a ABNT, na norma tcnica NBR 10006, Projeto Processo nico,

consistindo de um grupo de atividades coordenadas e controladas com datas para incio e

trmino, empreendido para alcance de um objetivo conforme requisitos especficos, incluindo

limitaes de tempo, custo e recursos. De acordo com o Project Management Institute

(PMBOK, 2004), Projeto Um empreendimento temporrio, planejado, executado e

controlado, com objetivo de criar um produto ou servio nico.

Segundo Pressman (1995), para que um projeto de software seja bem sucedido,

necessrio que alguns parmetros sejam corretamente analisados, como por exemplo, o

escopo do software, os riscos envolvidos, os recursos necessrios, as tarefas a serem

realizadas, os indicadores a serem acompanhados, os esforos e custos aplicados e a

sistemtica a ser seguida. A anlise de todos estes parmetros seria a funo tpica do

gerenciamento de projetos a qual, em geral, se inicia antes do trabalho tcnico e prossegue

medida que a entrega do software vai se concretizando.

De acordo com Capers Jones (apudChang & Christensen, 1999) a maioria

dos esforos em engenharia de software tem se preocupado em construir ferramentas CASE

para auxiliar no projeto, implementao e teste, enquanto os mtodos formais e ferramentas


15/420

usadas para medir, planejar, estimar e monitorar os projetos de software so praticamente

inexistentes.

Para entender e avaliar melhor a origem as falhas em projetos foram realizados

muitos estudos e pesquisas dentre eles o DOD (Departamento de Defesa do Estados Unidos,1994) e os do Standish Group (2001).

O estudo conduzido pelo DOD na dcada de 90 indicou que 75% de todos os

grandes sistemas intensivos de software adaptados falham e que a causa principal o pobre

gerenciamento por parte do desenvolvedor e adquirente e no o desempenho tcnico. O

conjunto de estudos desenvolvidos pelo Standish Group chamado de relatrio CHAOS

(Standish Group, 2001) tem como foco a indstria de software comercial. Nesta pesquisa

foram analisados cerca de 40.000 projetos de aplicaes de Tecnologia da Informao emgrandes empresas norte-americanas.

O primeiro cenrio mostra uma realidade de 1994, onde foram observadas as

seguintes concluses: As empresas dos Estados Unidos gastaram $81 milhes em projetos de

software que foram cancelados em 1994; 31% dos projetos de software estudados foram

cancelados antes de estarem concludos; 53% dos projetos de software excedem mais do que

50% a sua estimativa de custo; e, somente 9% dos projetos, em grandes empresas, foram

entregues no tempo e oramento; para empresas de pequeno e mdio porte, os nmerosmelhoraram em 28% e 16% respectivamente.

O segundo cenrio, resultante do relatrio CHAOS de 2001, mostra a

evoluo do quadro anteriormente mencionado, conforme as concluses abaixo: O percentual

de projetos entregues dentro do tempo, custo e especificaes previstos subiu para 28%; a

percentual de projetos cancelados ou falidos antes de serem completados caiu para 23%; a

extrapolao de oramento caiu para 45% e a de prazo caiu para 63%;

Segundo o Standish Group, as principais causas de falhas nos projetos esto

associadas a dificuldades com os seguintes temas: apoio da alta gerncia, envolvimento do

usurio, experincia do gerente do projeto e definio clara das regras do negcio e escopo do

projeto.

Outra pesquisa, realizada na Universidade Estadual da Pennsylvania EUA

(2000) indica que, de uma maneira geral, os motivos mais relevantes nas falhas dos projetos

de software esto relacionados a problemas na comunicao da equipe do projeto entre si e

desta com a sua gerncia e demais envolvidos..


16/420

De um modo geral essas anlises levaram as mesmas concluses que so:

A imprevisibilidade do desenvolvimento de software;

Baixo percentual de projetos de software so entregues com sucesso dentro das

estimativas de oramento e custo; O sucesso ou falha dos projetos determinado em grande parte pelo gerenciamento

dos projetos;

Processos imaturos resultam em retrabalho.

Estas pesquisas apontam um relacionamento direto entre a utilizao de

tcnicas de gerenciamento de projetos e o progresso observado nas estatsticas apresentadas.

Fica evidente ento que as prticas de gerenciamento de projetos devem acompanhar a

evoluo das demais prticas gerenciais para que se tenha sucesso nos projetos de tecnologia

da informao.

Braga (1996) afirma que no se pode gerenciar o que no se pode medir.

importante estar ciente que as medidas so uma forma para se estimar prazos, custos e avaliar

a produtividade do desenvolvimento de software. Desta forma, torna-se importante integrar a

mtrica de software ao planejamento/gerenciamento de projetos, como forma de viabilizar

informaes consistentes para a tomada de deciso pertinente ao gerenciamento de projeto.

O contexto do gerenciamento de projetos moderno

O gerenciamento de projetos moderno, deve sua primeira grande contribuio

ao engenheiro Henry Laurence Gantt, com o Grfico de Gantt, em 1917. Seu grande

incremento, entretanto, ocorrreu durante a guerra fria, no final dos anos 50. A corrida do

governo americano para desenvolvimento tecnolgico detonada pela crise do Sputnik em

1957, resultou em vrias reaes. Algumas delas foram: a criao da NASA em 1958, oaumento drstico do oramento da Fundao Nacional de Cincias americana, de 34 para 134

milhes de dlares em 1959, e a criao do Programa de Msseis Polaris, com a construo de

um submarino nuclear para diminuir a diferena em relao ao arsenal russo. O Departamento

de Defesa Americano (DOD) tinha urgncia para realizar o programa e as ferramentas de

gerenciamento de projetos tradicionais no eram suficientes para garantir a entrega do projeto.

O DOD ento desenvolveu com a ajuda de Willard Frazar o PERT (Program Evaluation and

Review Technique), um sistema de sequenciamento de atividades que consegue determinar omenor tempo para a concluso de um projeto. A utilizao do PERT se tornou obrigatrio


17/420

para todos os projetos da marinha Americana. A Agncia de Pesquisa Avanada de Projetos

de Defesa do Pentgono iniciou nos anos 60 o projeto de uma rede de computadores chamada

ARPANET, que foi a percussora da Internet de hoje. Nesta mesma poca outros avanos

foram desenvolvidos no gerenciamento de projetos. A DuPont criou o CPM (Critical Path

Method), ou Mtodo do Caminho Crtico, que amplamente usado atualmente, para

identificar quais so as atividades crticas de um projeto que podem atras-lo. O trabalho do

PERT foi depois estendido para a Estrutura Analtica do Projeto (EAP). A fundao do PMI

(Project Management Institute) em 1969 sintomtica da evoluo e da formalizao do tema

nesse perodo. Porm, somente a partir dos 80 a indstria de software passou a incluir o

gerenciamento de projetos formal em suas prticas.

A seguir sero apresentadas as vises de gerenciamento de projetosapresentadas no Corpo de Conhecimento de Gerncia de Projetos (PMBOK , 2004) que a

bblia da profisso de gerncia de projetos, alm das prticas de gerenciamento de projetos

dentro dos modelos RUP Rational Unified Process (Rational Unified Process, 1998), SW-

CMM (Paulk 1993 e SEI-CMMI, 2000) e da Norma ISO/IEC 12207. Este trabalho se prope

a ser uma continuao dos trabalhos de Machado e Burnett (2003), acrescendo principalmente

a viso RUP.

2. PMBOK Guia para o Corpo de Conhecimento em Gerenciamento de

Projetos

Em 1987, o PMI publicou o primeiro conjunto de padres em Gerenciamento

de Projetos, chamado The Project Management Body of Knowledge (PMBOK Guide). Este

guia foi atualizado em 1996 e 2000 e novo PMBOK Terceira Edio foi lanado Novembro

de 2004. O PMBOK um guia onde se descreve a somatria de conhecimento e as melhoresprticas dentro da profisso de gerncia de projetos. um material genrico que serve para

todas as reas de conhecimento, ou seja, tanto para construo de edifcio, processo de

fabricao industrial, como para a produo de software.

Na definio do PMBOK (2004), gerenciamento de projetos a aplicao

de conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto, a fim de

atender os requisitos das partes interessadas. Para Vargas (2000) o gerenciamento de

projetos pode ser aplicado a qualquer situao onde exista um empreendimento que foge aoque fixo e rotineiro na empresa (ad hoc).


18/420

Satisfazer ou exceder as necessidades envolve equilibrar as vrias demandas

concorrentes em relao ao:

Escopo, tempo, custo e qualidade;

Partes interessadas com necessidades e expectativas diferenciadas; e

Requisitos identificados (necessidades) e requisitos no identificados (expectativas).

Para cobrir todas as reas que fazem parte da gerncia de projetos o PMBOK

se subdividiu em processos, conforme a Figura 1.

Figura 1: Processos de Gerenciamento de projetos

Cada processo se refere a um aspecto a ser considerado dentro da gerncia de projetos e, todos

os processos devem estar presentes quando da execuo do projeto para que esse tenha

sucesso. O conjunto de conhecimentos tcnicos de Gerenciamento de projetos necessrios

para o perfeito desempenho da funo percorre nove reas do conhecimento, descritas na

figura 2.

Figura 2: reas de Conhecimento do Gerenciamento de projetos


19/420

Estes conhecimentos so aplicados ao longo dos processos de Gerenciamento de projetos, de

forma matricial. A relao entre as nove reas de conhecimento e os cinco Processos, :

Gerenciamento

deProjetos

IniciaoPlanejamento

Execuo Controle Encerramento

Integrao DesenvolvimentodoPlanos de Projeto

Execuo doPlanos de Projeto

Gerenciamentointegrado demudanas

Gerenciamento de

Escopo

IniciaoPlanejamento dedefinio doEscopoDefinio,Sequnciamento ede Escopo

Verificao econtrole demudanas

Gerenciamento deTempo

Estimativa deAtividades

Desenvolvimentodo Cronograma

Controle deCronograma

Gerenciamento deCusto

Planejamento deRecursosEstimativa deCustos ,Oramento

ControleFinanceiro

Gerenciamento deQualidade

Planejamento daQualidade

Garantia daQualidade

Controle deQualidade

Gerenciamento deRH

PlanejamentoOrganizacionalMontagem deEquipe

Desenvolvimentode Equipe

Gerenciamento de

Comunicao

Planejamento da

Comunicao

Distribuio de

Informao

Relatrios de

Performance

Encerramento

AdministrativoGerenciamento deRiscos

Planejamento,Identificao,Qualificao,Quantificao eRespostas aosRiscos

Acompanhamentoe Controle deRiscos

Gerenciamento deContratao

Planejamento deContratosPlanejamento daContrataoSolicitao

SolicitaoSeleo deFornecedoresAdministrao deContratos

Encerramentodos Contratos

Tabela 1: Relao entre reas de Conhecimento do Gerenciamento e processos do gerenciamento de projetos

A seguir so apresentadas as reas de conhecimento descritas no PMBOK:

Gerenciamento da integrao: O objetivo principal realizar as negociaes

dos conflitos entre objetivos e alternativas do projeto com a finalidade de atingir ou exceder

as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a

execuo do plano do projeto, e o controle geral de mudanas.


20/420

Gerenciamento do Escopo: O objetivo principal definir e controlar o que

deve e o que no deve estar includo no projeto. Consiste da iniciao, planejamento,

definio, verificao e controle de mudanas do escopo.

Gerenciamento do Prazo: O objetivo principal garantir o trmino do projetono tempo certo. Consiste da definio, ordenao e estimativa de durao das atividades, e de

elaborao e controle de prazo.

Gerenciamento do Custo: O objetivo principal garantir que o projeto seja

executado dentro dos oramento aprovado. Consiste de planejamento de recursos ,e

estimativa, oramento e controle de custos.

Gerenciamento da Qualidade do Projeto: O objetivo principal garantir que

o projeto vai satisfazer as exigncias para as quais foi contratado. Consiste de planejamento,

garantia e controle de qualidade.

Gerenciamento dos Recursos Humanos: O objetivo principal garantir o

melhor aproveitamento das pessoas envolvidas no projeto. Consiste de planejamento

organizacional, alocao de pessoal e desenvolvimento de equipe.

Gerenciamento da Comunicao: O objetivo principal garantir a gerao

adequada e apropriada, coleta, disseminao, armazenamento e disposio final das

informaes do projeto. Consiste do planejamento da comunicao, distribuio da

informao, relatrio de acompanhamento e encerramento administrativo.

Gerenciamento do Risco: O objetivo principal maximizar os resultados de

ocorrncias positivas e minimizar as conseqncias de ocorrncias negativas. Consiste de

identificao, quantificao, tratamento e controle de tratamento de riscos.

Gerenciamento das Contrataes e Suprimentos (Aquisies): O objetivo

principal obter bens e servios externos organizao executora. Consiste do planejamentode aquisio, planejamento de solicitao, solicitao de propostas, seleo de fornecedores, e

administrao e encerramento de contratos.


21/420

3. CMM Capability Maturity Model e CMMI

Em 1987, o Software Engineering Institute - SEI sob a coordenao de Watts

Humphrey gerou a primeira verso do que veio a se chamar de modelo CMM. Segundo

Humphey, 1997, o modelo era composto pelos documentos de maturidade de processo e o

questionrio de maturidade. Em 1991, o SEI evoluiu a estrutura de maturidade de processo

para o chamado Capability Maturity Model for Software - SW-CMM.

O SW-CMM baseado em cinco estgios de maturidade. Estes estgios so

caracterizados pela existncia (definio, documentao e execuo) de determinados

processos dentro da organizao que so chamados de reas-chave de Processos. A

qualidade da execuo do processo, o nvel de acompanhamento desta execuo, a adequao

dos processos ao projeto so alguns dos fatores medidos para determinar o nvel de

maturidade da organizao. As reas-chave de Processos podem ser classificadas de

acordo com a categoria do processo (gerncia, organizao e engenharia) e o seu nvel de

maturidade conforme descrito na Tabela 2 0.

Como decorrncia da evoluo do modelo SW-CMM, em 2000 foi lanado um

novo produto: o CMMI. O CMMI agrega, alm da representao por estgios, a

representao contnua. Ou seja, na representao contnua, existem as reas-chave de

Processos, mas essas no esto distribudas em nveis, elas que contm graus de

capacidade. Esses processos, assim como, o objetivo do alcance da capacidade nos processos,

devem ser selecionados pela organizao e evoludos de acordo com os objetivos

organizacionais.

A representao contnua representada por nveis de capacidade, perfis de

capacidade, estgio alvo, e estgio equivalente (relao dessa representao em relao a

representao por estgio) como princpios de organizao dos componentes do modelo.

Nesse modelo existem seis nveis de capacidade designados pelos nmero de 0 at 5 que

correspondem a nvel 0 - Incompleto, 1 - Executado, 2 - Gerenciado, 3- Definido, 4

Gerenciado Quantitativamente e 5 - Otimizado. Os componentes do modelo CMMI podem

ser agrupados em 3 categorias:

Objetivos especficos e genricos so componentes do modelo requeridos e so

considerados essenciais para que a organizao alcance a melhoria de processo;

Prticas especficas e genricas so componentes do modelo esperados e podem


22/420

ajudar a alcanar os objetivos especficos e genricos; e

Sub-prticas, produtos de trabalho tpico, extenso da disciplinas, elaborao de

prticas genricas, ttulos de prticas e objetivos ajudam a entender o modelo.

Nvel dematuridade

GerencialPlanejamento de projeto de

software

OrganizacionalReviso e controle pela gerncia

snior

EngenhariaEspecificao, design,

codificao, controle dequalidade

2 Superviso eacompanhamento de projetos

Garantia de qualidade desoftware

Gerncia de configurao de

software Gerncia de contrato desoftware

Gerncia de requisitos Planejamento do projeto de

software3 Coordenao entre grupos

Gerncia de softwareIntegrada

Definio do processo daorganizao

Foco no processo daorganizao

Programa de treinamento

Engenharia deproduto de software

Reviso porparceiros

4 Gerncia quantitativa deprocessos

Gerncia dequalidade de

software5 Gerncia da evoluo dosprocessos

Gerncia da evoluotecnolgica

Preveno dedefeitos

Tabela 2- reas-chave de processos do SW-CMM de acordo com o nvel de maturidade e a categoria deprocessos

O modelo tambm subdividido em reas de processos e tem quatro categorias

que so: Processos de Gerncia de Processo, Processos de Gerncia de Projeto, Processos deEngenharia e Processos de Apoio. A Tabela 3 mostra as reas-chave de processos dentro das

categorias do CMMI. Os grupos de rea de processo bsicos so os que esto em nvel 1.

Essas prticas so consideradas essenciais para alcanar o propsito da rea de processo. As

prticas avanadas so as que esto presentes nos nveis maiores do que 1.


23/420

Categorias de processo Grupo de reade processo

Processos

Processos de Gerncia de Processo Bsico Foco no processo organizacional Definio do processo organizacional Treinamento organizacional

Avanado Execuo do processo organizacional Entrega e inovao organizacionalProcessos de Gerncia de Projeto Bsico Planejamento de projeto

Monitoramento e controle de projeto Gerncia de "contratos" com fornecedores

Avanado Gerncia de projeto integrada Gerncia de risco Gerncia de projeto quantitativa

Engenharia Desenvolvimento de requisitos Gerncia de requisitos Soluo tcnica Integrao de produto Verificao Validao

Processos de apoio Bsica Gerncia de configurao Garantia de qualidade de produto e processo Anlise e medio

Avanado Resoluo e anlise de deciso Resoluo e anlise de causa

Tabela 3 - Distribuio das reas-chave de processos no CMMI

4. NBR ISO/IEC 12207 Processos de Ciclo de Vida de Software

A Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software foicriado em 1995 com o objetivo de fornecer uma estrutura comum para que o adquirente,

fornecedor, desenvolvedor, mantenedor, operador, gerentes e tcnicos envolvidos com o

desenvolvimento de software utilizem uma linguagem comum. Esta linguagem comum

estabelecida na forma de processos bem definidos. Esses processos so classificados em trs

tipos: fundamentais, de apoio e organizacionais representado na Figura 3. Todos esses

processos, executados durante o projeto de software, conduzem a qualidade tanto do produto

quanto do processo.


24/420

Devido prpria evoluo da rea de engenharia de software e da necessidade

sentida por vrios usurios da Norma, foi disponibilizado em 2001 um anexo que atualizou a

Norma incluindo e expandido processos. Um dos processos que foi expandido e, o foco

deste artigo, o de Gerncia que ganhou alguns processos (veja Figura 4) e passou a ter os

seguintes objetivos:

Gerncia organizacional: Tem como objetivo estabelecer os objetivos de

negcio da organizao e desenvolver o processo, produto, e recursos os quais quando usados

por um projeto na organizao ajudam a organizao a encontrar os seus objetivos de negcio.

Gerncia de projetos: Tem como objetivo identificar, estabelecer, coordenar,

e monitorar as atividades, tarefas e recursos necessrios de um projeto para produzir um

produto e/ou servio, dentro do contexto dos requisitos e restries do projeto.

Gerncia da qualidade: Tem como objetivo satisfazer o cliente atravs do

alcance dos seus requisitos.

Figura 3 - Processos da Norma NBR ISO/IEC 12207 - Processos deCiclo de Vida


25/420

Gerncia de risco: Tem como objetivo identificar, gerenciar e minimizar os

riscos de forma contnua.

Alinhamento organizacional: Tem como objetivo assegurar que os indivduos

na organizao compartilhem uma viso e cultura comum e o entendimento dos objetivos donegcio para que esses ajam conjunta e efetivamente.

Medio: Tem como objetivo coletar e analisar dados relacionados ao

desenvolvimento dos produtos e implementao dos processos dentro da unidade

organizacional, suportando o gerenciamento efetivo dos processo e demonstrando

objetivamente a qualidade dos produtos.

Gerncia do conhecimento: Tem como objetivo assegurar que o

conhecimento individual, informaes e perfis sejam coletados, compartilhados, reusados e

melhorados atravs da organizao.

5. RUP Rational Unified Model

Os processos do IBM Rational Unified Process ou RUP oferecem uma

abordagem prescritiva nas melhores prticas de engenharia de software. Eles descrevem que

faz o que, quando e como no desenvolvimento e instalao de software. Tem como

caractersticas ser dirigido a casos de uso, centrado na arquitetura, dirigido a risco e iterativo.

Os requisitos funcionais, descritos na forma de casos de uso direcionam a arquitetura do

cdigo executvel. Alm disso, o processo foca no esforo do time como elemento estrutural

e comportamental importante . A mitigao dos elementos de risco mais importantes feita

nas primeiras iteraes do ciclo de vida. E finalmente, RUP particiona o ciclo de

desenvolvimento de software em iteraes que produzem verses incrementais da aplicao.

Figura 4 - Processos de gerncia da NBRISO/IEC 12207 expandido atravs do seu anexo

(verso 2001)


26/420

As disciplinas do RUP esto relacionadas s melhores prticas de

desenvolvimento de software, mas tambm representam os papeis dos membros ou subgrupos

no time de desenvolvimento de software. Estas disciplinas so:

1. Modelagem de negcio

2. Requisitos

3. Anlise e Projeto

4. Implementao

5. Teste

6. Instalao

7. Gerenciamento de projeto

8. Ambiente

9. Configurao e gerenciamento de mudanas

Das disciplinas do RUP Rational Unified Model, estamos interessados na

relativa a gerenciamento de projetos (RUP PM). O RUP (Kruchten, 2000, citando RUP)

define gerenciamento de projetos de software como a arte de equilibrar objetivos que

competem entre si, gerenciando risco e ultrapassando restries de modo a entregar com

sucesso um produto que atinge as necessidades dos clientes (aqueles que requerem que o

software seja desenvolvido) e dos usurios.

Figura 5: Disciplinas do RUP (fonte: IBM RUP)


27/420

A disciplina RUP PM fornece:

1. Um modelo para gerenciar projetos intensivos de software

2. Regras prticas para planejamento, contratao e execuo e monitoramento de

projetos

3. Um modelo para gerenciar risco

Esta disciplina foca principalmente nos aspectos mais importantes de um

processo de desenvolvimento iterativo:

1. Gerenciamento de riscos

2. Planejamento de um projeto iterativo, atravs do ciclo de vida e atravs de uma

interao particular

3. Monitorao do progresso de um projeto iterativo, mtricasH vrias reas do gerenciamento de projetos que saem do escopo da disciplina

RUP PM, porm so cobertas por outras prticas, como o PMBOK:

Gerenciar pessoas: Contratao, treinamento, coaching (cobertas pela rea de RH

do PMBOK);

Gerenciamento do custo: Definio, alocao e assim por diante (est ligado a rea

de gerenciamento do custo do PMBOK); Gerenciamento de contratos: fornecedores e clientes (est ligado a rea de

gerenciamento das aquisies do PMBOK).

Dentre as principais caractersticas do RUP, no que se refere a gerenciamento

de projetos, podemos citar:

Especfico para a rea de gerenciamento de software;

Contm prticas de gerenciamento de projetos e de desenvolvimento de software;

Cobre somente alguns aspectos do gerenciamento de projetos;

prescritiva (e no descritiva);

As fases e iteraes so especficas para desenvolvimento de software.


28/420

6. Comparao PMBOK, CMMI, RUP e NBR ISO/IEC 12207

A comparao ser feita dos modelos CMMI, RUP e NBR ISO/IEC em

relao as prticas de gerenciamento de projetos propostas pelo PMBOK, de modo a

analisarmos qual o grau de atendimento da engenharia de software em relao as prticas

executadas e consagradas como melhores prticas pelos profissionais em gerenciamento de

projetos.

PMBOK CMMI RUP NBR ISO/IEC 12207Integrao Gerncia de projetointegrada

Gerenciamento deProjetosRequerimentosInstalaoConfigurao egerenciamento demudanas

Gerncia organizacional

Escopo Planejamento deacompanhamentoGerncia de requisitos

Gerenciamento de projetoRequisitosConfigurao egerenciamento demudanas

Gerncia de projetoGerncia de Requisitos

Tempo Acompanhamento econtrole.Mas, no endereaespecificamente essaquesto.

Gerenciamento de projeto Gerncia de projeto.Mas, no endereaespecificamente essa questo.

Custo Acompanhamento econtrole.Mas, no endereaespecificamente essaquesto.

Sem mapeamento Gerncia de projeto.Mas, no endereaespecificamente essa questo.

Aquisio Gerncia de Contratos comfornecedores

Sem mapeamento No tem processos que trateespecificamente essa questo.Ela coberta na norma pela

Aquisio e Fornecimento e gerenciada da mesma formaque um projeto interno organizao.

Recursos Humanos A prpria concepo domodelo diz que devem seter habilidades paraexecutar, mas nomenciona explicitamente anecessidade degerenciamento de recursoshumanos atravs dosprojetos da organizao.

Sem mapeamentocompleto, embora defina aorganizao do projeto

Recursos HumanosGerncia do Conhecimento

Comunicao Gerncia de Configuraocobre parcialmente esse

Gerenciamento de projeto Gerncia de Configuraocobre parcialmente esse


29/420

processo.A prpria concepo domodelo diz que osprocessos devem sercomunicados, mas nomenciona explicitamente a

necessidade decomunicao dos produtosdo projetos para todos osenvolvidos.

processo.Mas, no mencionaexplicitamente esse processo

Risco Gerncia de Risco Gerenciamento de projeto Gerncia de RiscoGarantia deQualidade

Garantia de qualidade deproduto e processo

Gerenciamento de projetogerenciamento demudanas

Gerncia da Qualidade

Tabela 3 Comparativo PMBOK, CMM, RUP e NBR ISO/IEC 12207 em relao a

gerenciamento de projetos

7. Concluso

O PMBOK, por ser mais genrico, cobre processos no cobertos pelos modelos

RUP, NBR ISO/IEC 12207 e CMM. Estes tm includo prticas gerenciais nos processos de

software, porm, apesar de diversas pesquisas evidenciarem que o problema gerencial e no

tcnico isso no est sendo representado devidamente nos modelos.

Para que a evoluo dos modelos possa reduzir a quantidade de falhas no

desenvolvimento de software importante o investimento em mtodos de gerenciamento mais amplos

e na profissionalizao das organizaes.


30/420

Engenharia de Software, 2006 Jair C Leite

Planejamento e Gerenciamento deProjeto de Software

Definio das atividades

Estimativas e Mtricas

Dimensionamento do software

Clculo do esforo

Anlise dos Riscos

Definio Equipe Alocao de tarefas

Cronograma

Oramento


O processo de desenvolvimento

prazos

custos

ferramentas

atividades

equipe

tempo

Situaoatual

Situaofutura

Software

modelos, prottipose documentos


31/420


Planejamento e Gerenciamento

Planejamento Previso de atividades, recursos, custos e prazos

Estimativas do produto e processo

Gerenciamento

Controle de acordo com o que foi planejado

Verificao da qualidade do produto e do processo

prazos

custos

ferramentas

atividades

pessoal

tempo

Software


previso controle

Planejamento

Gerenciamento


Caractersticas do Planejamento e

Gerenciamento de Software

Dificuldades O software intangvel

No h um processo de software padro

A ES no possui a mesma tradio e status deoutras engenharias civil, mecnica e eltrica.

Grandes projetos de software so freqentementenicos.

Aspectos comuns Tcnicas de planejamento e gerenciamento so

amplamente aplicadas em diversas reas

Planejamento e gerenciamento so atividadescomuns em outras engenharias


32/420


Planejamento

ferramentas

atividades

tempo

Situaoatual

Situaofutura

Software


modelo deprocesso

Requisitos

planejamento

Cronograma: prazos

Oramento: custos

Equipe: pessoal


Principais atividades

Elaborao de propostas

Planejamento e cronograma de projeto

Oramento do projeto

Monitoramento e revises

Seleo e avaliao de pessoal

Elaborao de relatrios e apresentaes


33/420


Planejamento

Totalizao dos custosElaborar oramento

Estimativas de produtividade,restries de prazos e custos,disponibilidade de pessoal eferramentas

Elaborar cronograma

Estimativas do produto e restriesde prazos e custosAlocao de pessoa-tarefa(atividade)

De acordo com atividades,

capacidade do pessoal , prazos ecustos

Definir equipe

De acordo com atividades e custosEscolher ferramentas

Modelo de processoDeterminar atividades

Como?O que?


Gerenciamento e Avaliao

Gerenciamento do Processo

Os prazos esto sendo cumpridos?

Os custos esto dentro do oramento?

A equipe obedece alocao de tarefas?

As ferramentas esto adequadas?

As atividades esto sendo realizadas com planejadas?

Avaliao do produto

Os modelos, prottipos e documentos esto sendoproduzidos com qualidade?

O software produzido tem qualidade?


34/420


Qualidades do processo e produto

prazos

custos

atividades

equipe

tempo

Software


Mtricasdo produto

Mtricasdo processo

Qualidade do processo e do produtoGerenciamento

Avaliao


Estrutura de um plano de projeto

Introduo

Organizao de projeto

Anlise de riscos

Requisitos necessrios de hardware e

software Estrutura analtica de trabalho

Cronograma de projeto

Mecanismos de monitoramento e elaborao

de relatrios

[Ian Sommerville]


35/420


Tipos de planos

Plano de projeto de software Descreve as atividades, equipe, oramento, cronograma,

recursos, etc.

Plano de qualidade Descreve os procedimentos de testes de qualidade que

sero utilizados

Plano de validao Descreve a abordagem, os recursos e o mtodo utilizados

pa validao

Plano de manuteno Prev requisitos, custos e esforo necessrio para a

manuteno

Plano de desenvolvimento da equipe Descreve como as habilidades e a experincia sero

desenvolvidas


Modelo de Plano de Desenvolvimento

de Software

Introduo

Organizao do Projeto

Processo Gerencial

Processo Tcnico

Cronograma e Oramento

Padro IEEEMtodo Prxis


36/420

1

CI nCI n--UFPEUFPE 112001,2001, JaelsonJaelson Castro e Alexandre VasconcelosCastro e Alexandre Vasconcelos

Engenharia de SoftwareEngenharia de Software

Requisitos de Software


Requisitos de softwareRequisitos de software

n Descrio e especificao de um sistema


37/420


38/420

3


Exemplos de requisitos funcionaisExemplos de requisitos funcionais

n O usurio deve ser capaz de pesquisar tanto todo oconjunto inicial do banco de dados ou selecionar umsubconjunto dele.

n O sistema deve fornecer visualizadores (viewers)apropriados para ler documentos.

n Para cada pedido deve ser alocado um identificador nico

(ORDER_ID).


Impreciso dos requisitosImpreciso dos requisitos

n Problemas surgem quando os requisitos no sodeclarados precisamente

n Requisitos ambguos podem ser interpretados de formadiferente por desenvolvedores e usurios

n Considere o termo visualizadores apropriadosu Inteno do usurio - visualizadores de propsito especial para

cada tipo de documento diferenteu Interpretao do desenvolvedor - um visualizador textual que

mostra o contedo do documento


39/420

4


Requisitos noRequisitos no--funcionaisfuncionais

n Requisitos de produtou Requisitos que especificam que o produto entregue tem que se

comportar de um modo particular. Por exemplo, velocidade deexecuo, confiabilidade, etc.

n Requisitos organizacionaisu Requisitos que so uma conseqncia de polticas e

procedimentos organizacionais. Por exemplo, padres deprocessos usados, requisitos de implementao, etc.

n Requisitos externosu Requisitos que surgem de fatores que so externos ao sistema e

ao seu processo de desenvolvimento. Por exemplo, exigncias deinteroperabilidade, requisitos legislativos, etc.


Tipos de requisitos no funcionaisTipos de requisitos no funcionais

Performancerequirements

Spacerequ irements

Usabilityrequirements

Efficiencyrequir ements

Reliabilityrequir ements

Portabilit yrequirements

Interoperabil ityrequirements

Ethicalrequirements

Legis lativerequirements

Impl ementat ionrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Pro ductrequir ements

Org anizatio nalrequirements

Externalrequirements

Non-functio nalrequirements


40/420

5


Interao entre requisitosInterao entre requisitos

n Conflitos entre requisitos no funcionais diferentes socomuns em sistemas complexos

n Exemplo: em um sistema de uma nave espacialu Para minimizar o peso, a quantidade de chips no sistema deve ser

minimizadau Para minimizar o consumo de energia, chips de baixo consumo

devem ser utilizados

u Contudo, o uso de chips de baixo consumo significa que maischips vo ter que ser usados. Qual o requisito mais crtico


Problemas com especificao em LNProblemas com especificao em LN

n Falta de clarezau Preciso difcil sem tornar o documento difcil para leitura

n Confuso de requisitosu Requisitos funcionais e no funcionais tendem a ser misturados

n Fuso de requisitosu Vrios requisitos diferentes podem ser expressos juntos


41/420

6


Problemas com especificao em LNProblemas com especificao em LN

n Ambigidadeu Os leitores e escritores do requisito devem interpretar as mesmas

palavras da mesma maneira. LN naturalmente ambgua o que torna oseu uso muito difcil.

n Flexibilidadeu A mesma coisa pode ser dita de vrias formas diferentes na

especificao

n

Falta de modularizaou Estruturas de LN so inadequadas para estruturar requisitos do s isteman Concluso: Necessidade de uma notao mais

apropriada


O documento de requisitosO documento de requisitos

n O documento de requisitos a documentao oficial doque requerido dos desenvolvedores do sistema

n Deve incluir tanto a definio como a especificao dosrequisitos

n Ele NO um documento de projeto. Na medida dopossvel, ele deve definir O QUE o sistema deve fazer emvez do COMO ele deve fazer


42/420

7


Usurios de um documento de requisitosUsurios de um documento de requisitos

Use t he req uirements todevelop validation tes ts forthe s ystem

Use the requirementsdocument to plan a bid for

the system and to plan thesystem deve lo pment process

Use the requirements tounderstan d what sys tem is tobe developed

System tes tengineers

Managers

System engineers

Specif y the requirements andread them to che ck that t hey

meet their needs. The yspecify ch anges to th erequiremen ts

System customers

Use the requirements to help

understand the system andthe relati onship s betw een itsparts

Systemmaintenance

engineers


ElicitaoElicitao de Requisitosde Requisitos

n ELICITAR: descobrir, tornar explcito, obter o mximode informaes para o conhecimento do objeto emquesto

n Cabe elicitao a tarefa de identificar os fatosrelacionados aos requisitos do Sistema, de forma aprover o mais correto e mais completo entendimentodo que demandado daquele software


43/420

8


ElicitaoElicitao de Requisitos: Dificuldadesde Requisitos: Dificuldades

n Usurios podem no ter uma idia precisa do sistema por elesrequerido;

n Usurios tm dificuldades para descrever seu conhecimentosobre o domnio do problema;

n Usurios e Analistas tm diferentes pontos de vista do problema(por terem diferentes formaes);

n Usurios podem antipatizar-se com o novo sistema e se negarema participar da elicitao (ou mesmo fornecer informaes

errneas).


Componentes daComponentes da elicitaoelicitao de requisitosde requisitos

Application

domain

Stakeholderneeds andconstraints

Problem to be

solved

Businesscontext


44/420


45/420

10


O processo daO processo da elicitaoelicitao de requisitosde requisitos

Businessgoals

System

constraints

Problem to besolved

Establish objectives Understand background

Organisationalstructure

Applicationdomain

Existing

systems

Stakeholderidentification

Goalprioritisation

Domain

knowledgefiltering

Organise knowledge

Stakeholderrequirements

Collect requirements

Domainrequirements

Organisational

requirements


Estgios daEstgios da ElicitaoElicitao

n Definio dos objetivosu Os objetivos organizacionais devem ser estabelecidos incluindo

objetivos gerais do negcio, um descrio geral do problema a serresolvido, porque o sistema necessrio, e as limitaes do sis tema.

n Aquisio de conhecimento do backgroundu Informao de background do sistema: inclui informao acerca da

organizao onde o sistema ser instalado, o domnio de aplicao dosistema, e informao acerca de outros sistemas existentes

n Organizao do conhecimentou A grande quantidade de conhecimento que foi coletada nos estgios

anteriores deve ser organizada e colocada em ordem.

n Coleta dos requisitos dos stakeholdersu Os stakeholders do sistema so consultados para descoberta de seus

requisitos.


46/420

11


Anlise e negociao de requisitosAnlise e negociao de requisitos

Necessitychecking

Consistency andcompleteness

checking

Feasibilitychecking

Unnecessaryrequirements

Confli cting andincomplete

requirements

Infeasiblerequirements

Requirementsdiscussion

Requirementsprioritisation

Requirementsagreement

Requirements analysis

Requ irements negotiation


Anlise dos requisitosAnlise dos requisitos

n Verificao da necessidadeu A necessidade os requisitos analisada. Em alguns casos, alguns

requisitos propostos podem no contribuir para os objetivos de negcioda organizao ou para o problema especfico tratado pelo sistem a.

n Verificao de consistncia e completudeu Os requisitos so verificados entre si para determinar consistncia e

completude. Consistncia significa que nenhum requisito deve sercontraditr io; completude significa que nenhum servio (ou limitao)que seja necessrio foi esquecido.

n Verificao de viabilidadeu Os requisitos so verificados para garantir que so viveis dentro do

oramento e tempo disponvel para o desenvolvimento do sistema.


47/420

12


Negociao dos requisitosNegociao dos requisitos

n Discuo dos requisitosu Os requisitos que foram identificados como problemticos so

discutidos e os stakeholders envolvidos apresentam seus pontosde vista acerca dos requisitos.

n Priorizao dos requisitosu Os requisitos disputados so priorizados para identificar requisitos

crticos e ajudar o processo de tomada de deciso.

n Concordncia dos requisitosu Solues para os problemas dos requisitos so identificadas e um

conjunto de requisitos so acordados. Geralmente isto envolvemudanas em alguns dos requisitos.


Tcnicas deTcnicas de ElicitaoElicitao

n Tcnicas especiais que podem ser usadas para coletarconhecimento sobre os requisitos dos usurios

n Este conhecimento deve ser estruturadou Particionamento - agregando conhecimentos relacionadosu Abstrao - reconhecendo generalidadesu Projeo - organizando de acordo com uma perspectiva

n Problemas da elicitaou No existir muito tempo para a elicitaou Preparao inadequada dos engenheirosu Stakeholders no estarem convencidos da necessidade de um

novo sistema


48/420

13


Algumas tcnicas deAlgumas tcnicas de elicitaoelicitao

n Entrevistasn Leitura de documentosn Questionriosn Cenriosn Observaes e anlise sociais (etnografia)n Reuso de requisitosn Prototipagem


n O profissional de ER deve selecionar as tcnicas a seremutilizadas e estabelecer de que maneira elas serointegradas

n importante utilizar uma tcnica de modelagem de apoio

para que os fatos elicitados fiquem corretamenterepresentados para futuro tratamenton A escolha das tcnicas e seu esquema de integrao

depender do problema e da equipe participanten O ponto importante ter conhecimento sobre estas

tcnicas e identificar onde uma tcnica superior a outra

ElicitaoElicitao de Requisitosde Requisitos


49/420

14


Tcnicas deTcnicas de ElicitaoElicitao

n Sempre perguntar: o que? Por que(m)? Como?n Pergunte o bvion Organize as respostas: durante versusdepoisn Observen Estudar o que? Por que? Onde comearn Seja humilde, procure aprender!


CenriosCenrios

n Cenrios so estrias que explicam como um sistema poder serusado. Eles devem incluir:u uma descrio do estado do sistema antes de comear o cenriou o fluxo normal de eventos do cenriou excees ao fluxo normal de eventos

u informaes sobre atividades concorrentesu uma descrio do estado do sistema ao final do cenrio

n Cenrios so exemplos de sesses de interao que descrevemcomo o usurio interage com o sistema

n A descoberta de cenrios expe interaes possveis do sistema erevela as facilidades que o sistema pode precisar


50/420

15


Cenrios e Projeto OOCenrios e Projeto OO

n Cenrios so partes inerentes de alguns mtodos dedesenvolvimento orientados a objeto

n O termo caso de uso ou use-case (um caso especficodo uso do sistema) usado s vezes para se referir a umcenrio


Cenrio de um sistema de livraria virtualCenrio de um sistema de livraria virtual

n Entre no sisteman Escolha o comando pedido de documentosn Entre um nmero de referncia do documento pedidon Selecione um ponto de entregan Saia do sistema


51/420


52/420


53/420


54/420

19


Anlise de requisitosAnlise de requisitos

n O objetivo da anlise descobrir problemas,incompletude e inconsistncia nos requisitos elicitados.Eles normalmente so retornados aos stakeholders pararesolv-los, atravs de um processo de negociao

n A anlise intercalada com elicitao, pois problemasso descobertos quando os requisitos so elicitados

n

Uma lista de verificao de problemas poder ser usadapara ajudar a anlise. Cada requisito poder ser avaliadocontra esta lista


Lista de verificao da anliseLista de verificao da anlise

n Projeto prematurou Os requisitos incluem informao prematura de projeto ou

implementao?

n Requisitos combinadosu A descrio do requisito descreve um requisito nico ou este pode ser

descrito em vrios requisitos diferentes?

n Requisitos desnecessriosu O requisito realmente necessrio, ou ser que uma mera adio

cosmtica ao sistema?

n Uso de hardware no padronizadou Os requisitos implicam no uso de uma plataforma de hardware no

padronizada? Para tomar esta deciso, voc precisa conhecer osrequisitos de plataforma do computador.


55/420


56/420

21


Matrizes de InteraoMatrizes de Interao

Requirement R1 R2 R 3 R4 R5 R6

R1 0 0 1 000 0 1 1

R2 0 0 0 0 0 0

R3 1000 0 0 1000 0 1000

R4 0 0 1 000 0 1 1

R5 1 0 0 1 0 0

R6 1 0 1 000 1 0 0


Negociao de requisitosNegociao de requisitos

n Problemas nos requisitos so inevitveis quando umsistema possui muitos stakeholders. Conflitos no sofalhas, mas refletem necessidades e prioridadesdiferentes entre as partes interessadas

n

A negociao de requisitos o processo de discussodos conflitos de requisitos e a busca de um compromissono qual todas as partes interessadas concordem

n No planejamento do processo de engenharia derequisitos, importante deixar bastante tempo paranegociao. Alcanar um compromisso aceitvel podetomar um tempo considervel


57/420

22


Encontros de negociaoEncontros de negociao

n Um estgio de informao onde a natureza dosproblemas associados com os requisitos so explicados.

n Um estgio de discusso onde as partes interessadasdiscutem como o problema poder ser resolvido.u Todas as partes interessadas no requisito devem ter a

oportunidade de comentar. Neste estgio so atribudasprioridades aos requisitos.

n Estgio de resoluo onde as aes que dizem respeitoao requisito so concordadas.u Estas aes podem ser: deletar o requisito, sugerir modificaes

ao requisito ou elicitar mais informaes sobre o requisito.


Pontos principaisPontos principais

n Requisitos definem o que sistema deve fazer e asrestries sobre suas operaes e implementao

n Requisitos funcionais definem os servios que os sistemadeve fornecer

n Requisitos no funcionais restringem o sistema que estsendo desenvolvido ou o processo de desenvolvimento

n O documento de requisitos a especificao para osclientes, engenheiros e gerentes


58/420


59/4201

Prof. Cristiano R R [email protected]

Engenharia de Software

Tema da Aula

Projeto de Software

Engenharia deSoftware

Projeto (Design) de Software

Projetar Software o processo de aplicar vrias tcnicas e

princpios com o propsito de se definir um dispositivo,

processo ou sistema, com detalhes suficientes para permitir

sua realizao fsica. (Taylor-59).

O Projeto de software o ncleo tcnico da Engenharia de

Software. a nica maneira de se traduzir "com preciso", os

requisitos do usurio para um produto ou sistema acabado.

Meta:

Traduzir requisitos numa representao de software.


60/4202


Projeto (Design) de Software

Princpios

Desenvolver um projeto de software um processo quecombina:

Instituio de critrios baseados na experincia adquirida naconstruo de entidades similares.

Um conjunto de princpios e/ou heursticas que guiam odesenvolvimento do modelo.

Um conjunto de critrios que facilitam a verificao da

qualidade. Um processo de iterao que conduz a uma representao

do projeto final


Projeto (Design) de SoftwareDiferentes Vises

' Projeto Procedimental: descrio da funcionalidade dosoftware (algoritmos).

' Projeto de Dados: definio das estruturas de dados.

' Projeto das Interfaces: Layouts e mecanismos deinterao homem-mquina (se necessrio).

' Projeto Arquitetural: associao entre os principaiselementos estruturais do software (rvore dos mdulos,mensagens entre objetos, Nivelamento em Camadas).


61/4203

Engenharia deSoftware Projeto (Design) de SoftwareTransio Anlise -> Projeto

Dados tratados pelo sistema

Como os dados so tratados

Como o sistema reage a eventos


Projeto (Design) de SoftwareModelo Clssico (Cascata)

Projeto de Software:


62/4204

Engenharia deSoftware Projeto (Design) de SoftwareModelo Clssico (Cascata)

Projeto de Software:


Processo (Design) de Software

'Projeto Preliminar

Transformao dos requisitos em modelos de

arquitetura, dados e procedimentos.

'Projeto Detalhado

Refinamento da representao da arquitetura, dosdados e dos procedimentos, gerando estruturas maisrefinadas (detalhadas).


63/4205

Engenharia deSoftware Qualidade do Projeto de Software

'A Qualidade do Projeto avaliada atravs derevises tcnicas formais (walkthrougs deprojetos), usando-se os seguintes critrios dereferncia:

1. Organizao hierrquica: atravs do uso inteligentede controle entre os elementos do software;

2. Modularidade: particionamento lgico em elementosque executam funes e subfunes especficas;


Qualidade do Projeto de Software

' A Qualidade do Projeto avaliada ...

3. Representaes distintas para dados e procedimentos:mesmo que sejam posteriormente agrupados em objetos;

4. Deve levar a Mdulos ou Classes de objetos queapresentam caractersticas funcionais independentes;

5. Deve levar interfaces que reduzam a complexidade deconexes entre os mdulos e com o ambiente externo; e


64/4206

Engenharia deSoftware Fundamentos do Projeto de Software

Fundamentos:

1. Abstrao: Concentrar-se no problema com um certo nvelde generalizao.Abstrao procedimental

Abstrao de dados

2. Refinamento sucessivo: um processo de elaboraoque parte de uma declarao de funo, que serelaborada atravs de sucessivos refinamentos, cada umincorporando mais detalhes.

Abstrao do Projetoe de seu ambiente


Fundamentos do Projeto de Software

3. Modularidade:


65/4207

Engenharia deSoftware Projeto de Software


Fundamentos do Projeto de Software

4. Arquitetura de Software: Estrutura hierrquica de componentes procedimentais e Estrutura de dados

5. Hierarquia de Controle:Representa a organizao de componentes de um programa e

a hierarquia de controle entre seus mdulos.


66/4208


Projeto Procedimental de SoftwareDiagrama Estrutura - Hierarquia dos Mdulos


Projeto Procedimental de SoftwareDiagrama Estrutura - Hierarquia dos Mdulos

Deciso: o mdulo

abaixo pode ou no

receber o controle

(deciso).

Chamada repetida

(iterativa)

Passagem de dados

entre mdulos

Passagem de controle

entre mdulos


67/4209

Engenharia deSoftware Projeto de Dados de Software

Projeto de Dados


Projeto de Dados de Software

Representao do relacionamento lgico entreelementos de dados individuais. Determina aorganizao, mtodos de acesso, associaes e

alternativas de processamento.

'Parte dos dados levantados e representados na fasede anlise: Dicionrio de Dados Fluxo, Contedo e Estrutura


68/42010

Engenharia deSoftware Projeto de Dados de Software

Atividades do Projeto de Dados:

'Selecionar representaes de dados;

'Estudar e escolher estruturas de dados quepermitam a implementao mais adequada;

'Caracterizar a Abrangncia (escopo) dos Dados Local (componente), Partes do software ou Global

Caracterizas a Persistncia dos Dados Persistentes (B.Dados) No Persistentes (Dados em memria, estruturas de

manipulao/intermediria)..



Estruturas/Elementos de DadosComuns:

'Itens Elementar (Tipos Primitivos)

'Listas Lineares

Gerais Pilhas Filas

'Lista no lineares rvores Grafo


69/42011



Dados Persistentes

Modelo de Entidade-Relacionamento (MER)

Entidades Relacionamentos

Atributos


Projeto de Software

Projeto Arquitetural de Software


70/42012

Engenharia deSoftware Projeto Arquitetural de Software

Visa modelar a estrutura completa do software e as maneirasfornecidas para manter a integridade conceitual de umsistema:

Arquiteturas Tradicionais: Centralizada Parcialmente Distribuda Cliente-Servidor (2 Camadas)

Cliente-Servidor (3 Camadas) Distribuda (Multi-Camadas)


Projeto Arquitetural de SoftwareArquitetura Centralizada

' Caractersticas: Processamento centralizado no Mainframe; Terminais Burros (sem processamento); Redes Corporativas; Software uso Departamental (Baixa Integrao).

Terminal burro

Mainframe


71/42013



Arquitetura Parcialmente Distribuda

Caractersticas: Um pouco de processamento departamental; Micros com algumas aplicaes locais; Rede Corporativa conectando micro-mainframe; Software Departamental com maior Integrao; Incio de Integrao entre parceiros (EDI).

Mainframe

Microcomputador


Projeto Arquitetural de SoftwareCliente-Servidor (2 camadas)

Caractersticas: Boa parte do processamento local Micros com algumas aplicaes locais Redes LANs ou WANs Integrao entre Parceiros (cliente-servidor)

Micro Cliente

Servidor

Cliente

ClienteCliente

Rede


72/42014



Cliente-Servidor 3 camadas

Client Side

(Camada 1)

Camada de Rede

Sockets e

Midleware

Server Side

Regras Negcio Bases de Dados

(Camada 2) (Camada 3)

Caractersticas: Mais capacidade de Processamento Distribudo Internet/Intranet como infra-estrutura de rede 2 Nveis de Servidor Internet Aplications / Software Integrados(ERPs)

Servidorde

Aplicaes

Servidorde Bases

de DadosCliente


Projeto Arquitetural de SoftwareArquitetura Distribuda Multi-Camadas

Client Side

(Camada 1)

Camada de Rede

Sockets e

Midleware

Cliente

Regras Negcio Bases de Dados

(Camada 2 e 1) (Camada 3)

Servidor de

Aplicaes

Servidorde Bases

de Dados

Servidor deAplicaes

Servidorde Basesde Dados

Browser

Regras de

Negcio

Bases de

Dados


73/42015



Arquitetura Distribuda Multi-Camadas

'Caractersticas:

Alta Capacidade de Processamento Distribudo

Internet/Intranet/Extranet/VPNs como infra-estrutura de rede

Distribuio dos Servios em vrias camadas de servidoresde aplicao e dados

Internet Aplications de ltima gerao, CRM (Relacionamentocom Cliente), SCM (Cadeias de Produo e Distribuio

Integradas), Bancos de Dados Distribudos


Projeto de Software

Projeto Procedimental


74/42016

Engenharia deSoftware Projeto Procedimental de Software

Finaliza os detalhes de processamento (procedimentos) decada mdulo. O procedimento deve oferecer umaespecificao precisa do processamento, inclusive aseqncia de eventos, operaes repetitivas etc.

Baseia-se na Especificao dos requisitos, na modelagem(DFD, Diagrama Classes) e no Dicionrio de Dados,obtidos na anlise.


Projeto Procedimental de SoftwareModelo Comportamental

Diagrama de Estados dos Exemplares


75/42017

Engenharia deSoftware Projeto Procedimental de Software

Seqncia:

1. Decomposio, Identificao e Modelagem do softwareatravs de Componentes (Mdulos ou Classes)

2. Representao da estrutura de controle e interao entreos componentes

3. Reviso e Refinamento da Estrutura

4. Representao dos detalhes algortmicos


Projeto Procedimental de Software

Estrutura do mdulo Monitorar Sensores

8/6/2019 TI - Conhecimentos Esp

Documents

TI - Conhecimentos Específicos - Engenharia da Computação - Concursos