Escopo de Projeto x Escopo de Produto: A Engenharia de Requisitos como subsdio para a Gesto de Software1

Carlos Eduardo Marquioni2, M.Sc., PMP

Resumo:
Considerando que a qualidade do processo utilizado para o desenvolvimento e a manuteno de um produto ou sistema tem influncia direta em sua qualidade final, o artigo apresenta alguns dos processos da Engenharia de Requisitos como uma alternativa vivel e prtica para melhoria da qualidade de software atravs da sistematizao dos processos de gerenciamento de escopo (de projeto e de produto) tanto nos casos de desenvolvimento quanto de manuteno deste tipo de produto. A abordagem, que aderente s recomendaes das referncias PMBoK e CMMI-DEV, baseia-se na definio de uma WBS (Work Breakdown Structure) padro a partir dos processos da Engenharia de Requisitos. Esta WBS passa a ser customizada para cada projeto de software em funo de um critrio objetivo definido pela organizao (no caso deste artigo considerado como exemplo o critrio tamanho do projeto de software, baseado em uma estimativa de pontos por funo), possibilitando melhoria nos processos relacionados gesto do escopo, com conseqente melhoria no produto final.

Palavras-chave: WBS; Lista de Requisitos; Engenharia de Requisitos; Gesto de

Project Scope Management x Product Scope Management: Requirements Engineering supporting Software Management
Abstract:
This article presents some of the Requirements Engineering processes as a practical and viable alternative to scope management (both, project and product scope management) in the case of software projects, considering that the quality of a product or a system is influenced by the quality of the process used to develop or maintain it.
1

Artigo apresentado no III Simpsio Internacional de Administrao e Marketing/V Congresso de Administrao da ESPM realizado na ESPM/SP em Dezembro/2008. 2 [email protected] Mestre em Comunicao e Linguagens (UTP/2008) e Bacharel em Anlise de Sistemas (PUC-Campinas/1994).

Pgina: 1 de 19

This approach permits relation with the recommendations of PMBoK and CMMI-DEV, and is based on the definition of a standard WBS (Work Breakdown Structure) elaborated from Requirements Engineering processes. Such WBS is tailored to each software project using an objective criteria defined by the organization (in the case of this article, it is used as example the criteria size of software project, based on function points estimating method), allowing improvement in the scope management process and, as consequence, in the software product.

Key-words: WBS; Requirements List; Requirements Engineering; Product Scope

Pgina: 2 de 19

INTRODUO

A qualidade de um sistema ou produto influenciada pela qualidade do processo utilizado para desenvolv-lo e mant-lo (CHRISSIS et al., 2003, p. 5); assim, a melhoria do processo de desenvolvimento de software tende a melhorar a qualidade do produto resultante. Este artigo apresenta uma alternativa para melhoria de processos de software, atravs de uma sugesto de sistematizao para uso conjunto de dois processos relacionados gesto de escopo: de projeto e produto. Quando se trata de projetos de software, o termo escopo costuma referenciar apenas o contedo do produto a desenvolver mais precisamente, uma lista geral dos requisitos que fazem parte do produto de software. Curiosamente, so raros os casos em que h meno explcita ao escopo do projeto segundo sua definio conceitual original, que envolve a identificao e formalizao das atividades que devem ser executadas para desenvolver ou manter o produto de software. Mesmo quando utilizado o termo escopo do projeto, a inteno dos gestores de software parece ser referenciar o escopo do produto gerado a partir da execuo do projeto. As poucas referncias explcitas ao termo escopo de projeto no mbito do desenvolvimento e manuteno de software talvez estejam relacionadas ao desgaste sofrido pela sigla MDS (Metodologia de Desenvolvimento de Software), resultado de definies em dcadas recentes de processos burocrticos, eventualmente com estabelecimento de elos pouco evidentes com atividades da engenharia, ou mesmo com acompanhamento limitado (particularmente em relao garantia de qualidade) durante sua institucionalizao, o que tipicamente leva ao abandono do processo nas primeiras situaes de crise. Mas este trabalho no pretende debater este problema a complexidade envolvida parece justificar um artigo parte. Ao invs de propor reflexes acerca do desgaste, o artigo apresenta uma alternativa conceitualmente vivel e prtica para definio de processos de software segundo uma abordagem que possibilita gerenciar tanto

