sábado, 27 de maio de 2017

Case Study: Schiaparelli (EXOMARS lander) failure

EXOMARS is a success (the orbiter is up and running, since 2016) but the experimental lander, failed spectacularly (and the crater where it landed was already located at Mars)... Why was that?
Because of hardware, and also of software:

"The following main weaknesses in the overall process led to the failure of the landing of Schiaparelli:
• Lack of specification and focus on a mission critical parameter from Prime to Supplier. The
persistence of the saturation flag in the application software, became the ultimate cause of the
Schiaparelli landing mishap.
• Lack of rigorous verification approach (including testing of failure/anomaly cases and
recording of closure of requirements).
• Lack of PA/QA rigorousness for acceptance of the unit"

"The following root causes for the mishap have been identified:

- Insufficient uncertainty and configuration management in the modelling of the parachute
dynamics which led to expect much lower dynamics than observed in flight;
- Inadequate persistence time of the IMU saturation flag and inadequate handling of IMU
saturation by the GNC;
- Insufficient approach to Failure Detection, Isolation and Recovery and design robustness;
- Mishap in management of subcontractors and acceptance of hardware."

Source: EXOMARS 2016 - SCHIAPARELLI ANOMALY INQUIRY
More info:
http://exploration.esa.int/mars/59176-exomars-2016-schiaparelli-anomaly-inquiry/
http://www.bbc.com/news/science-environment-40029180


PS. Kudos to A. Santos for pointing this out.

sexta-feira, 26 de maio de 2017

SW Construction | SW Testing: best practices

Here are some interesting considerations (do you agree on all of them?) about coding AND testing, with additional links to books and/or articles every good boy (read: every engineer) should read:

https://opensource.com/article/17/5/30-best-practices-software-development-and-testing

domingo, 21 de maio de 2017

BOOK: Microservices Patterns (MEAP)

Out during 2017, you can check right now the free chapter (follow the link):
https://www.manning.com/books/microservice-patterns

Quoting:
"The monolithic architecture works well for small, simple applications. However, successful applications have a habit of growing. Eventually the development team ends up in what is known as monolithic hell. All aspects of software development and deployment become painfully slow. The solution is to adopt the microservice architecture, which structures an application as a services, organized around business capabilities. This architecture accelerates software development and enables continuous delivery and deployment of complex software applications.

Microservice Patterns teaches enterprise developers and architects how to build applications with the microservice architecture. Rather than simply advocating for the use the microservice architecture, this clearly-written guide takes a balanced, pragmatic approach. You'll discover that the microservice architecture is not a silver bullet and has both benefits and drawbacks. Along the way, you'll learn a pattern language that will enable you to solve the issues that arise when using the microservice architecture. This book also teaches you how to refactor a monolithic application to a microservice architecture."

sexta-feira, 19 de maio de 2017

SW Design: Microservices and nanoservices?

What is this all about?
https://en.m.wikipedia.org/wiki/Microservices

Quoting:
"Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services.

In a microservices architecture, services should be fine-grained and the protocols should be lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring. Microservices-based architectures enable continuous delivery and deployment."
(...)
"The microservices approach is a first realisation of SOA that followed the introduction of DevOps and is becoming more popular for building continuously deployed systems."

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

Standard: Automated Quality Characteristic Measures


Quoting:
"Automated Quality Characteristic Measures for measuring the Security, Reliability, Performance Efficiency, and Maintainability of software"

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

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)

Standards: Code Quality driven by a Consortium (CISQ)?

Interesting consortium joining SEI (that developed the CMMI model) and OMG (UML and some related standards):

"Consortium of IT Software Quality (CISQ). CISQ brings together industry executives from Global 2000 IT organizations, system integrators, outsourcers, and package vendors to jointly address the challenge of standardizing the measurement of IT software quality and to promote a market-based ecosystem to support its deployments.
(...)
Jointly organized by the Software Engineering Institute (SEI) at Carnegie Mellon University and the Object Management Group (OMG), CISQ is designed to be a neutral forum in which customers and suppliers of IT application software can develop an industry-wide agenda of actions for defining, measuring, and improving IT software quality."
Source: Wikipedia

quinta-feira, 18 de maio de 2017

SW Testing: Testing activities and maybe some tools?

Ah well, testing. So good (or bad, depending on your point of view)!

Testing Activities

