From MIKE2 Methodology
Activity: Software Development Lifecycle Preparation
Objective
The Software Development Lifecycle Preparation activity involves the implementation of the baseline infrastructure to support the new information environment. It is a time consuming activity that needs to be completed by the time development and testing begins. This activity will be revisited during the Roadmap phase.
Major Deliverables
- Software and Hardware Procurement
- Software Development Environment Designed and Deployed
- Test Strategy
Tasks
Define Team Workstation Environment
Objective:
During this task, workstations are setup for each desired user type. It’s important during this task to specify all user hardware requirements including any workgroup software, mail systems, internet access or software development applications will be needed. Developing a well-formulated team workstation environment is critical for enabling efficient work practices.
Input:
- SDLC tool requirements and selected products
- Tools requirements listings
Output:
Procure Hardware and Software
Objective:
The purpose of this task is to procure the components of the technical architecture that is eventually going to represent the production environment. This may include hardware and software to support development, multiple testing environments (defined by the Test Strategy) and production. Keep in mind that procurement times vary greatly among vendors and are usually much longer for hardware than software. The client’s own procurement process may also cause unusual delays.
Input:
Output:
Define SDLC Procedures
Objective:
The purpose of this task is to ensure that there are uniform development & testing procedures to follow. With most clients there are standards and procedures that already exist; new procedures will have to be developed when existing ones are inadequate.
It is important that the information management environment have documented development & testing procedures. This environment has many different types of technologies that need to be integrated, so it is important to have such procedures well-established. These procedures should adhere to the standards developed in other tasks and should concentrate on when to use certain technologies and when and how software artifacts should move through the development process and into production.
Input:
Output:
Define Testing Strategy
Objective:
The purpose of this document is to describe the overall testing strategy and framework that will be used for the implementation. This document also forms a framework that outlines the testing scope, approach, roles and responsibilities, and test phases. Along with the overall testing plan, it also outlines the requirements and provides an integrated view of the testing activities for this project. The defect management process and resolution strategy are also defined in this document.
In summary, the purpose of this document is to describe:
- What will be tested
- How testing will be performed.
- An overview of what resources will be needed, and when
This is presented at a very high level. It may also propose some initial recommendations around the development of a Test Centre of Excellence. This document may be revised during the Roadmap.
Input:
- Strategic Requirements for Applications, Infrastructure and Information
- Strategic Non-Functional Requirements for Applications, Infrastructure and Information
- Logical Architecture for Applications, Infrastructure and Information
- Initial Blueprint Timelines and Programme Plan
- Tools and Technologies Selected
Output:
Define Development and Test Environments Technical Architecture
Objective:
The purpose of this task is to produce a technical infrastructure design based on the technologies selected in the previous activity. As this is part of the Blueprint, this is still a fairly high level deliverable – effectively an architecture diagram with a high level supporting explanation of the components. This task also defines the mechanism for deploying technologies into the development environment.
Input:
Output:
Install and Configure Development and Testing Baseline Infrastructure
Objective:
The purpose of this task is to physically implement the hardware and software for the information management development and testing environment. The nature of this activity in this task often takes two main forms depending on the client’s infrastructure management arrangements – they being either in-house or outsourced.
Installing hardware and software with an in-house hosted infrastructure requires receiving and installing the hardware with assistance from the hardware vendors as well as in-house expertise. The installation requires facilities planning (space, HVAC, electrical) and operations planning (re-start, re-fresh, diagnostics).
Outsourced infrastructure arrangements often shield the project teams from much of this complexity (ie HVAC and electrical assessments) but other network considerations (connectivity, communication protocols, file-sharing and security) must still be considered. The software implementation will also require vendor assistance. Training classes and on-site consulting assistance will most likely be required to gain an initial understanding of the tools. More in-depth training may be necessary depending on in-house experience and learning ability.
Following is a list of tasks that need to be performed:
- Arrange for Physical Facilities
- Install Hardware/Network
- Install development Tools
- Finalise Development Procedures
- Prepare Development Staff
It is essential to begin the infrastructure management planning activity as soon as possible due to long lead times. At least some level of backups must be in place before development begins. Furthermore, make sure the new infrastructure has connectivity to all the necessary source systems and the developers have mail, internet access and printing capability.
Input:
Output:
Evaluate New Baseline Infrastructure
Objective:
The purpose of this task is to test and evaluate the baseline infrastructure to ensure both its technical feasibility, but also at some level test its ability to support the strategic business requirements. This opportunity should also be taken to do some level of testing on the environment for specific areas of risk or unknowns. Some specific test cases will need to formulated at this stage often done as part of a vendor checklist.
Input:
Output:
Core Supporting Assets
Yellow Flags
- Major procurement delays for any aspect of the technology infrastructure
- Development team forced to use sub-standard equipment
Key Resource Requirements
BlogMarks
del.icio.us
digg
Furl
Simpy
smarking
