During the postportem of a critical bug into IBC we learned that changes
introduced to meet user needs interacted with (underspecified) components to
open up essential security vulnerabilities. We need a method for rationalize and
hardening the process of change management.
Approaches
Register implmementation units with “unit owners”
When a tagged implementation unit is changed in a PR it should automatically
tag a “unit owner” (analog of “code owners”) for review.
Traditionally, change impact analysis has been viewed as an area in traditional
software en-gineering. Software artifacts (source code, usually) are modified
in response to a change in userrequirements. Aside from making sure that the
changes are inherently correct (testing and ver-ification), programmers
(software engineers) need to make sure that the introduced changes arecoherent
with those parts of the systems that were not affected by the artifact
modification. Thelatter is generally achieved by establishing adependency
relationbetween software artifacts. Inrough lines, the process of change
management consists of projecting the transitive closure of thethis dependency
relation based on the set of artifacts that have actually changed and assessing
howthe related artifacts changed.
TRC-REV.1::INC.1::TOOL.1
During the postportem of a critical bug into IBC we learned that changes introduced to meet user needs interacted with (underspecified) components to open up essential security vulnerabilities. We need a method for rationalize and hardening the process of change management.
Approaches
Register implmementation units with “unit owners”
References
Perpetual Requirement Engineering: