These notes are an expansion of the material that may be found in:
Abdel-Hamid, Tarek, and Mdnick, Stuart E., Lessons Learned from Modeling the dynamics of Software Development, Communications of the ACM, December 1989, Volume 32, Number 12, page 1426-1438.
Assignment: In the original paper is a model that was developed using System Dynamics to show the impacts of alternative policies and decisions that try to keep a software project on schedule. Your task is to suggest at least one extension in the form of at least one added causal relationship to extend the basic model. There will be a question activity created for this assignment.
History of Software Development: cost overruns, late deliveries, poor reliability and users’ dissatisfaction.
Advances have been tired in the technology of software production: structured programming, structured design, formal verification, language design for more reliable coding, diagnostic compiles, case tools.
Managerial considerations often neglected in research on problem:
"Perhaps this is so because computer scientists believe that management per se is not their business, and the management professionals assume that it is the computer scientists’ responsibility."
(Cooper, I. D., Corporate level software management, IEEE Trans. Software. Engineering. SE-4, No. 4, July 1978, 319-325)
Critical Management Decisions and Issues in Software Production
What is the distribution of effort in the phases of development (e.g. ratio between development and testing)?
What are the reasons for the implications of the differences between potential productivity, actual productivity, and perceived productivity?
Why does the "90% completion syndrome" chronically recur?
Simple model of software production
A project control and measurement system that measures progress as related to original or modified goals and objectives.
More detailed considerations of changing the project:
Adding more people to a late project leads to higher communication needs among the project team and training overheads for new people. the larger the project, the closer to completion results in more effort needed for training of new people. Usually only a viable solution early in a project effort.
Adding more effort to a late project: Encouraging current staff to work more (examples of doubling effort in literature) and/or concentrating on only the essential tasks. Resulting effort produces higher pressure on people which results in more errors and forces greater amount of rework. Putting off "non essential tasks" such as documentation and comprehensive testing leads to some errors or problems not being caught till later when they then tend to cause a greater amount of reworking.
Added pressure increases the error rate and the amount of rework on the project.
"People under time pressure don’t work better, they just work faster….In the struggle to deliver any software at all, the first causality has been consideration of the quality of the software delivered." De Marco, T. Controlling Software Projects, Yourdon Press, 1982.
Software Production Model
How late is a late software project? Software is intangible until it is complete and therefore difficult for project managers to assess real progress (even when complete consider the Y2T problem). Complicated by human bias in estimation which is often optimistic (integration complexities often not well perceived in a large project).
The prior model is rather limited in that it does not really treat the total process and if one looks at a more complete model it would appear as follows
Overview of the Interaction of Various Development models
There are at least three major sub-models that interact during the lifetime of a software project. The more successful the product the greater is the revision of it over long periods of time. In other words the above is really a continuous or evolutionary process.
More detail for the design phase is given in the following model that shows the user interface design process with in the context of the over all life cycle process.
Balasubramanian, V.,, Ullman, David, Turoff, Murray, A Systematic Approach to Support the Creative Phases of the User Interface Design Process, HICCS 1998, Volume 2.
The User Interface Design Process within the context of the Software Development Life Cycle.
The user interface design process is made of the following three phases, as shown in the above figure.
Planning and Idea Generation: This is an early design activity where the designer reviews the requirements for an information system and mentally plans the various design elements of the user interface. We subscribe to the school of thought that system requirements are best gathered in the process of designing and refining the user interface for an information system.
Currently, designers do plan this phase either in the form of design notes or memos to users and other team members, but it is seldom structured. In addition, there are no guidelines or systematic support for this phase.
Prototyping and Design: A number of prototyping techniques have evolved over the past decade. Static prototyping, also called low-fidelity prototyping, relies on mockups, storyboarding and paper and pencil strategies. This is followed by dynamic or high-fidelity prototyping with the construction of the actual interface using UIMS or popularly known as Graphical User Interface Builders. The various manufacturers as well as windowing systems come with user interface design guidelines as to how to make the system more user-friendly. These builders also generate programs for the user interface layer which can directly be integrated with application and data layers.
Evaluation: At the end of the prototyping and design phase, a number of evaluation techniques can be employed to assess the usability of the resulting interface. These include well known strategies such as usability testing, usability engineering, heuristics evaluation, protocol analysis, cognitive walkthroughs, and controlled experiments. There are also guidelines for applying these techniques.
There have also been efforts to put guidelines online in the form of help systems and hypertext-based manuals (SIGCHI, 1995).
The best analogy is the database design process which also involves three phases: logical design (planning and modeling the entities and relationships using E-R diagrams), physical design (actually creating the database tables and procedures), and evaluation (testing the database using sample data). For the data modeling phase a number of systematic techniques and tools have evolved over these years. There is nothing similar for the planning and modeling phase of the user interface design process.
Software Production Continued
Many of the above considerations allow one to construct a working simulation model using system dynamics that allow us to investigate the relationships among management decisions and the resulting impacts on production. Decisions that can be modeled are those that affect specific software development process such as scheduling, productivity, and staffing to derive implications about the behavior of the total socio-technical system.
"The cause-effect relationships that exist in organizations are dense and often circular. Sometimes these causal circuits cancel the influences of one variable on another, and sometimes they amplify the effects of one variable on another. It is the network of causal relationships that impose many of the controls in organizations and that stabilize or disrupt the organization. It is the patterns of these causal links that account for much of the what happens in organizations." (Weick, K. E. The Social Psychology of Organizations. 2nd ed. Addison Wesley, Reading, Mass. 1979.
Human Resource Management Model:
The general software production model has four components
The prior sub-model is clearly missing the moral and commitment factors of the workforce and the many factors that can as a result influence turnover which is one of the critical measures of a technical organization.
Software Production Model
The quality assurance effort is clearly influenced by the resources committed to it and it is one of the areas that can be sacrificed in a crises situation where the project is behind and/or over budget.. There is not a complete sub-model for the funds/effort allocations or redistribution.
Another problem with the model is the lack of any integration of the impacts of users and their contributions to the atmosphere and moral of the development effort. Furthermore, the accuracy of requirements and the resulting changes to the system while it is under development is another key factor. The problems associated with the requirements definition phase are not included and it is assumed that phase was perfect and is not being revisited. There are no changes made to the project via changes in requirements. There is no incremental development and no changes based upon prototype trials or any product evaluation mechanism.
Even with these basic limitations the model does exhibit in its operation many of the basic management pitfalls of typical crises decisions made in the software production phase.
Some Basic Assumptions
Actual Productivity = Potential Productivity - Losses due to faulty processes.
Assumed that progress, especially in the earlier phases of software development, is typically measured by the actual expenditure of budgeted resources rather than by some count of accomplishments (supported in the literature).
What is 40% or 50% completion?
Initially the input is repeating the original plan, only when one nears completion does it become evident when things are not going right and hence we get the reaching the 90% level and staying there for some time.
The model places a very specific distinction between actual and perceived model variables. True productivity is very difficult to access:
"It is difficult to measure performance in programming. . . It is difficult to evaluate the status of intermediate work such as undebugged programs or design specifications and their potential value to the complete project." Mills, H. D. , Software Productivity, Little Brown and Co. Boston 1983.
Validation of the Model
Such models can be validated in a number of different ways:
Face validity: Using the estimates of experienced managers to estimate the various rate/level/feedback structures on both a qualitative and quantitative basis.
Replication of reference models: Taking the actual history of typical software projects and seeing the model can be tuned to generate a match to the history utilizing consistent values of the rate and correlation factors in the model.
Extreme Condition Simulations: Testing extreme conditions to ensure the model does not generate absurd behavior. This is a form of sensitivity analysis.
Sample Reference Model:
Project 24,000 delivered source instructions, IBM 360-95, FORTRAN. Project was estimated to be 1,100 person-days to be completed in 320 working days. Actual was 2,200 person days and 380 days to complete.
It was not till over day 200 that perception occurs that estimates are off and about 250 before crises mode goes into effect with brining in more people and pushing harder work (longer hours) of everyone. Workforce at end was about double of what it was at 300.
A different analysis
Classical estimation by Boehm’s COCOMO model for initial estimate of lines of code encourages the use of safety factors because:
In fact, biases are not so simple. Very large projects of a new type are often over estimated when the completion date is years in the future. Smaller more familiar type projects are often underestimated. In the latter people feel they can see the pieces that will be needed and underplay the problems of integration and consistency of those pieces. In very new long term projects they do not know all the pieces and therefore they are often over pessimistic. In theory there is a point in between where the estimator is accurate but it is not the same point for everyone.
Model does predict the increase of actual man days needed because of adding more people after a project has been underway. Higher work force level means more communication and training overhead on the part of those that are suppose to be working on the project.
More accurate estimates are necessarily better estimates. If one does over estimates people will find the way to fill up the time and the estimated will become accurate. Projects are never early. So safety factors can be a problem when it comes to the total resulting cost of the project.
Experimenting with the model
The model demonstrates that QA is a critical factor in the overall system behavior. The percentage of the total effort devoted to QA dramatically affects the cost.
At low values of QA expenditures, the increase in costs results from the high cost of the testing phase.
At high values of QA expenditures, the excessive QA expenditures are themselves the reason for high cost.
10 to 20 percentage seems to be the optimum range of the QA effort. There is no way one can conduct a whole series of field trials controlling for QA to try and establish this sort of information. It can only be observed from the construction of such a model.
Examination of Brook’s law: Adding more manpower to a late software project makes it later.
In fact this does not always occur. It certainly adds to the cost of the project but before the project will get later the impact on productivity of the individuals involved have a significant drop in productivity and the addition of people have to occur relatively late in the project. It now becomes clear that detection of problem early on by more accurate determination of progress is critical to being able to add more people in those situations where a schedule must be met.
Software production is a process with a great deal of causation feedback so that it is not always obvious what the results are of typical one dimensional decision.
The model in this paper was a good start but more comprehensive models of the process are waiting to be built.
Balasubramanian, V., Ullman, David, Turoff, Murray, A Systematic Approach to Support of the Creative Phases of the User Interface Design Process, Proceedings of HICSS 31, 1998, volume 6, page 425.
Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981 (the classic reference in the field)
Ben Shneiderman, Software Psychology, 1981 Addison Weseley.