CEN 4021 Software Engineering II

Slides:



Advertisements
Similar presentations
PROJECT RISK MANAGEMENT
Advertisements

The Rational Decision-Making Process
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
By Saurabh Sardesai October 2014.
Managing Project Risk.
Project Risk Management Risk Mitigation. Risk Management  The prime objective of risk management is to minimize the impact and probability of the occurrence.
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Change Control.
S/W Project Management
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Release Management.
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Software Project Planning.
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Software Project Planning.
1. 2 IMPORTANCE OF MANAGEMENT Some organizations have begun to ask their contractors to provide only project managers who have been certified as professionals.
CEN st Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi What.
Recap from last week Understand organizations, including the four frames, organizational structures. Explain why stakeholder management and top management.
CEN rd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Phases of Software.
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Software Project Planning.
1 © The Delos Partnership 2004 Project Management Organisation and Structure.
Chapter 7: A Summary of Tools Focus: This chapter outlines all the customer-driven project management tools and techniques and provides recommendations.
Project Life Cycle – Project Initiation © Ed Green Penn State University All Rights Reserved.
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Software Project.
Copyright 2008  Project management process groups progress from initiating activities to planning activities, executing activities, monitoring and controlling.
 System Development Life Cycle System Development Life Cycle  SDLC Phases SDLC Phases Phase 1: Preliminary Investigation Phase 2: Feasibility Study.
CEN st Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Monitoring (POMA)
SOFTWARE PROJECT MANAGEMENT
Chapter 6: THE EIGHT STEP PROCESS FOCUS: This chapter provides a description of the application of customer-driven project management.
Working in Partnership
Introduction to Project Management Chapter 9 Managing Project Risk
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Company LOGO. Company LOGO PE, PMP, PgMP, PME, MCT, PRINCE2 Practitioner.
The Project Management Process Groups
Risk Mitigation Submitted By, S. Anitha Devi, M.E-CSE.
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Monitoring (POMA)
Project Management Finals Lesson 1 - Principles - Techniques - Tools.
Ch. 13 Project Management “Process” Why do we need project management? Why can’t we just follow one of the software development process and be left alone?
Requirement Elicitation Nisa’ul Hafidhoh Teknik Informatika
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
From Idea to Business Case
Project Management PTM721S
Project Management Jukka A. Miettinen September 4, 2006
MGT 461 Lecture #27 Project Execution and Control
COMM02 Project Monitoring and Control Unit 8
Workplace Projects.
8.4 Management of Postdelivery Maintenance
BANKING INFORMATION SYSTEMS
Improving the Defect Life Cycle Management Process
Project Management Processes
Assistant Professor of Computer Science Washington State University
Software Project Management
Software Engineering Fall 2005
Project Integration Management
ITS Strategic Planning Guidelines
Project Integration Management
The Systems Engineering Context
Project management.
Iterative design and prototyping
Software Project Management
Project Theory and Application
Successful IT Projects By Darren Dalcher & Lindsey Brodie
Acknowledgements.
Project Management Process Groups
Introduction to Software Engineering (CEN-4010)
Project Management Processes
Chapter # 4 Development and Quality Plans
Teaching slides Chapter 13
CEN 4021 Software Engineering II
KEC Dhapakhel Lalitpur
Director, CPF Financial Services Limited
Chapter 13: Software Project Management
Presentation transcript:

CEN 4021 Software Engineering II Adjustments and Actions (POMA) Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/ sadjadi@cs.fiu.edu

Acknowledgements Dr. Onyeka Ezenwoye Dr. Peter Clarke

Agenda Adjustments and Actions (POMA) Planned Unplanned

Adjustments and Actions Software projects are subject to changes, imperfect planning, and necessary trade-offs. The manager should not be afraid to take action and make adjustments when necessary. Examples of staff beliefs and attitudes that may warrant change are: Believing or hoping that a problem will go away by itself Believing that making changes is a sign of weakness and lack of commitment Not realizing that changes and actions are needed

Adjustments and Actions Being afraid of changes Not knowing what options are available and what adjustments to make If actions are not taken when needed, several unpleasant outcomes may result: Projects may fail Projects may barely get completed while taking a great toll on the organization

Adjustments and Actions Adjustments are often necessary due to: Changing software requirements Discovery of an unfeasible design Loss of skilled team members Financial constraints It is very important to do a thorough risk analysis during the planning stage of the project.

