SW Development: MISRA Coding Standards

An article (from a tool provider, not affiliated) on MISRA C and C++ coding standards and some example rules:

https://www.perforce.com/resources/qac/misra-c-cpp

Security: WebAuthn what?

This:

https://www.w3.org/TR/webauthn/

Quoting:
"The below use case scenarios illustrate use of two very different types of authenticators, as well as outline further scenarios. Additional scenarios, including sample code, are given later in §12 Sample Scenarios.

1.2.1. Registration

On a phone:

User navigates to example.com in a browser and signs in to an existing account using whatever method they have been using (possibly a legacy method such as a password), or creates a new account.

The phone prompts, "Do you want to register this device with example.com?"

User agrees.

The phone prompts the user for a previously configured authorization gesture (PIN, biometric, etc.); the user provides this.

Website shows message, "Registration complete."

1.2.2. Authentication

On a laptop or desktop:

User pairs their phone with the laptop or desktop via Bluetooth.

User navigates to example.com in a browser and initiates signing in.

User gets a message from the browser, "Please complete this action on your phone."

Next, on their phone:

User sees a discrete prompt or notification, "Sign in to example.com."

User selects this prompt / notification.

User is shown a list of their example.com identities, e.g., "Sign in as Alice / Sign in as Bob."

User picks an identity, is prompted for an authorization gesture (PIN, biometric, etc.) and provides this.

Now, back on the laptop:

Web page shows that the selected user is signed in, and navigates to the signed-in page. (...)"

Standards: Safety Critical what?

About safety critical and the most common standards to comply with:
"The Safety Critical technical area addresses the analysis, development, verification and validation of software and systems that are classified as either safety- or mission-critical.

Systems classified as safety-critical are those where failure may lead to personal injuries, fatalities or harmful effects to the environment. Airborne systems in aircraft and signalling systems in railway are traditionally the best-known cases of safety-critical systems. Systems controlling industrial processes in chemical, petrochemical and nuclear plants are also in this category.
Mission-critical systems are those where failure may lead to either loss or major degradation of the mission performance. Traditionally the best known cases of mission-critical systems are unmanned space missions such as telecommunications and scientific satellites, and the energy production and distribution infrastructure.
Enterprise systems in banking, retail and other industries may also be considered mission-critical though we prefer to designate them ‘business-critical’.

The services delivered by the Safety Critical technical area aggregate a set of disciplines and technology that is closely related to international safety standards. These standards are a daily reference in the work performed by the Safety Critical technical area. The most common standards used are for aerospace: ARP-4754, ARP-4761, DO-178B and DO-178C, and DO-254; for railway: EN-501216, EN-50128 and EN-50129; for space ECSS-E-ST-40C and ECSS-Q-ST-80C; for automotive the ISO 26262 and for industrial systems in general IEC 61508.

The work performed by the Safety Critical technical area is characterised by the rigour of the engineering processes. The main challenge faced is to comply with that rigour in the most economically efficient way. The projects and activities developed by the Safety Critical technical area fall into the following categories:

1. • Development of real-time embedded software in either full life-cycle, from requirements to final acceptance, or in partial life-cycle. Often the development entails close co-operation with the customer and in some cases members of the project team may work at the customer’s premises while interacting with the project team at home. The SW will typically be developed in either C or Ada and requires knowledge of real-time operating systems, microprocessor architectures and low-level communication protocols. 
2. • Verification and validation of real-time embedded software, from requirements and code reviews, to unit tests, integration and system tests. A full life-cycle embedded software development also includes V&V but this type of service is often delivered as specific projects, where we verify and validate software developed by the customer or a third party. The V&V services include not only testing software but also testing with hardware-in-the-loop. Typical tools used include VectorCAST, LDRA and bespoke validation facilities. 
3. • Development of integrated electronic systems comprising the software and the hardware that supports it. This requires competencies in both software and electronics, including the ability to procure and integrate COTS components. Typical systems developed include validation facilities with HW-in-the-loop and solutions for military C&C systems. 
4. • Functional safety assessment and reliability prediction (known as RAMS). This entails analysing the failure modes of systems using techniques such as Fault Tree Analysis (FTA) and Failure Mode Effects Analysis (FMEA). This analysis may contribute to both allocate criticalities to components and to reformulate the system design to minimise the number of critical components. 
5. Certification support to help our customers comply with safety-critical standards and training on those standards. This implies a wide body of knowledge in the technical, normative and application domain. 

