AppSys-SDM Concepts and Practices_v0-02

System Development Methodology
Concepts and Practices
For Application System Development
Document Name: AppSys-SDM Concepts Practices_v0-02.doc
Revision Number: 0.02
Revision Date: December 20, 2013
Author: Raymond W. Wong
No Copyrights in effect

System Development Methodology – Concepts and Practices For Application Systems
Page: 1 / 57
TABLE OF CONTENTS
CHANGE HISTORY.................................................................................................................................................................... 3
PREFACE................................................................................................................................................................................... 4
PURPOSE OF THIS WRITING........................................................................................................................................................5
DEFINITION OF INITIAL TERMS................................................................................................................................... 6
Term / Acronym...................................................................................................................................................................6
Definitions........................................................................................................................................................................... 6
RELATED DOCUMENTS.............................................................................................................................................................. 7
PART 1: OVERVIEW OF SOFTWARE SYSTEM DEVELOPMENT METHODOLOGY (SDM)......................................................... 8
1.1 - OVERALL GOALS OF APPLICATION SOFTWARE SYSTEM DEVELOPMENT METHODOLOGY (SDM).................................................8
1.2 - THE ORDINAL NATURE OF APPLICATION SOFTWARE SYSTEM DEVELOPMENT.......................................................................... 9
1.2.1 - Initial Application Development Project............................................................................................................9
1.2.2 - The Importance of "Build Order" for Subsequent Change Layers.....................................................................9
1.3 - SDM’S BACKBONE CONCEPTS: “BUILDING FROM KNOWN SOURCE” AND “SYSTEM PROMOTION (GATING)”.11
1.3.1 - Building (the Application’s Software Content) from Known Source (BKS):...............................11
1.3.1.1 - The BKS Process: Applying Project Groups to Reach Desired Software Content:.................................................11
1.3.1.2 - Example: The Basic BKS Build Sequence....................................................................................................................13
1.3.1.3 - Why Automate Software Installation?...........................................................................................................................16
1.3.1.4 - Goals and Benefits of Building from Known Source (BKS).........................................................................................16
1.3.1.4.1 - Goal #1 of BKS: Control and Consistency of Application Software Content.................................17
1.3.1.4.1.1 - Theoretical BKS – Complete Build:................................................................................................................17
1.3.1.4.1.2 – Actual (Usual) Practice BKS – Build from Baseline:......................................................................................17
1.3.1.4.2 - Goal #2 of BKS: System Promotion (Gating).......................................................................................... 17
1.3.1.4.3 - Goal #3 of BKS: To Make “Known” the Software Content of Application System.......................18
1.3.1.4.4 - Goal #4 of BKS: To Provide a Framework for the System Development Life Cycle.................... 20
1.3.1.5 - Sample BKS Based System Development Life Cycle (SDLC).....................................................................................21
PART 2: - SDM OPTIMIZATION AND QUALITY TOPICS......................................................................................................... 25
2.1 - AGILE SDM - VARIATIONS ON THE SYSTEM DEVELOPMENT LIFE CYCLE...................................................................................25
2.2 - PROJECT MANAGEMENT: MANDATE TO AVOID "SCOPE CREEP" IN BKS SDM ENVIRONMENT...................................................27
2.2.1 - The "Change Request Project" as the Proper Channel for Project Redirection..............................................27
2.2.2 –The Fallacy of “ Scope Creep” as a "Feature" of Agile SDM Project Management........................................27
2.2.2.1 - Unrealistic Expectations of "Agile" OOP Development.................................................................................................28
2.2.2.2 - Allowing "Scope Creep" Undermines the Basic Goals and Metrics of Project Management....................................... 29
2.2.2.3 - BKS/System Promotion Based SDM Assumes Fixed Project Scope...............................................................................29
2.2.2.4 - Real Quality verses Unprofessional and Absurd Expectations......................................................................................30
2.2.2.5 - SAF Rapid Software Inc. Verses PDM Systems, Inc........................................................................................................31
2.3 - THE QUALITY MANUAL................................................................................................................................................... 33
2.3.1 - Link to Quality Manual Definition:..................................................................................................................34
2.3.2 - Programming Guide in the BKS Environment..................................................................................................35
2.3.2.1 - Standards from the Programming Language and Operating System Platforms........................................................... 35
2.3.2.2 – Standards from the Application's Own Programming and Configuration Guidelines..................................................35
2.3.2.3 - Requirements from the Software DBA (SDBA) to support BKS builds.......................................................................... 36
2.3.2.3.1 – SDBA Coding Standards - MAKE File................................................................................................................... 36
2.3.2.3.2 – SDBA Coding Standards - One-Time Set-Up Facilities........................................................................................ 36
2.3.2.4 - Standards from the Local BKS-SDM Development Environment.......................................................................... 37
2.3.2.4.1 - Source Code Format (as ASCII Text) for Library Storage.....................................................................................37
2.3.2.4.2 - Internal Program Documentation........................................................................................................................38
SUMMARY:.............................................................................................................................................................................39

Page: 2 / 57
APPENDIX A: THE ELEMENTS OF BKS:.................................................................................................................... 40
A1: THE SOFTWARE LIBRARY:.................................................................................................................................................. 40
A1.1 - Project Library Group Data.............................................................................................................................. 40
A1.2 – Library Structure and Project Group Maintenance......................................................................................... 41
A2 – THE SOFTWARE CONTROL SYSTEM (SCS)..........................................................................................................................43
A2.1 SCS Utilities to Service Programming Development.......................................................................................... 43
A2.2 SCS Utilities to Manage Application Software Content..................................................................................... 43
APPENDIX B: PROJECT DOCUMENTS WITHIN SDM: TRADITIONAL VERSES AGILE............................................................ 45
Project Document Optimisation:.................................................................................................................................45
Typical Project Documents in the System Development Life Cycle............................................................................45
APPENDIX C: VARIANT STREAM (MULTIPLE DEVELOPMENT PATH) DEVELOPMENT......................... 52
INTRA-RELEASE (ALL WITHIN ONE RELEASE) VARIANT STREAM CO-ORDINATION............................................................................... 52
INTER-RELEASE (PROJECTS SPREAD OVER TWO OR MORE RELEASES) VARIANT STREAM CO-ORDINATION.............................................. 53
APPENDIX D: SERVICE BUREAU SHELL SOFTWARE SUPPORT CONSIDERATIONS.............................................................. 54
THE DILEMMA OF CLIENT SPECIFIC CUSTOMISATION IN MULTI-CLIENT ENVIRONMENT:......................................................................54
The SBS Approach to Client Specific customisation - Software Licensing..................................................................54
APPENDIX E: SOFTWARE DEVELOPMENT IN THIRD PARTY APPLICATION VENDOR ENVIRONMENT............................... 56

Page: 3 / 57
CHANGE HISTORY
Revision Date Author Description
0.01 Dec 8, 2013 Ray Wong First draft
0.02 Dec 13, 2013 Ray Wong Minor Edits




Page: 4 / 57
PREFACE
When new IT technologies and buzzwords are showcased before a mass audience, they are often perceived
as almost magical solutions where alleged results and benefits are expected within weeks after subscribing to
the technology. Realistically, these new technologies should be viewed for what they are - simply tools that
require proper understanding of the tool's behaviour, benefits, resource requirements and other
prerequisites, before they should even be considered.
For instance when the first wide-audience demonstrations of Relational Databases debuted, people
envisioned themselves issuing data mining queries of almost infinite variation and receiving instant results all
without any IT Department assistance and development effort. The excitement created by the "Relational"
buzzword had many companies diving headlong into this arena only to face harsh realities. These included
the daunting, enormously costly and inevitable task of legacy database cleanup and normalisation, the
complex and often difficult decisions in database design, the enormous task of adapting and converting
existing applications to interface with the new relational database management system (RDBMS).
Additionally, there’s the need to hire and integrate a full time database administrator (DBA) into the system
development life cycle (SDLC), and to consider the time and costs related to the staff learning curve
associated with the getting up to speed with the RDBMS provider’s platform.
Agile SDM: Making Traditional Software Development Methodology Look Staid
Another technology that has also stirred the imagination has been Agile Software Development Methodology
(Agile SDM). Agile SDM has streamlined the traditional System Development Life Cycle (SDLC) by leveraging
object-oriented development and rapid prototyping. Agile SDM has piqued the imagination of IT
Department management and spawned many seeds of positive and long overdue changes within software
system development methodology (SDM).
However some have misinterpreted the “Agile” buzzword by making the assertion that Agile SDM gives
license to abandon core SDM controls and structures, disdainfully dismissing these controls as “legacy”
methodology.
This impetuous assertion is a failure to recognise that Agile SDM is merely a set of tools and methods that
offer improvements to help expedite certain phases of core software System Development Methodology
(SDM). Agile SDM was never meant as a replacement for the core practices and principles of SDM. (A
comparison between Agile and traditional SDM will be discussed later in this document.)
Whenever inconsistent and disinterested use of core SDM practices takes place, the associated software
control systems become incomplete, unreliable and out-of-sync with the actual software content of the
supported application. As a result, faith and use of these controls erode, and eventually these core controls
are abandoned. The most critical effect of this ruination, is the abandonment of the consistent use of the
source code library. With the abandonment of the Library as the centralised source code manager, source
code management becomes anarchic and “de-normalised” (spread out and with duplication). Soon, Project
Managers (typically on contract with deadlines to meet) typically take matters into their own hands by
hoarding and managing their own source code within their own flash drives, private to their own projects.
In this decentralised uncontrolled development environment, once a project has completed unit testing, the
Project Manager will typically deem their project closed and will hand the code to the company before

