Back Matter

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Appendix A: Software Quality Defined

Quality software criteria simplified:

1.
Meets the needs of the user
2.
Robust
3.
Easy to use
4.
Easy to maintain

Attributes of Quality

International Organization for Standardization (ISO)

ISO 25010 (superseding ISO 9126) is a taxonomy of attributes of software quality. The new model has eight characteristics, instead of six, and is quite similar to the old ISO model (Table A-1). The following list shows the main categories and subcategories of ISO 25010 – product quality model.

Functional suitability – The degree to which the product provides functions that meet stated and implied needs when the product is used under specified conditions:

Functional completeness
Functional correctness
Functional appropriateness

Performance efficiency – The performance relative to the amount of resources used under stated conditions:

Time behavior
Resource utilization
Compliance

Compatibility – The degree to which a product, system, or component can exchange information with other products, systems, or components, and/or perform its required functions while sharing the same hardware or software environment:

Coexistence
Interoperability

Usability – The degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use:

Appropriateness and recognizability
Learn ability
Operability
User error protection
User interface aesthetics
Accessibility

Reliability – The degree to which a system or component performs specified functions under specified conditions for a specified period of time:

Maturity
Availability
Fault tolerance
Recoverability

Security – The degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization:

Confidentiality
Integrity
Nonrepudiation
Accountability
Authenticity

Maintainability – The degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers:

Modularity
Reusability
Analyzability
Modifiability
Testability

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

Portability
Adaptability
Install ability
Compliance

Table A-1

ISO attributes mapped to the four criteria from the 1970s

ATTRIBUTE	Meet the Needs of the User	Robust	Easy to Use	Easy to Maintain
Functional Suitability	X
Performance Efficiency		X
Compatibility	X
Usability			X
Reliability		X
Security		X
Maintainability				X
Portability	X

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

Items defined by quality control area

1. Meets the needs of the user

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

Table A-2

Attributes and action items for each area of quality improvement

1970’s Criteria	ISO Attributes of Quality	Action Items
1. Meets the Needs of the User	Functional Suitability Compatibility Portability Security	Develop Vision Statement Identify Security Considerations Create High-Level Process Diagram Identify Nonfunctional Requirements Identify Architectural Requirements Determine Business Rules Review Implementation of Business Rules with Users
2. Easy to Use	Usability	Identify Usability Requirements Review Interface with Users at All Stages of the Emerging System Provide User’s Guide Provide Training
3. Robust	Reliability Performance Efficiency	Identify Security Considerations Provide Error and Conflict Management Perform Input Testing and Load Testing Perform Application Testing at All Stages
4. Easy to Maintain	Maintainability	Adhere to Standards, Guidelines, and Procedures Create Process Diagram of the System Perform Code Walk-Through/Refactoring Create Database Design Document Create Data Dictionary Create a Glossary Create Configuration Management Plan Maintain Traceability Matrix Provide Architecture Documentation

Determine Business Rules
Business rules define the core activities of the organization as embodied in proposed development effort. A “business rule” must be decomposed into a set of atomistic statements that become the testable requirements of the system.
Review Implementation of Business Rules with Users
As the business rules emerge, nuances and ambiguities must be resolved. This can be accomplished through successive iterations of the detailed design cycle.

2. Easy to use

Identify Usability Requirements
These requirements may include accessibility issues and a “three-click” rule: that each function of the system can be accessed in three mouse clicks (or less).
Review Interface with Users at All Stages of the Emerging System
Acceptability of the visual interface can be “washed” several times through successive iterations until the optimum solution emerges.
Provide a User’s Guide
Drafts of the User’s Guide should be delayed until the software has matured to a reasonable level of stability – and should be composed by an experienced technical writer.
Provide Training
Training must include training for the trainers.

3. Robust

Identify Security Considerations
Provide Error and Conflict Management
The system must be “fail soft” such that no application or system error can bring down the system. Application and system errors should produce appropriate error messages.
Perform Input and Load Testing
Does the interface and system remain stable with incorrect input or with the maximum number of users?
Perform Application Testing at All Levels
This includes test-driven development.

4. Easy to maintain

Adhere to Standards, Guidelines, and Procedures
In particular, in-stream comments, screen identifiers and code formatting, process diagram of the system, and diagram of logical database design.
Create a Process Description of the System
In the interpretation of the development model contained herein, the system overview and data dependencies are accomplished by means of data flow diagrams.
Perform Code Walk-Through/Refactoring
Measures taken during the construction cycle to produce clean code facilitating maintenance.
Create Database Design Document
IDEF1X model of the relational database (Integration DEFinition for information modeling).
Create and Maintain Data Dictionary
Compendium of definitions of all database elements should be sortable by element or table name.
Create and Maintain Glossary
Accompanied by list of acronyms and map of the organization.
Create Configuration Management Plan
Identify roles and responsibilities for maintaining Software Configuration Inventory (SWCI) and version control.
Maintain Traceability Matrix
Traces business rules from the Vision Statement to their location in a segment of code.
Provide Architecture Documentation (Application Architecture)
Show how the application shall interface with the logon, sign-off, user identification, and audit trail processes.

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

Appendix B: Summary of Standards, Guidelines, and Procedures

Standards

Standard	Responsible Party	Description
Document Control	Configuration Manager	Example
Requirement Statements and Business Rules	Lead Business Analyst	2 Pages
Configuration Item Naming Conventions	Configuration Manager	Example
Database Naming Conventions	Database Administrator	Example
Data Dictionary	Librarian and Database Administrator	Example
Program Naming Conventions	Lead Tech	Example
Program Style Sheets (For Each Language)	Lead Tech	Example
Standard and Guidelines for In-Stream Comments	Lead Tech	Example
Menu System	Lead Tech	Example
Screen Presentation	Lead Tech	Example
Report Format	Lead Tech	Example

Guidelines

Guideline	Responsible Party	Description
Interpreting DFDs	Lead Business Analyst	Pre-prepared Materials
Expressing Requirements and Business Rules	Lead Business Analyst	Pre-prepared Materials

Policies and Procedures

Procedure	Responsible Party	Description
Procedure for Reviewing Requirements and Business Rules	Lead Business Analyst	1 Page and Checklist
Procedure for Maintaining a Compendium of Requirements Documents	Librarian (Configuration Manager) and Lead Business Analyst	1 Page
Procedures for Managing the CMDB	Configuration Manager	3 Pages
Procedure to Maintain Database of Hardware Requirements (HWCI)	Librarian (Configuration Manager)	1 Page
Procedure to Maintain Database of Nonfunctional Requirements	Librarian (Configuration Manager)	1 Page
Procedure to Process Change Reports (CRpt)	Configuration Manager	1 Page and Form
Procedure for Code Version Control	Lead Tech	(Training)
Procedure for CM Status Accounting from the SWCI Database	Configuration Manager	1 Page
Procedure for baselining Configuration Items	Configuration Manager	1 Page
Migration Plan – procedure to move DB structure across baselined partitions	Database Administrator	2 Pages
Procedure for Adding to Store of Global Variables	Lead Tech	1 Page
Procedure for Error Handling	Lead Tech	1 Page
Procedure for Connecting to the System Architecture	Lead Tech / System Architect	3 Pages
Procedure for Technical Code Inspections and Refactoring	Lead Tech	1 Page and Checklist
Test Protocols Form and Format	Test	2 Pages
Test readiness reviews / Inspections	Software Quality Assurance	Checklist
Procedure to Process Discrepancy Reports (DR)	Configuration Manager	1 Page and Form

Audits

