Guide to Software Systems Development: Connecting Novel Theory and Current Practice

Description

This book argues that the key problems of software systems development (SSD) are socio-technical rather than purely technical in nature. Software systems are unique. They are the only human artefacts that are both intangible and determinant. This presents unprecedented problems for the development process both in determining what is required and how it is developed. Primarily this is a problem of communications between stakeholders and developers, and of communications within the development team. Current solutions are not only inadequate in expressing the technical problem, they also evade the communications problems almost entirely. Whilst the book addresses the theoretical aspects of the process, its fundamental philosophy is anchored in the practical problems of everyday software development. It therefore offers both a better understanding of the problems of SSD and practical suggestions of how to deal with those problems. It is intended as a guide for practising IT project managers, particularly those who are relatively new to the position or do not have a strong IT development background. The book will also benefit students in computing and computer-related disciplines who need to know how to develop high quality systems. Software systems development (particularly of large projects) has a notoriously poor track record of delivering projects on time, on budget, and of meeting user needs. Proponents of software engineering suggest that this is because too few project managers actually comply with the disciplines demanded of the process. It is time to ask the question, if this is the case, why might this be? Perhaps instead, it is not the project managers who are wrong, but the definition of the process. The new understanding of the SSD presented here offers alternative models that can help project managers address the difficulties they face and better achieve the targets they are set. This book argues that time is up for the software engineering paradigm of SSD and that it should be replaced with a socio-technical paradigm based on open systems thinking. Preface Why Software Systems Development? Why is This? References Contents 1 A New Approach to Software Systems Development 1.1 Introduction 1.2 “Models”, “Methodologies” and “Methods” 1.2.1 Models 1.2.2 The SDLC Model 1.2.3 Methodologies 1.2.4 Methods 1.2.5 Consequences of Confusing Models, Methodologies and Methods 1.2.6 A Model for Choosing a Methodology 1.3 The Appeal of Software Engineering 1.4 A New Model? 1.5 Discussion Questions References 2 The Nature of the Beast 2.1 Introduction 2.2 The Nature of Software 2.3 The Nature of a Software System’s Requirements 2.3.1 The Ambiguity of Natural Language 2.3.2 Non-functional Requirements (NFR) 2.3.3 Emergent Requirements 2.3.4 Tacit Knowledge 2.3.5 Exceptions/Anomalies to the Process 2.3.6 Volatility of Requirements 2.3.7 Summarising Requirements 2.4 The Nature of a Software System’s Users 2.4.1 Categories of Stakeholder 2.4.2 Conflict of Interest 2.4.3 Status of Stakeholders 2.4.4 Conclusions Regarding Stakeholders 2.5 The Nature of Communications Between Users and Developers 2.5.1 Access 2.5.2 Language and Culture 2.6 The Nature of the Problem 2.7 A Model of the Problem 2.8 A Paradigm for the Problem 2.9 Conclusion 2.10 Discussion Questions References 3 Software Systems Development: An Open Systems Perspective 3.1 Introduction 3.2 What Is an Open System? 3.3 An Open Systems Perspective of SSD 3.3.1 The Interface Between People and Software Systems 3.3.2 The Consequences of the Interaction Between Software Systems and Its External Environment 3.3.3 People in the Software Systems Development Process 3.4 Why Not Open Systems? 3.5 Conclusion 3.6 Discussion Questions References 4 Team Management 4.1 Introduction 4.2 Theory X Versus Theory Y 4.3 Contingency Theory 4.4 Communication Skills 4.4.1 The Person to Person Communication Level 4.4.2 Active Listening 4.4.3 Interpreting Information 4.4.4 Intra-group Communication 4.5 Inter Team Dynamics 4.6 The Role of the Project Manager 4.7 Manager’s Power and Authority in the Team 4.8 Conclusion 4.9 Discussion Questions References 5 Project Management Decision Making 5.1 Introduction 5.2 Top Down Decision Making 5.3 Bottom Up Decision Making 5.4 SWOT and SVOR 5.5 Selecting from Potential Projects 5.5.1 Strategic Versus Tactical Projects 5.6 Feasibility 5.6.1 Risk Assessment 5.6.2 Cost Estimation 5.7 Capability Assessment 5.8 In-house or Third Party Development 5.9 Informatics 5.10 Systems Procurement Options 5.10.1 Bespoke and Integration Projects 5.10.2 Tailored Projects 5.10.3 Component Off the Shelf 5.10.4 End User Developments 5.10.5 Procurement Option Conclusion 5.11 Cost/Benefit 5.12 Conclusion 5.13 Discussion Questions References 6 Software Systems Quality Assurance and Evaluation 6.1 Introduction 6.2 Context 6.3 Classical Approaches to Software Quality 6.3.1 Theoretical Background to SSD Quality 6.3.2 Software Process Improvement (SPI) 6.4 Definition 6.4.1 Hierarchical Models 6.4.2 Meta-Models 6.4.3 Statistical Models 6.4.4 Non-functional Requirements (NFR) 6.5 Quality Metrics, Measurement and Evaluation 6.6 Development Realities 6.6.1 The Programmer’s Dilemma 6.6.2 The System’s Developer Dilemma 6.6.3 Design Patterns 6.6.4 Model Driven Development (MDD) 6.6.5 Test Driven Development (TDD) 6.7 Quality at the Interface 6.8 Culture Not Compliance 6.9 Discussion Questions References 7 So What? 7.1 Introduction 7.2 Implications of the Theory and for Theory 7.3 Practical Application of the Theory 7.3.1 Greater Priority Given to Requirements Elicitation 7.3.2 Project Management 7.3.3 Staff Selection, Development and Relationships 7.3.4 Changes Arising from the Relationship Between Theory and Practice 7.3.5 Curriculum Changes Arising from the Theory 7.4 Future Research 7.5 Professionalisation of Software Systems Development 7.6 Last Words 7.7 Discussion Questions References Appendix A Dimensions of Team Dynamics An Instrument for Facilitating Group Observation and Enhancing Team Effectiveness Introduction What is the DoTD Approach? Valency of Vision Leadership and Initiative Taking Structure and Flexibility Group or Self-Reliance Task or Social Orientation Acceptance of Responsibility Self Belief How to Use DoTD How does DoTD Compare to other Approaches? References Appendix B Dimensions of Team Dynamics Observation Sheet Appendix C Exercise: The Click and Collect Catalogue Company Instructions for Exercise Leaders Running the Exercise Overview Strategists’ and Architect’s Briefing Paper Agenda for Meeting 1 Agenda for Meeting 2 Project Management Team Briefing Paper Agenda for Meeting 1 Agenda for Meeting 2 Development Management Team Briefing Paper Agenda for Meeting 1 Agenda for Meeting 2 User Group Briefing Paper Agenda for Meeting 1 Agenda for Meeting 2 Consultants’ Briefing Paper Preliminary Report Project Overview Project Plan Current Status Current Staff Assignments Comments on Project Management Agenda for Meeting 1 Agenda for Meeting 2 Directors’ Briefing Paper Agenda for Meeting 1 Agenda for Meeting 2 Index