Project management Inspection Configuration management Change management Process management Other Processes1.

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

Risk Management From Keep Your Projects On Track Other Processes1.
Why Is Software Difficult to Build?
Configuration Management
Communication Facilitation Other Processes1. Meeting Types Project Planning Meetings Review of progress against schedule Update plan, identify pain points.
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 Pittsburgh, PA Lecture 6: Team Planning.
Copyright 2009  Develop the project charter: working with stakeholders to create the document that formally authorizes a project—the charter  Develop.
Risks  All projects have some degree of risk  Risks are issues that can cause problems  Delay in schedule  Increased project costs  Technical risk.
Stepan Potiyenko ISS Sr.SW Developer.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
SE 555 Software Requirements & Specification Requirements Validation.
Course Technology Chapter 3: Project Integration Management.
Iterative development and The Unified process
Chapter 3: The Project Management Process Groups
Chapter 5: Project Scope Management
4 4 By: A. Shukr, M. Alnouri. Many new project managers have trouble looking at the “big picture” and want to focus on too many details. Project managers.
Other Processes 1 Project management Inspection Configuration management Change management Process management.
Chapter 2- Software Process Lecture 4. Software Engineering We have specified the problem domain – industrial strength software – Besides delivering the.
Configuration Management
Project Execution.
Software Configuration Management
SystematicSystematic process that translates quality policy into measurable objectives and requirements, and lays down a sequence of steps for realizing.
Other Software Processes
Michael Solomon Tugboat Software Managing the Software Development Process.
Release & Deployment ITIL Version 3
S/W Project Management
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
Copyright Course Technology 1999
PMP® Exam Preparation Course
N By: Md Rezaul Huda Reza n
1 Chapter 4: Project Integration Management. 2 Learning Objectives Describe an overall framework for project integration management as it relates to the.
Software Testing Life Cycle
Software Configuration Management (SCM)
Resources Performance time. resources Performance time 2.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
Lecture 11 Managing Project Execution. Project Execution The phase of a project in which work towards direct achievement of the project’s objectives and.
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.
BSBPMG505A Manage Project Quality Manage Project Quality Project Quality Processes Diploma of Project Management Qualification Code BSB51507 Unit.
Georgia Institute of Technology CS 4320 Fall 2003.
INFO 424 Team Project Practicum Week 2 - Launch report, Project tracking, Review report Glenn Booker Notes largely from Prof. Hislop.
Develop Project Charter
STEP 4 Manage Delivery. Role of Project Manager At this stage, you as a project manager should clearly understand why you are doing this project. Also.
BSBPMG501A Manage Project Integrative Processes Manage Project Integrative Processes Project Integration Processes – Part 1 Diploma of Project Management.
Introducing Project Management Update December 2011.
BSBPMG404A Apply Quality Management Techniques Apply Quality Management Techniques Project Quality Processes C ertificate IV in Project Management
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Software Configuration Management SEII-Lecture 21
~ pertemuan 4 ~ Oleh: Ir. Abdul Hayat, MTI 20-Mar-2009 [Abdul Hayat, [4]Project Integration Management, Semester Genap 2008/2009] 1 PROJECT INTEGRATION.
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
Peer Review Presented by : Basker George. Peer ( 同等的人 ) Review( 回顾 ) During the development of software, defects are inevitably ( 不可避免 ) injected. Defect.
BSBPMG501A Manage Project Integrative Processes Manage Project Integrative Processes Project Integration Processes – Part 2 Diploma of Project Management.
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
Adaptive Software Development Process Framework. Version / 21 / 2001Page Project Initiation 2.0 Adaptive Cycle Planning 5.0 Final Q/A and.
Prof. Shrikant M. Harle.  The Project Life Cycle refers to a logical sequence of activities to accomplish the project’s goals or objectives.  Regardless.
Software Project Configuration Management
Software Quality Control and Quality Assurance: Introduction
Software Configuration Management (SCM)
Managing the Project Lifecycle
Software Configuration Management
Chapter 3: The Project Management Process Groups: A Case Study
Project Management Process Groups
Chapter 11: Software Configuration Management
Mumtaz Ali Rajput +92 – SOFTWARE PROJECTMANAGMENT Mumtaz Ali Rajput +92 –
QA Reviews Lecture # 6.
Presentation transcript:

Project management Inspection Configuration management Change management Process management Other Processes1

Development Process is the central process around which others revolve Methods for other processes often influenced by the dev process We have looked at various models for dev process a “real” process likely derived from a model Other Processes2

