The Dynamics of Software Project Staffing: A System Dynamics Based Simulation Approach

Size: px

Start display at page:

Download "The Dynamics of Software Project Staffing: A System Dynamics Based Simulation Approach"

Rudolph Robertson
8 years ago
Views:

1 The Dynamics of Software Project Staffing: A System Dynamics Based Simulation Approach IEEE Transactions on Software Engineering(TSE, 1989) TAREK K. ABDEL-HAMID Park, Ji Hun

2 Contents Introduction Background Overall approach Conclusion Discussion 2 / 24

3 Problem statement Introduction In 1989, people issues have gained recognition There is lack of researches on the whole life cycle of software development as an integral It is remarkably difficult to test hypothesis in software engineering In this paper, Suggests system dynamics simulation of software development process Integral model to describe software development process Formal method to verify hypothesis in software engineering 3 / 24

4 Background (1/3) System dynamics model Approach to understanding the behavior of complex system over time Looking at things as a whole Simulation large system with feedback and loop Source Rate LEVEL 4 / 24

5 Background (2/3) System dynamics model (cont d) Source Rate LEVEL Rate Sink Level : accumulation over time of flows Rate : The flows increasing and decreasing a level Input Auxiliary Output Input Auxiliary : Intangible, additional algebraic computations 5 / 24

6 Background (3/3) System dynamics model (cont d) Flows Information Flows Other Flows (e.g., People, Software) Constant Constant Variable cross-reference Influencing Variable that is on Other Diagram Variable Being Influenced on Other Diagram 6 / 24

7 Integrative System Dynamics Model of Software Development An integrative perspective Including management-type functions and software production-type activities Four subsystems Human resource management Progress status Software Production Work force available Work force needed Tasks completed Schedule Controlling Effort remaining Planning 7 / 24

8 The human resource management subsystem(1/8) CEILING ON NEW HIRES MOST NEW HIRES PER FT EXP STAFF HIRING DELAY AVEARAGE ASSIMILATION DELAY FTE EXPERIENCED WORKFORCE AVEARGE EMPLOYMENT TIME HIRING RATE NEWLY HIRED TRANFER RATE TRANSFER DELAY NEWLY HIRED WORKFORCE WORKFORCE ASSIMILATION RATE TOTAL WORKFORCE EXPERIENCED WORKFORCE EXPERIENCED TRANFER RATE TRANSFER DELAY QUIT RATE CEILING ON TOTAL WORKFORCE WORKFORCE GAP WF LEVEL SOUGHT WORKFORCE LEVEL NEEDED

The human resource management subsystem(2/8) Separating the workforce into two categories Orientation phase For newly hired and transferred from other project members Both technical as well as social

9 The human resource management subsystem(2/8) Separating the workforce into two categories Orientation phase For newly hired and transferred from other project members Both technical as well as social dimensions They are less than fully productive Training process Training of new comers is usually carried by experienced staffs Newly hired It takes 15% ~ 25% of an experienced employee s time Experienced Communication overhead 9 / 24

The human resource management subsystem(3/8) Workforce level needed Indicated workforce level Workforce level which is necessary to complete the project on schedule Workforce level needed =

10 The human resource management subsystem(3/8) Workforce level needed Indicated workforce level Workforce level which is necessary to complete the project on schedule Workforce level needed = (Indicated workforce level) * (WCWF) + (Current workforce) * (1 WCWF) WCWF : Willingness to Change WorkForce gap Weight factor Indicated workforce level Current workforce WCWF : 1-WCWF 10 / 24

11 The human resource management subsystem(4/8) Willingness to Change WorkForce(WCWF) WCWF-1 Capturing the pressures for workforce stability Increases when Time remaining / Time parameter increases Time parameter = Hiring delay + Average assimilation delay 11 / 24

12 The human resource management subsystem(5/8) Willingness to Change WorkForce(WCWF) (cont d) WCWF-2 In organizations such as NASA, serious schedule slippages could not be tolerated Increases when Scheduled completion date / Maximum tolerable completion date increases 12 / 24

13 The human resource management subsystem(6/8) Willingness to Change WorkForce(WCWF) (cont d) WCWF = MAX ( WCWF-1, WCWF-2) When the early phase of the project, WCWF-2 would be zero When the project reaches to the end, usually WCWF is dominated by WCWF-2 WCWF is an expression of a policy for managing Also, the shapes of the WCWF policy curves can be derived on the basis of historical project records 13 / 24

14 The human resource management subsystem(7/8) Ceiling on total workforce Workforce Level Needed level does not translate necessarily into actual hiring goal Full-time-equivalent Exp workforce Most new hires per FT Exp Staff Ceiling on new hires 14 / 24