Typical projects include certification support for railway signalling systems, support for airborne software and hardware certification and training on standards such as DO-178C. The work in the Safety Critical technical area requires interest in safety aspects, the ability to analyse systems as a whole, to know that there is more than just software development and, of course, good reading and writing skills."

[INTERNAL] Source: CSW-QMS-2000-CPD-0174, VERSION: 13, 2017-08-09, Annex B.

BOOK: "The Road Map to Software Engineering: A Standards-Based Guide"

Another Software Development / Software Engineering book FFR:
The Road Map to Software Engineering: A Standards-Based Guide: 9780471683629: Computer Science Books @ Amazon.com

Quoting:
"The Road Map to Software Engineering: A Standards-Based Guide organizes relevant IEEE software and systems standards using two frameworks: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. This useful guide is endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society for both practitioners and students."

Standards: NASA Technical Standards

And the family of standards for NASA - systems engineering, i.e. not only software development - can be found below (a similar roadmap to ESA ECSS standards can be found here).

https://standards.nasa.gov/nasa-technical-standards (following some links to the standards inside this link might require login)

Quoting:
"Each NASA Technical Standard is assigned to a Technical Discipline. Please select the respective link to access that discipline's standards.

0000 - Documentation and Configuration

1000 - Systems Engineering and Integration, Aerospace Environments, Celestial Mechanics

2000 - Computer Systems, Software, Information Systems

3000 - Human Factors and Health

4000 - Electrical and Electronics Systems,  Avionics/Control Systems, Optics

5000 - Structures/Mechanical Systems, Fluid Dynamics, Thermal, Propulsion, Aerodynamics

6000 - Materials and Processes, Parts

7000 - System and Subsystem Test, Analysis, Modeling, Evaluation

8000 - Safety, Quality, Reliability, Maintainability

9000 - Operations, Command, Control, Telemetry/Data Systems, Communications

Any questions on the above standards can be directed to the NTSS Curator at standards@msfc.nasa.gov"

And the relevant links are...

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

• https://en.wikipedia.org/wiki/Software_maintenance#Categories_of_maintenance_in_ISO.2FIEC_14764
• https://en.wikipedia.org/wiki/Change_request (and the various names it might get to be called: CR, SCR, CCN, ...)
• Note: ISO/IEC 14764 does not mention the term "Evolutionary Maintenance" that in a SW Maintenance contract means that there is a budget (in hours) for developing new features to the product being maintained (avoiding explicit change requests and additional contract management activities). "Predictive maintenance"is also relevant for HUMS (Health and Usage Maintenance [management] Systems)

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)
• Make sure you also read about TDD, RUP, etc.

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

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

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

Standards: The floating point standard (IEEE-754)

The standard that solved a lot of standardization problems:
https://en.m.wikipedia.org/wiki/IEEE_floating_point

http://grouper.ieee.org/groups/754/

Standards: Automated Enhancement Points (AEP) standard (CISQ)

The Automated Enhancement Points (AEP) Standard details and uses:
http://it-cisq.org/standards/automated-enhancement-points/

Quoting:
"Automated Enhancement Points is a standard measure of software size to be used in productivity analysis and the sizing of software maintenance activities. As of October 2016, the specification is an official standard of the Object Management Group® (OMG®).

The Automated Enhancement Points specification was published after the Automated Function Point (AFP)standard written by CISQ in 2013. Automated Enhancement Points improves the measurement of software size for use in productivity analysis by measuring both the functional and non-functional size of software. This is a significant advance in automated software sizing that solves problems that functional size measures have experienced in analyzing productivity during maintenance and enhancement activities.

With these two standards [AFP and AEP] for function point analysis and software sizing, organizations can:

- perform software quality and productivity analysis
- enable users to determine the ROI of an application by sizing the functionality that specifically matches the requirements of their organizations
- calibrate estimating methods against the results of past estimates
- measure and manage contracts and agreements with system integrators and outsourcers
- normalize data used in software benchmarks
- determine the size of a purchased application package (COTS or customized system) by sizing all the code included in the package"

The standard can found here: http://www.omg.org/spec/AEP/

Also make sure to read about the AFP and AQCS standards (also from CISQ).

Standards: Code Quality Standards (CISQ)

Ways of measuring objectively (and automatically) Software quality (measuring things related to non-functional quality attributes such as Maintainability) and knowing if you should act or not. Very interesting indeed:

Quoting:
"Code Quality Standards

IT organizations can use code quality standards to detect critical violations of good coding and architectural practice in software. Measure software against code quality standards at every release, e.g., measure code compliance to secure architectures, and put CISQ software quality measures into contracts with outside developers or software vendors to track to established outcomes.

Published Standards (Available for Use)

Automated Function Points (AFP) and Automated Enhancement Points (AEP) for software sizing
Automated Quality Characteristic Measures for measuring the Security, Reliability, Performance Efficiency, and Maintainability of software

Automated Quality Characteristic Measures in Detail

The nonfunctional requirements of software (Security, Reliability, Performance Efficiency, and Maintainability) can be traced to the most damaging of security breaches and system failures and are at the core of code quality standards and recommendations. CISQ Quality Characteristic Measures are consistent with ISO/IEC 25010 definition. The measures are designed to be automated on source code to identify critical vulnerabilities in the software that are severe enough that they need to be fixed. Combined with a sizing measure, a density metric is produced for each quality characteristic. Thresholds can be set for each characteristic.

The CISQ Quality Characteristic Measures cover eighty-six well-established software engineering rules to ensure secure, reliable, efficient and easy to maintain software. The following table shows a snapshot of software engineering rules contained in the measurement of each quality characteristic at the unit level and system level."

More details (and source): http://it-cisq.org/standards/

Standards: Automated Function Point (AFP) Specification (from CISQ)

The beauty of standards continues: Now (some years ago, in fact), a standard for counting function points (which is a measure of "size" of software source code):

"AFP provides a standard for automating the popular Function Point measure according to the counting guidelines of the International Function Point User Group (IFPUG). AFP provides a standard for automating the popular Function Point measure according to the counting guidelines of the International Function Point User Group (IFPUG). While there are several automated counters available in the market, there has never been a standard that ensures they are all counting the same way."

OMG has adopted it (in 2013 ;):

"The announcement by OMG of a specification for [AFP] counting should dramatically expand the use of Function Points for sizing IT applications," stated Dr. Bill Curtis, Director, CISQ. "By dramatically reducing the cost of counting and eliminating the problem of inconsistency among manual counters, automated Function Point measurement can become a standard component of the software development and maintenance process."

Source: http://www.omg.org/news/releases/pr2013/01-17-13.htm

The standard can be found here: http://www.omg.org/spec/AFP/

Also be sure to check the AEP and the ACQS (also from CISQ)

What's AQAP and what and when should you know about their standards?

The Short Story

The Allied Quality Assurance Publications (AQAP) publishes some standards that are freely available (which you might now know but is uncommon, because standards are - in some cases - also a business). As you might have already noticed, the focus is on QA of systems (be it hardware systems or software systems).

Example:
Standard: NATO - AQAP-2110 - NATO QUALITY ASSURANCE REQUIREMENTS FOR DESIGN, DEVELOPMENT AND PRODUCTION

If you intend to work for NATO, or for the defence sector (navy, air force, and so on), you have to know them. If your company is to be contracted by NATO, you'll have to have your company certified in some of them. "Vague enough"? If so, you'll have to learn more on the subject.

The Long Story

Quoting Wikipedia (as per 2017-05-02):
"The Allied Quality Assurance Publications (AQAP) are standards for quality assurance systems that have been developed by NATO. The aim of the AQAP agreement is to define standards for Quality Assurance of defence products. These standards are an integral part of contracts awarded in the military field involving NATO member countries. AQAP documents are therefore important to contractors and companies wanting to bid for such contracts.