Other Processes In the context of Dev Processes Other Processes3

Project management process Inspection process Configuration management process Change management process Process management process Will briefly look at these now Other Processes4

5

The Typical PMs Role Overall responsibility for the successful planning, execution, monitoring, control and closure of a project. Primary point of contact with project sponsors Key tasks Plans Meets Communicates Project Management == Leadership Other Processes6

10 Qualities of a PM 1. Inspires a Shared Vision 2. Good Communicator 3. Integrity 4. Enthusiasm 5. Empathy 6. Competence 7. Ability to Delegate Tasks 8. Cool Under Pressure 9. Team-Building Skills 10. Problem Solving Skills Other Processes7

What does a PM do? Development process divides development into phases and activities To execute it efficiently, must allocate resources, manage them, monitor progress, take corrective actions, … These are all part of the PM process Hence, PM process is an essential part of executing a project Other Processes8

PM Process Phases There are three broad phases Before: Planning During Monitoring and control Communication facilitation After: Postmortem analysis Planning is a key activity that produces a plan, which forms the basis of monitoring Other Processes9

Project Management Concerns Other Processes10

Project Management Tools Other Processes11

Planning Done before project begins Key tasks Cost and schedule estimation Staffing Monitoring and risk mgmt plans Quality assurance plans Etc. Will discuss planning in detail later Other Processes12

Monitoring and control Lasts for the duration of the project and covers the development process Monitors all key parameters like cost, schedule, risks Takes corrective actions when needed Needs information on the dev process – provided by metrics Other Processes13

Communication Facilitation Realistically no plan covers everything! Additional decisions are made during development Documents should be updated and communicated Typical environment Multiple teams Multiple user groups Multiple disciplines Multiple locations In many setting PM is center of communication hub Will discuss in more detail later Other Processes14

Meeting Types Project Planning Meetings Review of progress against schedule Update plan, identify pain points and dependencies Publically call team leads to task Content Meetings Regular meetings focused around content topics E.G. “Reporting”, “Backend API” Make decision, Record them, Communicate them Use of the “Rolling ” Other Processes15

Meeting Types Issues Meetings Regularly schedule meeting (ie. open in everyone’s schedule) Issues gathered the day before and distributed Issue initiator indicates required attendance QA Meetings Planning Discussion with business Discussion with developers Regular Review of open tickets Other Processes16

Meeting Modalities Modalities In person Video Conference Voice Conference Shared Desktop + Voice Conference Pros/Cons of each? Other Processes17

Postmortem Analysis Postmortem analysis is performed when the development process is over Basic purpose: to analyze the performance of the process, and identify lessons learned Improve predictability and repeatability Central to a “Learning Organization” or culture Also called termination analysis Other Processes18

Relationship with Dev Process Other Processes19

Risk Management From “Keep Your Projects On Track” Other Processes20

Risk Management Usually performed 1. at the start of a project, 2. at the beginning of major project phases (such as requirements, design, coding and deployment), and 3. when there are significant changes (for example, feature changes, target platform changes and technology changes). Other Processes21

Risk Management Four steps to risk management are 1. risk identification, 2. risk analysis, 3. risk management planning and 4. risk review Other Processes22

1) Risk Identification the brainstorming session, consider : Weak areas, such as unknown technology. Aspects that are critical to project success, such as the timely delivery of a vendor's database software, creation of translators or a user interface that meets the customer's needs. Problems that have plagued past projects, such as loss of key staff, missed deadlines or error-prone software Other Processes23

1) Risk Identification Collect up the stakeholder! Who? Hold a brainstorming session, consider : Weak areas, such as unknown technology. Aspects that are critical to project success, such as the timely delivery of a vendor's database software, creation of translators or a user interface that meets the customer's needs. Problems that have plagued past projects, such as loss of key staff, missed deadlines or error-prone software Other Processes24

2) Risk Analysis Make each risk item more specific. Risks like "Lack of management buy-in" and "People might leave" are too vague. Split the risk into smaller, specific risks, such as "Manager Jane could decide the project isn't beneficial," "The database expert might leave," and "The webmaster may be pulled off the project.“ Set priorities Other Processes25

2) Risk Analysis Other Processes26 Risk Items (Potential Future Problems Derived from Brainstorming) Likelihood of Risk Item Occurring Impact to Project if Risk Item Does Occur Priority (Likelihood * Impact) New operating system may be unstable Communication problems over system issues We may not have the right requirements 9654 Requirements may change late in the cycle Database software may arrive late Key people might leave The Priority Scheme