Adjustments and Actions Project managers must first recognize the need to take action and evaluate the risks of not taking action. It is essential to document why an adjustment is needed and the risk of not taking action. After an adjustment the monitoring process dictates if further adjustments and modifications are necessary.

Adjustments and Actions Taking Actions Some changes are planned for deliberately, others occur in response to an event (unplanned). Key metrics and measurements are defined during the planning activity. Analyzing the measurements during the project will indicate if an adjustment and action is to be taken. It is a good idea to monitor deviations from the project plan at regular meetings. Problems should not drag on to other meetings.

Adjustments and Actions Steps in Taking Actions Recommended approach to dealing with situations requiring urgent actions: Clearly state the problem. Communicate the problem while working on the potential solutions to it. Seek out the root cause of the problem and any relevant solutions. Gain the necessary agreement for the chosen solution. Act on the solution.

Adjustments and Actions Steps in Taking Actions Communicate the actions Report on the status of the problem’s resolution. manager must always exhibit good leadership and set the proper tone. The above 7 steps may involve sub-steps.

Adjustments and Actions Change management A set of activities directed towards controlling changes. May include identifying, assessing, measuring and tracking changes. May not include the actual solution discovery process.

Adjustments and Actions Change management Once a solution is chosen the manager must ensure that all stakeholders agree on it. Implementing a particular solution may require: acquiring more resources changing assignments changing schedules Scaling back features All of the above alternatives will call for the cooperation of the team members, including managers.

Adjustments and Actions Change management In some situations the customers may be consulted, particularly concerning deliverables and budget. If the solution necessarily involves dramatic changes to the project’s schedule, functionality, or resources, then the manager must consult both executives and customers as early as possible to win their support for the proposed solution.

Adjustments and Actions Change management List of potential targets for change: The product's functional and nonfunctional requirements A process methodology Schedule The customer’s expectations Tools

Adjustments and Actions Planned adjustments managers should regularly plan on making adjustments throughout the project cycle. Management team may decide to have a planned adjustment at the end of each of the project activities e.g., requirements analysis, design, implementation and coding, testing, and integration. Key metrics are always reviewed before potential adjustments are made functionality, resources, and schedule.

Adjustments and Actions Unplanned adjustments Unplanned activities usually come in response to unanticipated requests or incidents. Most of these unplanned requests and incidents involve high-priority or crisis-level problems. For example a customer suddenly requests a tighter schedule or a key member of the project team leaves, causing direct changes to one of the three main parameters: functionality, resources, schedule.

Adjustments and Actions Unplanned adjustments Any change in one of the three main parameters of functionality, resources, or schedule should evoke a corresponding adjustment in one or both of the other two parameters. This adjustment should not be delayed, and the actions must be taken with urgency.

Adjustments and Actions Unplanned adjustments Functionality changes: Changes in functionality takes more effort and time than defining changes in resources or schedule. The cumulative effect of these simple changes can topple and entire project. Changes made in the earlier stages of software development require less effort and have smaller effects on the project schedule and resource costs. A problem found during testing may require multiple changes and rework in previous completed areas such as design, code, test cases, and test analysis.

Adjustments and Actions Unplanned adjustments cont Functionality changes: Adjusting functionality, resources and schedule will certainly have implications for the budget. Too many projects have failed due to the problem of ever-increasing functionality, known as “scope creep”. Scope creep: Unexpected, gradual increase in work units. The accumulated effect of these increases is often underestimated and potentially poses a high risk to the project.

Adjustments and Actions Unplanned adjustments Resource changes Adjustments need to be made to the schedule or product functionality if a change in the resources occurs. Managers must understand that they need to adjust functionality or schedule unless the organization is lucky enough to have replacement talents in waiting, which is highly unlikely. Changes in human resources, tools, processes, or the budget will require adjustments to either schedule or functionality.

Adjustments and Actions Unplanned adjustments Schedule changes Most of the time the, request adjustment is to shorten the schedule for reasons such as marketplace competition, customer needs, or budget needs. Adding resources in terms of people or tools may not improve the schedule. A schedule can be shortened if there are sub-activities that can be performed in parallel. The availability of a new or different methodology or tool may also shorten a sub-activity.