Audit	Responsible Party	Description
Audit Integrity of Pointers from Requirement and Business Rule Data Stores to Offline Compendium of Documents	Quality Assurance Officer	Report
Audit of CRpts Outstanding	Quality Assurance Officer	Report
Audit of Baselined Items	Quality Assurance Officer	Report
Audit Integrity of Traceability Matrix	Configuration Management and Quality Assurance Officer	Report
Audit Execution of Migration Plan (Baselines)	Quality Assurance Officer	Report
Audit Conversion Plan Against Result (Where Applicable)	Quality Assurance Officer	Report
Conduct Data Conversion Readiness Review	Quality Assurance Officer	Report
Conduct Test Readiness Reviews	Quality Assurance Officer	Report
Audit of DRs Outstanding	Quality Assurance Officer	Report

GRAND TOTALS

16 One-Page Documents
3 Two-Page Documents
2 Checklists
2 Forms
9 Examples
9 Reports
1 Entity Relationship Diagram

Additional Materials due at Turnover (For Acceptance Test)	Responsible Party (By Role)
User’ Manual and Training Guide	Technical Writer
Application Administrator’s Manual (Use of System Backbone Features)	Developed In-house for Security
Help Desk Instructions	Technical Writer
Data Dictionary – Online and Printed Copies	Librarian, Data Modeler
Glossary List of Acronyms List of Abbreviations Organization Chart	Librarian
Database Documentation – Entity Relationship Diagram or Big Data Schema	Data Modeler
Database Script Library	Database Administrator (DBA)

Appendix C: Quality Engineering: By Area

Business Analysis

Item	Type	Description
Guideline Interpreting DFDs	Guideline	(Prepared Materials)
Requirements Statements and Business Rules	Standard	1 Page
Guideline Expressing Requirements and Business Rules	Guideline	(Prepared Materials)
Procedure for Reviewing Requirements and Business Rules	Procedure	Checklist

Configuration Management

Item	Type	Description
Procedure for Maintaining a Compendium of Requirements Documents	Procedure	1 Page
Configuration Item Naming Conventions	Standard	Example
Maintain CMBD	Procedure	User’s Guide (Training)
Process Change Reports (CRpts)	Procedure	1 Page Form
Update Status Accounting in the SWCI Database	Procedure	1 Page
Procedure for Baselining Configuration Items – Produce Report	Procedure	1 Page
Process Discrepancy Reports (DRs)	Procedure	1 Page Form

Librarian

Item	Type	Description
Document Control	Standard	Example
Maintain List of Hardware Requirements (HWCI)	Procedure	1 Page
Maintain Database of Other Nonfunctional Requirements	Procedure	1 Page
Maintain Data Dictionary	By Example	1 Page

Database Administration

Item	Type	Description
Database Naming Conventions	Standard	Example
Create Initial Version of Database from DFD	Procedure	ERD
Populate Initial Version with Test Data	Procedure	1 Page
Migration Plan – Procedure to Move DB Structure Across Baselined Partitions	Procedure	2 Pages
Conversion Plan	Procedure	2 Pages

Tech - Programming

Item	Type	Description
Procedure for Code Version Control Tool	Procedure	(Training)
Program Naming Conventions		Example
Program Style Sheets (For Each Language)	Standard	Example
Guidelines for In-Stream Comments	Standard	Example
Format for Menu System	Standard	Example
Format for Screen Presentations	Standard	Example
Format for Reports	Standard	Example
Procedure for Error Handling	Procedure	1 Page
Procedure for Adding to Store of Global Variables	Procedure	1 Page
Procedure for Connecting to the System Architecture	Procedure	2 Pages
Technical Code Inspections and Refactoring	Procedure	Checklist
Make Corrections in Response to Discrepancy Reports	Procedure	1 Page

Software Quality Assurance and Test

Item	Type	Description
Audit Integrity of Pointers from Requirement and Business Rule Data Stores to Offline Compendium of Documents	Audit	Report
Audit of CRpts Outstanding	Audit	Report
Audit of Baselined Items	Audit	Report
Audit of Integrity of Traceability Matrix	Audit	Report
Audit Execution of Migration Plan (Baselines)	Audit	Report
Audit Conversion Plan Against Result (Where Applicable)	Audit	Report
Conduct Data Conversion Readiness Review	Audit	Report
Test Protocols (Form and Format)	Procedure	2 Pages
Test Readiness Reviews/Inspections	Procedure	Report
Audit of DRs Outstanding	Audit	Report

Appendix D: Data Flow Diagramming

Data Flow Diagrams

Data flow diagrams (DFDs) are diagrams showing the flow of data through a system. DFDs show dependencies between processes and data requirements enabling a preliminary database design.

There are two alternative sets of symbols: Chris Gane and Trish Sarson’s notation, first published as Structured Systems Analysis: Tools and Techniques First Edition, July 1977, adopted by the McDonnell Douglas Corporation. The second symbol set is that of Tom DeMarco published in Structured Analysis and System Specification, Prentice Hall Inc., 1979. I have used the Gane and Sarson notation and prefer it to the DeMarco symbol set because the G&S “Process” symbol provides more “real estate” for labeling.

There are only four basic symbols in a DFD: Entities, Data Flows, Processes, and Data Stores (Figure D-1). An Entity can be a person, another system, or subsystem. In the Gane and Sarson notation, there is one additional symbol, a material flow, to denote the transfer of physical objects – such as a library book. Also in G&S, duplicate symbols (used for cosmetic purposes) are notated by an extra line on the symbol. I am introducing two more symbols to the set – a digital data flow to account for the special case of a material flow for the transfer of digitized information such as a digital picture (e.g., an accident damage photo) and a shaded Entity to show only partial involvement in the diagram’s activity.

In addition to the symbol set, there are some basic rules:

The flow of data begins with an external entity leading to a process.
Each external entity must be involved with at least one data flow.
A data flow from an external entity does not go to a data store directly. It must first pass through a process.
All processes should modify incoming data, producing new forms of outgoing data.
All processes must have at least one data flow in and one data flow out.
Data flows are in one direction only. Returning data is represented by a separate data flow.
Each data store must be involved with at least one data flow.
Each data flow must have a unique name.

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

Leveling

Leveling is the art of decomposing a process into its constituent parts – down to the level where the resultant data flow diagram represents the lowest level of process decomposition.

The creation of a DFD may begin with a high-level “Context Diagram,” which shows all the entities involved with the system, a single Process symbol, and the connecting data flows. While the Context Diagram has been variously as numbered 0 or 1 by different practitioners, I prefer the former because it represents no single process, but rather the sum of all processes, or Level 0. The decomposition of the Context Diagram begins with Level 1.

The Level 1 diagram decomposes the context diagram to a set of uniquely named Dataflows, numbered Processes, Datastores, and Entities. Where a numbered Process requires further decomposition, an asterisk (*) will be placed below the Process name.

There is one additional diagram for each process marked for decomposition. Each of the Level 2 diagram’s processes is numbered as a “dot” number referring to the parent process (e.g., 6.1, 6.2, 6.3, etc.) for the Level 2 child diagram of Level 1, Process 6. If Level 2 Process 6.4, for example, has lower-level children (Level 3), the processes thereof will be numbered 6.4.1, 6.4.2, 6.4.3, etc. Another way to remember how levels are numbered is to observe that Level 1 processes are numbered by a single integer (e.g., 6), Level 2 processes are numbered by a number and a dot number (e.g., 6.4), and the third level is numbered by three digits separated by dots (e.g., 6.4.1).

The source (or destination) of each inbound (or outbound) data flow may be a Process, Data Store, or Entity. Each lower diagram is required to show all attached data flows. The rule is that each symbol in the lower level is something not represented uniquely in the upper level.

Why Draw a Data Flow Diagram

The larger question is why an organization needs to automate or improve existing processes. In current terms, an organization undergoes a “Digital Transformation” to be competitive in a digital world.