Page: 5 / 57
dismantling the project team. Checking in code to the Library is now performed for no other known purpose
other than as a token formality.
Later, within a few days before the release date, release management typically discovers different versions of
the same program from separate projects (that typically have been separately managed). In a last minute act
of desperation, the disparate project modifications that were made upon the common programs are quickly
merged into single combined versions. The new and untested code is then slid back into the affected project
code packages that contained that program. Due to the fact that the original code packages are already
checked into the Library, these covertly performed, last minute changes are not checked into the Library and
therefore are not tracked as to the code’s whereabouts.
With such uncontrolled, decentralised and flawed source-code management, along with haphazard
installation methods, the inevitable happens: the software content of the Application system soon becomes
“unknown” to everyone.
In this state, Application support becomes next to impossible because support staff can neither ascertain the
source code version for any program within the Application, nor can they locate the corresponding source
code (that may or may not be in the Library). Additionally they do not have any record of how the software
was applied. Were the individual projects installed out of order? Was there any specific order in the first
place?
Without really knowing the software content of their test systems and how the systems were built, Quality
Assurance will no longer be able to guarantee that the behaviour of the system in which they performed their
tests, will be replicated in Production. Without being able to make this basic guarantee, QA itself then
becomes invalidated. The inevitable result is the eventual crippling of the IT Department’s ability to support
the Application System.
Purpose of this Writing
The purpose of this write-up is to describe the very basic elements, concepts and flow of proper Software
Development Methodology (SDM) as it applies to the development and support of Application Systems by an
IT Department. This core SDM must persist regardless of whether the SDM works within an "Agile" (object
oriented), or a "traditional" (procedural language) SDM environment. These concepts have been gleaned
from ISO 9001/9000-3 standards for application system software development.

Page: 6 / 57
DEFINITION OF INITIAL TERMS
While there will be several new terms introduced later, some basic terms bear clarification at the outset in
the context of this document:
Term / Acronym Definitions
IT Department The software application (or “Information Technology”) system
development company or department within a parent company. The IT
Department usually consists of management and staff pertaining to its
various business units such as: Marketing, Business Analysis, Project
Management, Programming, QA, Documentation (Technical Writing),
Special Teams, Implementation, Systems and Operations. The IT
Department’s main deliverables are software systems pertaining to the
Application system(s) it supports and delivers.
Software System Software Systems are the basic deliverables of an IT Department. “Software
System” has two connotations:
In its holistic sense, "Software System" can refer to the entire Application
system consisting of the entire software set along with its supporting
documentation.
Alternatively, "Software System" can also refer to the code and
documentation set that represents a change (or an add-on) to the
Application. The “change” can be either in the form of an added sub-
system, an enhancement, or a bug fix (error correction), for the main
Application.
Project Each Software System (yes even one-line bug fixes) are created and
managed under the umbrella of its own individual “project” each with its
own unique project number. Each project is accompanied by its own project
documentation (e.g. full system documentation, enhancement or change
request documentation, or bug fix type documentation). As projects, each
Software System is developed, QA tested, and installed to Production,
under normal project management. The source code and documentation
for each Software System is stored in the Software Library as a project
related Library Group, where each element within the project is under
version control. By this permanent linking of project documentation with
its source code, the project helps to not only define the nature and
functionality of the software deliverables, but more importantly, the
project helps to: a) define the scope (limits) of work, b) to provide a
development management unit, c) to localise and track costs, and progress
within the confines of the project, d) to ensure uniform project
documentation and to link this documentation to the actual software
changes.
The Project Number is a crucial identification key throughout most phases
and aspects of the system development life cycle (SDLC)..

Page: 7 / 57
Library The storage and control area for source code and files . See “A1: The
Software Library“ within Appendix A below for description of the Source
Code Library.
Software System
Development Methodology
(SDM)
The set of basic methods, concepts, standards and tools used in the
development of software systems, many as prescribed by ISO 9001
standards for software system development. Much of this write-up is
devoted to SDM.
Software System
Development Life Cycle
(SDLC)
The SDLC is the individual IT Department’s actual implementation of SDM
principles and concepts. The SDLC describes the phases and steps of each
project’s development within a particular IT Department. Due to the
variances in types of business application, working environment and
technical platforms used by each individual IT department, one company’s
SDLC implementation may differ somewhat from the SDLC of another firm.
However, no SDLC implementation can be viable unless it adheres to core
SDM principles.
Related Documents
Document Name Version / Date Location
ISO 9000-3 A Tool for
Software Product and
Process improvement,
Kehoe, Raymond, Jarvis, Alka
1996,XIII
ISBN 978-0-387-94568-2
http://www.springer.com/computer/swe/book/978-0-387-94568-2
What is Quality Manual-
Mapwrite ISO9001 Solutions,
Practical and Effective
Jane Bennett, 2013 http://www.mapwrite.com.au/quality_manual.html
ISO9001 in Plain English –
Craig Cochran
2008,
ISBN-13: 978-932828-20-7
http:/www.amazon.com/9001-Plain-English-Craig-
Cochran/dp/1932828206/ref-sr_1_1?ie=UTF8&qid=1386561131&sr=8-
1&keywords=iso9001
Configuration Management
and ISO 9001 – Robert
Bamford, William J. Deibler II
http://www.methodsandtools.com/archive/archive.php?id=36

Page: 8 / 57
PART 1: OVERVIEW OF SOFTWARE SYSTEM DEVELOPMENT METHODOLOGY (SDM)
1.1 - Overall Goals of Application Software System Development Methodology (SDM)
The overall goals of SDM for Application system development are fairly obvious – to deliver Application
Software Systems to End-User/Clients by meeting their real IT needs and their basic requirements in an
efficient, reusable, well constructed, maintainable, bug-free and timely manner. To this end, SDM involves
these basic tasks:
 To accurately and efficiently clarify, define and document the User's Requests and Needs (Documents:
Client’s Request for Proposal (RFP)), User Needs and/or Requirements, Prototype Model document)
 To do cost, time and business justification analysis, capacity planning, prioritisation, Project Team creation,
Release Scheduling.
 To Respond with due diligence to the Client's RFP and receive Client signoff to take the project to
completion. (Documents: Response to RFP containing: Overview of System Deliverables, Cost Estimates,
and Estimated Release Dates)
 To accurately and effectively describe the software system deliverables that the client is to receive - that is
the actual definition (and legal contract) of work. (Document: the Functional Specification)
 To design and develop the system deliverables in a manner that optimises the sometimes conflicting
