Title:
Modeling an agile web maintenance process using system dynamics Authors:
Xiaoying Kong Lecturer Address: Level 24, Building 1, Faculty of Engineering, University of Technology, Sydney P.O. Box 123, Broadway, 2007, NSW, Australia Phone: +61-2-9514-2445 Fax: +61-2-9514-2435 Email:
[email protected]
Li Liu Lecturer Address: Department of Civil Engineering, University of Sydney, NSW, 2006, Australia Phone: +61 2 9351 2123 Fax: +61 2 9351 3343 , Email:
[email protected]
David Lowe Professor Faculty of Engineering, University of Technology, Sydney, P.O. Box 123, Broadway, 2007, NSW, Australia Phone: +61 (0)2 9514 2526 Fax: +61 (0)2 9514 2435, Email:
[email protected]
1
Brief Biographies Dr Xiaoying Kong received her BE and ME degrees in control engineering from Beijing University of Aeronautics and Astronautics, China. She received her PhD in robotics from the University of Sydney, Australia. She has six years' working experience in aeronautical engineering and the semiconductor industry, and six years' industrial experience in Web development. She is currently a lecturer in the Faculty of Engineering, University of Technology, Sydney. Her research interests include Web technologies, software engineering, data fusion and robotics. Dr Li Liu is currently a lecturer at the Department of Civil Engineering, the University of Sydney. He has a PhD from the Australian Graduate School of Management (AGSM). He also has a Master's degree in Taxation, a MBA from the Asian Institute of Technology, and a Bachelor of Engineering. Dr Liu worked for a decade in systems engineering, project management, business research, management consulting and managing an E-com company. His research interests include enterprise-level project management, IT/IS project management, organisational theory, programme/portfolio management, and project/programme governance. Professor David Lowe is the Associate Dean (Teaching and Learning) in the Faculty of Engineering at the University of Technology, Sydney. He has active research interests in the areas of Web development and technologies, hypermedia, and software engineering. In particular he focuses on Web development processes and Web project specification and scoping, and information contextualisation. He has published widely, including several textbooks (Lowe and Hall, Hypermedia and the Web: An Engineering Approach, Wiley, 1999; Wilde and Lowe, XPath, XLink, XPointer, and XML: A Practical Guide to Web Hyperlinking and Transclusion, Addison-Wesley, 2002). He is on numerous Web conference committees and journal editorial boards (such as the Journal of Web Engineering and the International Journal of Web Engineering and Technologies) and is the Information Management theme editor for the Journal of Digital Information. He has undertaken numerous consultancies related to software evaluation, Web development (especially project planning and evaluation) and Web technologies.
2
Modeling an agile web maintenance process using system dynamics
Abstract To cope effectively with high levels of requirement volatility and frequent system change, practitioners have increasingly adopted iterative and agile methodologies in Web development and maintenance. Despite the increasing acceptance in the agile methods, empirical evidence of its effectiveness is mainly anecdotal. There is a need to understand the dynamic process of agile methodologies through a more structured analytical process.
In this paper, we attempt to model the influences of the values of the agile methodologies by analyse the factors that impact the productivity in agile web development and maintenance lifecycles. System dynamics is used to model an agile method-CFMethod. Qualitative analysis of the influence factors in the major maintenance process is conducted. Major influences to the major project concern “velocity of the exploration phase” are modeled using influence diagram. This qualitative model establishes an important step for further quantitative modeling of agile methodologies. Our next research step will be the simulation of Critical Feature Method based on the qualitative model in this paper. The results from Critical Feature Method could be scaled up to other agile methodologies in the future research..
3
Introduction Over the last decade, there has been a strong trend of moving from client-network computing to web-centric computing, where users can conduct sophisticated computing using standard web browsers. Web systems differ from conventional software systems in a number of ways. First, Web systems usually face high levels of uncertainty in requirements and in understanding whether a particular design will satisfy client needs. Second, due to the need to adapt to the changes in business model, Web systems tend to have short delivery timeframes and high levels of change in requirements and project scope, which often demands finer-grained evolution and maintenance with an ongoing process of content updating, editorial changes and interface tuning (Lowe et al. 2001). These characteristics impose unique requirements for the processes of the development and maintenance of Web systems. The processes need to be able to cope with high levels of system requirement volatility and support frequent changes within short timeframe.
Conventional software development models (such as waterfall approaches, prototyping, rapid application development (RAD), incremental development, spiral models, component assembly, and concurrent development (Pressman 2000) were originally designed for developing standalone software systems. These models specify the activities, outputs and artefacts at different lifecycle phases. To varying extents, they have been proven to be successful within domains that have stable requirements, but often have difficulties dealing with projects that have high levels of requirement uncertainty (Eckstein 2003), a common feature of Web site development and maintenance.
To cope effectively with high levels of requirement volatility and frequent system change, practitioners have increasingly adopted iterative and agile methodologies in Web development and maintenance. These methodologies include Rational Unified Process (Kruchten 2000), eXtreme Programming (XP), Crystal Family, Adaptive Software Development, Scrum, Feature Driven Development, Dynamic System Development Method and Lean Development (Martin 2002). Common features of the agile methodologies include an emphasis on communication between client and developers, minimal documentation, iterative development and rapid feedback.
The agile methodologies are based on the best practices in software development communities. Despite the increasing acceptance in the agile methods, empirical evidence of its effectiveness is mainly anecdotal. As an unstructured approach, it is sometimes difficulty to replicate successes. There is a need to understand the dynamic process of agile
4
methodologies through a more structured analytical process. More recently, studies on the effects and processes of agile methodologies start to emerge (Padberg et al. 2003; Misic 2002). There is a strong interest in the agile community in understanding the effects and dynamics of agile methodologies, focusing on the measurement framework of the productivity and quality in agile methods (EEAP 2002).
In this paper, we are attempting to model the influences of the values of the agile methodologies by analyse the factors that impact the productivity in agile web development and maintenance lifecycles. To achieve this goal, we apply system dynamics to model an agile web maintenance method--Critical Feature Method (CFMethod) (Kong et al 2004). CFMethod is developed to handle emergency situations that are common to web system maintenance. CFM is underpinned by a set of core values that emphasizes the collaboration between business executives and system developers; minimal feedback loop; close involvement of business executives; and rapid design focusing on critical features. The web system maintenance states are classified into three distinct states. In applying the SD modeling, the relationships among the attributes of CFM and the project outcomes are identified and modeled using influence diagrams and causal-loop diagrams. The maintenance processes are simulated at each of the 3 web maintenance states.
In the following sections, the Critical Feature Method is described; then, system dynamics is applied to model the CFMethod; and finally, conclusion and future research directions are discussed.
Critical Feature Method The Critical Feature Method (Kong et al 2004) is a lightweight web maintenance methodology for small and medium sized enterprises (SMEs). CFMethod is designed to effectively handle urgent change requests such as emergency situations that are common to web systems. The methodology involved analysing the web maintenance states and classifying them into three distinct states. The maintenance activities include exploration, development, testing and deployment of web features. The maintenance process of CFMethod can be integrated with the normal evolution of web systems.
CFMethod embraces a set of values that promote development speed and low cost. The core values are
5
•
Communication between the business executives and the developers (in order to ensure that the proposed changes are understood and the required critical functionality is maintained).
•
Rapid design coupled with minimal cost in communication and development (in order to allow rapid responses to urgent changes and emergency situations).
•
Simple documentation
To support the values, the following practices are applied:
•
Partition maintenance activities into three distinct states that support the management of emergency maintenance: the Emergency Maintenance state, the Post Emergency state and the Normal Evolution state.
•
Close collaboration between the business executives and the developers;
•
Merge business modeling, requirements gathering and analysis, and design into one exploration phase;
•
Adoption of an agile design process using pair-paper-prototyping and pair-telephone-prototyping;
•
Replace formal documentation with lightweight matrices. (See Figure 2 for an example of the matrix.)
Figure 1. State Diagram of Critical Feature Method
Figure 2 Critical Feature Matrix
6
Understanding influence factors on exploration phase CFMethod is distilled from the web development practice. An in-depth understanding of core values of the method is needed to investigate the effectiveness of the CFmethod. System dynamics approach provides a tool for modeling such a dynamic process.
We start with the modeling of the first phase of the maintenance lifecycle. Here, the factors influence the core values at “exploration phase” is examined using qualitative analysis approach. The exploration phase is illustrated in Figure 3.
Figure 3. Exploration phase
The terminologies used in Critical Feature Method are defined below: A “feature” is informally defined as a requirement, a user story, a use case or a change request depending on the experience of the business executive and the chief developer, and the company's convention. (Kong et al 2004) “Velocity of exploration” is defined as “prototyped-features per unit time”. “Quality of exploration” is the “defect density of the prototyped-features”. It is defined as “(failed prototyped features) / (total prototyped features)”. The unit of features is “Feature-Point” which is related to the size and the complexity of the feature. The quantitative definition of the feature point will be developed in the future research.
The core value “communication between the business executives and the developers” is embedded in the pair exploration activity in this phase. The value of “simple documentation” is reflected in the increase in the velocity of the exploration. The value of “rapid design” is reflected in the velocity and the quality of the prototyping. Consequently the main focus of the understanding of these three core values in the exploration phase is on the velocity and the quality of the exploration activity.
7
Influence factors onto exploration velocity The detailed influence factors to the exploration velocity are identified in Figure 4. The exploration velocity has two major components: “actual exploration velocity” and “potential exploration velocity”. The actual velocity of the exploration activity is influenced by the potential velocity and a number of complex factors as identified below.
Figure 4 Influence factors in exploration phase
8
Potential velocity Potential velocity of the exploration is defined as the velocity attained if the team uses the resources at the maximum level.
The major factors that influence the potential velocity include: team learning factor during the maintenance period (FactorLearning); ability to identify critical features, mutual understandability between the business executive and the chief developers (FactorMutualUnderstandability); available web patterns for the changes (FactorWebPatterns); design approaches
used
(FactorDesignApproach);
and
the
traceability
of
the
critical
feature
matrix
(TraceabilityCriticalFeatureMatrix) (See Figure 4).
Factors due to learning As the project proceeds, the team knowledge of how to do the project increases, hence the potential velocity increases. The learning curve is illustrated in Figure 5 (a). (Abdel-Hamid 1991, Weinberg 1982)
Figure 5 Learning curve and prototype approach influences
9
Ability to identify critical features When timeline is a major business requirement during an Emergency Maintenance State, the ability to identify and prioritize critical features will be crucial to both meet the business needs in tough timeline and maintain the quality of the web system. Ability to identify and analyse critical features will increase the potential velocity to explore critical features that are important to the business.
Mutual understandability The expertise of the business executives and the developers are in the business domain and technology domain respectively. The interpretation and transformation of the business features to the technological system features are influenced by the mutual understandability of the pair of the business executive and the chief developer. The degree of the mutual understandability can be impacted by the experience of working together; personality match; available web patterns for exploration; and the design approaches used. More the pair understands each other, higher the ability of the pair to identify critical features in a short time frame. For example, the potential velocity of a pair who have long term experience of working together is greater than the velocity of a new pair. White board prototyping face-to-face is more efficient than telephone prototyping in mental architecting.
Traceability of Feature Matrices In Critical Feature Method, two lightweight matrices “Critical Feature Matrix” and “Normal Feature Matrix” are introduced to replace the onerous conventional documentation. The design artifacts in the matrices are traceable to the business features. High traceability of the matrices will help to understand the existence of each artifact; increase the velocity to identify critical features; increase the mutual understanding of between the business executive and the chief developer. The more use of web patterns will make the tracing relationship in the matrix more effective.
Impact of web patterns The number of web patterns will increase the potential velocity of understanding and prototyping the requested features. During the Emergency Maintenance State, when the pair are physically isolated, a telephone prototype approach is used. Business patterns; architectural patterns; navigational patterns and user interface patterns that are used in the exiting web system will help the pair to understand the requested changes.
10
Impact of design approaches In three maintenance states, different design approaches are used. The effectiveness of the use of design approach is related to the effectiveness of the human communication approach. The relationship of communication effectiveness and the form of communication is illustrated in Figure 5 (b) (Cockburn 2005). The effectiveness of the prototype approach therefore decreases as the design approach changes from white-site prototyping, paper prototyping to telephone prototyping. See Figure 5 (c). However, the time to develop artifacts on three approaches increase as from white-site prototyping, paper prototyping to telephone prototyping. See Figure 5 (d). Telephone prototyping is based on the mental architecting without physical artifacts. The influence complexity of the design approaches onto the potential velocity at exploration stage will need further quantitative investigation in further research.
Actual velocity Actual velocity of the exploration activity (ActualVelocityExplore) is defined as a product of the “potential velocity” (PotentialVelocityExploration) and the “factor related to the maintenances state” (FactorMaintenanceState) and the “factor due to motivation losses” (FactorMotivation) (See Figure 4). ActualVelocityExplore = PotentialVelocityExploration*FactorMaintenanceState*FactorMotivation
Factor related to the maintenance state At Normal Evolution State, the team is able to utilize the resources with normal development pace at the maximum level. The level of FactorMaintenanceState affecting ActualVelocityExplore can be defined as 1. At Post Emergency State and Emergency Maintenance State, the actual velocity will be reduced respectively due to lack of the use of resources. See Figure 6 (a).
11
Figure 6. Influence by maintenance state and schedule pressure Schedule pressure Schedule pressure (SchedulePressure) and team loyalty to the business (FactorLoyalty) are two mayor factors that directly influence the motivation factors in the actual velocity. Schedule pressure can be defined as: SchedulePressure = (TotalDaysPerceivedNeeded-TotalDaysRemaingToDeadline)/TotalDaysRemaingToDeadline where
TotalDaysPerceivedNeeded is the estimated days that are needed to complete the remaining features.
TotalDaysRemaingToDeadline is the days remaining to the deadline set by the change requesters. If the estimated days that are needed to complete the remaining features are more than the days remaining to the deadline, the schedule pressure is positive. The schedule pressure is illustrated in Figure 6 (b). Under positive pressure, the team will increase the motivation by compress the slack time (e.g. time for reading mails, making-coffee and other non-project activities) to work on changing features. The number of working hours increased per person can be as much as 100% (Boehm 1981, Abdel-Hamid 1991).
Loyalty factor High level of employees’ loyalty to the business will increase the development motivation. The impact factors to the level of loyalty include the relationships of the team, leadership of team leader, individual salary, working conditions etc. In SMEs, usually some employees have close relationship with the business. During the Emergency Maintenance State these employees could maintain high loyalty and work overtime regardless of salary factors.
12
Conclusion and further research To gain insight understanding of agile methodologies, system dynamics approach is applied to the analysis of an agile method-CFMethod. Qualitative analysis of the influence factors in the major maintenance process is conducted. Major influences to the major project concern “velocity of the exploration phase” are modeled using influence diagram. This qualitative model establishes an important step for further quantitative modeling of agile methodologies. Our next research step will be the simulation of Critical Feature Method based on the qualitative model in this paper. The results from Critical Feature Method could be scaled up to other agile methodologies in the future research.
References Abdel-Hamid, T. (1991) “Software Project Dynamics, an Integrated Approach”, Englewood Cliffs, NJ. Prentice-Hall, Inc., 1991 Beck, K. (2000) Extreme programming explained: embrace change, Addison-Wesley, c2000 Boehm (1981) “Software Engineering Economics.” Englewood Cliffs, NJ. Prentice-Hall, Inc., 1981 Cockburn A. (2005)“Characterizing People as Non-Linear, First-Order Components in Software Development” Accessed 8 July 2005. Eckstein, J. (2003) Agile Software Development in the Large, Dorset House, 2003 EEAP (2002) “Summary of workgroup discussions”, Workshop on empirical evaluation of agile processes, XP/Agile Universe 2002 Kruchten, P. (2000) The Rational Unified Process: An Introduction (2nd Edition) Addison-Wesley, 2000 Lowe, D. & Eklund, J. (2001) Development issues in specification of web systems. The sixth Australia workshop on requirements engineering, Sydney, Australia, November, 2001 Martin, R. (2002) Agile Development: Principles, Patterns, and Process, URL http://www.agilealliance.org/, Accessed 8 July 2005 Misic, V., Gevaert, H., Rennie M. (2002) “Extreme dynamics: modelling the extreme programming software development process ”. Workshop on empirical evaluation of agile processes, XP/Agile Universe 2002 Padberg F. & Muller M (2003) “The costs and benefit of pair programming”. Proceedings of 9th international software metrics symposium, pp. 166-177 Sydney Australia, September 2003 Pressman, R. (2000) Software Engineering - A practitioner's approach, McGraw Hill, 5th Edition.2000 Weinberg, G.M. (1982) “Overstructured Management of Software Engineering.” Proceeding of the 6th international Conference on Software Engineering, Tokyo, Sept 1982.
13
