Software Development Activity Cycles: Collaborative Development, Continuous Testing and User Acceptance 1484282388, 9781484282380

Citation preview

Software Development Activity Cycles Collaborative Development, Continuous Testing and User Acceptance — Robert F. Rose

Software Development Activity Cycles Collaborative Development, Continuous Testing and User Acceptance

Robert F. Rose

Software Development Activity Cycles: Collaborative Development, Continuous Testing and User Acceptance Robert F. Rose Alexandria, VA, USA ISBN-13 (pbk): 978-1-4842-8238-0 https://doi.org/10.1007/978-1-4842-8239-7

ISBN-13 (electronic): 978-1-4842-8239-7

Copyright © 2022 by Robert F. Rose This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Shiva Ramachandran Development Editor: James Markham Coordinating Editor: Jessica Vakili Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza, New York, NY 10004. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail [email protected], or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail [email protected]; for reprint, paperback, or audio rights, please e-mail [email protected]. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at http://www.apress.com/bulk-sales. Printed on acid-free paper

Books, books! There are dozens of books, hundreds of books, on every subject imaginable. So please, if you must write a book, make it a small one. —Anonymous Professor of History If you can’t describe what you are doing as a process, you don’t know what you’re doing. —W. Edwards Deming

Table of Contents About the Author��������������������������������������������������������������������������������xv Author’s Preface�������������������������������������������������������������������������������xvii Introduction���������������������������������������������������������������������������������������xix Chapter 1: The DPAC Model������������������������������������������������������������������1 About the Model����������������������������������������������������������������������������������������������������2 DPAC and PDCA�����������������������������������������������������������������������������������������������������2 DPAC Embraces Agile and DevOps������������������������������������������������������������������������4 Activities Represented in the DPAC Model������������������������������������������������������������5 Stages, Cycles, Phases, Parts, and Steps�������������������������������������������������������������8 The Inception Stage of Application Development��������������������������������������������9 The Elaboration Stage of Application Development���������������������������������������10 The Construction Stage of Application Development������������������������������������11 The Assembly Stage of Application Development�����������������������������������������12 The Evolution Stage and Retirement�������������������������������������������������������������������14 Paradigms as a Hindrance to Understanding������������������������������������������������������15 Summation����������������������������������������������������������������������������������������������������16

Chapter 2: Why Include Support in a Development Model?���������������17 Statement of the Problem�����������������������������������������������������������������������������������17 To Put This in Terms of Total Cost������������������������������������������������������������������������18 Regarding the Quality Payoff for the Adoption of DevOps and Other Discipline Practices�����������������������������������������������������������������������������������19 Putting Support in the Equation��������������������������������������������������������������������������20 v

Table of Contents

Freeing the Statue from the Stone����������������������������������������������������������������������24 Improving Maintainability�����������������������������������������������������������������������������������25 Ameliorative Measures During Development to Improve Software System “Maintainability”�������������������������������������������������������������������������������28 Political and Social Capital����������������������������������������������������������������������������������32 Summation����������������������������������������������������������������������������������������������������33

Chapter 3: The Inception Stage����������������������������������������������������������35 Vision Statement�������������������������������������������������������������������������������������������������37 Requirements Traceability Matrix�����������������������������������������������������������������������38 Nonfunctional Requirements������������������������������������������������������������������������������40 Planning for Information Security and System Security�������������������������������������43 Privacy����������������������������������������������������������������������������������������������������������������45 Staffing���������������������������������������������������������������������������������������������������������������48 Four Things Every (Successful) Project Manager Must Know:����������������������48 Summation����������������������������������������������������������������������������������������������������52

Chapter 4: The Elaboration Stage�������������������������������������������������������53 Activities During Elaboration�������������������������������������������������������������������������������54 PLAN Phase of the Process Overview Cycle��������������������������������������������������54 Do Phase of the Process Overview Cycle������������������������������������������������������55 Check Phase of the Process Overview Cycle������������������������������������������������55 Act Phase of the Process Overview Cycle�����������������������������������������������������55 Ongoing Activities�����������������������������������������������������������������������������������������������56 Database Administration�������������������������������������������������������������������������������56 Other Activities����������������������������������������������������������������������������������������������������57 Additional Responsibilities����������������������������������������������������������������������������������57 Data Flow Diagrams��������������������������������������������������������������������������������������������58 Functional Requirements Specification (FRS) vs. System Requirements Specification (SRS)���������������������������������������������������������������������������������������������58 vi

Table of Contents

Design Review����������������������������������������������������������������������������������������������������59 Successful Requirements Prioritization Requires Knowledge of:�����������������������59 Determine Staffing, Roles, and Responsibilities. Begin the Hiring Process for the Construction Stage��������������������������������������������������������������������61 Initial Roles from Inception����������������������������������������������������������������������������61 Roles Added During Elaboration (Start Recruiting During Inception)�������������61 Rules of the Road (Staffing)���������������������������������������������������������������������������62 Design, Develop, and Document the System Architecture����������������������������������67 Demonstrate an Operating Backbone for Shared System Functions������������������68 Application Design Requirements�����������������������������������������������������������������������68 Introduction to Configuration Management Database (CMDB)���������������������������70 The CMDB Shall Comprise at Least the Following Information���������������������71 The Traceability Matrix����������������������������������������������������������������������������������74 On Joint Application Development (JAD)�������������������������������������������������������74 On Workshops (In General)����������������������������������������������������������������������������������75 Summation����������������������������������������������������������������������������������������������������76

Chapter 5: The Construction Stage�����������������������������������������������������77 The Process Detail Cycle�������������������������������������������������������������������������������������79 Process Detail Cycle: Roles and Responsibilities������������������������������������������80 Business Rules May Take the Form of, But Are Not Restricted to, the Following������������������������������������������������������������������������������������������������������81 User interface (UI) testing������������������������������������������������������������������������������81 Operational Requirements�����������������������������������������������������������������������������82 Lookup Values�����������������������������������������������������������������������������������������������82 “Drop-Down” Values��������������������������������������������������������������������������������������82 Decision Tables����������������������������������������������������������������������������������������������82 Process Flow and Dependencies�������������������������������������������������������������������83 Rule-Based Constraints���������������������������������������������������������������������������������83 vii

Table of Contents

Business Definitions��������������������������������������������������������������������������������������83 Data Integrity�������������������������������������������������������������������������������������������������83 Compliance with Audit and Regulatory Requirements (a Nonfunctional Requirement Shaping Code)�����������������������������������������������83 Compliance with External Requirements for Certification (also a Nonfunctional Requirement Shaping Code)���������������������������������������84 Data Constraints��������������������������������������������������������������������������������������������84 Business Rule Review (in the Act Phase of the Process Detail Cycle)����������������84 Roles for Review Panel����������������������������������������������������������������������������������84 Requirements Inspection Checklist���������������������������������������������������������������85 Perspective���������������������������������������������������������������������������������������������������������86 Requirements Are Necessary������������������������������������������������������������������������86 The Unit Development Cycle�������������������������������������������������������������������������������88 Change Reports (CRpts)���������������������������������������������������������������������������������89 Keep Everything in Version Control���������������������������������������������������������������89 Configuration Management���������������������������������������������������������������������������91 Advancement�������������������������������������������������������������������������������������������������92 Unit Development������������������������������������������������������������������������������������������92 Test Plans������������������������������������������������������������������������������������������������������94 Iterative Development�����������������������������������������������������������������������������������94 Code Check����������������������������������������������������������������������������������������������������94 Technical Review Subcycle���������������������������������������������������������������������������94 Test-Driven Development (TDD)��������������������������������������������������������������������95 True to Requirements������������������������������������������������������������������������������������95 Inspections����������������������������������������������������������������������������������������������������97 The Triad Principle��������������������������������������������������������������������������������������������101 Staffing for the Construction Stage�������������������������������������������������������������101 Essential Roles��������������������������������������������������������������������������������������������104 Summation��������������������������������������������������������������������������������������������������104 viii

Table of Contents

Chapter 6: The Assembly Stage��������������������������������������������������������107 Service Assembly and System Integration Cycles��������������������������������������������108 Service Assembly����������������������������������������������������������������������������������������������108 Continuous Integration (CI), Continuous Delivery (CD), and All That Jazz…��������������������������������������������������������������������������������������������109 Disadvantages of Test Automation��������������������������������������������������������������110 Roles and Responsibilities���������������������������������������������������������������������������112 The Emerging Role of the DevOps Engineer������������������������������������������������113 Systems of Record (SORs) and Systems of Engagement (SOE)������������������115 Test Data Management��������������������������������������������������������������������������������116 The Agile DBA����������������������������������������������������������������������������������������������117 DevOps and the Database���������������������������������������������������������������������������119 Summation��������������������������������������������������������������������������������������������������121

Chapter 7: The Evolution Stage��������������������������������������������������������123 The Deployment Cycle��������������������������������������������������������������������������������������124 Development of a Deployment Strategy������������������������������������������������������125 The Support Cycle���������������������������������������������������������������������������������������������126 Specifically, the Activities of Support Include����������������������������������������������126 There Are a Number of Processes, Activities, and Practices That Are Applicable to Software Support�������������������������������������������������������������127 About Software Support������������������������������������������������������������������������������128 Having a Permanent Support Team Has Many Benefits������������������������������129 Error Correction�������������������������������������������������������������������������������������������130 Bureaucratic Impediments��������������������������������������������������������������������������130 On the Difficulty of Correcting an Error During Support������������������������������132 Limited Understanding��������������������������������������������������������������������������������135 The technical challenges can in large measure be addressed by���������������136 Forces for Evolution�������������������������������������������������������������������������������������137

ix

Table of Contents

Lehman’s Laws��������������������������������������������������������������������������������������������138 DPAC Embraces Lehman’s Laws Completely����������������������������������������������142 Model of the Software Support Life Cycle (SMLC)���������������������������������������142 Version Staged Model����������������������������������������������������������������������������������144 The Importance of “Tribal Knowledge”��������������������������������������������������������147 Summation��������������������������������������������������������������������������������������������������148

Chapter 8: Risk Management�����������������������������������������������������������149 General Mayhem�����������������������������������������������������������������������������������������������149 Loss of Key Personnel: Missing a Window of Opportunity��������������������������������150 Software Development Always Has a Political Dimension��������������������������������151 Unrealistic Expectations. Lack of a Competent Project “Champion”����������������151 Missing Man������������������������������������������������������������������������������������������������������152 Keep Documentation Up-to-Date����������������������������������������������������������������������153 Missing Tools: Loss of “Tribal Knowledge”��������������������������������������������������������155 Missing Overview����������������������������������������������������������������������������������������������155 Lack of Quality Engineering Measures��������������������������������������������������������������156 Lack of Proper Tools������������������������������������������������������������������������������������������157 Overoptimistic Level of Effort����������������������������������������������������������������������������158 “Man Month” Is a Unit of Cost, Not Progress����������������������������������������������������158 No Tool Alone Will “Fix” Gaps in the Business Model����������������������������������������158 Learning What a Tool Does Not Do��������������������������������������������������������������������159 Lack of Appropriate Skills���������������������������������������������������������������������������������159 “Round Up the Usual Suspects!” (Claude Rains, Casablanca, 1942)�����������160 Boehm’s Risk Management-Driven Spiral Model���������������������������������������������162 Necessary Elements�����������������������������������������������������������������������������������������164 Summation��������������������������������������������������������������������������������������������������165

x

Table of Contents

Chapter 9: Engineering Software Quality������������������������������������������167 Software Quality Defined����������������������������������������������������������������������������������167 Meets the Needs of the User�����������������������������������������������������������������������������168 Robust���������������������������������������������������������������������������������������������������������168 Easy to Use (User-Friendly)�������������������������������������������������������������������������������168 Easy to Maintain�����������������������������������������������������������������������������������������������169 Software Quality Assurance (SQA)��������������������������������������������������������������������171 Ongoing Documentation�����������������������������������������������������������������������������������172 Data Flow Diagram (DFD)����������������������������������������������������������������������������������174 Configuration Management (CM)����������������������������������������������������������������������175 CMDB����������������������������������������������������������������������������������������������������������������177 Change Reports (CRpts) and Discrepancy Reports (DRs)����������������������������������178 The Hardware Configuration Inventory (HWCI)��������������������������������������������������178 Change Control��������������������������������������������������������������������������������������������179 Status Accounting���������������������������������������������������������������������������������������������180 Audits����������������������������������������������������������������������������������������������������������������181 Test�������������������������������������������������������������������������������������������������������������������183 Test-Driven Development (TDD)������������������������������������������������������������������������183 Perform Test������������������������������������������������������������������������������������������������������185 Data-Related Quality Engineering���������������������������������������������������������������������185 Conversion Plan������������������������������������������������������������������������������������������������186 Measure Twice Cut Once�����������������������������������������������������������������������������������187 Quality Engineering for Programming���������������������������������������������������������������187 Summation��������������������������������������������������������������������������������������������������189

xi

Table of Contents

Chapter 10: Final Remarks���������������������������������������������������������������191 Types of Software���������������������������������������������������������������������������������������������191 Types of Implementation�����������������������������������������������������������������������������������192 DPAC Activity Cycles�����������������������������������������������������������������������������������������192 Staffing�������������������������������������������������������������������������������������������������������������193 Tester and Programmer Pairs���������������������������������������������������������������������������194 On Tools�������������������������������������������������������������������������������������������������������������195 Regarding Tools for Automated Testing�������������������������������������������������������������196 The Tool-Scape Is Changing������������������������������������������������������������������������������197 No Silver Bullet (Brooks)�����������������������������������������������������������������������������������198 Categories of Essential Tools����������������������������������������������������������������������������199 Dr. Winston W. Royce vs. the “Waterfall”����������������������������������������������������������200 Kudos�����������������������������������������������������������������������������������������������������������205 Conclusion��������������������������������������������������������������������������������������������������������205

Appendix A: Software Quality Defined����������������������������������������������207 A  ttributes of Quality������������������������������������������������������������������������������������������207 International Organization for Standardization (ISO)�����������������������������������207

 Appendix B: Summary of Standards, Guidelines, and Procedures���������������������������������������������������������������������������������������217 Appendix C: Quality Engineering: By Area����������������������������������������223 Appendix D: Data Flow Diagramming�����������������������������������������������227 D  ata Flow Diagrams������������������������������������������������������������������������������������������227 L eveling�������������������������������������������������������������������������������������������������������������230 Why Draw a Data Flow Diagram�����������������������������������������������������������������������231 A Fictitious Example (Reductio Ad Absurdum)��������������������������������������������������233 Our Goal Is to Improve Customer Service Regarding Claims Management������234 xii

Table of Contents

Process Narrative (System to Be)���������������������������������������������������������������������234 D  ata Dictionary�������������������������������������������������������������������������������������������������242

Resources by Category���������������������������������������������������������������������245 Resources by Author.������������������������������������������������������������������������257 Index�������������������������������������������������������������������������������������������������267

xiii

About the Author Robert F. Rose has provided services to both private and public sectors including telecom and healthcare, NavAir, the Environmental Protection Agency (EPA), and Housing and Urban Development (HUD). His experience includes pioneering design and development of a warehouse system for storing and analyzing medical records, design and development of an early prototype logistics tracking system for the V22 Osprey, and design and implementation of a complex enterprise-wide web-based directory system. Among his accomplishments, he was Technical Project Manager for the Presidential Commission’s Inquiry on the Challenger Disaster. The DPAC model is the product of independent efforts both in management and in preparation of the technical approach section for various responses to requests for proposals (RFP). Now retired, Robert has pulled together the sum of his experience with the process of developing software into the DPAC framework. It is entirely original work and not derived from other approaches. He can be contacted at [email protected]

xv

Author’s Preface I should say from the outset, as of this writing, the DPAC model has not been used in practice. This is a concept paper, applied to a hypothetical example. That being said, I contend that the “Cycles of Activity” represented in the DPAC paradigm are representative of human activity in every information system development effort. DPAC makes a clear separation between human activity and the progress of software throughout the process. While the model is entirely original, my interpretation of the cycles has been informed by the long list of works contained in the Resources by Category and Alpha Listings. I have included books only. There are only a few articles cited in the book, most of them in Chapter 2. This belies the very large number of articles that were reviewed to find the best of the best, most relevant to the current discussion. Too many, in my opinion, to be listed for productive assistance. Regarding citations of materials found online, rather than using a web address, which changes for a specific item even as we speak (so to speak), I have cited “Google” which means Google the title to find the item at its current location. Not only do web addresses change, but in the current period companies are being gobbled up by other companies such that entire .com addresses are changing. Every effort has been made to contact the source of materials used herein – seeking permission for use. Some have been unresponsive quite possibly due to the fog of a merger. I apologize if I have given offense. Attribution has been provided nonetheless.

xvii

Author’s Preface

In this interpretation, DPAC is a fully “shift left” model, taking current trends to their “logical and absurd” conclusion. If nothing else, it should have heuristic value, although I believe it has merit in and of itself. I started building my technical library in 2012 and copyrighted the DPAC model with the present Chapter 1 in 2015. My earliest versions of the model stretch back to the mid-1990s. In the intervening years, my library was built up following industry trends – an expensive endeavor at best. I think we are now (2022) at a plateau where “stovepipe” thinking can be reduced or eliminated. I hope DPAC will help turn our thinking about software development around the corner. I would like to thank the folks at Apress – Jessica, Jim, and Shiva – for stewarding the manuscript through the travails of creating a book and for their patience with my occasional outbursts of panic as I leapt into the unknown. And special thanks to my support group for their kindness and encouragement over the years my “writing project” took to come to fruition. Carolyn, Diane, Doran, Jim, Jolene, Pam, and Richard – you helped more than you know.

xviii

Introduction Intent and Purpose The first computer I ever saw was playing Jingle Bells. It was 1958, on the ground floor of the DuPont engineering building near Wilmington, Delaware. The Univac computer was built around vacuum tubes and solenoids that buzzed and hummed while computing. A group of engineers, clearly making use of any free time, wrote a nonsense program that matched the noises to Christmas carols. I was mesmerized. My career in IT did not begin until a decade later in 1969 as a FORTRAN programmer. I started building systems in 1976. My first system was a small Management Information System (MIS) that was concluded with great success. My second effort was a system an order of magnitude more complex. After one flop at the start, it was completed but never deployed – giving me a strong sense of project risk. I started thinking about the process of developing software in the 1980s to respond to the technical approach section of various RFPs (requests for proposals). The DPAC model has evolved from that process through my direct participation over 35 years in six software development projects. There was no direct influence from other models. DPAC reflects my thinking since circa 1995; the DPAC model in its present form was copyrighted in 2015. Having also participated as a technical troubleshooter cleaning up systems after the developers “left the building,” I experienced firsthand that many issues in support are directly related to the quality of the software development effort.

xix

Introduction

The model described herein represents a continuum beginning with inception into ongoing evolution. While retirement seems inevitable, there are systems that are still going strong through decades of use. Legacy systems may need to be enhanced to enjoy the delights of user-facing web and mobile experiences. Another thing the DPAC model is designed to address is the derivation of functional requirements throughout the development process beginning with a Vision Statement and continuing into the Support Cycle. To that end, the cycles of activity in the DPAC model are represented as recursive and re-entrant, nested contiguous ovals. Each activity cycle is overlaid with an interpretation of the Deming quality control phases of Plan, Do, Check, and Act (PDCA).

The DPAC Model

xx

Introduction

The DPAC Model and Chapters at a Glance A model, as used in this context, is a graphic representation of the development processes. A tour through the DPAC model begins in Chapter 1. The larger case for development to keep software support in mind is presented in Chapter 2. Chapter 3 defines the Inception Stage, while Chapters 4–7 are walk-throughs of the Elaboration, Construction, Assembly, and Evolution Stages, respectively. Each of these chapters begins with the model diagram at the top highlighting the part of the model the chapter describes and where it fits in the overall process. Chapter 8 presents a summary of personal experiences with risk. Chapter 9 is a short exposition on Engineering Software Quality. Chapter 10 contains Final Remarks. Until now there has been no generalized model of the course of activities over all the application life stages. The DPAC model brazenly claims to fill that gap. In fact, I contend that it is the optimum model of geometric efficiency. It also describes a singular path of development, including recursive flows.

DPAC does for agile what Waterfall does for traditional methods of development.

The Tower of Babel 5 But the LORD came down to see the city and the tower that the men were building. 6 The LORD said, “If as one people speaking the same language they have begun to do this, then nothing they plan to do will be impossible for them. 7 Come, let us go down and confuse their language so they will not understand each other.” Gen 11:5-7 New International Version xxi

Introduction

Vocabulary informs our view of reality. As used herein, the term “User Acceptance-Driven Development (UADD)” is a superset of specification by example, behavior-driven development (BDD), and acceptance test-driven development (ATDD). Each of these methods has one thing in common. They are all dependent upon agreement by the user that the subject of analysis is covered. They all can use the triad approach of developer, tester, and client to achieve those objectives (collaborative development). UADD contends that it is user feedback that drives the development effort. Test-driven development (TDD) and refactoring are techniques used to reduce error and produce clean code.

Where, please, will the miracle occur? The odds are low that the needs of the user will be satisfied by a single meeting – no matter how long it may take, it is more likely than not that the process of Plan, Do, Test, and Review will require more than one pass. This is to say that the “little gray cells” need time to marinate on the problem. The problem of meeting the needs of the user continues through the Unit Development Cycle, Service Assembly, System Integration, and User Acceptance Test (UAT) just before the system is deployed.

The lack of a consistent terminology creates, to some degree, a waste of energy. In writing this book, one of the things I want to accomplish is to use a consistent vocabulary for describing a cyclical, iterative process. The DPAC model begins with the concept of Stages. Within each Stage are one or more cycles of activity. A Cycle is composed of phases, and a phase may have more than one part. “Step” can be used colloquially for any succeeding element. xxii

Introduction

QE, QA, CM, and Test There are a number of issues regarding vocabulary rooted deeply into the thinking and practice of development. The first is to disambiguate Software Quality Assurance (SQA) from test. Software Quality Assurance in the domain of Quality Engineering (QE) is the maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery and production. In the QE paradigm, “Test” is an element of quality control (see breakout, SWEBOK v. 3, and relevant ISO standards). Software Quality Assurance (SQA) officers play a crucial role. The most important of the Process QA tasks is to assure the integrity of the traceability matrix by ensuring that work products are visible, traceable, and accountable – including audits – and that standards are met.

 se of the Term “Quality Assurance” in the PriU vate and Public Sectors All this is muddied by the difference in the use of the term Quality Assurance (QA) between the private and public sectors. Many federal agencies (e.g., Department of Defense (DoD), Small Business Administration (SBA), NASA) as well as guidance from the General Services Administration (GSA), Office of Management and Budget (OPM), and Federal Acquisition Requirements (FAR) require a separate SQA function. Similarly, state (e.g., NV, CA, IA) and local governments may be obliged to use the term QA for monitoring of the entire development process. Private sector entities, on the other hand, which tend to be focused on the Support Activity Cycle, may have a “QA Department” (meaning test) and no dedicated Quality Engineering function.

xxiii

Introduction

Herein after, I will use Software Quality Assurance (SQA) to represent Process Quality Control and will avoid the use of the term QA as a synonym for test.

Configuration Management Another clarification in thinking is to disabuse the notion that configuration management (CM) is only about code version control. CM applies to control of each class of work products from the evolution of requirements, tracing test scripts, a traceability matrix, to maintenance of “lookup” tables such as a personnel roster or task list. It is governed by the “rule of immutability” – whereby each version of each work product is regarded as unique and is stored accordingly. In most efforts, however, code version control is under the supervision of the technical team.

Use of the Term “Service” I have borrowed the term “service” to indicate a complete and independent component of code. “Service” implies function, while the term “module” is used from the perspective of the programmer. A service may comprise one or more units of code where a unit is the smallest stand-­ alone system component. For example, a web-based ecommerce site might include (at least) four services: (1) catalog, (2) cart management, (3) checkout, and (4) customer. (The term “service” in this regard from Max Martynov and Kirill Evstigneev, Continuous Delivery Blueprint, Grid Dynamics, np 2017–2018)

xxiv

Introduction

Units, Components, Services, and Systems A unit is the smallest piece of stand-alone code. A component comprises one or more units of code as a stand-alone generally with a GUI (graphical user interface). One or more components comprise a service, and one or more services comprise a system. All changes take place at the unit level of code.

Systems of Record vs. Systems of Engagement There is a significant difference between a System of Record (SOR) such as a Management Information System (MIS) and a System of Engagement (SOE) such as a mobile phone application. A SOR is developed from the inside out, where requirements are unknown or only sparsely defined up front, resulting in a set of user interfaces (or screens). A SOE is developed (or should be developed) from the outside in, where the user interface is described up front and the SOR to support it is defined therefrom. DPAC as applied to the example used herein is for a System of Record. A System of Engagement may be served by a data structure supplementing the System of Record, or, for security purposes, may be isolated as a separate system with available data updated from the SOR accessible to the SOE on a periodic (even hourly) basis. Keep SOR data for the SOE separate from the LAN and intranet. The mobile app will want to retrieve current billing information. The SOE would have the means for the user to pay the current bill.

xxv

Introduction

Quality Assurance, Quality Control, and Test. What’s the Difference?

June 23, 2016 – Blog Post – Functionize.com (Google) Organizations throw around terms quite a bit and sometimes interchangeably, even if they aren’t really synonymous. A prime example of this is with such terms like Quality Assurance (QA), Quality Control (QC) and Testing. Though they’re closely related, they are, ultimately, different. If you work in the IT industry, you’ve probably come across them. You’ve also probably noticed that many executives  – and customers – don’t understand the difference between these terms. They most likely go as far as referring to them as the same processes, which they’re definitely not. Let’s figure out the difference. Quality assurance is process oriented. It is all about preventing defects by ensuring the processes used to manage and create deliverables works. Not only does it work, but is consistently followed by the team. Moreover, QA is about engineering processes that assure quality is achieved in an effective and efficient way. For instance, if a defect is found and fixed, there is no guaranteeing it won’t pop back up. The role of QA is to identify the process that allowed the error to occur and re-engineer the system so that these defects won’t appear for the second time. The QA process verifies that the product will continue to function as the customer expects. Though QC is absolutely necessary, QA is perhaps more important. By the time you reach the QC stage, for instance, fixing bugs becomes an expensive issue. Because of that, focusing efforts on improved QA processes is one of the best investments an organization can make. Examples of QA include process definition and implementation, training, audits and selection of tools. xxvi

Introduction

Quality control, alternatively, is product oriented. It is the function of software quality that determines the ending result is what was expected. Whereas QA is proactive, QC is reactive. QC detects bugs by inspecting and testing the product. This involves checking the product against a predetermined set of requirements and validating that the product meets those requirements. Examples of QC include technical reviews, software testing and code inspections. Testing is a subset of QC. It is the process of executing a system in order to detect bugs in the product so that they get fixed. Testing is an integral part of QC as it helps demonstrate that the product runs the way it is expected and designed for. To summarize, think of everything as an assembly line. QA can be thought of as the process to ensure the assembly line actually works, while QC is when the products coming off the assembly line are checked to verify they meet the required specifications. Ultimately, both QA and QC are required for ensuring a successful product. When used together, they can help detect inefficient processes and identify bugs in the product. Moreover, QA and QC can help to develop and deliver a consistently high-quality product to your customers.

Evolution vs. “Production” The term “production” is another carryover from the manufacture of “things” to “software” development efforts. It belies the true nature of software development as a process of evolving requirements to meet a set of generally defined objectives. “Turnover to Production” or “Transition to Production” largely set the view that software is delivered in a complete and final form. As anyone with experience in “Maintenance” is aware, this could not be farther from the truth – if only to complete system parts that were left unfinished by the development team. DPAC labels this “Stage 5. Evolution.”

xxvii

Introduction

Support vs. “Maintenance” One performs maintenance on a car to restore it to its original condition. One supports the evolution of software. “Maintenance” is yet another carryover from the manufacture of things. The DPAC model recognizes software as an organic medium providing a conduit for the processing and transformation of information. The Evolution Stage is the same as the initial development stages except in slow motion as the system continues to evolve. Requirements morph into additional requirements and/or changes or additions to basic business rules. Again as used herein, the Support Activity Cycle includes software support (including evolutionary changes), operations (providing support and provisioning for hardware, LAN, configuration, and access to the system), and Database Administration (DBA). Scrum is defined by Scrum.org as “a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” DPAC is an alternative “framework,” although Chapter 5 may be used to explain what goes on inside a “Sprint.”

The “Application Life Cycle” I have a problem with the term “application life cycle,” with phases, instead of a linear model with “stages.” It’s not really like we are going to start all over again on the same ground. Lay the progress line flat. It’s about one system, not many. If the “application life cycle” does mean anything, it means that the first one flopped so hard that another contractor was called in to finish the job. And one after that, and one after that… ad nauseam until somebody declares the project “Dead” and pulls the fiduciary plug. So much for the Cycled Life of the Application.

xxviii

Introduction

Interestingly enough, the activities that emerged from each Activity Cycle mostly “fell out” of the model as I have described them herein (Chapters 3–7, the stages respectively). It may well be that the “tasks” to which the model must respond define the most efficient course of the activities of the developers of the system.

The Software Development Industry DPAC proposes a different world view of software development activities from that of the “Software Development Industry.” The System Development Life Cycle (SDLC), a competing model, faces the same demise as the “application life cycle,” that is, you do it over, and over, and over…” etc. The SDLC model has, however, spawned a legion of serial “software developers.” That is the essence of build/fail, build/fail, until either you get it right or the Contracting Officer advises the Budget Director, and funds are pulled from the project. Then as someone said on a failed federal contract – “You don’t think the Government is going to take the blame for this, do you?” And another contractor bites the dust.

The DPAC Model I have picked up bits and pieces from a long list of “resources,” a set of techniques from literature on the subject, and influences from the various agile methods and methodologies. But it was ultimately the DPAC model that has emerged from decades thinking about the process of developing software that changed my own “world view” of the development process. It is different in three ways: (1) The moderation of words and references emanating from the “production of things” (2) The recognition that systems evolve, and software support services need to support that activity xxix

Introduction

(3) The DPAC model itself – which I posit as the most efficient geometric representation, including recursion, through the “software development” maze DPAC is a conceptual framework on which one can “hang the ornaments,” that is, the techniques, methods, and procedures appropriate to each stage or activity cycle of the model. As interpreted herein, DPAC depends on inspections, exercised in the Act Phase of the PDCA quality model, that cogent internal documentation – in stream comments – exists. (Trust but verify.) The external documentation comprises adherence to standards, guidelines, and procedures which have the secondary importance of having a new person come up to speed faster than without them. All the rest is “tribal knowledge,” which can verbally tie up two people in conversation to bring a new person up to speed. Put the standards and procedures up on Wiki accessible to all. Demand that procedures known only to developers by tribal knowledge be written down where it is accessible to all. These are responses to risk mitigation, especially the loss of a key person. See my experience with this matter in Chapter 9. “How do I file a Change Report (CRpt)?” without a written procedure is a question that could tie up two or more persons’ time. The “standard” need be no longer than a few sentences: “Hand it to the Configuration Manager who will log it in and turn it over to the Project Manager for evaluation. Expect a response within two days.” To be sure, the DPAC model is informed by my participation as the Software Quality Assurance (SQA) officer, on a 50-55 person development effort. Scrum thrives on a considerably smaller scale. But DPAC can also work in smaller schemes such as several agile teams of about nine persons each assigned to a specific service, but each following the methodology suggested by the DPAC model. (See definition of a service above.) The model can be iterated to accommodate larger projects.

xxx

Introduction

Developers vs. Support Personnel Finally, software support personnel make poor developers. Development is raising something from scratch and needs several specialized skills – an architect, programmers, business analysts, and testers. Support, on the other hand, builds “add-ons” like building a sun porch to an existing structure. Something new to support might be the addition of a Configuration Management Database (CMDB) to support a help desk, or a new service: “inventory.” And developers make terrible support personnel. Support is not the thrill of making something out of nothing other than of the intent of the users. I believe that the DPAC model, taken as a framework for developing software, resolves the dissonances that cost time figuring out which way to go. The interpretation of DPAC presented herein takes a Lean-Agile Collaborative Development approach to these issues; test is built into each activity cycle as part of the Check Phase of PDCA as is Review with User. So that’s the broad description, but

From such crooked wood as that which man is made of, nothing straight can be fashioned. —Immanuel Kant

xxxi

Introduction

All that being said: Onward through the fog…

xxxii

CHAPTER 1

The DPAC Model This view describes the DPAC Model and Cycles of Activity.

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_1

1

Chapter 1

The DPAC Model

About the Model A model, as used in this context, is a graphic representation of the development processes. Until now there has been no generalized model of the course of activities over all the application life stages. The DPAC model brazenly claims to fill that gap. In fact, I contend that it is the optimum model of geometric efficiency. It also describes a path of development, including recursive flows. Linear models, on the other hand, tend to be complex in a pale representation of what is fundamentally a cyclical process. (See Figure 1-1.)

DPAC does for agile what “waterfall” does for traditional methods of development. Where other models track the progress of software, DPAC tracks the activity of people.

Figure 1-1.  Rube Goldberg’s model Source: (c) Vernier Software & Technology used with permission.

DPAC and PDCA DPAC follows an interpretation of the Deming quality cycle – Plan, Do, Study, and Act (PDSA) – or the earlier Japanese version, Plan, Do, Check, and Act (PDCA):

2

Chapter 1

•

Plan the work.

•

Do – implement the plan.

•

Check

•

•

Test the result (where appropriate).

•

Review with users.

The DPAC Model

Act – determine the course of the next iteration, and review the results when the component is coded (trust but verify).

Each activity cycle is re-entrant. That is, an activity cycle may repeat or re-enter a previous cycle before “graduating” to the next cycle. For example, if any error of understanding or new view from the user is uncovered in the Service Assembly Cycle, the progress of development is routed back to the Process Detail Cycle – indicating more interaction with the user – and then to the Component Development Cycle where all coding takes place. Then, the service is reassembled in the Service Assembly Cycle, and the progress moves ahead to the System Integration Cycle where the process is repeated as necessary to gain the user’s concurrence. DPAC is inherently a “shift left” model, moving the function of test to “as you go” testing. This approach •

Lowers the number of errors detected later in the development process – thereby decreasing overall cost

•

Reduces the amount of time to actually fix the error as at this point the team is in direct contact with the user

•

Lessens complexity to locate the source of an error in code as it is being developed

3

Chapter 1

The DPAC Model

DPAC Embraces Agile and DevOps Agile is a response to “waterfall” methods that require completion of each stage before moving on to the next. In waterfall, requirements are fixed at the end of the Process Detail Cycle with a “high ceremony” detailed design review before moving on to writing code. This is represented by the first brick wall in Figure 1-2. Likewise, in waterfall each component of code must be considered complete, including test, before sending it over the second brick wall to operations. The waterfall approach is fraught with delay and inefficiencies. In the DPAC model, agile is represented by the Process Detail and Component Development cycles (Construction Stage). DevOps is represented in the Assembly Stage: Service Assembly and System Integration cycles. Deployment herein is part of the Evolution Stage, where support comprises operations, support programming, and Database Administration. The purpose of DevOps is to get solid code to production as fast as possible.

DevOps is fundamentally about changing culture, about building much more responsible organizations that can move quickly in ever-changing circumstances. It’s also about taking full advantage of modern technology, to replace manual, time-consuming and error-prone activities with automation. Source: Gareth Rushgrove “Get Started with DevOps: A Guide for IT Managers” Puppet White Paper ND retrieved 2/2018 (Google)

4

Chapter 1

The DPAC Model

Figure 1-2.  Transition between business cases and development, and between development and operations Source: Matt Watson January 16, 2013, Insights for Dev Managers, “Divvy Up DevOps Tasks, Defining the Ops in DevOps” https://stackify. com/defining-the-ops-in-devops/ (Google)

