The Software Development Life Cycle
2.8 THE PRELIMINARY CONSTRUCTION STAGE
evaluated. Business users and developers have worked together throughout the entire design process. This is the fi nal, formal review before taking the design to top management for approval.
2.7.4 Select the Best Design
Armed with the evaluation data, business owner management and executives can se- lect the best design. The management group can include project sponsors in the form of the fi rm’s executive committee and MIS steering committee, information systems managers, and user area managers working with members of the project team who provide technical expertise. With the design selected and approved, the developers can turn their attention to preliminary construction.
Across this life cycle process, the development of custom software evolves through four environments, illustrated in Table 2.4. The software for each module is prepared and tested in the development sandbox environment. The software for the integrated system is assembled and tested in the development integration environ- ment. User acceptance testing occurs in the production staging environment. The approved system goes into operational use in the production environment. The fl ow of purchased or packaged software through the environments usually starts with the production staging environment because there is no source code for the fi rm’s pro- grammers to develop or integrate.
A development sandbox consists of the required software development tools and preliminary test data that developers use in “building sandcastles.’’ This is a term used by developers to denote trying out creative designs without constraints imposed by a rigid production environment. Locally duplicated sandboxes, called variant sandboxes, enable team members to simultaneously work on different re- leases of the same project. In this environment, developers use their own desktop or laptop computers and engage in coding, prototyping, individual component and
Development sandbox environment
Development integration environment
Production staging environment
Production environment Hardware Individual
developers’
workstations or designated individual server areas
Shared server space
Staging server(s)—
maybe externally hosted
Production server(s)—maybe externally hosted
Access Developers access their own hardware
Project team members, project managers
Review team, project managers
Public—might include worldwide use or limited use to enterprise intranet or other security boundaries Activities Coding
Prototyping Individual
component and page development Unit testing
Component and page integration Integration
testing Integration
problem resolution
System testing User acceptance
testing
Public operation Table 2.4 Software development environments
2.8 The Preliminary Construction Stage 51
page development, and unit testing. The important ingredients of the development environment include
copies of the latest software fi les by version number prepared by the module team,
short test data fi les,
copies of all system documentation, and
a change log that identifi es the version, author, and date for each software module revision.
•
•
•
•
Create new software files (Development sandbox—
individual)
1
Test current team version (Development
sandbox—
individual)
2
Revise individual files (Development sandbox—
individual)
3
Test integrated system (Production
staging environment)
4
Development integration environment
Production environment Individual software files
Preliminary team version
Tested software files
Tested team files
Tested integrated system files Individual
software files
Figure 2.12 Software flow to the production environment
Figure 2.12 shows how the software flows from the development environ- ments to the production environment. As developers complete copies of their software (Step 1), it is loaded into the development integration environment where it is made available to the members of all module teams. Each mem- ber can load the software from the development integration environment into their own sandboxes so that they can test their software to ensure that it works with the team software (Steps 2 and 3). The developers revise their software as needed and copy it back to the development integration environment (Step 3). The integrated system software is tested before entering the production environment (Step 4).
2.8.1.1 Test the Components of Each Module
Testing usually brings to mind software testing fi rst, which is certainly important.
But, attention should also be given to testing the other system components like the hardware, the data, and the personnel.
Unit tests: The tests that are conducted on the module software are called unit tests or module tests.
Data tests: Creation of the data component is so important that teams often designate it as a separate phase. Planning for the database or warehouse data repository to be used by the system must begin early in the project, perhaps as early as the Preliminary investigation stage. In the Preliminary construc- tion stage, data testing takes the form of building subsets of the database or warehouse repository and confi rming that the data structures and contents perform as anticipated by the system design independent of the software that must maintain it.
Hardware tests: When the system module utilizes new hardware, tests should be conducted to ensure that the hardware operations conform to the man- ufacturer’s promises and the module’s operational requirements (processor speed, screen resolution, data storage capacity, memory capacity for multiple concurrent tasks, and so on).
Personnel tests: Testing the personnel component is intended to determine whether the personnel already have suffi cient skills to use the new system.
The new system may require more detailed business knowledge than the old system. How does the business manager measure his or her staff’s readiness?
What training is available to close any skill gaps before the system “goes live?”
2.8.2 Demonstrate the New System Modules to Users and Project Sponsors
As the software modules successfully pass the tests, they are demonstrated to users and project sponsors. There are three possible outcomes of these demonstrations.
•
•
•
•
2.8 The Preliminary Construction Stage 53
If signifi cant changes are considered to be necessary, an on-the-spot feasibil- ity study can be conducted to determine whether to scrap the project or repeat the analysis, design, and Preliminary construction stages.
If only minimal changes are identifi ed, the project reverts back to the analysis stage and the changes are incorporated in the design.
When the users and project sponsors accept the module as demonstrated, the next step is the Final construction stage.