criteria of: a) consistent and optimal compliance to the Functional Specification and real User Needs, b)
optimisedperformance and efficiency, c) inclusion of design for future expansion and change, d) module
(object) reusability, e) readability and supportability (structured readable code), and f) compliance,
conformity and optimisation to the existing architecture and norms (i.e. conformity to the programming
standards) of the Application, the language platform standards and the local programming standards of the
IT Department. (Documents: Source code, MAKE Scripts, Design Specifications, Unit Test Log,
Programming Guide)
 To perform Quality Assurance Testing (which includes Unit, System, Regression, Negative, Integration, and
Limits Tests (where applicable as per QA standards) on the new system deliverables. The goal is to ensure
that the system works as described in the FS, and does so in a fault free manner without unexpected
negative impact on other portions of the core Application System. (Documents: QA Test Plans, Test Results,
Approvals, Quality Standards Manual).
 To install and implement the System Deliverables in "live Production" (i.e. final delivery of Software System
to the Clients). This may involve User or Internal Training, special control table set-up, data conversion/re-
organisation runs or special software install and new system activation timing . (Documents/Training:
Release Bulletin, Installation and Implementation Guide, Operations Guide, End-User
Documentation/Manuals, Actual User Training and Follow-up Support).

Page: 9 / 57
1.2 - The Ordinal Nature of Application Software System Development
Before any discussion of Application system SDM begins, one must first understand the uniquely layered and
serial (ordinal) nature of Application system development. This will be explained below as an Application is
traced from its initial development and then transitions into maintenance mode where change layers are
continually being applied for the remainder of the Application system’s life span.
1.2.1 - Initial Application Development Project
The development of the original core version of any small, medium or large Application Software System is
typically performed by a project team whose target deliverable is the first “completed” iteration (or “version”)
of the Application System. Depending upon the scale of the Application and development effort, the original
development may be split into several phases or layers. If the development work is layered, initial layers
usually provide foundational platforms for the subsequent development layers.
The number of programs that typically make up the core portion of the Application depends of course on the
size of the Application, and typically ranges from a few dozen, to hundreds, to thousands or even tens of
thousands of individual program source code files. The initial version may take anywhere from weeks to
months to several years to develop (depending on scale, staff size and expertise, and development/language
platforms).
All the software elements that pertain to this first iteration of the Application System must then be stored as
the initial versions in the Software Library. This entire software set is then linked together as a Library project
group. When re-extracted as a group, the entire application's software set must (theoretically) be re-buildable
(from scratch) from this extraction. The Project Number representing this initial development will identify this
project group. This Library group will serve as the “baseline” for the inevitability of future changes to the
Application.
1.2.2 - The Importance of "Build Order" for Subsequent Change Layers.
After initial Development, the Application System’s development will transcend into "maintenance" mode,
where additional Software System layers that are applied to the main Application will come forth in the form of
individual IT Department projects. Each of these project layers contains a new "software system" (see above -
“Definition of Initial Terms”) in the form of a new sub-system or an enhancement or a bug fix to the main
Application. Each project layer is added sequentially to the main Application, one at a time, one on top of the
other, in a pre-determined ``Build Order``.
Stabilisation of Development Platform
The reason why these project change “layers” are added serially in a fixed, sequential and predefinedBuild
Order rises from the fact that each new software package technically and essentially changes the overall
behavior of the core Application (even if the project change is comprised of merely a one-line bug fix).
In order viably work on the development of each new project change, the development must have stable
(frozen) software content from which to work from. As each new change is completed, it then becomes part of
the platform for the next change, and so on. This pre-ordered, serial stream of software application to the
Application System is referred to as the “Build Order”.

Page: 10 / 57
Build Order Still Persistent Within a Release of Concurrent Project Development
In practice, most IT departments will typically work on several projects concurrently (and the projects are
delivered together as a Release). One might argue that this apparent concurrent project development
invalidates the above notion that Application system development is a serial and layered process. But note that
while in fact the multiple projects within a Release are developed concurrently, there is still the assumption of
relative order between the projects within the Release. This is especially true when the projects either affect
one another functionally, or even more importantly, if a common program is being modified by multiple
projects within the Release. Therefore the individual projects within the Release must still align themselves in a
fixed Build Order and will be developed and managed in that Order.
Build Order and Configuration Methods Viewed as Part of Application Functional Software
So critical is this Build Order (and the overall Software content build method), that they become part of the
functional "software" of the project in as much as the logic within program source code define.
In as much as program bugs can bring the Application system to a halt, installing code from multiple projects
out of sequence or if the software is configured improperly, can be just as crippling to the Application. Often
times these “build related” errors are much harder to identify trace and resolve than regular in-code bugs.
The importance of Build Order is obvious when multiple projects share common programs. As a hypothetical
example, let’s say that Project 1100 and Project 1104 share a common program and their respective changes
are located in different routines within the common program source code file. In this example, as you would
expect, the more recent changes to the common program from Project 1104, were correctly built and added on
top of the older Project 1100’s changes. But if the software for Project 1104 is somehow installed before
installingProject 1100 (in reverse order), then the changes to the common program by Project 1104 would be
missing thus causing the system functionality of Project 1104 to abort with errors.
Build Order’s Continuing Significance Even with Functionally and Physically Separate Projects:
In the case where it seems obvious that none of the multiple projects within the Release share any common
code, one would think that in this case, the Build Order would be a non-issue. This might appear especially true
if it is also apparently obvious that there are also no functional dependencies between the remotely and
physically separated Projects.
However as we will see later on, the Build Order between two seemingly unrelated projects is still an important
factor during QA’s System and Integration Testing, In QA’s holistic tests (Regression, System and Integration
testing), among the mandates of these types of tests are to ensure that the set of projects are indeed working
properly and to ensure that they are in fact not impacted by one other. By fixing their relative build order, the
order in which they were installed can be eliminated as the error-causing factor in cases where QA testing does
indeed find problem(s) witheither or both projects. If in fact the Application error did indeed stem from an
error in the Build Order or in other automated software configuration tasks, these can be permanently
corrected in the Software Control System and replayed and re-tested (much like a source code bug is
permanently corrected and re-tested).
Layering and Build Order as Underlying Foundational Concepts for SDM
In summary, the point is that in as much as automobile manufacturing is only viably accomplished by modern
assembly-line processing, likewise, the basic development methodology for Application System development

Page: 11 / 57
can only viably be accomplished by building the Application serially, applying each project change, one at a time
as "layers", in a predetermined "Build Order".
Proper Software Development Methodology (SDM) understands this unique serially layered nature of
Application system development. In part because of this fundamental, ISO 9001 proposes the dual notions of
"Building Systems from Known Source", and "System Promotion" (also referred to as "Gating"). These dual
notions serve as not only as the means to support this sequentially built dynamic of software development, but
also to serve as the backbone for Software Development Methodology in general.
1.3- SDM’s Backbone Concepts: “Building from Known Source” and “System
Promotion (Gating)”
Proper System Development Methodology is based on the dual notions of "Building from Known Source"
(BKS), and "System Promotion" (also called "System Gating"). The later notion (System Promotion) can
only be understood within the context of the first notion (Building from Known Source). As such, System
Promotion will finally come to light as Goal #2 of BKS (section 1.3.1.4.2) below.
1.3.1 - Building (the Application’s Software Content) from Known Source (BKS):
Whether it is for a Programming Team of a Project getting ready to begin development of new changes to
the Application, or the QA staff preparing to test the projects for the next Release, or for any other sub-
department within IT that must perform some operation using the Application, the Application system
must first contain the proper baseline software content that is appropriate for their respective tasks.
The ISO 9001 principle and mandate to "Build from Known Source" (abbreviated here as "BKS") refers to
how baseline applications are to be prepared before they are used by these IT business units. This same
BKS method is also used to create the final Production level Application (the final deliverable to the
Client). The consistent use of BKS to build the Application’s software content ensures software content
consistency as it moves (or “promoted”) from one business unit to the next.
1.3.1.1 - The BKS Process: Applying Project Groups to Reach Desired Software Content:
In a nutshell, the “Build (the Application System’s software content) from Known Source” (BKS) concept
describes how the software content of an Application is build up. BKS does this by applying software
layers from project groups within the Source Library one at a time in a predefined Build Order, and
continuing this process until the Application’s software content reaches a desired level.
Before an IT Department can implement BKS builds, the following requisite BKS system elements must be
in place beforehand. Briefly listed below is each of these BKS elements (some of these elements are
described in more detail in the Appendices).

Page: 12 / 57
 Source Code Library (“Library”) – In addition to its ability to store version generations of source
code, MAKE scripts and project documentation, the Library must also be able to create and manage
specific "library groups" that link specific versions of library elements. The Library must also be able
extract these elements as a group using this library group linkage. The vast majority of these library
groups will be “project groups” that link together elements that make up the project’s files (source
code, project documents, compilation scripts (MAKE file), and other project related control files. The
Library is discussed further below in section "A1: The Software Library" within Appendix A.
 Build Order File (BOF) – The Build Order File is an ordered list of project related library groups. The
BOF dictates the order in which the project groups must be installed into the Application. This order
is discussed and determined during project whiteboard sessions and also by the Programming lead
working in conjunction with the Software DBA. The BOF is also a library element under version
control and is managed by the Software DBA (SDBA). The BOF is actually a conceptual file (meaning
that if its function to manage and control the order in which project layers are applied is already built
into existing platforms, then the “BOF” as file per se is not applicable.
 MAKE files – a MAKE file is a script or program included within each project group. The MAKE
configures and complies (i.e. installs) the source code pertaining to its project into the Application.
The Software Control System (SCS – see below) will use the MAKE to install the project group into the
Application System. The MAKE file is actually a conceptual file (like the BOF above), and may not
actually exist as a separate file if its functions are already built into the Application platform, or the
Software Control System.
 Release Level Control File (RCF) - This file (also under Library and version control) links specific and
contiguous project groups within the Library to a Release number. This file is used by the SCS to
extract a set of project groups (that are associated with a software Release), to create a Release
Install Package. The Release Level Control File (RCF) is also a conceptual file (like the BOF and MAKE
files). I.e. if functionality to arrange and manage projects groups as releases is already built into the
Software Control System, then the RCF may not be an actual file. The Release Number itself is
usually comprised of a decimal number with the format ‘vvvvv.rrrrr’ (where ‘vvvvv’ is “version”
(representing a major benchmark Application system change), and ‘rrrrr’ is “revision” (representing
smaller incremental enhancements and bug fixes that occur between versions).
 Application Software Content Data (“Content Data”) – These files residing within each Application
System’s database, logs the time stamp when project group software was installed into the
Application. This Content Data also logs the present Release level of the Application. The Content
Data is used by the SCS to ascertain the present software content of any iteration of the Application
system. It then uses the BOF, RCF and project groups in the Library to prepare a software install
package containing a stream of project software packages that will bring the Application system up to
a targeted software content level. Once the software is installed, the Content Data will be re-
updated to reflect the new software content of Application.

Page: 13 / 57
 Software Control System (SCS) (also referred to as “Software Configuration and Management System
(SCMS) – is the system layer around the Library that performs the Build from Known Source (BKS)
system build process. For this key function, the SCS scans the targeted Applications system and
installs the project group's software. It does this in a serial fashion according to the Build Order File,
and continues the same procedure for each project group in Build Order File order, until a targeted
Release level (as per the Release Level control File) is reached and installed. The SCS also performs
several other ancillary activities upon the Library, including code and Release analysis (extracting the
code text of the actual of a project or Release). The SCS produces software control related reports
(including Code Review Reports) for the Software Database Administrator (SDBA – see below). The
SCS provides other development tools such the software reservation system, as well as source code,
project, and release comparison utilities. The SCS is operated by and managed by the SDBA. The SCS
is discussed further in section "A2 – The Software Control System (SCS)" under Appendix A.
 Software Database Administrator (SDBA) – The SDBA is a person who administers the Library and
the SCS. The SDBA monitors code check-in/check-out registers, and performs cursory review of
incoming software for conformity to requirements necessary for the software to work with the BKS
environment (mainly the verification and testing of MAKE files). The SDBA also creates and maintains
Library Groups, and maintains the Build Order File (BOF), and the Release Level Control File (RCF).
Most importantly, the SDBA also administers the SCS and uses it to build the software content of
Application systems in preparation for use by all IT departments and for final Production level
delivery to the Client. The SDBA is also present during Release creation and Release Implementation
meetings helping to determine set the Project Build Order and Release content and management.
System Architect/Programming Team Leader (SA/TL) - The SA/TL - is the most senior and
knowledgeable person regarding the Application system. These might be separate persons, but the
SA/TL will be used here to designate the most senior technical lead regarding the Application system.
The SA/TL's tasks are mainly: a) to chair Whiteboard sessions and most major meetings along the
System Development Life Cycle (see section "1.3.1.5 Sample BKS Based System Development Life
Cycle (SDLC)" below), b) co-ordinate the Programming Team during multiple Project Release
development and helps define the Build Order, c) performs Code Review and/or heads and designs
the code review process, d) works with SDBA to ensure system build is co-ordinated, e) review
procedures at the Implementation meeting, f) authors the Programming Guide and co-
ordinates/authors the creation of the Programming Team Standards Manual.
1.3.1.2 - Example: The Basic BKS Build Sequence
The basic action of the "Build from Known source" (BKS) System Software install ("build") sequence is a
matter of pulling all of the elements pertaining to the project related Library group and installing the project
as a software layer onto the Application. This is an automated process performed by the Software Control
System (SCS). A "BKS Software install" attempts to use this basic action repeatedly (and in proper Build

Page: 14 / 57
Order) to update the software content of the targeted Application system up to targeted software content
level (a Release Level). (In practice, the SCS might create an installation package (an .inf file) to perform the
same functions.)
The BKS process is actually executed at several points in the System Development Life Cycle, but in this
example illustration, the BKS sequence snapshot is taken during the turnover of a Release of software from
the Programming Team to the QA Team. Below is a narrative and diagram of this BKS sequence:
1. Three (hypothetical) Projects #100, #101 and #102 have completed the coding phase by the
Programming Team. These three projects have been loaded into the Library by the SDBA and he/she
has set up their respective project groups in the Library. The SDBA has also updated the Build Order
File (BOF) within the Library, with the inclusion of these three new projects (the 3 projects are to be
installed in ascending numerical order after Project 99). Release 5.01 (which contains only these 3
Projects - #100, #101, and #102) has also been added (also by the SDBA) to the Release Level Control
File (RCF) in the Library.
2. The Software DBA (SDBA) receives a request from QA to prepare an Application System for QA Testing
of Release 5.01. The SDBA will choose a baseline Application system (typically a copy of the present
Production System). For this example, the Content Data of this Production level Application system
shows that it is presently at Release level 5.00 (the current Production level).
3. The SDBA runs the SCS function to update the target Application System from its present software
content level to the target level (Release #5.01). The SDBA feeds the SCS just two parameters: 1) the
location of the Application System, and 2) the target Release Level (“Release #5.01”).
4. The SCS first scans the Content Data of the target Application system to determine its present
software content and it finds that it is presently at the current Production level (Release 5.00).
5. The SCS then scans the Build Order File and the Release Level Control File within the Library. From
these scans the SCS is able to deduce that in order to update the target Application System’s software
content from it’s present Release 5.00 (current Production) level to the intended Release 5.01 level,
the SCS needs to install the three projects that comprise Release 5.01 - Projects 100, 101 and 102 in
that order.
6. To install Project 100, the SCS extracts the software elements of Project 100 (Including its MAKE file)
from the Library and installs this software, by executing the Project 100 MAKE file that contain the
instructions that describe the configuration, compilation instructions, and set-up instructions for
installing Project 100. This sequence is repeated for Projects 101 and 102 in that order. (In practice,
the SCS will extract all three projects' software and will create a portable install package (.INS) file.
When the .INS file is executed the software will be installed as described above, the only difference is
that the source files will come from the INF file instead of the Library.)
7. The SCS will then update the software Content Data files within the Application indicating the
date/time of installation of Projects 100, 101 and 102, and that the Application’s software

Page: 15 / 57
content level has been successfully upgraded from Release 5.00 to 5.01. (In practice the .INS
file will do this update as its final step).
Figure 1: The Basic BKS Build Sequence
Start SCS BKS Build
Get Parameters from
SDBA
Enter: Target App System and
Target Software Content Level Library
Build
Order File
Target Application
System
Software
Content
Data
Programs
Release
Level
Control
File
Project
Library
Groups and
Project
Elements
Determine Software
Content of Application
Determine Build list of
Projects to Apply and
Order of Application
Target
Reach
ed?
Extract
Project
Software
From Project
Install Project
Software
A
A
Update SW
Content Data
End
Y
N

Page: 16 / 57
1.3.1.3 - Why Automate Software Installation?
There are at least three reasons why the above automation of software installs is highly recommended over
doing all of this manually:
Build from Known Source (BKS): The real benefit of BKS builds can only be achieved with automation.
These benefits are, a) Consistency of the software content and b) consistency in the way in which the
software layers (projects) were applied to the Application. The way in which software layers are
installed can "make or break" the system. Manual software installation errors could result in projects
being installed out of sequence. If set-up tasks are executed manually via interactive screens, and if
errors occur, the log of this activity and resulting error is usually lost. By automating the install
process, the errors are logged. Once the process is fixed, it can be replayed again.
Volume of software Projects and Confidence Factors: For a medium to large application, the number of
projects (believe it or not) can number in the hundreds or even the thousands within just a few years.
Even after a few dozen projects, manually managed and built software content builds will become
both unwieldy and error prone with little audit trail as to where errors may have occurred. Most
importantly, this manual method of system building will create serious doubts (especially to QA)
regarding the soundness of the software content platforms that they base their tests upon.
Build to specific targeted Release (specific software content): In special ad-hoc situations there might
be requests to produce the Application system where the software content must be contemporary
with a certain point in time (i.e. restoration of an old Clients database for special runs, or for archive
data reporting). This can be achieved by the automation of BKS builds by the SCS. It provides
facilities to "replay" a sequence of project layer installs until it reaches a specific software content
level that is contemporary to and compatible with the database structure. (See “1.3.1.2 -Example:
The Basic BKS Build Sequence” above.)
1.3.1.4 - Goals and Benefits of Building from Known Source (BKS)
While there are several benefits from the above described "Build from Known Source" (BKS) method, the
following are four crucial goals and benefits of BKS:
1. To Ensure Control and Consistency of Software Content within the Application
2. To Implement System Promotion (Gating)
3. To Ensure that the Software Content of Application System is “Known” by direct linkage to the Library
where links to a project's software set and documentation can be readily accessed for support and future
enhancement of the Application.
4. To Provide a Framework for the Entire System Development Life Cycle (SDLC).

Page: 17 / 57
1.3.1.4.1 - Goal #1 of BKS: Control and Consistency of Application Software Content
A major goal of Building from Known Source is to ensure the consistency and accuracy of the software content
of the Application System. This is accomplished the careful tracking and control of the source code in the
Library and directly using this source from the Library to build the software content of the Application. Secondly
by adhering to a pre-defined Build Order, the manner in which software is applied to the Application is
controlled, published, and fixed. By using the automation of SCS's build functions (instead of reliance upon
manual efforts) ensures that the software content of the application is built consistently as it is promoted from
Development, to QA and finally to Production.
1.3.1.4.1.1 - Theoretical BKS – Complete Build:
The theoretical build of BKS implies that the application system has been built from the groundup, using the
same BKS manner of sequentially applying project group layers taken directly from the Software Library and
applying these layers in a fixed Build Order. The Theoretical BKS concept starts with an “empty” Application
system skeleton (devoid of software). The "Build" starts by applying the first project group which is the
entire software set of the original version of the original Application system. Following this baseline build,
BKS then applies all project packages created since the original version. These projects may pertain to major
releases, added sub-systems, small, medium or large enhancements, change requests and bug fixes. The
build applies each project software system package layer one at a time in their proper Build Order until the
Application system reaches a targeted software version (Release level).
1.3.1.4.1.2 – Actual (Usual) Practice BKS – Build from Baseline:
In actual practice, BKS builds usually start from a previously established baseline (such as the current
Production level) and then applies specific Project groups from the Library on top of the baseline until the
targeted version level is reached. This "Usual Practice BKS" assumes that the beginning baseline
Application system has already been built as per the above "Theoretical BKS" manner, and therefore, (if in
fact, these baselines are available) there is no needto replay the build prior to the baseline.
1.3.1.4.2 - Goal #2 of BKS: System Promotion (Gating)
The process of Building from Known Source (BKS) is the method used to prepare the software content of the
Application system that is to be used by every major sub-department within the IT Department. BKSbuilds
systems of specific version content for Programming (for development), then for QA (for Testing) and ultimately
for the client as the final deliverable "Production" system, thus moving a Release of software through its
development stages in process called "System Promotion" or "Gating".
The following sequence shows how a software Release is “Promoted” through the IT Department by BKS:
 Development (Programming Department): BKS builds a specific baseline system from which Programming
can add their changes. The baseline is usually just the Production baseline, but often times the baseline can
be based on the Production level plus other Work-in-Progress (WIP) projects (that have already been
checked into the Library and that are also part of the next Release). In this way BKS facilities help the
Programming Department stabilise their development platforms, and also helps to co-ordinate the
development of concurrent multiple projects by promoting the culture that adheres to a predefined Build
Order. The Library's software reservation system also helps co-ordinate concurrent project changes upon a
common program (also called "Variant Stream" development - see section "Appendix C: Variant Stream
(Multiple Development Path) Development" below). Completed software is reviewed to check compliance

Page: 18 / 57
to BKS build standards before being configured into the Library as a project group. The project group is
added to a Release. In this way, the project software is readied to be passed (or "Promoted") to QA for
testing (or re-testing).
 Quality Assurance (QA): For QA, BKS produces Systems in the same way - by applying completed Release
project changes from the ProgrammingTeam into QA test systems. The SDBA applies these changes in
BKSfashion as described above in the above section "1.3.1.2 - Example: The Basic BKS Build Sequence". In
this controlled scenario QA can test with confidence that any system configuration and build order issues
have been eliminated, and that only the known (and expected) changes have been introduced to their test
systems. Within the BKS scenario QA tests not only the code changes, but also the build method.
 Production: The same build method used to build the QA test systems will be the same one used to build
the system that is delivered (or Promoted) to the Client as the Production system. By replaying the same
build (from Library source) method, BKSensures that the system that QA tested will be the same that is
delivered to the Client because they were both build in the exact same fashion.
This method of using BKS (as described above) to move new software development from one development
phase to the next (DEV->QA->Prod) by controlling its configuration and build order, is what as known as
System “Promotion” (or “Gating”).
This same build method of BKS also produces systems of specific versions for other IT sub-departments for
various reasons. The BKS method allows for building of Application system whose software content reflects a
level that is contemporary to a particular point in time or software content level.
 Client Care: BKS can build a system for use by Client Care customer support (usually the current Production
version).
 Implementation/Conversion Teams: BKS builds systems of specific software version baselines for their
implementation set-up, or for conversion or de-conversion projects. Implementation teams generally
choose the current and latest Production baseline, but De-conversion Teams may choose a baseline that is
contemporary withthe software content level that the de-converting client will possess at the estimated
date of de-conversion.
 Operations: BKS may need to build systems based on the software release level from previous years in
their special requests for archive, year-end, or prior year tax reporting, that may require processing on
older databases which may contain data structures that are incompatible with the current software version.
1.3.1.4.3 - Goal #3 of BKS: To Make “Known” the Software Content of Application System
Some of the important attributes of "knowing" the software content of an Application as a result of using
the BKS build process are:
1. For any program in the Application, one can find its exact corresponding source code version in the
Library. This program version will be linked to a project number.
2. Through the project group linkage, one can also find all other elements (code and documentation) of
that project within the Library.
3. Because all versions of a program are in the Library, all generation changes can be identified (via tools
offered by the SCS). Usually the most recent changes are of most interest, but being able identify the

Page: 19 / 57
changes that every generation entailed is often very useful. Each change can be linked back to the
Project Documentation that also describes the nature and purpose of the changes. In fact, all
changes made by the project (plus all the project's documentation) can are extractable and
identifiable by SCS functions operating on the Library (see "A2.1 SCS Utilities to Service Programming
Development" under Appendix A).
By accomplishing the above, the following are some of the crucial benefits of BKS Goal #3 (“Known”
Software Content)
 Controlled Software Content during System Promotion: As mentioned above under the heading of
"System Promotion and Gating", BKS introduces a framework that helps to clearly identify and control
the software content (the functional scope) of the Release. Also, of equal (if not greater) importance,
BKS controls the way in which the software is installed. As the new Release project software
"promotes" itself from Development to QA and finally to Production, BKS ensures that Production
receives the exact same software content that was tested by QA. In this BKS environment, QA not
only tests the functionality of the software changes, but also tests the Build Order and individual
MAKE scripts that configure, compile the software and performs the set-up during the System builds.
 Maintenance, Support: By being able to identify the exact coding changes pertaining to any release of
software, and having ready access to project documentation, the BKS system build environment to
facilitate programming maintenance support, and future enhancements. Most likely, bugs that are
reported just after an install of a Release usually stem from the changes pertaining to the recent
Release. Traceability and understanding of previous project related code changes within the Release
not only tremendously helps bug support, but is also crucial in the design approach of future project
enhancements.
 System Backout: The dependable identification of code changes pertaining to individual projects and
to a Release, and the manner in which BKS builds systems, also creates a framework that facilitates
software system back-out mechanisms. Coding standards and QA criteria can be created to require
additional System Back-out facilities that must be included with each project in the release.
Specifically, the Programming Standards and Code Reviews, and QA Test Plans can then include
checks and tests to ensure that the back-out facilities are present, standardised, and Tested.
 Effects on Programming Methodology and Programming Standards: BKS's method of Library
controlled sequential system building affects the Coding Standards within the Programming
department in the areas of program documentation standardisation, build (MAKE) script design,
program design and approach (which must take into account how the software is to be installed
during implementation and the inclusion of viable back-out facilities). Code Reviews are then
tailored to enforce these BKS related design requirements.
 Effects on QA Standards and Methodology: BKS also affects the flow of work in QA. In the BKS
structure, application systems are always built only from the controlled environment of the Library in
a one-directional "promotion" or movement of software. For instance let's look at a QA resubmission
scenario where bugs that are reported by QA. In this resubmission, the project is sent back to
Programming for rework. In the BKS environment, when the Programmer completes his/her bug
corrections, the completed fixes/rework are NOT handed directly back to QA, but instead, the rework
must be checked-in to the Library where the Project group is then updated to include the reworked
program versions. Then the QA system is rebuilt by the SDBA from the new "known source" using the

Page: 20 / 57
BKS method. In this BKS process flow, QA tests (and re-tests) the build process in addition to the
actual changes. QA also tests other BKS related features such as the system back-out mechanism.
1.3.1.4.4 - Goal #4 of BKS: To Provide a Framework for the System Development Life Cycle
The core practice of Building (Systems) from Known Source actually provides the basic workflow framework for
all work phases in the System Development Life Cycle (SDLC). This is best illustrated in the next section "A
System Development Life Cycle (SDLC) using the BKS Framework".

Page: 21 / 57
1.3.1.5 - Sample BKS Based System Development Life Cycle (SDLC)
The following is narrative of a hypothetical BKS-based, System Development Life Cycle (SDLC).
This example emphasises how BKS / System Promotion provides the framework for the SDLC from the handling
of the Client's RFP, to how SDLC activities move the developing system in/out of the Library, promoting it from
one business unit to the next. (Figure 1) Some of the differences between Agile SDM and Traditional SDM (T-
SDM) will also be highlighted. Following this narrative is a diagram of the same SDLC.
1. Client Meeting and RFP: This hypothetical System Development Life Cycle begins with the Client
requesting a change to the Application System. This can be either a phone call from the Client to the
Client's Marketing Representative. In this instance if the "Client" is external to the IT Department, a
Request for Proposal (RFP) is issued from the Client. The External Client is informed of the minor costs of
processing the next 4 steps that are payable by the Client regardless of whether or not there is a go-ahead
to continue with the project.
2. User Needs or Prototyping: After the above request has been made, the Marketing and Business Analyst
(B/A) meet with the Client to further ascertain and define the Client's needs. In the traditional SDM
environment, a draft of the User Needs document is created after discussion with the Client. In an Agile
SDM environment, a Programmer/Analyst is also invited to help create and run real time Prototypes of the
proposed changes, while the Business Analyst supplements the Prototype with a “Prototype Processing
Summary”. The Prototype Processing Summary summarises the changes represented in the Prototype as
well as outlines significant behind the scene processing details that may not be readily observed from the
Prototype. (For non-external, internally initiated changes the User Needs will simply be a brief listing of the
intended changes, written by IT internal staff.)
3. White-boardSession#1 – Discussion of System Approach: (Attendees: System Architect (Chair),
Programmer/Analyst, Business Analyst. Purposes of this Meeting: a) Discuss system design approach of
the changes (discussion led by System Architect assisted by P/A). b) Discuss scope of work and create rough
Work Estimates by P/A. c) P/A to pass Work Estimate to Business Analyst and a QA Analyst to add their
estimates.
4. Cost Benefit & Capacity Planning Meeting: (Meeting Attendees: Marketing Representative (Chair),
Business Analyst (who did the User Needs or prototyping), System Architect/Team Lead, QA Manager,
Programming Manager, IT manager, Marketing Manager). Purposes of this Meeting: a) Determine urgency
and priority of proposed changes via cost/benefit analysis (based on the Work Estimates created as a result
of the above White Board Session, b) Determine which Release the change would fall into (as this would
determine the estimated date of system delivery), c) Determine if there is enough staff capacity to create a
Project Team for this request d) Finally, decide whether or not it is in the best business interest to go ahead
with the project.
5. Response to RFP: Response to the Client's Request for Proposal with Cost Estimates, copy of User Needs
and/or Prototype Processing Summary and Estimated Completion Date. If the Client accepts the response,
then continue, otherwise this project closes and the Client (if external) is invoiced for the modest
processing fee for the RFP as mentioned in step 1 above.
6. White-Board Session #2: - Project Creation and Scheduling, Set Build Order: (Attendees: System Architect
(Chair), Programming Manager, QA Manager, SDBA, Project Manager and Business Analyst tentatively
assigned to this project, and finally, Project Managers from other project teams that might be affected or