Activities Represented in the DPAC Model The Change Advisory Board (CAB) replaces the Change Control Board (CCB) in traditional models, and the change request (CR) is changed to a Change Report (CRpt). This reflects the diminution of formalisms in an agile environment – reducing the time it takes in traditional development efforts to convene the CCB with a CR and the development effort being held in abeyance. A change report however simply reports a change from previous documentation which the team may consider to be elevated to the CAB for consideration. In other words, a CRpt is created if the analyst/coder discovers a process not represented in the high-level process model, in this example a data flow diagram (DFD). A decision must be made on whether to modify the high-level model or to skip over that particular modification. If the change is minor, the coding effort may proceed. A major change

5

Chapter 1

The DPAC Model

would be a report that identifies a circumstance not covered in the Vision Statement. The important razor is whether or not the integrity of the system would be compromised.

The larger function of the CAB is to maintain communication between the host organization and the development team regarding progress toward (or impediments against) objectives. Impediments may include lack of accessibility or availability to the development team of area specialists, particularly as the development process proceeds into the Process Detail and Component Development Cycles. Business Rule and Requirements Review is conducted by the Lead Business Analyst. The objective is to ensure that business rules and requirement statements are decomposed to “atomistic” statements of testable requirements. These data shall be maintained in a Requirements Database – consisting of online pointers to offline documents where accountable. The offline document compendium can be maintained by a designee of the Lead Business Analyst performing the role of librarian. Technical review may include inspections, and/or refactoring. It is the responsibility of each programmer to maintain source code version control and track “build” options. In addition, the technical reviewers process Change Reports (CRpts) brought forward by the component developers. If the change is deemed to be a significant departure from the Vision Statement, the Technical Project Manager may refer the CRpt to the Change Advisory Board (CAB) for a decision of whether to carry it forward or to pass on its implementation. Operations (DevOps) move persons from operations in the host organization into the development process. Analysis, coding, test, and user review. There is a strong argument to be made for having the testers in the development process brought in with the development team, not as an extension of the host support staff. First,

6

Chapter 1

The DPAC Model

the team can hire testers who want to work alongside a programmer and/ or business analyst. Second, the host test component will take over during the Deployment Cycle in the early Stage and would be stretched to provide personnel for the development team. Configuration management (CM) is carried out in a set of roles that may be filled by different individuals. The principal functions of the Configuration Manager are: •

To track the progress of each component of code in a Software Configuration Inventory (SWCI) database

•

To track the initiation and progress of Change Reports (CRpts) and Discrepancy Reports (DRs) through to completion

•

To initiate and maintain a traceability matrix, as a part of the Configuration Management Database (CMDB)

Each item in the software inventory is tracked through each activity cycle. The traceability matrix enables a tester at any level to identify to whom a questionable result of testing should be referred, and, in the event a business rule is changed or modified, allows an analyst or programmer to identify where in code a particular business rule is actualized. Other roles and responsibilities for configuration management include: Business analyst – Maintains a compendium of business rules reducing requirements to an irreducible (atomic) level. Tied to the goals and objectives of the Vision Statement, this is the bottom level of the traceability matrix. Technical management – Maintains version control over source code, builds and deploys scripts and libraries, and synchronizes test data with current activity.

7

Chapter 1

The DPAC Model

Test – Preserves test protocols and tool scripts. Librarian – Maintains document control and publishes standards, guidelines, and procedures in conjunction with the Process Quality Assurance officer. In addition to maintaining version control of document work products (e.g., the compendium of business rules), this person maintains the glossary. Database Administration – The Agile DBA maintains version control over database scripts, generation of test data and various versions of the Entity Relationship Diagram (ERD). The DBA is also the data modeler and initiates the data dictionary. Software Quality Assurance (SQA) conducts audits to assure the integrity of the software development process. It is responsible for the promulgation of standards, guidelines, and procedures. Project Management and Administration – The principal responsibilities are to track the burn rate and maintain liaison with the host organization. Programmers (programmer/analyst, programmer/ tester) perform the coding of the application.

Stages, Cycles, Phases, Parts, and Steps While these terms are often considered interchangeable, in DPAC each has a distinct meaning. Stages are linear measurements of progress from inception to retirement. Cycles represent circular activities within a stage toward progression to the next stage. (See Table 1-1.) Cycles may repeat many times before completion of a particular unit of code. Each item of

8

Chapter 1

The DPAC Model

software proceeds independently through the model following activity of the developers. Phases are an overlay of each activity cycle by the Deming PCDA paradigm (Plan, Do, Check, and Act). A phase may have one or more steps – such as two parts to the Check Phase being Test and then Review with the user. Each progressive increment of the model can be referred to as a step (e.g., the step following the Check Phase would be the Act Phase).

Table 1-1.  Development stages and activity cycles Stage

Cycle(s)

Inception

Vision Statement

Elaboration

Process Overview Cycle (Data Flow Diagram)

Construction

Process Detail Cycle Component Development Cycle

Assembly

Service Assembly Cycle System Integration Cycle

Evolution

Deployment Cycle Support Cycle

Retirement

Fold up process

The Inception Stage of Application Development The Inception Stage is occupied with the creation of a Vision Statement. The process begins with the identification of principal shareholders (area specialists) headed up by the sponsor, a “champion,” or a designated chairperson. The statement should begin with a declaration of purpose.

9

Chapter 1

The DPAC Model

The declaration of purpose is followed by “bullet points” of specific goals and objectives. It is critical that these “bullet points” be comprehensive of what the system is intended to accomplish.

T he Elaboration Stage of Application Development Following the creation of a vision statement comes the creation of a system-wide process diagram. The practical objectives are: •

To identify process and data dependencies

•

To populate the data flows and data stores of the data flow diagram

•

To identify implementation priorities

•

To derive an initial estimated level of effort for each prioritized component

In this interpretation of the DPAC model, these objectives are met by the upper levels of a data flow diagram (DFD). This activity is represented in the DPAC model by iterations of the Process Overview Cycle.

At the conclusion of the Elaboration Stage, there should be a Design Review session for shareholders and development team members to walk through the DFD of the completed “system to be.” This will allow time for questions to be asked and answered regarding the broad outline of the system. In this “low ceremony,” agile interpretation of the DPAC model, the DFD will constitute a functional requirements specification (FRS). The DFD should contain enough information to provide an early estimate of the level of effort to complete the software system. Again, the DFD and this information should be available at the end of the Elaboration Stage (after completion of various iterations of the Process Overview Cycle). 10

Chapter 1

The DPAC Model

There is a vertical line at the edge of the Process Overview Cycle where the Functional Design Review of the high-level DFD takes place. This represents the mark at which the Elaboration Stage ends and an early estimate of level of effort can be ascertained. In a “high ceremony” interpretation of the DPAC model, the end of the Elaboration Stage would be moved forward to the end of the Process Detail Cycle to indicate that the Elaboration Stage continues. The software requirements specification (SRS) then contains requirements defined at their lowest (atomic) level.

In general, the larger the project, the greater the need for “ceremony” (formalisms).

T he Construction Stage of Application Development Identification of business rules is a part of the Process Detail Cycle. The work of the Process Detail Cycle is: •

To make assignments based on the processes uncovered in the Process Overview Cycle

•

To complete the data flow diagram (where required)

•

To create an initial (incremental) database design

•

To identify any subprocess logic that may have emerged as the work on design continues

•

To identify and define business rules

Through successive iterations, the requirements for a database design emerge following the priorities and dependencies uncovered in the Elaboration Stage. This prepares the Stage for coding in the Component Development Cycle.

11

Chapter 1

The DPAC Model

The Process Detail Cycle and the Component Development cycle are paired for each Component of software where work on each unit of code can proceed independently of others. Particularly where Test-Driven Development is employed, it is essential that the programmer fully understands the requirements (business rules) to be rendered in code. It may be prudent to send a business analyst to conduct the first round of interviews, and have a programmer/analyst and a tester perform the second round. If anything remains unclear, the business analyst might do another round with or without a programmer before coding takes place. There may be several “spirals” and teams running concurrently – finishing at different times. Cycles are not necessarily of equal duration. In general, the DPAC system strives to reduce the number of “handoffs” by pair programming with a tester and/or a business analyst. The Process Detail Cycle and the Component Development Cycle may be iterated several times in successive order as “requirements” are clarified or uncovered late in the code development process.

The Assembly Stage of Application Development The business of the Construction Stage is to produce “bug-free” components of code that meet the needs of the users. The business of the Assembly Stage is to assemble these units into operational components, and to test these components for “dynamic integrity.” “Dynamic integrity” refers to uncovering conflicts between components – and in the case of the System Integration Cycle, conflicts between services. One test is to determine if navigation controls are functioning as intended from sign-on to sign-off. Hopefully there have been adequate architectural choices that enable assembly processes.

12

Chapter 1

The DPAC Model

Operations and support programming personnel become closely involved with development personnel during the service assembly and System Integration cycles (DevOps). See Figure 1-3. In that manner, the organization’s personnel become familiar with the system prior to turnover and can assist during the user acceptance test moving forward.

Figure 1-3.  DevOps is operations reaching back into the development environment Each of the servers required in the Construction and Assembly Stages must be identically provisioned (i.e., same hardware requirements, same version and release number as the Support Servers). This enables a smooth transition of code and data and eliminates hardware and operating system variation as sources of error.

13

Chapter 1

The DPAC Model

The Evolution Stage and Retirement Nowhere in application development is the ability to recover from an error more important than in the Support Cycle. Here, an error can bring down the system for an unspecified period of time – costing the organization for downtime of staff and internal matters – but more significantly can block customer engagement at an even higher cost in terms of customer retention. All the more reason to establish a traceability matrix. Retirement generally happens in a staggered relationship with the next generation. The objective of this model is to maintain the conceptual integrity of requirements from inception to completion of the application life cycle. There is no “Requirements Cycle” as such in this representation of the model. This interpretation embraces the concept that there exists some optimum set of Requirements and Design that best fit the needs of the user and that this optimum set will be “uncovered” incrementally as the development process proceeds through the iterative paths of the Process Overview Cycle, Process Detail Cycle, and Component Development Cycle – even as late in the process as the Service Assembly and System Integration cycles, with the last chance being the User Acceptance Test. There is no “Test Cycle” in the DPAC model; test is a step of each cycle in the Check Phase of the PDCA paradigm (continuous testing). This model is adaptable to product development, new database applications, system “conversions,” Management Information Systems (MIS), or workflow applications. It can be scaled down to small team and agile operations, “parceled out” to subcontractors working in a specific stage, or replicated over multiple locations of complex development activities. Use of this model greatly facilitates the management of multiple projects at higher administrative levels. Any set of standards or controls can be applied within this framework. It can also be used in production environments, and can help in the achievement of compliance with Capacity Maturity Model Integration (CMMI) requirements.

14

Chapter 1

The DPAC Model

The model does not in any way change the need for a Software Quality Assurance Plan, a Configuration Management Plan, and thorough test protocols (scripts). The activity cycles in this model do not correspond to method cycles such as a “sprint” nor does the ACT step correspond to daily stand-up meetings or a “scrum.” This model describes the recursive path of single units of code from concept to requirements, to components, to a completed, integrated delivered system.

Paradigms as a Hindrance to Understanding The labels and milestones in this model are not written in stone. However, the core concepts of Plan, Do, Check, and Act (PDCA) are the overriding guidance for what to do during each cycle, and in what order. The cycles in the model are not time boxed. Each team of a sprint works independently, whereas the sprint ends as a snapshot in time. Nor does the ACT step necessarily correspond to time-boxed events such as daily stand-ups or a scrum. The model represents patterns of behavior free from time constraints. However, there are events that may take place each time an individual effort passes through the ACT step. These may include technical review, review of business rules, intervention by the Change Advisory Board, and, at every turn, tracking by the configuration manager who, among other things, maintains the traceability matrix.

The objective of this model is to control the quality of the development effort.

15

Chapter 1

The DPAC Model

Summation As a management tool, DPAC allows the combined efforts of the CAB and the development team to control change, to prevent “requirements creep,” to halt runaway development efforts, and to track progress of each Component of code. It provides the means to measure the impact of changes to requirements or design before the construction of code. As a software quality engineering tool, it provides a framework for the implementation of standards, guidelines, and procedures. It also serves to ensure the quality of the software, and to ensure uniform presentation in each stage of the development effort.

16

CHAPTER 2

Why Include Support in a Development Model? “Building it right” and “building the right thing” is expensive, but less than the total cost of achieving that end any other way. The selling point is return on investment (ROI). While this may be a difficult “sell,” it is important to remember:

Software system developers have two sets of clients: those who will use the system, and those who will maintain it.

Statement of the Problem Researchers reviewed 548 software failures they found in English language news articles. In total, the failures at some 363 companies affected some 4.4 billion customers and caused more than 315 1/2 years of lost time, according to the report. It’s like companies are burning money. Source: Report: Software failures cost $1.1 trillion in 2016, testbytes.net/ blog/ Posted by Michael Joseph on March 8, 2017 (Google)

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_2

17

Chapter 2

Why Include Support in a Development Model?

Software bugs, or errors, are so prevalent and so detrimental that they cost the U.S. economy an estimated $59.5 billion annually, or about 0.6 percent of the gross domestic product, according to a study commissioned by the Department of Commerce's National Institute of Standards and Technology (NIST). At the national level, over half of the costs are borne by software users and the remainder by software developers/ vendors. Source: “Software Errors Cost US Economy” NIST Press Release, June 28, 2002

Software maintenance personnel already spend approximately 80 percent of development costs on identifying and correcting defects, and yet few products of any type other than software are shipped with such high levels of errors. Other factors contributing to quality problems include marketing strategies, limited liability by software vendors, and decreasing returns on testing and debugging, according to the study. Source: Karl E Wiegers, “Inspecting Requirements,” StickyMinds.com Weekly Column, 25 July 2001 (Google)

To Put This in Terms of Total Cost [A] report, issued annually by the Austrian software testing firm Tricentis, estimates the cumulative cost of software bugs, glitches and security failures worldwide last year at a whopping $1,715,430,338,504.. For some perspective, that’s more than the total GDP of Mexico last year. Source: S  oftware Fail Watch, 5th edition. Tricentis 2018 (Google) Problems found during support incur costs in addition to the cost of repair. A product’s lifetime cost is determined by repair costs, personal valuations of time and inconvenience, losses due to downtime, and other

18

Chapter 2

Why Include Support in a Development Model?

economic variables. The full cost of support is not only the cost of time to repair but also the cost of organizational time lost while support is being performed. In a mission-critical application, this cost can be considerable indeed. In a customer-facing application, the time to correction can result as a loss of income and/or a loss of customer trust.

ITIC’s latest survey data finds that 98% of organizations say a single hour of downtime [including hardware failure] costs over $100,000; 81% of respondents indicated that 60 minutes of downtime costs their business over $300,000. And a record one-third or 33% of enterprises report that one hour of downtime costs their firms $1 million to over $5 million. Source: “Cost of Hourly Downtime Soars: 81% of Enterprises Say it Exceeds $300K On Average.” ITIC (Information Technology Intelligence Consulting) web page August 2, 2016 (Google) These numbers more than justify the amount spent on enforcing standards, guidelines, and procedures, the creation of a Configuration Management Database (CMDB) including a traceability matrix, and tools to support agile development and DevOps.

 egarding the Quality Payoff for the Adoption R of DevOps and Other Discipline Practices Because quality is inherently difficult to measure, we used unplanned work and rework as proxies. We found that highperforming organizations spend 22 percent less time on unplanned work and rework. As a result, they are able to spend 29 percent more time on new work, such as new features or code. This year, we are happy to report that high-performing organizations spend 21 percent less time on unplanned work and rework, and 44 percent more time on new work. 19

Chapter 2

Why Include Support in a Development Model?

Source: 2017 State of DevOps Report | presented by Puppet + DORA (Google)

Most problems that are associated with software maintenance can be traced to deficiencies of the software development process. Source: Gerardo Canfora and Anielo Cimitile Software Maintenance, University of Sannio, Faculty of Engineering at Benevento, Benevento Italy, 29 November, 2000

The main problem in doing maintenance is that we cannot do maintenance on a system which was not designed for maintenance. Unless we design for maintenance, we will always be in a lot of trouble after a system goes into production. Source: Norman F Schneidewind, The State of Software Maintenance, IEEE Transactions on Software Engineering, Vol. SE-13, No. 3, March 1987

Putting Support in the Equation Support takes about 60% of the software application budget; test takes about 50% of the cost of all development activities (including unit test). The remarkable thing is that these two percentages have remained roughly the same since this diagram (Figure 2-1) appeared in 1979. (Estimates vary between 40% and 80% of total time devoted to support, 60% average.)

20

Chapter 2

Why Include Support in a Development Model?

Figure 2-1.  Distribution of effort over the application’s life Source: Zelkowitz et al. Principles of Software Engineering and Design. Prentice Hall 1979 The number of “legacy” systems is growing as work winds down on development projects already in progress. Figure 2-2 shows the relative decrease in the cost of hardware and the increasing cost of support proportional to new development from 1950 through 2020. The support line broke even with the development line around 1995 (where the cost of support and the cost of development were approximately the same) also equivalent to the cost of hardware: •

The cost of support was projected to overwhelm the relative cost of development as 80% of the proportional cost by 2020. (See Figure 2-1.)

•

The support line broke even with the development line around 1995 (where the cost of support and the cost of development were approximately the same) also equivalent to the cost of hardware.

Very simply, every development project that succeeds, even if challenged, becomes a support project. 21

Chapter 2

Why Include Support in a Development Model?

Figure 2-2.  Proportional distribution of cost Source: Rajkumar Buyya, Thamarai Selvi, Xingchen Chu, Object Oriented Programming withJava:Essentials and Applications, Tata McGraw Hill Press, New Delhi, India, 2009 Table 2-1 puts another face on the looming problem. In a nutshell, it roughly means that by 2025, 77% of the aggregate cost spent on software applications will be spent on maintenance.

The importance of accurate functional requirements cannot be overstated.

22

Chapter 2

Why Include Support in a Development Model?

Table 2-1.  Support as a percentage of total personnel Year

Development Maintenance Total Personnel Percent in Maintenance Personnel

Personnel

1950 1,000

100

1,100

9.09%

1955 2,500

250

2,750

9.09%

1960 20,000

2,000

22,000

9.09%

1965 50,000

10,000

60,000

16.67%

1990 900,000

800,000

1,700,000

47.09%

1995 1,000,000

1,100,000

2,100,000

52.38%

2000 750,000

2,000,000

2,750,000

72.73%

2005 775,000

2,500,000

3,275,000

76.34%

2010 800,000

3,000,000

3,800,000

78.95%

2015 1,000,000

3,500,000

4,500,000

77.78%

2020 1,100,000

3,750,000

4,850,000

77.32%

2025 1,250,000

4,250,000

5,500,000

77.27%

Source: Capers Jones, “The Economics of Software Maintenance in the Twenty First Century,” version 3 – February 14, 1996 An erroneous specification leads to an erroneous design and erroneous programs which create hidden errors when they arrive at test. The test may pass, but the solution remains wrong. Sadly, the error might not be noticed until someone observes that an item in an annual report “looks funny.” The difficulty of detecting an error depends on where in the process of delivering code the error occurs.

23

Chapter 2

Why Include Support in a Development Model?

If there is a correct design but a faulty requirement, the source of the error is difficult to detect, and the faulty requirement will lead to incompatible code. If the design is incorrect, the requirement will be written on the erroneous specification leading to programs based on erroneous design. These errors remain hidden from the tester’s point of view – and may not be detected until the system has been in production for some time. If the error is never found, it could be secretly costing the company money, and no one could be the wiser. (See Figure 2-3.)

Freeing the Statue from the Stone Industry data suggests that approximately 50 percent of product defects originates in the requirements. Perhaps 80 percent of the rework on a development project can be traced to requirements defects. Source: Karl E Wiegers, “Inspecting Requirements,” StickyMinds.com Weekly Column, 25 July 2001 (Google) In an iterative approach to development as described herein, the unfolding of requirements from the user community is carried out in repetitive, recursive iterations, slowly freeing the statue from the stone. “I’ll know it when I see it.”

24

Chapter 2

Why Include Support in a Development Model?

Figure 2-3.  Origin and consequences of error Source: Revised from Alan Davis, Software Requirements, Revision, Prentice Hall 1993

The best way to deal with software errors is to keep them out of the software in the first place.

Improving Maintainability Many technical problems contribute to the costs of software support. Among the challenging problems of software support are factors supporting code reliability and measures during development to improve software system maintainability.

25

Chapter 2

Why Include Support in a Development Model?

In a rigorous study of 137 software projects, each project was evaluated in 5 documented dimensions of software development problems each with 5 contributing factors.1 The study returned a ranked order of ten development problems affecting the degree of “maintainability.” The key findings are: Five dimensions of software development problems: Documentation quality problems (DOC) Inadequacy or poorness of documentation which would cause software to be hard to understand, change, and modify Programming quality problems (PGM) Improper manner of programming which causes source codes to be hard to read, diagnose, and analyze System requirements problems (SYS) Incorrect, incomplete, unrealistic, unclear, or uncertain system requirements which would cause software products to fail to meet customer’s needs Personnel resources problems (PER) The personnel-related factors which would cause project risk and negatively affect project performance Process management problems (PM) Poor management in software development process, which would cause project risk and negatively affect project performance J ie-Cherng Chen, Sun-Jen Huang “An empirical analysis of the impact of software development problem factors on software maintainability” The Journal of Systems and Software 82, (2009) Elsevier, Inc.

1

26

Chapter 2

Why Include Support in a Development Model?

The top ten higher-severity development problem factors regarding “maintenance”: Rank Software Development Problem Factors

Abbreviation

1.

Inadequacy of source code comments

PGM2

2.

Documentation is obscure or untrustworthy

DOC1

3.

Changes are not adequately documented

DOC4

4.

Lack of traceability; difficult to trace back to design specifications and user requirements

DOC3

5.

Lack of adherence to programming standards

PGM1

6.

Lack of integrity/consistency

DOC5

7.

Continually changing system requirements

SYS5

8.

Frequent turnover within the project team

PER1

9.

Improper usage of programming techniques so that degrading PGM5 self-documentation of source code occurs

10.

Lack of consideration for software quality requirements

SYS4

Software development problems not ranked in top ten as contributing to “maintenance” difficulties: Documentation quality problems (DOC) DOC2 – Inadequate system documentation; incomplete or nonexistent system documentation Programming quality problems (PGM) PGM3 – Lack of modularity to divide the program into functionally and operationally independent components PGM4 – Lack of refactoring/restructuring; high level of program 27

Chapter 2

Why Include Support in a Development Model?

System requirements problems (SYS) SYS1 – Incorrect system requirements SYS2 – Unclear or incomplete system requirements SYS3 – Unrealistic or conflicting system requirements Personnel resources problems (PER) PER2 – Insufficient skills or experience PER4 – Lack of resources and time PER5 – Lack of commitment to the project Process management problems (PM) PM1 – Lack of policy and management support PM2 – Ineffective project planning and control PM3 – Inadequate estimation of cost and schedule PM4 – Ineffective configuration management to control software PM5 – Ineffective quality control audits to ensure level of quality

 meliorative Measures During Development A to Improve Software System “Maintainability” “The DOC and PGM problem dimensions of all the three levels of software maintainability exceed the baseline threshold. This suggests that successfully dealing with these two problem dimensions is a key requirement to achieve the desired software maintainability” (ibid).

28

Chapter 2

Why Include Support in a Development Model?

Documentation quality problems (DOC) DOC1 – Documentation is obscure or untrustworthy. DOC2 – Inadequate system documentation; incomplete or nonexistent system documentation. DOC3 – Lack of traceability; difficult to trace back to design specifications and user requirements. DOC4 – Changes are not adequately documented. DOC5 – Lack of integrity/consistency. Programming quality problems (PGM) PGM1 – Lack of adherence to programming standards PGM2 – Inadequacy of source code comments PGM3 – Lack of modularity to divide the program into functionally and operationally independent components PGM4 – Lack of refactoring/restructuring; high level of program PGM5 – Improper usage of programming techniques so that degrading self-documentation of source code occurs While the study does not deal with ameliorative measures, my take (not specifically tied to the study’s categories) is as follows: •

Cogent and interpretable in-stream comments

•

Adherence to standards •

Configuration item naming conventions 29

Chapter 2

•

30

Why Include Support in a Development Model?

•

Database naming conventions

•

Program naming conventions

•

Program language style sheets

•

Standards and guidelines for in-stream comments

•

Menu system

•

Screen presentation (including screen identifiers)

•

Report formats

•

Font and point size

A system of code inspections and audits (guidelines and procedures) to assure code completeness: •

Include adequate internal documentation in the form of in-stream comments

•

Identify author(s), when initiated, and when and by whom last updated

•

Reduce errors due to faulty code (bugs)

•

Compliance with standards

•

Clean code

•

Early acceptance testing to reduce errors in definition of functional requirements

•

Test-Driven Development (TDD)

•

Refactoring - Rewriting code for better comprehension without changing the outcome

•

Preserve test cases from early testing at the unit level (including Test-Driven Development – TDD), module assembly tests, and system tests to facilitate regression testing

Chapter 2

Why Include Support in a Development Model?

•

Maintainable lookup tables (as opposed to hardcoding values)

•

Audit trails •

For “mechanical” difficulties such as auditing database updates

•

For security purposes such as tracing a user’s progress through the system to identify intruders or unwarranted use of the system

•

For database anomalies such as a corrupted database entry

•

Program and system error identification and recovery – fail soft

•

Overall process diagram (e.g., data flow diagram - DFD)

•

Database documentation

•

Data dictionary

•

Database schema (ERD)

•

Initiation and maintenance of a compendium of business rules and glossary

•

Initiation and maintenance of a traceability matrix •

Forward – Such that a change in a business rule can be implemented in a particular unit of code

•

Backward – Such that a logical error can be traced back to the underlying business rule for validation (to determine if the error is a defective business rule or an error in processing logic)

31

Chapter 2

Why Include Support in a Development Model?

•

A well-documented system architecture

•

The maintenance programmer’s secret dream – numbering the screens so anomaly can be located to repeat the user’s problem

Political and Social Capital Involving operations and support staff early in the development process has at least two distinct benefits. First, meetings of the leads from support and operations with leads from the development team begin to establish interpersonal familiarity which hopefully will translate to better communication as the process proceeds. Second, given that DevOps can create a “culture clash“ between operations and the development team, the earlier familiarity and personal recognition between Dev and Ops are established the better. Further, involvement of operations and support very early in the process helps the support team to comprehend the organization’s intent – providing the basis for them to anticipate the needs of the developers and prepare for changes in project direction trickling down from above. Thomas Pigowski goes so far as to say:

Maintenance should begin coincident with the decision to build a new system… Certainly this participation should be well before the signing of any development contract, and before the initiation of any development effort Source: Thomas N Pigowski, Practical software maintenance, Wiley 1997 Early involvement of the support team, preferably the lead tech from support and a representative from operations, can help to see that the budget for support fits squarely with their present knowledge of the level of effort necessary, and helps to establish rapport with representatives of the client organization. This social and political capital will prove to be very useful as the development effort continues. 32

Chapter 2

Why Include Support in a Development Model?

Summation Out of sight, out of mind. As long as the activities which comprise support are kept out of view in the conceptual model of the development process, developers will continue to deliver a mostly operational, rat’s nest of problems to the software support personnel of the system.

33

CHAPTER 3

The Inception Stage The Inception Stage concerns itself with the creation of a Vision Statement.

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. —Frederick P. Brooks, Jr. The Mythical Man Month. p 42 © Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_3

35

Chapter 3

The Inception Stage

Begin with the end in mind. —Stephan R. Covey The Seven Habits of Highly Effective People, Habit 2

Be Proactive. –ibid. Habit 1 The principal goal of the Inception Stage is to achieve concurrence among stakeholders on the lifecycle objectives for the project. Here are nine objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the intended solution, some of which cross over among themselves: 1. Understand what to build. Determine an overall vision, including the scope of system and its boundaries. Identify the stakeholders who have a vested interest in this system and their criteria for success. 2. Achieve consensus among the stakeholders regarding the goals and objectives of the project. (This has high political importance.) 3. Establish priorities between project objectives (which of the objectives are most critical). 4. Initiate the traceability matrix. Everything that follows should be traceable to some provision of the Vision Statement 5. Preliminarily identify nonfunctional requirements: hardware and software package requirements, interfaces or conversions from other systems, 36

Chapter 3

The Inception Stage

special needs of user community including support of mobile devices reliability, performance, supportability, maintainability, flexibility, and regulatory compliance. 6. Determine security requirements for each project objective and for the project as a whole. 7. Determine necessary internal standards, guidelines, and procedures. 8. Identify risks associated with the project. 9. Identify the principals and subject matter experts (SMEs) key to the development effort. A general discussion follows.

Vision Statement At the start of the development process, the only thing visible is a declared statement of intent of the organization. This should be in the form of a Vision Statement – a carefully crafted statement of how the intended development will support the purpose of the organization stating specific goals and objectives. It should be accompanied by an organization chart that identifies the organizational components, principals, and area specialists (stakeholders) affected. While the overall statement of purpose may be promulgated by the “champion” of the “system to be,” it is important that the principals of all affected areas participate in the development of specific goals and objectives. The way by which the Vision Statement is created is as important as the Vision Statement itself.

37

Chapter 3

The Inception Stage

This is the first opportunity (beyond a feasibility study) for each stakeholder (and upper management) to buy into the idea. If no Vision Statement exists, the development team should create a “straw man” for circulation and comments. In either event, the draft should be circulated among the principal shareholders for comments until a consensus is reached. It is important to allow time for reflection, which is why trying to shorten the clock by packing it all into a JAD (Joint Application Development) session is probably not a good idea. The Vision Statement is the highest level of system design. It defines the scope and scale of the effort. Any system component not traceable to some part of the Vision Statement should be considered to be beyond the scope of the project. The Vision Statement can be modified as needed to accommodate late discoveries, but insistence upon this relationship, keeping the organization involved with change, is one way to insure against the surprise of runaway projects. Unmonitored scope creep will put any realizable estimates of level of effort in abeyance.

The vision statement is a declaration of intent – including specific, prioritized objectives.

Requirements Traceability Matrix Traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use and through all periods of on-going refinement and iteration in any of these phases.) Source: Gotel, O. & Finkelstein, A. (1994) An analysis of the requirements traceability problem. In: Proceedings of the International Conference on Requirements Engineering (RE), pp. 94–101 (Google)

38

Chapter 3

The Inception Stage

The traceability matrix begins with objectives of the Vision Statement and ends with a user interface. In between it touches on requirements, including those uncovered during the course of the development process and code implementing them. Traceability in a forward direction is necessary to accommodate change to a requirement or business rule after the system is in production. A maintenance programmer can locate where in code that particular business rule is implemented and efficiently make necessary adjustments. The objective is to ensure that each requirement is fully implemented in the system (that we are building the product right). Traceability in a backward direction traces each unique work product (e.g., design element, object/class, code unit, user interface, or test plan) back to its associated requirement. Backward traceability helps ensure that the evolving product remains on the correct track with regard to the original and/or evolving requirements (that we are building the right product). The objective is to ensure that we are not challenging the scope of the project by adding design elements, code, tests, or other work products that are not identified in the requirements.

Traceability allows a programmer to assess the impact of planned changes to existing code. In short, the extra effort of maintaining a traceability matrix makes sense in the context of test (50% of the development effort) and maintenance (at least 60% of the total software life).

Traceability saves a considerable amount of time (and money) during test and maintenance. A broader purpose of the traceability matrix is to carry forward the “tribal knowledge” of the initial developers – after they have “left the building.” The traceability matrix will also include the person or persons accountable at each juncture. This includes subject matter experts (SMEs), business analysts, programmers, and testers. 39

Chapter 3

The Inception Stage

The objective is to make all the elements of the system traceable, visible, and accountable. This is like a blueprint for an invisible house. It identifies the critical infrastructure of the system, otherwise unavailable.

Figure 3-1.  Simplified visual representation of a traceability matrix

Nonfunctional Requirements With the purpose of the system visible and agreed upon, it is possible to begin to define the hardware requirements and interfaces of the system to be. One can begin to detail nonfunctional requirements such as interfaces to other systems or COTS (commercial off-the-shelf ) software requirements, and start the process of defining the requirements for security.

40

Chapter 3

The Inception Stage

Table 3-1.  Nonfunctional requirements Compliance with External Requirements

• Legal compliance, regulatory environment, patent and licensing agreements, contract compliance • Compatibility with external standards and/or certification (i.e., ISO 27001, 27002, HIPPA, FISMA) • CMMI rating • Globalization – GDPR •  Breach of security incidents

Reliability

• Availability (e.g., 24x7x 365) •  Maintenance downtime •  Frequency and severity of failures •  Fault recovery

Performance

• Response time to complete specified tasks • Recoverability – mean time to repair (MTTR) •  Maximum number of concurrent users • Throughput (e.g., transactions per second) •  Data capacity, resource usage, •  Startup, shut downtimes

Supportability

• Adaptability – new environments, upgrade version •  Compatibility – previous versions, legacy systems •  Configurability – customizability •  Install ability – ease of installation •  Localizability – supports multiple human languages •  Maintainability – serviceability •  Scalability – scale in terms of volume and users • Testability

(continued)

41

Chapter 3

The Inception Stage

Table 3-1.  (continued) Implementation Requirements

•  Implementation languages – e.g., Visual Basic, Cobol • RDBMS (e.g., Oracle) • Platform support – Apple, PC • Resource limits – memory, hard disk •  Standards compliance – e.g., ISO 9000, 9001

Interface Requirements

• External – hardware and/or software systems with which the system must communicate • Internal – interfaces between in-house systems, e.g., Budget and Project Management subsystems

Physical Requirements

• Shape, and/or size and/or weight – may impose a specification of devices required by the system, e.g., servers, uninterrupted power supply (UPS), printers, storage devices • Physical security – key card access to hardware room, electronic lock

Usability Requirements (Question of Being Listed as Functional Requirements)

• Ease of learning – appropriate for user • Task efficiency – follows intention of user • Understandability • Ease of remembering •  Subjective satisfaction •  Feedback to user from application •  Mistake handling •  User’s guide • Help desk •  In context help (F1) • Online Help • Chat • Other architectural components

(continued) 42

Chapter 3

The Inception Stage

Table 3-1.  (continued) Can Also Include

• Portability • Software or RDBMS or development tool compatibility • Scalability • Open source • Reusability • Modifiability

 lanning for Information Security P and System Security Users want to be assured that •

They can trust the information they use.

•

They can trust that information they provide to the system will not be misused (privacy, lost, or stolen pirated).

•

The information they are responsible for will be shared only in the manner they expect (including privacy concerns).

•

The information will be available when they need it.

•

The systems they use will process information in a timely and trustworthy manner.

Source: Linda Pesante, “Introduction to Information Security” Carnegie Mellon University 2008 Key security activities for the Inception Stage include

43

Chapter 3

The Inception Stage

•

Delineation of business objectives in terms of confidentiality, integrity, and availability; Federal Information Security Modernization Act (FISMA)

•

Determination of information categorization and identification of known special handling requirements to transmit, store, or create information such as personally identifiable information (PII)

This broad policy should include training and orientation to establish a culture of security, restricted ingress and egress, policy regarding telecommuting, limited access to CD/DVD RW devices, policy on use of USB devices (e.g., memory sticks), badge/bar code authorization to access machines, or biometrics (e.g., fingerprint/retinal scan, facial recognition). The NIST handbook’s general approach to computer security is based on eight major elements: 1. Computer security should support the mission of the organization. 2. Computer security is an integral element of sound management. 3. Computer security should be cost-effective. 4. Computer security responsibilities and accountability should be made explicit. 5. System owners have computer security responsibilities outside their own organizations. 6. Computer security requires a comprehensive and integrated approach. 7. Computer security should be periodically reassessed. 8. Computer security is constrained by societal factors. 44

Chapter 3

The Inception Stage

