Marquioni
 
 
 
 
Você no Marquioni.com.br
Em breve, você poderá ser um articulista em nosso site. Cadastre-se!
 
Técnico vs. usuário: uma análise do processo comunicacional na Engenharia de Requisitos de Software
Clique aqui para mais informações de como adquirir o livro.
 
 
   
     
 
 
     
 

Selecionar idioma:

Escopo de Projeto x Escopo de Produto: A Engenharia de Requisitos como Subsídio para a Gestão de Software
 
 
Autor Carlos Eduardo Marquioni, M.Sc., PMP
 

 

Considerando que a qualidade do processo utilizado para o desenvolvimento e a manutenção de um produto ou sistema tem influência direta em sua qualidade final, o artigo apresenta alguns dos processos da Engenharia de Requisitos como uma alternativa viável e prática para melhoria da qualidade de software através da sistematização dos processos de gerenciamento de escopo (de projeto e de produto) – tanto nos casos de desenvolvimento quanto de manutenção deste tipo de produto. A abordagem, que é aderente às recomendações das referências PMBoK e CMMI-DEV, baseia-se na definição de uma WBS (Work Breakdown Structure) padrão a partir dos processos da Engenharia de Requisitos. Esta WBS passa a ser customizada para cada projeto de software em função de um critério objetivo definido pela organização (no caso deste artigo é considerado como exemplo o critério ‘tamanho do projeto de software, baseado em uma estimativa de pontos por função’), possibilitando melhoria nos processos relacionados à gestão do escopo, com conseqüente melhoria no produto final.
 
Palavras-chave: WBS; Lista de Requisitos; Engenharia de Requisitos; Gestão de Escopo de Produto; Gestão de Escopo de Projeto.
 

1 INTRODUÇÃO

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, através de uma sugestão de sistematização para uso conjunto de dois processos relacionados à gestão de escopo: de projeto e produto.


Quando se trata de projetos de software, o termo escopo costuma referenciar apenas o conteúdo do produto a desenvolver – mais precisamente, uma lista geral dos requisitos que fazem parte do produto de software. Curiosamente, são raros os casos em que há menção explícita ao escopo do projeto segundo sua definição conceitual original, que envolve a identificação e formalização das atividades que devem ser executadas para desenvolver ou manter o produto de software. Mesmo quando utilizado o termo escopo do projeto, a intenção dos gestores de software parece ser referenciar o escopo do produto gerado a partir da execução do projeto. As poucas referências explícitas ao termo escopo de projeto no âmbito do desenvolvimento e manutenção de software talvez estejam relacionadas ao desgaste sofrido pela sigla MDS (Metodologia de Desenvolvimento de Software), resultado de definições em décadas recentes de processos burocráticos, eventualmente com estabelecimento de elos pouco evidentes com atividades da engenharia, ou mesmo com acompanhamento limitado (particularmente em relação à garantia de qualidade) durante sua institucionalização, o que tipicamente leva ao abandono do processo nas primeiras situações de crise. Mas este trabalho não pretende debater este problema – a complexidade envolvida parece justificar um artigo à parte. Ao invés de propor reflexões acerca do desgaste, o artigo apresenta uma alternativa conceitualmente viável e prática para definição de processos de software segundo uma abordagem que possibilita gerenciar tanto escopo de projeto quanto de produto em projetos de software, a partir da execução de um grupo de processos que tipicamente são observados no desenvolvimento ou manutenção de produtos de software (além de possibilitarem um elo evidente com atividades de engenharia, o que pode facilitar sua compreensão por técnicos). Entre os benefícios que podem ser observados quando consideradas as duas gestões destacam-se:

• Em relação ao escopo do produto: esta gestão possibilita o controle efetivo das mudanças nos requisitos do produto, através da análise das solicitações de mudança e definição de critérios de aceite de forma objetiva. A gestão de escopo do produto permite ainda que haja acompanhamento das variações de tamanho do produto a partir das variações nos requisitos;
• Em relação ao escopo do projeto: esta gestão possibilita a definição de uma data de fim do projeto objetiva, evidenciando a execução de atividades diferentes daquelas previstas originalmente como um motivo para eventuais replanejamentos;
• Quando consideradas em conjunto: é possível evidenciar as variações do planejamento a partir de aspectos concretos, mensuráveis, observáveis tanto pelo gestor do projeto quanto pelos técnicos de software e pelos stakeholders, facilitando as negociações que sejam necessárias.

