BOOK: NASA Systems Engineering Handbook, NASA - Amazon.com

Rev1 of SEBoK from NASA (caution, there is a Rev2 and the PDF can be found at NASA sites):

NASA Systems Engineering Handbook, NASA - Amazon.com

Quoting:
"This handbook consists of six core chapters: (1) systems engineering fundamentals discussion, (2) the NASA program/project life cycles, (3) systems engineering processes to get from a concept to a design, (4) systems engineering processes to get from a design to a final product,(5) crosscutting management processes in systems engineering,and (6) special topics relative to systems engineering. These core chapters are supplemented by appendices that provide outlines, examples, and further information to illustrate topics in the core chapters. The handbook makes extensive use of boxes and figures to define, refine, illustrate, and extend concepts in the core chapters without diverting the reader from the main information. The handbook provides top-level guidelines for good systems engineering practices; it is not intended in any way to be a directive."


PDF version: https://www.nasa.gov/feature/release-of-revision-to-the-nasa-systems-engineering-handbook-sp-2016-6105-rev-2

SPACE: TESS architecture and SW image processing made

Due to bandwidth limitations, heavy processing of the high res images taken is made at space and only relevant results are sent back. Here is an interesting description of the new NASA's TESS mission (now that the Kepler mission is being phased out due to lack of fuel) that has the goal of finding new exoplanets:
https://arstechnica.com/science/2018/09/get-ready-for-a-flood-of-new-exoplanets-tess-has-already-spotted-two/

Quoting:
"TESS images a single area for roughly a month before moving on to the next. Over the course of a year, this will allow it to capture most of the sky in a single hemisphere; it will switch to the other hemisphere for its second year of observations. Should the hardware still be operational at the two-year mark, it will have imaged most of the sky, and a similar cycle will likely start again.

This cadence creates some trade offs. If a planet's orbit is such that it doesn't pass in front of its star during the month TESS happens to be pointing that way, we'll miss it (unless it's part of the small overlap between separate areas). This will bias us toward finding planets with short orbital periods, where a transit is guaranteed to happen whenever TESS gets around to pointing at it. Short enough orbits mean we can observe multiple transits during that month, confirming the planet's existence without the need for follow-on observations."

Configuration Management: NASA finds lost mission (IMAGE satellite)...

NASA finds lost IMAGE satellite thanks to an amateur astronomer and is not sure that communications will be possible (configuration management issue?):

• https://www.theregister.co.uk/2018/01/30/zombie_satellite_is_image/

Quoting:

"NASA finds satellite, realises it has lost the software and kit that talk to it. Vanished IMAGE now found. Don't suppose anyone kept a copy of its comms code?" 

(...)

"The Goddard boffins next need to undertake what the agency called “significant reverse-engineering” to capture and analyse data from the signal.

“The challenge to decoding the signal is primarily technical,” the announcement said. “The types of hardware and operating systems used in the IMAGE Mission Operations Centre no longer exist, and other systems have been updated several versions beyond what they were at the time”.

If NASA can decode data from the satellite, it will then try to turn on the science payload “to understand the status of the various science instruments”, and make a decision about IMAGE's future."

Update (2018-01-31) - Additional source for the same news:

• https://www.engadget.com/2018/01/31/nasa-makes-contact-with-satellite-lost-in-space-13-years-ago

STANDARDS: Recommended approach to software development, revision 3 : Landis, Linda : Free Download & Streaming : Internet Archive

The NASA JPL recommended approach to SW development (PDF) is "oldie but goldie" and stated as consistent with NASA/GSFC standards:

Recommended approach to software development, revision 3 : Landis, Linda : Free Download & Streaming : Internet Archive

Quoting:
"Guidelines for an organized, disciplined approach to software development that is based on studies conducted by the Software Engineering Laboratory (SEL) since 1976 are presented.

It describes methods and practices for each phase of a software development life cycle that starts with requirements definition and ends with acceptance testing.

For each defined life cycle phase, guidelines for the development process and its management, and for the products produced and their reviews are presented.

Documentid 19930009672"

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

And some relevant links include...

About SDP and life cycles (some not widely used nowadays): 

• https://en.wikipedia.org/wiki/Software_development_process
• https://en.wikipedia.org/wiki/Spiral_model
• https://en.wikipedia.org/wiki/Extreme_programming
• https://en.wikipedia.org/wiki/V-Model_(software_development)
• https://en.wikipedia.org/wiki/Change_request

Make sure you also read about TDD, RUP, etc.

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 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

Maintenance categories (applicable to SW development, of course):

