ICT Standards and Guidelines
Segment 202
Software Applications
Main Document
(Version 2.0)
Disclaimer
The Office of the Minister of State for Administrative Reform (OMSAR) provides the contents of the ICT Standards and Guidelines documents, including any component or part thereof, submission, segment, form or specification, on an 'as-is' basis without additional representation or warranty, either expressed or implied. OMSAR does not accept responsibility and will not be liable for any use or misuse, decision, modification, conduct, procurement or any other activity of any nature whatsoever undertaken by any individual, party or entity in relation to or in reliance upon the ICT Standards and Guidelines or any part thereof. Use of or reliance upon the ICT Standards and Guidelines is, will be and will remain the responsibility of the using or relying individual, party or entity.
The ICT Standards and Guidelines are works in progress and are constantly being updated. The documentation should be revisited regularly to have access to the most recent versions.
The last date of update for this document was June 2003.
Table of Contents - Software Applications
Chapter 1 - Introducing Software Applications 1
1.0 Executive Summary for Software Applications 2
2.0 Background for Software Applications 4
2.1 The Scope of Software Applications 4
2.1.1 Acquired or Developed Software? 4
2.1.2 Examples of Software Applications 5
2.2 The Benefits of Standardization 6
2.3 Policies to Follow for Software Applications 7
2.4 Risks Resulting from the Standardization Activities 7
2.5 Related Documents 8
2.6 How to Use This Document? 8
2.7 Related Terms and Acronyms 10
2.8 Related Segments and Cross References 10
2.9 Related International Standards 11
2.9.1 CMM 11
2.9.2 ISO 12
2.9.3 TickIT 12
2.10 All Segments in the ICT Standards and Guidelines 13
3.0 Analysis and Design 14
3.1 Design Life Cycles 14
3.2 Analysis of Requirements 16
3.3 Functional Design and the Functional Specifications Document (FSD) 16
3.4 Technical Design and the Technical Specifications Document (TSD) 17
3.5 Good Practice: Using the Spiral Development Model 17
3.6 Good Practice: Mapping the Three Processes to a Software Project Plan 18
3.7 Good Practice: Focus on Improvement of Business Procedure 19
3.8 Good Practice: Model Visually 20
3.8.1 Using the Unified Modeling Language (UML) 20
3.8.2 Business Modeling Technical Paper 21
3.9 Good Practice: Manage the Software Configuration 21
3.10 Good Practice: Develop Iteratively and Incrementally 21
3.11 Good Practice: Use Component Architecture 22
3.12 Good Practice: Develop Prototypes 23
3.12.1 Some Characteristics of Prototypes 23
3.12.2 When to Use Prototypes? 23
4.0 Develop or Acquire the Software Application? 24
4.1 Developed Software: Advantages and Disadvantages 24
4.2 Acquired Software: Advantages and Disadvantages 24
4.3 Procedure for Selecting Whether to Develop or Acquire 25
4.3.1 Step 1: Decide on the Mandatory Conditions 26
4.3.2 Step 2: Evaluate the Criteria for Acquiring or Developing 27
4.3.3 Step 3: Evaluate the Commercial Software 27
Chapter 2 - Phase 1: Initiating a Software Project 1
1.0 Initiating a Software Application Project 2
2.0 Process 1: Developing the Project Definition Document 3
2.1 The Project Definition as a Prototype of the Project Plan 3
2.2 The Main Deliverable of the Initiation Phase 3
2.3 Milestone 1: Approve the Project Definition Document 3
Chapter 3 - Phase 2: Project Planning Processes (Analysis and Design) 1
1.0 How to Plan a Software Project? 2
1.1 The Main Deliverable of the Planning Phase 2
1.2 The Objectives of the Planning Phase 2
1.3 How to Develop a Project Plan? 2
1.4 The Question of Development or Acquisition in Planning 4
1.5 Milestone 2: Approve the Project Plan 6
2.0 Process 2 - Modeling the Current (AS IS) System or Process 7
2.1 Objectives and Scope of Modeling the AS IS System or Process 7
2.2 Are There Situations Where Such Modeling is not Required? 7
2.3 The Inputs to this Activity 7
2.4 Roles and Responsibilities 8
2.5 Identify Tools for Modeling the Current System 8
2.6 Developing the AS IS or the Current System Model 8
2.7 Completion and Approval of the Current System Model 8
3.0 Process 3 - Analysis of Requirements 9
3.1 Objectives and Scope of the Analysis of Requirements 9
3.2 Introducing Analysis of Requirements 9
3.2.1 The Purpose and Use of Analysis of Requirements 9
3.2.2 Classification of Requirements 10
3.2.3 Characteristics of Requirements 12
3.2.4 Risks for Analysis of Requirements 13
3.3 Pre-Requisites for the Analysis of Requirements 13
3.4 Step 1: Identify the Analysis Team 14
3.5 Step 2: Identify Requirements using the Requirements Form 14
3.6 Step 3: Prioritize Requirements 15
3.7 Step 4: Specify Requirements 16
3.8 Step 5: Verify Requirements 16
3.9 Step 6: Baseline Requirements 16
3.10 The Content of the Requirements Definition Document 17
3.11 Defining the Analysis of Requirements with the UML? 17
3.12 Good Practices and Recommendations 17
3.13 Completion and Approval of the Requirements Analysis 18
4.0 Process 4 - Functional Design and Functional Specifications 19
4.1 Objectives and Scope of the Functional Design 19
4.2 Selecting the Functional Design Methodology 20
4.3 Quality Assurance in Functional Design 20
4.3.1 Qualify the Design Process or Method 20
4.3.2 Verify That the Functional Design Process is Being Used 21
4.3.3 Qualify the Functional Specifications Document 21
4.4 The Functional Design Process 22
4.5 Step 1: Identify the Design Team 22
4.6 Step 2: Develop the Design 23
4.7 Step 3: Model the Design 23
4.8 Step 4: Qualify the Functional Specifications Document (FSD) 23
4.9 Step 5: Approve the Functional Specifications Document 25
5.0 Process 5 - Evaluation of Commercial Off the Shelf Software 26
6.0 Process 6 - Technical Design and Technical Specs 27
6.1 Objectives and Scope of the Technical Design 27
6.2 Selecting the Technical Design Methodology 28
6.3 Quality Management in Technical Design 29
6.3.1 Qualify the Design Process or Method 29
6.3.2 Verify That the Technical Design Process is Being Used 29
6.3.3 Qualify the Technical Specifications Document 29
6.4 The Technical Design Process 30
6.5 Step 1: Identify the Design Team 30
6.6 Step 2: Develop the Design 31
6.7 Step 3: Model the Design 31
6.8 Step 4: Qualify the Technical Specifications Document (TSD) 31
6.9 Step 5: Approve the Technical Specifications Document 32
7.0 Process 7 - Preparing the Master Schedule 34
7.1 Preparing the Work Breakdown Structure 34
7.2 Preparing the Master Schedule 35
7.3 Trade Offs 36
7.4 Good Practices While Estimating Durations 37
8.0 Process 8 - Preparing the Budget Plan 38
8.1 Good Practices While Estimating Costs and Budgeting 38
9.0 Process 9 - Finalizing the Risk Management Plan 39
10.0 Process 10 - Finalizing the Deployment Plans 40
11.0 Process 11 - Finalizing the Team Structure and Assignment 41
12.0 Process 12 - Planning Configuration Management 42
13.0 Process 13 - Planning Quality Management 43
14.0 Process 14 - Finalizing the Communications Plan 44
14.1 Typical Communications 44
Chapter 4 - Phase3-Software BuildingProcesses 1
1.0 Phase 3 - Building and Implementing the Software Application 2
1.1 What are the Main Deliverables of the Building Phase? 2
1.2 The Activities in the Building Phase 3
1.3 The Main Processes in the Building Phase 4
1.4 Milestone 3: Approve the Completed Product Scope 5
2.0 Process 15 - Monitoring and Tracking 6
2.1 Monitoring Schedules and Costs 6
2.2 Risk Monitoring 6
2.3 Configuration Management 6
2.4 Quality Assurance 6
3.0 Process 16 - Software Development 7
3.1 Pre-Requisites for Development 7
3.2 Good Practice: Programming Standards 7
3.3 Good Practice: Development Activities Tracking and Control 9
3.4 Good Practice: Time Sheet Monitoring 9
4.0 Process 17 - Evaluation of Off the Shelf Software 11
4.1 Using the Evaluation and Selection Framework 11
4.2 Using the Functional Design Document 11
5.0 Process 18 - Parameterization of Off the Shelf Software 12
6.0 Process 19 - Software Testing 13
6.1 What are the Objectives of Testing? 13
6.2 Quality Assurance and Testing 13
6.3 SOP for Testing 14
6.4 Good Practices: General 15
6.5 Good Practice: Locating Testers 16
6.6 Good Practices: Test Designs 16
6.6.1 Construction Testing 16
6.6.2 System Testing 17
6.6.3 Special Types of Tests 18
6.7 Good Practices: Test Data 18
Chapter 5 - Phase 4 - Transition Processes 1
1.0 Transiting the Application to Completion 2
1.1 The Main Deliverables of the Transition Phase 2
1.2 The Main Processes and Activities in the Transition Phase 2
1.3 Milestone 4: Approve the Completed Project Scope 3
2.0 Process 20 - Training 1
3.0 Process 21 - Implementation 2
4.0 Process 22 - System Documentation 3
5.0 Processes 23, 24 and 25 - Warranty, Maintenance and Support 4
Figures - Software Applications
Figure 1: Types of Software Applications 5
Figure 2: Processes in Software Development 9
Figure 3: Standards and Their Relationships 11
Figure 4: The Analysis and Design Flow 14
Figure 5: Inputs to the Design Processes 15
Figure 6: Requirements, Functional and Technical Design 15
Figure 7: Software Project Phases 18
Figure 8: Processes for Developed and Off the Shelf Software 19
Figure 9: Selection Criteria for Developing or Acquiring Software 25
Figure 10: Steps to Decide Whether to Develop or Acquire 26
Figure 11: Criteria for Deciding Whether to Develop or Acquire 27
Figure 12: Activities in the Phases of a Software Application 28
Figure 13: Converting the Project Definition into a Project Plan 4
Figure 14: Activities for Developing and for Acquiring Software 6
Figure 15: Using Requirements 9
Figure 16: Classification of Application Requirements 11
Figure 17: Converting Requirements to Functional Specifications 19
Figure 18: Functional Design Steps 22
Figure 19: Converting Functional to Technical Specifications 27
Figure 20: Steps in Technical Design 30
Figure 21: Developing the Master Schedule (PMI) 35
Figure 22: Activities in the Building Phase 3
Chapter 1 - Introducing Software Applications
1.0 Executive Summary for Software Applications
The objectives of this Segment are to develop Standards and Guidelines to be observed by vendors or by internal ICT Units in the Public Sector. The standards cover various aspects of handling of Software Applications.
The main objectives of this segment are to present Guidelines and Good Practices in the following areas:
· Software Project Management
· Software Development Models
· Software Engineering Processes
· Software Team Structures
· Business Modeling and its Uses in Software Applications
· Software Development and Quality Processes:
Configuration Management
Data Entry Standards
Programming Standards
Software Testing and QA
Communications
Documentation
· Software Development Supporting Tools
· Software Metrics and Performance Indicators
The approach taken in this segment is to cover the handling of Software Applications in its various modes: project management, development, acquisition, selection and evaluation. One of the key issues being discussed is the handling of software application development or acquisition as part of Software Project Management. This is a crucial aim of this segment.
The approach of this segment follows these general lines:
1. To present the approach as based on the Capability Maturity Model™ (CMM) of the Software Engineering Institute. (This is introduced in a separate document). This model defines the process areas needed to improve Software Engineering Processes. The maturity model charts a path through 5 levels. The lowest is practiced by organizations with ad hoc software engineering processes. As the maturity improves, such organizations go through different levels to reach Level 5. During this growth, Software Engineering Processes become repeatable, defined, managed and optimized.
2. To recommend that Ministries and Agencies aim at reaching Level 2 which stresses many processes directly related to software development project management.
3. To present a recommended 4 Phase Software Applications project that covers both acquisition and development of Software. The project would start from the initial strategic analysis of the organization and cycle through the various phases until a software application is fully built or acquired.
4. To introduce Software Development Models in a separate Technical Paper and to justify the choice of the Spiral Model as the recommended Model to use when acquiring or developing software. The Spiral Model will be incorporated in the recommended Project Management approach in this segment.
5. To present 20 processes starting from the Analysis of Requirements, Functional Design, Technical Design, Business Modeling, Development and going through to implementation and documentation. These processes integrate to form a complete software application project.
6. To relate to processes discussed in other segments such as Quality Management, Selecting and Evaluating Frameworks, Configuration and Risk Management.
The segment has several related technical papers that discuss current methodologies related to Business Modeling, Roles and Responsibilities, Software Metrics and Software Development Models.
2.0 Background for Software Applications
This section covers various issues that need to be known before the segment’s core sections.
2.1 The Scope of Software Applications
This segment will cover Software Applications that are either acquired off the shelf or developed. If developed, the segment will discuss issues related to internal development or one that is outsourced.
2.1.1 Acquired or Developed Software?
In this segment, two major types of software applications will be considered:
1. Developed Software:
· Tailor Made Software: this is software that is developed almost from scratch for a particular application
· Adapted Software: this is software that has already been developed but that will be modified to suit a particular application.
2. Commercial Off the Shelf or Acquired Software:
· Configurable Commercial Off the Shelf Software (COTS): this is software that is available off the shelf. However, its application scope is wide which would require a fair amount of configuration or parameterization. This often requires large implementation effort by either the software vendor or the internal development Unit. This type shall be referred to as Configurable COTS.
· Fixed Purpose Commercial Off the Shelf Software (COTS): this is software that is available on an AS IS basis. In most cases, this would cover office technology or other fixed purpose work such as computer aided design, etc. It can be acquired from the software vendor but generally, there would be no implementation effort. This type shall be referred to as Fixed Purpose COTS.