ARTIGO TÉCNICO: Engenharia de Sistemas e Gerenciamento de Projetos

Engenharia de Sistemas e Gerenciamento de Projetos

Resumo – Considerando que o sucesso dos projetos depende de competências técnicas e gerenciais, propomos a sinergia destas disciplinas complementares: gerenciamento de projetos e engenharia de sistemas. Este artigo apresenta conceitos e processos de engenharia de sistemas aplicados ao gerenciamento de projetos.

Palavras-chave: Engenharia de sistemas; Gerenciamento de projetos; Stakeholders.

  1. Introdução

O gerenciamento de projetos, como tradicionalmente conhecido, procura reunir e sistematizar melhores práticas e metodologias baseadas em processos orientados ao projeto, processos de gestão.

Uma distinção importante aparece no Guia PMBOK® (2008): ciclo de vida do projeto versus ciclo de vida do produto. Os processos orientados ao produto são aqueles empregados para a construção ou desenvolvimento do produto ou resultado único do projeto. São processos que dependem da indústria, por exemplo: processos para a construção civil, processos da indústria aeronáutica e processos para desenvolvimento de software.

A engenharia de sistemas aparece como uma disciplina complementar ao gerenciamento de projetos na medida em que reúne melhores práticas para coordenar os processos orientados ao produto, considerando todo o ciclo de vida do produto.

A recente parceria entre o Project Management Institute (PMI) e o International Council of Systems Engineering (INCOSE) reforça a importância de sinergia entre as disciplinas de gerenciamento de projetos e engenharia de sistemas.

  1. Contexto

Frequentemente, gerentes de projetos são também os gerentes técnicos dos projetos. Essa dupla função sobrecarrega o GP, que precisa não apenas possuir conhecimentos de gestão de projetos mas também conhecimentos técnicos sobre o produto e a indústria.

O envolvimento do GP nas decisões técnicas observado no contexto brasileiro é um pouco diferente do utilizado em outros países em que a engenharia de sistemas é mais desenvolvida. Nos Estados Unidos, as funções dos gerentes de projetos e dos engenheiros de sistemas são bem definidas e separadas. Há um gerente técnico, que precisa ter conhecimento do produto e dos processos de engenharia de sistemas. E há um gerente do projeto, responsável pela gestão, processos de gerenciamento de projetos, organização e planejamento.

Engenharia de sistemas é uma abordagem de engenharia colaborativa e multidisciplinar para desenvolver, evoluir e verificar uma solução sistêmica que satisfaça os stakeholders ao longo de seu ciclo de vida. (IEEE Std 1220, 1994).

O foco da engenharia de sistemas, portanto, está na camada entre os processos de gerenciamento de projetos e os processos de construção do produto, que seriam métodos, ferramentas e técnicas de engenharia nas suas disciplinas tradicionais.

engenharia-sistemas1Figura 1 – Engenharia de sistemas e gerenciamento de projetos

 

A engenharia de sistemas procura estabelecer, de maneira geral, um conjunto de melhores práticas em como definir e orientar o desenvolvimento de qualquer tipo de sistema, considerando todo o seu ciclo de vida, independentemente de quais tecnologias e engenharias serão utilizadas.

Assim como PMI possui o Guia PMBOK®, o INCOSE criou o padrão Systems Engineering Handbook – A Guide for System Life Cycle Processes and Activities. Os processos de engenharia de sistemas complementam os aspectos de gerenciamento de escopo no que tange aos processos orientados ao produto, não tratados no Guia PMBOK®.

  1. Desenvolvimento

Os processos de engenharia de sistemas são orientados a produtos, voltados para a correta identificação de necessidades e definição de requisitos. A engenharia de sistemas parte do domínio do problema para o domínio da solução, perpassando os diferentes níveis de abstração.

engenharia-sistemas2
Figura 2 – Domínio do problema e domínio da solução

 

No domínio do problema, identificam-se as necessidades e os requisitos dos stakeholders, definindo a missão e operação do sistema. O domínio da solução transforma as necessidades em requisitos de sistema para definir e detalhar o funcionamento, atributos e a arquitetura do sistema. Finalmente, a arquitetura funcional é traduzida no design detalhado dos componentes do sistema.

processo pmbok 5 trentim

Figura 3 – Processos de Gerenciamento (Adaptado do Guia PMBOK® 5a ed)

 