The answers should not be surprising. They were effectively articulated by Michael Hammer, Beyond Reengineering, Harper Business, 1996. It is defined therein by four principles:

Principle 1 – The mission of a business is to create value for its customers.
“... a company exists to create customer value. Everything a company does must be directed to this end.”
Value can be as simple as offering excellent customer service, or facilitating the process of a customer to spend their money at the business or at its virtual presence on the Internet. In other words, it eliminates customer frustration and saves the customer’s time. For example, Amazon is fundamentally a superior web-based customer service organization, with superior fulfillment processes that happens to sell books, music recordings, and video offerings, initially, now a broad variety of consumer goods supported by the same basic processes.
Principle 2 – It is a company’s processes that create value for its customers
“…a process [is] a group of tasks that create customer value. The tasks are the bits of work that people actually perform, but the tasks themselves do not create value nor do the individuals performing them. It is only the whole process, all the tasks put together, that creates value.”
Principle 3 – Business success comes from superior process performance.
“Execution – process - is the key to contemporary success, not plans – strategies.”
Principle 4 – Superior process performance is achieved by having a superior design, the right people to perform it, and the right environment for them to work in.
“The structure, layout, and the organization of the process – how the individual tasks are performed and integrated – is a critical determinate of how well the process performs.”

A data flow diagram of the “system to be” is an important tool toward uncovering superior process performance.

In general, a DFD:

Narrows the focus of the effort, noting matters out of scope of the Vision Statement
Identifies how data is passed through the organization
Identifies dependencies of processes and data
Identifies timing issues
Decomposes processes to the lowest unit of functionality

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

A Fictitious Example (Reductio Ad Absurdum)

Acme Auto Insurance, with offices in each of the lower 48 states and the District of Columbia, wants to automate manual claim processing to offer a more efficient response to client requests for information regarding their claim. COTS (commercial off-the-shelf) systems for claims processing were examined, but none were without integration of auto insurance with other types of insurance (such as homeowner’s) and were so expensive that development of a bespoke system for claims processing was chosen. There is presently no common procedure for processing claims at each local office, nor is there means to track progress of the incident nationwide.

It was decided that the client contact records and exhibits would be retained at each local office to avoid the accumulation of all contact records and exhibit records from all offices nationwide at the national level. Plus, the maintenance of records at the local level would require quite a large increment of processing power for the hardware at the national system.

The client profile and policy databases are on a central hardware facility held in the main office in Lincoln, Nebraska, available to each local office over a secure Internet connection. It was also decided that a common Incident A summary record be made available on the national system, available to all local offices nationwide.

The Vision Statement for the expansion of services is outlined in the following sections.

Our Goal Is to Improve Customer Service Regarding Claims Management

Interface local Claims management with the National Client Profile and Policy System to improve the ability to respond to claim status inquiries nationwide.
Speed up the process of claim resolution.
Respond promptly to customer requests for information regarding their claim.
Move to digital capture and storage of all documentation (including digital photographs, videos, accident reports, medical claims, repair estimates, and other documentation).
Examine alternatives for document digitization and handling (COTS software).

Process Narrative (System to Be)

The process begins with the registration of a Client Profile and issuance of a custom tailored Policy on the existing national system at the time a new client is enrolled. A Claim is initiated, usually by a phone call, of an initial incident reported to a local office.

Using the national system, the Agent verifies that the person submitting an incident report is in fact an insured client and that the policy reflects a current valid status. The client is notified that the claim has been received and is being processed, and a contact record is created on the local system to document each transaction regarding that claim.

An Incident data store will be created on the national system to reflect the status of processing at the local office closest to the incident, yet available nationwide to the office where the policy was issued.

The next step is to begin to assemble documentation of the incident beginning with the incident report. Other materials may include digital photos of the damage, police reports, policy numbers of the other motorist(s), medical bills, repair costs or estimates, and any other items pertaining to the occurrence. The document acquisition process may also issue requests to the appropriate parties for items not forthcoming.

Each item of evidence received is recorded in an Exhibit database, which stores images and data with the corresponding client, policy, and incident identifiers. There is one exhibit record for each item of documentation. Digital images, including scanned hard copy of each exhibit, are stored in an Image database.

If an incident occurs on the road distant from the local office which issued the policy, the office local to the scene of the accident processes the documentation but enters an Incident record so progress can be monitored at the local office back home. (It is always more efficient to gather information at the office closest to the scene.)

A Context Diagram showing all external entities for the claims processing system is represented in Figure D-3.

The Level 1 diagram (below) depicts claims processing at the first level of detail. Note that I have numbered the Processes with a letter prefix to differentiate the three distinct services of the system:

M – Main office engagement of the insured to the system by an Agent of the firm.
C – Manage Image Records; assemble documentation.
Ordinal numbers alone – Response to inquiries.

In addition, data stores are identified in two categories: national, with an N prefix, and local with a D prefix.

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

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

Hardcopy documents are Bates Stamped by the Document Capture Section to generate date of receipt and identification number. They are then scanned and given a visual inspection. The document is rescanned and/or subjected to visual enhancement as required to create the best image possible. Hardcopy is archived in Manual Document Storage. The Exhibit database is updated and made available to the local office.

In parallel, documents arriving in digital form, such as digital photos or videos, are visually inspected and enhanced as necessary. The Exhibit database is updated, and the digital items are passed to Digital Quality Control.

In the system to be, the Document Capture Section scans all hardcopy and records each, as well as digital items (like scene photos), in an Image data structure synchronized with Exhibit and checked by the Quality Control Section. The set of all current data is then processed by the Analysis Section in the main office. All communication regarding each claim is recorded in a Contact database.

The Image structure is defined by a set of disk directories based on Claim number. Each record from each database is “filed” under its corresponding Claim number. Images are stored as jpeg files.

Short Specification for the Claims Department Information Image Processing Subsystem

The system must accommodate all materials tied to a specific claim:
- Digitized (scanned) printed material
- Digital photos and/or videos
The system must be able to enhance “fuzzy” (focus) or “blurred” (contrast) images and convert images to jpeg files.
The system must provide for Image Quality Control for receipt of digitized documentation.
The system must accept distinct image labels.
The system must produce management reports for the main office.

Data Dictionary

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

The result is a preliminary outline for a Respond to Client Inquiry and Document Handling system that could be applied to a number of situations. It also results in a preliminary database design that can be physically instantiated and populated with test data for the implementation of the system as a whole – including management tracking and summary reports.

Omitted from this overall design is the ability to sign on and sign off, to add and subtract users, to assign security levels, and to provide the ability to change passwords and track (audit) user activity if required.

One huge risk is finding a way to transfer the Client and Policy information from the central data system to the local subsystem (or vice versa).

From the Documentation Block (DocBlock) on the Process Claim Level 1 DFD, this solo design effort lasted 6 weeks. This duration was not working every day; it allowed time off for rejuvenation and thinking time for the “little gray cells” to reformulate the problem. Finally, to fulfill the last objective of the Vision Statement, the search for a COTS (commercial off-the-shelf) system should simultaneously be carried out by a business analyst with technical experience. At the least, turnkey image enhancement software needs to be added to the list of alternatives.

The DFD in its present form identifies three new “Services” and can serve as a functional requirements specification document from which early estimates of required staffing (and cost) can be derived.

1.
Verify caller’s status:
- Capture client ID and policy number on local system.
- Initiate Incident record on national system.
2.
Track contacts:
- Initiate a contact record on the local system.
- Assign unique record number.
3.
Collect, digitize, and store exhibits.
- Update Incident Record.

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

Resources by Category

SOCIAL COMMENTARY

Axelrod, Robert. The Evolution of Cooperation. Cambridge, MA: Basic Books, 1984

