Professional Skills 1 - Report

Topic: Computer software on which our lives depend is

said to be safety critical. What measures can we take to
minimize errors occurring in such systems?

Paul Russell

Submitted in partial fulfillment of the Profession Skills I

Module.

Student ID: 13491812

02/02/2015

Summary/Abstract
This report investigates the many different methods and techniques that are
used in software development and in system design to minimize errors in
such systems/software. There are many key elements that come into play
when developing software while at the same time eliminating the chance of
bugs or errors occurring. This report covers Continuous Integration (a widely
used software development approach), Agile Software Development with
Scrum (a framework used in software development), Risk Assessment and
Risk Management.
Continuous Integration
Paul Duvalls book Continuous Integration: Improving Software Quality with
Continuous Integration describes this method of development very precisely
and shows steps for its use in a wide variety of applications. The primary aim
of CI is to reduce risk and improve software quality of the project/system
being developed. CI is basically building the code every a time a change is
made to it, these changes are noted and if an error occurs the new code is
changed back to the most recent fully operational code that contained no
errors. CI is important because integrating software often decreases the lifespan of a defect Duvall (2007).
There are few requirements if CI is to be put into practice, the first one being
a reliable build process, such as Maven. Maven is a build automation tool
used primarily for Java projects, it holds information on how software is built
and also describes its dependencies, such as the build order and external
plug-ins. In conjunction with a build processor a Software configuration
management (SCM) system is also used. This module handles the tracks all
changes made to the software, it also has the ability to identify what went
wrong in a system and what was changed to cause the error. It does not
handle the management of source code, this is handled by a Revision Control
System (RCS). The final element of CI is the Continuous Integration Server
(CIS) such as CruiseControl. This is an automated build server where a team
of developers commit their code frequently, each integration of code is
verified by the CIS.
Duvall outlines that the use of broad software builds is essential, this is
because it will increase visibility. The code must be test before it is
committed to a build, test failure is build failure. Duvall (2007). Software
inspection is the last element of CI, it is divided up into five primary groups;
Complexity, duplication, dependencies, coding standards and code coverage.
Complexity in code means that there are more paths, therefore more cost
and it also lead to decrease in the comprehensibility of the code, making it

less flexible. Code duplication can replicate defects, shows poor design and
is not good practice. Dependencies [FINISH].
Coding standards enforce consistency, increase comprehensibility and
decrease defects due to common effect patterns Duvall (2007), and finally
code coverage, this helps identify what code has been tested and promotes
collaboration between development and quality assurance.

Scrum (Agile Software Development)

The Scrum project management framework has been used to develop
complex products since the early 1990s. It is a framework within which you
can employ various processes and techniques. It works well when used for
projects with aggressive deadlines. Scrum projects move forward via a
series of iterations called sprints, these sprints are typically two to four
weeks long.
The Scrum framework consists of a set of scrum teams and their associated
roles, scrum teams consist of five to nine people in most instances. A team
will have a product owner and ScrumMaster; the product owner is the
projects key stake holder and will represent users, customers and
developers, the product owner is often someone from the marketing sector
of a company. The ScrumMaster is the equivalent of a captain to the team,
the role of a ScrumMaster is to ensure the team is being productive as
possible.
The team work on products in the product backlog, this is a prioritized list
of features that are to be added to the software. This is not to be confused
with the sprint backlog, which is a list of features to be completed within
the sprint period. Before each sprint, a planning meeting is held, in which
the product owner outlines the fundamental items of the product/application,
the team then selects an item to work on and the tasks within that item are
transferred from the product backlog to the sprint backlog. Each day a daily
scrum is held, this is a short meeting to ensure the team stays on track, all
team members must attend. At the end of each sprint, a sprint review
meeting is held, where the team exhibit the functionality and efficiency of
the sprint. Software maybe demonstrated, and errors highlighted and
addressed at this meeting, following this, a sprint retrospective is
conducted, which includes its ScrumMaster and product owner. During this
meeting the team reflect on the forgone sprint and discuss the current
system and how improvements can be made. Cohn (2008)

Risk Assessment Matrix

A key element that is used among the majority of software development

teams is the risk matrix. This matrix is used among senior management to
increase visibility of potential risks so informed decisions can be made in
context. It consists of two axes; on the y axis is probability and on the x-axis
is the level of impact. A risk is rated for its probability and impact on a
scale to understand where on the matrix it lies. Upon being analyzed and
depending on the level of the risk, it is then moved forward into the risk
management process.

Risk Management Process

Software risk management is one of many software engineering practices
with many different methods and frameworks that can be adapted by a
software development team. It makes for positive decision-making and the
team must always be thinking of what can go wrong. There are many
different process models available for risk management but the model
developed by the Software Engineering Institute [VanScoy92][Carr93] is the
one that will be examined in this instance. There are six phases to this
model; Identify, Analyze, Plan, Track, Control and Communicate.
The first phase, identify, involves searching for, and pinpointing risk in a
project before it escalates and becomes a major defect affecting the project
as a whole. It is then time to analyze the risk data with the use of a risk
assessment matrix so that it can be processed into decision-making
information, after this stage is completed the risk information is translated to
decisions and actions being planned for both present and future. The next
stage involves tracking all risk indicators and monitoring the actions
implemented to combat risk. Following this stage is correction; the project is
inspected to confirm that there are no deviations from the risk precautions
that have been implemented. Finally, is the communication stage, this is
where the project is made visible and feedback data is provided internally
and externally on current and emerging risk activities.

Bibliography

Duvall,M.P with Matyas, S & Glover,A (2007). Continuous Integration:

Improving Software Quality and Reducing Risk. Boston, U.S.: Pearson
Education.

Department of Energy Quality Managers Software Quality Assurance

Subcommittee. (2000). Software Risk Management A Practical Guide.
Available:
http://energy.gov/sites/prod/files/cioprod/documents/Risk_Management.pdf.
Last accessed 03/02/2015
Anand Chittoor. (2013). What is a Risk Matrix?. Available:
http://network.projectmanagers.net/profiles/blogs/what-is-a-risk-matrix. Last
accessed 03/02/2015.
Michael Cohn. (2008). Scrum Overview for Agile Software Development.
Available: http://www.mountaingoatsoftware.com/agile/scrum/overview. Last
accessed 03/02/2015.