3) Risk Management Planning Other Processes27 Risk Items (Potential Future Problems Derived from Brainstorming) Actions to Reduce Likelihood Actions to Reduce Impact if Risk Does Occur Who Should Work on Actions When Should Actions Be Complete Status of Actions New operating system may not be stable. Test OS more.Identify second OS. Joe3/3/01 Communica-tion problems over system issues. Develop system interface document for critical interfaces. Add replan milestone to realign the team's schedule with other areas. Cathy5/6/01 We may not have the right requirements. Build prototype of UI. Limit Initial product distribution Lois4/6/01

4) Risk Review review your risks periodically, check how well mitigation is progressing. change risk priorities, as required Identify new risks. rerun the complete risk process if the project has experienced significant changes. incorporate risk review into other regularly scheduled project reviews Other Processes28

Risk Management Time Effective! 90 to 120 minutes for projects that are 12 to 60 person- months Control the length of the session by controlling the scope you choose, most sessions usually take less than two hours Other Processes29

Communication Facilitation Other Processes30

Meeting Types Project Planning Meetings Review of progress against schedule Update plan, identify pain points and dependencies Publically call team leads to task Content Meetings Regular meetings focused around content topics E.G. “Reporting”, “Backend API” Make decision, Record them, Communicate them Use of the “Rolling ” Other Processes31

Meeting Types Issues Meetings Regularly schedule meeting (ie. open in everyone’s schedule) Issues gathered the day before and distributed Issue initiator indicates required attendance QA Meetings Planning Discussion with business Discussion with developers Regular Review of open tickets Other Processes32

Meeting Modalities Modalities In person Video Conference Voice Conference Shared Desktop + Voice Conference Pros/Cons of each? Other Processes33

Face to Face Communication A verbal message is affected by: The message itself Paralingual attributes of the message (ie. the pitch, tone, and inflections in the speaker's voice) Nonverbal communication (ie. Posture, facial expression, shoulders, tugging on the ears, crossed arms, hand signals) To be an effective communicator, you must ask questions. Do you understand me? Questions help the project team, ask for clarification, and achieve an exact transfer of knowledge. Other Processes34

Writing 1) Understand why you’re writing have explicit answers for two questions: Why am I writing this? What exactly do I want the result of this message to be? Other Processes35

Writing 2) Get what you need Really just three basic types of business . Providing information - “Larry Tate will be in the office Monday at 10.” Requesting information - “Where did you put the ‘Larry Tate’ file?” Requesting action - “Will you call Larry Tate’s admin to confirm our meeting on Monday?” The recipient must immediately know which type of it is. Other Processes36

Writing 3) Make One Point per If you need to communicate a number of different things: Consider writing a separate on each subject, especially if they related to different topics or have different timescales. Consider presenting each point in a separate, numbered paragraph, especially if relate to the same project. Making each point stand out, significantly increasing the likelihood that each point will be addressed. Other Processes37

Writing 3) Write a great Subject line Help your recipient to immediately understand why you’ve sent them an quickly determine what kind of response or action it requires Avoid “Hi,” “One more thing…,” or “FYI,” Best is a short summary of the most important points Lunch resched to 1pm Reminder: Monday is "St. Bono’s Day"–no classes REQ: Resend Larry Tate zip file? HELP: I’ve lost the source code? Thanks for the new liver–works great! Other Processes38

Writing 3) Brevity is the soul of…getting a response The Long Crafted 1% Explores nuances Handling political hot potatoes The Short Directed 99% Make it fit on one screen with no scrolling. Better still in the “review space” A concise is much more likely to get action But be presise… Other Processes39

Bad Example Good Example Subject: Proposal Lynn, Did you get my proposal last week? I haven't heard back and wanted to make sure. Can you please call me so we can discuss? Thanks! Peter Subject: Checking On Reliable Landscapes Proposal Lynn, I just wanted to check that you have received the landscaping proposal I ed to you last week. I haven't heard back and wanted to make sure it went through. Can you please call me by Thursday so we can discuss? This is when our discount offer expires, and I want to make sure you don't miss it! The quickest way to contact me is by cell phone. Thanks! Peter Schuell, Owner Reliable Landscaping, Inc (office) (cell) Other Processes40

Other Processes41

Background Main goal of inspection process is to detect defects in work products First proposed by Fagan in 70s Earlier used for code, now used for all types of work products Is recognized as an industry best practice Data suggests that it improves both Q&P Other Processes42