É relevante destacar que o uso do termo projeto diz respeito não apenas a novos desenvolvimentos de software como também a manutenções 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 são as atividades que fazem parte do projeto (quais atividades devem ser executadas para que os requisitos sejam entregues).


Apesar de haver relação entre o escopo do produto e o escopo do projeto, eles são documentados em artefatos distintos: o escopo do projeto costuma ser formalizado utilizando uma WBS (Work Breakdown Structure) – ou EAP (Estrutura Analítica do Projeto), se o leitor preferir. O escopo do produto tipicamente é formalizado através de uma lista de requisitos e, no caso de projetos de software, posteriormente através de várias abstrações técnicas em diagramas e programas fonte. Para que a formalização em artefatos distintos não provoque dificuldades no tratamento em conjunto dos dois tipos relevantes de escopo que devem ser abordados em todo projeto de software, uma alternativa viável é considerar a Engenharia de Requisitos como um elo, um ponto em comum entre as formas de gestão de escopo – conforme proposta da Tabela 1.

Tabela 1 – Escopo do Produto vs. Escopo do Projeto

DISPONÍVEL NA VERSÃO PDF DO ARTIGO

Fonte: Sugestão do autor

A alternativa pode ser particularmente interessante se considerada uma WBS padrão elaborada a partir dos processos da Engenharia de Requisitos, que pode ser customizada para se adaptar a cada projeto, viabilizando aplicação prática cotidiana e transparente pelos gestores e técnicos de software desses dois grupos de processo. A transparência estaria relacionada à derivação da WBS a partir de atividades de caráter de engenharia, mais facilmente observáveis/reconhecíveis por técnicos de software, e mesmo por muitos gestores de software, que tipicamente são técnicos em sua formação original.


A customização do processo a utilizar para um projeto específico a partir de uma WBS padrão é recomendada por vários modelos de referência consagrados e adotados mundialmente – neste artigo, uma vez que o objetivo é abordar a gestão de projetos de software, são utilizadas não apenas as definições propostas pelo PMBoK 3ª Edição (enquanto referência para gerenciamento de projetos) como também aquelas apresentadas pelo CMMI-DEV staged v. 1.2 (enquanto referência para projetos de software). Esta dupla abordagem visa inclusive evidenciar possível tangência entre as referências.


Para desenvolver o tema de modo ordenado, o artigo é subdivido em outras três partes principais, além desta introdução e das considerações finais. A seção dois, a seguir, apresenta brevemente duas áreas de conhecimento do guia de gerenciamento de projetos PMBoK 3ª Edição fundamentais para o debate proposto (Gerenciamento de Integração e Gerenciamento do Escopo do Projeto), assim como duas áreas de processo do CMMI-DEV (Desenvolvimento de Requisitos e Gestão Integrada de Projetos). A seção três apresenta de forma geral quatro dos processos da Engenharia de Requisitos, suficientes para os objetivos do artigo, e sugere uma WBS padrão simplificada a partir de tais processos. Finalmente, a quarta seção utiliza um exemplo básico para contextualização e customização desta WBS em um projeto de software específico. 

2 CONCEITUAÇÕES FUNDAMENTAIS SEGUNDO MODELOS DE REFERÊNCIA

2.1 PERSPECTIVA DO PMBOK

A área de conhecimento Gerenciamento de Integração do Projeto “inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de gerenciamento de projetos” (PMBOK, 2004, p. 77). Particularmente em relação ao debate proposto neste artigo, Jonasson informa que este grupo de processos é responsável por garantir “que o escopo do produto esteja sincronizado com o escopo do projeto. [...] Qualquer mudança 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 documentação dos requisitos do produto (p. 78). De fato, um dos processos integradores, através do qual é desenvolvido o Project Charter (ou Termo de Abertura do Projeto), tem como uma de suas entradas um artefato nomeado Declaração do Trabalho do Projeto, que indica claramente aspectos de gestão de escopo de produto e projeto que devem ser considerados e tratados sistematicamente:


a. A Declaração do trabalho do projeto engloba a “Descrição do escopo do produto – [que] documenta os requisitos do produto e as características do produto ou serviço para os quais o projeto será realizado” (PMBOK, 2004, p. 83): no caso de projetos de software, corresponde à lista dos requisitos;
b. A Declaração do trabalho do projeto tem ainda como entrada os Ativos de Processos Organizacionais, que relatam a necessidade de “Processos organizacionais padrão, [...] modelos da estrutura analítica do projeto” (PMBOK, 2004, p. 84): evidentemente referenciando uma WBS padrão.


Outra área de conhecimento, Gerenciamento do Escopo do Projeto, “inclui os processos necessários para garantir que o projeto inclua todo o trabalho necessário, e somente ele, para terminar o projeto com sucesso. O gerenciamento do escopo do projeto trata principalmente da definição e controle do que está e do que não está incluído no projeto” (PMBOK, 2004, p. 103). Dentre os processos que devem ser executados para que ocorra esta definição do trabalho necessário, merece destaque aquele nomeado “Criar a WBS [...] [que envolve a] subdivisão das principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis” (PMBOK, 2004, p. 103).


Assim, enquanto a área de conhecimento Gerenciamento de Integração do Projeto indica a necessidade dos requisitos do produto estarem documentados e a possibilidade de uso de uma WBS padrão, o Gerenciamento do Escopo do Projeto sistematiza a criação da WBS.

2.2 PERSPECTIVA DO CMMI-DEV

A área de processo Desenvolvimento de Requisitos tem como propósito “produzir e analisar os requisitos do cliente, do produto e dos componentes do produto [...] [, que] endereçam 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 elicitação) das necessidades, a definição das funcionalidades requeridas, a análise dos requisitos, a procura pelo equilíbrio entre as necessidades do cliente e as restrições do projeto (análise e negociação de requisitos) e a validação dos requisitos com os stakeholders relevantes (p. 391). Claramente se trata da definição de escopo do produto, e é possível estabelecer relação direta com a Descrição do escopo do produto citada anteriormente.


Outra área de processo do CMMI-DEV, Gestão Integrada de Projeto, tem como propósito “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 padrão da organização” (CMMI-DEV, 2006, p. 145). Neste caso, algumas práticas específicas relacionadas informam que deve ser definido o processo do projeto utilizando o processo organizacional como referência (p. 147). Aqui a relação se estabelece com os modelos de estrutura analítica citados e com o Gerenciamento do Escopo do Projeto.


As duas áreas de processo do CMMI-DEV citadas endereçam aspectos coincidentes com as áreas de conhecimento do PMBoK identificadas anteriormente: ambos os modelos de referência destacam a importância de gerenciar os dois tipos de escopo abordados. A Tabela 2 apresenta um resumo das perspectivas consideradas.

Tabela 2 – Quadro resumo das perspectivas consideradas

DISPONÍVEL NA VERSÃO PDF DO ARTIGO

Fonte: Sugestão do autor

3 ALGUNS PROCESSOS DA ENGENHARIA DE REQUISITOS

A Engenharia de Requisitos é a parte da Engenharia de Software através da qual os requisitos são abordados de forma sistematizada, englobando os processos de Levantamento, Análise, Especificação, Validação e Gerenciamento. Uma vez que o objetivo do artigo é a definição de uma WBS padrão a partir destes processos, e em conformidade com os conceitos do PMBoK e do CMMI-DEV apresentados anteriormente, são 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 próximos parágrafos apresentam em linhas gerais os processos da Engenharia de Requisitos considerados (KOTONYA; SOMMERVILLE, 1998), (PRESSMAN, 2000), enquanto a Figura 1 ilustra graficamente e em linhas gerais as possibilidades de interação 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, restrições 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 análise desta complexidade ultrapassa os limites definidos para este artigo, informações adicionais podem ser consultadas em (MARQUIONI, 2007a).


