If I had mod points, I'd mod you up some more.
Any new safety critical code has to be developed with "State of the Art" techniques, which now means using a variety of fancy tools for job & bug tracking, requirements and V&V (the requirements shall be written the same way we decided 20+ years ago), design IDE (UML from the 90's), coding IDE (emacs anyone? probably not at work), static analysis for complexity metrics, coverage tools for decision and structural coverage, source control, etc. These tools then get scripted to cross reference everything. And that's just for the software portion.
At system level, you have to perform a hazard & risk analysis to determine what the potential for harm is from hazards that may be encountered during operation. If you were writing software for radiation therapy machine like the THERAC 25, you would have to identify risks, like exposure to high dose of radiation and the severity of harm, in this case potentially lethal radiation poisoning. This determines you safety integrity level, and amount of process which must be applied, in avionics it's the difference between DO-178B Levels A - E (A = plane falls from sky, E = no risk to critical systems), in automotive it's the safety integrity level SIL 0 - 3. Then you would have to define safe operation, like maximum plausible therapeutic dosage. Then from a functional perspective you would identify critical signals from sensors, data buses which carry data that feed the algorithms which control the X Ray Beam intensity and activation. It will also mandate various software integrity tasks for each component like cyclic CPU core tests, program flow control monitoring, cyclic RAM and ROM tests, stack monitoring or analysis, and trace-ability of requirements to design to code to tests, and level of independence between coders and testers. For a SIL 3 component like an electronic steering wheel, where a malfunction in steering control at highway speeds can cause multiple fatal accidents, an independent organization would be required to develop and implement the test plan based on the requirements.
Managing the development of software by teams of individuals requires much more documentation and meetings than working as a lone coder and a process in which only 10% or less of the work is actually coding, that means enough documentation for new team members so they don't have to bug the productive team members and having a work culture that strives towards excellence in ensuring mundane details like a decimal point don't kill someone. If you want to write software that does cool stuff like control the maneuvering thrusters on the SpaceX Falcon 9R for a soft ground landing, then you and maybe dozens of other people have to make sure all those mundane details are right when its the difference between landing softly at the spaceport and crashing into a major metropolitan area and exploding (or so I assume, considering I do not and have never worked for Space X). If you undertake a project like this and fail to do your due diligence and are negligent in carrying out these tasks and people die, you or your manager might easily end up in jail or your company could be fined Billions in damages like what happened to Toyota.