Os processos de engenharia de sistemas devem andar junto com os processos de gerenciamento do projeto. Na iniciação, quando temos o Termo de Abertura do Projeto e o Registro de Stakeholders, é importante definir uma especificação preliminar das necessidades que o sistema deverá satisfazer. Associando o Business Case e estudos de viabilidade à Statement of Needs, o envolvimento e suporte dos stakeholders é maior desde o início do projeto.

No grupo de processos de planejamento, enquanto trabalhamos no plano de gerenciamento do projeto, o primeiro passo é definir o escopo. O Guia PMBOK® é bastante sucinto no gerenciamento do escopo, necessitando ser complementado pelos processos de engenharia de sistemas.

A coleta de requisitos identifica as necessidades dos stakeholders, que serão analisadas pela engenharia de sistemas para derivar requisitos de alto nível dos stakeholders. Os requisitos devem ser objetivos, mensuráveis, essenciais e não voltados para implementação (implementation free). Esses requisitos de stakeholders serão avaliados por medidas de efetividade (MoEs) e devem ser aceitos, aprovados ou validados pelos stakeholders.

A partir dos requisitos dos stakeholders e das medidas de efetividade para esses requisitos, passamos ao conceito de operação do sistema (CONOPS), isto é, definição da missão do sistema, seu propósito (Mission Statement). São também identificados os cenários de uso do sistema, bem como as circunstâncias e o que é desejado nos modos de operação do sistema, para criar uma primeira definição de arquitetura operacional demonstrando as funções do sistema e seus relacionamentos externos.

Concluída a etapa inicial de definição dos requisitos de alto nível e medidas de efetividade, os engenheiros de sistemas criam requisitos de sistemas, subsistemas e componentes, mantendo a rastreabilidade com os requisitos de stakeholders.

 engenharia-sistemas4
Figura 4 – Rastreabilidade de requisitos (Hull, 2011, p. 14)

 

O gerenciamento da configuração tem por base os requisitos, de maneira que quaisquer modificações futuras no escopo serão avaliadas e rastreadas de maneira consistente. Considerando que podemos ter centenas de milhares de requisitos e especificações em diferentes níveis, fica claro que uma simples planilha de rastreabilidade de requisitos no MS-Excel não será adequada.

Para este tipo de projeto, necessitamos de softwares como IBM Doors, Smarteam e outros, que permitem realizar controle de configuração e rastreabilidade de uma grande quantidade de requisitos. A rastreabilidade dos requisitos permite realizar análises de impactos da mudança em algum requisitos e a análise da derivação ou necessidade dos requisitos de nível mais baixo.

 engenharia-sistemas5
Figura 5 – Engenharia de requisitos (Hull, 2001, p. 15)

 

O V da engenharia de sistemas (Figura 6) procura garantir a satisfação dos requisitos dos stakeholders, assegurando que o desenvolvimento do produto esteja alinhado ao longo do seu ciclo de vida. Os requisitos dos stakeholders são a base para o planejamento do escopo. Partindo de requisitos objetivos e rastreáveis que serão verificados e validados durante a execução, procura-se projetar um sistema que opere de acordo com as necessidades dos stakeholders.

 engenharia-sistemas6