Page: 22 / 57
impacted by this project). Purposes of this Meeting: a) To create Project Number and select and set Project
Team, b) Overview System Design and approach with the team, c) Determine Project's Build Order by
discussing shared code issues with other WIP Projects (see "section variant stream development" below),
or any other Architectural consideration that might effect the development path of other affected projects,
or possible Reset of Build Order and priorities of other Projects.
7. Traditional SDM: FS creation and Client-sign-off to commit to work. In Traditional SDM, the Functional
Specification must be completed by the Business Analyst and signed by the Client before the Project can
continue. (In Agile SDM, this step (7) is not required because the Client's go-ahead approval was made
earlier in step #5. In Agile SDM the FS development becomes a collaborative effort between the Business
Analyst and the Programmer/Analyst beginning with the second White Board during the coding phase. The
completed FS then is delivered for Client sign-off at the end of the Project. See "2.1 – Agile SDM – Variations
on the System Development Life Cycle" below.)
8. Project Group and Release Update in Library: The Software DBA (SDBA) now creates a project group for
the new project in the Library. The SDBA also inserts the Project Group into the Build Order File. If the
Release, in which the Project belongs to, has not yet been created, the SDBA will also create the Release in
the Release Level File (RLF) and inserts the Project Group under the Release within the RLF.
9. BKS Build #1: Baseline Creation for Programming: The SDBA creates a baseline system for the Project's
Programmer/Analyst to begin work on the Project Changes. This baseline system is either the Current
Production level Application System, or Production plus any WIP Project software that precede the Project
as per the Build Order. On-going co-ordination (headed by the SA/TL) between these concurrently
developedprojects must be maintained to continually retrofit on-going changes made by the preceding
projects (that are also within the same Release) onto the Project's baseline system.
10. Code Reservation: Before any coding can begin, if an existing program is to be modified, the
Programmer/Analyst must reserve the code from the Library. If the code is already reserved for another
project, this situation must be co-ordinated by the System Architect/Team Lead (SA/TL) in conjunction with
the Project Managers of the projects that are linked by the common code. While the relative Build Order
between projects was mostly determined during Whiteboard Session #2, if the SA/TL is in agreement with
the Project Managers to revise the Build Order, they must also inform the Software DBA who must update
the Build Order File (BOF).
11. Programming: From the BKS perspective, the Developer must be cognisant of the guidelines of
programmingwithin a BKS type environment. See section "2.3.2 - Programming Guide in the BKS
Environment" for a summary of these guidelines.
12. Code Review: This review is normally the domain of the System Architect/Team Lead, but even if
delegated to another Programmer/Analyst, in addition to reviewing the code against the Programming
Standards, the Code Review must validate the BKS criteria as described above in the Programming Step
(step 11). Again, these standards are outlined in “2.3.2 - Programming Guide in the BKS Environment” below.
13. Code Check-in & Project Group/ Release Management: Upon Code Review approval, all source code, the
MAKE file, and other files completed by the Programmer and the Business Analyst (for Agile SDM, the
completed draft of the Functional Specification) are given to the Software DBA (SDBA) to check into the
Library. The tasks of the SDBA in this instance are: a) to check to ensure that the source code was originally
properly checked out, b) to create new versions of the submitted files during the check-in process, c) to
update the project's library group linkages to include these project elements.

