And some relevant links include...

The NASA report about the (failed Mars mission) Mars Climate Orbiter and the ICD/ICS problem:

• https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf

About risk management in SW Development (a NASA doc) and why it is important to do it  - see next link:

• http://csse.usc.edu/csse/event/2009/UARC/material/Macro%20Risk%20Model.pdf

And some relevant links include...

About software end of life (or not, and the 400 USD billions spent):
https://en.wikipedia.org/wiki/Year_2000_problem

Mars missions and the diffcult path to Mars:
https://en.wikipedia.org/wiki/List_of_missions_to_Mars
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
https://en.wikipedia.org/wiki/Deep_Impact_(spacecraft)#Contact_lost_and_end_of_mission

NASA report on the ICD/ICS problem:
https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf

About risk management (NASA):
http://csse.usc.edu/csse/event/2009/UARC/material/Macro%20Risk%20Model.pdf

On the importance of interface specifications (ICD)

On the importance of interface specifications (doing it and then... following it). Lots of systems fail due to interfaces to external systems. What is an external system? In this context, anything where you'll have to read data from and/or export / write data to.

In some projects/markets these are mandatory deliverables (the designation and the acronym can vary): SIS (Software Interface Specification), ICS (Interface Control Specification), ICD (Interface Control Document). The interface specification can be a document by itself or part of the broader design documentation (a section of it). The advantage of having it extracted is that it is easier to share externally (you'll have to share just that part of the design with external companies and that eases up distribution issues for organizations that restrict distribution).

As per the external interfaces by themselves:
Identify all intervening external systems and specify the needed interfaces thoroughly: specify the data flows, frequency and means of communication, review and accept those documents so that all teams (persons) working for all components of the information system are aligned.


Case study / example (on the importance of interface specifications):

The Mars Climate Orbiter  is one of the many failed Mars missions. It crash landed in Mars in 1999:

• https://en.wikipedia.org/wiki/Mars_Climate_Orbiter

"The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit, contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, expected those results to be in metric units, in accordance with the SIS."

They had a spec, they just didn't read it. Or even worse, they produced contradicting documentation.



PS. The full NASA 1998 report can be found here:

• ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf

DIGEST: Recent links...

And the recent relevant links might as well be:

Glossary (GLS) article. Other terminology standards:

• http://silvaonsoftware.blogspot.pt/2016/05/standards-terminology-standards.html

Top-level QMS/SDP Docs:

• https://quality.critical.pt/qmsunified/HLP-high-level-processes/SDP1-software-development/CSW-QMS-2002-SDP-0909-software-development.pdf#search=name%3A0909
• https://quality.critical.pt/qmsunified/HLP-high-level-processes/PLC-project-life-cycles/CSW-QMS-2003-PCS-2296-project-life-cycles.pdf#search=PLC

SDP, PLC context and some things we've been talking about:

• http://silvaonsoftware.blogspot.pt/2016/05/defining-your-sdp.html
• http://silvaonsoftware.blogspot.pt/2016/05/about-qms-process-areas-documentation.html
• Phases vs. Processes "mess": http://silvaonsoftware.blogspot.pt/2016/05/the-phases-vs-processes-mess.html

AOB:

• Mars missions: https://en.wikipedia.org/wiki/List_of_missions_to_Mars
• Failed Mars Mission (ICD/ICS; Mars Climate Orbiter): https://en.wikipedia.org/wiki/Mars_Climate_Orbiter

• PPB (and PPM): https://spcorp.critical.pt/publishing/document-and-resources/148 (INTERNAL)

• A "passarada à solta": http://nainternetetal.blogspot.pt/2016/09/porque-e-que-os-passaros-nunca-colidem.html

(2017-05-17: Reformatting; PPB info)

Process: SW Design Process and its main work products

After SW Requirements (and the SW Requirements Engineering Phases ends successfully) we'll be applying the next QMS Process: ENG.2 SW Design Process. The main goal is to define "how to do" things (requirements were focused on "what to do").

Typically all design decisions (high-level-design) are written on the Software Architecture Specification (SAS) which is commonly a deliverable.

The pertinent milestone is called the Critical Design Review (CDR) unless you have provided the customer with a SAS V1 on PDR. If you did so, you'll probably end the CDR with SAS V2. If not you'll be releasing a SAS V1 apar with the code (and the binaries needed for deploying the system on a testing environment, for the next phase, the Validation Phase).
In some QMSs, some part of the design and the code are performed in the same phase (so that if you spot a need to change de design during the code, you are still able to change it).

Other Design Documents

Sometimes customers will ask for a Software Detailed Design (SDD is a kind of a programmer's manual that describes all source files contents including for an OOP language all classes, including data members, operations, interfaces and the algorithms being implemented in those source files). If possible, align the team with the proper coding conventions and comments to be produced aling the code, in order to be possible to reverse engineer te code to a modelling tool (that enables you to build in a faster way the SDD document). Sometimes this document is called Detailed Design Description.

There are also special documents called Interface Control Documents (ICD) that come specially handy when you need to establish communications (data flows in and out) with external systems. These could be described in a section in the SAS, or sent to a separated ICD document (if you want to share just the interface control part to external departments and/or companies).

Database specification documents (DBS) are also considered detailed design documents and are typically generated from data modelling tools (or reversed engineered to a model and then to a document) for publication (to the customer, to the developer/maintenance teams).

This is where you want to define key technologies to use (what DB Server, what Application Server, what OS) up to the version if needed and the last great opportunity to think on reuse (COTS components, open source components, in-house components, etc.)

Main Activities (SW Design)

Mainly we'll be doing:

• Architectural requirements (completing the requirements catalog with non-functional - or other organizational and even functional - requirements); Architectural Requirements are a subset of the user, system and software requirements, determined by architectural relevance.
• Architecture specification:
• Defining the meta-architecture options: principle, style, key-mechanisms 
• Defining the conceptual architecture: Partition system, allocate responsibilities
• Defining the logical architecture: Model collaborations, design interfaces
• Architecture Validation: As in all things in life, we'll be peer reviewing the SAS document, and before that, we'll be brain-storming key decisions and thinking on Reuse (remember to use DAR).

You can find the process definition here.
For a good online resource on architecting remember to look at the The Visual Architecting Process (VAP, by Ruth Malan and Dana Bredemeyer, 2002)