Figura 6 – V da engenharia de sistemas (Fonte: Research and Innovative Technology Administration, http://www.its.dot.gov/)

 

Após definir os requisitos de stakeholders e os traduzir em requisitos de sistemas, definiremos a arquitetura do sistema (design requirements) para podermos passar para a última fase, especificações detalhadas da implementação (detailed design).

engenharia-sistemas7
Figura 7 – Processos de engenharia de sistemas por fases do projeto (Fonte: Defense Aquisition University, www.dau.mil)

 

Na Figura 7, observamos os processos de engenharia de sistemas coordenando os aspectos técnicos no gerenciamento do projeto ao longo de seu ciclo de vida. As revisões técnicas e baselines são construídas progressiva e iterativamente, provendo informações para que o plano de gerenciamento do projeto e seus planos subsidiários sejam detalhados. Assim como as revisões gerenciais do programa ou projeto, as revisões técnicas podem representar transições de fase e pontos de decisão (Go – No Go, ou kill points), como na figura a seguir.

engenharia-sistemas8
Figura 8 – Elaboração progressiva e iterativa do produto

 

  1. Processos de Engenharia de Sistemas e Fases do Ciclo de Vida do Projeto

 Os processos de engenharia de sistemas estão representados na figura a seguir de forma resumida. O ponto de partida são as necessidades dos stakeholders.

engenharia-sistemas9
Figura 9 – Processos de engenharia de sistemas (Adaptado de Loureiro, 2011)

 

A Declaração das Necessidades dos Stakeholders, ou Statement of Needs, define o problema a ser resolvido ou a oportunidade a ser aproveitada. Deve ser escrito em linguagem não técnica, expressando o que os stakeholders desejam ser capazes de fazer com o sistema.

O passo seguinte consiste na identificação dos requisitos dos stakeholders, que descrevem funções, condições e performance. Exemplos de requisitos de stakeholders:

  • O sistema deve ser capaz de transportar 10 soldados (função) em terreno arenoso categoria 5, deserto, (condição) a uma velocidade de 80 ± 10 Km/h (performance)
  • O sistema deve ser capaz de aquecer 2 litros de água (função) em condições normais de temperatura e pressão (condição) no intervalo de 10 ± 2 minutos (performance)

Observa-se que os requisitos de stakeholders acima obedecem aos seguintes critérios: específicos, completos, não ambíguos e livres de implementação. Esses critérios permitem definir claramente quais são as necessidades dos stakeholders, ao mesmo tempo que proporcionam liberdade para a definição do sistema e design dos subsistemas e componentes nos passos posteriores.

É interessante associar medidas de efetividade (MoEs) aos requisitos dos stakeholders. As MoEs indicam fatores desejados pelos stakeholders, quanto mais o sistema satisfizer aos resquisitos dos stakeholders, mais altas serão as medidas de efetividade. Uma MoE para um automóvel seria a autonomia em KM / litro de combustível para determinadas condições (terreno). MoEs estão relacionadas com disponibilidade, utilização, funcionamento e performance de parâmetros importantes para a satisfação do stakeholder.

Identificados os requisitos de stakeholders e as medidas de efetividade, a etapa seguinte consiste em definir o Conceito de Operação (CONOPS) ou cenário operacional, que resume o funcionamento do sistema e sua interação com o exterior. O CONOPS descreve a missão do sistema, seu ambiente operacional e as funções e características do sistema neste ambiente. Isto é, “o que”, “quem”, “onde”, “por que” e “quando” o sistema será utilizado ao longo do seu ciclo de vida.

O CONOPS permite propor alternativas de solução, ou seja, arquiteturas operacionais do sistema para que ele cumpra com os requisitos dos stakeholders nos cenários operacionais. Neste momento, conceitualmente, o foco muda do domínio do problema (stakeholders requirements) para o domínio da solução (system requirements).

Os requisitos dos sistemas serão definidos por engenheiros de sistemas e especialistas a partir dos requisitos dos stakeholders, mantendo a rastreabilidade e determinando como serão feitas a validação e verificação.

 engenharia-sistemas10
Figura 10 – Rastreabilidade dos requisitos ao longo do ciclo de vida (Hull, 2011, p.11)

 

Na definição dos requisitos de sistema, a preocupação é com os requisitos de alto nível e com as funções dos sistema, resultando na arquitetura funcional. Arquitetura funcional é o desdobramento do conceito operacional do ponto de vista interno do sistema, isto é, definição das funções essenciais que devem ser desempenhadas internamente pelo sistema para satisfazer os requisitos dos stakeholders.

A partir da arquitetura funcional do sistema, é possível alocar as funções em subsistemas para depois definir a arquitetura física, que determina os requisitos de subsistemas. O nível de subsistemas permite definir os requisitos e especificações dos componentes, sendo realizado por especialistas nas diferentes disciplinas de engenharia. Ou seja, o trabalho do engenheiro de sistemas é gerenciar o desenvolvimento desde os requisitos dos stakeholders até os requisitos de subsistemas, orientando o trabalho de design dos componentes e definição das especificações da equipe do projeto.

Os engenheiros de sistemas, que podem estar hierarquicamente subordinados ao engenheiro-chefe ou gerente técnico do projeto, assessoram diretamente o gerente de projetos e programas nos aspectos técnicos de desenvolvimento do sistema, devendo trabalhar em sinergia.

Todos esses processos de engenharia de sistemas ocorrem tanto no planejamento quanto na execução do projeto, de maneira iterativa e progressiva. São diferentes níveis de abstração com os requisitos correspondentes: requisitos de stakeholders, requisitos de sistemas, requisitos de subsistemas e requisitos de componentes ou especificações.

 engenharia-sistemas11
Figura 11 – Níveis de abstração do sistema e seus requisitos (Hull, 2011, p.18)

 

Os processos de engenharia de sistema complementam os processos de gerenciamento do projeto no que tange ao gerenciamento do escopo. São atividades de gestão e coordenação para o desenvolvimento do sistema, assim resumidas:

  • Coleta e análise de requisitos dos stakeholders
    • Identificação e validação dos requisitos, definição das medidas de efetividade e das medidas de performance técnica
    • Initial Technical Review (revisão técnica)
  • Elaboração da solução funcional
    • Descrição da solução funcional a partir do conceito de operação e da arquitetura operacional do sistema
    • System Requirements Review (revisão técnica)
    • System Functional Review (revisão técnica)
  • Elaboração da solução física
    • Descrição da solução física, alocação das funções, definição dos subsistemas e seus requisitos
    • Preliminary Design Review (revisão técnica)
  • Avaliação da efetividade e decisão
    • Análise e seleção das alternativas para definir a solução mais adequada e efetiva
    • Critical Design Review (revisão técnica)
    • Test Readiness Review (revisão técnica)
  • Descrição dos elementos do sistema
    • Definir especificações dos componentes (solução de engenharia para da subsistema)
    • Physical Design Audit (revisão técnica)
    • Production Readiness Review (revisão técnica)
engenharia-sistemas12
Figura 12 – Processos de gerenciamento de projetos e de engenharia de sistemas ao longo do ciclo de vida do produto

 

Na Figura 12, dividimos o projeto em quatro fases: Concepção, Design, Construção, Integração e Testes. A cada fase, os grupos de processos de gerenciamento de projetos são realizados, identificando os processos de engenharia de sistemas adequados para a referida fase. Ou seja, ao longo de todo o projeto, são realizadas atividades de gerenciamento, verificação, validação, integração, entre outros processos de engenharia de sistemas com o objetivo de coordenar todo o desenvolvimento do produto com vistas ao seu ciclo de vida como um todo. Observa-se que essas atividades estão intimamente relacionadas ao gerenciamento do projeto.

  1. Discussões e Conclusões

Engenharia de Sistemas é uma abordagem multidisciplinar que coordena o desenvolvimento de sistemas de elevada complexidade. Seu foco principal é identificar e definir, logo no início no ciclo de desenvolvimento de um sistema, as necessidades dos stakeholders, requisitos e funcionalidades requeridos. Os processos de engenharia de sistemas asseguram a rastreabilidade dos requisitos para a validação do sistema, isto é, para garantir que o sistema funcione da maneira desejada pelos stakeholders.

A Engenharia de Sistemas integra diferentes disciplinas e especialidades em uma equipe de projeto, realizando análises e trade offs tanto para questões de ordem gerencial (tempo e custo) quanto de ordem técnica com o objetivo de gerar resultados de qualidade da maneira mais eficiente possível.

Concluímos pela necessidade de incorporar os processos e melhores práticas de engenharia de sistemas nos projetos atuais, cada vez maiores e mais complexos. Neste sentido, a parceria estabelecida entre o INCOSE e o PMI une duas disciplinas complementares muito importantes para o sucesso em programas e projetos complexos.

Assim como em gerenciamento de projetos, a engenharia de sistemas possui processos, melhores práticas, ferramentas e técnicas, como definidos no Systems Engineering Handbook do INCOSE, além de outros guias e padrões na área.

Os processos de engenharia de sistemas ocorrem ao longo do ciclo de vida do projeto em diferentes níveis de profundidade para cada fase e estão intimamente relacionados com os processos de gerenciamento do projeto. Não há conflito nem sobreposição entre essas duas áreas. O gerenciamento da performance técnica, isto é, da capacidade de realizar as entregas parciais e finais satisfazendo os requisitos dos stakeholders é coordenado pelos processos de engenharia de sistema.

Gerenciamento do projeto engloba processos de gestão desde a iniciação e planejamento do projeto até as atividades de execução, controle e encerramento. Preocupa-se com a gestão de recursos, tarefas e organização do projeto. A engenharia de sistemas consiste de processos orientados ao produto, serviço ou resultado único do projeto. Isto é, processos para planejamento, definição e gerenciamento do escopo, utilizando uma abordagem sistêmica coordenada e orientada à satisfação dos stakeholders.

A engenharia de sistemas contribui para o melhor gerenciamento do projeto ao mesmo tempo em que assegura a definição correta do escopo do produto em todos os seus níveis (sistema, subsistemas e componentes), gerenciando a configuração e a rastreabilidade dos requisitos. Considerando que o escopo do produto é o que irá satisfazer os requisitos dos stakeholders, o sucesso do projeto de sistemas complexos depende das boas práticas e processos de engenharia de sistema. Todos os esforços de gerenciamento de projetos serão desperdiçados sem uma boa definição e gerenciamento do escopo, aumentando as chances de fracasso do projeto.

  1. Referências Bibliográfica

[1] BLANCHARD, Benjamin S. and Wolter J. Fabrycky, Systems Engineering and Analysis, 3rd ed. New Jersey, Prentice Hall, 1998.

[2] BUCERO, Alfonso, ENGLUNG, Randall L. Project Sponsorship: Achieving Management Commitment for Project Success. San Francisco: Jossey-Bass, 2006.

[3] CABANIS, Jeannette; DINSMORE, Paul C. The AMA Handbook of Project Management, 2nd ed. Rio de Janeiro, AMACOM, 2006.

[4] CARPINETTI, Luis; GEROLAMO, Mateus; MIGUEL, Paulo. Gestão da Qualidade ISO 9001:2008: Princípios e Requisitos. São Paulo, Atlas, 2009.

[5] CARVALHO, Marly M.; RABECHINI, Roque. Construindo Competências para Gerenciar Projetos: Teoria e Casos. São Paulo, Atlas, 2008.

[6] CLELAND, David I. Field Guide to Project Management, Second Edition. New Yor, John Wiley & Sons, 2004.

[7] COOPER, Dale; GREY, Stephen; RAYMOND, Geoffrey; WALKER, Phil. Project Risk Management Guidelines: Managing Risk in Large Projects and Complex Procurements. Ed. John Wiley & Sons, 2005.

[8] Department of Defense, Risk Management Guide for DoD Acquisition, Defense Acquisition University, 5th ed, Available at http://www.dau.mil

[9] HULL, Elizabeth. Requirements Engineering, 3rd ed. United Kingdon, Springer, 2011.

[10] IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process, The Institute of Electrical and Electronics Engineers.

[11] KERZNER, Harold. Project Management, 10th Edition. New York: John Wiley & Sons, 2009.

[12] KERZNER, Harold. Project Management: a Systems Approach to Planning, Scheduling and Controlling. New York,Van Nostrand Reinhold, 1992.

[13] LOUREIRO, Geilson. Materiais de aula CES325-4 Engenharia de Sistemas Espaciais. São José dos Campos: INPE, 2012.

[13] MERSINO, Anthony. Inteligência Emocional para Gerenciamento de Projetos. São Paulo, Makron Books, 2009.

[14] VARGAS, Ricardo V. Gerenciamento de Projetos, 7a. Edição. Rio de Janeiro, Brasport, 2009

[15] VARGAS, Ricardo V. Manual Prático de Planejamento de Projeto. Rio de Janeiro, Brasport, 2009.

[16] WALTON, Mark S. Generating Buy-In: Mastering the Language of Leadership. Nova York: AMACON, 2004.

[17] YOUNG, Ralph. The Requirements Engineering Handbook. London, Artech House, 2004.

 

Posted on 10 de junho de 2016 in Gestão Estratégica de Projetos

Share the Story

About the Author

Engenheiro e Mestre pelo ITA, possui mais de 15 anos de experiência em estratégia, inovação e projetos (http://linkedin.com/in/trentim). Vencedor do prêmio 2014 PMIEF Harold Kerzner Award. Autor dos livros "Managing Stakeholders as Clients", "Manual do MS-Project 2013 e Melhores Práticas do PMI®" e "Gerenciamento de Projetos: Guia para as Certificações PMP® e CAPM®".
Back to Top
Mantenha-se Atualizado!
.
trentim.com.br/blog

Mantenha-se Atualizado!

.

trentim.com.br/blog

 

- Conteúdo sobre gestão de portfólios, programas e projetos.

- Videos, exercícios, estudos de caso e templates exclusivos.

- Dicas sobre carreira, certificações e ferramentas. 

Parabéns! Você se cadastrou com sucesso. Verifique sua caixa de emails.

figure1 project timeline

Dominando MS-Project 2013 e

Melhores Práticas do PMI®

Conteúdos exclusivos, vídeos, exercícios e templates no seu email semanalmente.

Dominar o MS-Project nunca foi tão fácil!

Parabéns! Você se cadastrou com sucesso. Verifique sua caixa de emails.