|
What’s New ? |
O X F O R D
S O F T W A R E E N
G I N E E R I N G |
|
What’s New PODS Products & Services Library Presentations & Papers Related Sites Events History Clients |
|
|
|
|
|
|
|
|
As well as funded work and tool support we
have several internal projects and other events that may be of interest to
software developers and the SPI community. This page lists some of our activities
and interests. Contact us at info@osel.co.uk if
you would like to know more about these.
|
|
|
|
|
|
|
|
|
|
26 May 2009: The Ten Rules of Software Process
Improvement
Recently we have
been involved in several discussions where people (including us) have
expressed discontent and concern about the current state of software process
improvement (SPI). It has prompted the drafting of a list to capture the
essence of ‘good’ SPI. Our list of rules looks like this at the moment: In no
particular order…. 1. Improvements are owned by those affected
by them. 2. Focus on
fixing real problems getting in the way of business goals - if you aren't
have a d****d good reason. 3. Require
rapid feedback (results) on the effect of changes... 4. ...and
evaluate and act on them. 5. Use a model
to provide a conceptual framework and scope (actually experience shows that
two are better), know how to use it, and who's in charge - don’t let
model compliance become the primary objective. 6. Don't manage
SPI as a project. 7. Measure
progress by results, not schedule. 8. Tactics
determine strategy. Strategies are valueless until you know what you can change
in practice. 9. SPI is
exploratory; many improvement efforts will fail. But these failures are
offset by those improvements that work well. 10. SPI must
pay for itself. If this cannot be demonstrated, stop. Comments
anyone? After drafting these
we found another set on the web by Yingxu Wang and Graham King. Similar but different … Rule 1: Software process
improvement is complicated system engineering. Rule 2: Software process
improvement itself is a goal-driven and a continuous process Rule 3: Software process
improvement is an experiment process. Rule 4: Software process
improvement is risk-prone. Rule 5: Software process
improvement is a time varying system. Rule 6: Software process
improvement is a random system dominated by human factors Rule 7: Software process
improvement has preconditions. Rule 8: Process improvement is
based on process system reengineering. Rule 9: Software process
improvement achievement is cumulative. They’re good and cover much of the
same ground, albeit with bigger words. And they pre-empt ours by ten years.
But they only have nine rules and we’ve got ten, so we win : ) |
|
|
|
|
|
|
|
|
|
19 May 2009: A visitor at OSEL
The
web site has been given another tidy up a visitor to the office. Chris Shelley has been here on a ‘go to work’ day and has been
reviewing and editing the web site. He also spent time listening in on a
‘webinar’ – but was not impressed – old hat to a thirteen year old.
|
|
|
|
|
|
|
|
|
|
18 May 2009: Changing Culture
I’m intending
to present at Tom Gilb’s seminar again this year. The topic is ‘Changing
Culture’. While I’ve been a close student of software culture (you have to be
if you want to have any influence at all) I’m not sure that I can claim to
know how to change it. The
paper describes software cultures and a way of mapping a culture in order
to better understand it. It also lists a number of tools that can be used to
change cultures. These are in no way complete or easy to use, but they do
seem to work.
|
|
|
|
|
|
|
|
|
|
18 May 2009… ‘Energizing CMMI’
There has been some interest in the
‘Energizing CMMI’ page - we seem to have hit on something that matters to a
lot of people. And following on from this interest we’ve been asked to do a
webinar. It’s scheduled for 23 June. If you’d like to log on and hear more
about SPI, CMMI and getting it to work then let me know and I’ll get you
registered for it. |
|
|
|
|
|
|
|
|
|
4 April 2009: New Requirement Book
Attended
the launch of Ian Alexander and Ljerka Beus-Dukic’s new requirements book:
‘Discovering Requirements: How to specify products and services’. It is a
described as a set of techniques and methods for eliciting (or discovering as
the authors say) a good set of requirements. Review to follow in due course
CCS |
|
|
|
|
|
|
|
|
|
March 2009: Next SPIN meeting
The next SPIN
meeting will be on the on the evening of Monday 1st June.
Adopting Agile: Traps and
Pitfalls Simon Whittington & Chris Cooper-Bland Overview Over the years we have
all developed a comprehensive portfolio of best practices which will help us avoid
the common problems on projects, the techniques include:
|
|
|
|
|
|
|
|
|
|
March 2009: SPIN goes online - BCS SPIN Forum:
The British SPIN (Software Process
Improvement Network – a BCS SG) has
been exploring, reporting and promoting software process improvement for
nearly twenty years now, looking at what works - what actually improves software
development and testing - and what doesn't. From early interests in using ISO 9000 and TQM we
have reported on the development and experiences with CMM, SPICE and later
CMMI. (SPIN owes its existence to the development of CMM.) We have tracked
the development and use of measurement for software engineering and
management, and have learned from the SPI experiences of world class software
organizations. We have also made an occasional foray into the more academic
aspects of software development. SPIN was one of the first to recognize and
take a look at the possibilities of agile development; we take a continuing
interest in emerging development practices. The value of six sigma, and
other sets of methods for making changes in software development environments
have also been, and continue, to be explored. We
now have an online forum. If you are actively involved in software process
improvement, or technology change, or simply want to know more about it email me for an invitation
join this independent forum. You will then be able to exchange experiences
and opinions, ask questions, post papers, and collaborate with you colleagues
in SPI… …and… …over this time we
have been directed by the needs and interests of our members. Now, with the
introduction of our forum (huddle) we have a great way of finding out where
we should direct our attention now and in the future. What's next? Show us
where the best ideas are. What direction should SPIN be going? (And not
clockwise, or anticlockwise please, or up or down.) |
|
|
|
|
|
|
|
|
|
February 2009: BCS SPIN – next meeting…
The CMMI and Innovation: A Lost Promise or the Coming Thing? This
year's SPIN evening meetings are scheduled for:
-
Tuesday, 24 February,
-
Tuesday, 26 May,
-
Tuesday, 25 August,
-
Tuesday, 24 November all at the usual time and venue - 6.oo pm at the
BCS London office in Southampton Street. As an
antidote to the current fashion for CMMI compliance we have a talk about real
process improvement. Marilyn Bush is taking a critical look at CMMI and
proposing refinements to enable and encourage innovation in software
development: Title: The
CMMI and Innovation: A Lost Promise or the Coming Thing? Abstract: Modern
companies are always looking ahead. Innovation, though, means more than
aspiration. It corresponds to a choreographed and repeatable process - the
foundations of the CMMI and before it the CMM. Yet over the years those emphases
have been displaced in favour of top-down discipline. This paper will examine
the evolution of the CMMI and the links between the CMMI and the kind of
organizational values that in successful innovative companies foster
systematic creativity. Presenter:
Marilyn
Bush (and Charley W. Bush). Marilyn is one of the authors of the original CMM
and a CMMI assessor and trainer with a particular interest in innovation in
software development. Venue:
BCS London Office, Southampton Street. Time:
18:00 - 20:00, 24 February 2009 Meeting
Format: Presentation and
discussion afterwards Attendance:
Free Sustenance:
Sandwiches and refreshments provided from 18:00, with 18.30 start. Registration:
Delegates
must register, please send notification to: Mandy Bauer mailto:mandy.bauer@hq.bcs.org.uk or
Clifford Shelley mailto:shelley@osel.netkonect.co.uk |
|
|
|
|
|
|
|
|
|
January 2009: A domino model of software and system processes The
increasing interest in statistical modelling requires the development of
useful models to which the statistics can be applied. The development of these
models is perhaps the most important aspect of any statistical or simulation
modelling. A poor or incorrect model can be worse than no model at all. But
the models that tend to be used at the moment are either simplistic,
traditional, but unhelpful, or so complicated that they tend to be
inflexible, very difficult to validate and difficult to have much confidence
in. A simple model building technique is needed.
The domino
model may provide that technique. Everyone is familiar with the idea of
falling dominos, and will have seen elaborate patterns of falling dominos.
This appears to be a useful way of looking at processes too. In software
management the idea that a task is done or not done, not 90% done is
generally accepted good practice, as is the idea of partitioning large pieces
of work into small tasks. The analogy to dominos is clear. Domino models can
be built of most software processes with opportunities to design for speed,
low risk, flexibility - and other required software development outcomes.
Some issues need development – designing domino models for synchronization is
not yet clear but the domino model does appear to hold promise as an easy to
use approach for understanding
and reasoning about software development models, and as a ‘substrate‘ onto
which to graft statistical and probabilistic models. CCS January 2009
|
|
|
|
|
|
|
|
|
|
October 2008: Metronomicon Some years ago Sarah
Sheard wrote a paper called ‘The Frameworks Quagmire’. This attempted to describe
the increasing number of software engineering standards, models and
frameworks in use. The paper included a diagram showing the
relationships between these models and standards, and explaining the title of
the paper. (Since then the situation has got worse: models are products and
tend to proliferate and get
‘improved’, and it is often far easier to invent your own model that
invest in an extant one.) The
software measurement community is in a similar situation. Despite the
relative simplicity and abstract nature of software measurement its
application in different domains and software cultures (engineering,
commercial, financial, agile (who seem to be doing a reasonable job of using
measurement)), the academic community (very keen on measures of software
structure), the influence of the business culture and organizational
performance measurement, the strong influence (or distortion) of a pervasive
project management orientation, together with the diverse needs of the
different users of measurement, the collectors and verifiers of data, and the
designers of measures and analyses, have resulted in a metrics maze every bit
as tangled and confused as the frameworks quagmire. Buried in this maze are a
more or less complete set of methods and tools, important lessons on what
works, and perhaps more important, what doesn’t. But identifying this good
stuff, filtering out the worthless or obsolete is very difficult, especially
for practicing engineers and managers simply looking to use measurement, not
wanting to embark on a time consuming quest for knowledge.
The UK’s Software
Metrics Association (UKSMA), prompted
by its Chairman, Rob Radcliff, has initiated the METRONOS project to address
this. METRONOS has two objectives: the first is to use UKSMA’s and the
software measurement community’s experience to review software measurement
knowledge - especially the almost unknown software measurement standards - and organize and categorize it in a
way that makes it easy for the non specialist to access and navigate around –
the metronomicon; the second, when the first is achieved, is to design
qualifications for those undertaking software measurement in much the same
way as the software testing community has developed qualifications for
testers. METRONOS is not inventing or developing anything new. Everything
needed for effective software measurement is already available. It simply
needs organizing and promulgating. This is an ambitious project depending on
the good experience and judgement. If you would like to help with this work contact me , or any member of the UKSMA committee. CCS
October 2008
|
|
|
|
|
|
|
|
|
|
October 2008: Monte Carlo Methods for Software Projects and Processes The use of statistical
modelling is becoming increasing popular, and an expected part of software
organizations’ planning and risk management, however the correct application of
statistical modelling methods to complex and subtle software engineering
environments can be problematic, leading to defective or misleading
estimation, planning and management information, or loss of confidence in the
delivered information. OSEL can provide informed and objective guidance on
the development and application of robust and accountable methods based on
wide ranging experience within software development and testing across most
industry sectors, together with a background in the application of
statistical models and methods.
If you are considering using Monte Carlo simulations, or other
statistical modelling tools within your organization and would like help,
ranging from guidance, to model development, the identification of
appropriate distributions and running your simulations then contact us now at info@osel.co.uk for more information.
|
|
|
|
|
|
|
|
|
|
July 2008: More than Projects The usual way of describing software development work is as
a project. It is a convenient shorthand, recognized and supposedly well
understood across the industry, and built into models of software development
and management. When a piece of work is identified as a project it triggers
the use of project management tools and roles and provides a framework for
the work. The downside of this is that much software development work is not
suited to being treated as a project. The work may be simple, short term or
repetitive or in other ways not like a project needing planning, tracking,
project boards etc., etc. And by invoking the project model routine work may
become inflexible, unresponsive and overloaded with management and
administrative tools that increase costs, obstruct and delay the work, and
discredit project management techniques. What are the alternatives? And why
do we not have a choice? There are remarkably few words describing packages
of work that deliver a result or value that are used in software development.
Some, like Scrum, have a following (including me), but, despite its many
strengths, proprietary terms like this will not attract a wide following and
may fall from favour in the longer term. Terms like release and fix
are understood but are often bundled into the project framework with all that
implies in terms of management overheads. It is worth taking a look at other
professions to see what terms they use for packages of work: case,
engagement, brief, operation, commission, exercise, revision, value stream,
service, mission, sortie, study…. . These sound odd when applied to
software development or support but they do provide a variety of models or
metaphors, rather than the largely unsuccessful project monoculture that
software developers tends to be stuck with. However to be genuinely useful some
way of categorizing the work to be performed and its context is needed to
enable the correct model to be selected and built. First is the character of
the problem to be solved. Manfred Bundschuh’s excellent categorization of
problems - Interpolation (simple, puzzle like, ‘production’ oriented),
Synthesis (real problem, interesting, engaging, containing ‘unknowns’,
and ‘project like’), and Dialectic (research, exploratory, with
‘unk-unks’, and rather worrying) - is really useful for this. Then there is the scale; how big is
the task?, man days, weeks, years? This requires more than categorization
into little project, project, or programme. There are
qualitative differences too. The culture and organization (or organizations)
within which the work is to be performed will also exert an influence and
should be described and categorized.
And so on. With a useful categorization and selection criteria models
for the work can then be evaluated for their suitability. There will always
be projects, but these will be real projects requiring project management,
not arbitrary bundles of work mislabelled as projects. There will be value
streams for routine processing of software changes or defects, and perhaps
small packages of work directed by no more than ‘five paragraph field orders’
(the military may be a very fruitful source of models – they are experts at
delivering results in uncertain situations). We are currently working to identify a set useful models
for software development -
borrowing from other professions
- and to develop a simple methodology to enable the optimum model to
be selected and implemented from patterns or pattern sets, to provide the
optimum approach to software development and support. If you would like to
help us with this work, or to trial some of the models and patterns do get in
touch. CCS. |
|
|
|
|
|
|
|
|
|
10 July 2008
BCS
Software Process Improvement Network (SPIN) Specialist Group CMMI
Workshop 20 Years of CMM and CMMI – Where are
we now, where next? - 21-22 October
2008, Oxford CMMI, and its predecessors, SPA and CMM, have been in
widespread use for twenty years. They have exerted a major influence on the
way software development is managed worldwide. The British SPIN is conducting a two day workshop this autumn
to assess experiences with these models and to identify and propose
improvements to CMMI model and the way it is used. This is an opportunity for
experienced users of CMMI to compare their experiences and contribute
improvement proposals to these influential tools. There will be two aspects to the workshop: The Model: Areas of interest include: -
The Scope of CMMI: CMMI
addresses a wide range of software development and management activities in
terms of ‘process areas’. Are these PAs correctly placed within the model?
Are there too many PAs (at ML3)? Could the emphasis be shifted within or
across PAs. Are some PAs missing? -
The Structure of CMMI: The
structure of CMM and CMMI has evolved over their lifetime, from the high profile
maturity levels to the detailed practices. What aspects of CMMI’s structure
are most useful, and what are the least? Is the structure sufficiently
general to enable widespread and useful interpretation? -
Best and Worst: CMMI is expensive. Which
parts of the model give best return on investment and which the worst? -
High Maturity: Maturity Levels 4 and 5
focus on quantitative aspects of software development. Does the focus on
process control deliver the benefits expected? What is the value of the quantitative
process models required of high maturity organizations? Does the drive for
control driving out excellence? Using CMMI: Areas of interest include: -
Patterns of Use: How is the model being
interpreted and used to improve software development and management, are
there better ways? How is CMMI best adapted for different types of
organization? -
Appraisals: What works and what doesn’t. Are appraisals now audits?
What influence do appraisals have on process improvement and innovation? Is
the SCAMPI process now too onerous? -
Ethics and conflicts of interest: Lead
Appraisers are often placed in difficulties as they advise organizations on
process improvements and then lead assessments. How should potential
conflicts of interest be managed? -
Perspectives: What perspectives is
CMMI intended to be viewed from, and what perspectives are not intended, or
ineffective? How should senior managers, software staff and customers view
and use CMMI? How do their interests influence the way CMMI is used? -
Other Models:
How should CMMI relate to emerging approaches to software
development and management? Is
CMMI capable of coexisting with these contemporary approaches? Users of CMMI are invited to submit a concise statement of
an issue, concern or opportunity for improvement of the model or its use,
based on evidence or experience, together with a description of its
resolution. (The statement of issue and resolution can be from one to five
pages in length. Guidelines for the statements will be provided on the SPIN
website, or with this invitation.) Space at the workshop is limited and
preference will be given to those statements received early. Send your statement to any of
the organizing committee: The closing date for submission is 15 September. Selected workshop participants will be able to present
their statement, contribute to workshop panels, and to work with other
workshop participants in the development of a set of experiences and
proposals for refinements to the CMMI model and its patterns of use.
(Participants may submit more than one statement but will only be able to
present one.) It is intended that the products of the workshop will be
refined, published and made widely available to the CMMI community. Attendance at the workshop is free, but participants will
be responsible for their own travel and accommodation arrangements, and their expenses. |
|
|
|
|
|
|
|
|
|
June 2008
Managing Risk and Uncertainty This year Tom Gilb’s seminar was concerned with risk and uncertainty. Plenty of ideas – in particular I was surprised by the extent to which risk is dealt with implicitly, by designing the project and the software to minimize risk, rather than explicitly with traditional risk management techniques. I spoke about the customary, de facto standard technique; its strengths and weakness, and proposed some modifications to make it more effective and credible, including the need to introduce some carefully selected risks into projects to inject life and value into them. The paper is here and the slides here. And I collected sufficient new ideas (thanks in particular to Russ and Matthew) and confirmation of existing ones to begin rebuilding our standard project risk management tools. |
|
|
|
|
|
|
|
|
|
May 2008
The International Conference on Agile Processes and extreme
Programming XP208 will be in
Limerick from 12 to 14 June – details below…. The International Conference on Agile
Processes and eXtreme Programming in Software Engineering, XP2008, is
the leading world event on the topics of agility in software and information
systems development. Keynote Speakers: Case Study:
Co-presented by Neil Munro, HBOS and Brian Hanly,
Exoftware. The ninth conference (XP2008) will be hosted by Lero – the Irish
Software Engineering Research Centre at the Register
Here - http://www.lero.ie/XP2008/Registration.html |
|
|
|
|
|
|
|
|
|
April
2008 BCS SPIN SG Gradual
Process Improvement using Agile Retrospectives Tuesday 20 May 2008 Speaker: Rachel Davies - Rachel provides consultancy and coaching teams in agile software development. She has been applying agile approaches since 2000 and has experience of a range of agile methods including XP, SCRUM, Lean and DSDM. Rachel is a well-known presenter at and organizer of industry conferences and a long serving director of non-profit Agile Alliance. Venue: BCS London Office Time: 18:00 - 20:00 Meeting Format: Presentation and discussion afterwards Attendance: Free Sustenance: Sandwiches and refreshments provided from 18:00, with 18.30 start. Registration: Delegates must register, please send notification to: Mandy Bauer mandy.bauer@hq.bcs.org.uk or Clifford Shelley shelley@osel.netkonect.co.uk (Dietary requirements: Please notify Mandy Bauer) Full details of how to get to the BCS London office can be found here: http://www.epsg.org.uk/locations/bcsss-guide.html courtesy of the BCS Electronic Publishing group (these are by far the best location instructions I
have seen anywhere). Note: Delegates need to be BCS members. The BCS has a
special offer open until the 30 April 2008 where SPIN members can join
the BCS free of charge. If non-BCS members wish to take advantage of this
offer, then please contact Clifford Shelley so that he can register you as a
SPIN member with the BCS. For further information, please consult ‘Joining a
Group’ on the SPIN website: http://www.bcs.org/server.php?show=nav.7057. |
|
|
|
|
|
|
|
|
|
February 2008
BCS SPIN SG CMMI and Metrics, 19 February 2008 This is free event with
limited numbers, so it is on a first come first serve basis. The details are: Title: CMMI
and Metrics (A review of the application of measurement for CMMI) Date: Tuesday
19 February 2008 Speaker: Dr
Clifford Shelley Venue: BCS
London Office Time: 18:00
- 20:00 Meeting Format: Presentation and discussion afterwards Attendance: Free Sustenance: Sandwiches
and refreshments provided from 18:00, with 18.30 start. Registration: Delegates
must register, please send notification to: Mandy Bauer mailto:mandy.bauer@hq.bcs.org.uk or Clifford Shelley mailto:shelley@osel.netkonect.co.uk (Dietary requirements:
Please notify Mandy Bauer) Full details of how to get
to the BCS London office can be found here: http://www.epsg.org.uk/locations/bcsss-guide.html courtesy of the BCS
Electronic Publishing group (these are by the best location instructions I
have seen anywhere) As you are probably aware
there has not been too much activity within the group for some time. In the
past we have held full day meeting and charged for attendance, but recently
it has proved hard to get enough attendee to make this worth while. So we
have decided on a change of format, we are still looking for a lively debate
and will value your input into the future of the group. We would also like to draw
your attention to another event being run by the Young Professionals Group,
details are here: |
|
|
|
|
|
|
|
|
|
August 2007
Introduction to CMMI v1.2 Oxford October 2007… Marilyn Bush is presenting an SEI licensed ‘Introduction to CMMI v1.2’
course in October on the 10th to 12th, in Oxford. Marilyn is one of the
contributors to the original S/W CMM and one of the most experienced and
insightful CMMI assessors and trainers; if you are planning to attend an
Intro to CMMI course this is the one. Course and booking details are here. |
|
|
|
|
|
|
|
|
|
2 August 2007
The next SPIN meeting
is on 14 August at the BCS’s London Offices. Visit http://www.bcs.org/server.php?show=nav.9416
for details and a booking form
|
|
|
|
|
|
|
|
|
|
July 2007
Smart Decision Making Tom Gilb’s annual symposium in London was concerned with ‘smart decision making’ this
year. My talk
concerned the anatomy of decisions, and looking at decision dysfunction (why
organizations force smart people to make dumb decisions). A paper was also
presented. |
|
|
|
|
|
|
|
|
|
29 March 2007
Another new training course for 2007…
Formal Technical Reviews: From Inspection
to Walkthrough: A
one day workshop that presents the principles and practice of Formal
Technical Reviews (FTRs). Participants will be able to plan what and when to
review and how to perform reviews, in line with industry best practice, to
reduce project risks and improve software quality to the required level. Call
or email for details.
|
|
|
|
|
|
|
|
|
|
29 March 2007
The UK Software Metrics
Association is issuing a call for papers for their autumn conference: The |
|
|
|
|
|
|
|
|
|
16 January 2007
Two pieces of work are nearing completion. We have a GQM procedure
that we would like independently reviewed – based in the GQM course it
presents GQM as a practical tool for use by individuals or teams, taking
measurement from initial needs through to validation of measurement data.
Supported by models and templates we think this takes the best of the GQM ideas
and presents it in a useful and practical package useable by anyone. The
other piece of work is handbook of software reviews. Again aimed at
individuals and teams looking for practical advice this handbook shows how to
perform reviews for best effect, managing the insidious ‘email review’ and
‘expert review’ problems. |
|
|
|
|
|
|
|
|
|
16 January 2007
It is time to get the British Software Process Improvement Network
(SPIN) functioning again. SPIN is a BCS specialist group for software people
looking for better ways of working from both management and technical
perspectives. If you have an interesting software process improvement, and,
particularly, if you have ideas for SPIN – how it could be more effective,
have ideas about what you would like from it, or would like to help the SPIN
group then get in touch with Clifford Shelley using the email contact above. |
|
|
|
|
|
|
|
|
|
15 January 2007
The UK Software Measurement Association is beginning to think about
the next measurement conference this autumn. If you have ideas for a theme
let us know. (I would like the theme to be measurement in other disciplines –
other areas struggle with measurement too, and some have come up with useful
ideas the software community could use. I’d also like to see some attention
paid to measurement in the small. Too much attention is given to ‘measurement
programmes’ with little new, useful or successful.) |
|
|
|
|
|
|
|
|
|
24 October 2006
Just back from the UK Software Measurement Association
(UKSMA) conference. Good material but the pace of development for software
measurement needs to accelerate: the world is changing and approaches to
software measurement need to keep up. OSEL’s paper on enhancing the
inspection process to recognize design excellence – not just defects - was well received. Here are the paper and slides. |
|
|
|
|
|
|
|
|
|
12 September 2006
New training courses for 2006 and 2007…
Four new courses are being completed for delivery in late
2006 / early 2007. These courses
have been designed to meet the needs of software developers and managers
working to meet changing business conditions, or respond sensibly to the
increasing pressures to conform to new governance models and standards. The
courses are: -
TCM: The Innovation Management Tool. A half day workshop introducing and
using the people and process oriented methods that makes PDCA and continuous
process improvement a practical reality. -
Goal/Question/Metric.
Measurements are increasingly required to demonstrate the value and integrity
of software development, but defining and using software measures is
notorious for it expense and ineffectiveness. This half day course distils
the learning from the best software measurement methods and makes software
measurement quick, simple and effective. -
Six Sigma for Software Developers. A one
day workshop specifically for software developers and managers that gives and
overview of the six sigma approach and then selects and describes the tools
that work best in software organizations. -
Lean Software Development. An intensive one day workshop
introducing software developers to the ideas of lean software development and
describing the thinking tools that reduce timescales and cut through waste. We will be posting more details of these courses in due course. If you
would like to find out more now please email us at info@osel.co.uk
|
|
|
|
|
|
|
|
|
|
28 July 2006
The UK SPIN group
should be reforming again soon. At a meeting yesterday a provisional
programme of meetings was discussed. Dates are 25 September, 4 December, 26
February ’07, and 21 March ’07 with topics covering process improvement
failure modes, off shoring, and managing change. The meetings will be held in London at the BCS Offices in
Southampton Street. The folk at
Lamri are offering to help so expect SPIN to start presenting a more interesting
and professional face to the world. If you want to know what process
improvement is really like, and where its heading (without the spin – so to
speak), or would like to present a paper do get in touch – either here or
email Andrew Griffiths at Lamri.
|
|
|
|
|
|
|
|
|
|
8 June 2006
Developed from the note below this draft paper discusses the ‘opposite of a defect’ and why it matters. I submitted this to Eurostar with no luck but the perceptive people at UKSMA have asked me to present it (a little more developed) this autumn. I’ll have copies with me at the SEPG in Amsterdam next week. I’m keen to hear comments on these ideas - especially if its been developed elsewhere already. |
|
|
|
|
|
|
|
|
|
1 February 2006
Peter Leeson is
running the popular three day ‘Introduction to the CMMI’ course in April in
Milton Keynes:
Course
Description This
three-day course introduces systems and software engineering managers and
practitioners, appraisal team members, and engineering process group (e.g.,
SEPG, EPG) members to Capability Maturity Model® Integration
(CMMI) fundamental concepts. CMMI models are tools that help organizations
improve their ability to develop and maintain quality products and services.
CMMI models are an integration of best practices from proven
discipline-specific process improvement models, including the CMM®
for Software, EIA 731, and the Integrated Product Development CMM. Participant cost is £1000.00 (plus VAT) per person.
This includes the training material, a light lunch on site and the
registration with the SEI. A non-refundable deposit of £100.00 is required
upon registration. Full payment is required by first day of workshop. Contact Q:PIT for details. |
|
|
|
|
|
|
|
|
|
6 January 2006
The excellent BCS Quality SiG (North West) is having a process modelling and definition seminar on 26 January. Details here. |
|
|
|
|
|
|
|
|
|
4 January 2006 – happy new year!The BCS’s SPIN group is planning their first meeting of the new year on 23 February at the BCS offices at Southampton St. London. The topic is metrics. The speakers are: Grant Rule, Rob Radcliff, Graham Thomas and Norman Fenton. Go to http://www.spin.bcs.org/events.htm for further details (in the near future). Alternatively email me at the address above. |
|
|
|
|
|
|
|
|
|
December 2005
Here is a paper
describing an elaboration of the review process usually encountered. Three
stage formal reviews are not new, but not well known either. They are usually
encountered in engineering and defence organizations – they deserve to be
better known. |
|
|
|
|
|
|
|
|
|
16 June 2005What’s the opposite of a defect? Identifying the mirror images of software defects may be
useful for improving software development and development processes:
The data of primary interest
from software inspections is defect data. Analysed with care it can provide
information about the software, and the projects and processes that produced
it. The value of defect data to software engineering is not surprising.
Defect data - whether as defect
counts or of measures of deviations from a norm - is also the primary source
of information for process control and revision in production engineering. However there
is a difference. Like manufacturing defects, software defects give rise to
rework, delay, increased cost, system failures and customer dissatisfaction,
but the uniformity, consistency and conformance to standard, so valued in
manufacturing’s essentially replication processes, are not the only criteria
by which software is judged: software development is design; and, as in
manufacturing design, excellence is the driver, not uniformity. Excellence is
not assessed solely by the number of defects. A good design will have a
certain number of defects, but an excellent design is not defined by fewer.
There is something else. Whatever this is it isn’t assessed by quality
control. But software quality control performed early in the development
cycle, particularly inspections, is not quality control alone. It is an aware
process performed by people that, as well as recognizing defects, may also
recognize excellence: ingenious solutions to difficult problems; prior
solutions; opportunities, and the elimination of complexity. This is
recognized as one of the additional benefits of software inspections but does
not appear to be formally managed or measured. In fact current practice may
actively obstruct the capture of this information. Discussion of design
options is discouraged, the focus to being fixed on detecting defects alone.
This may be a reflection of the origins of inspection as a hardware defect
detection technique, used to improve consistency and uniformity. Software
inspections can become even more valuable when adapted for use in a design
process; when they are supplemented by a requirement to recognize,
acknowledge and record those rare points of excellence that surprise and
please (and give rise to the occasional twinge of envy). Like defects these
points should be recorded, counted and analysed. Similar counts
and analyses of ingenuity could identify the nature and perhaps sources of
excellence. (There doesn’t appear to be useable antonym for defect.) The
analysis of points of excellence (undefects? proeffects? profects perhaps?)
would be similar to that of defects but, unlike defects, the emphasis would
be an amplifying or reusing them to produce ‘profective’ products and
processes. The removal of defects is a major contributor to the delivery of high
quality software, but is bounded by the lower limit of zero defects; the
amplification of excellence, by dissemination of profects, has no limit.
|
|
|
|
|
|
|
|
|
|
3 June 2005Many thanks to Jaap
Bloem who, in response to the defect analysis paper, pointed to the work of Professor Chris
Verhoef who has been using elegant graphical techniques to
reveal insights from unpromising looking software data. Professor Verhoef’s
paper 'Quantifying SPI' is a
model of the use of graphical techniques to analyse complex software data.
The techniques are notable for their simplicity and power. These approaches
really should be distinguished from the complex, obscuring, and often
inappropriate statistical analyses that so much software data is subject to.
(It’s tempting to add a ‘G’ for ‘Graphics’ to Basili’s GQM giving GQMGTuTu - with the second G directed by Tukey
and guided by Tufte.)
|
|
|
|
|
|
|
|
|
|
13 May 2005Here is the draft
of a paper about analysing software defect data I will be presenting later
this year. Your comments would be welcome. It suggests that SPC techniques are not a useful as might
be thought and that simpler defect analysis techniques can do more and open
up opportunities for improvement. It also proposes using software inspections
for more than identifying defects.
|
|
|
|
|
|
|
|
|
|
3 May 2005Download an evaluation
copy of PODS v1.9 for Lotus Notes (R5 and later) with full functionality:
defect tracker, change index, risk register, action tracker, test logger and
much more! The 814k zip file
contains complete PODS, the PODS manual, and installation notes. Available on
the PODS page.
|
|
|
|
|
|
|
|
|
|
18 April 2005Unexpected validation
for the rpi approach to process improvement (see www.osel.co.uk/rpi/rpi.htm): The
emphasis with rpi is on problem solving – ‘if you aren’t solving a problem
question what you are doing’, and ‘upstreaming’ (T - 1). These are recommendations from the ‘theory of
constraints’ (Goldratt, Theory of Constraints) which, in a nutshell, suggests
that improvement work be focussed on removing bottlenecks. Optimisation in
other areas does nothing but increase queues at the bottlenecks. This is
precisely what we have been learning and promoting with rpi. Nice to know
we’re getting it right.
|
|
|
|
|
|
|
|
|
|
6 April 2005We are planning two
public courses later in the year:
Rapid Process Improvement. A one day tutorial on the use
of the RPI toolset, Central London, 8 September 2005, £285.
An Introduction to CMMI – Staged and
Continuous,
A three day
training course, Central London, 20-22 September 2005, £745.
Details of these
courses will be posted on our events page in due course. If you would like
details now please do email us.
|
|
|
|
|
|
|
|
|
|
24 March 2005This is an observation
that I’m not aware of having been made before. I’ve noticed that those
organizations making progress in software process improvement - whether or not
it is measured in terms of conformance to standard, CMM Levels perhaps, or
improved performance - tend to be using two software process models;
the operational model and the reference model. The operational model is the
description of how work is performed, and may be an established lifecycle
model or an acquired and tailored commercial model, RUP, say, or even a
toolset. The reference model is used to direct and guide the development of
the operational model - in many cases this is CMM(I) - although it can be
something else, including models used by others as operational models. The
value appears to be in the models complementing each other; the operational
model being an explicit and coherent framework and tools to support working
practice, and an interpretation of the reference model; the reference model
providing direction and validation to the operational. Where this occurs it
appears to have happened quite unconsciously, and contrasts with
organizations where the new improved way of working (whatever it may be) is
introduced as both the operational and reference model, overwriting existing
practices, with predictable consequences. This two model approach is implied
in CMM(I)’s OPD where architectures and lifecycles reside, but the
relationship between these and the CMM(I) itself, especially with respect to
effectiveness of SPI, appears obscure, and tends to be ignored when the
‘implementation’ of CMM(I) is discussed. (I have never liked the term CMM(I)
implementation – maybe this is why.) Has this operational/reference, two
model approach been noticed or reported elsewhere?
|
|
|
|
|
|
|
|
|
|
7 March 2005I’ve been pointed to this and found it referenced in the
lean software development book – see library. It’s not exactly an easy read
but it may just open a door to understanding software processes a little
better. S/w development is intimately connected to software management which
is ‘difficult’. Professor Koskela’s paper may shed some light on this.
Distinguishing service models from project models as alternatives for
software and systems development (see the RPI slides) is not popular; the
project being taken as the default regardless of its appropriateness. This
paper may help justify non project oriented software management approaches.
|
|
|
|
|
|
|
|
|
|
28 February 2005Thinking about the CMM
again it occurred to me that you hear little about the many different ways it
can be used for process improvement. Here are some suggestions:
1.
Use the CMM (or CMMI) to tell you what
not to try.
This was how we originally used it. When the CMM first appeared we were
undertaking ambitious and diverse process improvement efforts, in particular
software measurement. Some things worked others didn’t. The CMM made it very
clear for the first time that some things come first and others, dependent on
them, come later. Use the CMM to understand your capability and make that
better – don’t launch process improvements to become more mature, use
it to become more effective and more efficient. Work to be a really good
<whatever level you are, even L1> organization and understand your
organization and measure the effect of your work before even thinking about
changing level.
2.
Start at the top. Look to Levels 4 and 5 for
toolsets for improvement and not as distant maturity levels. The tools
described at levels 4 and 5 can be used (carefully and locally) whatever the
your ‘official’ maturity rating. (A TQM organization not developing software,
or just starting software development would be level 1, but equipped with the
L4 and 5 processes to make it more effective – why not try it too.)
3.
Think of the maturity levels not as
levels but as types:
project oriented, process oriented, TQM oriented…. Some organizations are
intrinsically project oriented, others process oriented. An organization may
be a really good intrinsically L2 type organization, or it could be naturally
L3, but with holes. Which? Don’t spoil the good L2 organization by making it
mimic a L3 organization, but the ventilated organization could really benefit
by a drive to patch the holes. Trying to be the wrong type of organization,
process oriented when project oriented, or visa versa, is like wearing shoes
on the wrong feet, uncomfortable and unhelpful. Decide what type of
organization you are and work to be really good at that. Don’t be a ‘cargo
cult’ organization.
4.
Put the levels and process areas to
one side and look at the really important features of the CMM, the common
features. The
common features describe all the process areas at all the levels in the s/w
CMM. Why? - because they are the
key to understanding, managing and improving processes. Invest in
understanding and putting in place your own common features and you will be
unable to stop improvements in performance. (The common features persist in
CMMI, but tend to be overshadowed by the model’s size and complexity.)
If you have found good
ways of using the CMM - beyond formal assessment, ‘gap
analysis’ then attempting to be the next level (or two) up by <scheduled
date> - let us know and we can add them to the list.
|
|
|
|
|
|
|
|
|
|
17 January 2005Peter Leeson
is running a three day ‘Introduction to the CMMI’ course in March 29 - 31,
from 9.00 to 5.00 in Milton Keynes, in the UK. This course fulfils a prerequisite requirement for any
course requiring an official SEI Introductory CMMI course. Email us at info@osel.co.uk or call on 01993 700878 for
more details. The SEI Introduction to CMMI®
This three-day course introduces systems and
software engineering managers and practitioners, appraisal team members, and
engineering process group (e.g., SEPG, EPG) members to Capability Maturity
Model Integration (CMMI) fundamental concepts. CMMI models are tools that
help organizations improve their ability to develop and maintain quality
products and services. CMMI models are an integration of best practices from
proven discipline-specific process improvement models, including the CMM for
Software, EIA 731 and the Integrated Product Development CMM. In response to community requests, this course is an
upgrade to the existing Introduction to CMMI, Staged Representation and
Continuous Representation courses, incorporating concepts from both. The
course also includes improvements to slides, exercises, and other course
materials identified in other change requests submitted by the community. The course is composed of lectures and class exercises with ample opportunity for participant questions and discussions. After attending the course, participants will be able to describe the components of CMMI models and their relationships, discuss the process areas in CMMI models, and are able to locate relevant information in the model. |
|
|
|
|
|
|
|
|
|
7 December 2004Just received this
from the British Computer Society…
Following an exploratory meeting
yesterday (25 November), a proposal is being developed for the
formation of a BCS Open Source Specialist Group. Subject to approval of its
formation by the Specialist Groups' Executive Committee, this SG will have
a wide remit and will also include health/informatics. If any member is interested in being a member of this
group (and especially if anyone would be interested
in serving on an interim Committee to get the group up and running), please
contact Peter Murray, Chair, BCS HI Nursing SG, by 15 December on
peter@open-nurse.info Regards John Stephens Specialist Groups' Officer BCS 1 Sanford Street
SWINDON SN1 1HJ e-mail:
jstephens@hq.bcs.org.uk Tel (direct): 01793 417631 |
|
|
|
|
|
|
|
|
|
6 December 2004We have added a dedicated
RPI page where we will be
trialing access to the RPI toolset assets prior to moving them across the
SPIN website in March 2005. If you want something on the page that is not
available yet email us for it, but take a look at the RPI slides - below - to make sure you really do
want it first.
|
|
|
|
|
|
|
|
|
|
2 December 2004The US Sarbanes Oxley
Act seems to have the potential to stir things up in the software process community.
The requirements imposed by this act may trigger increased management
interest in visibility and accountability in software development and support
- and that can’t be bad.
|
|
|
|
|
|
|
|
|
|
(4 November 2004The web site has been given
a tidy up by a visitor to the office. Eleanor Shelley has been here on
a ‘go to work’ day and has been making herself useful by conducting some
usability tests on PODS and editing some of our web pages.)
|
|
|
|
|
|
|
|
|
|
October 2004
We have drafted a procedure called ‘Process Workshop’. It
has been developed to provide a simple, template procedure to put in place
changes to working practices and engage developers and managers in process
improvement. Its value is as an explicit and teachable process that can be
used by everyone and ‘officially’ recognized and measured. It encourages
consensus building and provides publicity for small, well scoped
changes. This is in contrast to TCM, a tool for larger scale process
improvements used for identifying and agreeing the problem and then
formulating the fix. Comments on the PW draft documents would be very welcome - procedure.pdf, procedure diagram.pdf. It
would be useful to us to know if you already do something similar, or if this
would be useful to you. Notes on errors and omissions, except typos, also
welcome. |
|
|
|
|
|
|
|
|
|
October 2004
I’ve just been sent
this - radice.pdf. It is a fascinating case study on the
use and value of software inspections by Ron Radice (see book reviews). I’m
not too sure if I should be posting this paper here - note it is copyrighted
– but it does include links to the author’s web site.
|
|
|
|
|
|
|
|
|
|
September 2004
We have been
contributing to the SPICE (Structured Process Improvement for Construction
Enterprises) since its inception. SPICE is a model for process improvement,
inspired by the SEI’s CMM, intended for the construction industry. SPICE III
is now preparing to launch the Level 3 definition. See www.scri.salford.ac.uk
or email us for details
|
|
|
|
|
|
|
|
|
|
September 2004
Don’t forget the UKSMA
conference in September - http://www.uksma.co.uk/ – we will be there
speaking on Six Sigma ( paper slides ) and
presenting the Rapid Process Improvement (RPI) tutorial ( slides ).
|
|
|
|
|
|
|
|
|
|
July 2004
Just returned from the
SCRUM course. SCRUM is a ‘wrapper’ for agile software
development, or perhaps more accurately, an agile wrapper for software
development. It’s a deceptively simple set of ideas - 30 day ‘sprints’ to
develop and deliver workable code of value to the business – with daily team
meetings (scrums) during sprints to keep development on course by the
self-managing team. In essence a refined and practical take on the
iterative/incremental development approach. SCRUM has a lot of potential – it
meets a real need, it’s simple, technically easy to implement – but like
anything involving new ways of working, potentially career limiting. It’s
designed to break the software development log jam and get value out of
software development fast. It sits neatly between the agile development
methods and the business that must get value from them. Its not just process
– like XP there’s some attitude in this too. There’s a SCRUM book (by Ken
Schwaber and Mike Beedle, SCRUM’s originators - ISBN 0-13-067634-9) but it doesn’t do credit to SCRUM
itself. If you can, get yourself on a Certified Scrum Master course. The
presenters at our 2 day course, Ken Schwaber and Joseph Pelrine, clearly know
what they’re talking about and were able to hold our attention with great
ideas, clear thinking and some good stories too. I don’t agree with
everything they said but like any good idea it’s made me think and question
what I believe. As an extra goodie it’s intended to keep SCRUM open so
everyone can get access and contribute to its development. Find out more at http://www.controlchaos.com/.
If you would like a SCRUM
tutorial or SCRUM training we now have a Certified ScrumMaster - contact us.
|
|
|
|
|
|
|
|
|
|
June 2004
SPIN has just started
up again – kick started by Tom Gilb’s excellent seminar on Agile Inspection. At
the next SPIN meeting this autumn we intend to start up two SPIN initiatives
(if the committee will let us). Firstly restart the SPI tools repository to
acquire and give SPI practitioners access to simple effective SPI tools.
(This was tried in ’98 but while the need was there few tools were
forthcoming. This has now changed.) Secondly start a SPIN project to develop ‘fault grids’ invented by
Jeremy Dick. Fault grids appear to be the most effective way of analysing and
presenting defect data. They have considerable potential but have had very
little exposure in the software development community. This project hopes to
change that.
|
|
|
|
|
|
|
|
|
|
26 May 2004
I’ve just received this.
Short notice but could be interesting if you can make it…
The Thames Valley Agile Special Interest Group would like
to invite you to our first seminar at Oxford Brookes University on the 1st
June 2004.
Topics: An
introduction to Agile Software Development / Extreme Programming (XP)
explained
Speaker: Tim Bacon
- Thoughtworks
Date: Tuesday
1st June 2004
Time: 19.00
- approx 21.00
Cost: Free
Location: Oxford
Brookes University
Headington
Campus
Gipsy
Lane
Oxford
OX3
0BP
(Arrive
at main reception from where you will see signs to the Agile User Group).
Summary:
Agile Software Development has had a dramatic impact on the Software Development industry over the past few years. Since the release of Kent Beck's book, 'Extreme Programming Explained - Embrace Change', Agile SD has gone from strength to strength. As more and more organisations are reaping the advantages of using these disciplined yet lightweight approaches to deliver customer focused software faster, its is becoming imperative for software teams to be able to utilise these 'agile' skills to keep up in the market place. |
|
|
|
|
|
|
|
|
|
April
2004
UKSMA – the software measurement group have issued a call for papers for their autumn conference: The UK Software Metrics Association (UKSMA) CALL FOR PAPERS The 15th
Annual UKSMA Conference is to be held on 15
September 2004, at the University of
Wolverhampton. The theme of the conference will be Software Measurement in
Practice.
You are
invited to submit papers on the subject of software measurement to conferences@uksma.co.uk. Please submit a short description summarising your paper. Each presenter has 45 minutes,
including 10 minutes for questions. It would be appreciated if you would indicate your intention to submit a paper as soon
as possible even if the description is not yet ready, so that we can gauge
the response. Deadline for papers is 7th May 2004 - Notification of acceptance by 28th May 2004. |
|
|
|
|
|
|
|
|
|
March 2004
In passing – we’ve
helped another of one of our client’s to CMM L2. They have just had a registered
CBA IPI and have achieved L2. This in very short timescales and with clearly
improved performance.
|
|
|
|
|
|
|
|
|
|
January 2004
The value of quality controls in all stages of software development
and maintenance is becoming increasingly evident, not just as quality
controllers identifying defects, but also as management and communications
tools. This is leading us to find define and categorize the best of these
techniques and processes. It looks like a big job. If you would like to help
with this or simply contribute some views email us. |
|
|
|
|
|
|
|
|
|
September 2003
We’ve come across some
interesting new ideas – dynamic configuration of systems – update your systems
while they’re running. Potentially makes the traditional release process
easier simpler and less risky. |
|
|
|
|
|
|
|
|
|
May
2003 |
|
|
|
|
|
|
|
|
|
April 2003 Satyam is a major Global
consulting and IT services company assessed at CMM Level 5. Satyam has a wealth
of software process and process improvement knowledge. OSEL has detailed
knowledge of UK and European software process capabilities and software
process improvement programmes. It also has highly effective process
improvement tools. We will be working
closely together with Satyam to maximise our capabilities by making world
class performance available - effectively - to organisations requiring
improved understanding and performance of their software processes. |
|
|
|
|
|
|
|
|
|
March 2003 The integration of the P2
metrics tool with the Microsoft PODS is underway. Following increasing
interest from industry and also a request at the UKSPIN we have prepared an
overview and comparison on Six Sigma and its applicability to software
development. |
|
|
|
|
|
|
|
|
|
February 2003 The growing interest in the
Unified Process and experiences of PRINCE2 has shown a need to integrate
these two methods. We are currently working on integrating the management
method and the software process. |
|
|
|
|
|
|
|
|
|
January 2003 PODS is now being ported
to VB. It is intended that this variant of mPODS will replace the current
Access based mPODS towards the end of this year. The new mPODS will retain
all the lPODS functionality, include P2, and be capable of working from most
databases. We have begun a study to
see how closely the PODS tool-set maps onto the PRINCE2 project management
method. PODS was deliberately developed independently of any particular
methods to ensure maximum applicability but the obvious synergies between
PODS and PRINCE2 have prompted us to consider a PODS variant that explicitly
supports PRINCE2. We are offering lPODS
1.8(d) (running on Lotus Notes R5) free with a view to extending the user
base. The distribution is of a design protected PODS but may change - see
below. Contact shelley@osel.netkonect.co.uk for an lPODS pack. OSEL is reviewing its
PODS distribution options. Should we take PODS open source? The impact of the
open source movement is impressive and opportunities for wider use and
improvement of PODS are tempting. Any views? |
|
|
|
|
|
|
|
|
|
November 2002 The Tactical Change
Management (TCM) method is being revised. The current issue (1.4) is rather
'procedural' in feel. We are revising it to make it look less intimidating
and to make it easier to learn. |
|
|
|
|
|
|
|
|
|
September
2002 |
|
|
|
|
|
|
|
|
|
June
2002 |
|
|
|
|
|
|
|
|
|
May
2002 |
|
|
|
|
|
|
|
What’s New PODS Products & Services Library Presentations & Papers Related Sites Events History Clients |
||
|
© Copyright OSEL 1998-2009 |
|
|