Testing activities (belonging to a test process) include things such as planning, specifying, executing and reporting (status). Most of you could have only executed tests (exploratory tests). This is sometimes called dynamic testing. Some methodologies will consider document and code reviews as testing also (static testing).

When we talk of the "execute tests" activity (or activities) we are talking of some common things you should be doing in order to verify (and validate, depending on the phase / goals you are trying to achieve) your software:

#1 - Unit testing,
#2 - System Testing; integration testing
#3 - Acceptance testing.

Test levels attempt to achieve different goals (by doing almost the same thing at different phases: execute tests). All test levels include executing tests (which consists of verifying that some part of the system is "OK", whatever OK means) but the focus and goals to reach, and the (sub)tasks (and toolings to use) could be completely different "beasts".

#1 are sometimes called developer tests, and ideally (if possible) are written (and executed) by the code author (developer). Could be reused in continuous integration environments (or continuous delivery).

#2 - Are used to test components after integration (HW + SW) / deployment to a pre-production environment. The focus is to test end-to-end functionality against (written, please) specifications (SRS, SAS, ICD,/ICS, DDS/SDD, ...).

#3 - Are used to make sure the customer needs were addressed; involves the customer, contractor or a(n  independent) team approved by him.

Testing Tools? 

As for tooling, you can do almost all of this without tools (you'll need at least an Office Suite for the reporting part, Excels, Words, ... unless you are willing to use hand-written paper sheets) maybe except for #1. But some tools will enhance your productivity (add you years of life) and ease up "regression testing" (i.e. making sure that a system did not regress in terms of behavior).

Good examples of tools and frameworks that you'll need to master are:
#1 - Unit testing frameworks: Think JUnit, NUNit, ... Also think on mocking behaviour with complementary frameworks (how to test your class without the "surrounding" classes?).

#2 - You'll have a (test) specification (with the test case catalog). Then you'll need a test management tool to choose subsets of it, assign them to testers (also called QA Engineers, SPA Engineers), record results (pass, fail, on-hold, etc). Note: If you have no test management tool available, use at least a spreadsheet shared with the team (configured for concurrent editing - even MS Office supports that, and it works well for small teams on a local network share). Only make sure that no passed tests are edited to failed by the concurrent edits (make frequent backups of the shared spreadsheet).

X-.Ray: If you're using JIRA for issue tracking, X-Ray could be of interest for test management. More on this below.

Still #2 - If you want to automate tests (think: "test automation"), you are writing (i.e. recording/programming) test scripts, which shall be rigorously aligned with the test specifications (that takes lots of effort to keep updated i.e. alive, so plan ahead for it).

SOAP UI: You could test automatically the business layer (data persistence issues like CRUDs, business rules) and there are tools for SOA architectures: Think SOAP UI (free and not free editions).

Robot FW: Sometimes you'll want to automate tests via the presentation layer, including (several) browser-based applications. Think on things that support several browsers, and that could allow you to record interactively the interaction, without X-Y dependencies, and to edit the resulting recorded script (to make values come from files, test databases, etc). Think Robot Framework and RIDE, which is based on Selenium.

Testing mobile apps (remotely) is yet another challenge (out of scope of this article, for now).

#3 - Acceptance testing is typically done manually (customers will want to "click" through), but it could be different. DevOps from the customer could do it - manually or any other way - on their side (and on their pre-production, production environments) before "accepting" deliveries, formally.
And we as suppliers of [deployed working] solutions could be asked by managers to execute (full) "dry runs" to make sure all specified acceptance test cases are OK as far as our teams can foresee (in our acceptance test beds, or even the customer's, if access is given to us).

If you need test automation at this test level, the same tools could be used (Robot FW, for instance).

(INTERNAL) Training

https://goo.gl/lWJ3IN - Info about Robot FW (INTERNAL, delivery)
https://goo.gl/Q4jOfc - XRay test management tool (integrated with JIRA)
https://goo.gl/TLwyqH - Training on SoapUI, testing via the service layer (INTERNAL, HR)
https://goo.gl/69nfuh - Training on Robot FW, testing via the presentation layer(s) (INTERNAL, HR)

Also, remember to... READ THE QMS PROCESS (ENG04 - Software Testing).

terça-feira, 16 de maio de 2017

Low-Code Platforms gain strength (Salesforce, Outsystems and more)

It is bespoke, but as it is so "agile" and quick to model data and functionality (to Web and Mobile) that it turns out a good solution for very dynamic and fast-paced businesses. These platforms are like Delphi / Visual Basic for the Web (technologically updated to 2017 architectures - whatever 2017 architectures are):

Reprints (from Outsystems): 

segunda-feira, 15 de maio de 2017

PT: Cursos de reorientação profissional?

(In PT, sorry English speakers, but we're sure that google can translate this for you in case of need):

Aproveitando a elevada procura de... programadores (ou será de engenheiros de software?) aparecem cada vez mais cursos de reorientação profissional, por vezes resultados de parcerias do sector privado (que precisa de engenheiros de software mas se receber bons programadores já não fica descontente) com as Universidades.
Aviso à navegação: Paga-se (bem?) e os cursos são exigentes porque tentam comprimir os currículos básicos numa fracção do tempo que leva a tirar um curso de engenharia (sem a parte das matemáticas, por exemplo, porque se um Engenheiro Civil quiser reorientar a sua carreira para a Informática já tem o background de matemática do seu curso de engenharia de origem):



quinta-feira, 11 de maio de 2017

Architecture: PaaS example (and PaaS, SaaS and IaaS compared)

As a good example of making available [software] products, one of the hypothesis is to choose an architecture that allows you to make them available as Product as a Service (more on this on the final links).

As an interesting example of PaaS products that start appearing "Here comes the sun", nemaed "Predix.io":



Quoting:
"The Cyber Security Analytics and Monitoring service receives PaaS data from various data streams.
After analysis, the data is stored and retained, so customers can query using a REST API to get their specific solution data using a multi-tenant API mechanism, ensuring the data is confidential per tenant.

Features and benefits (Predix.io)
Provides live-streaming logging (coming soon)

Helps customers identify and respond to meaningful events across security and compliance areas through one single pane of glass

Provides meaningful data, including Predix and Cloud Foundry PaaS level logs, network analysis, analytics, and monitoring in a discrete fashion, all in a multi-tenant secured environment

Produces unparalleled platform-level insights

Offers unique log and event aggregation and correlation capabilities

The service especially provides unique, meaningful information to Incidence Response and CIRT teams, allowing them to track all potential security hazards, anomalies, and applications usage.

The Cyber Security Analytics and Monitoring service assures optimum visibility when working in a microservice cloud environment, where clear security and tracking of all microservices, including customer services and platform services, are key to the solution."

PaaS, SaaS, Iaas Compared 

Google says:



Quoting (quick examples, Source: [2]):
"SaaS Examples: Google Apps, Salesforce, Workday, Concur, Citrix GoToMeeting, Cisco WebEx
Common SaaS Use-Case: Replaces traditional on-device software
Technology Analyst Examples: Bill Pray (Gartner), Amy DeMartine (Forrester)

Enterprise PaaS Examples: Apprenda
Common PaaS Use-Case: Increases developer productivity and utilization rates while also decreasing an application’s time-to-market
Technology Analyst Examples: Richard Watson (Gartner), Eric Knipp (Gartner), Yefim Natis (Gartner), Stefan Ried (Forrester), John Rymer (Forrester)

IaaS Examples: Amazon Web Services (AWS), Cisco Metapod, Microsoft Azure, Google Compute Engine (GCE), Joyent
Common IaaS Use-Case: Extends current data center infrastructure for temporary workloads (e.g. increased Christmas holiday site traffic)
Technology Analyst Examples: Kyle Hilgendorf (Gartner), Drue Reeves (Gartner), Lydia Leong (Gartner), Doug Toombs (Gartner), Gregor Petri (Gartner EU), Tiny Haynes (Gartner EU), Jeffery Hammond (Forrester), James Staten (Forrester)"



quarta-feira, 10 de maio de 2017

QMS [Management] Tools?

Not sure if I told you previously that for developing software you need a process (unless you are using the so called processes which answer by the name of "Cowboy Programming" or even the "POG, Programação Orientada à Gambiarra" - the latter is a very funny presentation in PT, google for it; sorry English speakers).

For "containing" those process definitions (and managing them) you can use a combination of tools such as CMS and productivity tools such as MS Office (to produce process documents, which contain process activities and reference to additional - documents - templates, procedures, check lists, etc). But you'll have some difficulty with traceability between those QMS elements/artifacts.
Traceability is most relevant to answer questions like: What is the impact of/What shall be updated when I update this process, task, template? Who should I notify? Who is using this process, this template? And much more. MS Word (and PDF) documents can include hyperlinks but from a bunch of them it is not easy to tell how many activities/roles/processes/et. do I have "buried" on those PDFs (for example).

So this is why you can find in the market, market for (most of them) expensive tools that allow you to manage the Process Definitions (metamodels) and, for some cases, at a second stage, allow you to perform QMS process instantiations (a specific project can be seen as a concrete instantiation of the generic definition of the QMS, tailored for the specific project). With that process instantiation feature you can have additional insight (times elapsed, next steps to be done, notifications per life cycle phase, ...), like in Business Process Management (BPM) tools.

QMS Process Management tools ideally shall support the SPEM notation (Software Process Engineering Metamodel); BPMN support only (Business Process Modeling Notation) lacks capacity of relation between some objects/concepts that are much needed for full QMS Processes Definition.

Some tools found in the market include (the list is not extensive, google for more please):

Eclipse Process Framework: https://www.eclipse.orf/epf 
Free
(RMC IBM tool includes it partially at least); some files are compatible with the RMC tool
IBM Rational Methods Composer (RMC) www.ibm.com/software/products/en/rmc
Process Management tool by IBM;
Floating and / or named user licenses possible. Payment per year. Be ready to pay ;)

With some standards already configured (unlike RMC) - standards mapping feature; allows anonymous (free) access per site (relevant for read-only users)

Process Management Tool: definition, implementation and monitoring of development and business processes; serves your digital QMS
Viewers - read-only users - also pay; Several prices (one-time) per role (Process Modeler, PM, Process User, Process     Viewer to be summed up tp payment per Server licenses: 1-5 users and other ranges; payed one time; anual fee for M&S (and updates) ~18%.
Callis www.callis.dk
Modeling and creation Web-based. Not so "extensible" as Stages; does NOT have process execution (no instantiation)
Ex-Process Engineer created the product;
Modeling done using Windows client-app. Exports the process definition to static (offline) web site.
allows SPEM but partially


These are some possible valid solutions for self-hosted QMS Management tools. If cloud based is acceptable for your organization, the offer widens. Again, google for it.

About SPEM and BPMN you can see the PDF here (valid at 2017-05-08)
About SPEM support in Sparx Systems' EA: http://www.sparxsystems.com/enterprise_architect_user_guide/10/domain_based_models/spem.html

quarta-feira, 3 de maio de 2017

And the Fresh leafy Links are... (information repositories and support tools)

The recent relevant (and mostly INTERNAL) links are indeed these ones:

- (Internal) Training resources should be shared internally; the task could be handed to HR (accumulating also with the responsibility of managing assiduity and training metrics collection - #hours of training per year, per worker). Example: https://goo.gl/Hq06W6
  • Sometimes you'll be able to access the training in editable formats, sometimes only the PDF. Sometimes you'll get the session video with audio (interesting to hear the Q&A sections or if some parts of the PPT are not self-explanatory). That's life ;)
  • A training policy shall exist (you can see it here) and a published training plan shall exist (you can see one example here).

- Project Management Information System (or systems) (PMIS):
  • Companies will use several different stacks (with the intent of managing projects and controlling them). 
  • Effort reporting is one important input for Project Controllers and for Project Managers (that will analyse EVM indicators). When possible, to save time, remember to use recurrence (PMIS/Wise, "More options | Recurrence" link). But "handle with care": Some will have no undo, no delete recurrence.
Documentation numbering: INTRA-DOC, Intradoc, IntraDoc, whatever and however they'll spell it.
It is a simple application with an important role: creating and centralizing the DOC ids that are being allocated throughout the company. The QMS Documentation Process (and several Quality Standards) requires this, and the process can be found here.

- Lessons learned (LL) database: It is a central repository of lessons learned (of type Strengths, Improvements and Weaknesses). Most of them are weaknesses. And the logic is to... learn from the past (and know for example how past projects have handled harsh situations).

It is also a QMS Process: QMS Lessons Learned Process which you can find here (and a guidebook explaining every field of a lesson learned as well as how to create them in the PMIS / WISE).

That's all. Please report any broken (INTERNAL) link.

(@2017-05-04, minor reformat and rephrases)

terça-feira, 2 de maio de 2017

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)