Conversions on the net: the professionalism issue
ACM SIGCSE Bulletin
A field study of the software design process for large systems
Communications of the ACM
Four paradigms of information systems development
Communications of the ACM
Technomethodology: paradoxes and possibilities
Proceedings of the SIGCHI Conference on Human Factors in Computing Systems
Information systems and organizational change
Communications of the ACM
On approaches to the study of social issues in computing
Communications of the ACM
Programming is a part time job
SIGUCCS '75 Proceedings of the 3rd annual ACM SIGUCCS conference on User services
Death March
ACM SIGCAS Computers and Society
A deja-vu look at software engineering researchers who care about practice
Communications of the ACM
Debugging debugged, a metaphysical manifesto of systems integration
ACM SIGSOFT Software Engineering Notes
Software maturity: design as dark art
ACM SIGSOFT Software Engineering Notes
The limits of systems-making organizations
ACM SIGSOFT Software Engineering Notes
| Hi-index | 0.00 |
Most if not all complex issues stated as problems intended to result in new systems may be analyzed using systems decomposition and then constructed by synthesis. Systems decomposition starts with a complex problem that may or may not be obviously solvable and deconstructs that problem into smaller more tractable problems that can be solved. Construction by synthesis treats the smaller solutions as building blocks. The key practical advantage to synthesis is that it permits concurrency of construction. The subsystems may be developed and tested independently in isolation. Not until integration will subsystems need to be brought together. Decomposition and synthesis are the ideal in theory. In practice there can be any number of problems. Potentially the most fatal of flaws can occur during decomposition where errors in abstraction lead to over-idealization of subsystem independence. Over-idealization leads to under-specification, that what is presumed to be independent is not. Once errors in subsystem specification are made, independent development ensures that undetected dependencies will remain undetected. Subsystem dependencies are hidden time bombs, dormant until the subsystems are brought together for systems integration. In systems integration the latent dependencies interact and explode in a manner most combinatorial. The term often used to describe the excitation of dormant dependencies is "emergent behavior". Emergent behavior is but one factor that plagues the integration of large software intensive systems. There have been few published analyses or case studies dedicated to systems integration, in particular analyses deemed useful as "lessons learned" for others to follow. This paper takes a hesitant first step, not towards a "lessons learned" but towards the meta, an estimation of the boundaries of what it might take before one can provide a useful "lessons learned".