AppSys-SDM Concepts and Practices_v0-02

System Development MethodologyConcepts and Practices

For Application System Development

Document Name: AppSys-SDM Concepts Practices_v0-02.docRevision Number: 0.02Revision Date: December 20, 2013Author: 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 THISWRITING........................................................................................................................................................5

DEFINITION OF INITIAL TERMS................................................................................................................................... 6Term / Acronym...................................................................................................................................................................6Definitions........................................................................................................................................................................... 6

RELATED DOCUMENTS.............................................................................................................................................................. 7

PART 1: OVERVIEW OF SOFTWARE SYSTEM DEVELOPMENT METHODOLOGY (SDM)......................................................... 8

1.1 - OVERALL GOALS OF APPLICATION SOFTWARE SYSTEM DEVELOPMENTMETHODOLOGY (SDM)................................................. 81.2 - THE ORDINAL NATURE OF APPLICATION SOFTWARE SYSTEM DEVELOPMENT.......................................................................... 9

1.2.1 - Initial Application Development Project............................................................................................................91.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)”.111.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:................................................. 111.3.1.2 - Example: The Basic BKS Build Sequence....................................................................................................................131.3.1.3 - Why Automate Software Installation?...........................................................................................................................161.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.................................171.3.1.4.1.1 - Theoretical BKS – Complete Build:................................................................................................................171.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).......................................................................................... 171.3.1.4.3 - Goal #3 of BKS: To Make “Known” the Software Content of Application System....................... 181.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................................................................................... 252.2 - PROJECTMANAGEMENT: MANDATE TO AVOID "SCOPE CREEP" IN BKS SDM ENVIRONMENT...................................................27

2.2.1 - The "Change Request Project" as the Proper Channel for Project Redirection..............................................272.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................................................................................................. 282.2.2.2 - Allowing "Scope Creep" Undermines the Basic Goals and Metrics of Project Management....................................... 292.2.2.3 - BKS/System Promotion Based SDM Assumes Fixed Project Scope...............................................................................292.2.2.4 - Real Quality verses Unprofessional and Absurd Expectations...................................................................................... 302.2.2.5 - SAF Rapid Software Inc. Verses PDM Systems, Inc........................................................................................................31

2.3 - THE QUALITYMANUAL................................................................................................................................................... 332.3.1 - Link to Quality Manual Definition:..................................................................................................................342.3.2 - Programming Guide in the BKS Environment..................................................................................................35

2.3.2.1 - Standards from the Programming Language and Operating System Platforms........................................................... 352.3.2.2 – Standards from the Application's Own Programming and Configuration Guidelines..................................................352.3.2.3 - Requirements from the Software DBA (SDBA) to support BKS builds.......................................................................... 36

2.3.2.3.1 – SDBA Coding Standards - MAKE File................................................................................................................... 362.3.2.3.2 – SDBA Coding Standards - One-Time Set-Up Facilities........................................................................................ 362.3.2.4 - Standards from the Local BKS-SDM Development Environment.......................................................................... 372.3.2.4.1 - Source Code Format (as ASCII Text) for Library Storage..................................................................................... 372.3.2.4.2 - Internal Program Documentation........................................................................................................................38

SUMMARY:.............................................................................................................................................................................39


Page: 2 / 57

APPENDIX A: THE ELEMENTS OF BKS:.................................................................................................................... 40

A1: THE SOFTWARE LIBRARY:.................................................................................................................................................. 40A1.1 - Project Library Group Data.............................................................................................................................. 40A1.2 – Library Structure and Project Group Maintenance......................................................................................... 41

A2 – THE SOFTWARE CONTROL SYSTEM (SCS)..........................................................................................................................43A2.1 SCS Utilities to Service Programming Development.......................................................................................... 43A2.2 SCS Utilities to Manage Application Software Content..................................................................................... 43

APPENDIX B: PROJECT DOCUMENTS WITHIN SDM: TRADITIONAL VERSES AGILE............................................................ 45

Project Document Optimisation:................................................................................................................................. 45Typical 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............................................................................... 52INTER-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 INMULTI-CLIENT ENVIRONMENT:...................................................................... 54The 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 Description0.01 Dec 8, 2013 Ray Wong First draft0.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 perceivedas almost magical solutions where alleged results and benefits are expected within weeks after subscribing tothe technology. Realistically, these new technologies should be viewed for what they are - simply tools thatrequire proper understanding of the tool's behaviour, benefits, resource requirements and otherprerequisites, before they should even be considered.

For instance when the first wide-audience demonstrations of Relational Databases debuted, peopleenvisioned themselves issuing data mining queries of almost infinite variation and receiving instant results allwithout 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 includedthe daunting, enormously costly and inevitable task of legacy database cleanup and normalisation, thecomplex and often difficult decisions in database design, the enormous task of adapting and convertingexisting 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 systemdevelopment life cycle (SDLC), and to consider the time and costs related to the staff learning curveassociated 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 leveragingobject-oriented development and rapid prototyping. Agile SDM has piqued the imagination of ITDepartment management and spawned many seeds of positive and long overdue changes within softwaresystem development methodology (SDM).

However some have misinterpreted the “Agile” buzzword by making the assertion that Agile SDM giveslicense 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 thatoffer 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. (Acomparison 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 softwarecontrol systems become incomplete, unreliable and out-of-sync with the actual software content of thesupported application. As a result, faith and use of these controls erode, and eventually these core controlsare abandoned. The most critical effect of this ruination, is the abandonment of the consistent use of thesource code library. With the abandonment of the Library as the centralised source code manager, sourcecode management becomes anarchic and “de-normalised” (spread out and with duplication). Soon, ProjectManagers (typically on contract with deadlines to meet) typically take matters into their own hands byhoarding 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, theProject 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 purposeother than as a token formality.

Later, within a few days before the release date, release management typically discovers different versions ofthe same program from separate projects (that typically have been separately managed). In a last minute actof desperation, the disparate project modifications that were made upon the common programs are quicklymerged into single combined versions. The new and untested code is then slid back into the affected projectcode packages that contained that program. Due to the fact that the original code packages are alreadychecked into the Library, these covertly performed, last minute changes are not checked into the Library andtherefore are not tracked as to the code’s whereabouts.

With such uncontrolled, decentralised and flawed source-code management, along with haphazardinstallation 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 thesource code version for any program within the Application, nor can they locate the corresponding sourcecode (that may or may not be in the Library). Additionally they do not have any record of how the softwarewas applied. Were the individual projects installed out of order? Was there any specific order in the firstplace?

Without really knowing the software content of their test systems and how the systems were built, QualityAssurance will no longer be able to guarantee that the behaviour of the system in which they performed theirtests, will be replicated in Production. Without being able to make this basic guarantee, QA itself thenbecomes invalidated. The inevitable result is the eventual crippling of the IT Department’s ability to supportthe Application System.

Purpose of this Writing

The purpose of this write-up is to describe the very basic elements, concepts and flow of proper SoftwareDevelopment Methodology (SDM) as it applies to the development and support of Application Systems by anIT Department. This core SDMmust persist regardless of whether the SDM works within an "Agile" (objectoriented), or a "traditional" (procedural language) SDM environment. These concepts have been gleanedfrom 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 inthe context of this document:

Term / Acronym Definitions

IT Department The software application (or “Information Technology”) systemdevelopment company or department within a parent company. The ITDepartment usually consists of management and staff pertaining to itsvarious business units such as: Marketing, Business Analysis, ProjectManagement, Programming, QA, Documentation (Technical Writing),Special Teams, Implementation, Systems and Operations. The ITDepartment’s main deliverables are software systems pertaining to theApplication system(s) it supports and delivers.

Software System Software Systems are the basic deliverables of an IT Department. “SoftwareSystem” has two connotations:

In its holistic sense, "Software System" can refer to the entire Applicationsystem consisting of the entire software set along with its supportingdocumentation.

Alternatively, "Software System" can also refer to the code anddocumentation set that represents a change (or an add-on) to theApplication. The “change” can be either in the form of an added sub-system, an enhancement, or a bug fix (error correction), for the mainApplication.

Project Each Software System (yes even one-line bug fixes) are created andmanaged under the umbrella of its own individual “project” each with itsown unique project number. Each project is accompanied by its own projectdocumentation (e.g. full system documentation, enhancement or changerequest documentation, or bug fix type documentation). As projects, eachSoftware System is developed, QA tested, and installed to Production,under normal project management. The source code and documentationfor each Software System is stored in the Software Library as a projectrelated Library Group, where each element within the project is underversion control. By this permanent linking of project documentation withits source code, the project helps to not only define the nature andfunctionality of the software deliverables, but more importantly, theproject helps to: a) define the scope (limits) of work, b) to provide adevelopment management unit, c) to localise and track costs, and progresswithin the confines of the project, d) to ensure uniform projectdocumentation and to link this documentation to the actual softwarechanges.

The Project Number is a crucial identification key throughout most phasesand aspects of the system development life cycle (SDLC)..


Page: 7 / 57

Library The storage and control area for source code and files . See “A1: TheSoftware Library“ within Appendix A below for description of the SourceCode Library.

Software SystemDevelopment Methodology(SDM)

The set of basic methods, concepts, standards and tools used in thedevelopment of software systems, many as prescribed by ISO 9001standards for software system development. Much of this write-up isdevoted to SDM.

Software SystemDevelopment Life Cycle(SDLC)

The SDLC is the individual IT Department’s actual implementation of SDMprinciples and concepts. The SDLC describes the phases and steps of eachproject’s development within a particular IT Department. Due to thevariances in types of business application, working environment andtechnical platforms used by each individual IT department, one company’sSDLC implementation may differ somewhat from the SDLC of another firm.However, no SDLC implementation can be viable unless it adheres to coreSDM principles.

Related Documents

Document Name Version / Date LocationISO 9000-3 A Tool forSoftware Product andProcess improvement,Kehoe, Raymond, Jarvis, Alka

1996,XIIIISBN 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 Managementand ISO 9001 – RobertBamford, William J. Deibler II

http://www.methodsandtools.com/archive/archive.php?id=36

http://www.springer.com/computer/swe/book/978-0-387-94568-2

http://www.mapwrite.com.au/quality_manual.html

http://www.methods


Page: 8 / 57

PART 1: OVERVIEW OF SOFTWARE SYSTEM DEVELOPMENTMETHODOLOGY (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 ApplicationSoftware Systems to End-User/Clients by meeting their real IT needs and their basic requirements in anefficient, reusable, well constructed, maintainable, bug-free and timely manner. To this end, SDM involvesthese basic tasks:

To accurately and efficiently clarify, define and document theUser's Requests andNeeds (Documents:Client’s Request for Proposal (RFP)), User Needs and/or Requirements, PrototypeModel document)

To do cost, time and business justification analysis, capacity planning, prioritisation, Project Teamcreation,Release Scheduling.

ToRespondwith due diligence to the Client's RFP and receive Client signoff to take the project tocompletion. (Documents: Response to RFP containing: Overview of SystemDeliverables, Cost Estimates,and Estimated Release Dates)

To accurately and effectively describe the software systemdeliverables that the client is to receive - that isthe actual definition (and legal contract) ofwork. (Document: the Functional Specification)

To design and develop the systemdeliverables in amanner that optimises the sometimes conflictingcriteria 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 programmingstandards) of theApplication, the language platform standards and the local programming standards of theIT Department. (Documents: Source code,MAKE Scripts, Design Specifications, Unit Test Log,ProgrammingGuide)