Source: Barbara Guttmann and Edward A. Roback An Introduction to Computer Security: The NIST Handbook. Special publication 800-12, 1995 (Google) A summary of security management concerns is provided in Table 3-2. The particulars of a security policy impact heavily on the software development effort. While the construction of cautions for sign-on and logout and the establishment of an audit trail including navigation tracking are themselves not overly complex, it is quite another matter to develop the means to analyze these data. This not only requires the consolidation of use statistics with a “standard” for normal usage based on the clearance of the end user but also requires collaboration with the network administrator to monitor these activities in “real enough” time. In highly secure environments, an automated “trip wire” should set off an alarm while the offending activity is in progress. This, in turn, requires cooperation and coordination between operations, the network administrator, and the development team.

Privacy With regard to privacy, including the handling of personally identifiable information (PII), note that more than half of the risk factors appertain to policy and planning. In other words, the main part of establishing a culture of security depends on actions by the organization to enable the demands of a secure environment.

All these are part of a broader risk management framework and security policy.

45

Chapter 3

The Inception Stage

Table 3-2.  Summary of security management concerns CATEGORY

ITEMS

1. Personnel and Policy Culture of Security

• Physical security – locked door, background checks • Declaring resources as public, sensitive, private, or confidential (onion model) • Deter obtaining confidential information by means of human interaction • Confidentiality – secure, encryption

2. Perimeter Security

• Operating system “policy” restrictions – disable features (reasonable and prudent measures) • Viruses and malware protection • Operating system issues – security updates • Exterior attacks – hacking and denial of service • Network security – firewall protection

3. Secure Software

•  Cloud and mobile computing •  System and data integrity • Availability (including against denial of service) •  Cots Integration

4. Data and System Quality Assurance (Audit Functions)

• Audit trails – accountability (accounting trails, session control) • Confidentiality •  User navigation history • Archive •  Use statistics

(continued)

46

Chapter 3

The Inception Stage

Table 3-2.  (continued) CATEGORY

ITEMS

5. Contingency Planning

• Contingency planning controls to be addressed during this phase include: •  Contingency planning policy and procedures • Alternate storage site • Alternate processing site • Telecommunications services •  Information system backup

6. Safety from Unauthorized Access

• Access control • Authentication • Authorization • Approval •  System and data integrity • Physical security – point of entry control • Encryption

7. Monitoring and Response

•  Containment, recovery, and user response • Tools, techniques, and personnel • Risk assessments

8. Privacy

• Policy • Data • Planning • Programming-related controls • Training • Audit and monitoring

47

Chapter 3

The Inception Stage

If data from a legacy system is sensitive, the legacy data may need to be encrypted to protect sensitivity from the developers of the new system, which in turn creates an interesting environment for data conversion. Identification of security requirements is initiated in the Inception Stage. These requirements are developed in greater specificity during the Elaboration Stage. The actual code embodying these requirements is created during the Construction Stage – where specific expertise may be required to produce secure code. This is particularly relevant to systems where there is a high level of personal confidential information and/or where monetary transactions occur. System integration and turnover to support must entail tests against security measures. This by itself can be nontrivial; tests against existing code (e.g., cyberattacks) require a specific skill set that is expensive if available at all.

S  taffing F our Things Every (Successful) Project Manager Must Know:

48

•

The PM must be familiar with the structure and population of the organization and the organization’s culture. Where the PM is a member of the developer team, this is accomplished by close collaboration with the in-house Project Champion.

•

The PM must understand an overview of the software development process. This is accomplished by the DPAC model.

•

The PM must also understand the field that the project is designated to automate. This is accomplished by the creation of a data flow diagram (DFD) in the Elaboration Stage.

Chapter 3

•

The Inception Stage

The PM must understand the staffing pattern required to carry out that model. This is the subject of the current section.

The scenarios represented in the following are based on the assumptions that there is no Vision Statement before the start of the project and that the effort will be carried out by contractors. These scenarios are also based on the assumption that there exists a Program Manager who may be monitoring more than one project. Before the project begins, the first person to be on board is the project manager who in turn will hire two business analysts. Candidates for these positions are found by a recruiter or by an in-house recruiting effort (which saves the recruiter’s fee, particularly significant for high-­ ticket items). However selected, each PM candidate is interviewed by the Program Manager, the CIO/CTO herself, and the Project Champion. At project kickoff, the business analysts begin to derive vision objectives and circulate straw man versions of the Vision statement for comments.

Figure 3-2.  First hires. Selection of administrative assistant (or recruiter), project manager, and two business analysts assigned to the PM

49

Chapter 3

The Inception Stage

While the business analysts are carrying out their job, the second key person to be brought on board is the Technical Project Manager in preparation for the Elaboration Stage. He is interviewed and selected by the IT Program Manager, the CIO/CTO herself, the PM, and a representative from the in-house IT staff. (See Figure 3-4.) The Technical Project Manager is responsible for hiring the staff to build the demonstration version of the new system backbone, and for hiring the Quality Engineering Director, also interviewed by the PM. The QE Director selected will then hire the Lead Tester and her backup tester. Each will play a specific role in the implementation that follows. (See Figure 3-5.)

Figure 3-3.  Hire for the Elaboration Stage

50

Chapter 3

The Inception Stage

Figure 3-4.  Security consultant

Figure 3-5.  Staffing pattern for the Elaboration Stage (does not represent support functions such as configuration management and software process engineering)

51

Chapter 3

The Inception Stage

Also during the Inception Stage, the search for a security consultant is begun. This person is key during the Elaboration Stage – available to help define a secure architecture. (See Figure 3-5.) Figure 3-6 shows an overall view of staffing for the Elaboration Stage. On small- to medium-size projects, the roles defined for building and demonstrating the system backbone can be collapsed into three positions: the Agile DBA and data modeler roles can be filled by one person as can the lead programmer and architect. (Test and test backup are included only as observers; both individuals are needed in the Construction Stage.)

[Note  Support services – director quality assurance, SQA (process QA officer), and Configuration Manager are not displayed in this view.]

Summation The Inception Stage is arguably the most important stage of the project. The outlines of the effort are defined, the requirements for nonfunctional requirements are identified, and security constraints are established. These are important factors both to keep the project in line with expectations, including constraints, and to allow the implementers of the system to plan for levels of access and the need for specialized security support.

52

CHAPTER 4

The Elaboration Stage This view describes the activities of the Elaboration Stage.

The goal of the Elaboration Stage is to develop consensus around a process model of the system to be. This process model will serve as a functional requirements specification (FRS) and will be used to conduct a design review identifying priorities, dependencies, and early estimates of cost. In this example, the process model is represented by a data flow diagram (DFD) (see Appendix D). © Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_4

53

Chapter 4

The Elaboration Stage

The Process Overview Cycle elaborates the objectives of the system as declared in the Vision Statement. The initial cut can be derived from the organization’s Project Champion and the department heads. The lower levels and business rules may not be uncovered until review in the Process Detail Cycle of the Construction Stage. The upper levels will show necessary data stores from which a preliminary database can be derived. This database can be instantiated and populated with test data to demonstrate the general use features described in the following. In short, the Elaboration Stage creates a picture of the system to be, baselined as Version 1.0. This is subject to enhancement during the Process Detail Cycle in the Construction Stage, leading to Requirements’ Baseline 2.0.

Activities During Elaboration The main activity of the Process Overview Cycle is to create a high-level process diagram such as a data flow diagram (DFD) measuring the scope and scale of the project. This process follows the Deming PDCA quality control cycle.

PLAN Phase of the Process Overview Cycle Develop a list of department heads of those offices affected by the proposed system. Schedule meetings at their convenience – use leverage of the Project Manager and/or the project’s “Champion” as needed. The PM may arrange the initial appointments on behalf of the analysts; this serves to consolidate a point of contact for the interviewees above the head of the interviewer. This serves a political purpose, but shall not distract from the work being done. It does not betray trust of the analysts, who shall thereafter make their own arrangements, but smoothens the way (also known as greasing the runway…). 54

Chapter 4

The Elaboration Stage

Do Phase of the Process Overview Cycle Business analysts carry out the interviews and develop user stories for each particular area. Each story will show as many levels as the interviewee is willing (or able) to relate. Carrying the DFD down to the level of requirements and/or business rules is the purpose of the Process Detail Cycle of the Construction Stage where the individuals who actually perform the work are interviewed. It should be expected that the requirements for business rules are not uncovered until the Construction Stage.

Check Phase of the Process Overview Cycle Gather feedback from the originating party. Resolve corrections and additions as needed, and refer back to the interviewee until agreement is reached that the work product matches the interviewee’s expectations.

Act Phase of the Process Overview Cycle The Lead Business Analyst shall consolidate user stories from each area into one cohesive system diagram. Refer back to interviewing analysts as needed. The Agile Database Administrator (DBA) shall develop a preliminary logical database design from the “data stores” represented on the consolidated DFD. Repeat the Process Overview Cycle until a high-level DFD and initial logical database design are stabilized.

55

Chapter 4

The Elaboration Stage

Figure 4-1.  Essential staffing for DFD and backbone development activities

Ongoing Activities Database Administration The Agile DBA shall maintain liaison with the support DBA, identify existing data repositories that may impact on the implementation process, and determine whether or not a conversion from a legacy system is required. The Agile DBA and Data Analyst shall also initiate work on a data dictionary in conjunction with the project’s librarian. The librarian shall also collect and maintain: •

The glossary

•

A list of abbreviations and list of acronyms

•

A populated organization chart with names, titles, and contact information

The librarian initiates document control – one page example for documentation – showing date and attribution. 56

Chapter 4

The Elaboration Stage

Other Activities •

Continue review and further specification of nonfunctional requirements – including usability requirements.

•

Continue to identify security considerations.

•

Implement Quality Engineering Plan for Elaboration.

The Configuration Manager sets standard for configuration item naming conventions. The Lead Business Analyst presents a DFD example and identifies materials for business rule review.

Additional Responsibilities The Project Manager (PM) shall maintain liaison with the organization’s personnel, in particular the “Champion” or supervisory person from the organization. The PM may also run point in setting up the interviews between business analysts and department heads, in conjunction with the point person from the organization. The lead tech and system architect shall begin work on the application backbone comprising the general use features described earlier, as specified by the lead tech during the Inception Stage. Still under the purview of the technical specialists, the lead tech and system architect shall initiate code version control using tools selected by the lead tech. The lead tester is available at this stage principally as an observer. This individual shall also work with the DBA to proscribe code and data baselines and recommend tools as appropriate to the size and scope of the project.

57

Chapter 4

The Elaboration Stage

Data Flow Diagrams A DFD is a venerable tool from structured programming which has fallen into lack of appreciation. (A state transition diagram might be more appropriate for an SOE, and indeed may be used as a decomposed requirement for the user interface of an SOR.) The DFD is important for a number of reasons: •

It provides an overview of the system to be.

•

It exposes data requirements.

•

It reveals process and data dependencies.

•

The decomposed DFD processes help identify the “epics” under which user stories reside.

•

It brings the end user community into the development process.

•

With user involvement most important, it builds consensus around the project expanding the Vision Statement with greater specificity.

•

It provides sufficient information to substantiate a preliminary estimate of level of effort and cost.

F unctional Requirements Specification (FRS) vs. System Requirements Specification (SRS) The DFD represents sufficient information to constitute a functional requirements specification (FRS) for “low ceremony” review. The FRS substitutes for a full “high ceremony” system requirements specification (SRS)

58

Chapter 4

The Elaboration Stage

wherein requirements are fully defined. The FRS (which may be amended under review) provides a “sign-off” milestone for the development effort to continue. The FRS represents a “lean” approach to defining the development effort as early as possible in the overall effort. The FRS also serves the political purpose of consolidating organizational support for the project, and obtaining consensus and commitment for the “go ahead.”

Design Review After circulation, the completed high-level DFD (the FRS) is presented to the group of contributors following a design review session. This may be the first time that Department A sees what Department B is all about. This may be a workshop session – whereby Department principals have another chance to apply changes. With approval of the overall design, the level of effort in terms of full-time equivalents (FTE) can be estimated as cost. However, before a schedule can be proposed, a prioritization must occur.

 uccessful Requirements Prioritization S Requires Knowledge of: Needs/problems of the customers and the relationship of various product requirements to the solutions of those needs/problems Relative importance of requirements to the customers: How to determine this is not easy and is addressed later in the chapter. (Simply asking the customers/stakeholders is usually not effective, as they tend to claim that all the candidate requirements are vital.)

59

Chapter 4

The Elaboration Stage

Timing – What is the market window? By when does the customer need each requirement to be addressed? How to determine this is not easy and is addressed later. (Customers tend to claim that all requirements must be satisfied immediately.) The relationships between requirements include the following: •

Relationships among requirements:

•

Must requirement A be satisfied in order for B to be satisfied?

•

If requirement A is satisfied, is B still needed?

•

Is requirement B easier to implement if A is already implemented?

•

Is requirement A consistent/compatible with B, C...?

Cost of satisfying each requirement – How many/much resources will be expended to satisfy the requirement (in terms of money, effort, time)? Requirements prioritization should be performed for every planned release of a product, to decide which requirements to satisfy in that release. Also, requirements triage activity should be repeated each time new requirements arise or new resources become available. Following design approval, there must be some interval of time to bring appropriate personnel on board. Hardware requirements must be ordered and put in place with the involvement of support operations, and appropriate testing tools and version control tools should be made ready. Work should be continued by the lead tech and system architect on the development of the application backbone – particularly on the completion of an audit trail (where required). Any coding framework shall be put in place by the system architect. The DBA will define the partitions needed for data migration (the sandbox version for developers, the version required for test, and the versions required for system integration and acceptance test.

60

Chapter 4

The Elaboration Stage

 etermine Staffing, Roles, D and Responsibilities. Begin the Hiring Process for the Construction Stage Initial Roles from Inception 1. Project Manager 2. Business analyst(s) – commensurate to proposed project scope

 oles Added During Elaboration (Start Recruiting R During Inception) 1. Technical Project Manager 2. Director Quality Engineering 3. System architect 4. Agile Database Administrator (DBA) 5. Data Analyst 6. Lead tester(s) 7. Lead programmer(s) 8. Configuration Manager 9. Librarian 10. Secretary/admin assistant 11. Software Quality Assurance (SQA) (process QA) officer

61

Chapter 4

The Elaboration Stage

Rules of the Road (Staffing) •

A person can play more than one role – such as Project Manager/Process Quality Assurance officer during Inception, or programmer/analyst during Construction.

•

On the organization’s side, the project’s “Champion” may play the roles of COTR, sponsor, and chairperson of the CAB.

•

Further, more than one person can play a single role such as business analyst(s), programmer(s), or tester(s).

•

Finally, not all roles need to be filled depending on the scope and scale of the project (e.g., data conversion specialist).

Roles and Responsibilities The distinct responsibilities during Elaboration covered in Tables 4-1 and 4-2.

62

Chapter 4

The Elaboration Stage

Table 4-1.  Roles and responsibilities (development team) 1. Project Manager • Maintains liaison with shareholders’ representatives • Tracks progress toward objectives and burn rate • Carries forward major Change Reports to Change Advisory Board (CAB) 2. Process Quality Assurance Officer

• Implements and enforces standards, guidelines, and procedures • Monitors activity of Configuration Manager and test personnel regarding progress toward objectives • Reports to Project Manager or directly to the principal of the CAB

3. Lead Business Analyst

• Reviews business rules for form and completeness • Maintains repository of business rules in CMDB • Creates initial consolidated DFD

4. Business Analyst(s)

• Maintains DFD sections appropriate to participatory involvement • Populates data flows and data stores • Decomposes processes down to a set of business rules • Works with programmers and test representatives to prepare test criteria prior to coding (Test-Driven Development – TDD) • Works with programmers and testers to convert business rules into code

5. Technical Project • Conducts code inspections and refactoring • Handles and routes Change Reports (CRpts) and Manager (Lead Discrepancy Reports (DRs) Tech)

(continued)

63

Chapter 4

The Elaboration Stage

Table 4-1.  (continued) 6. Coach

• Coordinates development activity (synchronizing programming effort during daily meetings) • Reports on progress to Project Manager

7. Software Architect

• Designs and implements application and system architectures

8. Programmer(s)

• Converts business rules (including edits) into code • Conducts unit tests with business analyst and test representative • Maintains software version control • Controls and tests module assembly

9. Data Conversion • Identifies and documents data from legacy systems • Prepares conversion plan Specialist (Where • Carries out conversion in conjunction with DBA Applicable) 10. Data Modeler

• Designs new system database • Oversees implementation and population • Performs V&V for data conversion

11. Agile Database • Creates new system’s logical database Administrator (DBA) • Populates new physical database with test data • Maintains database baselines and Data Analyst • Carries out conversion in conjunction with data conversion specialist

(continued)

64

Chapter 4

The Elaboration Stage

Table 4-1.  (continued) 12. Configuration Manager

• Maintains software configuration inventory (SWCI) and hardware configuration inventory (HWCI) • Maintains traceability matrix linking vision statement objectives to business rules to code, referential integrity, screens, and reports

13. Librarian

• Keeps track of project documentation • Maintains glossary, list of acronyms, and data dictionary • Keeps track of the emergence of nonfunctional requirements

14. Lead Tester

• Coordinates activity of other members of test team • Supervises system test • Supervises acceptance test

15. Test Team Member(s)

• Works with programmer(s) and business analyst(s) to prepare test criteria prior to coding (Test-Driven Development – TDD) • Works with programmers during Service Assembly Cycle in the Assembly Stage

16. Technical Writer • Produces user manual before acceptance test; usually best handled by a specialist 17. Security Consultant

• Works with software architect, lead tech, database administrator, operations and network administrator to preserve system integrity and seal leaks against attacks

65

Chapter 4

The Elaboration Stage

Table 4-2.  Roles and responsibilities (ownership team) 1. Contracting Officer • Keeper of the purse. Normally does not interact directly with the development team 2. Contracting Officer’s Technical Representative (COTR)

• Representative of the Contracting Officer who interacts with the development team. (US Gov’t projects) Monitors progress toward objectives (may be the project’s “Champion”)

3. Sponsor or “Champion”

• The primary person with the “vision” of the system to be. Works directly with the development team’s Project Manager

4. Chairperson of Change Advisory Board – CAB

• Should be the project “Champion” or a single representative of the shareholders

5. Stakeholders

• All those affected by the new system to be

6. Area Specialists

• Subject matter experts (SMEs). May be section heads or subordinates with firsthand knowledge of applicable “business rules”

7. Support Personnel • Observe/participate in system test and acceptance testing • Conduct verification and validation (IV&V) for data conversion and system implementation • Maintain system after turnover

66

Chapter 4

The Elaboration Stage

 esign, Develop, and Document D the System Architecture Constraints on the refinement of a system framework are software services above the level of the operating system shared by unit, module, and system levels of code. They may be handled internally by a RDBMS (Relational Database Management System) such as Oracle, or by a second layer object broker or other similar structure. These include: •

Communication – a mechanism for handling interprocess communication

•

Event management – a mechanism for handling asynchronous events within the system

•

Persistence – a mechanism for allowing system data to be written to disk

•

Transaction management- CRUD (create, read, update, delete), a set of properties that guarantee database transactions are processed reliably

•

Cache and memory management (where appropriate)

•

Exception management – error log

•

System error management

•

Interface – resolution of conflicts/identification of shared characteristics (variables, naming conventions, global variables)

67

Chapter 4

The Elaboration Stage

 emonstrate an Operating Backbone D for Shared System Functions As it is used here, backbone is a set of features that transcend application module boundaries, providing required services. The following are features that impact the application backbone. In general, these features deal with services outside unit and module code boundaries. This list is not exhaustive, nor will all these features be present in all systems. The basic backbone shall be up and running before application coding begins in the Construction Stage – demonstrating (where appropriate): •

User maintenance – add and remove users

•

Sign-on/sign-off function – authentication

•

Password control (change password)

•

Approval of changes to passwords or authorizations

•

Assign organizational privileges – authorization

•

Maintain lookup tables – such as organizational structure

•

Navigation testing

•

Application error management

•

Audit trail (where required)

These general functions provide the basic services of sign-on/sign-off, population of the user table, and the assignment of security and organizational identifiers, necessary to begin construction of the new system.

Application Design Requirements The following are functional features of the application not elsewhere specified (i.e., not business rules) that impact the system backbone. 68

Chapter 4

The Elaboration Stage

Table 4-3.  Design requirements Handling Violation of • Wrong number of parameters Input Limits • Improper data types – white spaces and special characters • Range limit conditions • Required field • Mistake handling • Accuracy (precision, resolution) for any calculations Common System Applications

• Printing capability • Reporting • Integrated email

Specialized Functions

• System management in a distributed environment • Licensing – restricted access • Localization – multilingual • Workflow – moving documents and other work items (e.g., review and approval phases)

Interfaces and Interoperability

• Connectivity – protocols (e.g., Bluetooth) • Cross platform (e.g., website, smartphones, tablets, touch screens) • Voice recognition – speech • Interface with third-party components – e.g., COTS software (commercial off-the-shelf)

Usability Requirements

• Online Help • Chat • In context help (F1) • Feedback to user from application • Special needs

69

Chapter 4

The Elaboration Stage

Introduction to Configuration Management Database (CMDB) A CMDB is a view of an aggregation of databases held throughout the system. (See Figure 4-2.) One of its practical uses is to support the activities of a help desk. The CMDB also allows the production of the Traceability.Matrix. The CMDM is a requirement of ITIL (Information Technology Infrastructure Library) and facilitates CMMI Certification (Capacity Maturity Model Integration). In this embodiment of a CMDB, both the requirement record and the test case Record provide pointers to offline requirement and test case documents, respectively. This is done because both requirements and test cases may take many forms, many of which do not lend themselves well to online processing or indexing. Actual tests are tracked in the Test Log table. When a test yields other than the expected result, a Discrepancy Report (DR) is issued to convey the result back to the developers. Discrepancy Reports are tracked in the DR table. In this interpretation, both the CRpts and the DRs themselves are written in hard copy, being easier to track – with the distribution and disposition held in the online file. The CMDB includes tools for collecting, storing, managing, updating, and presenting data about all configuration items and their relationships. The CMDB is maintained by configuration management and is used by all IT Service Management Processes.

70

Chapter 4

The Elaboration Stage

Figure 4-2.  Representational view of the CMDB

T he CMDB Shall Comprise at Least the Following Information Table 4-4.  CMDB components People Files

Staff (division, dept, office, security level) Development team (role) Support – including help desk Maintenance Help desk/end user Change Advisory Board (CAB)

(continued)

71

Chapter 4

The Elaboration Stage

Table 4-4.  (continued) Functional Requirements

Requirement (vision, process) Business rule Software Configuration Inventory (SWCI) ID Trigger Screen Test case

Operational Tables

Discrepancy Report (DR) Change Report (CRpt) Error Report Test log

There are six tables that identify the participants: 1. The staff table identifies those persons from the organization that have contributed to the determination of requirements, including subject matter experts (SMEs), those responsible for checking the progress of implementation, and those serving in an supervisory capacity. These individuals are traced to their place in the organization by tables listing division, department, and office – held as individual tables to enable any reorganization that may occur – including individual transfers between organizational components. 2. The development team (Dev Team) table identifies the role or roles that each member fulfills. An individual can play more than one role, and each role can be played by more than one person (manyto-many relationship). 72

Chapter 4

The Elaboration Stage

3. The support table identifies those individuals from the organization’s IT community that play a role in the development effort. Individuals may play one or many roles. 4. Support has a breakout to accommodate the help desk support persons. 5. The help desk identifies incident reports by end user and by screen identifier, the latter enabling trace back to software component in the SWCI (Software Configuration Inventory) database and from there back to requirement, process, and Vision Statement objectives. 6. The final table for participants is the Change Advisory Board (CAB). The CAB table comprises the project’s champion and other designees who rule on Change Reports (CRpts) of impending changes to the vision objectives, forwarded to them by the development team. This approach differs greatly from the traditional functions of a Change Control Board (CCB), processing change requests (CR). The approach here is for a less formal (medium ceremony) option whereby notification is given of deviations from business requirements uncovered by the implementers (programmers and/or business analysts) as Change Reports (CRpts). Those CRPTs affecting major change, such as circumstances not covered by the vision objectives, are forwarded by the Dev Team to the CAB. All CRpts are tracked by the Configuration Manager in the CRpt table with the original kept in hard copy.

73

Chapter 4

The Elaboration Stage

The Traceability Matrix A maintenance programmer should be able to trace a problem back to the business rule which the program is meant to embody. Similarly, in the event of a change to a business rule, the programmer needs to trace the implementation forward to code. The traceability matrix exists as a set of “foreign keys” placed in relevant tables (entities). These data are retrievable as a set of SQL queries that create reports or sets of temporary tables. One representation of the matrix is represented in Table 4-5. Each record in each table should contain foreign keys for each attribute represented.

Table 4-5.  Contents of a traceability matrix • Vision objective number(s) • Persons by type: • Business analyst(s) • Subject matter experts (SMEs) Programmer development team Tester(s) • Program identifier(s) • SWCI identifier • Program (unit) label • Screen, report, or web page • Process number (from DFD) • Business rule(s) • Edits • Referential integrity • Business rule analyst(s)

On Joint Application Development (JAD) Please note – There will be the temptation to have the DFD developed in a single or series of early JAD sessions. This is not a good idea because:

74

Chapter 4

The Elaboration Stage

1. Some interval of time on the part of the analyst is required to digest the design and development of a DFD, allowing time for multiple passes. 2. Iterative development on a one-to-one basis is more likely to achieve the desired outcome of uncovering requirements with completeness and accuracy. 3. Time is required to develop the finished DFD in presentable form. 4. The completed design segments should be cyclically reviewed with the individual interviewees before a final version is approved.

On Workshops (In General) The downside to workshops: •

People need time for the “little gray cells” to work.

•

Some people are embarrassed to speak in front of a group.

•

A few users tend to dominate the conversation.

•

Expensive use of time – waiting for a turn to speak.

•

Difficult to schedule (unless mandated).

Successful workshops: •

Post Vision Statement retrospective.

•

Kick off meeting following design review.

•

Work to establish “ubiquitous language” of domain.

•

Introduce tools and methods.

75

Chapter 4

The Elaboration Stage

•

Introduce developer’s vocabulary.

•

Reveal DFD example.

•

Demonstrate support from higher levels of management – mandated attendance.

S  ummation The Elaboration Stage comprises the production of a data flow diagram defining a functional requirements specification (FRS) for the system to be. It also comprises demonstration of the application backbone to include: •

Maintenance of a table of users with password, organizational designation, and assignment of clearances

•

Tables to record development and support personnel tied to a particular item of software

•

Sign-on and sign-off capabilities

•

Initiation of a user audit trail

These data are elements of the Configuration Management Database (CMDB) and the traceability matrix tied back to the objectives of the Vision Statement in the Inception Stage. One of the most important activities of the Elaboration Stage is to begin to collect resumes for staffing in the Construction Stage. The Elaboration Stage ends with a review of the FRS from which an early estimation of level of effort and cost of construction can be derived.

76

CHAPTER 5

The Construction Stage This view describes the activities of the Construction Stage.

The Construction Stage comprises two cycles of activity: the Process Detail Cycle and the Unit Development Cycle. These cycles operate as re-entrant spirals. Each cycle iterates for some number of times until user feedback is satisfied at that level. These cycles © Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_5

77

Chapter 5

The Construction Stage

may follow each other in succession or may circle through the same cycle several times – depending on the complexity of the task, user feedback, and/or the composition of each team. (See Figure 5-1 Spiraling Cycles.) There will be multiple instances of these spirals representing work by different teams. These spirals have a number of iterations as teams work concurrently decomposing different parts of the high-level system view. Each spiral, however, begins with a Process Detail Cycle and ends with a Unit Development Cycle. Iterations in both categories need not be of equal duration, nor need the teams in each cycle be composed of individuals with the same job description. Change Reports (CRpts) are notifications by the prime movers that they have encountered a response that may be beyond the defined scope of the project’s objectives and/or vision. They may be issued at any time – when a reportable circumstance is encountered.

Figure 5-1.  Spiraling cycles of activity during the Construction Stage 78

Chapter 5

The Construction Stage

The Process Detail Cycle The focus of the Process Detail Cycle is to elicit business requirements from the user community. The Process Detail Cycle uses an iterative and incremental approach to uncover requirements from subject matter experts (SMEs) and designated members of the user community. It takes the high-level requirements established by the data flow diagram in the Elaboration Stage, and proceeds to iteratively decompose that view to functional requirements and business rules. The Plan Phase of the Process Detail Cycle requires preparation by studying the existing documentation to date and scheduling initial appointments for interviews. The Do Phase carries out the interview. The first part of the Check Phase requires examination of the results of the interview to derive statements of business rules. The Check Phase concludes with another meeting with interviewees to review the results of that analysis. The Act Phase records progress toward objectives and reviews findings to date. (See Figure 5-2.) The goal is to identify and articulate business rules and record them in a form that can be placed under version control and which become the basis for sets of test cases.

79

Chapter 5

The Construction Stage

Figure 5-2.  Process Detail Cycle phases

Process Detail Cycle: Roles and Responsibilities In a traditional setting (waterfall), each requirement is defined by a business analyst working hand in hand with corresponding members of the user community. The business analyst passes the written requirement off to a programmer who renders the requirement in code. The code is then passed off to a tester who passes discrepancies back to a programmer – preferably the programmer who did the original programming. The programmer, who may consult with the business analyst, makes the correction in code, and the process continues as before. When discrepancies are resolved, the product is submitted to a User Acceptance Test – from which the need for further corrections may be identified and the work proceeds through the cyclical process again. As presented herein, “requirements” are derived by a programmer and a test analyst working with a subject matter expert (SME) from the host organization. The write-up (user story or use case and business rules) is then reviewed by the SME for accuracy, and the cycle repeats until the three participants (programmer, tester, and SME) are in agreement. 80

Chapter 5

The Construction Stage

At this point, as the requirements are passed through the Act Phase. They are reviewed by the Lead Business Analyst who inspects the user story or use case for business rules stated in an acceptable (testable) form. When the refinement of a business rule is finalized, it is added to the compendium of business requirements by a business analyst. The inevitability of late discoveries of error proves the need for traceability of software such that each component of software can be traced back to the requirement(s) that it is meant to represent, and each requirement can be traced from a business rule forward to a specific unit of code. Business rules are the heart of a software system. Fulfilling them, or adhering to them, is why the system exists.

A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business ­structure or to control or influence the behavior of the business. The business rules which concern the project are atomic - that is, they cannot be broken down further. Source: David Hay& Keri Healy “Defining Business Rules –What are they really?” (2000) (Google)

 usiness Rules May Take the Form of, But B Are Not Restricted to, the Following User interface (UI) testing •

Required fields

•

Valid entry

•

Input restrictions

•

Interval requirements

•

Contextual help (F1) 81

Chapter 5

The Construction Stage

•

Error messages/error log

•

Application

•

System

Operational Requirements •

Auditing system functions (e.g., number of database updates)

•

Security measures

Lookup Values •

For example, ICD 10-ICD 11 conversion database

•

Real-time updates

•

Currency conversions

“Drop-Down” Values •

Race/ethnicity

•

Appellatives

•

State

•

“Task” selection (as in a timecard service)

Decision Tables

82

•

Formed by a cluster of business rules – each rule dependent on each other

•

Process hierarchy

Chapter 5

The Construction Stage

Process Flow and Dependencies •

IF THEN ELSE.

•

For example, a valid driver’s license must be presented before a rental agreement can be issued.

Rule-Based Constraints •

For example, to be shipped the same day, an order must be received before 3:00PM.

Business Definitions •

For example, “The debt over income ratio is the ratio between total debt obligations over gross income for the same period (monthly or yearly).”

Data Integrity •

Item sold means deduction from inventory.

•

Deleted person means also deleting address.

 ompliance with Audit and Regulatory C Requirements (a Nonfunctional Requirement Shaping Code) •

For example, HIPPA

83

Chapter 5

The Construction Stage

 ompliance with External Requirements C for Certification (also a Nonfunctional Requirement Shaping Code) •

For example, CMMI

•

Adherence to a set of standards, such as standards for code formatting

Data Constraints •

What data may be or must be updated, e.g., required fields; restricted range of accepted values; date less than or equal to TODAY

•

Proscribed range of values

 usiness Rule Review (in the Act Phase B of the Process Detail Cycle) The Review only takes place when, in the judgment of the analysis team, further iterations of the Process Detail Cycle will yield no further decomposition. Otherwise, passing through the Act Phase will only initiate the recording of movement in an assignment status database. (See Table 5-1.)

Roles for Review Panel

84

•

Moderator (Software Quality Assurance Representative)

•

Inspector (Lead Business Analyst)

Chapter 5

•

Inspector (lead test)

•

Recorder

•

Representative from maintenance

The Construction Stage

Lead test is included in the review to begin formulating a test plan. Each test case comes from a business rule or from operational necessities. A representative from maintenance is included to continue to build and carry forward “tribal knowledge.”

Requirements Inspection Checklist • Is the requirement in scope for the project, release, or iteration? • Is each requirement uniquely and correctly labeled? • Is each requirement traced back to its origin (e.g. system level requirement from DFD, regulatory imperative (e.g. HIPPA), business rule)? • Is the requirement decomposed to its lowest level? • Is each requirement verifiable by testing, documentation, review, or analysis? • Do the requirements provide an adequate basis for design and test? • Have algorithms intrinsic to the functional requirements been defined? • Is the expected behavior documented for all expected error conditions? • Do any requirements conflict with or duplicate other requirements?

85

Chapter 5

The Construction Stage

Source: Judiciously extracted from a “master list” found in Karl Wiegers and Joy Beatty Software Requirements 3rd Edition This checklist is included in the set of standards, guidelines, and procedures available to all on a Wiki (read only). Each project member is required to adhere to the material on the Wiki – notice of updates is disseminated by email.

Perspective Requirements are living things. Requirements evolve throughout the development process and into the Support Cycle. At each level of development, requirements mature to define what needs to be done and how that goal is to be achieved.

Requirements Are Necessary •

To achieve agreement with the customer on what is to be done

•

To define the means of how those goals are to be accomplished

•

To establish an estimate of the level of effort required

•

To initiate the basis for a testing regime

•

To facilitate communication among the development team

Requirements are used to establish priorities. Requirements must be traceable to the Vision Statement and Project Objectives. The goal of requirement specification is to make requirements traceable, visible, and accountable to the source thereof (i.e., the team members and the shareholder from whom the requirement was derived). 86

Chapter 5

The Construction Stage

Requirements are embodied in the individual units of code. In the representation above, requirements may be added or refined in each cycle of development. Each unit of code passes through the Act Phase of each cycle until the expectations of the users appear to be met at that level. Requirements are updated or clarified as necessary in each iteration before proceeding to the next, higher, cycle (Unit Development).

Table 5-1.  Activities during the Act Phase of the Process Detail Cycle Activity

Responsibility

Detail

Business Rule and Requirements Review

Lead Business Analyst

Ensure that business rules and requirements are “decomposed” to “atomistic” statements of testable requirements

Maintain and Update the Requirements Database

Business Analyst Maintain the requirements performing configuration database and online pointers to management offline documents where appropriate

Update and Maintain the Data Flow Diagram (DFD) (Optional)

Lead Business Analyst

Decompose processes to lower levels. Define business rules where appropriate. Add new higher-level processes where dictated by the unfolding requirements inventory

Observers May Lead Tech, Lead Test, Preparation for future cycles. Include Security Consultant, Carry forward “tribal knowledge” Director of DevOps, Agile DBA Representative(s) from SW Support

87

Chapter 5

The Construction Stage

The Unit Development Cycle The activity of the Unit Development Cycle is the implementation of requirements, particularly business rules, in code – where a unit is defined as the smallest piece of stand-alone, testable software. Testing code is part of the Unit Development Cycle. The “Check” Phase of the Deming formula is split into two parts. The “Test” part verifies that the code is doing what it is supposed to do without error. The “Review” part validates that what the code is doing meets the needs of the user.

“Test” is testing to requirements. It is entirely probable that the Unit Development Cycle will be repeated to accommodate feedback. Any change requiring expansion of the Project Objectives should entail generation of a Change Report (CRpt) which is acted upon as received, per the Procedure for Processing Change Reports.

Figure 5-3.  Phases of the Unit Development Cycle

88

Chapter 5

The Construction Stage

Change Reports (CRpts) Upon receipt of a Change Report (CRpt), it will be logged in by the Configuration Manager. The Lead Tech will notify the Project Manager and Process Quality Assurance officer who will determine if the scope is outside of the bounds of the agreed-upon objectives, and will collectively inform the CAB of this occurrence. The absolute “razor” is whether or not the circumstance is beyond the scope of the Vision Statement – which would require a more serious decision – made in conjunction with the sponsors of the project. Meanwhile there may be other items that can be addressed independently from the item challenged that will keep the prime movers work in motion.

Build plenty of scaffolding. —Brooks Mythical Man Month

Keep Everything in Version Control Everything you need to build, deploy, test, and release your application should be kept in some form of versioned storage. This includes requirement documents, test scripts, automated test cases, network configuration scripts, deployment scripts, database creation, upgrade downgrade, and initialization scripts, application stack configuration etc Source: Jez Humble David Farley Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, Addison Wesley, 2011

89

Chapter 5

The Construction Stage

Table 5-2.  Activities during the Act Phase of the Unit Development Cycle Activity

Primary Responsibility Detail

Update the Software Configuration Manager Track status of all software Configuration Inventory items (SWCI) Carry out inspections Lead Tech of code as it is finished by development teams

May include a member of the SW Support team for ease of comprehension

Make adjustments as suggested by inspection

Programmer/tester team

In particular the use of in-­ stream comments

Refactoring

Lead Tech

Simplify existing code without changing function

Examine code for vulnerabilities

Security Engineer

Inform and instruct coders regarding correction of vulnerabilities

As unit/component is a completed compute velocity and flow

Project Manager

Flow is a measure of velocity by weighted degree of difficulty

Observers

DevOps, Test, Business Preparation for the next Analyst, Agile DBA, SW iteration Support

90

Chapter 5

The Construction Stage

Configuration Management Configuration management plays a vital part in this process — being mandated to maintain a repository of requirement documentation. The form of documentation will include the user story or use case and business rules. In this interpretation of the model, the programmer/analyst creates the user story, and the test member of the review team sketches out test cases for business rules. These can be recorded in machine-storable Word documents with the narrative at the top, and whatever space is necessary below to represent the business logic and business rules – plus the range of values, lookup values, etc. A clever use of naming conventions for documents and business rules can make this collection manageable, including revisions and updates. This information should also be included in the data dictionary for each element as applicable. The number of interviews and the approach should be left entirely in the discretion of the interviewer(s). The team should be allowed to decide for itself what approach is most appropriate for any particular round, based on skills and personalities of the designees and the tasks ahead. This is the “hands-off” management approach advocated by Agile practitioners. The important thing is that the process continues no matter the result of any particular round, so that each individual and the team as a whole can learn and grow from the experience. Rely on trust rather than command and control. The singular premise of the DPAC model is that “requirements” are ever changing up to and including the User Acceptance Test (UAT) and are additive and cumulative for each cycle. This emphasis is justified by the estimate that 50% or more of errors found in maintenance have their origin in incomplete, faulty, or missing requirements. This suggests that test plans and scripts will need to be modified at each iteration:

91

Chapter 5

The Construction Stage

Industry data suggests that approximately 50 percent of product defects originate in the requirements. Perhaps 80 percent of the rework effort on a development project can be traced to requirements defects. Source: Karl E. Wiegers, “Inspecting Requirements,” StickyMinds.com Weekly Column, 25 July 2001 (Google) Likely as not the first iteration of each cycle will not completely meet the needs of the user who may add additional requirements, including cosmetic changes, the cycle then is repeated until the user provides closure at that level. This may involve regressive iterations of the Process Detail Cycle. (See Figure 5-1.)

Advancement When a unit of code passes user inspection, it is advanced to the Service Assembly Cycle. The “build” process can be semiautomated – the automated integration server can poll the version control repository for finished units to be advanced (built) into services (components). When a build has been completed (with all units comprising that build), the service is then subjected to test and review. At this point, it may be instructive to look at what we are testing.

Unit Development Unit development, including process overview and Process Detail Cycles, is primarily all about the elaboration, and validation, of functional requirements including business rules.

All change is implemented at the Unit Level of code. However, reports may contain embed logic, the database may employ stored procedures, and the security perimeter may be integrated with each unit of code. 92

Chapter 5

The Construction Stage

The second group of test targets is what I am calling “mechanical” tests. “Mechanical” testing: Bug (code error) Free – crash proof (fail soft) Mechanical testing can be defined in two categories: error and conflict management and input testing. Error and conflict management: •

Exception handling – fault tolerance

•

System error handling – recoverability

•

Cache and memory management (where appropriate)

•

Interface testing – resolution of conflicts/identification of shared characteristics

•

Integration problems with COTS (commercial off-the-­ shelf ) software

•

Navigation testing

•

Static testing

The following factors are tested for fault tolerance and recoverability (fail soft) under the following conditions: Violation of input limits •

Wrong number of parameters

•

Improper data types – white spaces and special characters

•

Range limit conditions

•

Required fields

93

Chapter 5

The Construction Stage

Test Plans Each instance of test implies a test plan for that particular cycle which may incur recursive iterations of the Process Detail Cycle. Ongoing activities during the Construction Stage are represented in Table 5-3.

Iterative Development The development process continues to iterate through the Process Detail and Unit Development Cycles until the interviewee agrees with the interviewer that the basic business rules that guide the enterprise (for that particular area) have been uncovered. The user may not be able to refine the requirements until they have actually seen a screen (as the product of an iteration of the Unit Development Cycle). This process may iterate through each cycle more than once, recursively or successively (as in Figure 5-1). In any event, the initial cycle yields a set of process detail statements (requirements/user stories /use case), and the last iteration produces a viable unit of code.

Code Check Code-check software exists for many computer languages. This software should be run and repairs made by the programmer before the inspection begins. Having completed a successful compile of the corrected code, it is inspected by the Lead Tech.

Technical Review Subcycle There is a subcycle in Unit Development Cycle — the examination of source code for a particular unit. This Technical Review Subcycle iterates until all observable defects found in code or statements of requirements have been corrected by its author. (See Figure 5-5.) 94

Chapter 5

The Construction Stage

Test-Driven Development (TDD) The Unit Development Phase of the Technical Review Subcycle is where refactoring and/or Test-Driven Development (TDD) takes place. TDD is not intended to be a substitute for formal unit test, but rather serves to clarify requirements and the means to satisfy them before the unit is compiled. After a successful compile, the unit enters the Source Code Inspection Phase where the source code is processed as described in the following.

T rue to Requirements One of the key criteria for passing the “inspection” will be “true to requirements,” that is, all requirements are met. If the requirements are perceived to be incomplete, the Process Detail Cycle should be repeated to complete the requirements definition.

Table 5-3.  Ongoing activities Activity

Primary Responsibility

Detail

Conduct Periodic Audit of Traceability Matrix

Process Quality Assurance Officer

Assure integrity of the traceability matrix

Produce Reviewable Code

Programmers

Successful unit compile and static test

Capture and Store Test Cases

Test

Store in preparation for continuous integration (CI), continuous delivery (CD), and regression testing

(continued)

95

Chapter 5

The Construction Stage

Table 5-3.  (continued) Activity

Primary Responsibility

Detail

Maintain Data Dictionary

Data Modeler, Agile DBA, Librarian

Concurrent with development effort. Disseminate changes to all teams by email

Collect and Add to: Librarian Glossary L ist of Abbreviations List of Acronyms Org Chart

Keep the most recent versions accessible to all (Wiki)

Initiate Change Reports (CRpts)

Programmer/Test Team

Look for discrepancies between requirements and objectives

Maintain Change Report Database

CM Designee

Maintain a database to track Change Reports

Forward CRpts Immediately to Lead Tech for Evaluation

Configuration Manager

Fast action is the key to NOT hang up the development process

Maintain Liaison with Change Advisory Board (CAB)

Project Manager and Process Quality Assurance Officer

Librarian keeps minutes

(continued)

96

Chapter 5

The Construction Stage

Table 5-3.  (continued) Activity

Primary Responsibility

Detail

Structure and Maintain the Computing Environments

Operations Personnel DevOps

Generate Test Data Test and Data Analyst Manual or Test Data Generator Tool Implement Changes Agile Data Base to Database Administrator Structure

Keep up with changes put forward by developers. Update each “sandbox” version

Audit Unit Status Accounting

Process Quality Assurance Officer

Measure progress toward code objectives from SWCI DB

Audit Baseline Requirements

Process Quality Assurance Officer

Report generated from Requirements Database

I nspections The principal criteria for passing the inspection (which may be substituted by peer review) are: •

Appropriate and understandable in-stream comments

•

True to requirements

•

Conformance to standards

The cycles described herein may not strictly follow Deming’s paradigm; they let actions determine the interpretation of the model, and not allow the model to shape events.

97

Chapter 5

The Construction Stage

Figure 5-4.  Technical Review Subcycle When the Technical Review Subcycle has been completed, processing is released up to the Unit Test Part of the larger Unit Development Cycle. The unit then undergoes User Review, until changes to requirements have abated. This determination is made in the Act Phase of the Unit Development Cycle. Units of code can be processed on a first-come or priority basis – there may be many units of code in circulation at any point in time, each individually following the processes outlined above at different rates (velocity), each passing the milestones at different points in time. If the unit has no user interface (UI), one can be created (or simulated) for the purposes of user review. Test plans are derived from business rules, and are finalized when requirements are stabilized from the preceding cycle. “Test” should be involved with the unit development of the Technical Review Subcycle to assist with Test-Driven Development (TDD) and to prepare test plans for each unit of code. Maintenance should also be involved to assess the maintainability of each particular unit.

98

Chapter 5

The Construction Stage

Figure 5-5.  Classic source code inspection protocol Source: M. E. Fagan, “Design and code inspections to reduce errors in program development,” IBM System Journal, 15, (3), 182–211 (1976). Units completing code-check and inspections are promoted to the Service Assembly server, which process can be automated, leading to the Assembly Stage.

99

Chapter 5

The Construction Stage

The initial set of requirements is produced in the Process Detail Cycle which may be re-entered to further examine the needs of the users.

Figure 5-6.  Test matrix showing the place of code inspection As units are completed, the Project Manager updates estimated costs and level of effort, measuring velocity for each paired team.

100

Chapter 5

The Construction Stage

The Triad Principle Everyone may be familiar with the “Telephone Effect,” where some number of participants is seated in a circle and one initiates the game by whispering a story in the ear of the person sitting next to them. That person whispers what he or she heard to the next person, and so around the circle. The game is that the last person seated next to the person who started the game reports aloud what he or she heard to find that the story last heard is wildly different than the story that started the circle. The term “Power of Three,” as applied to software development, was coined (or made popular) by Crispin and Gregory in Agile Testing, Addison Wesley, 2009. I have long believed that two people cannot communicate fully without the point of view of a third party. This is not so much the difficulty of communication in any given language as it is the product of each person’s experience and intent. A third person’s point of view can help to reconcile the individual intents and vocabularies of two. I call this “the triad principle.”

Staffing for the Construction Stage Staffing for the Construction Stage begins with the accumulation of resumes late in the Elaboration Stage. Following review of the Functional Requirements Specification (the data flow diagram-based FRS), when the extent of implementation is known and approved, the actual hiring process for programmers and testers can begin.

101

Chapter 5

The Construction Stage

Figure 5-7.  Staff already on board One approach to staffing up is to again apply the triad principle. The hiring process should include interviewing the prospective team members both by a representative from test and a representative from programming. Where there is a lead and a backup tester and lead and backup programmer, the lead programmer could be paired with the backup lead tester to interview programmers. Similarly, the lead tester and backup lead programmer in tandem could interview prospective testers. There is more to a successful member of the team than a resume. What one is looking for in addition to a resume is compatibility with the triad approach and, hopefully, compatibility with one another. Giving testers a voice in hiring programmers and vice versa might be a step forward in this regard (see Figure 5-9).

102

Chapter 5

The Construction Stage

Figure 5-8.  Hiring for construction

103

Chapter 5

The Construction Stage

Essential Roles

Figure 5-9.  Essential roles during the Construction Stage

Summation The Construction Stage consists of two cycles: Process Detail and Unit Development. Each cycle may repeat itself until user acceptance is resolved at each level. The work products of the Construction Stage are units or components of code that comprise the services of the system which will be put together in the Assembly Stage. A change request initiated from Assembly filters back to the Construction Stage; all change is reflected in the requirements database and in a traceable unit of code.

104

Chapter 5

The Construction Stage

Both the Process Detail and the Unit Development cycles can be viewed as a back and forth between the client representative and the development team. As units are completed, the Project Manager updates remaining estimated costs and level of effort, measuring velocity weighted by difficulty for each paired team.

105

CHAPTER 6

The Assembly Stage Assembly Stage with emphasis on the included cycles of activity is shown here.

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_6

107

Chapter 6

The Assembly Stage

 ervice Assembly and System S Integration Cycles Definitions

A unit is the smallest piece of stand-alone software. A service is comprised of one or more co-related units/components. A system is comprised of one or more services attached to the “backbone” architecture (e.g., sign-on/sign-off, lookup table maintenance, audit trail, and error monitoring subsystems).

Service Assembly As units successfully advance through the Construction Stage, they are promoted (in the ACT Phase) to the Service Assembly Cycle. At this point, nothing proceeds until all the units that comprise a particular service have been advanced. When a service is assembled, it is returned to the programming team, tested, and again subjected to User Review. Comments from users may require correction to the underlying units of code – which are then sent through the Technical Review Subcycle and the Unit Development Cycle once again. Having achieved a stable version of each service, a technical writer can begin preparation of a user’s guide and training materials.

One does not make corrections to a Service or a System level component; one makes corrections to the unit(s) of code of which the Service is comprised. As each service is completed and all steps of review have been satisfied, the service is promoted to the System Integration area. Both the Service Assembly and the System Integration Cycles involve new rounds of Technical and User Review. New input from users must be reintegrated into unit code. Changes must be synchronized with the requirements base and brought forward to run the respective Unit Development, Service Assembly, and System Integration Cycles again. 108

Chapter 6

The Assembly Stage

The final “test” is the User Acceptance Test. A version of the entire system is put forward to give the users yet another chance to revise requirements including cosmetic issues. The Acceptance Test is run in cooperation with support staff in preparation for deployment.

Figure 6-1.  Accumulation of test cases in the Test Case Repository

 ontinuous Integration (CI), Continuous C Delivery (CD), and All That Jazz… CI, CD, and continuous deployment are well suited for client-facing Systems of Engagement (SOE), where the first look at the product comes at the end of the development life cycle. SORs (Systems of Record) break at each activity cycle in the Construction and Integration Stages and at the Acceptance Test for user feedback and rework as the true needs of the users emerge. 109

Chapter 6

The Assembly Stage

In this interpretation of the DPAC model, test cases accumulate at each cycle – and are summed at the end to constitute the means for a regression test – enabling feedback from the help desk during support to be integrated into the system and tested for conflicts. In this regard, for an SOR the main quality engineering benefit of CI, CD is to facilitate regression testing during support. This is the return on investment (ROI) for the costs of automating tests. This is an arduous process, mostly unthinkable without the use of tools – in particular, tools for software version control and for maintenance of a traceability matrix. When to use automation tools:

Automation refers to the use of strategies and tools which augment or reduce the need of manual or human involvement in unskilled, repetitive, or redundant tasks.

Disadvantages of Test Automation Though automation of testing has many advantages, it also has its own disadvantages. Some of the disadvantages are: 1) Proficiency is required to write the automation test scripts. 2) Debugging the test script is a major issue. 3) Test script maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be re-recorded or replaced by a new test script. 4) Maintenance of test data files is difficult. “Automated testing” means automating manual testing process currently in use. The prime requirement is the presence of a formalized “manual testing process.” 110