No processo de Análise, o discurso dos stakeholders apresentado durante o Levantamento passa por considerações e avaliações técnicas. Ao longo da execução desse processo há categorização e organização dos requisitos segundo perspectiva técnica, explorando o relacionamento de cada requisito com todos os demais, examinando inconsistências, omissões e ambigüidades. Neste processo podem ocorrer também negociações dos requisitos junto aos stakeholders relevantes.


Concluída a execução do processo de Análise ocorre a Especificação, que caracteriza o momento no qual a compreensão/interpretação dos requisitos pelo técnico de software é formalizada tecnicamente, de acordo com um critério (ou notação) definido pela organização.


A formalização criada para os requisitos durante a Especificação deve ser apresentada aos stakeholders para que seja identificado se a compreensão do técnico acerca do discurso original (e requisitos correspondentes) está correta: trata-se do processo de Validação. Este processo sofre forte influência dos critérios e notações utilizadas durante a Especificação, que podem caracterizar barreiras comunicacionais relacionadas à compreensão de jargão e diagramas técnicos de software – uma vez que a análise destas barreiras também ultrapassa os limites definidos para este artigo, informações adicionais podem ser consultadas em (MARQUIONI, 2007b) e (MARQUIONI, 2008a).

Figura 1 – Processos da Engenharia de Requisitos

DISPONÍVEL NA VERSÃO PDF DO ARTIGO

Fonte: Sugestão do autor, customizada a partir de (KOTONYA; SOMMERVILLE, 1998)

O elo com os conceitos debatidos anteriormente ocorre pois, enquanto a execução dos processos da Engenharia de Requisitos define o escopo do produto, o planejamento da execução destes processos pode ser interpretado como uma forma de caracterizar o escopo do projeto. A afirmação é válida pois, no caso de um projeto de software, uma forma de compreender as atividades técnicas executadas é através da execução iterativa destes processos, pois há sucessivos levantamentos, realizações de consideração técnicas, especificações e validações: tipicamente há variação em relação ao stakeholder e ao papel técnico responsável por executar o processo.


Para ilustrar a afirmação e conduzir as reflexões seguintes, a figura 2 apresenta uma possibilidade de WBS padrão. Note que para procurar tornar as etapas mais familiares aos profissionais de software, esta WBS utilizou a nomenclatura proposta por algumas Disciplinas e artefatos técnicos básicos definidos no Processo Unificado (JACOBSON et al., 2001). A escolha se justifica pela ampla divulgação destes conceitos entre os membros da comunidade de software, mas é importante observar que poderiam ser utilizadas outras referências com resultado equivalente.

Figura 2 – WBS padrão sugerida

DISPONÍVEL NA VERSÃO PDF DO ARTIGO

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

É importante ressaltar também que embora tenha sido realizado um recorte do Processo Unificado na representação da figura 2 (reforçado através das reticências inseridas na figura) para evitar tornar a análise demasiado extensa, a abordagem apresentada pode ser generalizada também para as Disciplinas não representadas. Em relação às Disciplinas evidenciadas, é possível observar que apesar de os nomes e o papel técnico responsável associado a cada uma delas variar (primeiro nível da WBS), o segundo nível pode ser resumido aos quatro processos apresentados da Engenharia de Requisitos. Mesmo as tarefas (último nível da WBS) possuem forte relação conceitual entre si, inclusive entre Disciplinas.


O leitor deve ter constatado que, por exemplo, o término da execução da totalidade das tarefas da Disciplina Requisitos disponibiliza os artefatos técnicos Documento de Visão, Lista de Requisitos (com os requisitos devidamente formalizados em um repositório) e especificações de Casos de Uso (diagramas e descrições correspondentes) devidamente aprovados. O conteúdo documentado nos artefatos constitui o escopo do produto; a execução dos processos para inserir tal conteúdo caracteriza uma parte do escopo do projeto.