15 The human resource management subsystem(8/8) Workforce gap Workforce Level Sought = MIN(CELTWF, WFNEED) CELTWF = CEiLing on Total WorkForce WFNEED = WorkForce level NEEDed Workforce gap = Total Workforce Workforce level sought Workforce gap < 0 Total Workforce Workforce gap > 0 Hiring delay Transfer delay Hire new employees Transfer workforce out of the project 15 / 24

16 The model s other subsystem(1/2) Software production subsystem Software development rate Software development productivity Man power Software developed Software testing rate Software testing productivity Software tested 16 / 24

17 The model s other subsystem (2/2) Planning Subsystem Indicated workforce = Man-days remaining Time remaining 40 = (per day) Required time to complete project Man-days remaining Workforce Level sought 17 / 24

18 Model experimentation (1/2) NASA s DE-A software development project NASA s launch of the DE-A satellite was tied to the completion of the DE-A software Because of strict deadline, workforce curve rises in the final stages of the project Brooks law? Adding manpower to a late software project makes it later 18 / 24

19 Model experimentation (2/2) The simulated project behavior The model s results conformed quite accurately to the project s actual behavior 19 / 24

20 Applicability of Brook s law to the DE-A Project (1/2) Time Parameter as a hiring policy No more hiring on the project s final stage It shows that the simulated project takes 60 more days than actual project Simulating DE-A with the time parameter set to 100 (Time parameter = Hiring delay + average assimilation delay In this case, WCWF = WCWF-1) 20 / 24

21 Applicability of Brook s law to the DE-A Project (2/2) Training & communication overhead vs. productivity gained Net impact of adding more people The cumulative contribution Impact of different staffing policies on cost and schedule Brook s law only holds in this range In this model, Brooks law is not supported totally 21 / 24

22 Contribution Conclusion An integrative model that captures the multiple functions of software development The computer simulation tools of system dynamics A formal model of the software development process Future work Model enhancement Extending on requirements analysis phase, multiple projects, large-scale project, quality New modeling applications 22 / 24

23 Pros Discussion It gives comprehensive simulation model Cons Considering this paper(book) s scope, more case studies are needed 23 / 24

25 Brooks law Brooks law Adding manpower to a late software project makes it later» F. P. Brooks, Fr. The Mythical Man-Month. It has not been formally tested 25 / 24

26 Average assimilation delay Average assimilation delay Formulated as a first-order exponential delay Average Time Delay (T) At any time (t), R(t) = L(t) / T Also, d/dt L(t) = -R(t) = -L(t)/T LEVEL (L) Rate (R) Finally, L(t) = L(0)e -t/t And it can be shown that the average time spent in the delay = T 26 / 24

27 Communication overhead Communication overhead Increases in proportion to n 2 where n is the size of team >> F. P. Brooks, Jr. The Mythical man-month >> H. D. Mills, Software development, IEEE Trans. Software Eng. Vol. SE-2 no. 5, Dec / 24

28 How is progress measured? (1/2) How is progress measured in a s/w project? (1/2) In the early phase, progress is measured by the rate of expenditure of resources In this situation, MDPRNT = MDPNNT MDPRNT : Man-Days Perceived Remaining for New Tasks MDPNNT : Man-Days Perceived still Needed for New Task 28 / 24

29 How is progress measured? (2/2) How is progress measured in a s/w project? (2/2) MDPRNT = MDPNNT MDPNNT = TSKPRM / PRDPRD MDPRNT = TSKPRM / PRDPRD As a result, the assumption suggests that value of productivity is solely a f u n c t i o n of f u t u r e p r o j e c t i o n s PRDPRD = TSKPRM / MDPNNT TSKPRM : Tasks Perceived Remaining PRDPRD : Perceived Development Productivity As the project advances towards its final stages, ACTPRD = CUMTKD / CUMDMD ACTPRD : Actual Development Productivity CUMTKD : Cumulative Tasks Developed CUMDMD : Cumulative Man-Days Expended 29 / 24

30 De-A Project s actual statistics De-A Project s actual statistics Name Value Project size DSI Cost - Initial estimate 1100 man-days Cost - actual 2220 man-days Completion time - initial 320 days Completion time - actual 380 days Staffing-type parameter Average productivity of exp. staff vs. that for new hires 2 : 1 Hiring delay 1.5 months Average assimilation delay 1 month Average transfer delay 2 weeks Turnover rate 20 percent Average effort committed to train new hires 25 percent c KAIST SE LAB 2009

Appendix: Dynamics of Agile Software Development Model Structure

Appendix: Dynamics of Agile Software Development Model Structure This study was conducted within the context of a much broader research effort to study, gain insight into, and make predictions about the