Chapter 6

The Assembly Stage

Great effort is required in initial automation of the test cases and maintaining them thereafter. Hence, some sort of cost-benefit analysis is quite helpful before investing money and putting efforts into it. Missing test data, unstable, unavailable, or incomplete test environments are the biggest time consumers in testing. Automation is suited to the following types of testing with specific intentions: Build automation – makes sure each build represents the most current unit of source code. Stress testing – to determine the absolute capacities of the application and operational infrastructure. Performance testing – to provide assurance that the performance of the system will be adequate for both batch runs and online transactions in relation to business projections and requirements. Load testing – to determine the points at which the capacity and performance of the system become degraded to the situation that hardware or software upgrades would be required. Test data generation - scripts that produce test data to maximize coverage of permutations and combinations of input and expected output for result comparison Creation of detailed test cases, including predictable “expected results,” which have been derived from business functional specifications and other design documentation. Automation should have scripts that produce test data to maximize coverage of permutations and combinations of input and expected output for result comparison. 111

Chapter 6

The Assembly Stage

Regression testing — is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is conducted by a test engineer.

Roles and Responsibilities The day-to-day responsibilities of Operations (SysAdmin) include:

112

•

Managing the email server

•

Installing server hardware, and operating systems

•

Configuring servers, networks, storage, etc.

•

Monitoring servers

•

Responding to outages

•

Managing phone systems and network

•

Performing Change Control (at deployment)

•

Backing up and planning for disaster recovery

•

Managing active directory (authorized users)

•

Tracking assets IT buying

•

Deploying software applications and COTS software

•

Enforcing policies around backup, disaster recovery, security, compliance, Change Control, etc.

•

Maintaining firewalls and anti-intrusion software

•

Other non-Support application—related tasks

Chapter 6

The Assembly Stage

•

Server provisioning (a set of actions to prepare a server with appropriate specifications, and made ready for network operation)

•

Assisting in monitoring the system

•

Application performance monitoring

•

Working with IT security

•

Managing the hardware infrastructure, including cloud environments (IaaS, Infrastructure as a Service, or PaaS, Platform as a Service) – with or without containers

Support personnel are responsible for: •

Participating (as an observer) in the entire development to carry forward “tribal knowledge” of the system from its inception

•

Participating as a reviewer in code inspections to assess maintainability

•

Conducting the Acceptance Test

•

Monitoring application and system health

•

Providing end-user support

•

Defining new work as needed to complete/augment the production system

The Emerging Role of the DevOps Engineer DevOps engineers are dedicated to ensure that an instantiation of code is migrated efficiently through the build and delivery processes including transition to maintenance and IT operations.

113

Chapter 6

The Assembly Stage

The qualifications of the DevOps engineer include •

Be an excellent system administrator.

•

Experience deploying virtualization (cloud).

•

Hands-on experience in network and storage.

•

Ability to code and script.

•

Soft skills are a must-have.

•

Be a bridge between the DevOps and operations teams.

•

Strong grasp of automation tools including test.

•

Security aspects of the IT transformation.

•

Knowledge of testing.

•

Data management skills.

•

Comfort with open collaboration, open communication, and reaching across functional boundaries.

To put this difference another way:

1. D  evops’ job is to collaborate on a high-level and ensure synergy in each section of the company. A system administrator is more focused on configuring, keeping up and maintaining servers and computer systems. 2.  Devops personnel are known for their experience working on a product from end-to-end, while sysadmins are only confined to smaller scope and responsibility. 3.  Devops personnel can do everything a sysadmin does, but a sysadmin cannot do everything a devops guy does.

114

Chapter 6

The Assembly Stage

Source: “What is the difference between devops and system administrator?” Damian Wolf, star Advisor, Contributor, InfoWorld | Jul 21, 2017 The Lead DevOps Engineer maintains liaison with development (Lead Tech) and operations (SysAdmin) and assumes scheduling responsibilities with Database Administration, Test (for automated and manual testing), and Maintenance. In this regard, the DevOps engineer functions like an air traffic controller (with the assistance of appropriate tracking tools). (See Figure 6-2.)

 ystems of Record (SORs) and Systems S of Engagement (SOE) This interpretation of the DPAC model is for a SOR, such as a Management Information System (MIS), as opposed to a client-facing SOE such as a mobile application. After each unit of code has passed through Service Assembly, the System Integration Cycle, and the Acceptance Test, the finalized test cases are scripted in automated test tools. In the DPAC model, test is embedded into each cycle of activity, testing each unit of code as it is being created. The proposition here is that software tested in an activity cycle forms the basis for User Review. With the test cases created and stored, any future change to the system can be accommodated. The overriding member of the tool chain is configuration management, in particular version control. This is particularly necessary to accomplish build automation – where each build consists of the most recent versions of unit code.

115

Chapter 6

The Assembly Stage

Figure 6-2.  Test steps spread over the development cycles of activity

Test Data Management Having the right test data is the first important step in automation. If your test data is not stable, you will never succeed. According to software industry statistics, nearly 30 percent of test execution failures are due to improper test data. Once you have defined the required attributes, where is the best place to find test data? To be completely flexible, and with the new GDPR legislation especially, it makes sense to build up required test data synthetically. This is a good option if you don’t need historical data (even though that is also possible to build) and if your data setup is not too complicated or distributed across too many different systems. If you require more complex data, you might use existing customer data that has been anonymized. In this case, queries are needed to find data in the databases matching the exact combinations of attributes. Usually, a combination of both approaches works best. Creating synthetic test data and running queries on a database to attain highly suitable test data can and should be automated. 116

Chapter 6

The Assembly Stage

Proper test data management is not only a must for automation; it’s required for manual testing as well. According to some surveys and statistics, manual testers spend 50 percent to 75 percent of their effort on finding and preparing appropriate test data. Test data must be independent from people maintaining it for you to get a return on investment. Source: Denise Rigoni. “5 Key Factors to Achieve Agile Testing in DevOps” StickyMinds To Go Newsletter [[email protected]] - December 12, 2018

The Agile DBA Data modeling serves as a link between business needs and system requirements. The creation of a data flow diagram (DFD) early in the Elaboration Stage depicts how information flows through the enterprise, and identifies data stores that can be easily transferred into a preliminary logical database design. In the case of an MIS project – the physical database model is more or less the same as the logical model. The Agile DBA responds to requests by Tech and Business Analyst(s) for changes to the database structure. Just as the outer face of the system emerges from iterative input from the user community, the inner face, the actualization of that vision in an agile development setting, is highly dependent on communication between members of the development team. This interaction is especially critical regarding the solidification of the foundation of the system – the database.

117

Chapter 6

The Assembly Stage

Figure 6-3.  Integration of test cases with database design While changes in code can be easily tossed away and restarted, changes to the database are more ponderous. Simply put, the lone coder is (generally) the only person affected by tossing away and restarting writing the code of a particular “program,” whereas the database is in use by

118

Chapter 6

The Assembly Stage

many who would all be affected by a database design “restart.” To address this concern, database restructuring (refactoring) should be managed by scripts – maintained in version control for retractions or reruns.

All database changes are database refactorings. The changes that are made to the database alter the way the database stores information, introduce new ways to store information, or remove storage that’s no longer needed. But none of the database changes, on their own, change the overall behavior of the system. Consequently we can see them as fitting the definition of a refactoring. One of the big differences about database refactoring is that it involves three different changes that have to be done together: •

Changing the database schema

•

Migrating the data in the database

•

Changing code that is affected by the change

The key difference of carrying out change to a work product between coders and the Agile DBA is the extent of impact, which change to the database can be can be made less taxing by maintaining a script library. Whenever we describe a database refactoring, we have to describe all three aspects of the change and ensure that all three are applied before we apply any other refactoring.

D  evOps and the Database There is no greater or more significant need for collaboration and cooperation than in the co-development of the emerging database.

119

Chapter 6

The Assembly Stage

Changes to the database schema brought forward by members of the programming team must be reconciled with existing code attached to those changes. Some sort of procedure must be in use to alert all members of the team of proposed changes prior to implementation… (email). Resolution of the matter may be a simple as a line item to be addressed in stand-up meetings. The designated librarian, under advisement of the Data Modeler, updates the data dictionary – which is maintained and available to all (read only) on a Wiki. The accumulated glossary and list of abbreviations are also kept on a Wiki where anyone can add entries as they emerge – routed through the project’s librarian. A request for change is first addressed to the Data Analyst who must assess the impact upon the present data structure and effort to implement the change. The DBA will then communicate the proposed change to all other members of the coding team including an alert to the Configuration Manager (CM) for tracking purposes. Each member of the team must then examine the impact of the proposed change on their code base – especially as regards SQL code that may be scattered here and there. Considerations against the change and conflicts should be called to the attention of the requesting party, the DBA, and again to the tracking database. CM will monitor inaction/or action taken. During transition, the database supports both the old access pattern and the new one simultaneously. This allows time for older systems to be migrated over to the new structures at their own pace.

120

Chapter 6

The Assembly Stage

S  ummation The Assembly Stage takes completed units of code and integrates them into services (the Service Assembly Cycle) and integrates the completed services into a system (System Integration Cycle). This involves the removal of stubs, mocks, or flags that simulated integration in the previous cycle – Unit Development or Service Assembly. It also requires test data that needs to be populated in a mature database design. It is only when the units or services are integrated that the users can see the units of code in the context of actual assembled component. Each step in the process should have its own fallback path – to return to the unit of code that has caused a test failure.

121

CHAPTER 7

The Evolution Stage Activity cycles of the Evolution Stage: Deployment and Support.

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_7

123

Chapter 7

The Evolution Stage

The Deployment Cycle The basic idea of the Deployment Cycle is to provide a path for rectification of errors reported during the User Acceptance Test (UAT) and even after deployment. The UAT should be carried out in a staging area, with the same nonfunctional identity as the production server. Errors in either area must be routed back to the Unit Development Cycle for repair or correction. Once repaired, the unit of code is moved ahead through the same build and integration processes, and the system is redeployed to the staging area for reexamination. When the UAT delivers a positive result (no defects observed), the system is then released to the production environment. There are things that must be in place prior to deployment: 1. Development of installation and deinstallation scripts 2. Development and distribution of documentation 3. Development of training materials (These last two will require the services of a technical writer. Plan for it.) Documentation must include, at the least, for each distribution group: Operations •

Backup procedures

•

Installation and deinstallation procedures

•

System administrator’s guide (Operations Manual)

Support

124

•

Contacts within development and operations

•

Support call procedures

•

Data dictionary

Chapter 7

•

Traceability matrix

•

Screen identifiers for rapid identification of problem areas

The Evolution Stage

Users •

Reference manual

•

User’s guide

•

Tutorial manual

Development of a Deployment Strategy Deployment is an important issue during the full project life cycle, not a last minute consideration. Source: Scott Ambler & Larry L. Constantine. The Unified Process Transition and Production Phases. Berkley, CA: CMP Books, 2002

Never underestimate the complexity of launching your latest system. Source: Scott W. Ambler, Planning for Deployment. ibid. “Many folks like sausages but no one likes to see how they are made.” The processes of deployment and delivery are indeed so complex that two books can be recommended to the interested reader. Jez Humble & David Farley. Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. Upper Saddle River, NJ: Addison Wesley, 2011 And Max Martynov & Kairill Evstigneev. Continuous Delivery Blueprint: Software Change Management for enterprises in the era of cloud, microservices, DevOps and automation. n.p.: Grid Dynamics, 2017-2018 The point here is that the DPAC model offers a view of the path to correction of errors and reinstallation whatever the deployment strategy. 125

Chapter 7

The Evolution Stage

The Support Cycle “Software Support is defined as the totality of activities required to provide cost-effective support to software.”

Activities are performed during the pre-delivery stage as well as during the post-delivery stage. Pre-delivery activities include planning for post-delivery operations, maintainability, and logistics determination for transition activities. Postdelivery activities include software modification, training, and operating or interfacing with a help desk. Source: P. Bourque and R.E. Fairley, eds., Guide to the Software Engineering Body of Knowledge, [SWEBOK] Version 3.0, IEEE Computer Society, 2014. Also found in Thomas Pigowski Practical Software Maintenance, 1997 Wiley p 46

Specifically, the Activities of Support Include

126

•

Correction of errors and defects

•

Improvements to the design

•

Conversion of programs so that different hardware, software, system features, and telecommunication facilities can be used to interface the program to other programs

•

Making changes in files or databases (by DBA)

•

Making enhancements or necessary changes to the application

Chapter 7

The Evolution Stage

T here Are a Number of Processes, Activities, and Practices That Are Applicable to Software Support •

Transition – a controlled and coordinated sequence of activities during which software is transferred progressively from the developer to the maintainer (deployment cycle).

•

Program understanding – activities needed to obtain a general knowledge of what a software product does and how the parts work together.

•

Impact analysis – a technique to identify areas impacted by a potential change.

•

Modification request acceptance/rejection – modifications requesting work may be rejected by maintainers and rerouted to a developer.

•

Support help desk – an end-user and support coordinated support function that triggers the assessment, prioritization, and costing of modification requests.

•

Training for both new users and new support personnel.

•

Support Service-Level Agreements (SLAs) and Support licenses and contracts – contractual agreements that describe the services and quality objective.

127

Chapter 7

The Evolution Stage

About Software Support

Figure 7-1.  Percentages of user enhancements by type Source: Bennett P Lientz Issues in Software Maintenance1983 Data from Lientz and Swanson 1980

Figure 7-2.  Breakdown of support tasks by the total number of person-hours

128

Chapter 7

The Evolution Stage

Source: Chart from Bertrand Meyer, Object-Oriented Software Construction, 2nd Edition ISE Inc, Santa Barbara CA, 1998 Correction of data drawn from the seminal publication - Bennet P. Lientz/E. Burton Swanson, Software Maintenance Management. A study of the Maintenance of Computer Application Software in 487 Data Processing Organizations. (p.73) Addison Wesley 1980. Referred to hereinafter as [Lientz and Swanson 1980] Most of the changes in user requirements are in the form of changes to reports. (See Figures 7-2, 7-3.) In my personal experience, about half of my time, in succession, was spent creating new or modifying old reports and the other half attempting to resurrect a module of the system left unfinished by the original development team. In deciding who will carry out the software support function, software engineering organizations may stay with the original developer or go to a permanent Support-specific team (or maintainer).

 aving a Permanent Support Team Has H Many Benefits •

Allows for specialization

•

Creates communication channels

•

Promotes an egoless, collegiate atmosphere

•

Reduces dependency on individuals

•

Allows periodic audit checks

•

Maintains tribal knowledge of the system

129

Chapter 7

The Evolution Stage

Error Correction While estimates of the ratio of how much time for correction during Support varies, the latter in the project, a bug is discovered the higher the cost of repair. There are some evident reasons for the delay: •

Finding the original programmer may be difficult as he or she may be tasked to different things.

•

Bringing someone in cold to repair that code requires time to have that person “read in.”

•

The delay of moving report of an error from the help desk to action to correct the error can be fraught with bureaucratic delays (see Hargraves, below).

•

Plus, of course, the time it takes to find and correct the error in code.

Bureaucratic Impediments Nonetheless, there can be bureaucratic impediments involved with changes during support. The following expresses this view from the perspective of a Support programmer:

Two things contribute to unhappy customers: bugs and late delivery. A bug is generally referred to as a feature in the application that does not work according to the customer’s expectations. This can be due to an unspecified or misunderstood requirement or just a mistake in the development of the software. Either way, bugs not only frustrate the customer, they considerably expand the project’s cost and timeline. Making an effort to catch bugs at the earliest point in the life cycle will result in a higher return on investment (ROI). The cost of fixing a bug differs depending on the stage of development it is caught in [sic]. 130

Chapter 7

The Evolution Stage

Requirements Stage: Bugs caught in the requirements writing stage simply cost the time to rewrite the requirement. Time spent in this stage is usually constant. Coding Stage: Bugs caught here require developer hours. Time varies but is considerably less than fixing a bug found by someone else. When a bug is found during this stage, the developer discovers it, already understands the problem, and often knows how to fix it. Integration Stage: Bugs caught here require developer and other system engineer hours. Time is usually at least twice as much, since the problem occurs at a higher level and there is a need to figure out which exact code or configuration is wrong. Testing Stage: Bugs caught here require developer, system engineer, PM, and QA hours. The process is much larger than before. Now things need to be tracked and prioritized. This now requires finding reproduction steps, submitting a bug, prioritizing the bug, meeting with developers, fixing the bug, pushing the fix to the test environment, verifying the fix, and tracking the changes of the bug in the system. Evolution Stage: Bugs caught here require developer, support, system engineer, PM, customer, and QA [test] hours. This process always involves all of the roles. It requires more planning and more prioritizing than in the testing stage. Usually a phone call comes to support, and they decide if it’s a bug or if it’s working as designed. The customer is notified, the PM is contacted, and then the process in the testing stage is followed. 131

Chapter 7

The Evolution Stage

As you can see, finding a bug later in the life cycle of the software costs more. The greatest ROI is to find bugs early. Doing all that can be done to collaborate with the customer will greatly help reduce development against buggy requirements. We’ve all played the operator game, and requirements can easily be watered down or even misunderstood once the project gets to the tester and developer. Source: “The Cost of Bugs,” by Christian Hargraves © By Intellectual Reserve, Inc. (Church of Jesus Christ of Latter-Day Saints) (used here with written permission)

 n the Difficulty of Correcting an Error O During Support The often-cited “100 times as difficult” stems from Barry Boehm’s 1981 book Software Engineering Economics. However, while this ratio may appertain to large-scale systems, “… a 5:1 ratio [was] more characteristic of small, noncritical software systems.” Source: Barry Boehm, Vistor R. Basili, “Software Defect Reduction Top 10 List,” Software Management, January 2001 Regarding types of support, Lientz and Swanson’s survey findings (1980) are still in use today: Corrective maintenance, i.e., emergency program fixes and routine debugging, accounted for slightly more than 20% of the total, on the average. Adaptive Maintenance, i.e., the accommodation of changes to data inputs, files, and to hardware and system software, accounted for slightly less than 25%.

132

Chapter 7

The Evolution Stage

Perfective maintenance, i.e., enhancements for users, improvement of program documentation, and recoding for efficiency in computation, accounted for over 50%. In particular, enhancement for users accounted for 45.3% of the total maintenance effort, on the average.

Figure 7-3.  Types of software support activities Source: Approximated from Lientz and Swanson, op.cit. p. 68 AddisonWesley, 1980 Another view is provided by Kitchenham et al.:

… since identifying a modification as an adaptive or a perfective Support activity depends on the reason for the change, and not on an objective characteristic of the change, we have used the following definition for types of Support changes: Corrections that correct a defect—i.e., a discrepancy between the required behavior of a product/application and the observed behavior. Enhancements that implement a change to the system that changes the behaviour or implementation of the system. We subdivide enhancements into three types:

133

Chapter 7

The Evolution Stage

• enhancements that change existing requirements, • enhancements that add new system requirements, and • e nhancements that change the implementation but not the requirements. Source: Kitchenham et al. Towards an Ontology of Software Maintenance, Wiley 1999 Kitchenham et al. do not provide percentages for their division of the Support effort, but I found a graphic which essentially summarizes their findings.

Figure 7-4.  Software support activities Source: Modified from James Martin and Carma Mclure op.cit. Yet another view of support activities:

134

Chapter 7

The Evolution Stage

Figure 7-5.  Support effort summary Source: Penny Grubb and Armstrong Software Maintenance Concepts and Practice, World Scientific Publishing Co., Singapore 2003. Data from Lientz and Swanson 1978

Limited Understanding Limited understanding refers to how quickly a software engineer can understand where to make a change or correction in software that he or she did not develop. Research indicates that about half of the total programmer’s time is devoted to understanding the software to be modified.

Figure 7-6.  Support programmer’s time 135

Chapter 7

The Evolution Stage

Source: SWEBOK Vol 3.0 Several technical problems contribute to the costs of software support. Among the challenging problems of software support are impact analysis and regression testing.

T he technical challenges can in large measure be addressed by

136

•

Source code with appropriate comments is the most important factor for understanding a system to be maintained although external documentation can be helpful.

•

Clean code (inspections, audits, compliance with standards).

•

Inspection of requirements – confirmation with end user.

•

Up-to-date system-wide, high-level process diagram (e.g., for an MIS a data flow diagram).

