Configuration Management Backup/Recovery Project Review.

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

Software Quality Assurance Plan
Copyright 2010, The World Bank Group. All Rights Reserved. Statistical Project Monitoring Section B 1.
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
NEES Project Management Workshop June 16 June 18 1 Segment 2.
Software Configuration Management Speaker: Jerry Gao Ph.D. San Jose State University URL:
Software Configuration Management
Configuration Management
Configuration Management
Chapter 27 Change Management
Software Configuration Management
CSSE 375 Software Construction and Evolution: Configuration Management
Configuration Management Avoiding Costly Confusion mostly stolen from Chapter 27 of Pressman.
Michael Solomon Tugboat Software Managing the Software Development Process.
1 Configuration Management 101 ITS Professional Capacity Building Program T3 Webinar February 21, 2008.
Effective Methods for Software and Systems Integration
Software Configuration Management (SCM)
INFO 637Lecture #31 Software Engineering Process II Launching & Strategy INFO 637 Glenn Booker.
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
Information Systems Security Computer System Life Cycle Security.
Seattle Area Software Quality Assurance Group Release and Configuration Management, The Acceleration of Change and Its Contribution To Software Quality.
Software Configuration Management
Software Configuration Management (SCM)
© Grant Thornton | | | | | Guidance on Monitoring Internal Control Systems COSO Monitoring Project Update FEI - CFIT Meeting September 25, 2008.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Gathering Network Requirements Designing and Supporting Computer Networks – Chapter.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Product Documentation Chapter 5. Required Medical Device Documentation  Business proposal  Product specification  Design specification  Software.
Week 2 Seminar: Project Scope Management
SacProNet An Overview of Project Management Techniques.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
CMM Level 2: Repeatable Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Software Quality Assurance
Georgia Institute of Technology CS 4320 Fall 2003.
OHT 18.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Introduction The foundations of high quality Foundation 1: software.
© Mahindra Satyam 2009 Configuration Management QMS Training.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Gathering Network Requirements Designing and Supporting Computer Networks – Chapter.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
Software Configuration Management (SCM). Product Developer Disciplines One view of the world is that there are three types of activities are required.
Quick Recap Monitoring and Controlling. Lesson 11: Monitoring and Controlling Project Work Topic 11A: Identify the Monitor and Control Project Work Process.
Software Maintenance Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
Module 5 Session 5.2 Visual 1 Module 5 Refining Objectives, Scope, and Other Project Parameters Session 5.2 Reviewing the PAR and refining key project.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
Software Configuration Management n Art of coordinating SW development to minimize confusion n Software quality assurance (umbrella) activity n Set of.
Software Configuration Management SEII-Lecture 21
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Software Engineering Lecture 9: Configuration Management.
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
Disaster Recovery Planning (DRP) DRP: The definition of business processes, their infrastructure supports and tolerances to interruptions, and formulation.
Configuration Control (Aliases: change control, change management )
OHT 18.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software configuration, software configuration items and software configuration.
Configuration Management
Software Configuration Management
Software Configuration Management
Software Project Configuration Management
Software Configuration Management (SCM)
Software Configuration Management
Configuration Management
Software Configuration Management
Chapter 27 Change Management
Lecture 3 Change Management
Software Configuration Management
Chapter 27 Change Management
Chapter 27 Change Management
Chapter 27 Change Management
Chapter # 6 Software Configuration Management
Effective Project Management: Traditional, Agile, Extreme
Chapter 27 Change Management
MANUFACTURING DISASTER RECOVERY PLAN
Presentation transcript:

Configuration Management Backup/Recovery Project Review

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

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

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

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

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

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

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

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."

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.

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

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"

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)

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

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