Module connection analysis: a tool for scheduling software debugging activities

Authors:
Frederick M. Haney
Affiliations:
Xerox Corporation, El Segundo, California
Venue:
AFIPS '72 (Fall, part I) Proceedings of the December 5-7, 1972, fall joint computer conference, part I
Year:
1972

Citing 0
Cited 6

Measuring the Ripple Effect of Pascal Programs

IWSM '00 Proceedings of the 10th International Workshop on New Approaches in Software Measurement
The architecture of software

ACM SIGMIS Database
Searching for relevant software change artifacts using semantic networks

Proceedings of the 2009 ACM symposium on Applied Computing
A study of ripple effects in software ecosystems (NIER track)

Proceedings of the 33rd International Conference on Software Engineering
The transformation of requirements into software primitives: Studying evolvability based on systems theoretic stability

Science of Computer Programming
How do developers react to API deprecation?: the case of a smalltalk ecosystem

Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering

Quantified Score

Hi-index	0.00

Visualization

Abstract

The largest challenge facing software engineers today is to find ways to deliver large systems on schedule. Past experience obviously indicates that this is not a well-understood problem. The development costs and schedules for many large systems have exceeded the most conservative, contingency-laden estimates that anyone dared to make. Why has this happened? There must be a plethora of explanations and excuses, but I think H. R. J. Grosch identified the common denominator in his article, "Why MAC, MIS and ABM will never fly." Grosch's observation is essentially that for some large systems the problem to be solved and the system designed to solve it are in such constant flux that stability is never achieved. Even for some systems that are flying today, it is obvious that they came precariously close to this unstable, "critical mass" state.