Background “A defect is an instance in which a requirement is not satisfied.” [Fagan, 1986] Defects injected in sw at any stage Hence must remove them at every stage Inspections can be done on any document including design docs and plans Is a good method for early phases like requirements and design Also useful for plans (PM plans, CM plans, testing plans,…) Other Processes43

Some Characteristics Conducted by group of technical people for technical people (i.e. review done by peers) Is a structured process with defined roles for the participants The focus is on identifying problems, not resolving them Review data is recorded and used for monitoring the effectiveness Other Processes44

Steps in Typical Review Process Other Processes45

Planning Select the group review team – three to five people group is best Identify the moderator – has the main responsibility for the inspection Prepare package for distribution – work product for review plus supporting docs Package should be complete for review Other Processes46

Overview and Self-Review A brief meeting – deliver package, explain purpose of the review, intro,… All team members then individually review the work product Lists the issues/problems they find in the self- preparation log Checklists, guidelines are used Ideally, should be done in one sitting and issues recorded in a log Other Processes47

Self-Review Log Project name: Work product name and ID: Reviewer Name: Effort spent (hours): Defect list Other Processes48 NoLocationDescriptionCriticality

Group Review Meeting Purpose – define the final defect list Entry criteria each member has done a proper self-review logs are reviewed Group review meeting A reviewer goes over the product line by line At any line, all issues are raised Discussion follows to identify if a defect Decision recorded (by the scribe) Other Processes49

Group Review Meeting… At the end of the meeting Scribe presents the list of defects/issues If few defects, the work product is accepted; else it might be asked for another review Group does not propose solutions though some suggestions may be recorded A summary of the inspections is prepared useful for evaluating effectiveness Other Processes50

Group Review Meeting… Moderator is in-charge of the meeting and plays a central role Ensures that focus is on defect detection and solutions are not discussed/proposed Work product is reviewed, not the author of the work product Amicable/orderly execution of the meeting Uses summary report to analyze the overall effectiveness of the review Other Processes51

Summary Report Example Project Work Product Type Size of work product Review team Effort (person hours) Preparation Group meeting Total XXXX Project plan 14 pages P1, P2, P3 10 (total) Other Processes52

Summary Contd. Defects No of critical defects No of major defects No of minor defects Total Review status Reco for next phase Comments Accepted Nil Nice plan Other Processes53

Rework and Follow Up Defects in the defects list are fixed later by the author Once fixed, author gets it OKed by the moderator, or goes for another review Once all defects/issues are satisfactorily addressed, review is completed and collected data is submitted Other Processes54

Roles and Responsibilities Main roles Moderator – overall responsibility Author –Listen, inform, avoid defensiveness Reviewer(s) – to identify defects Reader – not there in some processes, reads line by line to keep focus Scribe – records the issues raised Other Processes55

Guidelines for Work Products Work Product Inspection focusParticipants Req SpecMeet customer needs Are implementable Omissions, inconsistencies, ambiguities Customer Designer Tester, Dev Analyst HLDDesign implements req Design is implementable Ommissions, quality of design Req author Designer Developer Other Processes56

Guidelines for Work Products CodeCode implements design Code is complete and correct Defects in code Other quality issues Designer Tester Developer Test cases Set of test cases test all SRS conditions Test cases are executable Are perf and load tests there Req author Tester Proj mgr Proj Mgmt Plan Plan is complete and specifies all components of the plan Is implementable Omissions and ambiguities Proj mgr Another Proj mgr Other Processes57

Summary Purpose of reviews: to detect defects Structured reviews are very effective - can detect most of the injected defects For effective review, process has to be properly defined and followed Data must be collected and analyzed Other Processes58

Other Processes59

Background A software project produces many items - programs, documents, data, manuals, … All of these can be changed easily – need to keep track state of items Software Configuration Management (SCM) Systematically control the changes Focus on changes during normal evolution (req changes will be handled separately) CM requires discipline as well as tools Other Processes60

Background SCM often independent of dev process Dev process looks at macro picture, but not on changes to individual items/files As items are produced during dev they are brought under SCM SCM controls only the products of the development process Other Processes61

SCM Process and Dev process Other Processes62

Need for CM CM needed to deliver product to the client What files should comprise the product? What versions of these files? How to combine these to make the product? Just for this, versioning is needed, and state of different items has to be tracked There are other functions of CM also Other Processes63

Functionality Needed Capture current state of programs Capture latest version of a program Undo a change and revert back to a specified version Prevent unauthorized changes Gather all sources, documents, and other information for the current system Other Processes64