To performQuality Assurance Testing (which includesUnit, System, Regression, Negative, Integration, andLimits Tests (where applicable as perQA standards) on the new systemdeliverables. The goal is to ensurethat the systemworks as described in the FS, and does so in a fault freemanner without unexpectednegative impact on other portions of the core Application System. (Documents: QA Test Plans, Test Results,Approvals, Quality StandardsManual).

To install and implement the SystemDeliverables in "live Production" (i.e. final delivery of Software Systemto the Clients). Thismay involve User or Internal Training, special control table set-up, data conversion/re-organisation runs or special software install and new systemactivation timing . (Documents/Training:Release Bulletin, Installation and Implementation Guide, Operations Guide, End-UserDocumentation/Manuals, Actual User Training and Follow-up Support).


Page: 9 / 57

1.2 - The Ordinal Nature of Application Software System DevelopmentBefore any discussion of Application systemSDMbegins, onemust first understand the uniquely layered andserial (ordinal) nature of Application systemdevelopment. This will be explained below as an Application istraced from its initial development and then transitions intomaintenancemodewhere change layers arecontinually being applied for the remainder of theApplication system’s life span.

1.2.1 - Initial Application Development Project

The development of the original core version of any small, mediumor large Application Software System istypically performed by a project teamwhose target deliverable is the first “completed” iteration (or “version”)of the Application System. Depending upon the scale of the Application and development effort, the originaldevelopmentmay be split into several phases or layers. If the developmentwork is layered, initial layersusually provide foundational platforms for the subsequent development layers.

The number of programs that typicallymake up the core portion of the Application depends of course on thesize of the Application, and typically ranges froma fewdozen, to hundreds, to thousands or even tens ofthousands of individual program source code files. The initial versionmay take anywhere fromweeks tomonths to several years to develop (depending on scale, staff size and expertise, and development/languageplatforms).

All the software elements that pertain to this first iteration of theApplication Systemmust then be stored asthe initial versions in the Software Library. This entire software set is then linked together as a Library projectgroup. When re-extracted as a group, the entire application's software setmust (theoretically) be re-buildable(from scratch) from this extraction. The Project Number representing this initial developmentwill identify thisproject group. This Library groupwill serve as the “baseline” for the inevitability of future changes to theApplication.

1.2.2 - The Importance of "Build Order" for Subsequent Change Layers.

After initial Development, the Application System’s developmentwill transcend into "maintenance"mode,where additional Software System layers that are applied to themain Applicationwill come forth in the formofindividual IT Department projects. Each of these project layers contains a new "software system" (see above -“Definition of Initial Terms”) in the formof a new sub-systemor an enhancement or a bug fix to themainApplication. Each project layer is added sequentially to themain Application, one at a time, one on top of theother, in a pre-determined ``Build Order``.

Stabilisation of Development Platform

The reasonwhy these project change “layers” are added serially in a fixed, sequential and predefinedBuildOrder rises from the fact that each new software package technically and essentially changes the overallbehavior of the core Application (even if the project change is comprised ofmerely a one-line bug fix).

In order viably work on the development of each newproject change, the developmentmust have stable(frozen) software content fromwhich towork from. As each new change is completed, it then becomes part ofthe platform for the next change, and so on. This pre-ordered, serial streamof software application to theApplication System is referred to as the “BuildOrder”.


Page: 10 / 57

BuildOrder Still PersistentWithin a Release of Concurrent Project Development

In practice,most IT departmentswill typically work on several projects concurrently (and the projects aredelivered together as a Release). Onemight argue that this apparent concurrent project developmentinvalidates the above notion that Application systemdevelopment is a serial and layered process. But note thatwhile in fact themultiple projects within a Release are developed concurrently, there is still the assumption ofrelative order between the projects within the Release. This is especially truewhen the projects either affectone another functionally, or evenmore importantly, if a commonprogram is beingmodified bymultipleprojectswithin the Release. Therefore the individual projectswithin the Releasemust still align themselves in afixed Build Order andwill be developed andmanaged in that Order.

BuildOrder and ConfigurationMethods 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 thefunctional "software" of the project in as much as the logic within program source code define.

In asmuch as programbugs can bring the Application system to a halt, installing code frommultiple projectsout of sequence or if the software is configured improperly, can be just as crippling to the Application. Oftentimes these “build related” errors aremuch harder to identify trace and resolve than regular in-code bugs.

The importance of BuildOrder is obvious whenmultiple projects share common programs. As a hypotheticalexample, let’s say that Project 1100 and Project 1104 share a commonprogram and their respective changesare located in different routineswithin the commonprogram source code file. In this example, as youwouldexpect, themore recent changes to the common program fromProject 1104, were correctly built and added ontop of the older Project 1100’s changes. But if the software for Project 1104 is somehow installed beforeinstalling Project 1100 (in reverse order), then the changes to the common programby Project 1104would bemissing thus causing the system functionality of Project 1104 to abort with errors.

BuildOrder’s Continuing Significance Evenwith Functionally and Physically Separate Projects:

In the casewhere it seems obvious that none of themultiple projectswithin the Release share any commoncode, onewould think that in this case, the Build Orderwould be a non-issue. Thismight appear especially trueif it is also apparently obvious that there are also no functional dependencies between the remotely andphysically separated Projects.

However as wewill see later on, the BuildOrder between two seemingly unrelated projects is still an importantfactor duringQA’s Systemand Integration Testing, In QA’s holistic tests (Regression, Systemand Integrationtesting), among themandates of these types of tests are to ensure that the set of projects are indeedworkingproperly and to ensure that they are in fact not impacted by one other. By fixing their relative build order, theorder inwhich theywere installed can be eliminated as the error-causing factor in caseswhereQA testing doesindeed find problem(s) with either or both projects. If in fact the Application error did indeed stem fromanerror in the Build Order or in other automated software configuration tasks, these can be permanentlycorrected in the Software Control System and replayed and re-tested (much like a source code bug ispermanently corrected and re-tested).

Layering andBuildOrder as Underlying Foundational Concepts for SDM

In summary, the point is that in asmuch as automobilemanufacturing is only viably accomplished bymodernassembly-line processing, likewise, the basic developmentmethodology for Application Systemdevelopment


Page: 11 / 57

can only viably be accomplished by building the Application serially, applying each project change, one at a timeas "layers", in a predetermined "BuildOrder".

Proper Software DevelopmentMethodology (SDM) understands this unique serially layered nature ofApplication systemdevelopment. In part because of this fundamental, ISO 9001 proposes the dual notions of"Building Systems fromKnown Source", and "SystemPromotion" (also referred to as "Gating"). These dualnotions serve as not only as themeans to support this sequentially built dynamic of software development, butalso to serve as the backbone for Software DevelopmentMethodology in general.

1.3- SDM’s Backbone Concepts: “Building from Known Source” and “SystemPromotion (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) canonly be understood within the context of the first notion (Building from Known Source). As such, SystemPromotion 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 tothe 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 systemmust 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 tohow baseline applications are to be prepared before they are used by these IT business units. This sameBKS method is also used to create the final Production level Application (the final deliverable to theClient). The consistent use of BKS to build the Application’s software content ensures software contentconsistency 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) conceptdescribes how the software content of an Application is build up. BKS does this by applying softwarelayers from project groups within the Source Library one at a time in a predefined Build Order, andcontinuing 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 bein place beforehand. Briefly listed below is each of these BKS elements (some of these elements aredescribed in more detail in the Appendices).


Page: 12 / 57

Source Code Library (“Library”) – In addition to its ability to store version generations of sourcecode, MAKE scripts and project documentation, the Library must also be able to create and managespecific "library groups" that link specific versions of library elements. The Library must also be ableextract these elements as a group using this library group linkage. The vast majority of these librarygroups will be “project groups” that link together elements that make up the project’s files (sourcecode, project documents, compilation scripts (MAKE file), and other project related control files. TheLibrary 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. TheBOF dictates the order in which the project groups must be installed into the Application. This orderis discussed and determined during project whiteboard sessions and also by the Programming leadworking in conjunction with the Software DBA. The BOF is also a library element under versioncontrol and is managed by the Software DBA (SDBA). The BOF is actually a conceptual file (meaningthat if its function to manage and control the order in which project layers are applied is already builtinto 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 MAKEconfigures 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 theApplication System. The MAKE file is actually a conceptual file (like the BOF above), and may notactually exist as a separate file if its functions are already built into the Application platform, or theSoftware Control System.

Release Level Control File (RCF) - This file (also under Library and version control) links specific andcontiguous project groups within the Library to a Release number. This file is used by the SCS toextract a set of project groups (that are associated with a software Release), to create a ReleaseInstall Package. The Release Level Control File (RCF) is also a conceptual file (like the BOF and MAKEfiles). I.e. if functionality to arrange and manage projects groups as releases is already built into theSoftware Control System, then the RCF may not be an actual file. The Release Number itself isusually 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” (representingsmaller incremental enhancements and bug fixes that occur between versions).

Application Software Content Data (“Content Data”) – These files residing within each ApplicationSystem’s database, logs the time stamp when project group software was installed into theApplication. This Content Data also logs the present Release level of the Application. The ContentData is used by the SCS to ascertain the present software content of any iteration of the Applicationsystem. It then uses the BOF, RCF and project groups in the Library to prepare a software installpackage containing a stream of project software packages that will bring the Application system up toa 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 andinstalls 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 targetedRelease level (as per the Release Level control File) is reached and installed. The SCS also performsseveral other ancillary activities upon the Library, including code and Release analysis (extracting thecode 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). TheSCS 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 SCSis 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 andthe SCS. The SDBA monitors code check-in/check-out registers, and performs cursory review ofincoming software for conformity to requirements necessary for the software to work with the BKSenvironment (mainly the verification and testing of MAKE files). The SDBA also creates and maintainsLibrary 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 ofApplication systems in preparation for use by all IT departments and for final Production leveldelivery to the Client. The SDBA is also present during Release creation and Release Implementationmeetings 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 andknowledgeable person regarding the Application system. These might be separate persons, but theSA/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 theSystem Development Life Cycle (see section "1.3.1.5 Sample BKS Based System Development LifeCycle (SDLC)" below), b) co-ordinate the Programming Team during multiple Project Releasedevelopment and helps define the Build Order, c) performs Code Review and/or heads and designsthe code review process, d) works with SDBA to ensure system build is co-ordinated, e) reviewprocedures 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 amatter of pulling all of the elements pertaining to the project related Library group and installing the projectas a software layer onto the Application. This is an automated process performed by the Software ControlSystem (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 contentlevel (a Release Level). (In practice, the SCS might create an installation package (an .inf file) to perform thesame functions.)

The BKS process is actually executed at several points in the System Development Life Cycle, but in thisexample illustration, the BKS sequence snapshot is taken during the turnover of a Release of software fromthe 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 theProgramming Team. These three projects have been loaded into the Library by the SDBA and he/shehas set up their respective project groups in the Library. The SDBA has also updated the Build OrderFile (BOF) within the Library, with the inclusion of these three new projects (the 3 projects are to beinstalled in ascending numerical order after Project 99). Release 5.01 (which contains only these 3Projects - #100, #101, and #102) has also been added (also by the SDBA) to the Release Level ControlFile (RCF) in the Library.

2. The Software DBA (SDBA) receives a request from QA to prepare an Application System for QA Testingof Release 5.01. The SDBA will choose a baseline Application system (typically a copy of the presentProduction System). For this example, the Content Data of this Production level Application systemshows 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 softwarecontent level to the target level (Release #5.01). The SDBA feeds the SCS just two parameters: 1) thelocation 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 presentsoftware 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. Fromthese scans the SCS is able to deduce that in order to update the target Application System’s softwarecontent 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 inthat 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 theinstructions that describe the configuration, compilation instructions, and set-up instructions forinstalling 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 isthat 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 thedate/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 .INSfile will do this update as its final step).

Figure 1: The Basic BKS Build Sequence

Start SCS BKS Build

Get Parameters fromSDBA

Enter: Target App System andTarget Software Content Level Library

BuildOrder File

Target ApplicationSystem

SoftwareContentData

Programs

ReleaseLevelControlFile

ProjectLibraryGroups andProjectElements

Determine SoftwareContent of Application

Determine Build list ofProjects to Apply andOrder of Application

TargetReached?

ExtractProjectSoftwareFrom Project

Install ProjectSoftware

A

A

Update SWContent 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 overdoing 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 thesoftware layers (projects) were applied to the Application. The way in which software layers areinstalled can "make or break" the system. Manual software installation errors could result in projectsbeing installed out of sequence. If set-up tasks are executed manually via interactive screens, and iferrors occur, the log of this activity and resulting error is usually lost. By automating the installprocess, 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 ofprojects (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 becomeboth unwieldy and error prone with little audit trail as to where errors may have occurred. Mostimportantly, 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 mightbe requests to produce the Application system where the software content must be contemporarywith a certain point in time (i.e. restoration of an old Clients database for special runs, or for archivedata reporting). This can be achieved by the automation of BKS builds by the SCS. It providesfacilities to "replay" a sequence of project layer installs until it reaches a specific software contentlevel 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 fromKnown Source" (BKS)method, thefollowing are four crucial goals and benefits of BKS:

1. To Ensure Control and Consistency of Software Contentwithin theApplication

2. To Implement SystemPromotion (Gating)

3. To Ensure that the Software Content of Application System is “Known” by direct linkage to the Librarywhere links to a project's software set and documentation can be readily accessed for support and futureenhancement of the Application.

4. To Provide a Framework for the Entire SystemDevelopment Life Cycle (SDLC).


Page: 17 / 57

1.3.1.4.1 - Goal #1 of BKS: Control and Consistency of Application Software Content

Amajor goal of Building fromKnown Source is to ensure the consistency and accuracy of the software contentof the Application System. This is accomplished the careful tracking and control of the source code in theLibrary and directly using this source from the Library to build the software content of the Application. Secondlyby adhering to a pre-defined Build Order, themanner inwhich software is applied to the Application iscontrolled, published, and fixed. By using the automation of SCS's build functions (instead of reliance uponmanual efforts) ensures that the software content of the application is built consistently as it is promoted fromDevelopment, 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 systemhas been built from the groundup, using thesameBKSmanner of sequentially applying project group layers taken directly from the Software Library andapplying these layers in a fixed BuildOrder. The Theoretical BKS concept startswith an “empty” Applicationsystem skeleton (devoid of software). The "Build" starts by applying the first project groupwhich is theentire 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 projectsmay pertain tomajorreleases, added sub-systems, small, mediumor large enhancements, change requests and bug fixes. Thebuild applies each project software systempackage layer one at a time in their proper BuildOrder until theApplication 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 froma previously established baseline (such as the currentProduction level) and then applies specific Project groups from the Library on top of the baseline until thetargeted version level is reached. This "Usual Practice BKS" assumes that the beginning baselineApplication systemhas already been built as per the above "Theoretical BKS"manner, and therefore, (if infact, these baselines are available) there is no need to replay the build prior to the baseline.

1.3.1.4.2 - Goal #2 of BKS: System Promotion (Gating)

The process of Building fromKnown Source (BKS) is themethod used to prepare the software content of theApplication system that is to be used by everymajor sub-departmentwithin the IT Department. BKSbuildssystemsof specific version content for Programming (for development), then for QA (for Testing) and ultimatelyfor the client as the final deliverable "Production" system, thusmoving a Release of software through itsdevelopment stages in process called "SystemPromotion" or "Gating".

The following sequence shows howa software Release is “Promoted” through the IT Department by BKS:

Development (ProgrammingDepartment): BKS builds a specific baseline system fromwhich Programmingcan add their changes. The baseline is usually just the Production baseline, but often times the baseline canbe based on the Production level plus otherWork-in-Progress (WIP) projects (that have already beenchecked into the Library and that are also part of the next Release). In this way BKS facilities help theProgrammingDepartment stabilise their development platforms, and also helps to co-ordinate thedevelopment of concurrentmultiple projects by promoting the culture that adheres to a predefined BuildOrder. The Library's software reservation systemalso helps co-ordinate concurrent project changes upon acommonprogram (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 isadded to a Release. In this way, the project software is readied to be passed (or "Promoted") toQA fortesting (or re-testing).

Quality Assurance (QA): For QA, BKS produces Systems in the sameway - by applying completed Releaseproject changes from the Programming Team intoQA test systems. The SDBA applies these changes inBKS fashion as described above in the above section "1.3.1.2 - Example: The Basic BKS Build Sequence". Inthis controlled scenarioQA can test with confidence that any system configuration and build order issueshave been eliminated, and that only the known (and expected) changes have been introduced to their testsystems. Within the BKS scenarioQA tests not only the code changes, but also the buildmethod.

Production: The same buildmethod used to build theQA test systemswill be the same oneused to buildthe system that is delivered (or Promoted) to the Client as the Production system. By replaying the samebuild (from Library source)method, BKS ensures that the system that QA testedwill be the same that isdelivered to the Client because theywere both build in the exact same fashion.

Thismethod of using BKS (as described above) tomove new software development fromone developmentphase to the next (DEV->QA->Prod) by controlling its configuration and build order, iswhat as known asSystem“Promotion” (or “Gating”).

This same buildmethod of BKS also produces systems of specific versions for other IT sub-departments forvarious reasons. The BKSmethod allows for building of Application systemwhose software content reflects alevel 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 Productionversion).

Implementation/Conversion Teams: BKS builds systems of specific software version baselines for theirimplementation set-up, or for conversion or de-conversion projects. Implementation teams generallychoose the current and latest Production baseline, but De-conversion Teamsmay choose a baseline that iscontemporarywith the software content level that the de-converting clientwill possess at the estimateddate of de-conversion.

Operations: BKSmay need to build systems based on the software release level fromprevious years intheir special requests for archive, year-end, or prior year tax reporting, thatmay require processing onolder databaseswhichmay contain data structures that are incompatiblewith 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 usingthe BKS build process are:

1. For any program in the Application, one can find its exact corresponding source code version in theLibrary. 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) ofthat project within the Library.

3. Because all versions of a program are in the Library, all generation changes can be identified (via toolsoffered 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 theProject Documentation that also describes the nature and purpose of the changes. In fact, allchanges made by the project (plus all the project's documentation) can are extractable andidentifiable by SCS functions operating on the Library (see "A2.1 SCS Utilities to Service ProgrammingDevelopment" 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 controlthe 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 Productionreceives the exact same software content that was tested by QA. In this BKS environment, QA notonly tests the functionality of the software changes, but also tests the Build Order and individualMAKE 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 ofsoftware, and having ready access to project documentation, the BKS system build environment tofacilitate programming maintenance support, and future enhancements. Most likely, bugs that arereported just after an install of a Release usually stem from the changes pertaining to the recentRelease. Traceability and understanding of previous project related code changes within the Releasenot only tremendously helps bug support, but is also crucial in the design approach of future projectenhancements.

System Backout: The dependable identification of code changes pertaining to individual projects andto a Release, and the manner in which BKS builds systems, also creates a framework that facilitatessoftware system back-out mechanisms. Coding standards and QA criteria can be created to requireadditional 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 includechecks 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 Librarycontrolled sequential system building affects the Coding Standards within the Programmingdepartment 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 installedduring implementation and the inclusion of viable back-out facilities). Code Reviews are thentailored to enforce these BKS related design requirements.

Effects on QA Standards and Methodology: BKS also affects the flow of work in QA. In the BKSstructure, application systems are always built only from the controlled environment of the Library ina one-directional "promotion" or movement of software. For instance let's look at a QA resubmissionscenario where bugs that are reported by QA. In this resubmission, the project is sent back toProgramming for rework. In the BKS environment, when the Programmer completes his/her bugcorrections, the completed fixes/rework are NOT handed directly back to QA, but instead, the reworkmust be checked-in to the Library where the Project group is then updated to include the reworkedprogram 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 theactual 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) fromKnown Source actually provides the basic workflow framework forall work phases in the SystemDevelopment Life Cycle (SDLC). This is best illustrated in the next section "ASystemDevelopment 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, SystemDevelopment Life Cycle (SDLC).

This example emphasises howBKS / SystemPromotion provides the framework for the SDLC from the handlingof the Client's RFP, to how SDLC activitiesmove the developing system in/out of the Library, promoting it fromonebusiness unit to the next. (Figure 1) Some of the differences between Agile SDMand Traditional SDM (T-SDM)will also be highlighted. Following this narrative is a diagramof the same SDLC.

1. ClientMeeting andRFP: This hypothetical SystemDevelopment Life Cycle beginswith the Clientrequesting a change to the Application System. This can be either a phone call from the Client to theClient'sMarketing Representative. In this instance if the "Client" is external to the IT Department, aRequest for Proposal (RFP) is issued from the Client. The External Client is informedof theminor costs ofprocessing the next 4 steps that are payable by the Client regardless ofwhether or not there is a go-aheadto continuewith the project.

2. UserNeeds or Prototyping: After the above request has beenmade, theMarketing and Business Analyst(B/A)meetwith the Client to further ascertain and define the Client's needs. In the traditional SDMenvironment, a draft of theUser Needs document is created after discussionwith the Client. In an AgileSDMenvironment, a Programmer/Analyst is also invited to help create and run real time Prototypes of theproposed changes, while the Business Analyst supplements the Prototypewith a “Prototype ProcessingSummary”. The Prototype Processing Summary summarises the changes represented in the Prototype aswell as outlines significant behind the scene processing details thatmay not be readily observed from thePrototype. (For non-external, internally initiated changes theUser Needswill simply be a brief listing of theintended changes, written by IT internal staff.)

3. White-board Session#1 – Discussion of SystemApproach: (Attendees: SystemArchitect (Chair),Programmer/Analyst, Business Analyst. Purposes of thisMeeting: a) Discuss systemdesign approach ofthe changes (discussion led by SystemArchitect assisted by P/A). b) Discuss scope ofwork and create roughWork Estimates by P/A. c) P/A to passWork Estimate to Business Analyst and aQAAnalyst to add theirestimates.

4. Cost Benefit & Capacity PlanningMeeting: (Meeting Attendees:Marketing Representative (Chair),Business Analyst (whodid theUser Needs or prototyping), SystemArchitect/Team Lead, QAManager,ProgrammingManager, ITmanager,MarketingManager). Purposes of thisMeeting: a) Determine urgencyand priority of proposed changes via cost/benefit analysis (based on theWork Estimates created as a resultof the aboveWhite Board Session, b) Determinewhich Release the changewould fall into (as this woulddetermine the estimated date of systemdelivery), c) Determine if there is enough staff capacity to create aProject Team for this request d) Finally, decidewhether or not it is in the best business interest to go aheadwith the project.