•

An Entity Relationship Diagram of the database (IDEF1X or IE).

•

A current data dictionary.

•

Identifiers on screens for faster identification of a reported problem.

•

A current compendium of business rules.

•

A current traceability matrix to identify the location in code of requirements and business rules that may need to be updated or may be compromised by additional development effort.

Chapter 7

The Evolution Stage

•

Comprehensive configuration management.

•

Test cases from early testing at the unit-level tests (including Test-Driven Development – TDD), module assembly tests, and system test to facilitate regression testing.

•

And a well-documented system architecture.

These factors demonstrate that Support begins with inception. Generally, operations also maintains the email server and telephony equipments. It includes maintaining the list of authorized personnel (active directory), passwords, permissions for remote access, firewalls, and other appropriate security measures. During DevOps (or DevSecOps), operations work with developers to maintain a stable and consistent operating environment across platforms. It helps establish procedures and automated support for “build” Support and automated release procedures that hopefully will carry over into the production environment.

Forces for Evolution [Software evolution] is the concept that software is modified to keep it relevant to its users. Source: Erich Karsh, Microsoft Developer “Lehman’s Law of Software Evolution and the Staged-Model.” 2011/04/01 (Google) This includes changes in size, complexity, and functionality during software evolution affected by: •

New regulations

•

Legislative action

•

Change in workflow procedures 137

Chapter 7

The Evolution Stage

•

Competitive pressures

•

Features uncompleted by development team

•

Uncovered errors

•

Users’ requests for new features

•

Changes in business practice

•

Revised or new requirements

Lehman’s Laws M.M. Lehman produced a set of “laws” regarding forces for software evolution. The first three laws were promulgated in 1974, Laws 4 and 5 in 1977, Law 6 in 1991, and Laws 7 and 8 in 1996.

138

Chapter 7

The Evolution Stage

Table 7-1.  Lehman’s laws of software evolution No. Name

Statement

1

Continuing Change

A software system must be continually adapted, else it becomes progressively less satisfactory in use The term evolution in the context of software may be interpreted in two distinct ways. The most widespread view is that the important evolution issues in software engineering are those that concern the means whereby it may be directed, implemented, and controlled An alternative approach may also be taken. This less common, but equally, important view seeks an understanding of the nature of the evolution phenomenon, what drives it, its impact, and so on

2

Increasing Complexity

As a program is evolved its complexity increases unless work is done to maintain or reduce it In the software context, the term Support is incompatible with common usage. What happens with software is that it is changed or adapted to maintain it satisfactorily in changed domains and under new circumstances as judged by stakeholders such as users. Software is evolved to maintain embedded assumptions and its compatibility valid with respect to the world as it is now. Only in this sense is the use of the term Support appropriate in the software context

(continued)

139

Chapter 7

The Evolution Stage

Table 7-1.  (continued) No. Name

Statement

3

SelfRegulation

Global system evolution is feedback regulated. The program evolution process is self regulating with close to normal distribution of measures of product and process attributes The areas supported by software also evolve. The process of software evolution is self-regulating, with regard to the product and process artifacts that are produced.

4

Conservation of Organizational Stability

The work rate of an organization evolving a software system tends to be constant over the operational lifetime of that system or phases of that lifetime The process of software evolution also evolves. The term refers to the aggregate of all activities involved in implementing evolution in any of the above levels. It is variously estimated that between 60 and 95% of lifetime expenditure on a software system is incurred after first release

5

Conservation of Familiarity

In general, the incremental growth (growth rate trend) of systems is constrained by the need to maintain familiarity Achieving full understanding and mastery of it remains a distant goal. Modeling, using a variety of approaches, is an essential tool for study, control, and improvement of the process. Models facilitate reasoning about it, exploration of alternatives, and assessment of the impact of change, for example. As the process and understanding of it evolve, so must its model

(continued)

140

Chapter 7

The Evolution Stage

Table 7-1.  (continued) No. Name

Statement

6

Continuing Growth

Functional content of a software system must be continually increased to maintain user satisfaction over its lifetime System software must be continually adapted and changed if it is to remain satisfactory in use

7

Declining Quality

Software systems will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment A software system will be perceived as declining in quality over time, unless its design is carefully maintained and adapted to new operational constraints

8

Feedback System

System Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved The software evolution process is a complex multiloop feedback system in which the inputs are influenced by the outputs by many different routes or “loops” The feedback can come from many sources including users (who may press for new features), the application domain (if changes in tax law require changes in the way a POS system calculates taxes), the technical environment in which the system runs (if changes to the operating system require changes to how some of the functionality is implemented), and the system itself (when defects are identified and need to be fixed). Developers must be keenly aware that if their software system does not respond positively to these pressures, then over time the system will be seen as increasingly less appealing by its user base 141

Chapter 7

The Evolution Stage

Sources: Compiled and arranged from Meir Lehman and Juan C. Fernandez Software Evolution and Feedback: Theory and Practice Chapter 1 Software Evolution John Wiley & Sons, Ltd, 2006 and Meir M Lehman “Programs, Life Cycles, and Laws of Software Evolution.” Proceedings of the IEEE Vol 68 no 7, September 1980

DPAC Embraces Lehman’s Laws Completely In DPAC the last stage of development is labeled Evolution, and Support is represented by a cycle within that Stage. Each systemic change is routed back to the earlier stages representing further development, representing work accomplished to maintain the system. As user feedback is accumulated in the Support Cycle, regression is required to upgrade units of code of which the system is comprised. This evolutionary path (represented by nested ovals in DPAC) accommodates various releases of the software system. “Modeling... is an essential tool for study, control and improvement of the process” (Law 5 – Conservation of Familiarity). DPAC is a comprehensive model taking into account a path through its nested cycles to resolve evolutionary forces and maintain system quality. DPAC meets the criteria of Law 8 - “System Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved.” The Act Phase of each cycle determines which path is necessary to maintain the integrity of the system.

Model of the Software Support Life Cycle (SMLC) A model of the support life cycle has been put forward by K.H. Bennett, V.Y. Rajlich, and N. Wilde “Software Evolution and the Staged Model of the Software Lifecycle” (with case studies) Advances in Computers Vol 56 2002 and Bennett and Rajlich, “Software Maintenance and Evolution: A Roadmap,” Association for Computing Machinery (ACM) 2000. 142

Chapter 7

The Evolution Stage

This model represents Support as comprised of five stages: initial development, release to production, software evolution, servicing, phaseout and closedown. The original model represents development the way traditional development models do for Support, that is, showing initial development as a single, small block at the top - where development models show Support as a single block at the bottom. This representation of the model shows development as a large block at the start of the support process and release as the start of the Support Cycle. It is meant to imply that Support begins early in the Development Stages.

Figure 7-7.  The simple staged model Source: Derivative from Bennett and Rajlich 2000 op.cit. In practice, support work is performed on a copy of the production system where changes are carefully migrated to the working (or production) system in increments. Evolutionary changes, in the form of new reports, modified or new modules are generally migrated to the production environment during shutdowns for Support in the overnight or weekend hours. 143

Chapter 7

The Evolution Stage

Version Staged Model A copy of the production system may be maintained to test modifications in a true production environment before adding them to the “in use” production system. This would be called “switchover.”

Figure 7-8.  Version staged model of the Software Support Life Cycle (SSLC) To illustrate the versioned staged process for product development, Table 7-2 provides development and release information for three consecutive Windows products: Windows XP, Vista, and Windows 7. Application of these data to the model is represented in Figure 7-9.

144

Chapter 7

The Evolution Stage

Table 7-2.  Data for Figure 7-9 Windows XP

Windows Vista

Windows 7

1996 Start Development 1997 l 1998 l 1999 l 2000 l 2001 Release to Gen. Sales

Start Development

2002 Service Pack 1

l

2003

l

2004 Service Pack 2

i

Start Development

2005

l

l

2006 Service Pack 2b

Released to Manufacturing

l

2007

Released to Public

l

2008 Service Pack 3 (Patch)

Service Pack 1

l

2009

Service Pack 2

General Availability

2010 End of Mainstream Support 2011

Service Pack 1

2012 End Full Support 2013

End Retail Sales w/out SP1

(continued)

145

Chapter 7

The Evolution Stage

Table 7-2.  (continued) Windows XP

Windows Vista

Windows 7

2014 End Extended Support 2015

End Mainstream Support

2016

Security Update

2017

Ended Support

2018 2019 2020

End Extended Support

Source: Wikipedia for each operating system (Google)

Patches are released regularly by Microsoft to fix a specific problem. The key difference between a service pack and a patch, however, is that a service pack is MUCH more heavily regression tested than a patch. Source: Service Pack vs “Patch” contributed by the Technical Department at ITsynergy June 15, 2012

146

Chapter 7

The Evolution Stage

Figure 7-9.  Evolutionary release of Windows versions

The Importance of “Tribal Knowledge” Intimate knowledge of the developed system is accumulated by the development team over the course of the elaboration and construction stages. It is important that this intimate knowledge of the system and the function and interrelationships of its many parts is passed on to the Support staff. It has been suggested elsewhere that developers be retained into the support stage to preserve this knowledge. Rather than sentence developers to what they might perceive as a “fate worse than death,” it is far easier to fit Support personnel into the development stages to participate directly in the shared understanding. In particular, two representatives from Support (in case of the loss of one) should be assigned to these duties which should include: 1) Involvement with the development of requirements by participating in requirement reviews to grasp information regarding intent of the end users 147

Chapter 7

The Evolution Stage

2) Participation in inspections (even as an observer) – to grasp an intimate knowledge of the source code and its relationship with the architecture, and to comment on features that would make Support easier 3) Involvement with automation tools for build operations, release automation, and other DevOps measures which will carry over into the production arena 4) Familiarization with test plans and (if automation is used) tool test scripts to assist with regression testing 5) Familiarization with the system architecture 6) Establishment of rapport with developers which will carry over to identify the developer of a particular piece of code as it is incorporated into the emerging production version of the system Deployment may also be tasked to perform a V&V (verification and validation) function where verification examines a piece of code to be true to its specification, and validation to determine whether or not that requirement is indeed what the user intended. This is in lieu of an IV&V (independent V&V) to provide those services as an independent contractor. While the terms V&V and IV&V are commonly used to verify and validate data conversion, the concept is also applicable to other system components.

S  ummation The DPAC model demonstrates extraordinary strength in mapping system development, deployment, and support activities. I maintain that DPAC is the only geometric solution to offer this flexibility. 148

CHAPTER 8

Risk Management It’s a sloppy world. —Anonymous Professor of Political Science Most of the things that go wrong with information system development projects have absolutely nothing to do with computers.

General Mayhem There is hardly a technical obstacle that cannot be overcome or worked around. But it will take a lot of negotiating to get Department A to agree with Department B about how to properly categorize a widget – and Lisa and Fred simply refuse to arrange time to meet with the requirements analyst, not to mention Gene, the head of the Accounting Department, who is setting up accounts for next year’s budget and won’t be available until July. Further, there is no organization chart because things shift around so often, no one bothered to make one – and Betty in research really doesn’t need a computer, she needs a new microfilm reader because her MS tremors make her hand shake, and it takes her five times as long as it should to locate the right frame using the old microfilm reader with the broken crank handle. Then, it turns out that the person put in charge of the development effort is a distant cousin of the owner of the company – neither has ever developed anything before - and he is also an ex roommate of the Government’s Contracting Officer’s Technical © Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_8

149

Chapter 8

Risk Management

Representative (COTR) who by the way is having an affair with the “blonde with the red heels” head of the Requirements Team. So – at the last minute – the developers snatch all the notebook binders from the QA manager and lock the doors for 2 days to slam “code and go.” But they surface for air after 6 days of nonstop banging keyboards and proclaim a miracle has occurred; only it turns out that nothing – I mean absolutely nothing – works, and the Contracting Officer pulls the plug and calls in a new contractor after 5 years of work down the drain, and the whole mess starts over. Sounds silly? That is a composite, a small sample of things I have actually seen happen.

L oss of Key Personnel: Missing a Window of Opportunity My first system at the University of Florida (1976) was a raving success. My next system, an order of magnitude more complicated than the first effort, was a dismal failure. I was so low… The reason for this failure was the loss of one key person due to leaving the University system for a very lucrative private sector position and the loss of a second key person due to the occurrence of terminal cancer affecting that person’s spouse. I dropped my entire consensus building activities, picked up the slack on the programming effort, and finished the software development effort successfully. However, the “window of opportunity” was gone. The system was never deployed. I could keep the interest in the project alive, or I could finish the software development effort. I could not do both.

150

Chapter 8

Risk Management

 oftware Development Always Has S a Political Dimension My first big lesson: Winning the software battle is only half the issue. What matters is maintaining support of the political environment. The corollary to that discovery is also very important – technical management and project management are two separate and distinct activities. In most cases, those responsibilities should not be invested in the same person. There must be someone to serve as a Project Facilitator (someone with strong “people skills”) and a Technical Project Manager (or lead tech) to focus on the development effort itself. The job of the “Project Manager” is to support the “Technical Project Manager,” not the other way around. Politically motivated mandated timelines never work. Yet another reason the failure rate is so high. The Project Manager is a member of the development team. His job is to represent the needs of the development effort to the representative of the organization. In federal government projects, the representative for the organization may be the Contracting Officer’s Technical Representative (COTR).

 nrealistic Expectations. Lack U of a Competent Project “Champion” There are two factors most consistent for the success or failure of a project. First, projects succeed most often where there is a recognized project sponsor (product owner) – one person who holds the Vision for the project and maintains the interface between the development effort and the host organization. That person’s principal interface to the developers is

151

Chapter 8

Risk Management

through the Technical Project Manager. Second, a major reason for failure is the lack of stakeholder buy-in, and its principal root cause – the lack of user input. Addressing the issue of user involvement is the main reason to establish the Vision Statement for the project through consensus – to include the stakeholders from the outset of the effort. If the organization is unable by itself to form a Vision Statement, the developers should pony up a “straw man” version that can be circulated to management and stakeholders for comment. The circulation should go as high up the management chain as possible. Executive support and user involvement are essential to project success.

Missing Man The lesson of my second project experience is: Key people can disappear at any moment in time. Prepare accordingly. This proved to be a most valuable lesson later in my career – when I was hired to be a Technical Project Manager on a very high profile system. The first thing I did was to update all documentation of procedures, and monitor logging of all database loading activity. Sure enough, 6 weeks into the proceedings, the person doing the loading, who was pregnant, called to inform me that the placenta fell – and she would be at home for the duration. We had the situation well enough documented that I was able to pull an individual off the floor – who had only one course in COBOL as background, but wanted to learn, wanted to advance, and had demonstrated great reliability – trained him to do the loading operation, and resumed operations with less than a 6-hour delay. In fact, loss of a key person (or persons) has occurred three times in six development efforts which I have led or have been a participant. That is a 50% chance of it happening again. 152

Chapter 8

Risk Management

One way to take out “insurance” against loss of personnel is to institute a Standard for Program Specifications and a system of Software Development Notebooks (see Table 8-2). One purpose is to create “as-yougo” documentation to facilitate the process of assimilation for a successor. Another purpose for the SDNs is to facilitate system documentation by rounding up all the software notebooks as the documentation package.

Table 8-1.  Program specification Standard for Program Specifications

•  Diagram of tables accessed •  Pseudo-code and/or diagram •  Business rules that may apply •  Modification history •  Programmer ID, dates •  ID each “canvass” (screen and subscreens) and reports

Keep Documentation Up-to-Date An apocryphal story regarding the early days of Ross Perot’s company, Electronic Data Systems (EDS) - founded in 1962 – is that employees had two requirements: (1) their shoes had to be shined (if not they were sent home), and (2) each Software Development Notebook (SDN) had to be kept up-to-date by close of business every day, or the programmer would be let go (i.e., fired). A less draconian measure is to limit the extent of ongoing documentation to programmer’s notes at the end of each working day. These notes can be kept and maintained in an unused procedure space in a screen generator tool, or as a separate text file in a designated location.

153

Chapter 8

Risk Management

Table 8-2.  Software development notebooks Guidelines for Software Development Notebooks (SDNs)

Programmer ID, dates Requirement number(s) Program Specs Completed code Dates Logging of all changes

Guideline for SDN Review

Checklist

A program specification for object-oriented languages is difficult enough, but external documentation for proprietary screen generators is extremely difficult if not impossible. While these tools (e.g., Oracle Developer) have the advantage of inbuilt binding to the target database, they leave documentation in the tool itself. The unguided maintenance programmer has to look through each “snippet” of code buried in the tool to ascertain where any given problem or business rule might be hidden. A “Designer” tool, generally containing a visual representation of the database and a process diagram, leaves a little more guidance, but if the tool is discarded, so goes the documentation. This means that the tool must be available for the life of the system – which may be a very long time indeed. Further, if the ensuing programming is moved from a “Designer” tool to a “Developer” tool, the Designer tool is non–re-entrant. That is, the documentation is split between the two. This generally leads to the abandonment of the Designer tool altogether – and the supportive “documentation” is lost forever – or (most likely) must be reverse engineered by the maintenance team.

154

Chapter 8

Risk Management

Missing Tools: Loss of “Tribal Knowledge” In my personal experience working with a Management Information System (MIS), the original project was initiated using Oracle Designer, which creates screens and provides a view of the entire system. The screens were then imported into Oracle Developer for completion and maintenance. By the time we arrived, Oracle Designer was nowhere to be found, and the “documentation” consisted of a printed edition of a very good data dictionary, a database design diagram in Erwin, and code with in-stream comments which varied with the proficiency and experience of the individual programmer – from very good indeed to abysmal or none at all. As near as we could tell from the variety of presentation in code, there were six or more programmers in the initial effort. The original system was developed by contractors and cost the government $11M. The contractors had “left the building” 2 years ago, and there were no “in-house” personnel available to pass along “tribal knowledge” of the system.

Missing Overview My colleague and I were brought in as contractors to deal with a long list of bug fixes and new reports. With no system documentation, and no person we could turn to for information, we reverse engineered a picture of the system. With no supporting documentation, we looked at every slot where code might be located. Oracle Designer leaves slots with cryptic numbers in which code might be placed – as well as named slots which may or may not be actively involved with the operation of the system. That process took 6 weeks – before any error could be corrected. Among the “bugs” reported were a report that ran for 12 hours without producing tangible returns and an annual report that held erroneous data – which was caused by a failure to update the database – thus nullifying 2 years of data and its dependent calculations.

155

Chapter 8

Risk Management

In addition, there was one unfinished module, with no in-stream documentation, and for which business rules had to be reverse engineered. The process of restoring the module to limited functionality lasted 6 weeks. (It would have been easier to re-create the module but that was not within our mandate.) In short, we spent untold hours trying to comprehend what was going on and - in most cases - a short time for corrections.

Lack of Quality Engineering Measures There are three key principles of Software Quality Engineering: Accountability, Visibility, and Traceability. Software development is like building an invisible house that no one can see until completion. CM should be able to make progress toward objectives visible by tracking each item of code through the development process. Each item of code should be traceable from a provision of the Vision Statement through business rules that it may contain (including edits and referential integrity) to the test plan. The traceability matrix is the single most important piece of documentation to assist the maintenance programmer. As the system moves into production, it greatly reduces the time required to locate and make corrections to code for miscalculation of business rules or other discrepancies. A traceability matrix – identifying business rules and their location in the processing stream – is the most beneficial element of the business documentation package. The better the business model is defined, the less time specialists in the package will flounder spending time and money reverse engineering the location and substance of business rules – rules which the COTS package was intended to serve.

156

Chapter 8

Risk Management

The matrix allows traceability both forward and backward so a business rule can be traced forward to its implementation in code and a problem uncovered in a screen or report can be traced backward to a location in code. In short, maintaining the traceability matrix will shorten the time it takes to make corrections from test, greatly reduce the effort of correcting or changing business rules, and facilitate maintenance.

Lack of Proper Tools Of all the categories of available tools, none is more important than software version control. It is not uncommon in software development to create a mess of an item of code that requires starting over. With SW version control, one can recover the last functioning version of that specific item of code. Similarly, there will exist several versions of the database set up for early test of targeted coding (e.g., testing of edits and required fields) and dummies set up for module and system test. Database version management is accomplished by establishment of baselines, using different versions of the database for partitioning each progressive step through the development process. These partitions are managed by the Database Administrator (DBA) leading eventually to the production version. One important thing to recognize regarding tools, it is one thing to expect what a tool can do, but the trick is in learning (in trial by fire) what the tool doesn’t do. Allocate time and resources for the unexpected.

157

Chapter 8

Risk Management

Overoptimistic Level of Effort In my experience, the reason why programmers’ estimates for level of effort required to complete a task are so inaccurate - is because if they thought of the time and effort it would really take - it would seem so daunting that they would never begin. In the old days – where documentation was the last task to perform – it could be well said that 90% completed was halfway. The kindest explanation is that programmers are overly optimistic.

“Man Month” Is a Unit of Cost, Not Progress When there is slippage in the schedule, the initial response may be to add more people to the project (to increase the number of man months available to the effort). To oversimplify the situation, each person added to the project will require nonproductive training and time to get up to speed – assisted by interaction with persons already on the project - thus making the project later. As in “Brooks’ law”:

“Adding manpower to a late software project makes it later.”

 o Tool Alone Will “Fix” Gaps in the N Business Model I identify two principal categories of COTS software: (1) packages that solve a targeted problem (such as computing telecom taxes across more than 40,000+ possible jurisdictions) and (2) packages that serve an entire sector of business operations such as accounting or human resources, perhaps the best-known vendors of which are Oracle and SAP. In either case, a gap analysis should be carried out prior to purchase to determine how close the package may be to business requirements. 158

Chapter 8

Risk Management

The prerequisite, of course, is that business requirements are well defined. Each interface between the COTS package and the business should be carefully reviewed by subject matter experts (SMEs) which means that the time and effort prior to purchase should be included in the overall cost. In short, the ease of merging a COTS package into the business model is in large part determined by how well the business model is defined.

Learning What a Tool Does Not Do It is very likely that the largest element of cost is learning what a tool will NOT do. Hire someone with previous experience in that particular toolset. The large packages provide for customization, but the degree of “fit” can vary widely. Further, the costs of personnel (consultants), with the requisite skills to customize the package, are extremely expensive. Nonetheless, the price of an experienced hire is probably less that the downtime lost to overcoming a tool’s deficiencies. A traceability matrix – identifying business rules and their location in the processing stream – is the most beneficial element of the business documentation package. The better the business model is defined, the less time specialists in the package will flounder spending time and money reverse engineering the location and substance of business rules – rules which the COTS package was intended to serve.

Lack of Appropriate Skills I have never met a person involved with maintenance programming that does not believe that he or she can perform software development – and I have never met a developer who thinks that is a good idea.

159

Chapter 8

Risk Management

To turn to a house building analogy, the production team is very skilled in maintenance or additions to an existing structure – such as reroofing or adding a sundeck to a house. But these are not the same skills required to build a structure from scratch. In fact, developing software from scratch requires a number of skill set specialists. Testers, for example, are a breed apart from programmers, and programmers may find themselves at odds with Configuration Management and Quality Assurance requirements (except for software version control). The maintenance team can contribute significantly to the extraction of business rules from the user community. This is a part of the undocumented “tribal knowledge” shared by each maintenance worker. Proper involvement of production personnel can greatly expedite the development effort. It will also increase familiarity of the “system to be” on the part of production personnel that will greatly assist in the process of maintenance.

“ Round Up the Usual Suspects!” (Claude Rains, Casablanca, 1942) In summary, here are 14 risk factors I have encountered: 1. Personnel inexperienced in development (as opposed to maintenance). 2. Lack of consensus as to what is to be built (no Vision Statement) 3. Scope and/or specifications out of touch with reality (such as automating a process at headquarters without consideration for the needs of the field offices).

160

Chapter 8

Risk Management

4. Unrealistic schedules and budgets. (Timeline is declared by marketing without consulting the development team.) 5. Hiring personnel without adequate background checks (references, police records – Waiting for government clearances simply takes too long.) 6. Inexperienced project management. (Try to put someone who has been there before on the management team.) 7. Not seeking top talent because of budget constraints (nit picking) 80/20 rule (20% of the workers do 80% of the work.) Hire from the 20%. Paying more is more than compensated by productivity. 8. Inadequate or missing time allocated for learning curves. 9. No time allocated for preparation (getting personnel on board, getting all personnel acquainted with the situation). 10. Lack of controls and defined responsibilities. 11. Lack of preparation for turnover. 12. Failure to maintain the traceability matrix. 13. Preparation for missing persons. 14. Working from a dysfunctional model of the development process. Given the history of the “waterfall” and its transmogrification into the “SDLC,” it seems to me that the surprise is not how many development efforts have failed but rather how many have succeeded in spite of a dysfunctional view of the development process! 161

Chapter 8

Risk Management

 oehm’s Risk Management-Driven B Spiral Model Boehm’s model (Figure 8-1) depicts the use of risk-driven, multiple prototypes prior to implementation using a waterfall model (presumably after requirements have been uncovered and stabilized).

Figure 8-1.  Boehm’s spiral model of the software development process Source: Barry Boehm Tutorial: Software Risk Management. Washington DC. IEEE Computer Society Press, 1988 page 41 The main thing here is to show Boehm’s list of risks (Table 8-3).

162

Chapter 8

Risk Management

Table 8-3.  Boehm’s top ten list of software risk items Risk Item

Risk Management Techniques

1. Personnel shortfalls

< Staffing with top talent; job matching. Team building; key personnel agreements; cross-training; prescheduling key people

2. Unrealistic schedules and budget

< Detailed multisource cost and schedule estimation; design to cost; incremental development; software reuse; requirements scrubbing

3. Developing the wrong software functions

< Organization analysis; mission analysis; ops-concept formulation; user surveys; prototyping; early users’ manuals

4. Developing the wrong user interface

< Prototyping; scenarios; task analysis; user characterization (functionality, style, workload)

5. Gold plating

< Requirements scrubbing; prototyping; cost-benefit analysis; design to cost

6. Continuous stream of requirements changes

< High change threshold; information hiding; incremental development (defer changes to later increments)

7. Shortfalls in externally furnished components

< Benchmarking; inspections; reference checking; compatibility analysis

8. Shortfalls in externally performed tasks

< Reference checking; preawards audits; award-fee contacts; competitive design or prototyping; team building

9. Real-time performance < Simulation; benchmarking; modeling; prototyping; shortfalls instrumentation; tuning 10. Straining computer science capabilities

< Technical analysis; cost-benefit analysis; prototyping; reference checking

Source: Ibid. page 99

163

Chapter 8

Risk Management

Necessary Elements Responsibility for the success or failure of the project lies as far up the chain of command as it could possibly go. This means that reports on the status of the project must be frequent, short, and accurate – and directed up to the top of the ladder. What is required are four Cs: •

Communication

•

Consensus

•

Commitment

•

Cooperation

Communication between the user community and the development team should be in the form of direct involvement with the development process. Direct communication regarding the status of the project and progress toward objectives should be between the Project Manager (on the development side) and the Champion (or other designated representative) on the organization side of the equation. The representative of the organization has the responsibility to circulate progress reports up the chain of command. These processes should be in place to produce consensus as to what should be built – rapidly introducing results to the end users for review and creating direct involvement between the stakeholders and the development team. None of this is possible without commitment from the highest possible level of organization management – providing financial and motivational support - eliciting cooperation from the user community.

164

Chapter 8

Risk Management

S  ummation In my opinion, scrum succeeds in large part because it keeps a tight grip on its methodology, which is a radical departure from SDLC models. “Agile” is left floundering in a mess of different views of the development process such that it has all but lost its meaning in implementation efforts. DPAC is designed to address most of these methodologies with a cohesive generalized visual structure adaptable to many different interpretations. The application described herein represents one such interpretation of the model.

165

CHAPTER 9

Engineering Software Quality Software Quality Defined In the 1970s, when I first began designing and developing systems, the tribal knowledge at that time was that an information system should meet the following four criteria:

1. Meets the needs of the user



2. Be robust



3. Be easy to use



4. Be easy to maintain

Of course, those were the bad old days of punched cards, card sorters, mainframe computers, and IBM’s CICS (Customer Information Control System) as the most used (and still used) customer-facing application server. But the more things change, the more they stay the same.

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_9

167

Chapter 9

Engineering Software Quality

Meets the Needs of the User This criterion asserts that there exists some configuration of rules, data, and processes that optimize the intent of the user and that this optimum system can be uncovered and actualized by the development effort. Beginning with the Vision Statement, the development effort is an iterative process of uncovering and fulfilling “requirements” to meet that objective.

Robust Robust typically means it survives the unexpected well. In computing terms, robust is the resilience of the system under stress or when confronted with invalid input. It should be impossible for any action or set of actions on the part of a user or set of users to bring down or lock up the system: •

A system that does not break down easily or is not wholly affected by a single application failure

•

A system that is not wholly affected by a bug in one aspect of it

This is especially true with regard to subtle errors that only make their presence known in unusual circumstances. In this application, robust includes protection of privacy and against cyberattack.

Robustness is accomplished by thorough testing at all stages

Easy to Use (User-Friendly) The user interface should be intuitive with required fields clearly defined. Other factors may include:

168

•

Accessibility issues

•

Three-click rule – every available user option should be accessible with no more than three mouse clicks.

Chapter 9

Engineering Software Quality

•

Confirmation that significant transactions are (or are not) successfully completed.

•

Application and system errors should be handled and clearly identified for technical support.

•

Double-check (are you sure?) on critical operations, such as deletions, where existing data may be lost.

•

In-context help.

Easy to Maintain Anyone who has opened up code written by others knows the variety of presentations possible and probable. Ten things maintenance programmers want to see are: •

Standardized naming conventions and uniform standards for clean code

•

Standardized presentation of relevant and concise instream comments

•

Standardized presentation of screen numbers (e.g., in a small font in the lower right-hand corner) to put the maintenance programmer in sync with the befuddled user

•

A data dictionary

•

A Database Design Document

•

A glossary

169

Chapter 9

Engineering Software Quality

•

A traceability matrix to find where in code a change of business logic might be rendered or to find the original business rule embodied in a segment of code

•

A Software Configuration Inventory to determine where in the system specific code can be found

•

A process diagram to provide an overview of the system

•

Documentation for the architectural constraints of the system

•

Cogent in-stream comments

These points should be enforced by standards, guidelines, procedures, and Software Quality Assurance audits to ensure that these objectives are met. A Quality Engineering Plan for the DPAC Model

Figure 9-1.  Components of quality engineering

170

•

Software Quality Assurance (SQA) – Standards, guidelines, procedures, SQA Inspections, and audits. Progress reports on the status of the development process.

•

Configuration Management (CM) - Traceability matrix, code and database baselining, work products, version control, and release management

Chapter 9

•

Engineering Software Quality

Test – testing to requirements, Test-Driven Development, module assembly, system integration, and acceptance testing

Software Quality Assurance (SQA) Software Quality Assurance is part of a system for monitoring the process of software development over the entire software life cycle. ISO 9000 (2000) defines Software Quality Assurance [SQA] as “part of quality management focused on providing confidence that quality requirements will be fulfilled.” “Both customers and managers have a need for quality assurance because they are not in a position to oversee operations for themselves” [David Hoyle, ISO 9000 Quality System Handbook, 4th ed. 2001 (Google) ] ISO 15504:2000 Software Process Improvement and Capability Determination (superseded by ISO 33001) defines “The purpose of the Quality Assurance [SQA] process is to provide independent assurance that work products and processes comply with predefined provisions and plans.” CMMI for Development, Version 1.3 (November 2010) states: “The purpose of [Software Quality Assurance] is to provide staff and management with objective insight into processes and associated work products.”

171

Chapter 9

Engineering Software Quality

“Standards? We don’t need no stinking standards!” One might think no standards are necessary, but the person who must maintain your software 2 years after you have “left the building” will appreciate the uniformity of work product and supporting documentation you left behind.

Ease of maintenance is a primary goal of conformity to quality engineering requirements. The first standard implemented provides for identification and uniformity of work products generated during the development effort.

Table 9-1.  Universal documentation standard Standard for Documentation – Examples

•  Doc title • Date • Contributor •  Date of last update (DLUPD) •  Most recent contributor • Type face and font size • Pagination

Ongoing Documentation Four “living” documents are initiated in the Inception Stage: Glossary List of acronyms and abbreviations Organization chart – identifying key shareholders Data dictionary

172

Chapter 9

Engineering Software Quality

Each of these documents is subject to incremental change. The glossary and list of acronyms and abbreviations will grow over the course of the development effort. Even the organization chart, in particular the list of key shareholders, is subject to change over time. It is essential to maintain version control over the content and distribution of these documents as they mature over the life cycle of the system. In this interpretation of an Agile DPAC model, the “librarian” function may be performed by the Configuration Manager or his or her designee. Each of these documents may be updated with changes at any stage of the development process. It may be prudent to make these items available as new material is added by members of the development team. In particular, there is a need for circulation of updates to the data dictionary which is closely monitored by the Database Administrator (DBA) and maintained for form and format by the designated librarian. A document to familiarize staff and shareholders on how to read a data flow diagram (DFD) should be ready in the Inception Stage for use in the Elaboration Stage (see Chapter 5).

The general idea is to have materials prepared BEFORE they are needed. Table 9-2.  Guideline for DFDs Guide for Interpreting Data Flow Diagrams (DFDs) – Preprepared Materials

•  Symbol set • Rules • Example: This material provides by example enough information to comprehend a DFD system model

Work in the Inception Stage constitutes the completion of a Vision Statement proclaiming the objectives for the project. These stated objectives are assessed for weight in terms of security and priority for implementation. 173

Chapter 9

Engineering Software Quality

Data Flow Diagram (DFD) During the Process Overview Cycle of the Elaboration Stage, top levels of a data flow diagram (DFD) visualizing the parts and scope of the organization’s business are initiated. It is accomplished at this stage through interviews with the project’s champion and/or the heads of each department affected by the proposed system. User stories and requirements are captured by interviews with subject matter experts (SMEs) in the Process Detail Cycle of the Construction Stage. Each element of the high-level design must be “connected” to an objective of the Vision Statement. The Context Diagram (Level 0) and Level 1 DFD are initiated and completed by the Lead Business Analyst who renders the preliminary high-level DFD in a tool of choice. The completed products are circulated for comments and approval of the interviewees. Comments are woven back to the original DFD which is cycled until full approval has been achieved. Beneath the lowest level of each decomposed process represented in the DFD is the opportunity to express program logic and business rules. The purpose of standards during the Process Detail Cycle of the Construction Stage is not to enumerate all the possible forms for the expression of business rules but to set some criteria for analysis and test. During the Process Detail Cycle, statements of requirements and business rule logic may be expressed in a variety of forms. A compendium of these documents is held by the project librarian. SQA shall check the integrity of pointers to these documents from the requirements and/or business rule databases. Integrity shall also be maintained to the SWCI database, pointing to each specific item of software implementing each specific requirement and business rule.

174

Chapter 9

Engineering Software Quality

Table 9-3.  Standards, guidelines, and procedures for reviewing requirements and business rules Guidelines for Representing Requirements and Business Rules

• Pre-prepared Materials

Standard for Requirement Statements and Business Rules

• Numbering conventions • Form of requirements statements (atomic) • Include codes and valid parameters • Appropriate descriptors and/or diagrams • Report and/or screen examples

Procedure for Reviewing Form and Substance of Requirements and Business Rules – During the ACT Step of Each Quality Control Cycle

• Requirement statements must match narrative (user stories) •  Checklist

Procedure for Maintaining a Compendium of Requirements Documents (Subject to SQA Audits)

• Requirements database ( or spreadsheet) • Pointer to actual Requirements Document • Business rule library maintained by librarian

Configuration Management (CM) CM is the lynchpin of the Software Quality Management System.

CM ensures the effective management of the evolving configuration of a system, including all of its work products, during its life cycle. 175

Chapter 9

Engineering Software Quality

Source: International Council on Systems Engineering (INCOSE), Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities Version 3.1 – 2007 site 5.11

