There are many measures of the success of a software development project, the most
common are perhaps: delivery on time, delivery on budget and
delivering a system that actually does what the customer
requires. Each of these can be controlled, to a greater or
lesser extent, by a good software development process (such as MSM's
Quality Solved, quality management system). A good,
structured process is the first step to achieving successful
software project delivery and defines procedures and guidance on
what to do at each stage of the project and what to do in the event
of unforeseen circumstances. This not only helps manage risk
but also provides mechanisms for controlling project scope and
managing change - one of the key factors of successful delivery and
failure.
However, in many software development processes there is
often a 'black box' in the middle called 'Development' where the
process ceases to have control - influence yes and management of
the surrounding inputs and outputs definitely - but the actual
activity inside the 'box' is largely left in the hands of the
development team. This document examines some of the
techniques and practices employed in the 'black box' by MSM and governed by the
Quality Solved system, that ensure that the solution that is
delivered is on time and budget and to specification, this is
actually a quality artefact in itself.
What makes a system a quality system?
So we have an established, tried and tested software development process that has
enabled us to capture exactly what the client requires; but what
controls are in place to ensure the system is being written to a
high quality standard? How can the management team and
customers know that they have a quality system 'under the
hood'? Firstly it helps to define some key characteristics of
a quality software system.
- Low rates of failure - ideally there should be no failures but
in the real world there will always be situations where a system
may not perform as expected, as well as the possibility of coding
errors ('bugs').
- Ease of maintenance - in a fast changing business environment
there will always be new requirements for a system and those that
make it to the development stage will usually need to be
implemented quickly and as cost-effectively as possible. A
badly written system will take longer to change and have the
increased possibility of a change breaking other parts of the
system.
How then can we ensure then that our system will have low rates
of failure and be easy to maintain?
Ease of Maintenance
Ease of maintenance can be achieved by following defined
standards and guidelines in code style and system design. By
ensuring developers follow these then systems take on a degree of
commonality that enables new developers working on a system for the
first time to easily understand the function and purpose of the
code. Perhaps the key to quality software production is
knowledge sharing - by sharing how to solve particular problems and
which are the best patterns and practices to follow, common
solutions can be put in place and a great deal of time, effort and
cost can be saved. MSM recognise and support this knowledge sharing
ideal by providing an internal development knowledge base system
used and contributed to regularly by the entire development
team. The company also develops and maintains its own
development standards, which are subject to the Continuous
Improvement aspect of the overall
Quality Solved system.
Technology is another area that can be applied to ease
maintenance. By using established technologies such as
Microsoft's .NET framework and associated products, the company can
take advantage of the wide range of tools available for managing
and developing systems in those technologies. This means
little or no learning curve for software professionals usually
already familiar with such tools and therefore almost instant
productivity when starting work on a system, be it new development
or maintenance of an existing system.
Rates of Failure
What about low rates of failure? Traditionally a software development process defines a
quality control stage whereby the system is assessed for compliance
to specification and tested for defect. This function of
quality control is a key aspect of Quality Solved. To be most
effective this function should be carried out by experienced
persons who were not the developers of the system, as developers
are usually not best placed to see the error of their ways!
At MSM a
dedicated team of Software Test professionals perform the quality
control function in accordance to the Quality Solved process.
But this is outside of the 'black box' after a system has been
created or modified, so is there anything that can be done within
the 'box' to mitigate the number of failures that may occur?
Can we, in effect, build quality in?
As mentioned already, use of established design patterns and
knowledge sharing can go a good way in ensuring tried and tested
approaches are used in a system and help reduce the probability of
failure. However, each system has its own set of requirements
and presents its own unique set of challenges and scenarios.
To ensure compliance to requirements a series of tests need to be
carried out to verify each requirement is met and the system can
perform correctly in each scenario. For maximum accuracy
every area of code should be tested, down to the smallest area or
'unit' - hence the widely used term 'Unit Testing'.
Traditionally this unit testing is performed manually by developers
('debugging'), but over the past few years there has been a growing
trend to apply a Test-Driven Development (TDD) methodology to
software development projects. This methodology prescribes
the writing of the unit tests in code form so that they can be run
automatically and repeatedly to test the system. The coding
of unit tests has several advantages: firstly the accumulation of
unit tests during a development project provides a repeatable suite
of tests that can be run automatically at any point to verify the
components of a system are behaving as required. The impact
of future changes can be quickly assessed by checking if the
changes cause any of the unit tests to fail - an invaluable
advantage in a large system where extensive manual testing can be
costly in terms of time and money. Secondly, the TDD
methodology requires a different approach to development that
enforces adherence to good practice design patterns; this
effectively means building quality in. With developers
building quality in and testing all aspects of a system in detail
as they go, the probability of a high failure rate outside of the
'box' is greatly reduced. TDD is a practice endorsed by MSM's
QualitySolved system and helps deliver quality software time after
time.
Conclusion
MSM's Quality Solved system aims to deliver quality software, on
time and on budget and currently achieves this aim in 98% of
projects undertaken. By applying best practices in project
management and software development, MSM can produce high quality
systems rapidly that provide a faster return on investment for its
customers.