Pgina: 3 de 19

escopo de projeto quanto de produto em projetos de software, a partir da execuo de um grupo de processos que tipicamente so observados no desenvolvimento ou manuteno de produtos de software (alm de possibilitarem um elo evidente com atividades de engenharia, o que pode facilitar sua compreenso por tcnicos). Entre os benefcios que podem ser observados quando consideradas as duas gestes destacam-se: Em relao ao escopo do produto: esta gesto possibilita o controle efetivo das mudanas nos requisitos do produto, atravs da anlise das solicitaes de mudana e definio de critrios de aceite de forma objetiva. A gesto de escopo do produto permite ainda que haja acompanhamento das variaes de tamanho do produto a partir das variaes nos requisitos; Em relao ao escopo do projeto: esta gesto possibilita a definio de uma data de fim do projeto objetiva, evidenciando a execuo de atividades diferentes daquelas previstas originalmente como um motivo para eventuais replanejamentos; Quando consideradas em conjunto: possvel evidenciar as variaes do planejamento a partir de aspectos concretos, mensurveis, observveis tanto pelo gestor do projeto quanto pelos tcnicos de software e pelos stakeholders, facilitando as negociaes que sejam necessrias. relevante destacar que o uso do termo projeto diz respeito no apenas a novos desenvolvimentos de software como tambm a manutenes em produtos existentes.
1.1 ESCOPO DE PRODUTO E ESCOPO DE PROJETO

Enquanto o escopo do produto identifica os requisitos que fazem parte do produto (o que deve ser entregue), o escopo do projeto informa quais so as atividades que fazem parte do projeto (quais atividades devem ser executadas para que os requisitos sejam entregues).

Pgina: 4 de 19

Apesar de haver relao entre o escopo do produto e o escopo do projeto, eles so documentados em artefatos distintos: o escopo do projeto costuma ser formalizado utilizando uma WBS (Work Breakdown Structure) ou EAP (Estrutura Analtica do Projeto), se o leitor preferir. O escopo do produto tipicamente formalizado atravs de uma lista de requisitos e, no caso de projetos de software, posteriormente atravs de vrias abstraes tcnicas em diagramas e programas fonte. Para que a formalizao em artefatos distintos no provoque dificuldades no tratamento em conjunto dos dois tipos relevantes de escopo que devem ser abordados em todo projeto de software, uma alternativa vivel considerar a Engenharia de Requisitos como um elo, um ponto em comum entre as formas de gesto de escopo conforme proposta da Tabela 1.
Tabela 1 Escopo do Produto vs. Escopo do Projeto
Escopo do... Produto Conceito geral Requisitos que devem ser entregues como resultado do projeto Atividades que devem ser executadas para gerar/atualizar o produto Artefato tpico (Software) - Lista de Requisitos - Diagramas tcnicos - Programas Fonte WBS (EAP) Elo possvel atravs da Engenharia de Requisitos Execuo dos processos da Engenharia de Requisitos viabiliza a gerao e atualizao dos artefatos tpicos Planejamento da execuo dos processos da Engenharia de Requisitos constitui uma WBS

Projeto

Fonte: Sugesto do autor

A alternativa pode ser particularmente interessante se considerada uma WBS padro elaborada a partir dos processos da Engenharia de Requisitos, que pode ser customizada para se adaptar a cada projeto, viabilizando aplicao prtica cotidiana e transparente pelos gestores e tcnicos de software desses dois grupos de processo. A transparncia estaria relacionada derivao da WBS a partir de atividades de carter de engenharia, mais facilmente observveis/reconhecveis