No caso das disciplinas Análise & Design e Implementação a idéia é a mesma: o que ocorre é apenas a transcrição (tradução) do escopo de produto segundo outro idioma técnico, executando uma outra parte do escopo do projeto.


Assim, gerar conteúdo de engenharia a partir da execução 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 padrão identifica o máximo 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 próxima seção apresenta um exemplo que, embora simples, deve permitir visualizar a aplicação dos conceitos debatidos.

 

4 A CUSTOMIZAÇÃO DA WBS PADRÃO: GERENCIAMENTO DE ESCOPO DE PROJETO APLICADO

Nesta seção é considerado um exemplo simples, adaptado a partir de (MARQUIONI, 2008b), para procurar esclarecer o uso e customização da WBS padrão. O exemplo é relativo a uma solicitação hipotética de um usuário para que fosse elaborado um software que somasse dois valores numéricos informados, sem armazenar o resultado em banco de dados: trata-se de uma espécie de calculadora.


Ao se deparar com a solicitação do stakeholder (durante a execução do processo de Levantamento), o analista de negócios eventualmente pesquisa fontes de conhecimento e realiza considerações técnicas (Análise). A partir das considerações técnicas realizadas, são identificados e formalizados os requisitos (a lista pode ser bastante extensa, mesmo no caso da solicitação simples apresentada; para efeito do exemplo deste capítulo, são listados apenas dois requisitos funcionais):


RF1 – Manter interface para soma: O sistema realiza soma de pares de valor informados;
RF2 – Considerar conjunto dos números Inteiros (Z): O sistema realiza operações de soma considerando como válido apenas o conjunto dos números inteiros (conjunto Z, segundo teoria matemática).


Segundo a Engenharia de Requisitos, o aparecimento original dos requisitos se dá durante a execução do processo de Levantamento; observe, contudo, que o requisito RF2 pode não ter sido solicitado diretamente pelo usuário, mas eventualmente a consulta a fontes de conhecimento acarreta seu aparecimento, que deve ser alvo de validação. É importante observar que caso o requisito não seja identificado nos momentos iniciais, muito provavelmente ele aparecerá em um outro estágio de representação dos requisitos: quando iniciar a construção dos programas, e for necessária a definição das variáveis técnicas. Para detalhes acerca dos vários estágios de representação dos requisitos consulte (MARQUIONI, 2008b).


Uma vez identificados RF1 e RF2, sua formalização como lista constitui a execução de uma etapa do processo de Especificação. Finalmente, esses requisitos são apresentados ao stakeholder solicitante, o que corresponde ao processo de Validação.


Para que a execução da Disciplina Requisitos encerre, é necessário que sejam gerados outros artefatos técnicos, que também devem ser submetidos a Validações – como comentado anteriormente, a formalização dos requisitos constitui a execução de apenas uma parte do processo (pois a Especificação, segundo a WBS padrão apresentada, envolveria também a criação dos artefatos Documento de Visão e Especificação de Casos de Uso). Além disso, a ordem da elaboração destes artefatos técnicos pode eventualmente ser relevante – tipicamente são elaborados o Documento de Visão, a Lista de Requisitos e os Casos de Uso, nesta ordem.
É neste sentido que a customização da WBS padrão pode ser realizada para cada projeto de software. Considere que para o exemplo em questão, o gerente de projetos – ao ter conhecimento da simplicidade da solicitação do stakeholder, e considerando restrições que eventualmente possua –, negocie com o solicitante e com sua equipe de projeto que alguns artefatos técnicos não necessitam ser gerados para o projeto que vai originar o produto. Esta negociação poderia gerar, por consenso entre o gestor, os técnicos e stakeholders, uma WBS customizada como aquela apresentada na figura 3.

Figura 3 – WBS adaptada e negociada para o projeto exemplo

DISPONÍVEL NA VERSÃO PDF DO ARTIGO

Fonte: Sugestão do autor