Page: 23 / 57
14. BKS Build#2: SDBA Installs New code to QA Test System: The SDBA selects a baseline Application and
installs the new Project group into the Application using the methodology as described above in section
“1.3.1.2 - Example: The Basic BKS Build Sequence:”, and presents this system to QA for testing.
15. QA Testing : The QA test plans are created for Unit, System, Integration and Regression testing. Testing
must take into account at least 3 levels. a) To Unit Test this Project against the Functional Specifications
(which is also reviewed by QA). b) To run System and Integration testing of all Projects within the upcoming
Release. c) To run Regression tests of the main application at least on the core Application functionality
that might be affected by the Release software.
16. QA Resubmissions: If bugs are found in the new project code, the Project is resubmitted back to
Programming for correction. In this case, the BKS work flow reverts back to Step 10 above, where the
errant code is reserved again, this time for bug fixing. What is most important to note in this instance, when
the error corrected code is completed, the revised code will be checked into the Library, the Project group
is updated to include the latest fix, and the QA test system is re-prepared by rebuilding it (in BKS fashion)
with the new code before QA can test the error corrections. In this way, BKS build method preserves the
(QAtestable) software build integrity of the Application.
17. Release Document Preparation: The Release Bulletin, Implementation Guide, User and Training Guides
(for each project), and Operations Guides are created as needed. See "Project Documents within SDM:
Traditional Verses Agile" below for more details on these project documents.
18. Release Meeting: Making sure all is in order: (Attendees: SDBA (Chair), and QA Analysts from all projects
associatedwith release, Operations Lead, Client Care Lead, Implementation Team. Optional as Required:
QA Manager, Programming Manager, Operations Manager, System Architect/Team Lead). QA Analysts
overview the readiness of each project and go over any known loose ends, review and schedule any
critical/complex Operations tasks runs, review inter-project dependencies, discuss training issues or any
other implementation tasks that are part of the rollout of the Release. If some projects have to be pulled
from the Release, the Release Bulletin must be amended. Scheduling is now made of the exact time of
issuance of the Release Bulletin. Operations is made aware of any special runs that may be required as part
of the release rollout and they are given the Operations Guides for these purposes. A Release Installation
Support Team is now assembled: their task - to act as monitors and support staff for the actual install of the
Release Package. At end of meeting, the SDBA prepares the software install package and prepares the
instructions for when and how the package is to be installed to the Client's Application system(s).
19. BKS Build #3: Production Implementation: System backups are scheduled and executed. A BKS Build is
used to create the Production Install package. Software is installed to the Client(s)' Application systems. The
Release Installation Support Team monitor the installation and will either: a) signal that the Release
installation was successful and that the Client can continue using the Application, or b) alert all parties that
the installation was unsuccessful, and arranges the execution of Release Back-out procedures. User
Training (if required) is scheduled. Implementation Staff (in conjunction with Operations if required) carries
out any set-up procedures that may be required as part of the Release's implementation.
Figure 2 - System Development Life Cycle