The AQAP system is described in STANAG 4107 issued by the NATO Standardization Agency. There are currently two main types of AQAP documents; Contractual Type which are written as a Technical Specification intended for contractual use; and Guidance Type which provide general guidance."

List of current publications (standards)

• AQAP 160 NATO Integrated Quality Requirements for Software throughout the Life Cycle
• AQAP 169 NATO Guidance on the Use of AQAP 160 Ed.1
• AQAP 2000 NATO Policy on an Integrated Systems Approach to Quality through the Life Cycle
• AQAP 2009 NATO Guidance on the Use of the AQAP 2000 Series
• AQAP 2050 NATO Project Assessment Model
• AQAP 2070 NATO Mutual Government Quality Assurance (GQA) Process
• AQAP 2105 NATO Requirements for Deliverable Quality Plans
• AQAP 2110 NATO Quality Assurance Requirements for Design, Development and Production
• AQAP 2120 NATO Quality Assurance Requirements for Production
• AQAP 2130 NATO Quality Assurance Requirements for Inspection and Test
• AQAP 2131 NATO Quality Assurance Requirements for Final Inspection
• AQAP 2210 NATO Supplementary Software Quality Assurance Requirements to AQAP 2110
• AQAP 2310 NATO Quality Management System Requirements for Aviation, Space and Defence Suppliers (Source: Wikipedia)

Note: AQAP-150 was superseeded by AQAP-2210. Note the "Inactive" status in the previous link.

(@2017-05-09: Added reference to deprecation of AQAP-150, and hyperlinks to 2110 and 2210)

What is the ECSS and what are all those standards about (Roadmap)?

The Short Story

ECSS is the european standards organization for space activities. Follow the link for further details.
Amongst other things they produce... Standards.

If you know some of them, maybe this picture will suffice you (Source: ESA):

The Long Story

Space product development is (as you might know) a demanding area for hardware. As it is for software. ECSS was created to standardize space product development. The standards under ECSS superseeded the PSSs and now abound, i.e. they might confuse you; ECSS-M, ECSS-Q, ECSS-E, ...

So here are two quick intros (roadmaps) to the ESA standards:

• http://www.ecss.nl/wp-content/uploads/2016/09/ECSS-Training-L1(2017-03-14).pdf
• http://www.esa.int/esapub/bulletin/bullet111/chapter21_bul111.pdf

Product Design / System Engineering and the importance of standards - Samsung Galaxy Note 7

A very interesting article on product / system engineering / design and the importance of [international safety] standards.
From the Wall Street Journal:
http://www.wsj.com/articles/what-samsung-must-do-to-win-back-our-trust-1476218021?tesla=y

Read on and be appalled:
- There is no mandatory safety standard (in the US, in the EU) for mobile devices and since things could really catch fire (for instance on a plane) maybe there should be
- Sometimes the standards do exist but are not mandatory
- For some countries who deems a component or a phone all together suitable for a certain purpose is the company that produces it (really?)
- Components are subcontracted and due tot the secrecy involved (trade secrets are... secret), one company might not know what exactly is incorporating into its design (e.g. Batteries are certified / labeled by other companies; are all suppliers the same? Are all lots the same?)
- The problems can either come from hardware, or software but in the end, it doesn't really matter. Sometimes the recall chain is not giving you/collecting you the much needed information which is input for rework. This was a problem for Samsung (in the US) because it does not have a distribution chain in the US unlike Apple
- A compliance statements (the CE marking for instance) is just a statement by the manufacturer indicating they [think they] are compliant. Nobody checks it [before going into market - of course it will be checked after "something" goes wrong]. In fact most of the times there are no requirements for compliance testing (which is a different and safer thing, because some independent entity is analysing your work product)
- The fact that there is no word for re-recall: Because it rarely happens at such a scale, Samsung stopped the production (!). Nobody would trust on a recall of the recall. How many recalls would it take for Samsung to produce something that works properly as most products work (in terms of catching fire)?

The bottom line:
- Samsung shares are going down. There's talks of 15 K M EUR of losses.
- But worst than that: There's the image / reputation thing... Once lost it typically is like... Virginity.

