Software Health versus Software Quality

Achieve accountability through developer testing. Create thrust and establish a healthy relationship with your customers.

Software quality is often measured by the number of bugs remaining in the product, as an instanteneous view on the state of the system (also called external quality).

When software evolution is important we better talk about software health, look at the state of the software over time, how does it respond to stress ? when the load changes ? when the requirements changes ? when the customer base changes ? (also called internal quality)

Developer testing provides an excellent means to ensure software health. What can you do as a developer:

• Start with developer testing now. What problems can you think about, write tests for them. Think about the design, how can can you increase the testability of your code.
• continue with developer testing, also when you are under stress or don't get the neccesary support from your environment
• give frequent attention to the results, look at the numbers
• provide visibility of the software health through your test lists
• if your tests do not occasionally break, you are not testing enough
• Balance between bug fixing, refactoring, and retrofitting tests, keep the software's internal quality at a high level.
  

What does it cost:

• compared to what ? throwing your code over the wall to the testing department will cost you and your organisation a lot more time and effort
• in general developer testing would not take any longer
• reduce cost using automation tools like JUnit, CruiseControl

What are the benefits:

• fewer bugs, the improvement is substantial
• immediate feedback when something goes wrong
• enabler for other improvements, ie. continuous integration

Start with developer testing now before your software becomes terminally ill.
Listen to a one hour interview about developer testing with Kent Beck on ITConversations

ISO9126 Software Quality Attributes

ISO/IEC 9126 provides a framework for the evaluation of software quality.

It defines six software quality attributes, also called quality characteristics:

• Functionality: are the required functions available, including interoperabilithy and security
• Reliability: maturity, fault tolerance and recoverability
• Usability: how easy it is to understand, learn, operate the software system
• Efficiency: performance and resource behaviour
• Maintainability: how easy is it to modify the software
• Portability: can the software easily be transfered to another environment, including installability

Almost all these attributes are non-functional. However it is not uncommon that software requirements and testing activities are mostly focused on functionality. Problems with nonfunctional requirements detected late in the project can have a major impact on the schedule. Often significant changes have to be done on the architecture to resolve non-functional quality issues.

Use quality attributes to specify the required product quality, both for software development and software evaluation. For example select the top 3 attributes and define them Specific, Measurable, Acceptable, Realisable, and Traceable (SMART).

Do you give enough attention to the non-functional requirements of your development project, and are you using the relevant review and testing techniques to verify and validate the non-functional requirements ?

Scrum is easy, Scrum is hard

Scrum is a light weight management technique for iterative, incremental development. It produces a shippable set of functionality at the end of every iteration. Scrum is an agile process that controls the chaos of conflicting interests and needs, that improves communication and maximise co-operation, that helps in detecting and removing anything that gets in the way of developing and delivering products.

Basic concepts:
Scrum: 15 minute daily meeting. Team members respond to basics:
1. What did you do since last Scrum Meeting?
2. Do you have any obstacles?
3. What will you do before next meeting?
Product Backlog: Prioritised product features desired by the customer
Sprint: 30 day iteration at the end of which the new functionality is demonstrated
Sprint Backlog: Feature(s) assigned to sprint

Scrum can be implemented at the beginning of a project or in the middle of a project or product development effort that is in trouble.

The easy part of Scrum is to explain the benefits: achieving success every 30 days, daily status, just enough documentation and requirements to be successful.

However making the transistion can be hard: setting priorities and planning that never stops, enpower the team towards a self-directed organisation, some team members might not like Scrum, product managers might need process and documentation before starting even a daily standup scrum meeting, the sprint goal does not change during the sprint, no interruptions for 30 days.

For a 150 pages straightforward introduction to Scrum read Agile Software Development with SCRUM by Ken Schwaber, Mike Beedle.

What was your major blocking stone implementing Scrum in your organisation ?

Evaluating Open Source Software

How can you confidently determine wether the software you are considering is mature and business ready enough ?

Deciding which software package to adopt inside an organisatiion can be a challenging task. Business Readiness Rating (BRR) is a new proposed standard to facilitate assessment and adoption of Open Source Software (OSS).

The rating model weights the factors that have proven to be most important for successful deployment of OSS.

The BRR process is separated into 4 phases:

1. quick assessment: create a shortlist, filter initially through several suitable indicators: licensing, compliance with standards, referenceable adopters or users, supporting organisation, implementation language, support for internationalisation and localisation, existance of third party reviews and published books, followed by industry analysts such as Gartenr or IDC.
   
2. rank the importance criteria categories and metrics. Select metrics (measurable properties of an OSS project) defined in the 12 assessment categories Functionality, Usability, Quality, Security, Performance, Scalability, Architecture, Support, Documentation, Adoption, Community, Professionalism. Every category is rated on a scale from 1 (unaccaptable) to 5 (excellent). Only a limited number (max 7) of category ratings are used to calculate Business Readiness Rating to reflect the most essential categories of the assessment.
3. process the data. Gather data for each metric used in each category rating.
4. translate the data into the Business Readiness Rating. Use category ratings and the functional orientation weighting factors to calculate the Business Readiness Rating score. The rating is calculated by appropriately weighting a collection of category ratings according to the software's type and usage (mission-critical use, routine use, internal development, or experimentation)
   

The BRR model offers an open framework for software evaluation. BRR aims to accelerate the software evaluation process with a systematic approach, increasing confidence in high-quality open source software.

See OpenBRR.org for tutorials, samples, templates.