5. Response to RFP: Response to the Client's Request for Proposal with Cost Estimates, copy of User Needsand/or Prototype Processing Summary and Estimated CompletionDate. If the Client accepts the response,then continue, otherwise this project closes and the Client (if external) is invoiced for themodestprocessing fee for the RFP asmentioned in step 1 above.

6. White-Board Session #2: - Project Creation and Scheduling, Set Build Order: (Attendees: SystemArchitect(Chair), ProgrammingManager, QAManager, SDBA, ProjectManager and Business Analyst tentativelyassigned to this project, and finally, ProjectManagers fromother project teams thatmight be affected or


Page: 22 / 57

impacted by this project). Purposes of thisMeeting: a) To create Project Number and select and set ProjectTeam, b) Overview SystemDesign and approachwith the team, c) Determine Project's Build Order bydiscussing shared code issueswith otherWIP Projects (see "section variant streamdevelopment" below),or any other Architectural consideration thatmight 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 towork. In Traditional SDM, the FunctionalSpecificationmust be completed by the Business Analyst and signed by the Client before the Project cancontinue. (In Agile SDM, this step (7) is not required because the Client's go-ahead approval wasmadeearlier in step #5. In Agile SDM the FS development becomes a collaborative effort between the BusinessAnalyst and the Programmer/Analyst beginningwith the secondWhite Board during the coding phase. Thecompleted FS then is delivered for Client sign-off at the end of the Project. See "2.1 – Agile SDM– Variationson the SystemDevelopment Life Cycle" below.)

8. Project Group andReleaseUpdate in Library: The Software DBA (SDBA) now creates a project group forthe newproject in the Library. The SDBA also inserts the Project Group into the BuildOrder File. If theRelease, in which the Project belongs to, has not yet been created, the SDBAwill also create the Release inthe Release Level File (RLF) and inserts the Project Group under the Releasewithin the RLF.

9. BKSBuild #1: Baseline Creation for Programming: The SDBA creates a baseline system for the Project'sProgrammer/Analyst to beginwork on the Project Changes. This baseline system is either the CurrentProduction level Application System, or Production plus anyWIP Project software that precede the Projectas per the BuildOrder. On-going co-ordination (headed by the SA/TL) between these concurrentlydevelopedprojectsmust bemaintained to continually retrofit on-going changesmade by the precedingprojects (that are alsowithin the sameRelease) onto the Project's baseline system.

10. CodeReservation: Before any coding can begin, if an existing program is to bemodified, theProgrammer/Analystmust reserve the code from the Library. If the code is already reserved for anotherproject, this situationmust be co-ordinated by the SystemArchitect/TeamLead (SA/TL) in conjunctionwiththe ProjectManagers of the projects that are linked by the common code. While the relative Build Orderbetween projectswasmostly determined duringWhiteboard Session #2, if the SA/TL is in agreementwiththe ProjectManagers to revise the Build Order, theymust also inform the Software DBAwhomust updatethe Build Order File (BOF).

11. Programming: From the BKS perspective, theDevelopermust be cognisant of the guidelines ofprogrammingwithin a BKS type environment. See section "2.3.2 - ProgrammingGuide in the BKSEnvironment" for a summary of these guidelines.

12. CodeReview: This review is normally the domain of the SystemArchitect/Team Lead, but even ifdelegated to another Programmer/Analyst, in addition to reviewing the code against the ProgrammingStandards, the CodeReviewmust 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/ ReleaseManagement: Upon Code Review approval, all source code, theMAKE file, and other files completed by the Programmer and the Business Analyst (for Agile SDM, thecompleted draft of the Functional Specification) are given to the Software DBA (SDBA) to check into theLibrary. The tasks of the SDBA in this instance are: a) to check to ensure that the source codewas originallyproperly checked out, b) to create new versions of the submitted files during the check-in process, c) toupdate the project's library group linkages to include these project elements.


Page: 23 / 57

14. BKSBuild#2: SDBA Installs New code toQA Test System: The SDBA selects a baseline Application andinstalls the newProject group into the Application using themethodology as described above in section“1.3.1.2 - Example: The Basic BKS Build Sequence:”, and presents this system toQA for testing.

15. QATesting : TheQA test plans are created for Unit, System, Integration and Regression testing. Testingmust take into account at least 3 levels. a) To Unit Test this Project against the Functional Specifications(which is also reviewed byQA). b) To run Systemand Integration testing of all Projectswithin the upcomingRelease. c) To run Regression tests of themain application at least on the core Application functionalitythatmight be affected by the Release software.

16. QAResubmissions: If bugs are found in the newproject code, the Project is resubmitted back toProgramming for correction. In this case, the BKSwork flow reverts back to Step 10 above, where theerrant code is reserved again, this time for bug fixing.What ismost important to note in this instance, whenthe error corrected code is completed, the revised codewill be checked into the Library, the Project groupis updated to include the latest fix, and theQA test system is re-prepared by rebuilding it (in BKS fashion)with the new codebeforeQA can test the error corrections. In this way, BKS buildmethod preserves the(QA testable) software build integrity of the Application.

17. ReleaseDocument Preparation: The Release Bulletin, Implementation Guide, User and TrainingGuides(for each project), andOperations Guides are created as needed. See "Project Documents within SDM:Traditional Verses Agile" below formore details on these project documents.