Pgina: 5 de 19

por tcnicos de software, e mesmo por muitos gestores de software, que tipicamente so tcnicos em sua formao original. A customizao do processo a utilizar para um projeto especfico a partir de uma WBS padro recomendada por vrios modelos de referncia consagrados e adotados mundialmente neste artigo, uma vez que o objetivo abordar a gesto de projetos de software, so utilizadas no apenas as definies propostas pelo PMBoK 3 Edio (enquanto referncia para gerenciamento de projetos) como tambm aquelas apresentadas pelo CMMI-DEV staged v. 1.2 (enquanto referncia para projetos de software). Esta dupla abordagem visa inclusive evidenciar possvel tangncia entre as referncias. Para desenvolver o tema de modo ordenado, o artigo subdivido em outras trs partes principais, alm desta introduo e das consideraes finais. A seo dois, a seguir, apresenta brevemente duas reas de conhecimento do guia de gerenciamento de projetos PMBoK 3 Edio fundamentais para o debate proposto (Gerenciamento de Integrao e Gerenciamento do Escopo do Projeto), assim como duas reas de processo do CMMI-DEV (Desenvolvimento de Requisitos e Gesto Integrada de Projetos). A seo trs apresenta de forma geral quatro dos processos da Engenharia de Requisitos, suficientes para os objetivos do artigo, e sugere uma WBS padro simplificada a partir de tais processos. Finalmente, a quarta seo utiliza um exemplo bsico para contextualizao e customizao desta WBS em um projeto de software especfico.
2 CONCEITUAES REFERNCIA 2.1 PERSPECTIVA DO PMBOK FUNDAMENTAIS SEGUNDO MODELOS DE

A rea de conhecimento Gerenciamento de Integrao do Projeto inclui os processos e as atividades necessrias para identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de gerenciamento de projetos

Pgina: 6 de 19

(PMBOK, 2004, p. 77). Particularmente em relao ao debate proposto neste artigo, Jonasson informa que este grupo de processos responsvel por garantir que o escopo do produto esteja sincronizado com o escopo do projeto. [...] Qualquer mudana no escopo do produto ou do projeto impactar o outro (2008, p. 18). Dentre as atividades que a equipe de gerenciamento de projeto tem a executar, a rea de conhecimento do PMBoK destaca a necessidade de documentao dos requisitos do produto (p. 78). De fato, um dos processos integradores, atravs do qual desenvolvido o Project Charter (ou Termo de Abertura do Projeto), tem como uma de suas entradas um artefato nomeado Declarao do Trabalho do Projeto, que indica claramente aspectos de gesto de escopo de produto e projeto que devem ser considerados e tratados sistematicamente: a. A Declarao do trabalho do projeto engloba a Descrio do escopo do produto [que] documenta os requisitos do produto e as caractersticas do produto ou servio para os quais o projeto ser realizado (PMBOK, 2004, p. 83): no caso de projetos de software, corresponde lista dos requisitos; b. A Declarao do trabalho do projeto tem ainda como entrada os Ativos de Processos Organizacionais, que relatam a necessidade de Processos organizacionais padro, [...] modelos da estrutura analtica do projeto (PMBOK, 2004, p. 84): evidentemente referenciando uma WBS padro. Outra rea de conhecimento, Gerenciamento do Escopo do Projeto, inclui os processos necessrios para garantir que o projeto inclua todo o trabalho necessrio, e somente ele, para terminar o projeto com sucesso. O gerenciamento do escopo do projeto trata principalmente da definio e controle do que est e do que no est includo no projeto (PMBOK, 2004, p. 103). Dentre os processos que devem ser executados para que ocorra esta definio do trabalho necessrio, merece destaque aquele nomeado Criar a WBS [...] [que envolve a] subdiviso das principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciveis (PMBOK, 2004, p. 103).

