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.
Author(s): Clive Rosen
Publisher: Springer
Year: 2020
Language: English
Pages: 197
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
