Nos posts anteriores, falei para vocês do INCOSE Brazil e da importância da engenharia de sistemas para o sucesso no gerenciamento de projetos complexos. Relembrando, os processos de gerenciamento de projetos, como os propostos no Guia PMBOK, são voltados para gestão. Ou seja, são processos focados na gestão de pessoas, recursos, comunicação, stakeholders, aquisições, organização e controle de atividades e custos etc.

Já os processos de engenharia de sistemas são orientados a produtos. Isto é, são processos preocupados com a correta identificação de necessidades e requisitos, traduzidos do domínio do problema para os diferentes níveis de requisitos e especificações no domínio da solução. Basicamente, engenharia de sistemas gerencia o escopo do produto, que vai além do projeto. A preocupação da engenharia de sistemas é todo o ciclo de vida do produto, desde sua concepção e desenvolvimento (projeto) até a sua operação e descarte.

Os processos de engenharia de sistemas (SE – Systems Engineering) 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 do sistema. Através de um Business Case e estudos de viabilidade, teremos uma idéia da necessidade dos stakeholders – Needs Statement.

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, que deve ser complementado pelos processos de engenharia de sistemas.

A coleta de requisitos deve definir as necessidades dos stakeholders (Needs Statement) que serão analisadas pela engenharia de sistemas para derivar requisitos de alto nível dos stakeholders, que 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.

Uma abordagem interessante é pensar no conceito de operação do sistema (CONOPS). O conceito de operação envolve a missão do sistema, seu propósito (Mission Statement) e os cenários de uso do sistema, bem como as circunstâncias e o que é desejado nos modos de operação do sistema.

A partir destes documentos de necessidades e requisitos de alto nível, os engenheiros de sistemas produzirão requisitos de sistema, mantendo a rastreabilidade com os requisitos de stakeholders.

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. Pode parecer um trabalho desnecessário, mas se você imaginar que podemos ter centenas de milhares de requisitos e especificações em diferentes níveis, fica claro que aquela matriz de rastreabilidade de requisitos (no MS-Excel, por exemplo) será completamente inútil.

Neste tipo de projeto, necessitamos de softwares como IBM Doors, Smarteam e outros.

Observe que as figuras anteriores estão embasadas no V da engenharia de sistemas, que basicamente prega o desenvolvimento do produto alinhado com o restante do seu ciclo de vida. Isto é, os requisitos dos stakeholders são a base, os requisitos deverão ser objetivos e rastreáveis, verificados e validados durante a construção para resultar num sistema que deve operar conforme as necessidades dos stakeholders.

Voltando aos processos de engenharia de sistemas, 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).

Simplificadamente, o processo é esse. Obviamente, na prática o esforço é muito maior. Assim como em gerenciamento de projetos, cada processo de engenharia de sistemas possui melhores práticas, ferramentas e técnicas.

Vale ressaltar que os processos de engenharia de sistemas podem ser divididos em fases do projeto. Ou seja, não é necessário concluir todo o escopo do projeto para podermos planejar as atividades (tempo) e custos, bem como os demais planos subsidiários de projetos. É aqui que a cooperação dessas duas “disciplinas” (PM e SE) pode trazer grandes ganhos a programas e projetos complexos. Muito ainda temos que avançar…

Na próxima semana, conversaremos sobre análise e tomada de decisão em projetos. Até mais!