The Configuration Management process area supports all process areas by establishing and maintaining the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. Source: CMMI for Development, Version 1.3 (November 2010)

Software configuration management (SCM) [is] the discipline of identifying the configuration of a system at distinct points in time for the purposes of systematically controlling changes to the configuration, as well as maintaining the integrity and traceability of the configuration throughout the software life cycle. Source: P. Bourque and R.E. Fairley, eds., Guide to the Software Engineering Body of Knowledge [SWEBOK], Version 3.0, IEEE Computer Society, 2014 CM comprises five categories of activity:

176



1. Configuration identification



2. Configuration control (including code version control)



3. Configuration status accounting



4. Configuration audits



5. Identification of configuration items: •

Develop a strategy for numbering configuration items – by item type.

•

Identify baselines.

•

Identify procedures to advance items across baselines.

Chapter 9

•

Engineering Software Quality

Track structural relationships between items – e.g., build items.

The Software Configuration Inventory (SWCI) is updated during each ACT step for each iteration in the DPAC model. These data are also used to update and maintain the traceability matrix.

Table 9-4.  Configuration item naming conventions Standard for Configuration Item Naming Conventions

•  Description and examples

Table 9-5.  Configuration inventory database The Software Configuration Inventory (SWCI) and Traceability Matrix Shall Be Maintained by the Configuration Manager in a Configuration Management Database (CMDB)

See Figure 4-1

CMDB A Configuration Inventory Database (CMDB) is a repository that acts as a data warehouse for information technology (IT) installations. It holds data relating to a collection of IT assets (commonly referred to as configuration items (CI)), as well as the relationships between such assets. The CMDB includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMDB is maintained by configuration management and is used by all IT Service Management Processes. The major objective of the CMDB is to provide the means to create the traceability matrix.

177

Chapter 9

Engineering Software Quality

 hange Reports (CRpts) and Discrepancy C Reports (DRs) In this interpretation, both the CRpts and the DRs themselves are written in hard copy, being easier to track – with the distribution and disposition held in the online file.

Table 9-6.  Elements of a traceability matrix • Vision objective number • Subject matter experts (SMEs) • DFD architect(s) • Process number (from DFD) • Business Analyst(s) • Program Identifier(s): SWCI Identifier Program Label • Coder(s) • Business rule(s), edits, referential integrity • Screen, report, or web page • Business rule analyst(s) • Development team tester(s)

The Hardware Configuration Inventory (HWCI) The HWCI is put forth by the Configuration Management component of the development team, but the hardware itself is properly installed and maintained by the organization’s network administrator. The network administrator maintains a list of all hardware attached to the network including make and model, cost and serial number (for insurance purposes), and physical location of the item. 178

Chapter 9

Engineering Software Quality

The team maintains the HWCI (Hardware Configuration Inventory) to track the installation, operational status, and performance requirements of hardware components. Other nonfunctional requirements are tracked by the librarian (a CM designee) on behalf of the development team. Involvement of the test team includes hardware-related requirements such as performance and physical requirements. Nonfunctional requirements are further detailed in the Inception Stage description (Section 4) to follow.

Table 9-7.  Handling nonfunctional requirements Procedure to Maintain List of Hardware Requirements (HWCI)

• Description and examples – keep log of HW arrivals and installation   (maintained by librarian)

Procedure to Maintain Database of Other Nonfunctional Requirements

•  Description and examples

Change Control Configuration management is about managing change of the multiple items composing an information system Change Reports (CRpts) reflect changes to requirements uncovered during the development process. Each CRpt is submitted to Technical Review which may forward the matter to the Change Advisory Board (CAB) or act on it without review by the CAB, depending on a judgment call as to whether or not the CRpt requires a change in scope of the project. The purpose of the CRpt system is to remain true to the purpose of the software project defined by the Goals and Objectives of the Vision Statement and to modify the Vision Statement and process model (DFD) as necessary for that purpose.

179

Chapter 9

Engineering Software Quality

Table 9-8.  Procedure for processing Change Reports Procedure for Processing Change Reports (CRpts) (SQA monitors time to resolution, items outstanding)

• Log and forward to tech for distribution

A Technical Designee oversees the process of Software Version Control. Since this process depends on the tool used and the programming language, the procedure for using the tool should be appropriate to the need.

Table 9-9.  Code version control (tech) Procedure for Code Version Control

•  Create fallback positions and baselines of working code • Provide release management control • Provide instructions that are specific to the tools and languages employed

Status Accounting The Project Manager or the designated SQA Officer should be able to track the progress of each software configuration item (SWCI) throughout the process of development particularly with reference to baselines. This information is equally useful to the development team, in particular the Lead Tech, to know the state of each “build” – and which code “segments” have been promoted to the next baseline. (In other words - which modules have been completed and what code is required to complete any given module baseline) This information can be used to set priorities in the development sector.

180

Chapter 9

Engineering Software Quality

Table 9-10.  Status accounting Procedure for Updating Status Accounting in the SWCI Database in the ACT Step of the Quality Control Cycle

Generate reports for Tech and SQA to track the status of software configuration items (SWCIs) ready for builds and to track progress toward objectives

Audits Audits, inspections, and refactoring provide snapshots into the state of the development process at a particular moment in time: Audits are performed before the acceptance of a configuration baseline to assure the product complies with its specified requirements and to assure the product is accurately defined by its configuration documents. ISO 10007

Table 9-11.  SQA Audit of baselined requirements Procedure for Baselining Configuration Baseline audit reports generated from Items the Configuration Management Database (CMDB) CM Produces Reports for SQA Audit of Integrity of Traceability Matrix During ACT Step

One point of the audit is to assure that the traceability matrix is intact

181

Chapter 9

Engineering Software Quality

Table 9-12.  System-wide procedures Procedure for Adding to Store of Global Variables

•  (prefix, ulc) •  Means of notification

Procedure for Error Handling

•  System errors • Application errors • Error log/audit trail

Procedure for Connecting to System Architecture

• Logon/sign-off • Organizational identity •  Security clearance • Audit trail •  Screen navigation

Table 9-13.  Build functioning model demonstrating system architecture Build Functioning Demonstration of Core System Functions

• Logon/sign-off • Organizational identity •  Security clearance • Audit trail •  Screen navigation   (with documentation)

Technical review takes place by peer review (as appropriate) in the “Act” Phase of the DPAC model. Guidelines (in the form of checklists) are published for the benefit of programmers to prepare for the review and for the reviewer.

182

Chapter 9

Engineering Software Quality

Table 9-14.  Guidelines for technical review Guidelines for Code Inspections/Refactoring in the Act Phase of the Quality Management Cycle

• Checklists

Refactoring is the process of improving code after it has been written by changing the internal structure of the code without changing the external behavior.

Test “Test” is the third leg of the Quality Engineering paradigm. Test begins at Inception. During Inception, the Vision Statement is refined to a solid set of statements defining the project’s intent. The involvement of test this early in the development process serves to acclimate the test team to the goals of the project – in preparation for the stages that follow. As the project continues to evolve, the test team should be able to judge whether or not a given “requirement” is within the scope of the project according to the Vision Statement and provide input accordingly. Building familiarity continues through the Elaboration Stage and the process of creating data flow diagrams. Test moves into direct involvement with the development team during the Process Detail Cycle of the Construction Stage.

Test-Driven Development (TDD) TDD assures that code is tested and reviewed early in the Development Process. A trained test person, in conjunction with a business analyst, can assist the coder in this endeavor by developing test cases and data. Test should also participate in the inspections and technical review sessions as an observer. 183

Chapter 9

Engineering Software Quality

The general principal is to give the test team advanced and intimate awareness of the structure of the system prior to carrying out tests. Building awareness of the system’s intent and structure and participating in the development of test cases a priori will save time in the later stages where identification and correction of an error takes more time over correction in earlier stages by a considerable factor. The first proposition is that early involvement of test is less expensive than having personnel approach the System Integration Test blindly. •

There will be fewer errors at the module and system test levels, having been dealt with early on.

•

Test personnel will be familiar enough with the system to expedite identification and resolution of discrepancies.

•

Test cases will have been prepared at lower levels that can be applied to system-level tests.

Table 9-15.  Write test protocols Unit Test, Module Test, System Test, Acceptance Test

• Prepare test cases

Table 9-16.  Conduct SQA test readiness reviews •  •  •  • 

184

Test Readiness Reviews: Module Assembly System Integration Test Acceptance Test

• SQA provides assurance that all testable items are accounted for in the test plan

Chapter 9

Engineering Software Quality

Perform Test When a test result is other than what is expected, a Discrepancy Report (DR) is logged and sent back to the programmer who executed the code, identified by means of the traceability matrix, and referred through SWCI Database. The Discrepancy Report is a two-way document. After the offending unit of code is repaired, the form is sent back to test with the aforementioned result. A log of test results is maintained by the Lead Tester. The librarian (CM) keeps track of all DRs in circulation in a DR Database and stack of paper forms. (Paper forms capture a signature and provide for direct delivery.)

Table 9-17.  Procedure to process Discrepancy Reports Procedure to Process Discrepancy Reports (DRs)

•  Circulated from test to CM login

All these measures are monitored and/or audited by the Process Quality Assurance officer, who is responsible that each measure gets done.

Data-Related Quality Engineering Agile Database Development

Table 9-18.  Naming conventions Database Naming Standards

• Table (entity) names • Element (attribute) names • Reserved words

185

Chapter 9

Engineering Software Quality

Conversion Plan Converting legacy data to a new database is anything but straightforward. If nothing else, the naming conventions of the legacy data are likely not the same as in the new database. Other discrepancies may include: •

The number of columns in each is probably not the same.

•

The value range for lookup tables differs, for example, the coding for race or ethnicity (viz. Table 9-12).

•

Missing data, including value for primary key (yes, it happens! More often than you might think.)

•

“Text fields” in the Legacy Data may require parsing.

•

And a litany of other nonalignment problems…

Table 9-19.  Conversion plan – including value transformations Values for Race or Ethnicity Legacy Data 1. White 2. Black 3. Hispanic 9. Other SQA for Conversion Readiness Review

186

New Database 1. 2. 3. 4. 5.

White Hispanic Afro-American Oriental Other

Chapter 9

Engineering Software Quality

Measure Twice Cut Once Given the complexity of conversion, it is more than prudent to have a second set of eyes go over the Conversion Plan. This Process Quality Assurance task is generally delegated to test personnel, which serves the double purpose of having test become familiar with the structure.

Table 9-20.  Establish migration plan Migration Plan – move DB structure across baselined partitions during Construction Stage

• Data partitions, baselines

SQA assures that plan items are accounted for

• Review migration plan execution

Quality Engineering for Programming Programming receives the most attention from Quality Engineering. Anyone who has opened up a production system to correct persistent problems will know that legacy code can have a wide variety of presentations. While it may not be true that adherence to standards and inspection checklists eliminates problems in code performance, at the least they should provide pause for the programmer to be more vigilant. Requirements for code can be exemplified on one sheet for each programming language in use (e.g., Java, C++, SQL, Ruby). In addition to standards for code, there is a need for cosmetic standards for the menu system, screens, and reports.

187

Chapter 9

Engineering Software Quality

Table 9-21.  Standards and guidelines for programmers Standard for Program Naming Conventions (By Example)

•  Descriptive – upper/lower case

Style sheets for Programming Languages, e.g., SQL, COBOL, and Java (By Example)

• Capitalization • Use of upper/lower case • Reserved words • Indentation • Local and global variables (prefix, ULC) • Naming conventions • In-stream comments • Header block

Programmer’s Guidelines for In-stream Comments (By Example)

• Tabbing •  Break characters • White space

Table 9-22.  Cosmetic standards Standard for Menu System (By Example)

• Splash screen – logon • Main menu – hierarchy • Screen menu headings

Standard for Screen Presentations • Typeface and font size (By Example) • Color • Button size • Screen and subscreen ID numbers Standard for Reports (By Example)

188

• Title • Date • Type face and font size • Header, footer, top margin, pagination

Chapter 9

Engineering Software Quality

While there are standards that affect the cosmetic appearance of code, menu, screens, and reports, there are also standards that inform the programmer how to connect the program to the architecture –including access control.

Summation The sum and intent of standards, guidelines, and procedures is to create a “conduit” through which the quality of the software development effort can be controlled.

189

CHAPTER 10

Final Remarks Types of Software Software does not fit into one category. There are Embedded Systems, such as robotics, the Internet of Things (IoT), Fly by Wire in aircraft control systems, and voice recognition, where controls and “programs” are burnt into chips. These are at the heart of “Data Processing.” There is Enabling Software including Operating Systems, LAN software such as Novel, and Relational Database Management Systems (RDBMS) such as Oracle, and packaged frameworks such as .net. There are Products, including Office Productivity software such as MS Word, WordPerfect, Excel, or Adobe Acrobat, SAP – and there is packaged Application Software such as Entertainment, Games, and other application packages such as Song Surgeon, and mobile device APPS. And there are Information Systems including Management Information Systems (MIS) Decision Support Systems, and Warehouse systems – each requiring programming effort. Of these, there are Systems of Record (SORs) and customer-facing Systems of Engagement (SOE) such as websites or mobile devices explained earlier in the text. The interpretation of DPAC contained herein is for a System of Record.

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7_10

191

Chapter 10

Final Remarks

Types of Implementation First, there are “green fields” projects, where there is no existing system and the implementation can proceed from scratch. Then, there are projects that must deal with legacy systems: •

Upgrade (modernize) the legacy system for intranet or Internet access.

•

Consolidate several SOR systems into one.

•

Create a mobile access capability.

•

Add a data warehouse.

•

Attach a new service to an existing platform (e.g., add an Inventory service to a customer relations/order processing front end).

•

Interface with COTS packages.

•

Replace the legacy system with a more efficient bespoke system (e.g., convert a mainframe application written mostly in COBOL with an RDBMS - Relational Database Management System such as Oracle – application).

While retirement seems inevitable, there are systems that are still going strong through decades of use. Legacy systems may need to be enhanced to enjoy the delights of user-facing web and mobile experiences.

DPAC Activity Cycles The each Activity Cycle of DPAC represents a back and forth between implementation personnel and the client (end users). If the ellipses are rotated 90 degrees, one would observe a straight line, and movement

192

Chapter 10

Final Remarks

through the cycle would be represented by an up-and-down interaction between developers and clients from the organization. DPAC distinguishes itself from other development models in that it represents the movement of people rather than the progress of software – although the evolving software progresses (by human effort) along the same lines. The DPAC model is a shadow of activity in the real world. The DPAC model is designed to address the emergence of functional requirements throughout the development process, beginning with a Vision Statement and continuing into the Support Cycle. To that end, the cycles of activity in the DPAC model are represented as progressive, recursive (re-entrant), nested contiguous ovals; each activity cycle is overlaid with an interpretation of the Deming quality control cycle phases of Plan, Do, Check, and Act (PDCA). Each “Check” Phase has at least one part consisting of “review by User.” If the user is not satisfied at that level, the activity cycle repeats until that is accomplished. Where the user approves, activity advances to the next cycle. In DPAC, user feedback drives the development effort. For example, the Process Detail Cycle repeats until the user is satisfied with the result – at which time activity advances to the Unit Development Cycle. If, for some reason, criticism of the Unit Development shows poor understanding of the client’s needs (or the User has simply changed his mind), activity may circle back to the Process Detail Cycle or even back to the Process Overview.

Staffing Different personalities and experience bring different points of view to the table. While there may be as many exceptions as there are to the rule, a good business analyst has the persistence to get to the bottom of a user’s intent – not for the faint of heart – and has the modeling skills (such as creation of a DFD) used to describe the process. When the client 193

Chapter 10

Final Remarks

interviewed is not available to the programmers, a business analyst may be able to step in as a surrogate. In DPAC, in the Process Overview Cycle, two business analysts interview department heads (in triad) to outline the basic processes of the implementation field rendered in a DFD. Where there are multiple systems that are to be consolidated, a DFD should be created for each (by individual pairs of analysts), and an overall consolidated DFD created as a projected solution to duplication. Programmers are divided into those who like to build from scratch (developers) and those programmers who support the system. Testers, in my experience, are a breed apart. They may know how to read code, but are definitely not interested in development programming. They like to dig in and see how well the item of code meets requirements, and is stable, free of error. In this brand new era of comprehensive testing automation, however, testers must learn the basics of programming test automation tool(s).

Tester and Programmer Pairs Following the production of a comprehensive DFD, DPAC pairs a tester and a programmer to uncover the needs of the client by interviewing prospective clients of the system to be – applying the triad principle. There are several very good reasons for this pairing: 1. Each brings a different point of view to the problem of rendering the intent of the user into code. 2. Tool automation requires from 2:3 to 1:5 (or more) lines of code (LOC) than the unit code set down by the programmer/developer. Working together shortens the tester’s time overall to program the tool – as opposed to programming the tool after the programmer has completed his part of the task.

194

Chapter 10

Final Remarks

3. The perspective of the tester can provide a remedy to errors in code not apparent to the programmer. Early prevention is the cure. 4. Each test must be created manually prior to automation; the symbiosis of working together facilitates that effort. It may be true that the process of writing unit code will take longer than a programmer working alone, but the overall advantage of helping to create bug and error-free code saves considerable cost down the line. The matching of programmers to testers can begin in the hiring process. Each candidate can be questioned regarding her willingness to work with the other side. DPAC, in this interpretation, uses the lead programmer and the backup lead tester to interview prospective programmers. The lead tester and backup lead programmer interview prospective tester candidates. Some effort can be made in the final interviews to hire compatible personnel. (Likes repel; opposites attract.) Given the proclivities and differences between programmers and testers, compatibilities may be easier to find – given, of course, the willingness of each to give triad development with a tester a try. Call it the “willing suspension of disbelief.”

On Tools There are many roles for tools in the development process other than tools for the automation of software testing. Load and performance testing should be automated. Data must be generated for test. Other functions assisted by application software include but are by no means restricted to: •

Facilitating group communications (including Wiki for collecting and disseminating information and document control) 195

Chapter 10

Final Remarks

•

Controlling software versions as a part of a larger framework for configuration management

•

Maintaining the compendium of business rules

•

Carrying out database refactoring

•

Managing the handling of Change Reports (CRpts) and Discrepancy Reports (DRs)

Regarding Tools for Automated Testing There is a significant difference between a customer-facing application; Business to Customer (B2C), such as a website, IoT (Internet of Things), or a mobile application (APP); and a Management Information System (MIS) facing inward for internal organization use. The most significant difference is an MIS system uses inward-facing screens for input and screen based or hardcopy reports as the primary output. To put it another way, B2C applications are defined up front and worked back to implementation from the outside in. Full requirements for Systems of Record (SORs) such as an MIS evolve over time and are developed from the inside out. Further, in part the value of an SOR is that it enables ad hoc inquiry. It is absolutely essential that software for B2C applications gets out the door as rapidly as possible to be competitive in the marketplace. These applications get response from users after they are released, and tend to have a restricted user interface. The development of Systems of Record relies on feedback from users within the organization and may encompass many different services and interfaces. In the initial process of development, internal users are consulted in each iteration of the Process Overview Cycle in the Elaboration Stage and in the cycles of the Construction Stage. Another consideration regarding automated testing for MIS development efforts is the fact that the database structure also evolves 196

Chapter 10

Final Remarks

over time – through all the development cycles. Scripts for automation of functional requirement testing may have to be created or modified for each recursive iteration, still less time than it would take to perform the tests manually. A test plan would have to be prepared for either automated or nonautomated test. Even if the same test personnel are used for each progressive iteration, the time interval between manual testing and preparing or altering a test-tool script is significant. As stated earlier, the ratio of lines of program code (LOC) to automated test scripts is 2:3 or 1:5 or more. That is, 1000 lines of code can require up to 5000 lines of test script or more. The reason to use test automation scripts is to make the process of test reuseable for regression testing for changes made to the original unit code.

The Tool-Scape Is Changing At this writing (2022), the tool-scape is exploding with new entries and consolidations in every category. Between January 1917 and February 1918, there were $2,337,000,000 to 41 companies (and 11 undisclosed amounts) invested by venture capital into the tools market – crowned by $165,000,000 to Split Software in January 2017 and $100,000,000 to XebiaLabs in February 2018 - a market expected to reach $8.8 Billion by 2023. Source: Aaron Walker. “Agile Development: The State of DevOps Tools in 2018,” g2crowd/blog Technology Research, February 21, 2018 (retrieved 8/16/2018) (Google) The venture capital pouring into this sector means that a number of organizations will be absorbed by the fortunate few. When that happens, what becomes of the users of the tool absorbed? I have judiciously avoided the mention of specific tools, only indications where a category of tool (particularly administrative and 197

Chapter 10

Final Remarks

support tools) may apply – first and foremost because I have no firsthand knowledge nor hands on experience with any of the tools in use at this writing and, second, because the tool-scape is changing and will be changing so dramatically that whatever I might have to say will be out of date before this treatise comes to print. However, I will make three observations: •

A chain is only as strong as its weakest link. Beware of “all and everything” tool chains.

•

You will spend a lot of time and treasure discovering what a tool will not do.

•

“Best of breed” tools are the best – if they can “play well with others” (i.e., they offer enough of an open architecture to allow coupling with other best of breed tools).

No Silver Bullet (Brooks) Tools promise to lower costs – but none of these are free. Even “freeware” has a learning curve, and training takes time and costs money. Further, no tool will turn a bad design into a good one and finally:

Automation of an inefficient process automates inefficiency. Each tool is contained within a methodology – the more “integrated” the tool, the more it is dependent on a particular approach to doing business. Also each tool has its limits; the users of the tool will spend a great deal of effort discovering what the tool does not do. In some cases, this may mean abandonment of the tool (which compromises the integrity of the effort) or squeezing reality to fit the confines of the tool.

Any tool must support the integrity of the Vision, as well as the design and implementation thereof. 198

Chapter 10

Final Remarks

Categories of Essential Tools That being said, there are categories of essential tools that will facilitate a “lite” development effort as described herein. Drawing tools: •

Produce readable data flow diagrams and flowcharts

•

Produce a diagram of the database design (preferably in IDEF1X or IE)

Configuration management (CM) tools: •

Manage business rules and requirements

•

Maintain the traceability matrix

•

Track the progress of Change Reports and Discrepancy Reports

Version control tools: •

Manage software version control

•

Manage data and database version control

•

Maintain version control of test scripts

Process automation tools: •

Automate software “builds”

•

Automate software test

Communication and collaboration tools: •

Facilitate document circulation (e.g., a Wiki for standards, guidelines, and procedures)

•

Support face-to-face communication for working from home (WFH)

199

Chapter 10

Final Remarks

CM tools should be able to identify the business analyst that recorded the business needs, and the individual programmer (or programmer/ tester team) that is responsible for the completed code. This accountability facilitates the progress of test – where a Discrepancy Report can be directed to the originator of the code, thus expediting resolution.

Dr. Winston W. Royce vs. the “Waterfall” The earliest use of the term “waterfall” may have been in a 1976 paper by Bell and Thayer. Software requirements: Are they really a problem? TRW Defense and Space Systems Group, Redondo Beach, California, also published in Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976. (Wikipedia) The word “waterfall” does not appear in Royce’s paper: Managing the development of Large Software Systems. Proceedings, IEEE WESCON, August 1970, pages 1-9 (originally also published by TRW). In fact Royce was a firm critic of this approach. First launched in 1970, TRW built all 23 reconnaissance satellites in the Defense Support Program (DSP), which are the principal components of the Satellite Early Warning System currently used by the United States (Wikipedia). At that time (1970), the models for development of software followed the process of manufacturing “things,” as indeed was Royce’s interpretation. This simile was maintained for the next 30 years even to this day, although each succeeding model of the software development process brought something new to the table as computing began to turn from “Data Processing” to Information Processing. Royce was, however, the first to use this particular set of labels for the steps depicted in Figure 10-1.

200

Chapter 10

Final Remarks

Figure 10-1.  The cascading model With regard to this process, he relates: “I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in [Figure 10-2] below”

201

Chapter 10

Final Remarks

Figure 10-2.  Reality check Royce explained skipping over the analysis and coding steps of the model:

One cannot, of course, produce software without these steps, but generally [speaking in terms of the satellite manufacture support environment] these phases are managed with relative ease and have little impact on requirements design and testing. He wrote referring to amended model (Figure 10-2):

... I believe the illustrated approach to be fundamentally sound. The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks. These five steps are cogent to this day, regardless of the model employed: an abridged version follows, my emphasis in italics:

202

Chapter 10

Final Remarks

STEP 1: PROGRAM DESIGN COMES FIRST Write an overview document that is understandable, informative and current. Each and every worker must have an elemental understanding of the system. At least one person must have a deep understanding of the system which comes partially from having had to write an overview document. STEP 2: DOCUMENT THE DESIGN Each designer must communicate with interfacing designers, with his management and possibly with the customer. A verbal record is too intangible to provide an adequate basis for an interface or management decision. Recall that Royce is referring to software to support a satellite installation – where the customer is a group of scientific analysts – probably not culpable for program error. However, the other parties are members of the development team, and need to be kept in the loop. The remark regarding the need for more than a verbal record is true today: The real monetary value of good documentation begins downstream in the development process during the testing phase and continues through operations and redesign. STEP 3: DO IT TWICE If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned. 203

Chapter 10

Final Remarks

This was similarly noted by Frederick Brooks in The Mythical Man-­ Month (1975) as “Plan to throw the first one away, you will anyway.” In DPAC, the software is reinvented in every iteration of every activity cycle, progressively strengthened over time. STEP 4: PLAN, CONTROL AND MONITOR TESTING Without question the biggest user of project resources, whether it be manpower, computer time, or management judgment, is the test phase. It is the phase of greatest risk in terms of dollars. Most errors are of an obvious nature that can be easily spotted by visual inspection. Every bit of an analysis and every bit of code should be subjected to a simple visual scan by a second party who did not do the original analysis or code. STEP 5: INVOLVE THE CUSTOMER For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble. This is ameliorated in DPAC by progressive iteration of activity cycles uncovering requirements up to and including deployment. And most relevant even to today’s activities whatever the model: SUMMARY

I [Royce] would emphasize that each item costs some additional sum of money. If the relatively simpler process without the five complexities described here would work successfully, then of course the additional money is not well spent. in my 204

Chapter 10

Final Remarks

[Royce] experience, however, the simpler method [Figure 10-1] has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed. Source: Abridged from Winston Royce “Managing the Development of Large Software Systems,” Proceedings, IEEE WESCON, August 1970, pages 1-9 It is still a “hard sell.” Royce was indeed the first to label the parts of the cascading model in a form that has become common today, falsely enshrined as steps in the Software Development Life Cycle (SDLC) paradigm. The five steps, however, are still valid, and significant advice, and that, to me, is the enduring value of his article. Pity they are mostly overlooked. in describing the paper.

Kudos Royce’s paper is included in Harry R. Lewis ed. Ideas That Created the Future: Classic Papers of Computer Science: Classic papers by thinkers ranging from Aristotle and Leibniz to Norbert Wiener and Gordon Moore that chart the evolution of computer science. MIT Press 2021 This work collects 46 classic papers in computer science that map the evolution of the field. Royce is Number 33.

Conclusion Our profession is rife with misunderstandings, misinterpretations, misapplication, and lack of a viable model for the development of information systems (as opposed to data processing). I am putting DPAC forward as an independently generated model that resolves many of the 205

Chapter 10

Final Remarks

problems associated with our understanding of the software development process appropriate for agile and lean methods. If nothing else, I hope it will serve as a source for heuristic discussions of these issues. Again Onward through the fog!

206

APPENDIX A

Software Quality Defined Quality software criteria simplified: 1. Meets the needs of the user 2. Robust 3. Easy to use 4. Easy to maintain

Attributes of Quality International Organization for Standardization (ISO) ISO 25010 (superseding ISO 9126) is a taxonomy of attributes of software quality. The new model has eight characteristics, instead of six, and is quite similar to the old ISO model (Table A-1). The following list shows the main categories and subcategories of ISO 25010 – product quality model. Functional suitability – The degree to which the product provides functions that meet stated and implied needs when the product is used under specified conditions:

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7

207

Appendix A

Software Quality Defined

Functional completeness Functional correctness Functional appropriateness Performance efficiency – The performance relative to the amount of resources used under stated conditions: Time behavior Resource utilization Compliance Compatibility – The degree to which a product, system, or component can exchange information with other products, systems, or components, and/or perform its required functions while sharing the same hardware or software environment: Coexistence Interoperability Usability – The degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use: Appropriateness and recognizability Learn ability Operability User error protection User interface aesthetics Accessibility

208

Appendix A

Software Quality Defined

Reliability – The degree to which a system or component performs specified functions under specified conditions for a specified period of time: Maturity Availability Fault tolerance Recoverability Security – The degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization: Confidentiality Integrity Nonrepudiation Accountability Authenticity Maintainability – The degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers: Modularity Reusability Analyzability Modifiability Testability

209

Appendix A

Software Quality Defined

Portability – The degree to which a system or component can be effectively and efficiently transferred from one hardware, software, or other operational or usage environment to another: Portability Adaptability Install ability Compliance

Table A-1.  ISO attributes mapped to the four criteria from the 1970s ATTRIBUTE

Meet the Needs of the User

Functional Suitability

X

X X

Usability Reliability

X

Security

X X

Maintainability Portability

Easy to Use Easy to Maintain

X

Performance Efficiency Compatibility

Robust

X

Combining ISO 25010’s attributes of quality against the four attributes in use circa 1970 yields the first two columns of Table A-2. The third column in Table A-2 shows “action items” of how each quality attribute can be achieved.

210

Appendix A

Software Quality Defined

Items defined by quality control area 1. Meets the needs of the user Develop Vision Statement The Vision Statement defines the scope of the software development effort. Create High-Level Process Diagram In this example, this representation is level 1 of a data flow diagram. Identify Nonfunctional Requirements These include hardware performance and physical security requirements. Identify architectural requirements Distinction is made herein between architecture of the programming environment and the application architecture. Here, the latter will be accounted for in terms of common core functions (e.g., logon-related functions, audit trails).

211

Appendix A

Software Quality Defined

Table A-2.  Attributes and action items for each area of quality improvement 1970’s Criteria

ISO Attributes Action Items of Quality

1. Meets the Needs of the User

Functional Suitability Compatibility Portability Security

Develop Vision Statement Identify Security Considerations Create High-Level Process Diagram Identify Nonfunctional Requirements Identify Architectural Requirements Determine Business Rules Review Implementation of Business Rules with Users

2. Easy to Use

Usability

Identify Usability Requirements Review Interface with Users at All Stages of the Emerging System Provide User’s Guide Provide Training

3. Robust

Reliability Performance Efficiency

Identify Security Considerations Provide Error and Conflict Management Perform Input Testing and Load Testing Perform Application Testing at All Stages

4. Easy to Maintain

Maintainability Adhere to Standards, Guidelines, and Procedures Create Process Diagram of the System Perform Code Walk-Through/Refactoring Create Database Design Document Create Data Dictionary Create a Glossary Create Configuration Management Plan Maintain Traceability Matrix Provide Architecture Documentation

212

Appendix A

Software Quality Defined

Determine Business Rules Business rules define the core activities of the organization as embodied in proposed development effort. A “business rule” must be decomposed into a set of atomistic statements that become the testable requirements of the system. Review Implementation of Business Rules with Users As the business rules emerge, nuances and ambiguities must be resolved. This can be accomplished through successive iterations of the detailed design cycle. 2. Easy to use Identify Usability Requirements These requirements may include accessibility issues and a “three-click” rule: that each function of the system can be accessed in three mouse clicks (or less). Review Interface with Users at All Stages of the Emerging System Acceptability of the visual interface can be “washed” several times through successive iterations until the optimum solution emerges. Provide a User’s Guide Drafts of the User’s Guide should be delayed until the software has matured to a reasonable level of stability – and should be composed by an experienced technical writer. 213

Appendix A

Software Quality Defined

Provide Training Training must include training for the trainers. 3. Robust Identify Security Considerations Provide Error and Conflict Management The system must be “fail soft” such that no application or system error can bring down the system. Application and system errors should produce appropriate error messages. Perform Input and Load Testing Does the interface and system remain stable with incorrect input or with the maximum number of users? Perform Application Testing at All Levels This includes test-driven development. 4. Easy to maintain Adhere to Standards, Guidelines, and Procedures In particular, in-stream comments, screen identifiers and code formatting, process diagram of the system, and diagram of logical database design. Create a Process Description of the System In the interpretation of the development model contained herein, the system overview and data dependencies are accomplished by means of data flow diagrams.

214

Appendix A

Software Quality Defined

Perform Code Walk-Through/Refactoring Measures taken during the construction cycle to produce clean code facilitating maintenance. Create Database Design Document IDEF1X model of the relational database (Integration DEFinition for information modeling). Create and Maintain Data Dictionary Compendium of definitions of all database elements should be sortable by element or table name. Create and Maintain Glossary Accompanied by list of acronyms and map of the organization. Create Configuration Management Plan Identify roles and responsibilities for maintaining Software Configuration Inventory (SWCI) and version control. Maintain Traceability Matrix Traces business rules from the Vision Statement to their location in a segment of code. Provide Architecture Documentation (Application Architecture) Show how the application shall interface with the logon, sign-off, user identification, and audit trail processes.

The quality of the development environment affects the quality of the software product (particularly with regard to the ease (and cost) of maintenance). 215

APPENDIX B

Summary of Standards, Guidelines, and Procedures Standards Standard

Responsible Party

Description

Document Control

Configuration Manager

Example

Requirement Statements and Business Rules

Lead Business Analyst

2 Pages

Configuration Item Naming Conventions

Configuration Manager

Example

Database Naming Conventions

Database Administrator

Example

Data Dictionary

Librarian and Database Administrator

Example

Program Naming Conventions

Lead Tech

Example (continued)

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7

217

Appendix B

Summary of Standards, Guidelines, and Procedures

Standard

Responsible Party

Description

Program Style Sheets (For Each Language)

Lead Tech

Example

Standard and Guidelines for In-Stream Lead Tech Comments

Example

Menu System

Lead Tech

Example

Screen Presentation

Lead Tech

Example

Report Format

Lead Tech

Example

Guidelines Guideline

Responsible Party

Description

Interpreting DFDs

Lead Business Analyst

Pre-prepared Materials

Expressing Requirements and Business Rules

Lead Business Analyst

Pre-prepared Materials

Procedure

Responsible Party

Description

Procedure for Reviewing Requirements and Business Rules

Lead Business Analyst

1 Page and Checklist

Procedure for Maintaining a Compendium of Requirements Documents

Librarian (Configuration Manager) and Lead Business Analyst

1 Page

Policies and Procedures

Procedures for Managing the CMDB Configuration Manager

3 Pages

Procedure to Maintain Database of Librarian (Configuration Hardware Requirements (HWCI) Manager)

1 Page (continued)

218

Appendix B

Summary of Standards, Guidelines, and Procedures

Procedure

Responsible Party

Description

Procedure to Maintain Database of Librarian (Configuration Nonfunctional Requirements Manager)

1 Page

Procedure to Process Change Reports (CRpt)

1 Page and Form

Configuration Manager

Procedure for Code Version Control Lead Tech

(Training)

Procedure for CM Status Accounting from the SWCI Database

Configuration Manager

1 Page

Procedure for baselining Configuration Items

Configuration Manager

1 Page

Migration Plan – procedure to move DB structure across baselined partitions

Database Administrator 2 Pages

Procedure for Adding to Store of Global Variables

Lead Tech

1 Page

Procedure for Error Handling

Lead Tech

1 Page

Procedure for Connecting to the System Architecture

Lead Tech / System Architect

3 Pages

Procedure for Technical Code Inspections and Refactoring

Lead Tech

1 Page and Checklist

Test Protocols Form and Format

Test

2 Pages

Test readiness reviews / Inspections

Software Quality Assurance

Checklist

Procedure to Process Discrepancy Configuration Manager Reports (DR)

1 Page and Form

219

Appendix B

Summary of Standards, Guidelines, and Procedures

Audits Audit

Responsible Party

Description