Page: 24 / 57
Start of System development Life Cycle Step 1: Client Meeting and RFP
Step 2: User Needs/Prototyping
Step 3 White Board Session #1
Step #4: Cost Benefit/Capacity Planning
Step 5: Response to RFP
Step 6: White Board Session #2
Step 7: Functional Specification Commencement
Step 8:Project Group Creation and insertion to Release
Client
Go-Ahead?
Admin Charges Quit Task
Step 9: BKS Build #1: Base-Line for Programming
Software Library and
Software Control
system
BKS Build Function
Step 10: Code Reservation
Step 11: Programming
Step 12: Code Review
Step 13: Check-in and Project Group Update
Step 14: BKS Build #2: QA Test System Prep
Step 15: QA Testing
16. QA Resubmission?
Step 17: Release Document Preparation
Step 18: Release Meeting
Step 19: Project Documentation Check-in
Step 20: BKS Build #3: Production Build, Install and
Implementation End SDLC

Page: 25 / 57
PART 2: - SDM OPTIMIZATION AND QUALITY TOPICS
2.1 - Agile SDM - Variations on the System Development Life Cycle
The Preface of this document pointed out that Agile Software Development Methodology may offer real
improvements and streamlining upon traditional System Development Life Cycle.
With its powerful prototyping facilities, Agile SDM indeed offers better up-front understanding of the client's
real needs and Requirements. Also by leveraging the facilities of the prototype, Agile SDM can also offer much
quicker project completion times over traditional SDM. Agile SDM also streamlines certain aspects of the
traditional system development life cycle.
Agile SDM was in part, made possible by Object Oriented Design (OOD), and the rapid Prototyping that OOD
tools affords, and by Object Oriented Programming (OOP) that utilises a library of readily "reusable objects".
The developer uses these to build the Application much more rapidly and easily without redundant code and
logic.
The real benefits of Agile SDM are undeniable and some of its revisions over traditional SDM are indeed
welcome and long overdue. Amongthese benefits are:
 Prototyping with Client: Since the Business Analyst and Developer show actual prototypes to the Client,