Chase, Stuart (ed), Language Thought and Reality. Selected Writings of Benjamin Lee Worf. Mansfield Centre, CT: Martino Publishing, 2011

DeMarco, Tom & Timothy Lister. Peopleware. 2nd ed. Atlanta: Dorset House, 1999

Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago University Press, 1996

Ries, Eric. The Lean Startup. New York: Penguin Random House LLC, 2011

Schrange, Michael. No More Teams. Mastering the Dynamics of Creative Collaboration. New York: Doubleday, 1989

Winograd, Terry & Fernando Flores. Understanding Computers and Cognition. Reading, MA: Addison-Wesley, 1987

PERSPECTIVES

Adzic, Gojko. Bridging the Communication Gap. London, UK: Neuri, 2009

Boehm, Barry & Richard Turnet. Balancing Agility and Discipline. Boston: Addison-Wesley,2003

Brooks Jr., Frederick P. The Mythical Man Month (Anniversary Edition). Boston: Addison-Wesley, 2006

DeMarco, Tom & Timothy Lister. Waltzing with Bears. Englewood Cliffs, NJ: Yourdon Press, 2004

Boutros, Tristan & Jennifer Cardela. The Basics of Process Improvement. Boca Raton, FL: CRC Press, 2016

Glass, Robert L. Software Conflict 2.0. Atlanta: Developer*, 2003

Hammer, Michael. Beyond Reengineering. How the Process-Centered Organization is Changing Our Work and Our Lives. New York: HarperCollins, 1996

Hammer, Michael & James Champy. Reengineering the Corporation. New York: HarperCollins, 2003

Highsmith, Jim et al. Edge. Value Driven Digital Transformation. n.p.: Pearson Education, Inc., 2020

Hooks, Ivy F. & Kristin A. Farry. Customer Centered Products. Creating Successful Products Through Smart Requirements Management. New York: American Management Association, 2001

Johnson, Jim. My Life is Failure. West Yarmouth, MA: Standish Group International Inc., 2006

Oram, Andy &Greg Wilson Eds. Making Software. Sebastopol, CA: O’Reilly, 2011

Sakai, Takao. The Secret Behind the Success of Toyota, n.p., n.a, 2018

Yourdon, Edward. Death March 2nd ed. Boston: Addison-Wesley, 1995

APPLICATION LIFECYCLE MANAGEMENT

Aeillo, Bob & Leslie Sachs. Agile Application Lifecycle Management. Boston: Addison-Wesley, 2016

Huttermann, Michael. Agile ALM. Shelter Island, NY: Manning, 2012

Rossberg, Joachim. Beginning Application Lifecycle Management. New York: Apress, 2014

PROJECT MANAGEMENT

DeMarco, Tom. Controlling Software Project. Englewood Cliiffs, NJ: Yourdon Press A Prentice Hall Company, 1982

DeMarco, Tom. The Deadline. Atlanta: Dorset House, 1997

Gilb, Tom. Principles of Software Engineering Management. Boston: Addison-Wesley, 1988

Highsmith, Jim., Agile Project Management: Creating Innovative Products, 2nd Edition. Upper Saddle River: NJ; Addison Wesley, 2010

Humphrey, Watts S. Managing the Software Process. Boston: Addison-Wesley, 1989

McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1988

Royce, Walker. Software Project Management A Unified Framework. Boston: Addison-Wesley, 1998

Schwaber, Ken. Agile Project Management with Scrum. Sebastopol, CA: O’Reilly, 2003

Stellman, Andrew & Jennifer Greene. Applied Software Project Management. Redmond, WA: Microsoft Press, 2013

Tillman, George. Project Management Scholia., n.p.,: Stockbridge Press, 2019

Weinberg, Gerald M. Quality Software Management. Volume 1 Systems Thinking. New York;, Dorset House, 1992

Whitten, Neal., Managing Software Development Projects, 2nd Ediition. New York: John Wiley & Sons, 1995

RISK MANAGEMENT

Boehm, Barry W. Tutorial: Software Risk Assessment. Washington, DC: IEEE Computer Society Press, 1989

Hall, Elaine M. Managing Risk. Boston: Addison-Wesley, 1988

Karolak, Dale Walker. Software Engineering Risk Management. Los Alamitos, CA: IEEE Computer Society Press, 1996

APPROACH