18. ReleaseMeeting: Making sure all is in order: (Attendees: SDBA (Chair), andQAAnalysts fromall projectsassociatedwith release, Operations Lead, Client Care Lead, Implementation Team. Optional as Required:QAManager, ProgrammingManager, OperationsManager, SystemArchitect/TeamLead). QAAnalystsoverview the readiness of each project and go over any known loose ends, reviewand schedule anycritical/complexOperations tasks runs, review inter-project dependencies, discuss training issues or anyother implementation tasks that are part of the rollout of the Release. If some projects have to be pulledfrom the Release, the Release Bulletinmust be amended. Scheduling is nowmade of the exact time ofissuance of the Release Bulletin. Operations ismade aware of any special runs thatmay be required as partof the release rollout and they are given theOperations Guides for these purposes. A Release InstallationSupport Team is now assembled: their task - to act asmonitors and support staff for the actual install of theRelease Package. At end ofmeeting, the SDBAprepares the software install package and prepares theinstructions forwhen and how the package is to be installed to the Client's Application system(s).

19. BKSBuild #3: Production Implementation: Systembackups are scheduled and executed. A BKS Build isused to create the Production Install package. Software is installed to the Client(s)' Application systems. TheRelease Installation Support Teammonitor the installation andwill either: a) signal that the Releaseinstallationwas successful and that the Client can continue using the Application, or b) alert all parties thatthe installationwas unsuccessful, and arranges the execution of Release Back-out procedures. UserTraining (if required) is scheduled. Implementation Staff (in conjunctionwithOperations if required) carriesout any set-up procedures thatmay be required as part of the Release's implementation.

Figure 2 - SystemDevelopment 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

ClientGo-Ahead? Admin Charges Quit Task

Step 9: BKS Build #1: Base-Line for Programming

Software Library andSoftware Controlsystem

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 andImplementation 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 DevelopmentMethodologymay offer realimprovements and streamlining upon traditional SystemDevelopment Life Cycle.

With its powerful prototyping facilities, Agile SDM indeed offers better up-front understanding of the client'sreal needs and Requirements. Also by leveraging the facilities of the prototype, Agile SDM can also offermuchquicker project completion times over traditional SDM. Agile SDMalso streamlines certain aspects of thetraditional systemdevelopment life cycle.

Agile SDMwas in part,madepossible byObject OrientedDesign (OOD), and the rapid Prototyping that OODtools affords, and byObject Oriented Programming (OOP) that utilises a library of readily "reusable objects".The developer uses these to build the Applicationmuchmore rapidly and easily without redundant code andlogic.

The real benefits of Agile SDMare undeniable and some of its revisions over traditional SDMare indeedwelcome and long overdue. Among these benefits are:

Prototypingwith Client: Since the Business Analyst andDeveloper show actual prototypes to the Client,the Clientwill have amuch better and up-front understanding ofwhat they are getting andwill have amuch better idea ofwhether the solution is trulywhat they need. Through viewing andworkingwith theactual prototype, the Client can see first hand how the systemwill address their issue(s). The Client caninteractwith the prototype, andwith IT personal present, together they can fine-tune the prototypewiththe Client’s direct feedback. This prototyping phase can cut downon project costs, reduce developmenttime, and reduce the chance for cost-overruns by reducing the need for Change Requests (that are theseeming inevitablywith traditional SDM). Asmentioned in the step #2 in the above hypothetical SystemDevelopment Life Cycle, this prototyping phase is unique to Agile SDM, and the created prototype itself canused in place ofmuch of the traditional "User Needs" document that has been part of traditional SDM.

Concurrent Functional Specification and SystemDevelopment: Traditional SDMmandates that theFunctional Specification (FS)must be completed and signed off by the client before any actual codingbegins. This is because in the traditional SDMwork flow, the FS provides the guidelines for bothProgramming andQA testing, aswell as acts as the legal definition of deliverables for the project. Someofthe drawbacks to this traditional approach are:

a) Since the FSmust bewritten before any actual coding changes take place, the FSmust "predict" thedetails of the system that itmust eventually describe in detail, and

b) Programming is held upwhile awaiting signoff of the FS.

In practice however, unless the FS resorts to vagueness and generalisation of several important details,very rarelywill the FS define all of the pertinent details of the Software Systemwhich has yet to be coded,unless these details are added as revisions after the FS has been signed off. This situation is worsenedwhen the Programmer/Analyst is not allowed to collaboratewith the Business Analyst and the latermustcomplete the FS as a sole effort.

Agile SDM: Prototype used as Client Sign-off Vehicle forWork Commencement


Page: 26 / 57

With the prototype being an adequate description of the eventual software deliverables, the Client can usethe prototype (that is accompanied by a supplementary Prototype Processing Summary) can be used as asign-off document to signify that the Client commits to the project until its completion and delivery. (Intraditional SDM, the Clientmust sign off on the completed Functional Specification before committing totaking delivery of the system.)

In Agile SDM, the Functional Specification is developed concurrently with the prototyping/coding stagebecause the end-user signs off on the prototype (as opposed signing off on the completed FS) as the signalto allow coding to begin. In this way the FS can be developed alongside the project. In this approach theFS loses its work commencement signoff, and someof its programming template roles, but retains its roleas the legal description of systemdeliverables.

This allows the FS to be developed as a joint effort by both the B/A and P/A so that it will itmore closelymatch the system it attempts to describe. This collaborationwill benefit the FS from the uniqueperspectives of both the B/A and P/A. Also, depending on the object oriented prototyping tools, someprototyping tools can generatemuch of the content of the FS. In this way, the tasks of the BusinessAnalyst (as the primary author) the FS creation can be accelerated andwillmore accurately describe andmatch the systemdeliverables.

Controversy:

There is still controversy aboutwhether the FS should be developed alongside the code because intraditional SDM, the programming ostensibly is based the completed FS. Agile SDMoffsets this concern byusing the Prototype and its supporting document as sufficient template for Programming. The FS (in theAgile context), becomesmore of a "systemdescription" as opposed to beingmore of a "proposed solution"document for Client signoff within the traditional SDMscenario. To this author, this is one of the bestimprovements on traditionalmethodology by Agile SDM.

In the traditional SDMscenario, the FS development has always been in a bind. As a systemdescriptionand legal contract of software systemdeliverables, itmust faithfully and completely describe all aspects ofthe new software system layer. Yetwithout 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 committedto the project,making it difficult for IT commit anymore resources for the resource intensive task that isthe FS. Asmentioned above, the software system itself has not yet been created, so in essence, the FSmust “imagine” the system itmust describe. Due to commonbut unfounded fears that the Programmer'sperspectivewill skew the FS away from its original business intent, often times the Programmerwill not beallowed to collaboratewith the Business Analyst in creating the FS.

Source Code gleaned fromPrototype: Depending upon the features of the Prototyping tools used, asignificant portion of the programming can be either taken directly and/or indirectly from the prototype intheAgile SDMdevelopment 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 asembeddedwithin systembuild scripts), and/or partially generated by the prototyping tools and/or by codecomparison tools from the Source Library facilities. With the ability (in the PKS environment) to obtainlistings of all program changes and Function Specifications pertaining to any project, thesemay precludethe need for the Design Specification altogether (see section "Appendix B: Project DocumentsWithin SDM:Traditional Verses Agile" regarding the DS).


Page: 27 / 57

OOPenforcement: In an indirectway, Agile SDMcreates a natural enforcement upon the programmingdepartment to abide by the basic rules of Object Oriented Programming (OOP) - in particular to ensure thatthe programming department does indeed build,maintain, control and fully utilise its library of reusableobjects (withoutwhich theywould not be able to keep upwith the pacewithwhich Agile SDM imposes).

In Summary, it becomes evident thatwhile the Agile SDMdevelopment cycle streamlines and quickens theSystemDevelopment Life Cycle, none of its feature alters the basic software controls and systembuild SDMcore concepts of Building fromKnown Source and Software Promotion.

2.2 - Project Management: Mandate to Avoid "Scope Creep" in BKS SDMEnvironment

The purpose inmentioning ProjectManagementwithin this discussion of SystemDevelopmentMethodology(specifically within the Build fromKnown Source (BKS) development environment context), is not somuch todescribe basic ProjectManagement (a type of training that is readily available).

Rather this section re-emphasises one of themost fundamental principles and goals of the ProjectManagement principles – that is to control and freeze the scope of a project. At the same time there is also theintention to dispel some fallacious notions about ProjectManagement, that have come about as a result ofmisguided understanding of the real purposes of Agile development.

2.2.1 - The "Change Request Project" as the Proper Channel for Project RedirectionBefore getting too far into the topic of this section, it is important to know that proper ProjectManagementmethodology channels any request for change(s) to an original project's specification intowhat is known as a"ChangeRequest Project". These Change Request Projects are processed as separate and newprojects via thesameBKS based SystemDevelopment Life Cycle (as described above in section “1.3.1.5 Sample BKS BasedSystemDevelopment Life Cycle (SDLC)”), just like any other project. But Change Request Projects are allowedspecial 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 ManagementHowever, in asmuch as the "Agile" buzzword has been used by someas an opportunity to abandon the criticalsoftware controls afforded by SDM (as alluded to in the Preface), "Agile" has also been interpreted by some toimply "flexibility" tomodify a project’s scope before the project is completed and delivered. Specifically, thisinterpretation states that Agile development not only allowsmid- project changes (i.e. "scope creep"), butdescribes scope creep as awelcome featurewithin the newer development environment of Agile SDM.

The following paragraphs explain the dangers of this fallacy andwhy "scope creep" is still unviable evenwithinanAgile SDMenvironment. Moreover, the paragraphs explain how scope creep goes against the very basicaims of proper projectmanagement, and undermines the processes of Build FromKnown Source (BKS) baseddevelopment structure.


Page: 28 / 57

2.2.2.1 - Unrealistic Expectations of "Agile" OOP DevelopmentThe ability to prototype in anObject Oriented Programming (OOP) development environment doesmakesoftware developmentmore efficientwith less duplication. However, nomatter how efficient and objectoriented the programming platform, it is still not an environmentwhere sudden changes in functionalrequirements (scope creep) can viably be accommodated.

Architectural Commitment Point of NoReturn:

WhileOOPbenefits from the re-use of pre-written objects, it is the assemblage of those objects and thecreation of newobjects that not only inherit the behaviour of themore generic objects, but also increasinglyadds behaviour that is more specialised to the present project's functional goals. This growing specialisationeventually "commits" the project work to the functional goals of the original project specifications, as theoverall architecture becomesmore functionally specific. Because of this, within a short time this commitmentpasses a point such that if therewere a need to significantly revise the original functional goals, it would actuallybe best to start from scratch, where only themost 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 otherProject documentationwritten to that point. Thesemust all be reviewed either for heavy revisions orwholesale replacement.

Convoluted andDead Code thatmust still be tested:

Programming is never simply coding. It also involves extensive analysis, architectural design and approach inthe design of program structure before coding begins. This design and structure is not only optimised towardsthe 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 architecturewill beimmediately compromised. Rightfully, the entire architectural analysis should be repeated. Unfortunatelytime pressures usually forces the project into a dangerous path - to attempt to shoe-horn the new logic usingthe original code as baseline. This attempt to leverage original code to ostensibly expedite the coding processcreates several serious problems. As described below, this path to leverage original code as the platform for thechange request creates problems that aremore costly in time and effort than if the project had been restartedfrom scratch.

While screen and report prototypes can be relatively easy to redo (as they are literally drawnwith an objectoriented editor), it is the underlying supporting business logic routines that aremanually written andmuchmore complex. An attempt to shoe horn the change request logic into these complex routines thatwereoptimised and structured to accommodate the original specifications, usually results in the following:

a) The resulting programswill contain dead code that still must be somehow tested.

b) The programswill contain convoluted logic that is hard to follow and support in the future. Thismess willinevitably be inefficient and bug pronewith bugs that are especially difficult to fix given the convolution of newlogic retrofitted over the structures thatwere originally designed and optimized for the old business logic.

c) QA's Test Planswill have to be rewritten to include testing of a system thatwill have inexplicable attributesfrom the original Functional Specification. If QA has thewherewithal to reject the package because of thosedead attributes, this will force amandate to rewrite everything from scratch. After the inevitable shoutingmatches betweenQA and ProjectManagement the project have to choose between either of two undesirablepaths. Either QAwill be forced to allow the convolution to pass through (so as tomeet deadlines), or the


Page: 29 / 57

resulting rewritewill force the project to be pulled from the present releasewhere it will miss its deadline. Theproject in this casewill either be relegated to another later release, or permanently shelved.

d) If the project's timetables are such that it cannotmake the present release, it will have to be pulled fromthe release. If other projects have code thatwere built on top of this project, the other projectswill beadversely impacted aswell, since they have to remove the logic changes associatedwith this project from theircode and those other projectswill have to redo their tests.

2.2.2.2 - Allowing "Scope Creep" Undermines the Basic Goals and Metrics of Project ManagementAfter requirements andwork specifications for a project have been defined, the very basic and core aims ofbasic projectmanagement are to:

a) Ensure that the project deliverables are ready by the estimated duedate.

b) To providemetrics and statistics of the time and resources used by the project. Thesemetrics and statisticsare the crucial business data tomeasure costs (and thereforemeasure revenue), tomeasure performance, totrackwork progress and to do future project planning.

Yet all of these statistics andmetrics are lost when "scope creep" is allowed to entermid-project andwhen theoriginal project's deliverables are never allowed to reach completion. All metrics tracked by a project aremeaningful onlywhen the tasks (measured against the unchangedwork specificationwith predefined scope)have reached completion.When the incomplete statistics from the original work specification aremergedwithstatistics from the new specificationwhich leveragedwork from the incompletework of the first effort, neitherstatistics set is complete, and both sets becomeuseless. With projectmetrics thus ruined, the project isreduced to a drudging and desperate effort to somehowbring closure to the project after all previous deadlineshave been hopelesslymissed.

