|
Rapid Process Improvement & the RPI Tool-set |
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 C o n s u l t I n g S o f t w a r e E n g I n e e r s |
|
|
|
|
Rapid Process Improvement (RPI) is an approach to process improvement designed to deliver results early with minimal risk. There is little new in RPI, rather it is a return to proven methods and to the original intent of software process improvement (SPI) - improved performance - that have tended to become lost with the increasing use of software process models for conformance purposes, and with over ambitious attempts to introduce common corporate development capabilities. RPI seeks better ways of working where 'better' is decided by those best placed to recognize it, usually those doing the work, and those that understand how the work helps meet business objectives. The approach is exploratory and structured in small increments, where the work can be readily co-ordinated and the results evaluated. This type of approach limits risks and often far more acceptable than the centralized 'one size fits all' process improvement initiatives so often imposed on software professionals, and, ironically, it can achieve the results desired by the corporate initiatives faster and at lower cost. (The similarity of RPI to popular agile approaches is striking. We are not sure whether this is a good or a bad thing and are working to determine the reasons for this.) SPI and RPI discusses SPI and why RPI is different. Real improvement is greatly aided if the right tools are available. We have been collecting and developing RPI tools and composing an RPI tool-set. This tool-set is a diverse selection of methods, tools, techniques, infrastructure, and anything else that can be co-opted to deliver improvements. It has been developed by and for software process engineers. The tools are well
described and teachable to equip process engineers to improve understanding,
and to change intrinsically complex, subtle and often highly coupled software
development and support activities in a controlled and measurable way. They
have been acquired and developed over a number of years and will continue to
be developed and added to. Tools are classified in three main categories;
visibility, construction and infrastructure. A fourth ‘catch all’ category,
‘other’, is used for tools that do not fall readily into one of these
categories. We are keen to develop this classification as a tool in its own
right to enable process engineers to more readily select the right tool for
the job. Any suggestions or pointers to better classification systems would
be very welcome. Why have process improvement tools? The RPI tool-set is reasonably stable now but continues to be refined. If you would like to know more, receive a copy of the RPI paper, receive the RPI tutorial, or trial selected tools then email us at: …and if you have tools or assets you are willing to share we are keen to hear from you too. Tools for Visibility: These tools are designed to show how software development and support is performed. They answer the questions: “what is happening?”, “what effect have our process improvement activities or technology introductions had?”. These tools give process engineers data to work with. V - 1 Post Implementation Reviews and Retrospectives: fundamental tools for understanding and improving development and test practice V - 2 Assessments, Appraisals and Audits: potentially powerful diagnostic tools - but often misused or abused V - 3 Focussed Quality Assurance (FQA): A low risk, low cost method for introducing and ramping up a quality assurance capability for non engineering software organizations V - 4 Records: the team, project and organization’s memory – often disregarded or overlooked V - 5 Formal Technical Reviews (FTRs): A fundamental software engineering practice. (Actually a set of practices of variable formality and rigour, from walkthroughs, to inspections, to pairing. V - 6 Defect Models and Defect Tracking: Provide insights into product qualities, process efficiency, and project performance – defects are software development’s lab rats. V - 7 Measurement: Needs and deserves to be treated as a tool in its own right, but is integrated into many of the other tools too, to the extent that RPI could also be called MPI (Measurable Process Improvement) V - 8 Using Performance Targets: a double edged tool V - 9 Cost of Quality (CoQ) V - 10 Visualization: of patterns, processes, products and projects V - 11 External Consultants: getting best value from their knowledge and experience. V - 12 New Hires: for an objective but informed perspective of process performance, development and test capability, and organizational culture. Tools for Construction and Change: Software development is dependent on both technology and the people using it. These tools are designed to aid the change of technology, processes, expectations and behaviour. C - 1 Developing a Process
Improvement Plan (Dev-PIP) C - 2 Process Definition: A fundamental tool that ensures that
process definition work establishes a genuine and valued process baseline,
not shelf-ware. C - 3 Tactical Change Management (TCM): A simple framework for
process improvement that delivers results fast and reduces risk. C - 4 PIR Led Process Improvement (PIRL): Fundamental - start with this. C - 5 Process Improvement Templates: Characterize the types of process improvement, and selects the right process improvement tools. C - 6 Joint Application Development (JAD): It works for software – and software practices and processes too C - 7 Making Checklists: Fast, fun and an effective method of distilling and sharing wisdom. C - 8 Knowledge Transfer: C - 9 Process Workshop (PW): A method for tactical process improvement C - 10 Prefabricated Software Process Components: An approach for the rapid installation of software development capability C - 11 Strategy: Development: (and validation and maintenance)
Infrastructure Tools: These tools are models or templates for robust process infrastructures. They eliminate ambiguity redundancy and contention, and enable effective communications and collaboration. F - 1 Software Process Infrastructure F - 2 Process Improvement Infrastructure F - 3 Software Process Architecture F - 4 Tools Group
The difficult to classify tools: A selection of difficult to classify tools and techniques. T - 1 ‘Upstreaming’ T - 2 Resource Models T - 3 Leverage and ‘Reverse Leverage’ T - 4 Visible Migration (or development) of process and practice assets T - 5 Skills Recognition T - 6 Process Sponsors and Process Champions T - 7 Other Tools (mostly from other disciplines) T - 8 Process Action Teams (PATs)
|
|
|
For data sheets for these tools or further information email: info@osel.co.uk |
|
|
|
|
|
© Copyright OSEL 2004 - 2010 |
|