Audit Integrity of Pointers from Requirement and Business Rule Data Stores to Offline Compendium of Documents

Quality Assurance Officer

Report

Audit of CRpts Outstanding

Quality Assurance Officer

Report

Audit of Baselined Items

Quality Assurance Officer

Report

Audit Integrity of Traceability Matrix

Configuration Management and Quality Assurance Officer

Report

Audit Execution of Migration Plan (Baselines)

Quality Assurance Officer

Report

Audit Conversion Plan Against Result (Where Applicable)

Quality Assurance Officer

Report

Conduct Data Conversion Readiness Review

Quality Assurance Officer

Report

Conduct Test Readiness Reviews

Quality Assurance Officer

Report

Audit of DRs Outstanding

Quality Assurance Officer

Report

GRAND TOTALS 16 One-Page Documents 3 Two-Page Documents 2 Checklists 2 Forms

220

Appendix B

Summary of Standards, Guidelines, and Procedures

9 Examples 9 Reports 1 Entity Relationship Diagram Additional Materials due at Turnover (For Acceptance Test)

Responsible Party (By Role)

User’ Manual and Training Guide

Technical Writer

Application Administrator’s Manual (Use of System Backbone Features)

Developed In-house for Security

Help Desk Instructions

Technical Writer

Data Dictionary – Online and Printed Copies

Librarian, Data Modeler

Glossary List of Acronyms List of Abbreviations Organization Chart

Librarian

Database Documentation – Entity Relationship Diagram or Big Data Schema

Data Modeler

Database Script Library

Database Administrator (DBA)

221

APPENDIX C

Quality Engineering: By Area Business Analysis Item

Type

Description

Guideline Interpreting DFDs

Guideline (Prepared Materials)

Requirements Statements and Business Rules

Standard 1 Page

Guideline Expressing Requirements and Business Rules

Guideline (Prepared Materials)

Procedure for Reviewing Requirements and Business Rules

Procedure Checklist

Configuration Management Item

Type

Description

Procedure for Maintaining a Compendium of Requirements Documents

Procedure

1 Page

Configuration Item Naming Conventions

Standard

Example

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7

223

Appendix C

Quality Engineering: By Area

Item

Type

Description

Maintain CMBD

Procedure

User’s Guide (Training)

Process Change Reports (CRpts)

Procedure

1 Page Form

Update Status Accounting in the SWCI Database

Procedure

1 Page

Procedure for Baselining Configuration Items – Produce Report

Procedure

1 Page

Process Discrepancy Reports (DRs)

Procedure

1 Page Form

Librarian Item

Type

Description

Document Control

Standard

Example

Maintain List of Hardware Requirements (HWCI)

Procedure

1 Page

Maintain Database of Other Nonfunctional Requirements Procedure

1 Page

Maintain Data Dictionary

By Example 1 Page

Database Administration Item

Type

Description

Database Naming Conventions

Standard

Example

Create Initial Version of Database from DFD

Procedure

ERD

Populate Initial Version with Test Data

Procedure

1 Page

Migration Plan – Procedure to Move DB Structure Across Procedure Baselined Partitions

2 Pages

Conversion Plan

2 Pages

224

Procedure

Appendix C

Quality Engineering: By Area

Tech - Programming Item

Type

Description

Procedure for Code Version Control Tool

Procedure

(Training) Example

Program Naming Conventions Program Style Sheets (For Each Language)

Standard

Example

Guidelines for In-Stream Comments

Standard

Example

Format for Menu System

Standard

Example

Format for Screen Presentations

Standard

Example

Format for Reports

Standard

Example

Procedure for Error Handling

Procedure

1 Page

Procedure for Adding to Store of Global Variables

Procedure

1 Page

Procedure for Connecting to the System Architecture

Procedure

2 Pages

Technical Code Inspections and Refactoring

Procedure

Checklist

Make Corrections in Response to Discrepancy Reports

Procedure

1 Page

Software Quality Assurance and Test Item

Type

Description

Audit Integrity of Pointers from Requirement and Business Rule Data Stores to Offline Compendium of Documents

Audit

Report

Audit of CRpts Outstanding

Audit

Report

Audit of Baselined Items

Audit

Report

Audit of Integrity of Traceability Matrix

Audit

Report

Audit Execution of Migration Plan (Baselines)

Audit

Report

225

Appendix C

Quality Engineering: By Area

Item

Type

Description

Audit Conversion Plan Against Result (Where Applicable)

Audit

Report

Conduct Data Conversion Readiness Review

Audit

Report

Test Protocols (Form and Format)

Procedure 2 Pages

Test Readiness Reviews/Inspections

Procedure Report

Audit of DRs Outstanding

Audit

226

Report

APPENDIX D

Data Flow Diagramming Data Flow Diagrams Data flow diagrams (DFDs) are diagrams showing the flow of data through a system. DFDs show dependencies between processes and data requirements enabling a preliminary database design. There are two alternative sets of symbols: Chris Gane and Trish Sarson’s notation, first published as Structured Systems Analysis: Tools and Techniques First Edition, July 1977, adopted by the McDonnell Douglas Corporation. The second symbol set is that of Tom DeMarco published in Structured Analysis and System Specification, Prentice Hall Inc., 1979. I have used the Gane and Sarson notation and prefer it to the DeMarco symbol set because the G&S “Process” symbol provides more “real estate” for labeling. There are only four basic symbols in a DFD: Entities, Data Flows, Processes, and Data Stores (Figure D-1). An Entity can be a person, another system, or subsystem. In the Gane and Sarson notation, there is one additional symbol, a material flow, to denote the transfer of physical objects – such as a library book. Also in G&S, duplicate symbols (used for cosmetic purposes) are notated by an extra line on the symbol.

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7

227

Appendix D

Data Flow Diagramming

I am introducing two more symbols to the set – a digital data flow to account for the special case of a material flow for the transfer of digitized information such as a digital picture (e.g., an accident damage photo) and a shaded Entity to show only partial involvement in the diagram’s activity.

Figure D-1.  Basic symbol set In addition to the symbol set, there are some basic rules:

228

•

The flow of data begins with an external entity leading to a process.

•

Each external entity must be involved with at least one data flow.

•

A data flow from an external entity does not go to a data store directly. It must first pass through a process.

•

All processes should modify incoming data, producing new forms of outgoing data.

Appendix D

Data Flow Diagramming

•

All processes must have at least one data flow in and one data flow out.

•

Data flows are in one direction only. Returning data is represented by a separate data flow.

•

Each data store must be involved with at least one data flow.

•

Each data flow must have a unique name.

Legal and illegal combinations of data flows are depicted in Figure D-2.

Figure D-2.  Legal and illegal data flows

229

Appendix D

Data Flow Diagramming

Leveling Leveling is the art of decomposing a process into its constituent parts – down to the level where the resultant data flow diagram represents the lowest level of process decomposition. The creation of a DFD may begin with a high-level “Context Diagram,” which shows all the entities involved with the system, a single Process symbol, and the connecting data flows. While the Context Diagram has been variously as numbered 0 or 1 by different practitioners, I prefer the former because it represents no single process, but rather the sum of all processes, or Level 0. The decomposition of the Context Diagram begins with Level 1. The Level 1 diagram decomposes the context diagram to a set of uniquely named Dataflows, numbered Processes, Datastores, and Entities. Where a numbered Process requires further decomposition, an asterisk (*) will be placed below the Process name. There is one additional diagram for each process marked for decomposition. Each of the Level 2 diagram’s processes is numbered as a “dot” number referring to the parent process (e.g., 6.1, 6.2, 6.3, etc.) for the Level 2 child diagram of Level 1, Process 6. If Level 2 Process 6.4, for example, has lower-level children (Level 3), the processes thereof will be numbered 6.4.1, 6.4.2, 6.4.3, etc. Another way to remember how levels are numbered is to observe that Level 1 processes are numbered by a single integer (e.g., 6), Level 2 processes are numbered by a number and a dot number (e.g., 6.4), and the third level is numbered by three digits separated by dots (e.g., 6.4.1). The source (or destination) of each inbound (or outbound) data flow may be a Process, Data Store, or Entity. Each lower diagram is required to show all attached data flows. The rule is that each symbol in the lower level is something not represented uniquely in the upper level.

230

Appendix D

Data Flow Diagramming

Why Draw a Data Flow Diagram The larger question is why an organization needs to automate or improve existing processes. In current terms, an organization undergoes a “Digital Transformation” to be competitive in a digital world. The answers should not be surprising. They were effectively articulated by Michael Hammer, Beyond Reengineering, Harper Business, 1996. It is defined therein by four principles: Principle 1 – The mission of a business is to create value for its customers. “... a company exists to create customer value. Everything a company does must be directed to this end.” Value can be as simple as offering excellent customer service, or facilitating the process of a customer to spend their money at the business or at its virtual presence on the Internet. In other words, it eliminates customer frustration and saves the customer’s time. For example, Amazon is fundamentally a superior web-based customer service organization, with superior fulfillment processes that happens to sell books, music recordings, and video offerings, initially, now a broad variety of consumer goods supported by the same basic processes. Principle 2 – It is a company’s processes that create value for its customers

231

Appendix D

Data Flow Diagramming

“…a process [is] a group of tasks that create customer value. The tasks are the bits of work that people actually perform, but the tasks themselves do not create value nor do the individuals performing them. It is only the whole process, all the tasks put together, that creates value.” Principle 3 – Business success comes from superior process performance. “Execution – process - is the key to contemporary success, not plans – strategies.” Principle 4 – Superior process performance is achieved by having a superior design, the right people to perform it, and the right environment for them to work in. “The structure, layout, and the organization of the process – how the individual tasks are performed and integrated – is a critical determinate of how well the process performs.” A data flow diagram of the “system to be” is an important tool toward uncovering superior process performance. In general, a DFD:

232

•

Narrows the focus of the effort, noting matters out of scope of the Vision Statement

•

Identifies how data is passed through the organization

•

Identifies dependencies of processes and data

•

Identifies timing issues

•

Decomposes processes to the lowest unit of functionality

Appendix D

Data Flow Diagramming

Essentially, a DFD represents a snapshot, in our example, of future time.

 Fictitious Example (Reductio A Ad Absurdum) Acme Auto Insurance, with offices in each of the lower 48 states and the District of Columbia, wants to automate manual claim processing to offer a more efficient response to client requests for information regarding their claim. COTS (commercial off-the-shelf ) systems for claims processing were examined, but none were without integration of auto insurance with other types of insurance (such as homeowner’s) and were so expensive that development of a bespoke system for claims processing was chosen. There is presently no common procedure for processing claims at each local office, nor is there means to track progress of the incident nationwide. It was decided that the client contact records and exhibits would be retained at each local office to avoid the accumulation of all contact records and exhibit records from all offices nationwide at the national level. Plus, the maintenance of records at the local level would require quite a large increment of processing power for the hardware at the national system. The client profile and policy databases are on a central hardware facility held in the main office in Lincoln, Nebraska, available to each local office over a secure Internet connection. It was also decided that a common Incident A summary record be made available on the national system, available to all local offices nationwide. The Vision Statement for the expansion of services is outlined in the following sections.

233

Appendix D

Data Flow Diagramming

 ur Goal Is to Improve Customer Service O Regarding Claims Management •

Interface local Claims management with the National Client Profile and Policy System to improve the ability to respond to claim status inquiries nationwide.

•

Speed up the process of claim resolution.

•

Respond promptly to customer requests for information regarding their claim.

•

Move to digital capture and storage of all documentation (including digital photographs, videos, accident reports, medical claims, repair estimates, and other documentation).

•

Examine alternatives for document digitization and handling (COTS software).

Process Narrative (System to Be) The process begins with the registration of a Client Profile and issuance of a custom tailored Policy on the existing national system at the time a new client is enrolled. A Claim is initiated, usually by a phone call, of an initial incident reported to a local office. Using the national system, the Agent verifies that the person submitting an incident report is in fact an insured client and that the policy reflects a current valid status. The client is notified that the claim has been received and is being processed, and a contact record is created on the local system to document each transaction regarding that claim.

234

Appendix D

Data Flow Diagramming

An Incident data store will be created on the national system to reflect the status of processing at the local office closest to the incident, yet available nationwide to the office where the policy was issued. The next step is to begin to assemble documentation of the incident beginning with the incident report. Other materials may include digital photos of the damage, police reports, policy numbers of the other motorist(s), medical bills, repair costs or estimates, and any other items pertaining to the occurrence. The document acquisition process may also issue requests to the appropriate parties for items not forthcoming. Each item of evidence received is recorded in an Exhibit database, which stores images and data with the corresponding client, policy, and incident identifiers. There is one exhibit record for each item of documentation. Digital images, including scanned hard copy of each exhibit, are stored in an Image database. If an incident occurs on the road distant from the local office which issued the policy, the office local to the scene of the accident processes the documentation but enters an Incident record so progress can be monitored at the local office back home. (It is always more efficient to gather information at the office closest to the scene.) A Context Diagram showing all external entities for the claims processing system is represented in Figure D-3.

235

Appendix D

Data Flow Diagramming

Figure D-3.  Context diagram - Level 0 The Level 1 diagram (below) depicts claims processing at the first level of detail. Note that I have numbered the Processes with a letter prefix to differentiate the three distinct services of the system: M – Main office engagement of the insured to the system by an Agent of the firm. C – Manage Image Records; assemble documentation. Ordinal numbers alone – Response to inquiries. In addition, data stores are identified in two categories: national, with an N prefix, and local with a D prefix.

236

Appendix D

Data Flow Diagramming

Process Claim Level 1 (Figure D-4) decomposes to a lower level – assemble documentation - Process Claim Level 2 (Figure D-5). Documentation is gathered from the several providers and requests are issued for documents not forthcoming. The process continues with scanning hardcopy documents and directing digital documents to Digital Quality Control. After passing quality control, the digitized documents are made accessible to the local office for monitoring and evaluation.

237

Appendix D

Data Flow Diagramming

Figure D-4.  Process Claim 238

Appendix D

Data Flow Diagramming

Figure D-5.  Assemble documentation 239

Appendix D

Data Flow Diagramming

Both the Capture Hardcopy and Digital Quality Control processes from Level 2 decompose to third level DFDs shown in Figures D-6 and D-7, respectively.

Figure D-6.  Scan hardcopy Hardcopy documents are Bates Stamped by the Document Capture Section to generate date of receipt and identification number. They are then scanned and given a visual inspection. The document is rescanned and/or subjected to visual enhancement as required to create the best image possible. Hardcopy is archived in Manual Document Storage. The Exhibit database is updated and made available to the local office. In parallel, documents arriving in digital form, such as digital photos or videos, are visually inspected and enhanced as necessary. The Exhibit database is updated, and the digital items are passed to Digital Quality Control. In the system to be, the Document Capture Section scans all hardcopy and records each, as well as digital items (like scene photos), in an Image data structure synchronized with Exhibit and checked by the Quality

240

Appendix D

Data Flow Diagramming

Control Section. The set of all current data is then processed by the Analysis Section in the main office. All communication regarding each claim is recorded in a Contact database. The Image structure is defined by a set of disk directories based on Claim number. Each record from each database is “filed” under its corresponding Claim number. Images are stored as jpeg files.

Figure D-7.  Quality control Short Specification for the Claims Department Information Image Processing Subsystem •

The system must accommodate all materials tied to a specific claim: •

Digitized (scanned) printed material

•

Digital photos and/or videos

•

The system must be able to enhance “fuzzy” (focus) or “blurred” (contrast) images and convert images to jpeg files.

•

The system must provide for Image Quality Control for receipt of digitized documentation. 241

Appendix D

Data Flow Diagramming

•

The system must accept distinct image labels.

•

The system must produce management reports for the main office.

Data Dictionary The Claims Department Information System (CDIS) is built on four data stores: Incident, Exhibit, Contact, and Image. It also derives support from two data stores in the Main Office Information System: Client and Policy (not represented below). The preliminary database design of tables in the local system is represented in Figure D-8.

Figure D-8.  Preliminary database design

242

Appendix D

Data Flow Diagramming

The result is a preliminary outline for a Respond to Client Inquiry and Document Handling system that could be applied to a number of situations. It also results in a preliminary database design that can be physically instantiated and populated with test data for the implementation of the system as a whole – including management tracking and summary reports. Omitted from this overall design is the ability to sign on and sign off, to add and subtract users, to assign security levels, and to provide the ability to change passwords and track (audit) user activity if required. One huge risk is finding a way to transfer the Client and Policy information from the central data system to the local subsystem (or vice versa). From the Documentation Block (DocBlock) on the Process Claim Level 1 DFD, this solo design effort lasted 6 weeks. This duration was not working every day; it allowed time off for rejuvenation and thinking time for the “little gray cells” to reformulate the problem. Finally, to fulfill the last objective of the Vision Statement, the search for a COTS (commercial off-the-shelf ) system should simultaneously be carried out by a business analyst with technical experience. At the least, turnkey image enhancement software needs to be added to the list of alternatives. The DFD in its present form identifies three new “Services” and can serve as a functional requirements specification document from which early estimates of required staffing (and cost) can be derived. 1.

Verify caller’s status: •

Capture client ID and policy number on local system.

•

Initiate Incident record on national system.

243

Appendix D

2.

3.

Data Flow Diagramming

Track contacts: •

Initiate a contact record on the local system.

•

Assign unique record number.

Collect, digitize, and store exhibits. •

Update Incident Record.

Specific requirements are derived in the Process Detail Cycle of the Elaboration Stage emboldening refinement of the DFD in its present form. Early on, a DFD is a powerful tool to keep in the analysis toolkit.

244

Resources by Category SOCIAL COMMENTARY Axelrod, Robert. The Evolution of Cooperation. Cambridge, MA: Basic Books, 1984 Chase, Stuart (ed), Language Thought and Reality. Selected Writings of Benjamin Lee Worf. Mansfield Centre, CT: Martino Publishing, 2011 DeMarco, Tom & Timothy Lister. Peopleware. 2nd ed. Atlanta: Dorset House, 1999 Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago University Press, 1996 Ries, Eric. The Lean Startup. New York: Penguin Random House LLC, 2011 Schrange, Michael. No More Teams. Mastering the Dynamics of Creative Collaboration. New York: Doubleday, 1989 Winograd, Terry & Fernando Flores. Understanding Computers and Cognition. Reading, MA: Addison-Wesley, 1987 PERSPECTIVES Adzic, Gojko. Bridging the Communication Gap. London, UK: Neuri, 2009 Boehm, Barry & Richard Turnet. Balancing Agility and Discipline. Boston: Addison-Wesley,2003 Brooks Jr., Frederick P. The Mythical Man Month (Anniversary Edition). Boston: Addison-Wesley, 2006 DeMarco, Tom & Timothy Lister. Waltzing with Bears. Englewood Cliffs, NJ: Yourdon Press, 2004 Boutros, Tristan & Jennifer Cardela. The Basics of Process Improvement. Boca Raton, FL: CRC Press, 2016 Glass, Robert L. Software Conflict 2.0. Atlanta: Developer*, 2003

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7

245

RESOURCES BY CATEGORY

Hammer, Michael. Beyond Reengineering. How the Process-­Centered Organization is Changing Our Work and Our Lives. New York: HarperCollins, 1996 Hammer, Michael & James Champy. Reengineering the Corporation. New York: HarperCollins, 2003 Highsmith, Jim et al. Edge. Value Driven Digital Transformation. n.p.: Pearson Education, Inc., 2020 Hooks, Ivy F. & Kristin A. Farry. Customer Centered Products. Creating Successful Products Through Smart Requirements Management. New York: American Management Association, 2001 Johnson, Jim. My Life is Failure. West Yarmouth, MA: Standish Group International Inc., 2006 Oram, Andy &Greg Wilson Eds. Making Software. Sebastopol, CA: O’Reilly, 2011 Sakai, Takao. The Secret Behind the Success of Toyota, n.p., n.a, 2018 Yourdon, Edward. Death March 2nd ed. Boston: Addison-Wesley, 1995 APPLICATION LIFECYCLE MANAGEMENT Aeillo, Bob & Leslie Sachs. Agile Application Lifecycle Management. Boston: Addison-Wesley, 2016 Huttermann, Michael. Agile ALM. Shelter Island, NY: Manning, 2012 Rossberg, Joachim. Beginning Application Lifecycle Management. New York: Apress, 2014 PROJECT MANAGEMENT DeMarco, Tom. Controlling Software Project. Englewood Cliiffs, NJ: Yourdon Press A Prentice Hall Company, 1982 DeMarco, Tom. The Deadline. Atlanta: Dorset House, 1997 Gilb, Tom. Principles of Software Engineering Management. Boston: Addison-Wesley, 1988 Highsmith, Jim., Agile Project Management: Creating Innovative Products, 2nd Edition. Upper Saddle River: NJ; Addison Wesley, 2010

246

RESOURCES BY CATEGORY

