Configuration Management Backup/Recovery Project Review

1. Configuration ManagementBackup/RecoveryProject Review

2. Software changes Software will be changed because of required adaptations, perfections or corrections. Causes of change: • New business • New customer needs • Reorganizations • Budgetary constraints • Scheduling constraints • Government regulations

3. Software Configuration Management (SCM) The control of changes to the components of a software system so they: • fit together in working order • are never out of sync with each other

4. SCM Activities • Identify selected software work products • Control changes to identified software work products • Inform affected groups and individuals of the status and content of software baselines and proposed changes

5. Configuration Item A configuration item is a “thing” that represents an internal and/or external project deliverable: requirements, design documentation, test scripts, test files, etc.

7. SCM Basic Requirements • Identification – each software part is labeled so it can be identified (version and/or revision numbers) • Control – proposed changes need approval prior to incorporation • Auditing – to determine if requested changes have indeed been implemented • Status Accounting – provides a history of what has happened and when (get the amount of effort required throughout the lifecycle)

8. Disaster Recovery "The ability to respond to an interruption in services by implementing a disaster recovery plan to restore an organization’s critical business functions". Disaster Recovery Journal, Glossary

9. Disaster Recovery Plan "The document that defines the resources, actions, tasks and data required to manage the business recovery process in the event of a business interruption.” Disaster Recovery Journal, Glossary

10. Data Backup/Recovery Plan "Data backup is simply the backing up of data fields so that company personnel can go to the disaster backup site, restore files and application software, and be able to continue business as though nothing happened."

11. Don’t lose Project data Perform an impact analysis to identify critical data or applications. Schedule data backups that will be sufficient for restoring those processes.

12. Project Review • Don't repeat current mistakes in the next project. • Analyze the process used in the current project • Determine what worked (and what didn’t) • Develop a list of lessons learned • Project reviews can be done at the end of a project or after major milestones

13. Review the Process Not the People • First, prepare specific questions about the project and circulate them to team members. • Give team members time to think about them and prepare their responses individually. • Next, hold a meeting and discuss the team's responses to the questions. • Result of this discussion is often a list of "Lessons Learned"

14. Project Review Analysis Questionnaire Name of Project ______________ Short Project Description__________ Roles played in the project _________ Environmental characteristics (requirements volatility, product complexity, software tools, risk analysis, etc)

15. Project/Process Questions • Identify the key things that were done right. • Identify the key things that were done wrong. • How would you do things differently? • Describe one thing you could have done to improve the quality of the product. • Did you learn anything from this project? If you did, what was it? • Are you proud of our finished products? If yes, what's good? If no, what's wrong?

16. More Questions • What was the single most frustrating part of our project? How would you do things differently next time? • What was the most satisfying part of the project? • What would you have changed about the project? • Could the meetings be more effective? How? • Which method or process worked well? • Which method or process was frustrating to use? • Were you proud of our deliverables? If not, how could we have improved these? • How could we have improved our work process for creating deliverables?