the Client will have a much better and up-front understanding of what they are getting and will have a
much better idea of whether the solution is truly what they need. Through viewing and working with the
actual prototype, the Client can see first hand how the system will address their issue(s). The Client can
interact with the prototype, and with IT personal present, together they can fine-tune the prototype with
the Client’s direct feedback. This prototyping phase can cut down on project costs, reduce development
time, and reduce the chance for cost-overruns by reducing the need for Change Requests (that are the
seeming inevitably with traditional SDM). As mentioned in the step #2 in the above hypothetical System
Development Life Cycle, this prototyping phase is unique to Agile SDM, and the created prototype itself can
used in place of much of the traditional "User Needs" document that has been part of traditional SDM.
 Concurrent Functional Specification and System Development: Traditional SDM mandates that the
Functional Specification (FS) must be completed and signed off by the client before any actual coding
begins. This is because in the traditional SDM work flow, the FS provides the guidelines for both
Programming and QA testing, as well as acts as the legal definition of deliverables for the project. Some of
the drawbacks to this traditional approach are:
a) Since the FS must be written before any actual coding changes take place, the FS must "predict" the
details of the system that it must eventually describe in detail, and
b) Programming is held up while awaiting signoff of the FS.
In practice however, unless the FS resorts to vagueness and generalisation of several important details,
very rarely will the FS define all of the pertinent details of the Software System which has yet to be coded,
unless these details are added as revisions after the FS has been signed off. This situation is worsened
when the Programmer/Analyst is not allowed to collaborate with the Business Analyst and the later must
complete the FS as a sole effort.
Agile SDM: Prototype used as Client Sign-off Vehicle for Work Commencement

Page: 26 / 57
With the prototype being an adequate description of the eventual software deliverables, the Client can use
the prototype (that is accompanied by a supplementary Prototype Processing Summary) can be used as a
sign-off document to signify that the Client commits to the project until its completion and delivery. (In
traditional SDM, the Client must sign off on the completed Functional Specification before committing to
taking delivery of the system.)
In Agile SDM, the Functional Specification is developed concurrently with the prototyping/coding stage
because the end-user signs off on the prototype (as opposed signing off on the completed FS) as the signal
to allow coding to begin. In this way the FS can be developed alongside the project. In this approach the
FS loses its work commencement signoff, and some of its programming template roles, but retains its role
as the legal description of system deliverables.
This allows the FS to be developed as a joint effort by both the B/A and P/A so that it will it more closely
match the system it attempts to describe. This collaboration will benefit the FS from the unique
perspectives of both the B/A and P/A. Also, depending on the object oriented prototyping tools, some
prototyping tools can generate much of the content of the FS. In this way, the tasks of the Business
Analyst (as the primary author) the FS creation can be accelerated and will more accurately describe and
match the system deliverables.
Controversy:
There is still controversy about whether the FS should be developed alongside the code because in
traditional SDM, the programming ostensibly is based the completed FS. Agile SDM offsets this concern by
using the Prototype and its supporting document as sufficient template for Programming. The FS (in the
Agile context), becomes more of a "system description" as opposed to being more of a "proposed solution"
document for Client signoff within the traditional SDM scenario. To this author, this is one of the best
improvements on traditional methodology by Agile SDM.
In the traditional SDM scenario, the FS development has always been in a bind. As a system description
and legal contract of software system deliverables, it must faithfully and completely describe all aspects of
the new software system layer. Yet without sufficient time and system resources needed to create the FS,
the project’s progress gets stuck in a bind. Without a "go ahead" signoff the client has not yet committed
to the project, making it difficult for IT commit any more resources for the resource intensive task that is
the FS. As mentioned above, the software system itself has not yet been created, so in essence, the FS
must “imagine” the system it must describe. Due to common but unfounded fears that the Programmer's
perspective will skew the FS away from its original business intent, often times the Programmer will not be
allowed to collaborate with the Business Analyst in creating the FS.
 Source Code gleaned from Prototype: Depending upon the features of the Prototyping tools used, a
significant portion of the programming can be either taken directly and/or indirectly from the prototype in
the Agile SDM development environment, a definite help in accelerating the coding phase.
 Design Specification Streamlined: In certain Agile SDM implementations, the Programmer's document
(the "Design Specification" or DS) can be either be eliminated, or incorporated into other files (such as
embedded within system build scripts), and/or partially generated by the prototyping tools and/or by code
comparison tools from the Source Library facilities. With the ability (in the PKS environment) to obtain
listings of all program changes and Function Specifications pertaining to any project, these may preclude
the need for the Design Specification altogether (see section "Appendix B: Project Documents Within SDM:
Traditional Verses Agile" regarding the DS).

Page: 27 / 57
 OOP enforcement: In an indirect way, Agile SDM creates a natural enforcement upon the programming
department to abide by the basic rules of Object Oriented Programming (OOP) - in particular to ensure that
the programming department does indeed build, maintain, control and fully utilise its library of reusable
objects (without which they would not be able to keep up with the pace with which Agile SDM imposes).
In Summary, it becomes evident that while the Agile SDM development cycle streamlines and quickens the
System Development Life Cycle, none of its feature alters the basic software controls and system build SDM
core concepts of Building from Known Source and Software Promotion.
2.2 - Project Management: Mandate to Avoid "Scope Creep" in BKS SDM
Environment
The purpose in mentioning Project Management within this discussion of System Development Methodology
(specifically within the Build from Known Source (BKS) development environment context), is not so much to
describe basic Project Management (a type of training that is readily available).
Rather this section re-emphasises one of the most fundamental principles and goals of the Project
Management principles – that is to control and freeze the scope of a project. At the same time there is also the
intention to dispel some fallacious notions about Project Management, that have come about as a result of
misguided understandingof the real purposes of Agile development.
2.2.1 - The "Change Request Project" as the Proper Channel for Project Redirection
Before getting too far into the topic of this section, it is important to know that proper Project Management
methodology channels any request for change(s) to an original project's specification into what is known as a
"Change Request Project". These Change Request Projects are processed as separate and new projects via the
same BKS based System Development Life Cycle (as described above in section “1.3.1.5 Sample BKS Based
System Development Life Cycle (SDLC)”), just like any other project. But Change Request Projects are allowed
special scheduling and priority considerations as required by the specific circumstances of each Change Request.
2.2.2 –The Fallacy of “ Scope Creep” as a "Feature" of Agile SDM Project Management
However, in as much as the "Agile" buzzword has been used by some as an opportunity to abandon the critical
software controls afforded by SDM (as alluded to in the Preface), "Agile" has also been interpreted by some to
imply "flexibility" to modify a project’s scope before the project is completed and delivered. Specifically, this
interpretation states that Agile development not only allows mid- project changes (i.e. "scope creep"), but
describes scope creep as a welcome feature within the newer development environment of Agile SDM.
The following paragraphs explain the dangers of this fallacy and why "scope creep" is still unviable even within
an Agile SDM environment. Moreover, the paragraphs explain how scope creep goes against the very basic
aims of proper project management, and undermines the processes of Build From Known Source (BKS) based
development structure.

Page: 28 / 57
2.2.2.1 - Unrealistic Expectations of "Agile" OOP Development
The ability to prototype in an Object Oriented Programming (OOP) development environment does make
software development more efficient with less duplication. However, no matter how efficient and object
oriented the programming platform, it is still not an environment where sudden changes in functional
requirements (scope creep) can viably be accommodated.
Architectural Commitment Point of No Return:
While OOP benefits from the re-use of pre-written objects, it is the assemblage of those objects and the
creation of new objects that not only inherit the behaviour of the more generic objects, but also increasingly
adds behaviour that is more specialised to the present project's functional goals. This growing specialisation
eventually "commits" the project work to the functional goals of the original project specifications, as the
overall architecture becomes more functionally specific. Because of this, within a short time this commitment
passes a point such that if there were a need to significantly revise the original functional goals, it would actually
be best to start from scratch, where only the most generic and atomised objects can be reused.
Documentation Revision/Rewrite
In addition to the re-programming, there is also the cost of redoing the Functional Specification plus all other
Project documentation written to that point. These must all be reviewed either for heavy revisions or
wholesale replacement.
Convoluted and Dead Code that must still be tested:
Programming is never simply coding. It also involves extensive analysis, architectural design and approach in
the design of program structure before coding begins. This design and structure is not only optimised towards
the project’s functional specifications, but also considers interface design, performance and efficiency factors,
code legibility and functional and resource impact on the rest of the rest of the application system.
When the Functional Specifications have significantly changed, the previously coded architecture will be
immediately compromised. Rightfully, the entire architectural analysis should be repeated. Unfortunately
time pressures usually forces the project into a dangerous path - to attempt to shoe-horn the new logic using
the original code as baseline. This attempt to leverage original code to ostensibly expedite the coding process
creates several serious problems. As described below, this path to leverage original code as the platform for the
change request creates problems that are more costly in time and effort than if the project had been restarted
from scratch.
While screen and report prototypes can be relatively easy to redo (as they are literally drawn with an object
oriented editor), it is the underlying supporting business logic routines that are manually writtenand much
more complex. An attempt to shoe horn the change request logic into these complex routines that were
optimisedand structured to accommodate the original specifications, usually results in the following:
a) The resulting programs will contain dead code that still must be somehow tested.
b) The programs will contain convoluted logic that is hard to follow and support in the future. This mess will
inevitably be inefficient and bug prone with bugs that are especially difficult to fix given the convolution of new
logic retrofitted over the structures that were originally designed and optimized for the old business logic.
c) QA's Test Plans will have to be rewritten to include testing of a system that will have inexplicable attributes
from the original Functional Specification. If QA has the wherewithal to reject the package because of those
dead attributes, this will force a mandate to rewrite everything from scratch. After the inevitable shouting
matches between QA and Project Management the project have to choose between either of two undesirable
paths. Either QA will be forced to allow the convolution to pass through (so as to meet deadlines), or the

