Chp. 21: Change Management

Change management
– Stand. methodology for performing & recording changes during software deve. & system operations.
– Essential practice for managing software during its lifecycle, from deve., through deployment, & operation, until it’s taken out of service.
Change management is related to…
managing & controlling software deve., maintenance, operation, & risk.
Change management used in all phases of software’s Deve. Life Cycle:
– Deve.
– Testing
– Quality assurance (QA)
– Production
– Risk as related to implementation strategies
Segregation (seperation) of Duties – Best Practices:
– B/w deve., testing, quality assurance, & production should be documented, monitored, & enforced (req.).
– Prg. developers/testers should conduct activities on “test” data only (Dummy data).
– End users/sys. operators shouldn’t have direct access to prg. source code (User feed-back).
– Functions of creating, installing, & admin. software prg. should be assigned to diff. individuals (Individ. expertise e.g., web developers).
– All accesses & privileges to sys., software, or data should be granted based on principle of least privilege (need to know basis).
– Formal software change management policies & procedures should be enforced throughout enterprise.
– Managers at all levels should review existing/planned processes & sys. ensuring proper segregation of duties.
Configuration management
Referred from Change management’s roots’ in system engineering
Elements/Phases of Change management:
– Config. identification
– Config. control
– Config. status accounting
– Config. auditing
Configuration identification
– Process of identifying which assets need to be managed & controlled.
– Depending on size & complexity of software proj., appropriate set of data & software (or other assets) must be identified & properly managed.
– Identified assets = config. items/comp. software config. items
Configuration control
– Process of controlling changes to baselined items.
– Ensures only approved changes to a baseline are allowed to be implemented.
– Provides managers valuable insight if a sys. being changed, & being observed, them & others concerned are better informed.
– Ensures proper use of assets & avoids unnecessary downtime due to installions of unapproved changes.
Configuration status accounting
– Procedures for tracking & maintaining data relative to each config. item in baseline.
– Closely related to Config. control.
– Involves gathering & maintaining info. relative to each config. item.
Configuration audit
– Process of verifying that config. items built & maintained according to req., stand., or contractual agreements.
– Ensure policies & procedures being followed.
– Ensure all config. items (inc. hard/software) being properly maintained.
– Ensure existing doc. accurately reflects status of systems in operation.
Configuration audit forms:
– Functional
– Physical
Functional configuration audit
– Verifies config. item performs as defined by documentation of sys. req.
Physical configuration audit
– Confirms all config. items to be inc. in a release, install, change, or upgrade are actually inc., & no add. items (no more, no less).
Implementing change management
– Req. structure & discipline = effective.
– Scalable func. from small to enterprise-level (med. to large) proj.
Adapted to small org. by:
– Having deve. work only on their workstations & never on prod. sys.
– Having sys. admin. serve in build master func.
Build master
– Ind. person responsible for compiling & incorp. changed software into executable img.
Change management workflow
1. Deve. checks source code from code-control tool archive to deve. sys.
2. Deve. modifies code & conducts unit testing.
3. Deve. checks modified code into code-control tool archive.
4. Deve. notifies build master that changes are ready for new build & testing/QA.
5. Build master creates build w/modified code & complies code.
6. Build master notifies sys. admin. that executable img.’s ready for testing/QA.
7. Sys. admin. moves executables to test/QA sys.
8. QA tests new executables.
9. If tests passed, test/QA notifies manager, else process starts again.
10. Upon manager approval, sys. admin. moves executable to production sys.
Change control board (CCB)
– Oversee change management process.
– Convenes on reg. basis (weekly/monthly), emergency, or as-needed.
CCB’s membership consists of:
– Deve. proj. managers
– Net. admin.
– Sys. admin.
– Test/QA managers
– Info. security manager
– Operations center manager
– Help desk manager
Implement new sys. –> Remove old sys.
High risk
Implement concurrent systems old & new
Little risk
Gradual implementation
Medium risk
Pilot proj.
Low risk