Pgina: 7 de 19

Assim, enquanto a rea de conhecimento Gerenciamento de Integrao do Projeto indica a necessidade dos requisitos do produto estarem documentados e a possibilidade de uso de uma WBS padro, o Gerenciamento do Escopo do Projeto sistematiza a criao da WBS.
2.2 PERSPECTIVA DO CMMI-DEV

A rea de processo Desenvolvimento de Requisitos tem como propsito produzir e analisar os requisitos do cliente, do produto e dos componentes do produto [...] [, que] endeream as necessidades dos stakeholders relevantes (CMMI-DEV, 2006, p. 388). Dentre as atividades que o CMMI recomenda que sejam executadas para o Desenvolvimento de Requisitos, merecem destaque o levantamento (ou elicitao) das necessidades, a definio das funcionalidades requeridas, a anlise dos requisitos, a procura pelo equilbrio entre as necessidades do cliente e as restries do projeto (anlise e negociao de requisitos) e a validao dos requisitos com os stakeholders relevantes (p. 391). Claramente se trata da definio de escopo do produto, e possvel estabelecer relao direta com a Descrio do escopo do produto citada anteriormente. Outra rea de processo do CMMI-DEV, Gesto Integrada de Projeto, tem como propsito estabelecer e manter o projeto e o envolvimento dos stakeholders relevantes de acordo com um processo definido e que derivado a partir do conjunto de processos padro da organizao (CMMI-DEV, 2006, p. 145). Neste caso, algumas prticas especficas relacionadas informam que deve ser definido o processo do projeto utilizando o processo organizacional como referncia (p. 147). Aqui a relao se estabelece com os modelos de estrutura analtica citados e com o Gerenciamento do Escopo do Projeto. As duas reas de processo do CMMI-DEV citadas endeream aspectos coincidentes com as reas de conhecimento do PMBoK identificadas anteriormente: ambos os modelos de referncia destacam a importncia de

Pgina: 8 de 19

gerenciar os dois tipos de escopo abordados. A Tabela 2 apresenta um resumo das perspectivas consideradas.
Tabela 2 Quadro resumo das perspectivas consideradas
PMBoK KA (Knowledge Area) rea de Conhecimento Gerenciamento de Integrao do Projeto Gerenciamento do Escopo do Projeto PA (Process Area) rea de Processo Desenvolvimento de Requisitos Gesto Integrada de Projeto Relao com abordagem proposta no artigo - Indica a necessidade de documentar formalmente os requisitos do produto - Informa a possibilidade de uso de uma WBS padro - Sistematiza a criao da WBS CMMI Relao com abordagem proposta no artigo - Informa a necessidade de executar os processos da Engenharia de Requisitos para identificar, negociar, formalizar e validar os requisitos - Informa a necessidade de definir um processo para o projeto, a partir de um processo padro

Fonte: Sugesto do autor; resumo elaborado a partir de (CMMI, 2006), (PMBoK, 2004)

ALGUNS PROCESSOS DA ENGENHARIA DE REQUISITOS

A Engenharia de Requisitos a parte da Engenharia de Software atravs da qual os requisitos so abordados de forma sistematizada, englobando os processos de Levantamento, Anlise, Especificao, Validao e Gerenciamento. Uma vez que o objetivo do artigo a definio de uma WBS padro a partir destes processos, e em conformidade com os conceitos do PMBoK e do CMMI-DEV apresentados anteriormente, so suficientes os quatro primeiros processos (o processo de Gerenciamento de Requisitos possibilita elos com outras reas de conhecimento segundo o PMBoK e outra rea de processo segundo o CMMI-DEV estes elos podem ser tratados em um artigo futuro). Os prximos pargrafos apresentam em linhas gerais os processos da Engenharia de Requisitos considerados (KOTONYA; SOMMERVILLE, 1998), (PRESSMAN, 2000),