Page: 29 / 57
resulting rewrite will force the project to be pulled from the present release where it will miss its deadline. The
project in this case will either be relegated to another later release, or permanently shelved.
d) If the project's timetables are such that it cannot make the present release, it will have to be pulled from
the release. If other projects have code that were built on top of this project, the other projects will be
adversely impacted as well, since they have to remove the logic changes associated with this project from their
code and those other projects will have to redo their tests.
2.2.2.2 - Allowing "Scope Creep" Undermines the Basic Goals and Metrics of Project Management
After requirements and work specifications for a project have been defined, the very basic and core aims of
basic project management are to:
a) Ensure that the project deliverables are ready by the estimated due date.
b) To provide metrics and statistics of the time and resources used by the project. These metrics and statistics
are the crucial business data to measure costs (and therefore measure revenue), to measure performance, to
track work progress and to do future project planning.
Yet all of these statistics and metrics are lost when "scope creep" is allowed to enter mid-project and when the
original project's deliverables are never allowed to reach completion. All metrics tracked by a project are
meaningful only when the tasks (measured against the unchanged work specification with predefined scope)
have reached completion. When the incomplete statistics from the original work specification are merged with
statistics from the new specification which leveraged work from the incomplete work of the first effort, neither
statistics set is complete, and both sets become useless. With project metrics thus ruined, the project is
reduced to a drudging and desperate effort to somehow bring closure to the project after all previous deadlines
have been hopelessly missed.
With a working environment that allows scope creep, work estimates, cost analysis, scheduling, estimation of
completion dates, and performance tracking all become impossible to gauge. An attempt for any type of
estimation for future projects is reduced to a guessing game. The inevitable failure to meet customer
satisfaction in terms of functionality and timeliness of software deliverables will be unexplainable since Project
Management cannot reliably produce estimates, produce clean software, nor control its own costs and
processes because of improper project management practices where scope creep is the central problem.
2.2.2.3 - BKS/System Promotion Based SDM Assumes Fixed Project Scope
All mechanisms of Software Development within the context of BKS/System Promotion SDM is based on the
basic understanding that the scope and definition of work has been defined in the very early part of the System
Development Life Cycle (SDLC).
Once the Client has signed off to commence work, there is an implied commitment to carry through on the
intended changes (as they are) through the remainder of the SDLC until completion and delivery.
The initial SDLC phases (User Needs and Requirements definition, Prototyping and Project go-ahead) take place
at the beginning of the Life Cycle in order to permanently define and freeze the nature and scope of changes.
Only when the project scope has been fixed and determined, is the project then integrated into the Release
schedule where other projects are also being developed and are collectively co-ordinated in conjunction with
this new project. The new project is then promoted from the Development phase, to QA testing and finally to
Production via the BKS method of software building and promotion.

Page: 30 / 57
During this promotion, it is critical that the scope of changes remains constant because:
a) The scheduling, cost and resource allocation, and release dates that were set during the White Boarding
sessions are all based on the original project specifications,
b) Any changes to the any of the project specifications may not only force rework within the project where the
scope creep occurred, but also may force some rework and re-testing of other projects in the release, and may
also force undesirable extensions to the Release date.
c) QA testing always requires a frozen test basis. Any "scope creep" introduced to their test areas completely
invalidates all previous testing and forces a repeat of all holistic system tests.
2.2.2.4 - Real Quality verses Unprofessional and Absurd Expectations
No one should be able to go into a restaurant and do the following:
a) You as a customer, order a plate of hamburger and fries.
b) 10 minutes later, just before the waitress gets ready to deliver the food, you announce to the waitress that
you want to replace the hamburger/fries with a plate of steak and eggs.
c) You demand that you only expect to pay the hamburger/fries price for the more expensive steak and eggs.
d) In addition, you blame the waitress for the fact that you're starving and,
e) You demand that the steak and eggs be delivered within 3 minutes of your new steak order. (Your
reasoning: Since the hamburger/fries came 3 minutes earlier than the 15 minute allowance for order delivery,
you expect the steak and eggs within the remaining 3 minutes).
As absurd is the above example, it is equally absurd, unprofessional and disastrous for any software
development company to make it a practice to react to customer's project change requests by simply dropping
the original order and attempt to try to fill the new change request under the terms of the original order. No
business entity can viably conduct their business like that.
Yet within the performance-based, hired-contractor working environment of IT, where pandering to the whims
of the client can get the contractor valuable references, especially if their contract expires at the end of the
project, this absurdity has become commonplace within IT software development. With congratulatory letters
and glowing references in hand, the contractors can leave at the end of the project well before the product
deficiencies surface. The blame for the inevitable late delivery dates, and software bugs and functional
deficiencies can easily attributed to performance issues on the part of the Programming and QA staff who, with
their “Agile” development facilities, were theoretically supposed to be able to deliver as planned.
In any Quality seminar that defines the attributes of real quality and real customer satisfaction, there is
invariably the following axiom:
Real Quality is not really all about "Giving the customer what they want and demand", but rather, it is about
"Managing and Meeting (or Exceeding) their Expectations."
Just as the above absurd customer expectations in the above restaurant scenario should never be allowed,
properly managing customer expectations regarding software system development and carrying out the
business of software development responsibly and with proper disclosure of those deliverables should instead
be the norm instead of reacting irrationally and irresponsibly to Clients' whims and demands.

Page: 31 / 57
Note that the SDLC narrative in the above section "1.3.1.5 Sample BKS Based System Development Life Cycle
(SDLC)", showed how the Client's original RFP was NOT met with non-researched and flippant promises.
Instead, the Client's request was properly channelled into the IT Department's existing SDLC processes for
preparinga response to a Client’s Request for Proposal (RFP). The RFP response includes Prototyping models or
User Needs definition, along with realistic work and time estimates that are based on past project statistics and
metrics.
Of particular importance, also note that the response to the RFP disclosed the following IT department's
Agreement and Terms for the project:
a) The IT department will not continue with the project unless the Client signs a commitment to go through
with the proposed changes.
b) Once Client signs the commitment to go ahead with the proposed changes they implicitly agree to take the
project to completion and to take delivery of the software system as described.
c) The Client also agrees that the “Change Request Project” process will handle any subsequent revisions or
changes to the original specifications that are made before the completion of the original project. The Change
Request Project process is essentially another follow-up project that will follow the same development path as
the original project (including its own cost and time estimates). However Change Request projects will be
scheduled with special priorities as needed, so as to coincide (as closely as possible) with the delivery of the
original project.
2.2.2.5 - SAF Rapid Software Inc. Verses PDM Systems, Inc.
The following fictitious example is presented to contrast two IT software development companies with vastly
different business models. One company (PDM Systems, Inc.) uses the system development methodology as
describe herein, while the other company (SAF Rapid Software, Inc.) does not take this methodology seriously
because it is considered unnecessary for its business model. While the names are fictitious, the story line was
taken from actual situations.
In this hypothetical scenario the two competing "software-house" companies are: "SAF Rapid Software Inc."
and "PDM Systems, Inc." (abbreviated as "SAF" (implying "Slap and Fix") and "PDM" (implying "Proper
Development Methodology") respectively). Both SAF and PDM produce and market a software package for
small manufacturers that performed basic accounting (A/R, A/P, Order Entry, Payroll, Sales Analysis, etc.) and
manufacturing related functions (Inventory, Bill of Materials, Job Costing) for small and medium sized
manufacturers.
The business models differed dramatically between SAF and PDM.
At SAF, the emphasis and revenue dependency was upon unit sales of their software package. They confidently
(perhaps overconfidently) considered their product as a "Turn-Key" package, meaning they felt that once the
customer broke the shrink wrap of their software package, SAF's involvement with the customer was essentially
over. At the time of this example, SAF boasted over 30 customers of their package, and yet managed all of
them with a staff of 6 personnel, thus showing their emphasis and aim in unit sales with support as a non-
revenue producing after-thought or “necessary evil”. Since SAF considered customer support an afterthought
there was no software development methodology or project management infrastructure for customisation, or
support services. Most of the SAF’s 30 customers came on early when the package was first debuted, but SAF
has not taken on much more since that debut, since their small 6 person staff has been tied up with unwanted
emergency calls and issues from clients. Customisation for any one client was coded in a hasty, unstructured

AppSys-SDM Concepts and Practices_v0-02

AppSys-SDM Concepts and Practices_v0-02

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to AppSys-SDM Concepts and Practices_v0-02

Similar to AppSys-SDM Concepts and Practices_v0-02 (20)

AppSys-SDM Concepts and Practices_v0-02