Humphrey, Watts S. Managing the Software Process. Boston: Addison-­ Wesley, 1989 McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1988 Royce, Walker. Software Project Management A Unified Framework. Boston: Addison-Wesley, 1998 Schwaber, Ken. Agile Project Management with Scrum. Sebastopol, CA: O’Reilly, 2003 Stellman, Andrew & Jennifer Greene. Applied Software Project Management. Redmond, WA: Microsoft Press, 2013 Tillman, George. Project Management Scholia., n.p.,: Stockbridge Press, 2019 Weinberg, Gerald M. Quality Software Management. Volume 1 Systems Thinking. New York;, Dorset House, 1992 Whitten, Neal., Managing Software Development Projects, 2nd Ediition. New York: John Wiley & Sons, 1995 RISK MANAGEMENT Boehm, Barry W. Tutorial: Software Risk Assessment. Washington, DC: IEEE Computer Society Press, 1989 Hall, Elaine M. Managing Risk. Boston: Addison-Wesley, 1988 Karolak, Dale Walker. Software Engineering Risk Management. Los Alamitos, CA: IEEE Computer Society Press, 1996 APPROACH Ambler, Scott W.`The Object Primer. 3rd ed. New York, NY: Cambridge, 2009 Cohn, Mike. Succeeding With Agile. Boston: Addison-Wesley, 2010 Poppendiek, Mary & Tom Poppendiek. Lean Software Development. Boston: Addison-Wesley, 2003 Poppendiek, Mary & Tom Poppendiek. Implementing Lean Software Development. Boston: Addison-Wesley, 2007

247

RESOURCES BY CATEGORY

OVERVIEW Abahamsson, Pekka et al. Agile Software Development Methods: Review and Analysis. Otamedia, Finland: VTT Publications 478.2002 Larman, Craig. Agile and Iterative Development. Boston: Addison-­ Wesley, 2004 METHODOLOGY Ambler, Scott W. & Mark Lines. Disciplined Agile Delivery. Boston: IBM Press, 2012 Ambler, Scott W. & Mark Lines. Choose Your WoW. Newtown Square, PA: Project Management Institute, Inc., 2020 Cockburn, Alistair. Crystal Clear. Boston: Addison-Wesley, 2005 Highsmith, James A. Adaptive Software Development. Atlanta: Dorset House, 2000 Knaster, Richard & Dean Leffingwell. SAFe Distilled 4.5. Boston: AddisonWesley, 2011 Lines, Mark & Scott W. Ambler. Introduction to Disciplined Agile Delivery 2nd Ed. n.p. self, 2018 Martin, James. Rapid Application Development. New York: MacMillan Publishing Company, 1991 McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996 Rubin, Kenneth S. Essential Scrum. Boston: Addison-Wesley, 2013 Schwaber, Ken & Mike Beedle. Agile Development with Scrum. Upper Saddle River, NJ: Prentice Hall, 2002 Stapleton, Jennifer. DSDM Dynamic Systems Development Method. Edinburgh, England: Pearson Education Limited,1997 UNIFIED PROCESS Ambler, Scott W. & Larry L. Constantine. The Unified Process Inception Phase. Lawrence, KS: CMP Books, 2000 Ambler, Scott W. & Larry L. Constantine. The Unified Process Elaboration Phase. Lawrence, KS: CMP Books, 2000 248

RESOURCES BY CATEGORY

Ambler, Scott W. & Larry L. Constantine. The Unified Process Construction Phase. Lawrence, KS: CMP Books, 2000 Ambler, Scott W. & Larry L. Constantine. The Unified Process Transition and Production Phases. Lawrence, KS: CMP Books, 2002 Cockburn. Alistair. Writing Effective Use Cases. n.p.: self, 2001 Jacobson, Ivar et al. The Unified Software Development Process. Boston: Addison-Wesley, 2004 Kroll, Per & Phillippe Kruchten. The Rational Unified Process Made Easy. Boston: Addison-Wesley, 1999 Kruchten, Pillippe. The Rational Unified Process, An Introduction 3rd ed. Boston: Addison-Wesley, 2003 METHODS - DRIVEN DEVELOPMENT DD.Adzic, Gojko. Specification by Example. Shelter Island, NY: Manning, 2011 Gartner, Markus. ATDD by Example. Boston: Addison-Wesley, 2013 Koskela, Lassse. Test Driven. Shelter Island, NY: Manning, 2008 Nagy, Gaspar & Seb Rose. The BDD Books: Discovery. n.p.: self, 2021 Palmer, Stephan R. A Practical Guide to Feature Driven Development. Upper Saddle River, NJ: Prentice Hall, 2002 Pugh, Ken. Lean-Agile Acceptance Test-Driven Development. Boston: Addison-Wesley, 2011 Rose, Seb & Gaspar Navy. The BDD Books: Formulation. n.p: self, 2018 Stewart, John Ferguson.BDD in Action. Shelter Island, NY: Manning, 2015 TECHNIQUE Ambler, Scott W. Agile Modeling. Boston: Addison-Wesley, 2011 Beck, Kent. Test-Driven Development. New York Addison-Wesley, 2007 Beck, Kent. extreme Programming explained. New York: Addison-­ Wesley, 2000 Beck, Kent & Martin Fowler. Planning Extreme Programming. Boston: Addison-Wesley, 2001 249

RESOURCES BY CATEGORY

Bolboacä, Adrian. Practical Remote Pair Programming. Birmingham, UK; Packt Publishing, 2021 Chorafas, Dinitris N. Enterprise Architecture and New Generation Systems. Boca Raton, FL: St. Lucie Press. A CRC Press Company. 2002 Duval, Paul M. Continuous Integration. Boston: Addison-Wesley, 2003 Feathers, Michael C. Working Effectively with Legacy Code. Upper Saddle River, NJ: Prrentice Hall, 2005 Humble, Jez & David Farley. Continuous Delivery. Upper Saddle River, NJ: Prentice Hall, 2005 Martin, Robert C. Clean Architecture. Boston: Addison-Wesley, 2018 Mugridge, Rick & Ward Cunningham. Fit for Developing Software. New York: Prentice Hall, 2002 Muggridge, Rick & Ward Cunningham. FIT for Integrated Tests. Upper Saddle River, NJ: Prentice Hall, 2005 Newkirk, James & Robert C. Martin. Extreme Programming in Practice. Boston: Addison-Wesley, 2001 Nicega, Knil. Writing Great Specifications. Shelter Island, NY: Manning, 2018 Ruping, Andreas. Agile Documentation. Boston: Addison-Wesley, 2007 BUSINESS ANALYSIS AND REQUIREMENTS Beaty, Joy & Anthony Xhen. Visual Models for Software Requirements. Redmond, WA: Microsoft Press, 2012 Davis, Alan M. Software Requirements, revision. Upper Saddle River, NJ: Prentice Hall, 1993 Davis, Alan M. Just Enough Requirements Management. Boston: AddisonWesley, 2011 Gause, Donald C. & Gerald M. Wiesenberg. Exploring Requirements. Atlanta: Dorset House, 1989 Goldsmith, Robin F. Discovering REAL Business Requirements for Software Project Success. Norwood, MA: Artech House Inc., 2004 Hay, David C. Requirements Analysis. Upper Saddle River, NJ: Prentice Hall, 2003 250

RESOURCES BY CATEGORY

Heath, Fred. Managing Requirements the Agile Way, Liverey Place, Birmingham, UK: Packt Publishing, 2020 Leffingwell, Dean. Agile Software Requirements. Boston: Addison-­ Wesley, 2003 Leffingwell, Dean. Managing Software Requirements. 2nd ed. Boston: Addison-Wesley, 2016 McDonald, Kenty J. Beyond Requirements. Redmond, WA: Microsoft Press, 2013 Podeswa, Howard. The Agile Guide to Business Analysis and Planning. Boston: Addison-Wesley, 2021 Podeswa, Howard. The Business Analyst’s Handbook. Boston: Course Technology, 2009 Sampaio, Julio Cesar et al. Perspectives on Software Requirements. Norwell, MA: Kluwer, 2004 Wiegers, Karl & Joy Beatty. Software Requirements 3rd ed. Atlanta: Dorset House, 2005 Withall, Stephen. Software Requirement Patterns. Redmond, WA: Microsoft Press, 2007 BUSINESS RULES Morgan, Tracy. Business Rules and Information Systems. Boston: AddisonWesley, 2002 Ross, Ronald G. Principles of the Business Rule Approach. Boston: AddisonWesley, 2003 Ross, Ronald G. Business Rule Concepts. 3rd ed. n.p: Business Rule Solutions LLC, 2009 von Halle, Barbara. Business Rules Applied. New York: Wiley, 2002 USER STORIES Adzic, Gojko & David Evans. Fifty Quick Ideas to Improve Your User Stories. London, UK: Neuri, 2014 Cohn, Mike. User Stories Applied. Boston: Addison-Wesley, 2003 Patton, Jeff. User Story Mapping. Sebastopol, CA: O’Reilly, 2014 251

RESOURCES BY CATEGORY

DATABASE Ambler, Scott W. Agile Database Techniques. New York: Wiley, 2003 Burns, Larry. Building the Agile Database. Westfield, NJ: Technics Publications, 2011 Gurnsey III, Max. Test-Driven Database Development. Boston: AddisonWesley, 2013 O’Donnell, Glen & Carlos Casanova. The CMDB Imperative. Upper Saddle River, NJ: Prentice Hall, 2009 TEST Axelrod, Aron. Complete Guide to Test Automation. New York: Apress, 2018 Belzer, Borix. Software Testing Techniques 2nd ed. New York, NY: Van Nostrand Reinhold, 1990 Crispen, Lisa & Janet Gregory. Agile Testing. Boston: Addison-­Wesley, 2009 Gregory, Janet & Lisa Crispen. More Agile Testing. Boston: Addison-­ Wesley, 2015 Gregory, Janet & Lisa Crispen. Agile Testing Condensed. n.p.: Leanpub, 2019 Khorkov, Vladmir. Unit Testing. Shelter Island, NY: Manning, 2020 Lewis, William E. Software Testing and Continuous Quality Improvement. Boca Raton, FL: CRC Press, 2009 Meters, Glenford J. The Art of Software Testing. New York: Wiley, 1979 Paskal, Greg. Test Guide to Automation in the Real World. n.p.: self, 2017 Rasmunusson, Jonathan. The Way of the Web Tester. n.p.: Pragmatic Programmers, 2016 Schaeffer, Jeffrey et al. The Kitty Hawk Venture. New York: Apress, 2018 Tarlinder, Alexander. Developer Testing. Boston: Addison-Wesley, 2017 DEVOPS Davis, Jennifer & Katherine Daniels. Effective DevOps. Portland, OR: IT Revolution Press, 2013 Hutterman, Michael. DevOps for Developers. New York: Apress, 2012

252

RESOURCES BY CATEGORY

Kim, Gene & Jez Humble et.al. DevOps Handbook. 1st ed. Portland, OR: IT Revolution Press, 2016 Kim, Gene et.al. The Phoenix Project (revised). Sebastopol, CA: O’Reilly, 2016 SUPPORT Glass, Robert & Ronald A. Noiseux. Software Maintenance Guidebook. Upper Saddle River, NJ: Prentice Hall, 1981 Grub, Penny & Armstrong A. Takang. Software Maintenance Concepts and Practice 2nd Ed. Toh Tuck Link, Singapore: World Scientific Publishing Co., 2003 Lientz, Bennet P. & E. Burton Swanson. Software Maintenance Management. Boston: Addison-Wesley, 1980 Martin, James & Carma McClure. Software Maintenance. Upper Saddle River, NJ: Prentice Hall, 1983 Pigoski, Thomas M. Practical Software Maintenance. New York: Wiley, 1997 Polo, Maricio, Mario Piatinni. Advances in Maintenance Management. Hershey, PA: Idea Group Publishing, 2003 Swanson, E. Burton & Emanuel R. Bakeh. Maintaining Information Systems in Organizations. New York: Wiley, 1989 ON QUALITY Crosby, Philip B. Quality is Free. New York: McGraw-Hill, 1979 Deming, W. Edwards. Out of the Crisis, Cambridge. MA: MIT Press, 1982 Deming, W. Edwards. The New Economics. 2nd ed. Cambridge, MA: MIT Press, 1994 Feigenbaum, Armand V. Total Quality Control. 3rd ed. New York: McGrawHill, 1961 Juran, J.M. Juran on Planning for Quality. New York: The Free Press. A Division of Macmillan Inc., 1988 Juran, J.M. (editor in chief ). A History of Managing for Quality, Milwaukee, WI: ASQC Quality Press, 1995

253

RESOURCES BY CATEGORY

Jones, Capers. Applied Software Measurement. 3rd ed. New York: McGrawHill, 2008 Walton, Mary. The Deming Management Method. New York: The Putnam Publishing Group, 1986 SOFTWARE QUALITY ENGINEERING Daugherty, Taz. Fundamental Concepts for the Quality Engineer. Upper Saddle River NJ: Prentice Hall, 1992 Freedman, Daniel P & Gerald M. Weinberg. Handbook or Walkthroughs, Inspections, and Technical Reviews. New York: Dorset House, 2002 Galin, Daniel. Software Quality Assurance. Boston: Addison-­Wesley, 2004 Glass, Robert L. Building Quality Software. Upper Saddle River, NJ: Prentice Hall, 1992 Jones, Capers & Oliver Bonsignour. The Economics of Software Quality. Boston: Addison-Wesley, 2012 Kennett, Ron S. & Emanuel R. Baker. Software Process Quality. Atlanta: Dorset House, 1990 Tian, Jeff. Software Quality Engineering. Hoboken, NJ: Wiley Interscience, 2005 CONFIGURATION MANAGEMENT Aiello, Bob & Leslie Sachs. Configuration Management. Boston: AddisonWesley, 2011 Babich, Wayne A. Software Configuration Management. Boston: AddisonWesley, 1986 Berczuk, Stephen P. Software Configuration Management Patterns. Boston: Addison-Wesley, 2003 Martynov, Max & Krill Evstigneev. Continuous Delivery Blueprint. n.p.: Grid Dynamics, 2017

254

RESOURCES BY CATEGORY

STRUCTURED TECHNIQUES Barker, Richard & Cliff Longman. Case*Method, Boston: Addison Wesley, 1992 Demarco, Tom. Structured Analysis and System Specification. Englewood Cliiffs, NJ: Yourdon Press, 1978 Gane, Chris & Trish Sarson. Structured Systems Analysis.New York: Improved System Technologies, Inc. 1977 McGraw Karen & Karan Harbison. User Centered Requirements. Mahwah, NJ: Lawrence Erilbaum Associates Inc., 1997 Page-Jones, Meilir. Structured System Design. Upper Saddle River, NJ: Prentice Hall, 1988 Weaver, Audry M. Using the Structured Techniques. Englewood Cliffs, NJ: Yourdon Press, 1987 JOINT APPLICATION DESIGN / DEVELOPMENT August, Judy H. Joint Application Design. Upper Saddle River, NJ: Prentice Hall, 1991 Wood, Jane & Denise Silver. Joint Application Development. New York: Wiley, 1995

255

Resources by Author Abahamsson. Pekka et al. Agile Software Development Methods: Review and Analysis. Otamedia, Finland: VTT Publications 478, 2002 Adzic, Gojko. Bridging the Communication Gap. London. UK: Neuri, 2009 Adzic, Gojko. Specification by Example. Shelter Island. NY: Manning, 2011 Adzic, Gojko & David Evans. Fifty Quick Ideas to Improve Your User Stories. London. UK: Neuri, 2014 Aeillo, Bob & Leslie Sachs. Agile Application Lifecycle Management. Boston: Addison Wesley, 2016 Aiello, Bob & Leslie Sachs. Configuration Management. Boston: AddisonWesley, 2011 Ambler, Scott W. Agile Modeling. Boston: Addison-Wesley, 2011 Ambler, Scott W. Agile Database Techniques. New York: Wiley, 2003 Ambler, Scott W. & Larry L. Constantine. The Unified Process Inception Phase. Lawrence. KS: CMP Books, 2000 Ambler, Scott W. & Larry L. Constantine. The Unified Process Elaboration Phase. Lawrence. KS: CMP Books, 2000 Ambler, Scott W. & Larry L. Constantine. The Unified Process Construction Phase. Lawrence. KS: CMP Books, 2000 Ambler, Scott W. & Larry L. Constantine. The Unified Process Transition and Production Phases. Lawrence KS: CMP Books, 2002 Ambler. Scott W. & Mark Lines. Disciplined Agile Delivery. Boston: IBM Press, 2012 Ambler, Scott W. & Mark Lines. Choose Your WoW. Newtown Square, PA: Project Management Institute, Inc., 2020 Ambler, Scott W. The Object Primer 3rd ed. New York: Cambridge, 2009

© Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7

257

Resources by Author

August, Judy H. Joint Application Design. Upper Saddle River, NJ: Prentice Hall, 1991 Axelrod, Aron. Complete Guide to Test Automation. New York: Apress, 2018 Axelrod, Robert. The Evolution of Cooperation. Cambridge. MA: Basic Books, 1984 Babich, Wayne A. Software Configuration Management. Boston: AddisonWesley, 1986 Barker, Richard & Cliff Longman. Case*Method. Boston: Addison-­ Wesley, 1992 Beaty, Joy & Anthony Xhen. Visual Models for Software Requirements. Redmond, WA: Microsoft Press, 2012 Beck, Kent. Extreme Programming Explained. Boston: Addison-­ Wesley, 2000 Beck, Kent. Test-Driven Development. Boston: Addison-Wesley, 2007 Beck, Kent & Martin Fowler. Planning Extreme Programming. Boston: Addison-Wesley, 2001 Belzer, Borix. Software Testing Techniques 2nd Edition. New York: Van Nostrand Reinhold, 1990 Berczuk. Stephen P. Software Configuration Management Patterns. Boston: Addison-Wesley, 2003 Boehm. Barry W. Tutorial: Software Risk Assessment. Washington.DC: IEEE Computer Society Press, 1989 Boehm, Bary & Richard Turnet. Balancing Agility and Discipline. Boston: Addison-Wesley, 2003 Boutros, Tristan & Jennifer Cardela. The Basics of Process Improvement. Boca Raton. FL: CRC Press, 2016 Brooks Jr., Frederick P. The Mythical Man Month (Aniversary Edition). Boston: Addison-Wesley, 2006 Burns, Larry. Building the Agile Database. Westfield. NJ: Technics Publications, 2011 Chase, Stuart (ed). Language Thought and Reality: Selected Writings of Benjamin Lee Worf. Mansfield Centre, CT: Martino Publishing, 2011 258

Resources by Author

Chorafas, Dinitris N. Enterprise Architecture and New Generation Systems. Boca Raton. FL: St. Lucie Press, A CRC Press Company, 2002 Cockburn, Alistair. Crystal Clear. Boston: Addison-Wesley, 2005 Cockburn, Alistair. Writing Effective Use Cases. n.p: self, 2001 Cohn, Mike. Succeeding With Agile. Boston: Addison-Wesley, 2010 Cohn, Mike. User Stories Applied. Boston: Addison-Wesley, 2003 Crispen, Lisa & Janet Gregory. Agile Testing. Boston: Addison-­Wesley, 2009 Crosby, Philip B. Quality is Free. New York: McGraw-Hill, 1979 Daugherty, Taz. Fundamental Concepts for the Quality Engineer. Upper Saddle River. NJ: Prentice Hall, 1992 Davis, Alan M. Just Enough Requirements Management. Boston: AddisonWesley, 2011 Davis, Alan M. Software Requirements revision. Upper Saddle River. NJ: Prentice Hall, 1993 Davis, Jennifer & Katherine Daniels. Effective DevOps. Portland, OR: IT Revolution Press, 2013 DeMarco, Tom. The Deadline. Atlanta: Dorset House, 1997 DeMarco, Tom. Controlling Software Projects. Englewood Cliffs, NJ: Yourdon Press. A Prentice Hall Company, 1982 Demarco. Tom. Structured Analysis and System Specification. Englewood Cliffs, NJ: Yourdon Press, 1978 DeMarco, Tom & Timothy Lister. Peopleware 2nd Ed. Atlanta: Dorset House, 1999 DeMarco, Tom & Timothy Lister. Waltzing with Bears. Englewood Cliffs, NJ: Yourdon Press, 2004 Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Press, 1982 Deming, W. Edwards. The New Economics 2nd Edition. Cambridge, MA: MIT Press, 1994 Duval, Paul M. Continuous Integration. Boston: Addison-Wesley, 2003 Feathers, Michael C. Working Effectively with Legacy Code. Upper Saddle River, NJ: Prentice Hall, 2005

259

Resources by Author

Feigenbaum, Armand V. Total Quality Control 3rd Edition. New York: McGraw-Hill, 1961 Freedman, Daniel P & Gerald M. Weinberg. Handbook or Walkthroughs. Inspections. and Technical Reviews. New York: Dorset House, 2002 Galin. Daniel. Software Quality Assurance. Boston: Addison-­Wesley, 2004 Gane, Chris & Trish Sarson. Structured Systems Analysis. New York: Improved System Technologies. Inc., 1977 Gartner, Markus. ATDD by Example. Boston: Addison-Wesley, 2013 Gause, Donald C. & Gerald M. Wiesenberg. Exploring Requirements. Atlanta: Dorset House, 1989 Gilb, Tom. Principles of Software Engineering Management. Boston: Addison-Wesley, 1988 Glass, Robert & Ronald A. Noiseux. Software Maintenance Guidebook. Upper Saddle River. NJ: Prentice Hall, 1981 Glass, Robert L. Software Conflict 2.0. Atlanta: Developer*, 2003 Glass, Robert L. Building Quality Software. Upper Saddle River. NJ: Prentice Hall, 1992 Goldsmith, Robin F. Discovering REAL Business Requirements for Software Project Success. Norwood, MA: Artech House Inc., 2004 Gregory, Janet & Lisa Crispen. More Agile Testing. Boston: Addison-­ Wesley, 2015 Gregory, Janet & Lisa Crispen. Agile Testing Condensed. n.p: Leanpub, 2019 Grub, Penny & Armstrong A. Takang. Software Maintenance Concepts and Practice 2nd Ed. Toh Tuck Link. Singapore: World Scientific Publishing Co., 2003 Gurnsey III. Max. Test-Driven Database Development. Boston: AddisonWesley, 2013 Hall, Elaine M. Managing Risk. Boston: Addison-Wesley, 1988 Hammer, Michael. Beyond Reengineering. How the Process-­Centered Organization is Changing Our Work and Our Lives. New York: HarperCollins, 1996

260

Resources by Author

Hammer, Michael & James Champy. Reengineering the Corporation: Revised and Updated. New York: HarperCollins, 2003 Hay, David C. Requirements Analysis. Upper Saddle River. NJ: Prentice Hall, 2003 Heath, Fred. Managing Requirements the Agile Way. Liverey Place. Birmingham. UK: Packt Publishing, 2020 Highsmith, James A. Adaptive Software Development. Atlanta: Dorset House, 2000 Highsmith, Jim. Agile Project Management: Creating Innovative Products 2nd Edition. Boston: Addison Wesley, 2010 Hooks, Ivy F. & Kristin A. Farry. Customer Centered Products: Creating Successful Products Through Smart Requirements Management. n.p.: American Management Association, 2001 Humble, Jez & David Farley. Continuous Delivery. Upper Saddle River, NJ: Prentice Hall, 2005 Humphrey, Watts S. Managing the Software Process. Boston: Addison-­ Wesley, 1989 Hutterman, Michael. DevOps for Developers. New York: Apress, 2012 Huttermann, Michael. Agile ALM. Shelter Island, NY: Manning, 2012 Jacobson, Ivar et al. The Unified Software Development Process. Boston: Addison-Wesley, 2004 Johnson, Jim. My Life is Failure. West Yarmouth, MA: Standish Group International Inc., 2006 Jones, Capers. Applied Software Measurement 3rd Edition. New York: McGraw-Hill, 2008 Jones, Capers & Oliver Bonsignour. The Economics of Software Quality. Boston: Addison-Wesley, 2012 Juran, J.M. Juran on Planning for Quality. New York: The Free Press. A Division of Macmillan Inc., 1988 Juran, J.M. (editor in chief ). A History of Managing for Quality. Milwaukee, WI: ASQC Quality Press, 1995

261

Resources by Author

Karolak, Dale Walker. Software Engineering Risk Management. Los Alamitos, CA: IEEE Computer Society Press, 1996 Kennett, Ron S. & Emanuel R. Baker. Software Process Quality. Atlanta: Dorset House, 1990 Khorkov, Vladmir. Unit Testing. Shelter Island, NY: Manning, 2020 Kim, Gene & Jez Humble et.al. DevOps Handbook (first edition). Portland, OR: IT Revolution Press, 2016 Kim, Gene et.al. The Phoenix Project (revised). Sebastopol, CA: O’Reilly, 2016 Knaster, Richard & Dean Leffingwell. SAFe Distilled 4.5. Boston: AddisonWesley, 2011 Koskela, Lassse. Test Driven. Shelter Island, NY: Manning, 2008 Kroll, Per & Phillippe Kruchten. The Rational Unified Process Made Easy. Boston: Addison-Wesley, 1999 Kruchten, Pillippe. The Rational Unified Process An Introduction 3rd ed. Boston: Addison-Wesley, 2003 Kuhn, Thomas S. The Structure of Scientific Revolutions 3rd Ed. Chicago: University of Chicago University Press, 1996 Larman, Craig. Agile and Iterative Development. Boston: Addison-­ Wesley, 2004 Leffingwell, Dean. Agile Software Requirements. Boston: Addison-­ Wesley, 2003 Leffingwell, Dean. Managing Software Requirements 2nd Ed. Boston: Addison-Wesley, 2016 Lewis, William E. Software Testing and Continuous Quality Improvement. Boca Raton, FL: CRC Press, 2009 Lientz, Bennet P. & E. Burton Swanson. Software Maintenance Management. Boston: Addison-Wesley, 1980 Lines, Mark & Scott W. Ambler. Introduction to Disciplined Agile Delivery 2nd Ed. n.p.: self published, 2018 Martin. James. Rapid Application Development. New York: MacMillan Publishing Company, 1991 262

Resources by Author

Martin, James & Carma McClure. Software Maintenance. Upper Saddle River, NJ: Prentice Hall, 1983 Martin, Robert C. Clean Architecture. Boston: Addison-Wesley, 2018 Martynov, Max & Krill Evstigneev. Continuous Delivery Blueprint. n.p: Grid Dynamics, 2017 McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1988 McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996 McDonald. Kenty J. Beyond Requirements. Redmond, WA: Microsoft Press, 2013 McGraw Karen & Karan Harbison. User Centered Requirements. Mahwah, NJ: Lawrence Erilbaum Associates. Inc., 1997 Meters, Glenford J. The Art of Software Testing. New York: Wiley, 1979 Morgan, Tracy. Business Rules and Information Systems. Boston: AddisonWesley, 2002 Muggridge, Rick & Ward Cunningham. FIT for Integrated Tests. Upper Saddle River, NJ: Prentice Hall, 2005 Mugridge, Rick & Ward Cunningham. Fit for Developing Software. Upper Saddle River, NJ: Prentice Hall, 2002 Nagy, Gaspar & Seb Rose. The BDD Books: Discovery. n.p: self, 2021 Newkirk, James & Robert C. Martin. Extreme Programming in Practice. Boston: Addison-Wesley, 2001 Nicega, Knil. Writing Great Specifications. Shelter Island. NY: Manning, 2018 O’Donnel, Glen & Carlos Casanova. The CMDB Imperative. Upper Saddle River, NJ: Prentice Hall, 2009 Page-Jones, Meilir. Structured System Design. Upper Saddle River. NJ: Prentice Hall, 1988 Palmer, Stephan R. A Practical Guide to Feature Driven Development. Upper Saddle River, NJ: Prentice Hall, 2002 Paskal Greg. Test Guide to Automation in the Real World. n.p: self, 2017 263

Resources by Author

Patton Jeff. User Story Mapping. Sebastopol. CA: O’Reilly, 2014 Pigoski Thomas M. Practical Software Maintenance. New York: Wiley, 1997 Podeswa Howard. The Agile Guide to Business Analysis and Planning. Boston: Addison-Wesley, 2021 Podeswa Howard. The Business Analyst’s Handbook. Boston: Course Technology, 2009 Polo, Maricio. Mario Piatinni. Advances in Maintenance Management. Hershey, PA: Idea Group Publishing, 2003 Poppendiek, Mary & Tom Poppendiek. Lean Software Development. Boston: Addison-Wesley, 2003 Poppendiek, Mary & Tom Poppendiek. Implementing Lean Software Development. Boston: Addison-Wesley, 2007 Pugh, Ken. Lean-Agile Acceptance Test-Driven Development. Boston: Addison-Wesley, 2011 Rasmunusson, Jonathan. The Way of the Web Tester. n.p: Pragmatic Programmers, 2016 Reis, Eric. The Lean Startup. New York: Penguin Random House. LLC, 2011 Rose, Seb & Gaspar Navy. The BDD Books: Formulation. n.p: self, 2018 Ross, Ronald G. Principles of the Business Rule Approach. Boston: AddisonWesley, 2003 Ross, Ronald G. Business Rule Concepts 3rd ed. n.p: Business Rule Solutions LLC, 2009 Rossberg, Joachim. Beginning Application Lifecycle Management. New York: Apress, 2014 Royce, Walker. Software Project Management A Unified Framework. Boston: Addison-Wesley, 1998 Rubin, Kenneth S. Essential Scrum. Boston: Addison-Wesley, 2013 Ruping, Andreas. Agile Documentation. Boston: Addison-Wesley, 2000 Ruping, Andreas. Agile Documentation. Boston: Addison-Wesley, 2007 Sakai, Takao. The Secret Behind the Success of Toyota. n.p.: n.p, 2018

264

Resources by Author

Sampaio, Julio Cesar et al. Perspectives on Software Requirements. Norwell, MA: Kluwer, 2004 Schaeffer, Jeffrey et al. The Kitty Hawk Venture. New York: Apress, 2018 Schrange, Michael. No More Teams: Mastering the Dynamics of Creative Collaboration. New York: Doubleday, 1989 Schwaber, Ken. Agile Project Management with Scrum. Sebastopol, CA: O’Reilly, 2003 Schwaber, Ken & Mike Beedle. Agile Development with Scrum. Upper Saddle River, NJ: Prentice Hall, 2002 Stapleton, Jennifer. DSDM Dynamic Systems Development Method. Edinburgh, England. Pearson Education Limited, 1997 Stellman, Andrew & Jebbifer Greene. Applied Software Project Management. Redmond, WA: Microsoft Press, 2013 Stewart, John Ferguson. BDD in Action. Shelter Island, NY: Manning, 2015 Swanson, E. Burton & Emanuel R. Bakeh. Maintaining Information Systems in Organizations. New York: Wiley, 1989 Tarlinder, Alexander. Developer Testing. Boston: Addison-Wesley, 2017 Tian, Jeff. Software Quality Engineering. Hoboken. NJ: Wiley Interscience, 2005 Tillman, George. Project Management Scholia. n.p. Stockbridge Press, 2019 von Halle, Barbara. Business Rules Applied. New York: Wiley, 2002 Walton, Mary. The Deming Management Method. New York: The Putnam Publishing Group1986, 1986 Weaver, Audry M. Using the Structured Techniques. Englewood Cliffs, NJ: Yourdon Press, 1987 Weinberg, Gerald M. Quality Software Management. Volume 1: Systems Thinking. New York: Dorset House, 1992 Whitten, Neal. Managing Software Development Projects, 2nd Edition. New York: John Wiley & Sons, 1995 Wiegers, Karl & Joy Beatty. Software Requirements 3rd ed. Atlanta: Dorset House, 2005

265

Resources by Author

Winograd, Terry & Fernando Flores. Understanding Computers and Cognition. Reading, MA: Addison-Wesley, 1987 Withall, Stephen. Software Requirement Patterns. Redmond, WA: Microsoft Press, 2007 Wood, Jane & Denise Silver. Joint Application Development. New York: Wiley, 1995

266

Index A Acceptance test, 13, 14, 30, 60, 65, 66, 99, 109, 113, 115, 171, 214 Accounting, 97, 149, 158, 176, 180, 181, 219 Activities, 2, 4, 5, 8, 14, 33, 43, 45, 53, 54, 57, 70, 76, 77, 87, 127 Activity Cycle of DPAC, 192, 193 Act Phase Process Detail Cycle, 87 records, 79 requirements, 81 Unit Development Cycle, 90 Adaptive maintenance, 132 Administrative assistant selection, 49 Agent, 234, 236 Agile, 4, 5, 165 Agile DBA, 52, 87, 96, 117–119 Application design requirements, 68, 69 Architect, 52, 107, 134, 137 Architectural requirements, 211, 212 Architecture documentation, 212, 215 Assemble documentation, 235, 236, 239 © Robert F. Rose 2022 R. F. Rose, Software Development Activity Cycles, https://doi.org/10.1007/978-1-4842-8239-7

“As-you-go” documentation, 153 Attributes, 116, 140, 207, 210, 212 Audit and regulatory requirements, 83 Audits, 30, 181–184, 220 Automated testing, 110–112, 196, 197 Automation, 89, 110–112, 114, 115 Automation tools, 110, 114, 148, 194, 198

B Badge/bar code, 44 Biometrics, 44 Boehm’s risk management-driven spiral model, 162–165 Boehm’s top ten list, 163 Brooks’ law, 158 B2C applications, 196 Bugs, 18, 19, 30, 130–132, 155 Bureaucratic impediments, 130–132 Business analysis, 223 Business analyst, 7, 49, 50, 55, 57, 61, 63–65, 73, 74, 80, 81, 84, 87, 174, 178, 183, 193, 194, 200, 217, 218 267

INDEX

Business Rule and Requirements Review, 6, 87 Business rules, 63, 64, 66, 68, 79–82, 87, 88, 91, 136, 159, 175, 213 business definitions, 83 data constraints, 84 data integrity, 83 decision tables, 82 dependencies, 83 drop-down values, 82 inspection checklist, 85, 86 look up values, 82 operational requirements, 82 perspective, 86 process flow, 83 requirements, 85, 86 review, 57, 84 review panel, 84, 85 rule-based constraints, 83 UI testing, 81 Business to Customer (B2C), 196

C Cache and memory management, 67, 93 Capacity Maturity Model Integration (CMMI), 14 Capture Hardcopy, 240 Champion project, 37, 54, 57, 62, 73, 151, 152 Change Advisory Board (CAB), 5, 6, 63, 73, 96, 179 268

Change Control Board (CCB), 5, 73 Change Reports (CRpts), 5–7, 63, 73, 79, 89, 96, 178–180 Change request (CR), 5, 73, 104 Claim level 1, 237, 243 Claim level 2, 237, 239 Claims Department Information Image Processing Subs-­System, 241, 242 Claims management, 234 Claims processing system, 233, 235 Clean code, 30, 136, 169, 215 Client and Policy information, 243 Client profile, 233, 234 Code-check software, 94 Code inspections, 30, 99, 113, 183, 219 Code version control, 180, 219, 225, 230 Code Walk, 212, 215 Coding Stage, 131 Commercial off-the-shelf (COTS), 40, 233, 243 Commitment, 28, 59, 164 Communication/collaboration tools, 67, 164, 199 Compatibility, 41, 43, 102, 208, 210, 212 Component Development Cycle, 3, 4, 6, 9, 14 Computer security, 44, 45 Configuration Inventory Database (CMDB), 73, 177

INDEX

Configuration Management (CM), 91–94, 115, 137, 160, 170, 176–179, 223, 224 CMDB, 177 item naming conventions, 177 plan, 215 roles and responsibilities, 7, 8 Configuration Management Database (CMDB), 7, 19 components, 71, 72 representational view, 71 requirement record, 70 test case record, 70 tools, 70 Configuration Manager (CM), 57, 120 Consensus, 36, 38, 53, 58, 59, 150, 152, 160, 164 Construction Stage, 68, 174, 183, 196 business rules, 84–90 cycles of activity, 77 Process Detail Cycle (see Process Detail Cycle) staffing, 101–104 Unit Development Cycle (see Unit Development Cycle) Contact database, 241 Contact record, 233, 234, 244 Context Diagram, 174, 235, 236 Continuous Delivery (CD), 109, 110 Continuous Integration (CI), 95, 109, 110

Contracting Officer’s Technical Representative (COTR), 66, 149, 151 Conversion plan, 64, 186, 187, 220, 224, 226 Corrective maintenance, 132 Cosmetic standards, 188, 189 Cost-benefit analysis, 111, 163 Costs, 18, 19 proportional distribution, 22 software support, 25 of support, 21 Cryptic numbers, 155 Culture clash, 32 Cyberattack, 48, 166, 168

D Database administration (DBA), 55, 157, 173, 224, 225 Agile, 56 librarian, 56 Database Design Document, 169, 212, 215 Database version management, 157 Data constraints, 84 Data dictionary, 91, 120, 215, 242–244 Data flow diagram (DFD), 5, 10, 48, 53, 117, 173 construction stage, 174 context diagram, 174 data dictionary, 242–244 269

INDEX

Data flow diagram (DFD) (cont.) elaboration Stage, 174 goal, 234 guideline, 173 legal and illegal combinations, 229 principles, 231, 232 process, 234–242 Process Detail Cycle, 174 superior process performance, 232 symbols, 227, 228 Data integrity, 46, 47, 83 Data Modeler, 8, 52, 64, 96, 120, 221 Data Processing, 129, 191, 200 Data-related quality engineering, 185 Datastores, 230 Decision tables, 82 Decomposition, 84, 230 Dependencies, 10, 11, 53, 58, 83, 214 Deployment Cycle development, 125, 126 rectification of errors, 124 repair or correction, 124 UAT, 124 Design approval, 60 Designers, 203 Designer tool, 154 Design requirements, 68, 69 Design review, 59

270

Development model (See also Support) cost, 18, 19 political and social capital, 32 problem statement, 17, 18 software system improvement, 28–32 support in equation, 20–24 Development process activity cycles (DPAC) activities represented, 5–9 Agile, 4, 5 assembly stage, 12, 13 construction stage, 11, 12 DevOps, 4, 5 elaboration stage, 10, 11 inception stage, 9 and PDCA, 3, 4 Development stages and activity cycles, 9 Development team (Dev Team), 6, 7, 10, 16, 32, 38, 45, 63–66, 71–74, 76, 90, 105, 117, 129, 138 DevOps, 4, 5, 137 agile development, 19 and the Database, 120, 121 engineers, 113–115 operations, 13 quality payoff, 20, 21 Digital Quality Control, 237, 240, 241

INDEX

Discrepancy Reports (DRs), 7, 70, 178, 185 Documentation, 124, 170, 172, 173 Documentation Block (DocBlock), 243 Documentation quality problems (DOC), 26, 27, 29 Document Capture Section, 240 Document control, 8, 56, 195, 217, 224 Do Phase, 55, 79 DPAC activity cycles, 192, 193 DPAC model Lehman’s laws, 142 SOE, 115, 116 SOR, 115, 116 DPAC model, see Development process activity cycles (DPAC) “Drop-down” values, 82 Dynamic integrity, 12

E Elaboration stage, 50, 52, 183, 196 CMDB (see Configuration Management Database (CMDB)) DBA (see Database administration (DBA) description, 53 design requirements, 68, 69

design review, 59 DFD (see Data flow diagram (DFD)) FRS, 58, 59 ongoing activities, 56, 57 other activities, 57, 58 Process Overview Cycle (see Process Overview Cycle) requirements prioritization, 59, 60 roles and responsibilities, 62–66 Electronic Data Systems (EDS), 153 Email server, 112, 137 Embedded Systems, 191 Enabling Software, 191 Enhancements, 126, 128, 133 Entity, 227, 228, 230 Entity Relationship Diagram, 8, 136, 221 Error and conflict management, 93, 212 Error correction, 130, difficulties, 132–135 Errors, 203, 204 Essential tools, 199, 200 Event management, 67 Evolution stage, 14–16, 131, 137, 138 Exception management, 67 Exhibit database, 235, 240 External requirements, certification, 84

271

INDEX

F Fault tolerance, 93, 209 Federal Information Security Modernization Act (FISMA), 44 Fix Gaps, 158, 159 Foreign keys, 74 Freeing the statue from the stone, 24, 25 Fulfillment processes, 231 Full-time equivalents (FTE), 59 Functional requirements specification (FRS), 10, 53, 58, 59, 101, 243 Functional suitability, 207, 208, 210 Functioning model demonstrating system architecture, 182

G Grand Totals, 220, 221 Guidelines, 8, 175, 183, 188, 218

H “Hands-off” management approach, 91 Hardcopy documents, 237, 240 Hardware Configuration Inventory (HWCI), 64, 178, 179 Help desk, 42, 73, 127 Higher-severity development problem factors, 27 High-level process diagram, 136, 211 272

Hiring process, 103 initial roles, 61 roles added, 61 rules of the road, 62 Human resources, 158

I Image database, 235 Image labels, 242 Implementation types, 192 Inception stage, 9, 61, 172, 173 information security, 43–48 objectives, 36, 37 privacy, 45–48 requirements traceability matrix, 38–40 security activities, 43 staffing, 48–52 system security, 43–48 Vision Statement, 37, 38 Incident data, 235 Individual units of code, 87 Information Processing, 200 Information security, 43–48 Information Systems, 191 Information Technology Infrastructure Library (ITIL), 70 Information Technology Intelligence Consulting (ITIC), 19 Infrastructure as a Service (IaaS), 113

INDEX

Input testing, 93, 212 Inspecting requirements, 18, 24, 92 Inspection checklist, 85, 86, 136 Inspections, 97–102 Insurance, 153, 178, 233 Integration of test cases, 118 Integration Stage, 109, 131 Interface, 67, 126, 151 International Council on Systems Engineering (INCOSE), 176 International Organization for Standardization (ISO), 207–211 ISO 25010, categories, 207–211 ISO 9000 (2000), 171 Iterative development, 75, 94 Iterative paths, 14 IT Program Manager, 50

J, K Joint Application Development (JAD), 38, 74, 75

L Lead Business Analyst, 57, 81, 174, 218 Lead programmer, 52, 61, 102, 195 Lead Tech, 32, 57, 60, 63, 115 Lead tech and system architect, 57, 60 Lead tester, 50, 57, 102, 185, 192 Legacy systems, 21, 192

Lehman’s laws, 138–142 Leveling, DFD, 230 Librarian, 179, 224 Lines of program code (LOC), 197 Load testing, 111, 212, 214 Log of test results, 185

M Maintainability, 209 Maintenance, 25–28 Management Information System (MIS), 14, 115, 155, 191, 196 Manual Document Storage, 240 “Mechanical” testing, 93 Migration plan, 187 Modification request, 127

N National Client Profile and Policy System, 234 National Institute of Standards and Technology (NIST), 18 Network administrator, 45, 65, 178 Non-functional requirements, 36, 40, 52, 57, 83, 84, 179 Numbered Processes, 127, 230

O Object-oriented languages, 154 Office Productivity software, 191 Operating backbone, 68 273

INDEX

Operations, 45, 124 Oracle, 67 Oracle Designer, 155 Ownership team, 66, 67

P Perfective maintenance, 133 Performance efficiency, 208 Performance testing, 111, 195 Permanent Support Team, 129 Persistence, 67 Personally identifiable information (PII), 44, 45 Personnel resources problems (PER), 26, 28 Plan, Do, Check, and Act (PDCA), 3, 4, 193 Platform as a Service (PaaS), 113 Political dimension, 151 Portability, 210 Power of Three, 101, 127 Preliminary database design, 227, 242, 243 Privacy, 45–48 Procedures, 218 Process automation tools, 199, 214 Process Detail Cycle, 4, 11, 14, 174, 183, 193, 244 Act Phase, 87 goal, 79 roles and responsibilities, 80, 81 SMEs, 79 Process Discrepancy Reports, 185 274

Process management problems (PM), 26, 28 Process Overview Cycle, 14, 196 Act phase, 55 business rules, 54 check phase, 55 Do phase, 55 lower levels, 54 PLAN phase, 54 Process Quality Assurance task, 8, 62, 63, 89, 95–97, 185, 187 Product quality model, 207 Products, 191, 208, 209 Program error, 203 Program Manager, 49, 50 Programmer pairs, 194, 195 Programmers, 8, 80, 160, 188 Programming, 57, 64, 187–189 Programming quality problems (PGM), 26, 27, 29–32 Program specification, 153, 154 Project management and administration, 8 Project Manager (PM), 48–52, 54, 151, 180 additional responsibilities, 57 developer team, 48

Q Quality Assurance requirements, 160 Quality control area, 211 Quality engineering, 170, 187–189 Quality payoff, 20, 21

INDEX

R Recoverability, 41, 93 Regression test, 110, 112, 142 Relational Database Management System (RDBMS), 67, 191 Reliability, 152, 209 Requirements cycle, 14 Requirements engineering (RE), 38 Requirements prioritization, 59, 60, 86, 87 Requirements Stage, 131 Return on investment (ROI), 110, 130 Review Panel, 84, 85 Risk management key person loss, 152, 153 missing overview, 156, 157 missing tools, 155 necessary elements, 164 optimistic level, 158 quality engineering measures, 156, 157 risk factors, 160, 161 skills, lack, 159, 160 software development, 151 “window of opportunity”, 150 Robustness, 168, 214 Roles and responsibilities development team, 62–64 initial roles, 61 ownership team, 66, 67 roles added, 61 rules of the road, 62 Service Assembly, 112, 113

Royce, Winston W., vs. waterfall 200–205 Rube Goldberg’s model, 2 Rule-based constraints, 83 Rules of the road, 62

S Satellite Early Warning System, 200–205 Security, 43, 209 Security considerations, 57, 212, 214 Security consultant, 51, 52, 65, 87 Security management concerns, 45–47 Security requirements, 37, 48 Service Assembly Agile DBA, 117–119 automation of testing, 110–112 CD, 109, 110 CI, 109, 110 cycle, 108 definition, 108 DevOps, 120, 121 DevOps engineers, 113–115 roles and responsibilities, 112, 113 and System Integration Cycles (see System Integration Cycles) test cases, 109 test data, 116, 117 user’s guide, 108 275

INDEX

Service Assembly Cycle, 3, 9, 65, 92 Service-Level Agreements (SLAs), 127 Services of the system, 236 Shared system functions, 68 Sign off, 12, 59, 68, 76, 243 Sign on, 76, 108, 243 Simple staged model, 143 Snippet, 154 Software configuration inventory (SWCI), 7, 73, 170, 177, 215 Software Configuration Management (SCM), 176–179 Software Development Life Cycle (SDLC), 205 Software Development Notebook (SDN), 153, 154 Software development problems, 26, 27 Software development process, 8, 20, 26, 48, 162 Software evolution, 137–139 Software maintainability, 28–32 Software Quality business rule, 213 change control, 179, 180 CM, 176–179 components, 170 CRpts, 178 DFD (see Data flow diagram (DFD)) documentation, 172, 173 DRs, 178 HWCI, 178–180 276

ISO (see International Organization for Standardization (ISO)) maintenance, 169–171 quality engineering, 187–189 robustness, 168 SQA (see Software Quality Assurance (SQA)) status accounting, 180 TDD, 183, 184 test, 183 usability requirements, 213 user-friendly, 168 user needs, 168 Software Quality Assurance (SQA), 8 baselined requirements, 181 integrity of pointers, 174 life cycle, 171 and test, 225, 226 test readiness reviews, 184 Universal documentation standard, 172 Software requirements specification (SRS), 11 Software support, 129, 130, 134 Software support life cycle (SMLC), 142, 143 Software, types, 191 Solidification, 117 Spiraling cycles, 78 Staffing, 48–52, 56, 61–67, 101–104, 194, 195, 243 Staffing pattern, 49, 51

INDEX

Stakeholders, 36 buy-in, 152 goals and objectives, 36 vision, 36 Standard for Program Specifications, 153 Standards, 175, 188, 217, 218 Status accounting, 176, 180 Stress testing, 111 Structured Analysis and System Specification, 227 Structured programming, 58 Structured systems analysis, tools and techniques, 227 Subject matter experts (SMEs), 37, 39, 72, 80, 159, 174 Support, 20–24, 48 Support Cycle, 193 activities, 126, 127 bureaucratic impediments, 130–132 description, 126 error correction, 130 error correction difficulties, 132–135 Lehman’s laws, 138–142 limited understanding, 135, 136 number of processes, 127 permanent support team, 129 and practices, 127 SMLC, 142, 143 software, 129, 130 technical challenges, 136, 137 version staged model, 144–147

Support operations, 60 Support table, 73 Symbol set, 227, 228 Synthetic test data, 116 SysAdmins, 114, 115 System architecture, 67, 137, 148, 182 System Integration Cycles, 4, 13, 14, 48, 107, 108, 115, 121 System requirements problems (SYS), 26, 28 System requirements specification (SRS), 58, 59 System security, 43–48 Systems of Engagement (SOE), 109, 115, 116, 191 Systems of Record (SORs), 109, 115, 116, 191, 196 System-wide procedures, 182

T Technical challenges, 136, 137 Technical management, 7, 151 Technical Project Manager, 50, 151, 152 Technical Review Subcycle, 94, 95, 98, 108 Tech-Programming, 225 Telecommuting, 44 Telephone Effect, 101 Telephony equipments, 137 Test, 171, 183, 226 277

INDEX

Test automation, 110–112 Test Cycle, 14 Test data generation, 111 Test Data Management, 116, 117 Test-driven development (TDD), 12, 30, 95, 98, 183, 184 Tester, 132, 160, 194, 195 Testing Stage, 131 Test matrix, 100 Test Plans, 91, 94, 148 Test protocols, 8, 15, 184 Tools, 195, 196 automated testing, 196, 197 costs, 198 essential tools, 199, 200 methodology, 198 Tool-scape, 197, 198 Total cost, 18, 19 Traceability matrix, 7, 15, 19, 31, 36, 136, 156, 159, 215 backward direction, 39 contents, 74 context of test, 39 elements, 178, 179 foreign keys, 74 forward direction, 39 JAD, 74, 75 maintenance programmer, 39 objectives, 39 simplified visual representation, 40 SQL queries, 74 Vision Statement, 39

278

Transition, 113, 120, 127 Triad principle essential roles, 104 staffing, 101–104 Tribal knowledge, 147–149, 160 Trip wire, 45 True to requirements, 95, 97

U Unit Development Cycle, 77, 78, 92, 93, 108 Code-check, 94 configuration management, 91–94 CRpts, 88, 89 Deming formula, 88 inspections, 97–102 iterative development, 94 phases, 88 sub-cycle, 94 test plans, 94 version control, 89 Units of code, 92, 108 Unit Test Part, 98 Universal documentation standard, 172 Usability, 208, 213 User Acceptance Test (UAT), 91, 109, 124 User-friendly, 168, 169 User interface (UI), 81, 98, 168 User Review, 6, 98, 108, 115

INDEX

V

W, X, Y, Z

Version control, 89, 170, 173, 176, 180 Version control tools, 60, 199 Version staged model, 144–147 Vision Statement, 38, 39, 152, 156, 168, 183, 211, 233

“Waterfall”, 200–205 “Window of opportunity”, 150 Workshops, 75, 76

279