• https://en.wikipedia.org/wiki/Software_maintenance#Categories_of_maintenance_in_ISO.2FIEC_14764

ENG QMS Process example (for TOC analysis, INTERNAL):

• https://quality.critical.pt/qmsunified/ENG-engineering/ENG01-requirements-analysis/CSW-QMS-2005-PCS-3424-requirements-analysis.pdf#search=eng01

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

Voyager 1 and 2 still operating

Two top examples of good (redundant but not only) design and coding:
https://www.nasa.gov/press-release/nasa-s-voyager-spacecraft-still-reaching-for-the-stars-after-40-years

Quoting:
"Because the Voyagers' power decreases by four watts per year, engineers are learning how to operate the spacecraft under ever-tighter power constraints. And to maximize the Voyagers' lifespans, they also have to consult documents written decade’s earlier describing commands and software, in addition to the expertise of former Voyager engineers.

"The technology is many generations old, and it takes someone with 1970s design experience to understand how the spacecraft operate and what updates can be made to permit them to continue operating today and into the future," said Suzanne Dodd, Voyager project manager based at NASA's Jet Propulsion Laboratory (JPL) in Pasadena, California.

Team members estimate they will have to turn off the last science instrument by 2030. However, even after the spacecraft go silent, they’ll continue on their trajectories at their present speed of more than 30,000 mph (48,280 kilometers per hour), completing an orbit within the Milky Way every 225 million years.

The Voyager spacecraft were built by JPL, which continues to operate both. The Voyager missions are part of the NASA Heliophysics System Observatory, sponsored by the Heliophysics Division of SMD."

Into NASA coding philosophy

Some additional insights on NASA and the highly reliable code that it produces:
https://mystudentvoices.com/a-look-into-nasas-coding-philosophy-b747957c7f8a

Quoting:
"With some years of work there, I wish to provide a first-hand account on the philosophy that’s allowed the space agency to produce some of the world’s most reliable software, and I’ll frame their attitude towards programming with a set of four assumptions I think they make for programmers in the workforce (and which I have experienced directly.)"

SW Construction: Let's do it like they do it on space? | NASA Coding Conventions

So I remembered that some (oldie but for sure goldie) coding conventions are freely available from NASA JPL, several languages available:
https://www.google.pt/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=nasa%20jpl%20coding%20standards

FFR. But meanwhile you can start applying it (and doing "IT" like they do it on - i,e. for - space)

3 articles involving NASA and NASA-SEL (software engineeering & process improvement)

3 interesting articles on NASA and the NASA Software Engineering Laboratory (NASA-SEL). Final links are 2 clicks away (sorry I am grouping this info here):

1. Rise and fall of the NASA-SEL (about process improvement and some pitfalls during the implementation): http://silvaonsoftware.blogspot.pt/2016/08/ieee-xplore-abstract-lessons-learned.html
2. The code of the Apollo 11 mission (man on the moon mission) was retyped, filled in and published on Github (!): http://everything-techie-under-the-sun.blogspot.pt/2016/07/the-code-that-took-america-to-moon-was.html (this one explains the BURN BABY BURN routine and much more).
3. And some history on the alarms it raised during the mission: http://silvaonsoftware.blogspot.pt/2016/08/apollo-11-lunar-surface-journal-program.html
4. A video of the emulator working: https://www.youtube.com/watch?v=hyhI85Rd1kI

Updated: 2018-04-03, emulator video.

IEEE Xplore Abstract - Lessons learned from 25 years of process improvement: the rise and fall of the NASA-SEL

Interesting article on NASA Software Engineering Laboratory (NASA-SEL):

IEEE Xplore Abstract - Lessons learned from 25 years of process improvement: the rise and fall of the NASA software enginee...

Abstract:

"Lessons learned from 25 years of process improvement: The Rise and Fall of the NASA Software Engineering Laboratory. For 25 years the NASA/GSFC Software Engineering Laboratory (SEL) has been a major resource in software process improvement activities. But due to a changing climate at NASA, agency reorganization, and budget cuts, the SEL has lost much of its impact. In this paper we describe the history of the SEL and give some lessons learned on what we did right, what we did wrong, and what others can learn from our experiences. We briefly describe the research that was conducted by the SEL, describe how we evolved our understanding of software process improvement, and provide a set of lessons learned and hypotheses that should enable future groups to learn from and improve on our quarter century of experiences."

PDF: https://www.cs.umd.edu/~basili/publications/proceedings/P94.pdf

