DIGEST: SW Construction - Further Reading

Additional Resources for SW Construction:

While building your software (aligned with the gathered requirements - SRS - and the software design that your high-level architecture defines - SAS) several additional topics are relevant. For instance: Coding standards to comply with (if any); comments to create and % of comments and eventual traceability to requirements IDs / component ID there left; static analysis to perform (and extracted KPIs to comply with - if any); continuous integration server and tasks to use; verification measures such as unit tests, code reviews. For more generic information on these topics see here.
   
For further detailed information please see the following links (some are INTERNAL).

Static Analysis: 

1. http://silvaonsoftware.blogspot.pt/2016/05/tools-source-monitor-static-analysis.html
2. http://silvaonsoftware.blogspot.pt/2016/05/tools-static-analysis-tools-listing.html
3. http://silvaonsoftware.blogspot.pt/2016/10/sw-construction-static-analysis-tools.html

Code Reviews: 

1. The QMS context (INTERNAL): Review Procedure here; Crucible Tool GBK here; CheckStyle (Java) tool GBK here.
2. Code Reviews example - Crucible (Plugin to JIRA; INTERNAL): https://crucible.critical.pt/cru/ATG-5#CFR-11408

Continuous Integration (CI):

1. About CI, a list of several servers available can be seen here: https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
2. Example - Jenkins (INTERNAL): http://jenkins.critical.pt/computer/(master)/ (INTERNAL; Teamcity could also be in use for some projects).

Unit Testing: 

1. Think "developer tests" (and see Module 9 for now; again, INTERNAL)

Further reading - Coding Standards: 

Each company might have internally defined coding standards. Or it could be using external standards (e.g. HP, NASA, ESA, etc.). Google for "C Coding Standard" and see what it is meant by coding standards here: For instance this is 1994 NASA-SEL's style guide for C (PDF).

Further reading - BOOKS: 

There are lots of books on SW Engineering that focus on best practices for coding activities, with the objective of writing clearer code, easier to understand and maintain, easier to reuse, etc. 

Two must read examples might include: 

• Clean Code - Robert C. Martin, 
• Code Complete 2 - Steve McConnell

Many more books have full chapters on writing "good" code. 

Again, "Google" and/or "Amazon" for it.

Happy readings!

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

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