Pgina: 9 de 19

enquanto a Figura 1 ilustra graficamente e em linhas gerais as possibilidades de interao entre estes processos. O Levantamento de requisitos o processo executado para identificar junto aos stakeholders o problema a ser resolvido, o desempenho desejado do produto, restries de equipamentos etc. O processo de Levantamento possui uma complexidade especial relacionada a aspectos comunicacionais que pode levar a problemas de instabilidade (ou volatilidade) dos requisitos uma vez que a anlise desta complexidade ultrapassa os limites definidos para este artigo, informaes adicionais podem ser consultadas em (MARQUIONI, 2007a). No processo de Anlise, o discurso dos stakeholders apresentado durante o Levantamento passa por consideraes e avaliaes tcnicas. Ao longo da execuo desse processo h categorizao e organizao dos requisitos segundo perspectiva tcnica, explorando o relacionamento de cada requisito com todos os demais, examinando inconsistncias, omisses e ambigidades. Neste processo podem ocorrer tambm negociaes dos requisitos junto aos stakeholders relevantes. Concluda a execuo do processo de Anlise ocorre a Especificao, que caracteriza o momento no qual a compreenso/interpretao dos requisitos pelo tcnico de software formalizada tecnicamente, de acordo com um critrio (ou notao) definido pela organizao. A formalizao criada para os requisitos durante a Especificao deve ser apresentada aos stakeholders para que seja identificado se a compreenso do tcnico acerca do discurso original (e requisitos correspondentes) est correta: trata-se do processo de Validao. Este processo sofre forte influncia dos critrios e notaes utilizadas durante a Especificao, que podem caracterizar barreiras comunicacionais relacionadas compreenso de jargo e diagramas tcnicos de software uma vez que a anlise destas barreiras tambm ultrapassa os limites definidos para este artigo, informaes adicionais podem ser consultadas em (MARQUIONI, 2007b) e (MARQUIONI, 2008a).

Pgina: 10 de 19

Figura 1 Processos da Engenharia de Requisitos

Fonte: Sugesto do autor, customizada a partir de (KOTONYA; SOMMERVILLE, 1998)

O elo com os conceitos debatidos anteriormente ocorre pois, enquanto a execuo dos processos da Engenharia de Requisitos define o escopo do produto, o planejamento da execuo destes processos pode ser interpretado como uma forma de caracterizar o escopo do projeto. A afirmao vlida pois, no caso de um projeto de software, uma forma de compreender as atividades tcnicas executadas atravs da execuo iterativa destes processos, pois h sucessivos levantamentos, realizaes de considerao tcnicas, especificaes e validaes: tipicamente h variao em relao ao stakeholder e ao papel tcnico responsvel por executar o processo. Para ilustrar a afirmao e conduzir as reflexes seguintes, a figura 2 apresenta uma possibilidade de WBS padro. Note que para procurar tornar as etapas mais familiares aos profissionais de software, esta WBS utilizou a nomenclatura proposta por algumas Disciplinas e artefatos tcnicos bsicos definidos no Processo Unificado (JACOBSON et al., 2001). A escolha se justifica pela ampla divulgao destes conceitos entre os membros da comunidade de software, mas importante observar que poderiam ser utilizadas outras referncias com resultado equivalente.

Pgina: 11 de 19

Figura 2 WBS padro sugerida

Fonte: Sugesto do autor, customizada a partir de (JACOBSON et al., 2001); (KOTONYA; SOMMERVILLE, 1998)