No caso da WBS apresentada na figura 3, as atividades comentadas anteriormente, executadas em relação à Disciplina Requisitos já seriam suficientes para este projeto. Assim, após a aprovação dos requisitos (Validação), a lista criada é objeto de leitura e de considerações pelo papel técnico Desenvolvedor (Levantamento e Análise – relativos à Disciplina Implementação) e o requisito passa a ser redigido utilizando uma linguagem de programação (Especificação). A atividade de Levantamento neste caso ocorre em relação aos artefatos resultantes da execução da Disciplina Requisitos (apenas a Lista de Requisitos). Uma vez concluída a programação, haverá nova Validação – em função do estágio no ciclo de vida provavelmente através de testes.


No caso deste exemplo, o critério considerado para customização da WBS padrão foi o julgamento subjetivo do gerente de projeto, que procurou acordo junto ao solicitante e à equipe técnica acerca do tailoring a realizar. Contudo, esta customização pode considerar critérios mais objetivos – por exemplo, tamanho em Pontos por Função (PF) ou Pontos por Casos de Uso (PUC). A Tabela 3 apresenta uma possibilidade de WBS padrão de acordo com a sugestão da Figura 2 – considerando apenas o processo de Especificação –, em função de tamanho em Pontos por Função. Segundo a Tabela 3, o tamanho da calculadora solicitada no exemplo se enquadra em “Até x PF”.

Tabela 3 – Critério de artefatos a gerar em função de tamanho em Pontos por Função

DISPONÍVEL NA VERSÃO PDF DO ARTIGO

Fonte: Sugestão do autor

Considerando a WBS customizada da Figura 3, em relação 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 CONSIDERAÇÕES FINAIS

Gerenciar simultaneamente os escopos do projeto e do produto não é necessariamente uma atividade trivial. Particularmente no caso de projetos de software, em que os gestores costumam ter origem técnica, é importante estabelecer elos que permitam associar estes dois escopos com atividades de caráter de engenharia – esta abordagem acaba gerando uma contextualização mais familiar ao gerente de projetos – e, porque não dizer, também aos técnicos, que inevitavelmente são afetados pelas atividades de gerenciamento.


Enquanto a execução dos processos da Engenharia de Requisitos define os requisitos do produto, o conhecimento dos processos que a compõem possibilita a definição de uma WBS padrão a partir da qual é possível realizar customizações específicas para cada projeto em função de um critério definido. É importante observar que podem existir várias sugestões de customização da WBS padrão em função, por exemplo, de tamanho de produto: esta abordagem facilita as atividades de tailoring – há neste caso, de fato, uma customização prévia sugerida da WBS padrão.


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 responsáveis pela definição de processos de engenharia e qualidade de software como uma alternativa viável e de fácil aplicação prática para gestão de escopo de projeto e de produto.

 
 

 

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. Disponível: <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, São Paulo (USP). Anais... São Paulo: CD-ROM, 2007a. Disponível em www.marquioni.com.br.
___________. Comunicação através de Diagramas de Casos de Uso no Desenvolvimento de Software – Uma breve análise de sentido. In: CONECO (Congresso de Estudantes de Pós-Graduação em Comunicação), 2º, 2007, Rio de Janeiro (PUC-Rio). Anais... Rio de Janeiro: CD-ROM, 2007b. Disponível em 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, São Paulo (USP). Proceedings. São Paulo: CD-ROM, 2008a. Disponível em www.marquioni.com.br.
___________. Técnico vs. usuário: Uma análise do processo comunicacional na Engenharia de Requisitos de software. Curitiba: UTP, 2008b.
PMBoK. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos – Terceira Edição. Newton Square: PMI, 2004.
PRESSMAN, R. Software Engineering – A Practitioner’s Approach – European Adaptation. London: McGraw Hill International Limited, 2000.
 

Artigo apresentado no III Simpósio Internacional de Administração e Marketing/V Congresso de Administração da ESPM realizado na ESPM/SP em Dezembro/2008.

 
 
 
 
Selecionar idioma:
 
Artigos  |  Seja um Articulista  |  Cadastre-se  |  Links  |  RSS  |  Administrar
pH Design Desenvolvido por pH Design | Copyright © 2008