So what do you think on the lack of process (and international standards) on product
/ system design? Is it a bore or is it much needed? We carry those things on the pocket of our trousers. Into planes. We are giving it to our kids...

DIGEST: Freshly linked...

And the relevant links (besides the Márcias talk and the José Cid beautiful photo - that should work as a reminder for always locking your machine before leaving it unattended) are:

- QMS Portal: http://quality.critical.pt (look at QMS Unified, Alignment status, Change log, Standards Repository, Tutorials, and more).

- As for Tutorials (see link above), search tips include the use of search specifiers and the use of minus for exclusion:

For instance, if you type "name:GBK -name:CSWT filetype:pdf" in the QMS Portal and execute the search you'll quickly find a list of all QMS guidebooks (respecting the naming convention for guidebooks and not coming from UK).

- About standards, and namely the two it is recommended that you perform a scan read (NASA and ECSS): http://silvaonsoftware.blogspot.pt/2016/05/the-beauty-of-standards-and-more.html

Portal informativo sobre a ISO27001 (Information Security)

Portal informativo sobre a ISO27001 (Information Security):

• https://www.27001.pt/ (disponibilizado pela https://labs.integrity.pt/ que presta serviços nesta área)

Citando:
"A norma ISO 27001 é o padrão e a referência Internacional para a gestão da Segurança da informação, assim como a ISO 9001 é a referência Internacional para a certificação de gestão em Qualidade.

A norma ISO 27001 tem vindo, de forma continuada, a ser melhorada ao longo dos anos e deriva de um conjunto anterior de normas, nomeadamente a ISO 27001 e a BS7799 (British Standards). A sua origem remota na realidade a um documento publicado em 1992 por um departamento do governo Britânico que estabelecia um código de práticas relativas à gestão da Segurança da Informação. "

About QMS Process Areas, Documentation Levels and the Software Development Process (SDP)

The Short Story

• The Top Level Docs of a QMS, e.g. the QM
• How to subdivide Areas into Process Areas? By defining Key Process Areas in a QMS (acc. ISO15504 for instance). Details about Process Areas.  
• Documentation levels: QMS artifacts range from the top-level ones (referred above) to the more detailed ones. How could documentation levels be defined?
• And last but not least: How to define your SDP?

The Long Story...

... Can be read following the above links and reading the SDP process document.

Key Process Areas in your QMS (ISO 15504, ISO 12207)

In a QMS several types of processes will be needed in order to accomplish your work. 

For a software development company, lots of core processes will be defined (engineering ones) but they are not enough. In the end you'll end with dozens of processes so it's a good idea to organize them in order to allow for some roles (e.g. engineers, project managers) not to get lost while starting. 

So, one of the main issues here is how to do this split between them? Again the main keyword is REUSE. Let's not invent the wheel. 

The key process areas in a Quality Management System can be based on the ISO15504/SPICE process model as well as the ISO12207 Life Cycle Model standards.

According to SPiCE for SPACE (ISO/IEC TR 15504 Conformant Method for the Assessment of Space Software Processes - Part A: SPiCE for SPACE Assessment Model, Issue 1.1 Draft C, 27.07.01, PASCON/WO6-CCN5/TN7A.) the following description is provided for each dimension:

Primary life cycle processes, includes customer-supplier processes and engineering processes. Customer-supplier processes have directly impact on the customer, support development and transition of the software to the customer, and provide for the correct operation and use of the software product and/or service. Engineering processes consists of processes that directly specify, implement, or maintain the software product, its relation to the system, and its customer documentation. In circumstances where the system is composed totally of software, the engineering processes deal only with the construction and maintenance of such software.

Supporting life cycle processes, includes processes that may be employed by any of the other processes (including other supporting processes) at various points in the software life cycle.

Organisation life cycle processes, includes management and organisation processes. Management processes contain practices of a generic nature that may be used by anyone who manages any type of project or process within a software life cycle. Organisation processes establish the business goals of the organisation and manage process, product, and resource assets that, when used by the projects in the organisation, will help the organisation achieve its business goals.

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