University of Toronto University of Toronto Department of Computer Science Department of Computer Science What is the state of the practice Lecture 13 Summary Last Last Week Week Integrated Integrated RE RE method methodengineering engineering problem problemframes frames Lubars 1993 field study of 10 organizations Customer specific projects usually given large monolithic statements of requirements seldom in machine readable form are often sketchy ill defined concept of superdesigner used for interpretation filling gaps Market specific projects have smaller requirements often produced in house This This Week Week Findings Customer interaction always hard Many projects use doc standards few adopt any particular method Summary Summary how howisisRE REcurrently currentlydone doneininpractice practice Course Course Summary Summary and and Evaluation Evaluation Projects using OO methods had trouble modularizing their requirements some thought that structured analysis led to unintelligible specifications Many projects use some organizational approach to requirements validation Conclusions Organizational solutions preferred over technology General purpose technology preferred over CASE Requirements activities undercapitalized only 1 3 used some tools Market driven projects increasingly important About 1 3 of the projects did some sort of prototyping Requirements evolution a major concern 2000 2003 Steve Easterbrook 1 University of Toronto Department of Computer Science 2000 2003 Steve Easterbrook 2 University of Toronto Managing Process Change Capability Maturity Model Source Adapted from Humphrey 1989 chapter 1 Source Adapted from Humphrey 1989 chapter 1 Humphrey s principles Level Characteristic Key Challenges 5 Optimizing Improvement fed back into process you need a map you need to know where you are on the map 4 Managed Quantitative measured process process improvement is not a one shot effort 3 Defined Identify process indicators Empower individuals Automatic collection of process data Use process data to analyze and modify the process Process measurement Process analysis Quantitative Quality Plans Establish a process group Identify a process architecture Introduce SE methods and tools Project Management Project Planning Configuration Mgmnt Change Control Software Quality Assurance Major changes to software processes must start at the top with senior management leadership Ultimately everyone must be involved Effective change requires a goal and knowledge of the current process Change is continuous Software process change will not be retained without conscious effort and periodic reinforcement Software process improvement requires investment Department of Computer Science 2 Repeatable Software Engineering Process Groups SEPGs Team of people within a company responsible for process improvement identifies key problems establishes priorities assigns resources tracks progress etc 1 Initial Needs senior management support 2000 2003 Steve Easterbrook 3 2000 2003 Steve Easterbrook Qualitative process defined and institutionalized Intuitive process dependent on individuals Ad hoc Chaotic No cost estimation planning management 4 1 University of Toronto University of Toronto Department of Computer Science Recent Findings Example Problems Source Requirements Problems in Twelve Software Companies An Empirical Analysis Tracy Hall Sarah Beecham Austen Rainer 2001 Source Requirements Problems in Twelve Software Companies An Empirical Analysis Tracy Hall Sarah Beecham Austen Rainer 2001 General issues Developers are more aware of requirements process problems than project managers and senior managers Most requirements problems 64 were human organisational in nature Organisational issues Data collection 45 focus groups 200 staff Sept 99 to Mar 00 Organisational problems are more important than process technical issues But are harder to address Organisational problems amplify some process problems Lack of skills exacerbates these problems Data from 12 companies Range of maturity levels Small medium and large companies Poor staff retention has an impact on requirement process capability Better communication needed between developers and customers Requirements growth and change had less of an impact than expected Higher maturity companies tend to exhibit fewer requirements problems Problems in higher maturity companies tend to be organisational High maturity processes more resistant to damage from organisational issues Manager groups in high maturity companies understand requirement process problems better 5 University of Toronto Organisational requirements problems Frequency 56 47 33 29 28 19 18 230 Developer communication Inappropriate skills Inadequate resources Staff retention User communication Lack of training Company culture Total organisational problems Percentage 24 20 14 13 12 8 8 100 Process based requirements problems 3 types of group Senior managers Project managers technical staff Maturity issues 2000 2003 Steve Easterbrook Department of Computer Science Vague initial requirements Undefined requirements process Requirements growth Complexity of application Poor user understanding Inadequate requirements traceability Total process problems Frequency 33 32 31 27 5 4 132 Percentage 25 24 23 20 4 3 100 2000 2003 Steve Easterbrook 6 University of Toronto Department of Computer Science Barriers to cultural change Department of Computer Science RE and Extreme Programming Source Adapted from Kauppinen et al 2002 Obstacles It is not worth discovering needs directly from users Examples We ve been developing such products for a long time and know users needs But experience shows We also use our own products and can act as users ourselves Developers tend to be biased by their technical expertise It s a new product therefore users cannot have any needs for it Still need to understand the current context and existing tasks It is difficult to discover needs directly from users Users are unable to say what they need and want Combination of observation and other elicitation techniques works There are so many users we cannot interview them all It is possible and useful to identify representative potential users It is risky to discover needs directly from users Customers might think we don t know the basics of their business It is not worth documenting user requirements systematically Customers want to see the technical specs not user reqts investigating needs often reveals that a technical solution won t