importante ressaltar tambm que embora tenha sido realizado um recorte do Processo Unificado na representao da figura 2 (reforado atravs das reticncias inseridas na figura) para evitar tornar a anlise demasiado extensa, a abordagem apresentada pode ser generalizada tambm para as Disciplinas no representadas. Em relao s Disciplinas evidenciadas, possvel observar que apesar de os nomes e o papel tcnico responsvel associado a cada uma delas variar (primeiro nvel da WBS), o segundo nvel pode ser resumido aos quatro processos apresentados da Engenharia de Requisitos. Mesmo as tarefas (ltimo nvel da WBS) possuem forte relao conceitual entre si, inclusive entre Disciplinas. O leitor deve ter constatado que, por exemplo, o trmino da execuo da totalidade das tarefas da Disciplina Requisitos disponibiliza os artefatos tcnicos Documento de Viso, Lista de Requisitos (com os requisitos devidamente formalizados em um repositrio) e especificaes de Casos de Uso (diagramas e descries correspondentes) devidamente aprovados. O contedo documentado nos artefatos constitui o escopo do produto; a execuo dos processos para inserir tal contedo caracteriza uma parte do escopo do projeto.

Pgina: 12 de 19

No caso das disciplinas Anlise & Design e Implementao a idia a mesma: o que ocorre apenas a transcrio (traduo) do escopo de produto segundo outro idioma tcnico, executando uma outra parte do escopo do projeto. Assim, gerar contedo de engenharia a partir da execuo das atividades propostas na WBS origina o escopo do produto; por outro lado, realizar tailoring customizar a WBS define o escopo do projeto, uma vez que cada Disciplina listada nesta WBS padro identifica o mximo de atividades que podem ser executadas em um projeto. Vale lembrar que conceitualmente apenas as atividades identificadas na WBS devem ser executadas para o projeto. A prxima seo apresenta um exemplo que, embora simples, deve permitir visualizar a aplicao dos conceitos debatidos.
4 A CUSTOMIZAO DA WBS PADRO: GERENCIAMENTO DE ESCOPO DE PROJETO APLICADO

Nesta seo considerado um exemplo simples, adaptado a partir de (MARQUIONI, 2008b), para procurar esclarecer o uso e customizao da WBS padro. O exemplo relativo a uma solicitao hipottica de um usurio para que fosse elaborado um software que somasse dois valores numricos informados, sem armazenar o resultado em banco de dados: trata-se de uma espcie de calculadora. Ao se deparar com a solicitao do stakeholder (durante a execuo do processo de Levantamento), o analista de negcios eventualmente pesquisa fontes de conhecimento e realiza consideraes tcnicas (Anlise). A partir das consideraes tcnicas realizadas, so identificados e formalizados os requisitos (a lista pode ser bastante extensa, mesmo no caso da solicitao simples apresentada; para efeito do exemplo deste captulo, so listados apenas dois requisitos funcionais): RF1 Manter interface para soma: O sistema realiza soma de pares de valor informados;

Pgina: 13 de 19

RF2 Considerar conjunto dos nmeros Inteiros (Z): O sistema realiza operaes de soma considerando como vlido apenas o conjunto dos nmeros inteiros (conjunto Z, segundo teoria matemtica). Segundo a Engenharia de Requisitos, o aparecimento original dos requisitos se d durante a execuo do processo de Levantamento; observe, contudo, que o requisito RF2 pode no ter sido solicitado diretamente pelo usurio, mas eventualmente a consulta a fontes de conhecimento acarreta seu aparecimento, que deve ser alvo de validao. importante observar que caso o requisito no seja identificado nos momentos iniciais, muito provavelmente ele aparecer em um outro estgio de representao dos requisitos: quando iniciar a construo dos programas, e for necessria a definio das variveis tcnicas. Para detalhes acerca dos vrios estgios de representao dos requisitos consulte (MARQUIONI, 2008b). Uma vez identificados RF1 e RF2, sua formalizao como lista constitui a execuo de uma etapa do processo de Especificao. Finalmente, esses requisitos so apresentados ao stakeholder solicitante, o que corresponde ao processo de Validao. Para que a execuo da Disciplina Requisitos encerre, necessrio que sejam gerados outros artefatos tcnicos, que tambm devem ser submetidos a Validaes como comentado anteriormente, a formalizao dos requisitos constitui a execuo de apenas uma parte do processo (pois a Especificao, segundo a WBS padro apresentada, envolveria tambm a criao dos artefatos Documento de Viso e Especificao de Casos de Uso). Alm disso, a ordem da elaborao destes artefatos tcnicos pode eventualmente ser relevante tipicamente so elaborados o Documento de Viso, a Lista de Requisitos e os Casos de Uso, nesta ordem. neste sentido que a customizao da WBS padro pode ser realizada para cada projeto de software. Considere que para o exemplo em questo, o gerente de projetos ao ter conhecimento da simplicidade da solicitao do stakeholder, e