Apollo 11 Lunar Surface Journal: Program Alarms (That Occurred During the Mission)

Interesting insights on the Apollo 11 Mission (that took the man to the moon, now that the code was published as it was pointed out), the computer architecture and the assembly programming language that was used with it and some program alarms that it raised during the mission:

• Apollo 11 Lunar Surface Journal: Program Alarms

Defining your SDP

When defining your Software Development Process (SDP) where should you start?

First of all, if you can, don't define it. But most of the times you'll have to (to introduce your company's specifics and to allow for easier alignment of large teams).

So where should you start? From scratch?
No, it is suggested that you find whatever the industry states regarding the processes you are interested in and build upon it, using these standards as Reference Documents.

E.g.: If you're working for space, does it make sense to build your own SDP from scratch? Absolutely not. Above all, companies working on such mature markets will have to comply to standards, and some of those standards are related to software development, so you should start using them.
It'll save you time getting certifications, being certified by suppliers that might want to check how do you develop software (and perform other types of activities such as project management) before hiring you, etc.

So, you should definitely start by reading, understanding and using things like:

- ECSS (ESA standards), NASA-SEL (NASA standards): http://silvaonsoftware.blogspot.pt/2016/05/the-beauty-of-standards-and-more.html

For life cycles you have ISO 12207: http://silvaonsoftware.blogspot.pt/2016/04/standard-isoiec-12207-systems-and.html

For tailoring you have CMU/SEI-94-TR-024 and more: http://silvaonsoftware.blogspot.pt/2016/05/tailoring-in-your-sdp.html

For terminology you have also additional standards: http://silvaonsoftware.blogspot.pt/2016/05/standards-terminology-standards.html

So, for all reasons in the world you'll be doing... REUSE.

The beauty of standards (and more)

Ah! The beauty of [software engineering] standards... Software engineering standards come in all kinds of shapes and colors like Victoria's Secret bras... Some standards are new but there are also good old standards that stood the test of time. On the darker side, the "standards industry" is well... an industry. If I build a better standard, certification, etc. I am able to sell you standard documents, certifications, training programs for training tutors, training sessions for people on companies and so on.
Standards people are also strange people. They can gather all together in a 5 story building for several months in a row to discuss a certain rephrase to this section of the standard. I know a person that has its name in the DO-178C draft. Not me.

If you're into the software engineering scene, maybe you can find interesting to browse these 2 space software standards:

• ESA: https://goo.gl/4Gzdtq (ECSS stands for European Comitee for Space Standardization - INTERNAL)
• NASA: https://goo.gl/wzJ8XE (SEL stands for Software Engineering Lab - INTERNAL)

Happy "readings".

Milestone meetings and Milestone Reports (Waterfall)

Waterfall uses milestones at the end of phases as a formal moment to mark the closure that phase.

Milestone Meetings

Every milestone must have milestone meetings. Some milestones have internal meetings as well as the external (i.e. with the customer) meetings. External milestone meetings typically involve several customer stakeholders for a large period of time (half a day, a full day or even more, depending on the agenda and on the complexity of the project). External meetings can involve travel to the customer premises (to Cannes or wherever the customer is located, which could be "nice").

Each milestone meeting has a specific agenda, but typically will involve overviewing the work performed in the current phase, performing a walk-through of some deliverable documents, presenting some statistics on the work thas has been performed, making clear whatever open issues that were still left unclosed and a final special moment where the customer confirms that it's ok to move to the next phase (that statement should be present in the meeting minutes, by the way).

Typically it is a good idea that the QMS has some kind of guide to help the (project) management team as well as the rest of the team preparing the milestone meeting. Here's an example in the format of a "Project Life Cycle Milestone Meetings Guidebook" (internal) :

• https://quality.critical.pt/QMS%20PT/MAN-management/MAN-01-project-management/CSW-QMS-2009-GBK-03894-project-milestones-meetings.pdf#search=milestone%20meeting%20gbk
• Details on a possible TOC can be found here. 

Milestone Reports

As a result of a successful milestone being achieved, a milestone meeting report is produced (and this is typically the exit criteria of the phases - the existence of an approved milestone review report by the customer).

This NASA document has example TOCs for those reports (and much more):

• https://quality.critical.pt/orgstandards/nasa/nasa-sel/software-management-handbook.pdf

Example of those deliverables are: 

• PDR Report (Preliminary Design Review Report)
• CDR Report (Critical Design Review Report)
• QR Report (Qualification Review Report)
• AR Report (Acceptance Review Report)

(2016-05-05: added URL for MM GBK possible TOC)