With a working environment that allows scope creep, work estimates, cost analysis, scheduling, estimation ofcompletion dates, and performance tracking all become impossible to gauge. An attempt for any type ofestimation for future projects is reduced to a guessing game. The inevitable failure tomeet customersatisfaction in terms of functionality and timeliness of software deliverableswill be unexplainable since ProjectManagement cannot reliably produce estimates, produce clean software, nor control its own costs andprocesses because of improper projectmanagement practiceswhere scope creep is the central problem.

2.2.2.3 - BKS/System Promotion Based SDM Assumes Fixed Project ScopeAllmechanisms of Software Developmentwithin the context of BKS/SystemPromotion SDM is based on thebasic understanding that the scope and definition ofwork has been defined in the very early part of the SystemDevelopment Life Cycle (SDLC).

Once the Client has signed off to commencework, there is an implied commitment to carry through on theintended 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 placeat the beginning of the Life Cycle in order to permanently define and freeze the nature and scope of changes.Onlywhen the project scope has been fixed and determined, is the project then integrated into the Releaseschedulewhere other projects are also being developed and are collectively co-ordinated in conjunctionwiththis newproject. The newproject is then promoted from theDevelopment phase, toQA testing and finally toProduction via the BKSmethod 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 thatwere set during theWhite Boardingsessions are all based on the original project specifications,

b) Any changes to the any of the project specificationsmay not only force rework within the project where thescope creep occurred, but alsomay force some rework and re-testing of other projects in the release, andmayalso force undesirable extensions to the Release date.

c) QA testing always requires a frozen test basis. Any "scope creep" introduced to their test areas completelyinvalidates all previous testing and forces a repeat of all holistic system tests.

2.2.2.4 - Real Quality verses Unprofessional and Absurd Expectations

Noone 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) 10minutes later, just before thewaitress gets ready to deliver the food, you announce to thewaitress thatyouwant to replace the hamburger/frieswith a plate of steak and eggs.

c) You demand that you only expect to pay the hamburger/fries price for themore expensive steak and eggs.

d) In addition, you blame thewaitress for the fact that you're starving and,

e) You demand that the steak and eggs be deliveredwithin 3minutes of your new steak order. (Yourreasoning: Since the hamburger/fries came3minutes earlier than the 15minute allowance for order delivery,you expect the steak and eggswithin the remaining 3minutes).

As absurd is the above example, it is equally absurd, unprofessional and disastrous for any softwaredevelopment company tomake it a practice to react to customer's project change requests by simply droppingthe original order and attempt to try to fill the new change request under the terms of the original order. Nobusiness entity can viably conduct their business like that.

Yetwithin the performance-based, hired-contractorworking environment of IT, where pandering to thewhimsof the client can get the contractor valuable references, especially if their contract expires at the end of theproject, this absurdity has become commonplacewithin IT software development. With congratulatory lettersand glowing references in hand, the contractors can leave at the end of the projectwell before the productdeficiencies surface. The blame for the inevitable late delivery dates, and software bugs and functionaldeficiencies can easily attributed to performance issues on the part of the Programming andQA staff who,withtheir “Agile” development facilities, were theoretically supposed to be able to deliver as planned.

In anyQuality seminar that defines the attributes of real quality and real customer satisfaction, there isinvariably the following axiom:

RealQuality is not really all about "Giving the customerwhat theywant and demand", but rather, it is about"Managing andMeeting (or Exceeding) their Expectations."

Just as the above absurd customer expectations in the above restaurant scenario should never be allowed,properlymanaging customer expectations regarding software systemdevelopment and carrying out thebusiness of software development responsibly andwith proper disclosure of those deliverables should insteadbe 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 SystemDevelopment Life Cycle(SDLC)", showed how the Client's original RFPwasNOTmetwith non-researched and flippant promises.Instead, the Client's request was properly channelled into the IT Department's existing SDLC processes forpreparing a response to a Client’s Request for Proposal (RFP). The RFP response includes Prototypingmodels orUser Needs definition, alongwith realistic work and time estimates that are based on past project statistics andmetrics.

Of particular importance, also note that the response to the RFP disclosed the following IT department'sAgreement and Terms for the project:

a) The IT departmentwill not continuewith the project unless the Client signs a commitment to go throughwith the proposed changes.

b) Once Client signs the commitment to go aheadwith the proposed changes they implicitly agree to take theproject to completion and to take delivery of the software system as described.

c) The Client also agrees that the “ChangeRequest Project” processwill handle any subsequent revisions orchanges to the original specifications that aremade before the completion of the original project. The ChangeRequest Project process is essentially another follow-up project thatwill follow the same development path asthe original project (including its own cost and time estimates). However Change Request projectswill bescheduledwith special priorities as needed, so as to coincide (as closely as possible)with the delivery of theoriginal 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 companieswith vastlydifferent businessmodels. One company (PDMSystems, Inc.) uses the systemdevelopmentmethodology asdescribe herein, while the other company (SAF Rapid Software, Inc.) does not take thismethodology seriouslybecause it is considered unnecessary for its businessmodel. While the names are fictitious, the story linewastaken from actual situations.

In this hypothetical scenario the two competing "software-house" companies are: "SAF Rapid Software Inc."and "PDMSystems, Inc." (abbreviated as "SAF" (implying "Slap and Fix") and "PDM" (implying "ProperDevelopmentMethodology") respectively). Both SAF and PDMproduce andmarket a software package forsmallmanufacturers that performed basic accounting (A/R, A/P, Order Entry, Payroll, Sales Analysis, etc.) andmanufacturing related functions (Inventory, Bill ofMaterials, Job Costing) for small andmedium sizedmanufacturers.

The businessmodels differed dramatically between SAF and PDM.

At SAF, the emphasis and revenue dependencywas upon unit sales of their software package. They confidently(perhaps overconfidently) considered their product as a "Turn-Key" package,meaning they felt that once thecustomer broke the shrinkwrap of their software package, SAF's involvementwith the customerwas essentiallyover. At the timeof this example, SAF boasted over 30 customers of their package, and yetmanaged all ofthemwith a staff of 6 personnel, thus showing their emphasis and aim in unit saleswith support as a non-revenue producing after-thought or “necessary evil”. Since SAF considered customer support an afterthoughttherewas no software developmentmethodology or projectmanagement infrastructure for customisation, orsupport services. Most of the SAF’s 30 customers cameon early when the packagewas first debuted, but SAFhas not taken onmuchmore since that debut, since their small 6 person staff has been tied upwith unwantedemergency calls and issues from clients. Customisation for any one clientwas coded in a hasty, unstructured


Page: 32 / 57

purpose-driven and expedientmanner. As such, any customisation effortmade by SAFwas non-reusable forany other client.

At PDM, the emphasis and revenue dependencywas upon software system support services, meaning theirbusinessmodelwas to establish a long-term relationship via a support services contractwith the client. PDM’scontractual and business aimwas to tailor their software application package to fit the client's needs. Theirmain applicationwas heavilymodularised and structured (in object oriented fashion) to allow for heavycustomisation and support of this customisation. PDMused the BKS based SDM (as described in this document)as their software developmentmethodology. PDMbased their revenue not only on unit sales, butmuchmoreso upon a schedule of types and duration of services rendered to the Client. As a software house supportingmultiple customers, parts or all of each customisationwas designed to be generic and reusable by other clients(object oriented). At the timeof this example, PDMhad only 15 clients, supported by a staff of 15 people, butthe rate of client additions and staff growthwas accelerating. (In their 5 year existence, they grew from5 to 15clients, and their staff grew from6 to 15 people in only the last couple of years (years 4 and 5), with evenmorerapid growth rate expected due toword ofmouth recommendationswithin the smallmanufacturingcommunity).

In this example both SAF and PDMvied for a contract with an aluminiumdoormanufacturer called All-ProAluminium. SAFwon the contract because of SAF’s aggressive and personablemarketing representativewhoboasted lower IT costs (over PDM). In addition SAF also promised quick turnaround time for a limited timeperiod (1 year) of free customisation, and promised two covetedmanufacturing applications:MaterialRequirements Planning (MRP) and Capacity Planning (CP). (Neither SAF nor PDMhad yet to complete theseMRP and CP applications into their packages, but PDMwas already 50% completed, while SAF had not yet evenstarted its development.)

PDM lost the initial contract because it did notmatch the promisesmadeby the SAFMarketing Representative.Even though PDMwas alreadywell into its ownprojects to develop its ownMRP and CP packages, PDMwasmore frank about their estimated completion dates, thatwere not as optimistic as those promised by SAF.

But as All-Pro Aluminium’s business relationshipwith SAFwore on through its first year, All-Pro soon learnedthat SAF's promisesweremostly empty. Almost nothingwas delivered by SAF on the promised delivery date,normet All-Pro's expectations in terms of functionality and quality. What SAF didmanage to deliverwas bugprone, lacking support, and contained no viable documentation. All-Pro soon learned that SAF's internalworking environmentwas in disarray and that the promisedMRP and CP application projects had not yet evenstarted. SAF's beleaguered staff of 6 peoplewas tied up just trying to put out fires (bug fixes, fixing brokendatabases and quelling irate customers). Unable to take on new customers, andwith the original unit salesrevenue of their early 30 customers drying up, SAFwas also in a cash crunch.

Eventually All-Pro bit the bullet and severed tieswith SAF and entered a contractwith PDM (despite the extracost of de-converting fromSAF's system to the PDMsystem). TheMarketing representative at SAFwasmiffedand baffled at All-Pro's decision. He pleaded his case by showing ample examples of howat least 60%of thetime SAFmanaged to deliver customisation thatwere requested by All-Pro. He also pointed out that at least15%of those projectswere delivered in amuch quicker elapsed timeover the stated development times thatPDMpublished for the same tasks.

Initially All-Pro did not divulge to SAFwhy they switched from the "rabbit" thatwas SAF to the "plodding turtle"(as labelled by the SAF Rep) thatwas PDM.

But after just 2 years of complete satisfactionwith the PDM, All-Pro finally divulgedwhy theymade the switch:

"What was most important to us was not how quickly or cheaply we would receive our deliverables, butwhether we could depend upon receiving the expected product on the expected delivery date. As a business


Page: 33 / 57

ourselves we adjusted our plans and budgets around those dates, and cost estimates. That's further reasonwhy it was so important for us that our IT vendor met those deadlines and we could depend on them to do so.PDM not only met our expectations, but exceeded them by offering exceptional customer care and support fortheir excellent application system, top notch documentation, and fair disclosure on any service or product theysold. We were always gratified that client care was their core business focus. PDM has been instrumental inputting us at the forefront of our business."

Again the above example (taken from a real life situation) again proves thatReal Quality (and a soundbusinessmodel) is not really all about "Giving the customerwhat theywant and demand", but rather, it is about"Managing andMeeting (or Exceeding) their Expectations".

Managing Client expectations in software systems development includes having the discipline to route all ClientRequests into thework definition and estimates analysis in order to provide a proper disclosure to the Client. Italsomeans to avoid the temptation to circumvent this important step bymaking blind and baseless promises tothe Client.

Meeting expectations in software systemdevelopment requires the proper use of Build fromKnown Source(BKS)/SystemPromotion based Software DevelopmentMethodology (SDM)within the software systemdevelopment life cycle (SDLC). It alsomandates that ProjectManagementmaintains a culture that freezes theproject functional scope throughout the duration of the project, and to route any changes to the project's scopethrough the Change Request development path, in order to viablymanage projects.

2.3 - The Quality Manual

The “QualityManual” fully describes the overall methodology of howa productmanufacturing company goesabout its business. As its name implies, its distinct purpose is to display and prove the company's quality level inboth itsmethods (its Software SystemDevelopmentMethodology – SDM) and in its deliverables.

The audience for thisManual is usually for process and business viability auditors, but the ultimate audience fortheQualityManual is the certification committee for ISO9001 Certification.

For a Software Development Company or department (i.e. "IT Department") theQualityManual describes theCompany’s overall SystemsDevelopmentMethodology. From the auditor’s perspective, theQualityManualdescribes the overall "Quality System" that is put in place by the company.

TheQualityManual is the central document required for ISO9001 Certification for software developmentmethodology (SDM).

TheQualityManual is written by, and is under the administration of theQuality AssuranceManager and theQADepartment.

Content:

TheQualityManual beginswith a description of the SystemDevelopment Life Cycle (SDLC) of the company.This includes the howbasic SystemDevelopmentMethodology (SDM) being used is interpreted in the actualSystemDevelopment Life Cycle (SDLC). For the purposes of ISO9001 certification, themore evidence of theprinciples of "Building fromKnown Source" (BKS), and using BKS to implement Software Promotion (SystemGating), then the better the chance of getting this certification.


Page: 34 / 57

Following the SDLC narrative is the combined collection of "Standards"Manuals from the various business unitsinvolvedwith software development. Each business unit StandardsManualmust bewritten by the respectivebusiness unit, but theManualswill be under the administration and control of theQAManager (whomay alsoprovide guidance and templates to assist to the business unit to help them in the production of their ownStandardsManual).

Participation in thismanual should include at least these typical business units with IT:

Marketing

Business Analysts

ProjectManagement

Programming

Quality Assurance

Systems

Operations

Implementation

For instance forMarketing and Systems units, their respective documents could be entitled, "Marketing TeamStandards" and "Systems Team Standards" respectively. The common title format (e.g. "----- Standards")indicates their general purpose and inclusion as part of QualityManual.

Each of these business unit "Standards"manuals needs to describe the business units’:

Business Function(s) and Goal(s)

Qualifications, duties and deliverableswithin each job title within the business unit

Tools andmethods used by its personnel

Source of data for the various functions performed

Standards andMethodologies enforcedwithin the Business Unit **

Roles and duties as they occurwithin the SystemDevelopment Life Cycle **

**Of particular importance to ISO9001 certification are the last two bullets: "Standards andMethodologyenforcedwith the Business Unit." and "Roles and dutieswithin the SDLC". This is because ISO 9001 certificationwill check to see how well these two areas are integrated into the overall System Development Life Cycle (asdescribed in the Quality Manual and in actual practice). They will also check how well they contribute to overallquality within the context of their roles in the SDLC. For this reason, it is best that the overall Quality Manualeffort be closely co-ordinated by the QA Manager (or whoever is the lead on Quality Manual production).

2.3.1 - Link to Quality Manual Definition:http://www.mapwright.com.au/quality_manual.html

http://www.mapwright.com.au/quality_manual.html


Page: 35 / 57

2.3.2 - Programming Guide in the BKS EnvironmentAs mentioned in the previous Quality Manual section, each of the several business units contribute andsubmit their own "Standards Manual" to be included within the umbrella Quality Manual. For instance,the Programming Team would submit their "Programming Team Standards"manual for inclusion to theumbrella QualityManual.

This section focuses on a sub-section of the Programming Team Standardsmanual: the "ProgrammingGuide".

As its name implies, the ProgrammingGuide outlines coding standards and practices for the ProgrammingTeam. This Guidemust be known, understood and in compliance by anyonewhowrites code for theApplication. This sectionwill outline someof themore important coding considerations, especially regardinghow these programming guidelines integrate into the BKS / Software Promotionwork environment.

The "ProgrammingGuide" should bewritten/compiled by the team's technical lead, such as the SystemArchitect/TeamLead (SA/TL).

The ProgrammingGuide actually is comprised of standards and guidelines fromvarious sources and platformlevels. These include:

1. Standards from the Programming Language andOperating SystemPlatforms

2. Standards from the Application's Programming and ConfigurationGuidelines

3. Requirements from the Software DBA (SDBA) to support BKS builds

4. Standards from the local BKS-SDMdevelopment environment.

2.3.2.1 - Standards from the Programming Language and Operating System PlatformsThemost common and central programming guidelines and standardswould be those that pertain to theprogramming language (and its development platform) and some from theOperating system interfacelanguage.

Ironically, these Guidelines and Standards are not likely providedby the Language providers, but instead arewritten internally by the Programming Team's Technical Lead such as the SystemArchitect or Team Leader,qualified through his/her thorough understanding of the languages and development platforms.

On the one hand, the Guide highlights the usage and coding practices of the language that are optimal forthe Application, and, on the other hand, it compiles a list practices to avoid and the reasoning behindavoiding these potential gaffes. Several of these "do's and don'ts"may be specific to the supportedApplication. For instance someesoteric coding practices and language featuresmight be ideal for scientificapplications (where ultimate performance and efficiency are paramount), but not so ideal for financialapplications (where supportability, expandability and readability trumps self-indulgent, concealed, and/oroverly tight code).

2.3.2.2 – Standards from the Application's Own Programming and Configuration GuidelinesThe brunt of coding guidelineswill come fromApplication layer andwould have beenwritten by theApplication’s original vendor. Programming guidelines of this type include:


Page: 36 / 57

a) The published list of Application utilities and their proper usage, reusable object and common libraryroutines,