Pgina: 14 de 19

considerando restries que eventualmente possua , negocie com o solicitante e com sua equipe de projeto que alguns artefatos tcnicos no necessitam ser gerados para o projeto que vai originar o produto. Esta negociao poderia gerar, por consenso entre o gestor, os tcnicos e stakeholders, uma WBS customizada como aquela apresentada na figura 3.
Figura 3 WBS adaptada e negociada para o projeto exemplo
Desenvolver Software WBS Adaptada

Disciplina Requisitos

Papel Tcnico: Analista de Negcios

Disciplina Implementao

Papel Tcnico: Desenvolvedor

...

Levantamento

- Preparar levantamento Requisitos; - Realizar levantamento Requisitos. - Realizar Anlise alternativas tcnicas e conflitos entre requisitos. - Redigir Lista de Requisitos (Requirements attributes database).

Levantamento

- Realizar levantamento Implementao. - Realizar Anlise alternativas tcnicas e conflitos entre requisitos (Implementao). - Especificar (construir) programas. - Realizar validao Implementao (testes unitrios e integrao).

Anlise

Anlise

Especificao

Especificao

Validao

- Realizar validao Disciplina Requisitos.

Validao

Fonte: Sugesto do autor

No caso da WBS apresentada na figura 3, as atividades comentadas anteriormente, executadas em relao Disciplina Requisitos j seriam suficientes para este projeto. Assim, aps a aprovao dos requisitos (Validao), a lista criada objeto de leitura e de consideraes pelo papel tcnico Desenvolvedor (Levantamento e Anlise relativos Disciplina Implementao) e o requisito passa a ser redigido utilizando uma linguagem de programao (Especificao). A atividade de Levantamento neste caso ocorre em relao aos artefatos resultantes da execuo da Disciplina Requisitos (apenas a Lista de Requisitos). Uma vez concluda a programao, haver nova Validao em funo do estgio no ciclo de vida provavelmente atravs de testes. No caso deste exemplo, o critrio considerado para customizao da WBS padro foi o julgamento subjetivo do gerente de projeto, que procurou acordo

Pgina: 15 de 19

junto ao solicitante e equipe tcnica acerca do tailoring a realizar. Contudo, esta customizao pode considerar critrios mais objetivos por exemplo, tamanho em Pontos por Funo (PF) ou Pontos por Casos de Uso (PUC). A Tabela 3 apresenta uma possibilidade de WBS padro de acordo com a sugesto da Figura 2 considerando apenas o processo de Especificao , em funo de tamanho em Pontos por Funo. Segundo a Tabela 3, o tamanho da calculadora solicitada no exemplo se enquadra em At x PF.
Tabela 3 Critrio de artefatos a gerar em funo de tamanho em Pontos por Funo
Tamanho At x PF x < PF <= z PF > z Disciplina Requisitos - Redigir Lista de Requisitos - Redigir Lista de Requisitos - Especificar Casos de uso - Redigir Documento de Viso - Redigir Lista de Requisitos - Especificar Casos de uso n/a - Especificar Modelos Classes - Especificar Modelos Classes - Especificar Diagramas Seqncia Especificar Diagramas Componentes Disciplina Anlise & Design Disciplina Implementao Especificar Programas Especificar Programas Especificar Programas (construir) (construir) (construir)