Ambler, Scott W.`The Object Primer. 3rd ed. New York, NY: Cambridge, 2009

Cohn, Mike. Succeeding With Agile. Boston: Addison-Wesley, 2010

Poppendiek, Mary & Tom Poppendiek. Lean Software Development. Boston: Addison-Wesley, 2003

Poppendiek, Mary & Tom Poppendiek. Implementing Lean Software Development. Boston: Addison-Wesley, 2007

OVERVIEW

Abahamsson, Pekka et al. Agile Software Development Methods: Review and Analysis. Otamedia, Finland: VTT Publications 478.2002

Larman, Craig. Agile and Iterative Development. Boston: Addison-Wesley, 2004

METHODOLOGY

Ambler, Scott W. & Mark Lines. Disciplined Agile Delivery. Boston: IBM Press, 2012

Ambler, Scott W. & Mark Lines. Choose Your WoW. Newtown Square, PA: Project Management Institute, Inc., 2020

Cockburn, Alistair. Crystal Clear. Boston: Addison-Wesley, 2005

Highsmith, James A. Adaptive Software Development. Atlanta: Dorset House, 2000

Knaster, Richard & Dean Leffingwell. SAFe Distilled 4.5. Boston: Addison-Wesley, 2011

Lines, Mark & Scott W. Ambler. Introduction to Disciplined Agile Delivery 2nd Ed. n.p. self, 2018

Martin, James. Rapid Application Development. New York: MacMillan Publishing Company, 1991

McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996

Rubin, Kenneth S. Essential Scrum. Boston: Addison-Wesley, 2013

Schwaber, Ken & Mike Beedle. Agile Development with Scrum. Upper Saddle River, NJ: Prentice Hall, 2002

Stapleton, Jennifer. DSDM Dynamic Systems Development Method. Edinburgh, England: Pearson Education Limited,1997

UNIFIED PROCESS

Ambler, Scott W. & Larry L. Constantine. The Unified Process Inception Phase. Lawrence, KS: CMP Books, 2000

Ambler, Scott W. & Larry L. Constantine. The Unified Process Elaboration Phase. Lawrence, KS: CMP Books, 2000

Ambler, Scott W. & Larry L. Constantine. The Unified Process Construction Phase. Lawrence, KS: CMP Books, 2000

Ambler, Scott W. & Larry L. Constantine. The Unified Process Transition and Production Phases. Lawrence, KS: CMP Books, 2002

Cockburn. Alistair. Writing Effective Use Cases. n.p.: self, 2001

Jacobson, Ivar et al. The Unified Software Development Process. Boston: Addison-Wesley, 2004

Kroll, Per & Phillippe Kruchten. The Rational Unified Process Made Easy. Boston: Addison-Wesley, 1999

Kruchten, Pillippe. The Rational Unified Process, An Introduction 3rd ed. Boston: Addison-Wesley, 2003

METHODS - DRIVEN DEVELOPMENT

DD.Adzic, Gojko. Specification by Example. Shelter Island, NY: Manning, 2011

Gartner, Markus. ATDD by Example. Boston: Addison-Wesley, 2013

Koskela, Lassse. Test Driven. Shelter Island, NY: Manning, 2008

Nagy, Gaspar & Seb Rose. The BDD Books: Discovery. n.p.: self, 2021

Palmer, Stephan R. A Practical Guide to Feature Driven Development. Upper Saddle River, NJ: Prentice Hall, 2002

Pugh, Ken. Lean-Agile Acceptance Test-Driven Development. Boston: Addison-Wesley, 2011

Rose, Seb & Gaspar Navy. The BDD Books: Formulation. n.p: self, 2018

Stewart, John Ferguson.BDD in Action. Shelter Island, NY: Manning, 2015

TECHNIQUE

Ambler, Scott W. Agile Modeling. Boston: Addison-Wesley, 2011

Beck, Kent. Test-Driven Development. New York Addison-Wesley, 2007

Beck, Kent. extreme Programming explained. New York: Addison-Wesley, 2000

Beck, Kent & Martin Fowler. Planning Extreme Programming. Boston: Addison-Wesley, 2001

Bolboacä, Adrian. Practical Remote Pair Programming. Birmingham, UK; Packt Publishing, 2021

Chorafas, Dinitris N. Enterprise Architecture and New Generation Systems. Boca Raton, FL: St. Lucie Press. A CRC Press Company. 2002

Duval, Paul M. Continuous Integration. Boston: Addison-Wesley, 2003

Feathers, Michael C. Working Effectively with Legacy Code. Upper Saddle River, NJ: Prrentice Hall, 2005

Humble, Jez & David Farley. Continuous Delivery. Upper Saddle River, NJ: Prentice Hall, 2005

Martin, Robert C. Clean Architecture. Boston: Addison-Wesley, 2018

Mugridge, Rick & Ward Cunningham. Fit for Developing Software. New York: Prentice Hall, 2002

Muggridge, Rick & Ward Cunningham. FIT for Integrated Tests. Upper Saddle River, NJ: Prentice Hall, 2005

Newkirk, James & Robert C. Martin. Extreme Programming in Practice. Boston: Addison-Wesley, 2001

Nicega, Knil. Writing Great Specifications. Shelter Island, NY: Manning, 2018

Ruping, Andreas. Agile Documentation. Boston: Addison-Wesley, 2007

BUSINESS ANALYSIS AND REQUIREMENTS

Beaty, Joy & Anthony Xhen. Visual Models for Software Requirements. Redmond, WA: Microsoft Press, 2012

Davis, Alan M. Software Requirements, revision. Upper Saddle River, NJ: Prentice Hall, 1993

Davis, Alan M. Just Enough Requirements Management. Boston: Addison-Wesley, 2011

Gause, Donald C. & Gerald M. Wiesenberg. Exploring Requirements. Atlanta: Dorset House, 1989

Goldsmith, Robin F. Discovering REAL Business Requirements for Software Project Success. Norwood, MA: Artech House Inc., 2004

Hay, David C. Requirements Analysis. Upper Saddle River, NJ: Prentice Hall, 2003

Heath, Fred. Managing Requirements the Agile Way, Liverey Place, Birmingham, UK: Packt Publishing, 2020

Leffingwell, Dean. Agile Software Requirements. Boston: Addison-Wesley, 2003

Leffingwell, Dean. Managing Software Requirements. 2nd ed. Boston: Addison-Wesley, 2016

McDonald, Kenty J. Beyond Requirements. Redmond, WA: Microsoft Press, 2013

Podeswa, Howard. The Agile Guide to Business Analysis and Planning. Boston: Addison-Wesley, 2021

Podeswa, Howard. The Business Analyst’s Handbook. Boston: Course Technology, 2009

Sampaio, Julio Cesar et al. Perspectives on Software Requirements. Norwell, MA: Kluwer, 2004

Wiegers, Karl & Joy Beatty. Software Requirements 3rd ed. Atlanta: Dorset House, 2005

Withall, Stephen. Software Requirement Patterns. Redmond, WA: Microsoft Press, 2007

BUSINESS RULES

Morgan, Tracy. Business Rules and Information Systems. Boston: Addison-Wesley, 2002

Ross, Ronald G. Principles of the Business Rule Approach. Boston: Addison-Wesley, 2003

Ross, Ronald G. Business Rule Concepts. 3rd ed. n.p: Business Rule Solutions LLC, 2009

von Halle, Barbara. Business Rules Applied. New York: Wiley, 2002

USER STORIES

Adzic, Gojko & David Evans. Fifty Quick Ideas to Improve Your User Stories. London, UK: Neuri, 2014

Cohn, Mike. User Stories Applied. Boston: Addison-Wesley, 2003

Patton, Jeff. User Story Mapping. Sebastopol, CA: O’Reilly, 2014

DATABASE

Ambler, Scott W. Agile Database Techniques. New York: Wiley, 2003

Burns, Larry. Building the Agile Database. Westfield, NJ: Technics Publications, 2011

Gurnsey III, Max. Test-Driven Database Development. Boston: Addison-Wesley, 2013

O’Donnell, Glen & Carlos Casanova. The CMDB Imperative. Upper Saddle River, NJ: Prentice Hall, 2009

TEST

Axelrod, Aron. Complete Guide to Test Automation. New York: Apress, 2018

Belzer, Borix. Software Testing Techniques 2nd ed. New York, NY: Van Nostrand Reinhold, 1990

Crispen, Lisa & Janet Gregory. Agile Testing. Boston: Addison-Wesley, 2009

Gregory, Janet & Lisa Crispen. More Agile Testing. Boston: Addison-Wesley, 2015

Gregory, Janet & Lisa Crispen. Agile Testing Condensed. n.p.: Leanpub, 2019

Khorkov, Vladmir. Unit Testing. Shelter Island, NY: Manning, 2020

Lewis, William E. Software Testing and Continuous Quality Improvement. Boca Raton, FL: CRC Press, 2009

Meters, Glenford J. The Art of Software Testing. New York: Wiley, 1979

Paskal, Greg. Test Guide to Automation in the Real World. n.p.: self, 2017

Rasmunusson, Jonathan. The Way of the Web Tester. n.p.: Pragmatic Programmers, 2016

Schaeffer, Jeffrey et al. The Kitty Hawk Venture. New York: Apress, 2018

Tarlinder, Alexander. Developer Testing. Boston: Addison-Wesley, 2017

DEVOPS

Davis, Jennifer & Katherine Daniels. Effective DevOps. Portland, OR: IT Revolution Press, 2013

Hutterman, Michael. DevOps for Developers. New York: Apress, 2012

Kim, Gene & Jez Humble et.al. DevOps Handbook. 1^st ed. Portland, OR: IT Revolution Press, 2016

Kim, Gene et.al. The Phoenix Project (revised). Sebastopol, CA: O’Reilly, 2016

SUPPORT

Glass, Robert & Ronald A. Noiseux. Software Maintenance Guidebook. Upper Saddle River, NJ: Prentice Hall, 1981

Grub, Penny & Armstrong A. Takang. Software Maintenance Concepts and Practice 2nd Ed. Toh Tuck Link, Singapore: World Scientific Publishing Co., 2003

Lientz, Bennet P. & E. Burton Swanson. Software Maintenance Management. Boston: Addison-Wesley, 1980

Martin, James & Carma McClure. Software Maintenance. Upper Saddle River, NJ: Prentice Hall, 1983

Pigoski, Thomas M. Practical Software Maintenance. New York: Wiley, 1997

Polo, Maricio, Mario Piatinni. Advances in Maintenance Management. Hershey, PA: Idea Group Publishing, 2003

Swanson, E. Burton & Emanuel R. Bakeh. Maintaining Information Systems in Organizations. New York: Wiley, 1989

ON QUALITY

Crosby, Philip B. Quality is Free. New York: McGraw-Hill, 1979

Deming, W. Edwards. Out of the Crisis, Cambridge. MA: MIT Press, 1982

Deming, W. Edwards. The New Economics. 2nd ed. Cambridge, MA: MIT Press, 1994

Feigenbaum, Armand V. Total Quality Control. 3rd ed. New York: McGraw-Hill, 1961

Juran, J.M. Juran on Planning for Quality. New York: The Free Press. A Division of Macmillan Inc., 1988

Juran, J.M. (editor in chief). A History of Managing for Quality, Milwaukee, WI: ASQC Quality Press, 1995

Jones, Capers. Applied Software Measurement. 3rd ed. New York: McGraw-Hill, 2008

Walton, Mary. The Deming Management Method. New York: The Putnam Publishing Group, 1986

SOFTWARE QUALITY ENGINEERING

Daugherty, Taz. Fundamental Concepts for the Quality Engineer. Upper Saddle River NJ: Prentice Hall, 1992

Freedman, Daniel P & Gerald M. Weinberg. Handbook or Walkthroughs, Inspections, and Technical Reviews. New York: Dorset House, 2002

Galin, Daniel. Software Quality Assurance. Boston: Addison-Wesley, 2004

Glass, Robert L. Building Quality Software. Upper Saddle River, NJ: Prentice Hall, 1992

Jones, Capers & Oliver Bonsignour. The Economics of Software Quality. Boston: Addison-Wesley, 2012

Kennett, Ron S. & Emanuel R. Baker. Software Process Quality. Atlanta: Dorset House, 1990

Tian, Jeff. Software Quality Engineering. Hoboken, NJ: Wiley Interscience, 2005

CONFIGURATION MANAGEMENT

Aiello, Bob & Leslie Sachs. Configuration Management. Boston: Addison-Wesley, 2011

Babich, Wayne A. Software Configuration Management. Boston: Addison-Wesley, 1986

Berczuk, Stephen P. Software Configuration Management Patterns. Boston: Addison-Wesley, 2003

Martynov, Max & Krill Evstigneev. Continuous Delivery Blueprint. n.p.: Grid Dynamics, 2017

STRUCTURED TECHNIQUES

Barker, Richard & Cliff Longman. Case*Method, Boston: Addison Wesley, 1992

Demarco, Tom. Structured Analysis and System Specification. Englewood Cliiffs, NJ: Yourdon Press, 1978

Gane, Chris & Trish Sarson. Structured Systems Analysis.New York: Improved System Technologies, Inc. 1977

McGraw Karen & Karan Harbison. User Centered Requirements. Mahwah, NJ: Lawrence Erilbaum Associates Inc., 1997

Page-Jones, Meilir. Structured System Design. Upper Saddle River, NJ: Prentice Hall, 1988

Weaver, Audry M. Using the Structured Techniques. Englewood Cliffs, NJ: Yourdon Press, 1987

JOINT APPLICATION DESIGN / DEVELOPMENT

August, Judy H. Joint Application Design. Upper Saddle River, NJ: Prentice Hall, 1991

Wood, Jane & Denise Silver. Joint Application Development. New York: Wiley, 1995

Resources by Author

Abahamsson. Pekka et al. Agile Software Development Methods: Review and Analysis. Otamedia, Finland: VTT Publications 478, 2002

Adzic, Gojko. Bridging the Communication Gap. London. UK: Neuri, 2009

Adzic, Gojko. Specification by Example. Shelter Island. NY: Manning, 2011

Adzic, Gojko & David Evans. Fifty Quick Ideas to Improve Your User Stories. London. UK: Neuri, 2014

Aeillo, Bob & Leslie Sachs. Agile Application Lifecycle Management. Boston: Addison Wesley, 2016

Aiello, Bob & Leslie Sachs. Configuration Management. Boston: Addison-Wesley, 2011

Ambler, Scott W. Agile Modeling. Boston: Addison-Wesley, 2011

Ambler, Scott W. Agile Database Techniques. New York: Wiley, 2003

Ambler, Scott W. & Larry L. Constantine. The Unified Process Inception Phase. Lawrence. KS: CMP Books, 2000

Ambler, Scott W. & Larry L. Constantine. The Unified Process Elaboration Phase. Lawrence. KS: CMP Books, 2000

Ambler, Scott W. & Larry L. Constantine. The Unified Process Construction Phase. Lawrence. KS: CMP Books, 2000

Ambler, Scott W. & Larry L. Constantine. The Unified Process Transition and Production Phases. Lawrence KS: CMP Books, 2002

Ambler. Scott W. & Mark Lines. Disciplined Agile Delivery. Boston: IBM Press, 2012

Ambler, Scott W. & Mark Lines. Choose Your WoW. Newtown Square, PA: Project Management Institute, Inc., 2020

Ambler, Scott W. The Object Primer 3rd ed. New York: Cambridge, 2009

August, Judy H. Joint Application Design. Upper Saddle River, NJ: Prentice Hall, 1991

Axelrod, Aron. Complete Guide to Test Automation. New York: Apress, 2018

Axelrod, Robert. The Evolution of Cooperation. Cambridge. MA: Basic Books, 1984

Babich, Wayne A. Software Configuration Management. Boston: Addison-Wesley, 1986

Barker, Richard & Cliff Longman. Case*Method. Boston: Addison-Wesley, 1992

Beaty, Joy & Anthony Xhen. Visual Models for Software Requirements. Redmond, WA: Microsoft Press, 2012

Beck, Kent. Extreme Programming Explained. Boston: Addison-Wesley, 2000

Beck, Kent. Test-Driven Development. Boston: Addison-Wesley, 2007

Beck, Kent & Martin Fowler. Planning Extreme Programming. Boston: Addison-Wesley, 2001

Belzer, Borix. Software Testing Techniques 2nd Edition. New York: Van Nostrand Reinhold, 1990

Berczuk. Stephen P. Software Configuration Management Patterns. Boston: Addison-Wesley, 2003

Boehm. Barry W. Tutorial: Software Risk Assessment. Washington.DC: IEEE Computer Society Press, 1989

Boehm, Bary & Richard Turnet. Balancing Agility and Discipline. Boston: Addison-Wesley, 2003

Boutros, Tristan & Jennifer Cardela. The Basics of Process Improvement. Boca Raton. FL: CRC Press, 2016

Brooks Jr., Frederick P. The Mythical Man Month (Aniversary Edition). Boston: Addison-Wesley, 2006

Burns, Larry. Building the Agile Database. Westfield. NJ: Technics Publications, 2011

Chase, Stuart (ed). Language Thought and Reality: Selected Writings of Benjamin Lee Worf. Mansfield Centre, CT: Martino Publishing, 2011

Chorafas, Dinitris N. Enterprise Architecture and New Generation Systems. Boca Raton. FL: St. Lucie Press, A CRC Press Company, 2002

Cockburn, Alistair. Crystal Clear. Boston: Addison-Wesley, 2005

Cockburn, Alistair. Writing Effective Use Cases. n.p: self, 2001

Cohn, Mike. Succeeding With Agile. Boston: Addison-Wesley, 2010

Cohn, Mike. User Stories Applied. Boston: Addison-Wesley, 2003

Crispen, Lisa & Janet Gregory. Agile Testing. Boston: Addison-Wesley, 2009

Crosby, Philip B. Quality is Free. New York: McGraw-Hill, 1979

Daugherty, Taz. Fundamental Concepts for the Quality Engineer. Upper Saddle River. NJ: Prentice Hall, 1992

Davis, Alan M. Just Enough Requirements Management. Boston: Addison-Wesley, 2011

Davis, Alan M. Software Requirements revision. Upper Saddle River. NJ: Prentice Hall, 1993

Davis, Jennifer & Katherine Daniels. Effective DevOps. Portland, OR: IT Revolution Press, 2013

DeMarco, Tom. The Deadline. Atlanta: Dorset House, 1997

DeMarco, Tom. Controlling Software Projects. Englewood Cliffs, NJ: Yourdon Press. A Prentice Hall Company, 1982

Demarco. Tom. Structured Analysis and System Specification. Englewood Cliffs, NJ: Yourdon Press, 1978

DeMarco, Tom & Timothy Lister. Peopleware 2nd Ed. Atlanta: Dorset House, 1999

DeMarco, Tom & Timothy Lister. Waltzing with Bears. Englewood Cliffs, NJ: Yourdon Press, 2004

Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Press, 1982

Deming, W. Edwards. The New Economics 2nd Edition. Cambridge, MA: MIT Press, 1994

Duval, Paul M. Continuous Integration. Boston: Addison-Wesley, 2003

Feathers, Michael C. Working Effectively with Legacy Code. Upper Saddle River, NJ: Prentice Hall, 2005

Feigenbaum, Armand V. Total Quality Control 3rd Edition. New York: McGraw-Hill, 1961

Freedman, Daniel P & Gerald M. Weinberg. Handbook or Walkthroughs. Inspections. and Technical Reviews. New York: Dorset House, 2002

Galin. Daniel. Software Quality Assurance. Boston: Addison-Wesley, 2004

Gane, Chris & Trish Sarson. Structured Systems Analysis. New York: Improved System Technologies. Inc., 1977

Gartner, Markus. ATDD by Example. Boston: Addison-Wesley, 2013

Gause, Donald C. & Gerald M. Wiesenberg. Exploring Requirements. Atlanta: Dorset House, 1989

Gilb, Tom. Principles of Software Engineering Management. Boston: Addison-Wesley, 1988

Glass, Robert & Ronald A. Noiseux. Software Maintenance Guidebook. Upper Saddle River. NJ: Prentice Hall, 1981

Glass, Robert L. Software Conflict 2.0. Atlanta: Developer*, 2003

Glass, Robert L. Building Quality Software. Upper Saddle River. NJ: Prentice Hall, 1992

Goldsmith, Robin F. Discovering REAL Business Requirements for Software Project Success. Norwood, MA: Artech House Inc., 2004

Gregory, Janet & Lisa Crispen. More Agile Testing. Boston: Addison-Wesley, 2015

Gregory, Janet & Lisa Crispen. Agile Testing Condensed. n.p: Leanpub, 2019

Grub, Penny & Armstrong A. Takang. Software Maintenance Concepts and Practice 2nd Ed. Toh Tuck Link. Singapore: World Scientific Publishing Co., 2003

Gurnsey III. Max. Test-Driven Database Development. Boston: Addison-Wesley, 2013

Hall, Elaine M. Managing Risk. Boston: Addison-Wesley, 1988

Hammer, Michael. Beyond Reengineering. How the Process-Centered Organization is Changing Our Work and Our Lives. New York: HarperCollins, 1996

Hammer, Michael & James Champy. Reengineering the Corporation: Revised and Updated. New York: HarperCollins, 2003

Hay, David C. Requirements Analysis. Upper Saddle River. NJ: Prentice Hall, 2003

Heath, Fred. Managing Requirements the Agile Way. Liverey Place. Birmingham. UK: Packt Publishing, 2020

Highsmith, James A. Adaptive Software Development. Atlanta: Dorset House, 2000

Highsmith, Jim. Agile Project Management: Creating Innovative Products 2nd Edition. Boston: Addison Wesley, 2010

Hooks, Ivy F. & Kristin A. Farry. Customer Centered Products: Creating Successful Products Through Smart Requirements Management. n.p.: American Management Association, 2001

Humble, Jez & David Farley. Continuous Delivery. Upper Saddle River, NJ: Prentice Hall, 2005

Humphrey, Watts S. Managing the Software Process. Boston: Addison-Wesley, 1989

Hutterman, Michael. DevOps for Developers. New York: Apress, 2012

Huttermann, Michael. Agile ALM. Shelter Island, NY: Manning, 2012

Jacobson, Ivar et al. The Unified Software Development Process. Boston: Addison-Wesley, 2004

Johnson, Jim. My Life is Failure. West Yarmouth, MA: Standish Group International Inc., 2006

Jones, Capers. Applied Software Measurement 3rd Edition. New York: McGraw-Hill, 2008

Jones, Capers & Oliver Bonsignour. The Economics of Software Quality. Boston: Addison-Wesley, 2012

Juran, J.M. Juran on Planning for Quality. New York: The Free Press. A Division of Macmillan Inc., 1988

Juran, J.M. (editor in chief). A History of Managing for Quality. Milwaukee, WI: ASQC Quality Press, 1995

Karolak, Dale Walker. Software Engineering Risk Management. Los Alamitos, CA: IEEE Computer Society Press, 1996

Kennett, Ron S. & Emanuel R. Baker. Software Process Quality. Atlanta: Dorset House, 1990

Khorkov, Vladmir. Unit Testing. Shelter Island, NY: Manning, 2020

Kim, Gene & Jez Humble et.al. DevOps Handbook (first edition). Portland, OR: IT Revolution Press, 2016

Kim, Gene et.al. The Phoenix Project (revised). Sebastopol, CA: O’Reilly, 2016

Knaster, Richard & Dean Leffingwell. SAFe Distilled 4.5. Boston: Addison-Wesley, 2011

Koskela, Lassse. Test Driven. Shelter Island, NY: Manning, 2008

Kroll, Per & Phillippe Kruchten. The Rational Unified Process Made Easy. Boston: Addison-Wesley, 1999

Kruchten, Pillippe. The Rational Unified Process An Introduction 3rd ed. Boston: Addison-Wesley, 2003

Kuhn, Thomas S. The Structure of Scientific Revolutions 3rd Ed. Chicago: University of Chicago University Press, 1996

Larman, Craig. Agile and Iterative Development. Boston: Addison-Wesley, 2004

Leffingwell, Dean. Agile Software Requirements. Boston: Addison-Wesley, 2003

Leffingwell, Dean. Managing Software Requirements 2nd Ed. Boston: Addison-Wesley, 2016

Lewis, William E. Software Testing and Continuous Quality Improvement. Boca Raton, FL: CRC Press, 2009

Lientz, Bennet P. & E. Burton Swanson. Software Maintenance Management. Boston: Addison-Wesley, 1980

Lines, Mark & Scott W. Ambler. Introduction to Disciplined Agile Delivery 2nd Ed. n.p.: self published, 2018

Martin. James. Rapid Application Development. New York: MacMillan Publishing Company, 1991

Martin, James & Carma McClure. Software Maintenance. Upper Saddle River, NJ: Prentice Hall, 1983

Martin, Robert C. Clean Architecture. Boston: Addison-Wesley, 2018

Martynov, Max & Krill Evstigneev. Continuous Delivery Blueprint. n.p: Grid Dynamics, 2017

McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1988

McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996

McDonald. Kenty J. Beyond Requirements. Redmond, WA: Microsoft Press, 2013

McGraw Karen & Karan Harbison. User Centered Requirements. Mahwah, NJ: Lawrence Erilbaum Associates. Inc., 1997

Meters, Glenford J. The Art of Software Testing. New York: Wiley, 1979

Morgan, Tracy. Business Rules and Information Systems. Boston: Addison-Wesley, 2002

Muggridge, Rick & Ward Cunningham. FIT for Integrated Tests. Upper Saddle River, NJ: Prentice Hall, 2005

Mugridge, Rick & Ward Cunningham. Fit for Developing Software. Upper Saddle River, NJ: Prentice Hall, 2002

Nagy, Gaspar & Seb Rose. The BDD Books: Discovery. n.p: self, 2021

Newkirk, James & Robert C. Martin. Extreme Programming in Practice. Boston: Addison-Wesley, 2001

Nicega, Knil. Writing Great Specifications. Shelter Island. NY: Manning, 2018

O’Donnel, Glen & Carlos Casanova. The CMDB Imperative. Upper Saddle River, NJ: Prentice Hall, 2009

Page-Jones, Meilir. Structured System Design. Upper Saddle River. NJ: Prentice Hall, 1988

Palmer, Stephan R. A Practical Guide to Feature Driven Development. Upper Saddle River, NJ: Prentice Hall, 2002

Paskal Greg. Test Guide to Automation in the Real World. n.p: self, 2017

Patton Jeff. User Story Mapping. Sebastopol. CA: O’Reilly, 2014

Pigoski Thomas M. Practical Software Maintenance. New York: Wiley, 1997

Podeswa Howard. The Agile Guide to Business Analysis and Planning. Boston: Addison-Wesley, 2021

Podeswa Howard. The Business Analyst’s Handbook. Boston: Course Technology, 2009

Polo, Maricio. Mario Piatinni. Advances in Maintenance Management. Hershey, PA: Idea Group Publishing, 2003

Poppendiek, Mary & Tom Poppendiek. Lean Software Development. Boston: Addison-Wesley, 2003

Poppendiek, Mary & Tom Poppendiek. Implementing Lean Software Development. Boston: Addison-Wesley, 2007

Pugh, Ken. Lean-Agile Acceptance Test-Driven Development. Boston: Addison-Wesley, 2011

Rasmunusson, Jonathan. The Way of the Web Tester. n.p: Pragmatic Programmers, 2016

Reis, Eric. The Lean Startup. New York: Penguin Random House. LLC, 2011

Rose, Seb & Gaspar Navy. The BDD Books: Formulation. n.p: self, 2018

Ross, Ronald G. Principles of the Business Rule Approach. Boston: Addison-Wesley, 2003

Ross, Ronald G. Business Rule Concepts 3rd ed. n.p: Business Rule Solutions LLC, 2009

Rossberg, Joachim. Beginning Application Lifecycle Management. New York: Apress, 2014

Royce, Walker. Software Project Management A Unified Framework. Boston: Addison-Wesley, 1998

Rubin, Kenneth S. Essential Scrum. Boston: Addison-Wesley, 2013

Ruping, Andreas. Agile Documentation. Boston: Addison-Wesley, 2000

Ruping, Andreas. Agile Documentation. Boston: Addison-Wesley, 2007

Sakai, Takao. The Secret Behind the Success of Toyota. n.p.: n.p, 2018

Sampaio, Julio Cesar et al. Perspectives on Software Requirements. Norwell, MA: Kluwer, 2004

Schaeffer, Jeffrey et al. The Kitty Hawk Venture. New York: Apress, 2018

Schrange, Michael. No More Teams: Mastering the Dynamics of Creative Collaboration. New York: Doubleday, 1989

Schwaber, Ken. Agile Project Management with Scrum. Sebastopol, CA: O’Reilly, 2003

Schwaber, Ken & Mike Beedle. Agile Development with Scrum. Upper Saddle River, NJ: Prentice Hall, 2002

Stapleton, Jennifer. DSDM Dynamic Systems Development Method. Edinburgh, England. Pearson Education Limited, 1997

Stellman, Andrew & Jebbifer Greene. Applied Software Project Management. Redmond, WA: Microsoft Press, 2013

Stewart, John Ferguson. BDD in Action. Shelter Island, NY: Manning, 2015

Swanson, E. Burton & Emanuel R. Bakeh. Maintaining Information Systems in Organizations. New York: Wiley, 1989

Tarlinder, Alexander. Developer Testing. Boston: Addison-Wesley, 2017

Tian, Jeff. Software Quality Engineering. Hoboken. NJ: Wiley Interscience, 2005

Tillman, George. Project Management Scholia. n.p. Stockbridge Press, 2019

von Halle, Barbara. Business Rules Applied. New York: Wiley, 2002

Walton, Mary. The Deming Management Method. New York: The Putnam Publishing Group1986, 1986

Weaver, Audry M. Using the Structured Techniques. Englewood Cliffs, NJ: Yourdon Press, 1987

Weinberg, Gerald M. Quality Software Management. Volume 1: Systems Thinking. New York: Dorset House, 1992

Whitten, Neal. Managing Software Development Projects, 2nd Edition. New York: John Wiley & Sons, 1995

Wiegers, Karl & Joy Beatty. Software Requirements 3rd ed. Atlanta: Dorset House, 2005

Winograd, Terry & Fernando Flores. Understanding Computers and Cognition. Reading, MA: Addison-Wesley, 1987

Withall, Stephen. Software Requirement Patterns. Redmond, WA: Microsoft Press, 2007

Wood, Jane & Denise Silver. Joint Application Development. New York: Wiley, 1995

Index

Acceptance test

Accounting

Activities

Activity Cycle of DPAC

Act Phase

Process Detail Cycle

records

requirements

Unit Development Cycle

Adaptive maintenance

Administrative assistant selection

Agent

Agile

Agile DBA

Application design requirements

Architect

Architectural requirements

Architecture documentation

Assemble documentation

“As-you-go” documentation

Attributes

Audit and regulatory requirements

Audits

Automated testing

Automation

Automation tools

Badge/bar code

Biometrics

Boehm’s risk management-driven spiral model

Boehm’s top ten list

Brooks’ law

B2C applications

Bugs

Bureaucratic impediments

Business analysis

Business analyst

Business Rule and Requirements Review

Business rules

business definitions

data constraints

data integrity

decision tables

dependencies

drop-down values

inspection checklist

look up values

operational requirements

perspective

process flow

requirements

review

review panel

rule-based constraints

UI testing

Business to Customer (B2C)

Cache and memory management

Capacity Maturity Model Integration (CMMI)

Capture Hardcopy

Champion project

Change Advisory Board (CAB)

Change Control Board (CCB)

Change Reports (CRpts)

Change request (CR)

Claim level 1

Claim level 2

Claims Department Information Image Processing Subs-System

Claims management

Claims processing system

Clean code

Client and Policy information

Client profile

Code-check software

Code inspections

Code version control

Code Walk

Coding Stage

Commercial off-the-shelf (COTS)

Commitment

Communication/collaboration tools

Compatibility

Component Development Cycle

Computer security

Configuration Inventory Database (CMDB)

Configuration Management (CM)

CMDB

item naming conventions

plan

roles and responsibilities

Configuration Management Database (CMDB)

components

representational view

requirement record

test case record

tools

Configuration Manager (CM)

Consensus

Construction Stage

business rules

cycles of activity

Process Detail Cycle

SeeProcess Detail Cycle

staffing

Unit Development Cycle

SeeUnit Development Cycle

Contact database

Contact record

Context Diagram

Continuous Delivery (CD)

Continuous Integration (CI)

Contracting Officer’s Technical Representative (COTR)

Conversion plan

Corrective maintenance

Cosmetic standards

Cost-benefit analysis

Costs

proportional distribution

software support

of support

Cryptic numbers

Culture clash

Cyberattack

Database administration (DBA)

Agile

librarian

Database Design Document

Database version management

Data constraints

Data dictionary

Data flow diagram (DFD)

construction stage

context diagram

data dictionary

elaboration Stage

goal

guideline

legal and illegal combinations

principles

process

Process Detail Cycle

superior process performance

symbols

Data integrity

Data Modeler

Data Processing

Data-related quality engineering

Datastores

Decision tables

Decomposition

Dependencies

Deployment Cycle

development

rectification of errors

repair or correction

UAT

Design approval

Designers

Designer tool

Design requirements

Design review

Development model

Table of Contents for Back Matter

Create new playlist

Sign In

Sign Up

Table of Contents for
Back Matter