b) User interface "Standard Look and Feel" programming standards and guidelines,

c) Report programming guidelines,

d) Guidelines formodifying core Application routines, and

e) Explanations of the Application'sMajor Business Rules coding and guidelines.

2.3.2.3 - Requirements from the Software DBA (SDBA) to support BKS buildsIn order for the automated software installation towork, certain coding requirements for both source andsoftware installation scripts (MAKE files)must be adhered to. The Software Database Administrator (SDBA)dictates these requirements. Here are some of the programming standards in this regard (software controlandmanagement related):

2.3.2.3.1 – SDBA Coding Standards - MAKE FileTheMAKE file is either a script or a programor some othermechanism thatwill configure and install theproject's software into theApplication. (TheMAKE file is actually a conceptual file thatmay ormay not bean actual file. Depending on the facilities of the Software Control System, the Application, and thedevelopment platform the “MAKE file”’s purposes in installing softwaremay already be built into thosesystems. The references to it here arewith the assumption that it is an actual file).

The basic requirement from the Software DBA (SDBA) is the requirement that aMAKE file is to be includedwith each Project's software package. The SDBAowns the standards and guidelines forMAKE file codingand format. TheseMAKE standards help ensure that the Software Control System (SCS) is able to executetheMAKE and that theMAKEwill install the software properly. The SDBAwill also review all incomingMAKE files for compliance to those standards.

2.3.2.3.2 – SDBA Coding Standards - One-Time Set-Up FacilitiesThe BKS based Software Control System (SCS) basically installs Project related software packages in anautomated fashionwithoutmanual intervention. However the SCSwill have an occasion to potentially re-install the samepackagemore than once into the Application system. Thiswould be almost a non-issue ifthe package contains only program source code. However some projectsmay involve one-time set-up tasks,such as changes to file or table structures, population of newly created table columns, data conversions,new control table set-up, deletion of old programs that impede access to newprograms in the programaccess path, etc. The one pertinent characteristic of all of these “one-time” tasks is that theymust only beperformedonce and only once at the time of the initial installation. These tasksmust NOTbe re-run if forsome reason the SCS installs the package again in the sameApplication system.

Therefore programming guidelines for these one-time tasks should include:

The programs, scripts, tables, files and any other element that pertain to the one time task(s)must beseparated into their ownproject Library group package (under the same project number as themainline project). This Library groupwill have its "OnceOnly" flag turned on, so that it will only beexecuted oncewithin any iteration of the Application System (see "A1.1 - Project Library GroupData"below).


Page: 37 / 57

Programmingmustmake sure that one-time routines are physically placed and configured separatelyfrom the project'smain-line code package. The single execution programs should contain checks toensure that the tasks have not already been runwithin theApplication.

As a practice for any project that entails a long run (such as a data conversion ormapping run), it isrecommended that this run should NOT be automatically run during the SCS software install, but rathershould be scheduled as a separateOperations run. For this reason, the programs that perform theselong running initialisation tasks, should be designedwith prompts and interfaces, and back-out featuresthat are appropriate and required for Operations (as per theOperations Team StandardsManual) .

2.3.2.4 - Standards from the Local BKS-SDM Development EnvironmentThese guidelines pertain to the support of theword "Known" in the term "Build fromKnown Source" (BKS).

Specifically these are standards for source code format so the source code is appropriate for Librarystorage and versioning control.

Secondly these are standards for in-source code programdocumentation.

The Software Control System (SCS)will have utility functions that compare different generations of sourcecode to be able to reportwhat has been changed between versions. (See section "A2 – The SoftwareControl System (SCS)" below for a description of SCS functions). To support this feature the above tworequirements about the source code itselfmust be in place before such change reporting is possible andoptimised.

2.3.2.4.1 - Source Code Format (as ASCII Text) for Library StorageThis local BKS-SDMprogramming standard pertains to source code that is binary or not readily readable inits raw format (i.e. non-text files).

Some programmingplatforms allow the Programmer to operate on software development interfaces inwhich the Programmer is not directly editing source code of any known language, but rathermanipulatingthe program through anObject Oriented Editor (OOE). If this is the case, the following are requirements forcodemanagement:

The parameters (or "source code") that define the complete functional image of theOOE edited entitymust be exportable/Importable from/to theOOE as a text file. Upon importation, these parametersmust be able to replicate the programentity within theOOE.

Amechanism is required to recordModificationHistory and a Change SummaryNarrative (to be eithermanually added as comments to the exported code, or within comments placed in a separate parallelfile).

The SCS can compare different versions of the same code. This comparison should show the changesmadebetween the code versions. If these changes ("deltas") are indecipherable and/or the logicalchanges are not locatable upon viewing the deltas, new tools or SCS customisationmay be required totranslate and re-interpret these deltas so that the location and nature of these changes can bediscerned.


Page: 38 / 57

2.3.2.4.2 - Internal Program DocumentationFor traditionally edited source code changes, project changes should be documented in the followingmanner:

At the very top or bottomof each program should be a standardised header containing the sourcecode's name, origination date, original author, and general purpose.

In the second half of this header should be aModification History section, with columns for Date ofmodification, Project Number, Author, and Abstract Description of the changes.

Both the standardised header andModification History should begin and endwith a unique blockcomments that help the SCS locate the these sections and extract them if necessary.

Next to each change or change block should be special project references called "Line Tags". Line Tagsare short comments containing the Project #, Date of Change, and a short comment as required. Thisway, by searching on project number, one can locate all changes pertaining to the project (including theentry in theModificationHistory).

These in-code documentation conventions are documented in the Programmer's Guide and enforcedduring the Code Review.


Page: 39 / 57

SUMMARY:Of the several pointsmade, the following are themost central:

Software SystemDevelopment is a serially layered process. As each layer is completed, it forms part of thedevelopment platform for the next layer. Because of this ordinal development, each layer aligns itselfrelative to the other layers forming a BuildOrder.

In building the Application’s Software content this Build Ordermust bemaintained. By storing eachsoftware layer as project groups in the Library,we can replay the build of the Application. The processinvolves extracting the source layers from the Library, and applying them to the Application layer uponlayer in BuildOrder sequence in a process called “Build (Application System) fromKnown Source” (BKS). Itis by this BKSmethod that a new software release is promoted through the development business unitsuntil it reaches the production ready state for delivery to the client (SystemPromotion orGating). The BKSbuildmethod not onlymakes consistent the software content of the Application, but also fully publishes it,thus facilitating future support and development.

Scope creep undermines all projectmanagementmetrics and controls and short-circuits the BKS basedSystemDevelopment Life Cycle that is not designed to handlemid-project development scope changes.The impetus to force scope creep intomid-project development fails to recognise basic business practicesand forgets that real quality is not about giving into the demands andwhims of clients, but rather it is tomanage and exceed their expectations by using proper SystemDevelopmentMethodology.


Page: 40 / 57

APPENDIX A: THE ELEMENTS OF BKS:At the outset of the above overviewof the BKS process, the requisite elements of BKSwere briefly listed insection “1.3.1.1 - The BKS Process: Applying Project Groups to Reach Desired Software Content:”.

These BKS elementswere:

Source Code Library (“Library”)

BuildOrder File (BOF)

MAKE files

Software Control System (SCS)

Release Level Control file

Software DatabaseAdministrator (SDBA)

Application Software Content Data (“Content Data”)

Most of the aboveBKS elementswere briefly described in section 1.3.1.1.

In this Appendix A, further details are given to the Source Code Library, and the Software Control System (SCS):

A1: The Software Library:The central purposes of the Software Library (“Library”) are to serve as a repository for all versions of theelements pertaining to the supported Application(s), and to be able to link specific element versions into LibraryGroups, and offer facilities tomanage these LibraryGroups.

The Library’s structure then can be conceived as a X-Y graph, where the library elements are listed along thehorizontal ‘X’ co-ordinate, and generation numbers (startingwith ‘1’ and incrementing by one) along the ‘Y’ axis.The Library group can be conceived as a jagged line going through specific versions of selected elements (seeFigure 3 below).

Themost common LibraryGroup is the “Project Library Group” that links together all the active elementspertaining to a project including source code, control files,MAKE file, scripts, and project documentation. Theproject represents an Application software layer thatmust be only be appliedwithin the ordered context of theBuildOrder file. All Library Groups are created andmanaged by the SoftwareDatabase Administrator (SDBA).

A1.1 - Project Library Group DataWhile the Library Group offers simple linking of element versions, Project Library Groups require the followinginformation pertaining the Project:

Project Number – The unique Project number assigned to the Project

Project PackageNumber - The ‘nth’ Project LibraryGroup (in case the project requiresmore than 1 librarygroup). Starts at ‘1’.

Abstract Description – A one-line abstract of the project.


Page: 41 / 57

Project Type – A project type designation (S-System, E-Enhancement, C-Change Request, B-Bug Fix, G-General). ***

Date of Project Creation – The date the Project was started

Once only Flag (Y/N) – indicates that the project library groupmust be installed and configured only one foreachApplication system.

BuildOrder Number (foreign key) - The build order ordinal position of this project relative to other projects.The Build Order Number is actually not on this file but is obtained from the Build Order File (see below) byusing the Project number as the foreign key.

ReleaseNumber – (foreign key) - The ReleaseNumber that this Project pertains to. This number is actu allynot in here in this file, but is located in the Release Level File (see below) by using the Project number as theforeign key.

*** Below are further explanations of the Project Type:

System (S): This Project type refers to the entire software set of the Application (usually the original versionof the Application). When the application system is new, this type ‘S” project library groupwill representthe first version (version #1) of a the new application’s source code, control files,MAKE files anddocumentation files. For later versions of the Application the ‘S’ project library group is characterised bybeingmostly a replication of the previous systemgroup, butwith the group line going through any elementsversions that have been revised or newly created, and bypassing elements that are obsolete. If theapplication system is large, systemgroups can consist of tens of thousands of Application elements.

Enhancement (E): This group points to all elements associatedwith an enhancement sub-systemproject

Change Request (C): This ‘C’ (Change Request) Project Library group contains a project that is a revision ofa previous Enhancement Group (E).

Bug Fix (B): This group is a bug fix against any of the above System, Enhancement or Change requestgroups.

General (G): This group type is not project related, and is used for library groups that are not project related

A1.2 – Library Structure and Project Group MaintenanceThe following diagram within Figure 1 below shows the basic structure of the Library represented as aX-Y graph where the library elements are listed along X horizontal line, and their generation numbersare on the Y vertical line. Also shown are three project library groups.


Page: 42 / 57

Figure 3: Library Structure showing two (‘E’nhancement) groups and one (‘C’hange Request) group:

TheDiagram above (Figure 3), shows group structures for two Enhancement groups (type E group) forhypothetical Projects 100 and 120) , plus a change request project group (Project CR120)made over Project 120.

The Project 100 enhancement group is defined by the blue coloured line in the diagramof Figure 1. This groupconsists of two brand newprograms (ProgA and ProgB), plus revisions to two core application programs (ProgCas version #2, and a core common library routine Lib1 as version 4), aMake100 software install script (version2), and finally the Functional Specification (FS100 version 1).

The original enhancement project group for Project 120 is shown as the red coloured line. It consists ofmodifications to four core programs (version 4 of ProgD, and version 3 of both ProgE and ProgF, plus version 5of version Lib1. (Notice that since Project 120’s version of Lib1 is built upon Project 100’s version of Lib1, it ispertinent that the “build order” is such that Project 100 is installed first, prior to the installation of Project 120.If reversed, Project 120’s changes to Lib1will be lost. )

Finally there is a Change Request Group (type C) against Project 120 (the green line). It consists of additionalrevisions to Prog E (version 4) and to Lib1 (version 6) plus a newChange Request document (CR120 version 1).

ProgA ProgB ProgC FileA FS100 Make100 Lib1 ProgD ProgE ProgF FS120 Make120 CR120

V9

V8

V7

V6

V5

V4

V3

V2

V1


Page: 43 / 57

A2 – The Software Control System (SCS)The Software Control System is the system layer around the Library provides several utilities to service bothProgramming development and themanagement of application software content.

A2.1 SCS Utilities to Service Programming DevelopmentDue to its access to the Library the SCS can offer the following utilities to the Programming Team, and for theSoftware DBA to aid them in their respective tasks during the Software SystemDevelopment Life Cycle.

Software Reservation System – A front-end interface that enhances the Library’s natural reservationsystem, tailoring it towards the particular needs of the ProgrammingDepartment. For instance, theaddition of project related information can be added to reservation system. Also variant streamprocessingcan be added if not already inherent in the Library’s reservation system.

ProgramWhereUsed Reports – Using Project Library Groups in conjunctionwith generation history on aprogram file, a report on the overall modification history of any program can be produced that shows theproject numbers and abstract associatedwith each generation.

ProgramChangeHistory – Using file comparison utilities, the SCS can produce a report of the actualchangesmade to a programmade by each project that affected it.

Software Reservation ReviewReports – A Software DBA report showing outstanding reservations andassociatedprojects. Used during the SDBA’s code review as code is checked back into the Library.

CodeReviewAnalysis Report – A report the actual changes upon every program includedwithin a Project’swork package (as defined by its project library group linkage). This report is mainly used by the CodeReview Process.

A2.2 SCS Utilities to Manage Application Software ContentThese SCS utilities used by the Software Database Administrator (SDBA) tomanage the Application’s softwarecontent. These are private to the SDBA.

LibraryGroupMaintenance and Reporting – Utility to create, manage Library Groups. Reporting caninclude reporting on individual library groups, intersecting library groups, groups that effect a single orgroup of library elements, etc.

BuildOrder FileMaintenance and Reporting – The SDBAuses the SCS tomanage and report the BuildOrder of Projects.

Release Level FileMaintenance andReporting – The SDBAuses the SCS to alsomanage and report theRelease Level File.

BKS builds - the SDBAuses the SCS to perform the BKS software install as described in section “1.3.1.2 -Example: The Basic BKS Build Sequence”. The software content target level can be designated by the SDBAwith a project number, orwith a ReleaseNumber .


Page: 44 / 57

Build Log Reporting (Error Reporting) – The SCS can scan the software install logs for any errors during theBKSbuild and report these error(s) to the SDBA. The errors can be corrected and the original build shouldbe replayed to test the corrections.


Page: 45 / 57

APPENDIX B: PROJECT DOCUMENTS WITHIN SDM: TRADITIONAL VERSES AGILE

The purpose of this appendix is to attempt to offer some clarification and uniformmindset regarding the topicof project documentation. By identifying the true aims, purposes and audience of each document, these can beselectively streamlined, and perhaps new-found efficiencies can be gained, since these documents represent asignificant time, effort and resource cost factor that affect the project's quality and timeliness.

Project Document Optimisation:The documents listed below aremerely samples andmay differ in nature and purpose fromoneplace toanother. Themain point of this section is not somuch to prescribe the documents below, but to help reviewyour present project documentation set.

Project Documentation can use up a lot of time and labour hours that can undesirably extend the duration ofproject development. In the interest of saving valuable time and labour resources, andmaking the SDLCmoreefficient, a careful reviewof each type of project documentationmight be in order. For each document, reviewprimarily the purpose and audience. Then review other aspects such as format, and sign-off requirements.These documents and their criteria should all be reviewed in the context of the present SystemDevelopmentLife Cycle (SDLC). In fact, this document review could also coincidewith a reviewof the SDLC.

For instance the review should ask the questions ofwhether or not the purpose(s) of the document are stillreally pertinent and conversely, whether in fact the document really fulfils those purposes. Text Templates aremuch easier and quicker to produce than Formal Template type documents (the later should be reserved fordocuments that have external exposure). Periodic review of the formats and templates should be performed toa) adjust the template tomake it more efficient, b) whether the document should bewritten using a Texttemplate or a Formal template, orwhether the document should be discontinued ormerged into other entities.For instance can the DetailedDesign Specifications be eliminated (given its purpose, audience and ability toobtain its information fromother sources)? For instance, if a “User Needs” and “Requirements” are both beingproduced, given their purpose and audience, are they redundant? For documents thatwere previously writtenusing the Formal Template, could they use themuch simpler Text Template? Can some templates bestreamlined andmore efficient?

Typical Project Documents in the System Development Life Cycle

Request for Proposal ("RFP")

Written by: Client

Purpose: A Client Request a system change analysis, estimated cost and estimated time of delivery (ETD). fora time and cost estimate and Estimated Timeof Delivery (ETD), a system solution analysis and definition and thesolution's estimated cost and ETA regarding the client's proposal for a system change.

Audience(s):From IT:Marketing, SystemArchitect, Business Analyst, Programming andQAManager orrepresentative

General Content: (see Purpose)

Signoff by: Client and IT Vendor


Page: 46 / 57

Signoff Purpose: Acceptance by IT Vendor that theywill respondwith the Cost Estimate, ETA, and outline ofproposed changes (User Needs doc, or Prototyping output)

Format level*: (as per client standards and deemed acceptable by IT)

Agile SDMVariation: (none)

UserNeeds/Requirements ("Requirements")

Written by: Business Analyst (assisted byMarketing Rep)

Purpose: Verbalize the Client's requested changes andwhat they intend to gain from them. Given to Client aspart of the response to the Client's RFP.

Audience(s): Client, Business Analyst, all other Project Teampersonnel.

General Content: Narrative of expressed needs and background, screen/report/newdata structure layouts(where applicable), and processing change narrative. Explanation of business benefits aimed for by changes.

Signoff by: Client via Response to RFP (see below)

Signoff Purpose: (see Response to RFP)

Format Level*: Formal Template

Agile SDMVariation: See Prototype/Prototype Processing Summary below

Prototype Processing Summary

Written by: Business Analyst

Purpose: Used in anAgile SDMenvironment in lieu of theUser Needs/Requirements. Describes the Prototypethatwas presented to the Client.

Audience(s): Client, Business Analyst, all other Project Teampersonnel.

General Content: Contains screenshots of the Prototype, plus explanation of all background processingpertaining to the new software system. Plus narrative of the Client’s business needs as they relate to therequested software system.


Signoff Purpose: Signals Client approval to go aheadwith the project to completion.

Format Level*: Formal Template (external Client), Test Template (Internal Client).

Cost Estimates

Written by: Business Analyst (with assistance fromWhiteboard Session analysis, and Programming andQAestimates).

Purpose: a) to be given to Client as part of response to RFP, b) used by ProjectManager as projectmanagement parameters

Audience(s): Client, ProjectManager

General Content:


Page: 47 / 57


Signoff Purpose: (see Response to RFP)

Format Level*: Formal Template or Excel spreadsheet format


Response to RFP

Written by: Business Analyst (with assistance fromMarketing Rep and others fromWhiteboard session)

Purpose: to respond to the Clients Request for Proposal (RFP)with time and cost estimates, a reiteration of theClient's system requests, and general approach tomeeting those requests.

Audience(s): Client

General Content: Time and Cost estimates (including invoice for incidental costs of preparing this response),User Needs/Requirements document or Prototyping documentation.

Signoff by: Client

Signoff Purpose: Client's acceptance to allow IT to carry through on the customisation until completion (withcaveat thatmid-project change requestswill be handled via IT's Change Request project system).


Agile SDMVariation: Prototyping output and Supporting documentationmight be used in lieu of UserNeeds/Requirements document.

Functional Specifications ("FS") (Client Enhancement or Subsystem)

Written by: Business Analyst (in assistance fromProgrammer/Analyst)

Purposes: To define the project's software deliverables from a functional standpoint. Is the legal description ofthese deliverables.

Audience(s): Client, Programming, QA, Business Analyst, and business court of law

General Content:

Signoff by: Client

Signoff Purpose: (traditional SDM: signoff signals go-aheadwith project) (Agile SDM: sign-off is for Client'sverification of software content)

Format Level*: Formal template

Agile SDMVariation: The format of theAgile SDMbased FSmay be restructured to accommodate andmakeuse of output fromprototyping facility.

ChangeRequest Functional Specifications ("CRFS") (Change Request FS)


Page: 48 / 57

Written by: Business Analyst

Purposes: A brief Background and functional description (FS) of a Bug fix


General Content: A Functional Specification for the Client's request for a change of an earlier project. Althoughformattedwith a Formal Template, the CRFS ismuch smaller, relying upon references to the FS of the previousproject allowing he CRFS to focus upon the change(s).

Signoff by: Client

Signoff Purpose: To

Format Level*: Formal template

Agile SDMVariation: Again if output froma prototyping facility is useful in describing the change(s), then thismay be included as the description of the changes.

Bug Fix Functional Specifications ("BFFS") (Bug fix FS)

Written by: Programmer/Analyst

Purposes: A brief Background and functional description (FS) of a Bug fix


General Content: A background and functional description of the systemerror condition and the approach tothe correction. Reference to the affected Project software that introduced the error, or has been affected bythe error. This documentmay be only a few lines.

Signoff by: Team Lead/SystemArchitect

Signoff Purpose: to Verify the approach to the bug fix.

Format Level*: Text template


ProjectManagement Plan and Log

Written by: ProjectManager

Purposes: a) Key scheduling and projectmanagement tool for ProjectManager and Project Teamby providingstructure andmetrics for theWIP projects, b) encapsulates and controls project resources, progress and costs, b)to provide project job costing statistics for future estimation, c) provides performancemeasurements andstatistics for future process improvements.

Audience(s): ProjectManager and Team, IT DepartmentManagement

General Content: Usually a generated report froma projectmanagement tool or application that containsproject related scheduling, dependencies,milestones, due dates, progress tracking, and project pre-warningalerts for potential issues.

Signoff by: (none)


Page: 49 / 57

Signoff Purpose:

Format Level*: as per projectmanagement tools reporting facilities


DetailedDesign Specifications ("DDS")

Written by: Programmer, Programmer/Analyst

Purpose: to describe the nature and purpose of the program elements thatwere affected or created by theproject.

Audience(s): Future Programming Support, Possible supporting evidence and extension for the FunctionalSpecification.

General Content: Narrative of programming approach, followed by list of affected program elements, andwhatwas changed.

Signoff by: (none)

Signoff Purpose:

Format Level*: Text Template

Agile SDMVariation: Not somuch because of the effects of Agile SDM, butmore so because of the facilities ofPKS based software development and promotion, the DDS contentmay already be available on-demand fromthe Software Control System (SCS) reporting set. This is made possible because of the SCS's ability to providechange deltas between code generations, identify all element source generations that pertain to a project, andextract all project documentation files on demand. Depending upon needs and decisions of each ITenvironment, the creation of the DDSmay be deemed unnecessary unless the project is large enough towarrant a DDS thatwould provide amore deliberate and structured programming approach and designnarrative.