CM Mechanisms Configuration identification and baselining Version control Access control These are the main mechanisms, there are others like naming conventions, directory structure,… Other Processes65

Configuration Items Sw consists of many items/artifacts In CM some identified items are placed under CM control Changes to these are then tracked Periodically, system is built using these items and baselines are established Baseline – logical state of the system and all its items; is a reference point Other Processes66

Version and access control Key issues in CM Done primarily on source code through source code control systems, which also provide access control Allows older versions to be preserved and hence can undo changes Examples: CVS – Original open source system (1986) Subversion – Open source CVS replacement (1999) Microsoft Visual SourceSafe (VSS) – targeted for smaller dev projects IBM Rational ClearCase – Industrial strength solution Other Processes67

Version and Access Control When programmer developing code – is in private area When code is made available to others, it goes in an access-controlled library For making changes to an item in library, it has to be checked out Changes made by checking-in the item – versioning is automatically done Final system is built from the library Other Processes68

Version/Access Control Generally both version and access control done through CM tools Tools limit access to specified people - formal check in, check out procedures Automatic versioning done when a changed file is checked-in Check-in, check-out control may be restricted to a few people in a project Require successful compile/build cycle Other Processes69

CM Process Defines the activities for controlling changes Main phases CM Planning Executing the CM process CM audits Other Processes70

CM Planning Identify items to be placed under CM Define library structure for CM Define change control procedures Define access control, baselining, reconciliation, procedures Define release procedure Other Processes71

CM Audit During project execution CM procedures have to be followed (e.g. moving items between directories, naming, following change procedures, …) Process audit has to be done CM audit can also check if items are where they should be Other Processes72

Summary – CM CM is about managing the different items in the product, and changes in them Developing a CM plan at the start is the key to successful to CM CM procedures have to be followed; audits have to be performed Requires discipline and tools Other Processes73

Other Processes74

Background Requirements change at any time during the development Changes impact the work products and the various configuration items Uncontrolled changes can have a huge adverse impact on project in cost/sched Changes have to be allowed, but in a controlled manner Other Processes75

A Change Mgmt Process Log the changes Perform impact analysis on the work products and items Estimate impact on effort and schedule Review impact with stakeholders Rework the work products/items Other Processes76

Changes Change often triggered by change request Change req log keeps a record of requests Impact analysis for a change request involves identifying the changes needed to diff items, and the nature of change The impact of changes on the project is reviewed to decide whether to go ahead Cumulative changes also often tracked Other Processes77

Other Processes78

Background A process is not a static entity – it has to change to improve to improve the Q&P Focus of process management is to evaluate and improve the process Is different from project management which focuses on a project Process management is an advanced topic Other Processes79

Software Process Improvement To improve the process, an org must understand the current process Requires process be properly documented Properly executed on projects Data is collected from projects to understand the performance of process on projects Changes to process are best made in small increments Other Processes80

Software Process Improvement Frameworks What changes should be made to the process and when Frameworks suggest ways of how process improvement can proceed Capability Maturity Model (CMM) is one of the most common frameworks Other Processes81

CMM CMM has five maturity levels for a software process (level 1 is ad-hoc) In a level, process has some capabilities and lays the foundation for next level For moving from one level to another, CMM specifies areas to focus on Is used heavily by sw industry Other Processes82

CMM Other Processes83 Note: Student projects: CMM level 1 SW Engg. Course Project: CMM level 2

Course Project Notes Decide on roles and responsibilities Possible Roles Project management & Change management process Web site, Charter & Feasibility Doc, SRS & Project Plan, Meeting minutes Design & Dev Lead Design Docs Inspection Lead reviews of other group’s work products Configuration Management Lead Setup and management of version control and build system Quality Assurance & Testing Lead Test Docs, User manuals Software Process84

Course Project Notes Project Charter and Feasibility Doc Authorizes the project, describes the Why, What, How, Who and When. The customer, A problem statement (the business problem to be solved?), Project Description (the approach to be taken?), Goals, Objectives, and Design principles (How do you know if you are successful? What do you value?) The project scope (What is specifically included and excluded), Critical success factors (What is key to success, what are the key risks, and mitigation plans), Any assumptions and/or constraints Project organization, Major milestones, and Roles and responsibilities. Anchors a project helping the team avoid mid project drift. Every project needs a charter! If the sponsor doesn't provide it, the development team should create one and get it approved! See the Templates Directory for a number of Project Charter Templates. Software Process85