B.1
Reuse is now the standard approach for building many types of business system ComponentanalysisRequirementsmodificationSystem designwith reuseRequirementsspecificationDevelopmentand integrationSystemvalidation 2.3.5 Types of software component
1. Web services that are developed according to service standards and which are available for
remote invocation.
2. Collections of objects that are developed as a package to be integrated with a component
framework such as .NET or J2EE.
3. Stand-alone software systems (COTS) that are configured for use in a particular environment.
2.4 Process activities
2.4.1 Software specification
The process of establishing what services are required and the constraints on the system’s operation and development.
A.1 Requirements engineering process
B.1 B.2 B.3 B.4 Feasibility study
Requirements elicitation and analysis Requirements specification Requirements validation Requirementselicitation andanalysisIs it technically and financially feasible to build the system? What do the system stakeholders require or expect from the system? Defining the requirements in detail Checking the validity of the requirements FeasibilitystudyRequirementsspecificationRequirementsvalidationFeasibilityreportSystemmodelsUser and systemrequirementsRequirementsdocument Page 13 of 91
2.4.2 Software design and implementation
The process of converting the system specification into an executable system.
A.1 Software design
Design a software structure that realises the specification;
A.2 Implementation
Translate this structure into an executable program;
The activities of design and implementation are closely related and may be inter-leaved.
A.3 A general model of the design process
A.4 Design activities
B.1
Architectural design,
where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed.
B.2 B.3
Interface design, Component design,
where you define the interfaces between system components. where you take each system component and design how it will operate.
Page 14 of 91
B.4 Database design,
where you design the system data structures and how these are to be represented in a database.
2.4.3 Software validation
1. Verification and validation (V & V) is intended to show that a system conforms to its
specification and meets the requirements of the system customer. 2. Involves checking and review processes and system testing.
3. System testing involves executing the system with test cases that are derived from the
specification of the real data to be processed by the system. 4. Testing is the most commonly used V & V activity.
A.1 Testing stages
B.1
Development or component testing
Individual components are tested independently;
Components may be functions or objects or coherent groupings of these entities.
B.2 B.3
System testing Acceptance testing
Testing of the system as a whole. Testing of emergent properties is particularly important. Testing with customer data to check that the system meets the customer’s needs.
2.4.4 Software evolution
? Software is inherently flexible and can change.
? As requirements change through changing business circumstances, the software that supports
the business must also evolve and change.
? Although there has been a demarcation between development and evolution (maintenance)
this is increasingly irrelevant as fewer and fewer systems are completely new.
2.5 Coping with change
2.5.1 Introduction
A.1 Change is inevitable in all large software projects.
1. Business changes lead to new and changed system requirements
2. New technologies open up new possibilities for improving implementations 3. Changing platforms require application changes
A.2 Change leads to rework so the costs of change include both rework (e.g.
re-analysing requirements) as well as the costs of implementing new functionality
A.3 Reducing the costs of rework
B.1
Change avoidance
where the software process includes activities that can anticipate possible changes before
Page 15 of 91
significant rework is required.
For example, a prototype system may be developed to show some key features of the system to customers.
B.2 Change tolerance
where the process is designed so that changes can be accommodated at relatively low cost.
This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have be altered to incorporate the change.
2.5.2 Software prototyping A.1 Introduction
B.1
A prototype is an initial version of a system used to demonstrate concepts and try out design options. B.2 A prototype can be used in:
1. The requirements engineering process to help with requirements elicitation and validation; 2. In design processes to explore options and develop a UI design; 3. In the testing process to run back-to-back tests.
A.2 Benefits of prototyping
1. 2. 3. 4. 5.
Improved system usability.
A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort.
A.3 The process of prototype development
A.4 Prototype development
B.1 Introduction
C.1 May be based on rapid prototyping languages or tools C.2 May involve leaving out functionality
1. Prototype should focus on areas of the product that are not well-understood; 2. Error checking and recovery may not be included in the prototype;
Page 16 of 91