Unit Test Plan and Results

Written by: Programmer, Programmer/Analyst

Purpose: To prove that Unit Testswere done.

Audience(s): Code Review andQA

General Content: Brief Unit Test plan, List of actual tests and purposes. (Optional: unit test results)

Signoff by: Programmer, CodeReviewandQA

Signoff Purpose: Programmer: as promise thatUnit test were completed, and to claim liability if theywere not.To ensure thatUnit Tests by Programmingwas completed as expected.



QATest Plan and Results


Page: 50 / 57

Written by: QAAnalyst

Purpose: To define the types of tests planned for each project, to record test results, and to provide sign-off forcompletion of tests.

Audience(s): QA Analyst, QAManager, and Project Team

General Content: Pre-plan of prescribed tests for the projects of a Release

Signoff by: QAAnalyst

Signoff Purpose: Signals Project successfully completed the tests as perQA Test Plan



ImplementationGuide

Written by: QAAnalyst and Business Analyst

Purpose: To guide the implementation of a Project's software system.

Audience(s): (External): Client, External Vendors (Internal): Operations, Implementation Team.

General Content: Project roll-out procedures including Steps, tasks, and dependencies to install and implementa project's software layer. External partiesmay include Clients (if they are needed for set-up, programexecution or signoff tasks), or External Vendors (if they are needed to co-ordinate file transfers, 3rd partysystem activation, client alerts, etc.)

Signoff by: Implementation Team

Signoff Purpose: Signals when the project is fully implemented.

Format Level*: External Client Portion: Formal Template, Internal in-house portion (Text Template)


OperationsGuide

Written by: QAAnalyst, Programmer Analyst, or Business Analyst

Purpose: If the project requires services fromOperations, thismanual guidesOperations to how to execute thetaskswhether it be a single job run, or set-up for periodic runs.

Audience(s): Operations

General Content: Describes Operation Task, and Run-Sheets containing Jobs to run, suggested frequency,executionmethod, screen prompts, handling of output, etc.

Signoff by: Operations

Signoff Purpose: (Run Sheet: time and date of job completion and run by person.)




Page: 51 / 57

UserGuide

Written by: Business Analyst and/or TechnicalWriter

Purpose: To show client how to use the software

Audience(s): Client

General Content: Usermanual on how the Client is to set-up and operate the Project'smodification.

Signoff by: (none)

Signoff Purpose:



TrainingManuals

Written by: Business Analyst and/or TechnicalWriter

Purpose: TrainingNotes for a Client training session on use of project software

Audience(s): Client

General Content: (see purpose)

Signoff by: (none)

Signoff Purpose:

Format Level*: External - Formal Template. Internal - Text Template


* Format Levels Legend:

"Formal Template" - Uses fully formattedword processor document type specific predefined templatewithtable of contents, revision history, company header, pagination, formatted headings, headers and footers,standard file naming, version numbers, and Project Number reference.

"Text Template" - Text document in Template formwith template customised for the document type.


Page: 52 / 57

APPENDIX C: VARIANT STREAM (MULTIPLE DEVELOPMENT PATH)DEVELOPMENT

A "variant stream" (or "multiple development path") occurswhenever twoormore projects affect a commonLibrary controlled source code file. These situationsmust be carefully handledwithin a pre-set BuildOrderscenario.

The co-ordination of Variant StreamDevelopment is one of the tasks of the Programming Team Leader, butultimate the responsibility lieswith the Programmerswho are involvedwith the development; theymust co-ordinate their efforts between themselves. Programmers are first alerted to the situation by the Team Leaderwhowasmade aware of the variant streamduring projectWhiteboard sessions earlier on in the SDLC process(see "1.3.1.5 Sample BKS Based SystemDevelopment Life Cycle (SDLC)"). However themain signal that avariant stream is in effect, is during software reservation, when the Programmer sees a previous reservationagainst the code.

Some Library systems offer enhanced reservation systems that specifically service variant stream situations.Someof the characteristics of these Library features are:

a) The Library allowsmultiple reservations on the same program.

b) It creates separate version paths for each development stream.

c) It offers a "mainstreaming"mechanismwhen a variant stream ismerged into another variant streamorinto themain streamdevelopment path.

Themost valuable feature of these features is that the provisions of a history trail of these developmentstreams that point outwhich versions represent themerged version, andwhen themerging occurred. Yetwhether or not the Library supports such elaborate variant streamhandling or just supports simple singlereservations, the actual co-ordinationwithin the IT department remains the same.

Variant stream co-ordination differs significantly depending onwhether the variant stream is all within a singlesoftware release ("Intra-Release Variant Stream"), verses being spread across twoormore releases ("Inter-Release Variant Stream").

Intra-Release (all within one Release) Variant Stream Co-ordination

When the variant streamdevelopment is all containedwithin a single software Release (all projectsassociatedwith the variant streams are delivered on the same date), then there is essentially a single andserial development variant streamdevelopment path for the handling of the variant stream. The order ofproject development is based on the pre-established BuildOrder (see sections "1.2.2 - The Importance of"BuildOrder" for Subsequent Change Layers" and "1.3.1.5 Sample BKS Based SystemDevelopment LifeCycle (SDLC)" for themeaning of and determination of the systemBuild Order concept).

The TeamLeadwill consult with the individual Programmers as to the order of development between theprojects. Considerations on how the set the BuildOrderwill likely take into account the size of the project


Page: 53 / 57

(perhaps tackling the smaller (more easily completed) projects first will reduce bottlenecking), andwhetheror not one project has functional dependencies on the other. For instance if Project A creates a file thatProject B will require, then of course Project A should be completed first before Project B.

Inter-Release (Projects Spread over two or more Releases) Variant Stream Co-ordination

In this case, one ormore long termprojects are under development and slated for a release in the future,where those Releases post-date the present currently in-progress Release.

In this case, someproject(s) that pertain to the current release contain programs that are common to thelong-termprojects. When the programmers for the current projects attempt to reserve their code, theywillfind the code already reserved and presently beingmodified by the long-termprojects.

Since the projects pertaining to the current releasemust be processed in time for the present Release, theemphasis will be upon these projects, and theywill not need to consider any aspect of the long-termprojects.

Instead, the onus is upon the long-termprojects to continuallymerge/retrofit its work-in-progress changesinto themainstreamdevelopment path of the common. Therefore it is best for the long-termprojects todesign and structure their changes so as to ease thismigration process. One technique is to separate thelong-term changes into encapsulated callable routines (where possible), where the routines are unlikely tobe affected by other projects.


Page: 54 / 57

APPENDIX D: SERVICE BUREAU SHELL SOFTWARE SUPPORT CONSIDERATIONSIT support for an Application becomes a "Service Bureau Shell" (SBS)when there aremultiple clients using theApplication, and IT has created a "shell" - a system structure around themultiple iterations of the Applicationthat provides common services and support for collective client set. The SBS's services for the collective clientsinclude operations processing runs for all clients, Shared resources such as common SBS control tables, andcommonprocessing and distribution of data to/from external interfaces.

The Dilemma of Client specific Customisation in Multi-Client environment:Whenever a single IT Department supportsmultiple clients through a single Application, the great challenge ishow tomanage the differing customisation requirements of each of its Clients?

A first impulse approach to this issuewould be to simply dive into the customisation for each customer and tomake sure that each customer's software setwas separately controlled in the Library. However this approachbasically sends customers onto their own divergent development paths.

Again, remember the "layered" approach to software development as described in section "1.2 -TheOrdinalNature of Application Software SystemDevelopment" above. As the development path for a client veers fromboth themainstream code and the customisation paths of the other clients, therewill soon be no turning backto re-merge the divergent streams. For instance if the rest of the clients desires a customisation thatwasmadefor Client A, this customisationwouldmost likely not be portable to the other clients. This is because Client A’scustomisationwas built upon a specific foundation of Client A specific customisation. The only practical waythe other Clients would get the newmodification fromClient A in this case, would be to replace their ownsoftware setwith Client A's system. But these other clients would lose all their own customisation in theprocess. (This was one of the problems that the hypothetical "SAF Rapid Software Inc. experienced in theexample portrayed in section "2.2.2.5 - SAF Rapid Software Inc. Verses PDMSystems, Inc." above.)

The SBS Approach to Client Specific customisation - Software LicensingInstead, themost viable approach for Application customisationwithin a Service Bureau Shellmulti-clientenvironment is tomaintain only one software development path for all clients (i.e. all clients get the samesoftware). In this scenario, a Software Licensing systemalongwith its codingmethodology and architecturemust be implemented in order to "turn on" specific customisation for the appropriate subscribing Client.

The Licensing systeman SBS environmentmust have the following characteristics and features:

The Licensing table (held in a SBS commondatabase) should contain unique and referenceable customisationidentifiers and a list of clients whohave subscribed to each one. Also required is user interface tomaintain theLicensing Table that is exclusively accessible only by internal ITMarketing and Administration personnel.

A "Licensing" facility that includes callable routines that check to see if the client has subscribed to the licensefor the particular customised feature set. If not licensed, the Application should disable the customisation. Forinstance, if the customisation adds a newuser prompt to a user interface screenwindow, the field could still beshownbutwould not be accessible if the Client is not licensed for this feature. (If possible, it would be better ifthe newprompt did not appear at all for non-licensed Clients.)

All customisation logic need to first check the licensing and offer viable dualmode "licensed" and "not licensed"behaviour. Special attention and designmust be given to the "non-licensed" behaviour to ensure that theApplicationwill still function as it did before the customisation (or at least function viably without the benefit ofthe customisation processing).


Page: 55 / 57

All customisationmust be designed tomake use of the Licensing facility, unless the customisation is obviouslymeant for all clients (such as for governmentmandated changes, or industrywide changes thatmakes previousfunctionality obsolete. In the later case, consideration for possible need to process archived data (that runs onthe old logic) must be considered. In this case, itmight be advisable to still make the project "Licensed").

TheWhiteboard session #1 (see “13.1.5 Sample BKS Based SystemDevelopment Life Cycle (SDLC)”) shouldinclude discussions between Team Leader/SystemArchitect and Programmer regarding the design approachesfor licensed customisation. Special consideration for how the License switchwill create twobehaviours of thesoftware: onewhere the licensed switch is on and customisation is activated, and the otherwhere the switch isoff, where the systemmust performwithout the customisation.

Code Review should check each new customisation for proper utilisation of the Licensing procedure calls whereapplicable.

When the customisation is licensed, QAmust include in Test Plans tests of both Licensed and non-Licensedmodes of each customisation.


Page: 56 / 57

APPENDIX E: SOFTWARE DEVELOPMENT IN THIRD PARTY APPLICATION VENDOR ENVIRONMENT

When the IT Department is supporting anApplication that has been purchased froma third party vendor, thesituation creates two software source streams for the sameApplication. One source is from the Vendor (asperiodic updates), and the other from the internal IT Department in the formof project related changes.

Many times the program changesmade by the Vendor collidewith the local customised versions. Inmost cases,the Vendor will NOT be open to incorporating the local changes into theirmainstreamApplication. Instead, theVendor's software streamwill be one-directional; where the vendor's changesmust be dealtwith locally on a"Take it", or "Leave it (and thus invalidate your support contract)" basis.

If the local IT Department ("local IT") chooses to ignore these Vendor supplied updates (and thus terminate thesupport contract), it will essentially and permanently veer off from the Vendor's development path. Afterskipping a few vendor releases, therewill be no turning back. Any attempt to catch up to Vendor updates (atthat point) will become impossibly prohibitive due to the cost and effort required tomerge all the changes fromboth the Vendor and from local customisation thatweremade since the split.

If local IT chooses to keep upwith the Vendor updates, itmust put in place the framework to handle theVendor's software release stream. This framework should include the following features:

Each Vendor Update should be assigned a project number and is to be processed as a project through the sameSystemDevelopment Life Cycle (see section "1.3.1.5 Sample BKS Based SystemDevelopment Life Cycle (SDLC)").However these Vendor Release Projectswill differ fromnormal projects as follows.

TheUser Needs phase (Step #2 of the SDLC) is replacedwith an internal analysis of the nature and purpose oftheVendor's changes. It is recommended that ITmaintain a version of the Application that is purely theVendor's code (i.e. no local customisation added). In this "VendorOnly Application System", the new vendorchanges can be added, and viewed and tested.

In theWhite Board Session #2 (Step #6 of the SDLC), the Vendor's changes are discussed in termsof priority andscheduling (i.e. assigned to a Release) like any other project.

Note that typically the priority of Vendor changeswill normally be lower than the priority of internal projects.Therefore vendor release processing is typically pushed to a later Release (unless someor all of the Vendorrelease changes directly address someof the Client's current requests.)

In the Programming phase (Step #11 of the SDLC), the "programming" tasks involve examining the vendorchanges and in particular looks for any collisions between the vendor's code and local customisation. If found,the Programmer "re-engineers" or "retrofits" the Vendor code into local customisation, creating a new versionof the code. The Vendor changes are then packaged and configured as if theywere internal projects, so theycan be further promoted and processed along the SDLC.

In the Programming phase and Implementation phase (Steps #11 and #17 of the SDLC), any Vendordocumentation of their functional changes is transferred ormerged into the locally formatted projectdocumentswhere necessary and applicable.

* * *