Fonte: Sugesto do autor

Considerando a WBS customizada da Figura 3, em relao ao exemplo da calculadora solicitada, por mais simples que possa parecer, quando os dois requisitos listados forem especificados como programas, validados e aprovados pelo solicitante, o escopo do produto foi atendido. Se todos os processos da WBS customizada foram executados, o escopo do projeto foi atendido.
5 CONSIDERAES FINAIS

Gerenciar simultaneamente os escopos do projeto e do produto no necessariamente uma atividade trivial. Particularmente no caso de projetos de software, em que os gestores costumam ter origem tcnica, importante estabelecer elos que permitam associar estes dois escopos com atividades de carter de engenharia esta abordagem acaba gerando uma contextualizao mais

Pgina: 16 de 19

familiar ao gerente de projetos e, porque no dizer, tambm aos tcnicos, que inevitavelmente so afetados pelas atividades de gerenciamento. Enquanto a execuo dos processos da Engenharia de Requisitos define os requisitos do produto, o conhecimento dos processos que a compem possibilita a definio de uma WBS padro a partir da qual possvel realizar customizaes especficas para cada projeto em funo de um critrio definido. importante observar que podem existir vrias sugestes de customizao da WBS padro em funo, por exemplo, de tamanho de produto: esta abordagem facilita as atividades de tailoring h neste caso, de fato, uma customizao prvia sugerida da WBS padro. Qualquer que seja o formato adotado, vale lembrar que as atividades da Engenharia de Requisitos parecem possibilitar uma abordagem interessante que merece ser considerada pelos gestores de projeto e responsveis pela definio de processos de engenharia e qualidade de software como uma alternativa vivel e de fcil aplicao prtica para gesto de escopo de projeto e de produto.

Pgina: 17 de 19

Referncias
CHRISSIS, M. B.; KONRAD, M; SHRUM, S. CMMI: Guidelines for Process Integration and Product Improvement. Boston: Addison-Wesley, 2003. CMMI-DEV (2006). CMMI for Development. Version 1.2. Pittsburgh: SEI, 2006. Disponvel: <http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf>. Acesso: 23 mar. 2008. JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Software Development Process. Boston: Addison-Wesley, 2001. JONASSON, H. Determining Project Requirements. Boca Raton: Taylor & Francis Group, 2008. KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and Techniques. New York: John Wiley & Sons Inc, 1998. MARQUIONI, C. E. Volatile software requirements A conceptual analysis of a practical problem. In: CONTECSI (International Conference on Information Systems and Technology Management), 4, 2007, So Paulo (USP). Anais... So Paulo: CDROM, 2007a. Disponvel: www.marquioni.com.br. ___________. Comunicao atravs de Diagramas de Casos de Uso no Desenvolvimento de Software Uma breve anlise de sentido. In: CONECO (Congresso de Estudantes de Ps-Graduao em Comunicao), 2, 2007, Rio de Janeiro (PUC-Rio). Anais... Rio de Janeiro: CD-ROM, 2007b. Disponvel: www.marquioni.com.br. ___________. Use of interface prototypes as an idiom during requirements validation A semiotic analysis. In: CONTECSI (International Conference on Information Systems and Technology Management), 5, 2008, So Paulo (USP). Proceedings. So Paulo: CD-ROM, 2008a. Disponvel: www.marquioni.com.br. ___________. Tcnico vs. usurio: Uma anlise do processo comunicacional na Engenharia de Requisitos de software. Curitiba: UTP, 2008b.

Pgina: 18 de 19

PMBoK. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos Terceira Edio. Newton Square: PMI, 2004. PRESSMAN, R. Software Engineering A Practitioners Approach European Adaptation. London: McGraw Hill International Limited, 2000.

Pgina: 19 de 19