SE 477: Управление программными и системными проектами

SE 477
Software and Systems Project Management
Dennis Mumaugh, Instructor
dmumaugh@depaul.edu
Office: CDM, Room 428
Office Hours: Wednesday, 4:00 – 5:30
February 22, 2017
SE 477: Lecture 8
1 of 97
Administrivia
 Comments and feedback
 Lectures?
 Work Load?
 Reading?
 Progress
 Project
 Journal
Assignment 5 – Due March 8, 2017
 Monitoring and Control
 No late submissions!!
February 22, 2017
SE 477: Lecture 8
2 of 97
Midterm Exam
Winter
2013
Spring
2013
Fall
2013
Spring
2014
Fall
2014
Spring
2015
Winter
2017
100
99
99
100
100
99
100
Max
Min
66
72
67
75
82
6
2
00-69
0
88.35
Median
90.00 92.00
86.00 95.00
87
90.00
Std.
Dev.
9.40
6.53
9.49
6.94
7.48 11.84
8.26
Total
20
15
18
16
SE 477: Lecture 8
80-89
70-79
86.69 90.71 82.80
February 22, 2017
9
71
89.00 90.40 86.89
7
90-100
60
Mean
90
Grade
distribution
10
17
3 of 97
SE 477 – Class 8
Topic: Miscellaneous:
 Quality control: planning and assessment and project tracking
 Configuration management and change control
 Stakeholder management;
 Final stages
» Rollout
» Migration
» Project recovery
 Defining project success and failure
» Success tips
 Reading:
 PMBOK-SWE Ch. 4.4, 4.5, Ch. 8, Ch. 13
 See also reading list
February 22, 2017
SE 477: Lecture 8
4 of 97
Thought for the day
"I don't know the key to success but the key
to failure is trying to please everybody."
– Bill Cosby
February 22, 2017
SE 477: Lecture 8
5 of 97
Last time
 Post-Planning Project Management aka Execution,
Monitoring and Control, Project Closure
 Project executing processes
 Focusing on the project management process
 Project Monitoring, Tracking and Control
 Day-to-day tracking and management
 Measuring software progress
» Cost Schedule Control (aka Earned Value Analysis)
 Milestones and status reporting
February 22, 2017
SE 477: Lecture 8
6 of 97
Quality Control
"Quality must be built in at the design
stage. It may be too late once plans are
on their way."
– W. Edwards Deming
February 22, 2017
SE 477: Lecture 8
7 of 97
Perform quality control
Perform quality control is concerned with monitoring specific
project results for compliance with quality standards
 Performed throughout project
 May also include taking control actions to correct causes of
quality problems
Perform quality assurance is the process that provides the
framework of activities and standards for performing quality
control
February 22, 2017
SE 477: Lecture 8
8 of 97
Role of the SQA Group – I
Form a Software Quality Assurance Group
 Prepares an SQA plan for a project.
 The plan identifies
» evaluations to be performed
» audits and reviews to be performed
» standards that are applicable to the project
» procedures for error reporting and tracking
» procedures for change management
» documents to be produced by the SQA group
» amount of feedback provided to the software project team
 Participates in the development of the project’s software process
description.
 The SQA group reviews the process description for compliance with
organizational policy, internal software standards, externally imposed
standards (e.g., ISO-9001), and other parts of the software project
plan.
February 22, 2017
SE 477: Lecture 8
9 of 97
Role of the SQA Group – II
 Reviews software engineering activities to verify compliance
with the defined software process.
 identifies, documents, and tracks deviations from the process
and verifies that corrections have been made.
 Audits designated software work products to verify compliance
with those defined as part of the software process.
 reviews selected work products; identifies, documents, and
tracks deviations; verifies that corrections have been made
 periodically reports the results of its work to the project manager.
 Ensures that deviations in software work and work products
are documented and handled according to a documented
procedure.
 Records any noncompliance and reports to senior
management.
 Noncompliance items are tracked until they are resolved.
February 22, 2017
SE 477: Lecture 8
10 of 97
Software Quality Assurance
 The area of Software Quality Assurance can be broken
down into a number of smaller areas such as
 quality of planning,
 formal technical reviews,
 Testing
and
 training.
 Here we take a look at Formal Technical Review methods
and Testing ...
February 22, 2017
SE 477: Lecture 8
11 of 97
Formal Technical Reviews
 Software quality assurance activity performed by software
engineers to:
 Uncover errors in function, logic, implementation.
 Verify that the software meets requirements.
 Represented using correct standards.
 Achieve uniformity.
 Manage projects.
 Walkthroughs
 Inspections (Code Reading)
 Round-robin reviews
[See notes and next slides for
description/discussion of the
above terms.]
February 22, 2017
SE 477: Lecture 8
12 of 97
Formal Technical Reviews
 Walkthroughs
 The least formal and most common kind of review is the
walkthrough, which is any meeting at which two or more
developers review technical work with the purpose of improving its
quality.
 Walkthroughs are useful to rapid development because you can
use them to detect defects earlier than you can with testing.
February 22, 2017
SE 477: Lecture 8
13 of 97
Formal Technical Reviews
 Inspections and Code Reading
 Code reading is a somewhat more formal review process than a
walkthrough but nominally applies only to code.
 In code reading, the author of the code hands out source listings to
two or more reviewers. The reviewers read the code and report any
errors to the code's author.
February 22, 2017
SE 477: Lecture 8
14 of 97
Formal Technical Reviews
 Inspections and Code Reading
 Inspections are the most formal kind of technical review, and they have
been found to be extremely effective in detecting defects throughout a
project.
 Developers are trained in the use of inspection techniques and play
specific roles during the inspection process.
1. The "moderator” hands out the material to be inspected before the
inspection meeting.
2. The "reviewers" examine the material before the meeting and use
checklists to stimulate their reviews.
3. During the inspection meeting, the "author" paraphrases the material,
the reviewers identify errors, and the "scribe" records the errors.
4. After the meeting, the moderator produces an inspection report that
describes each defect and indicates what will be done about it.
5. Throughout the inspection process you gather data about defects,
hours spent correcting defects, and hours spent on inspections so that
you can analyze the effectiveness of your software-development
process and improve it.
February 22, 2017
SE 477: Lecture 8
15 of 97
Formal Technical Reviews
 Round-robin reviews
Each reviewer gets to present their comments on the product. The
reviewers present one comment at a time. The person to the left of the
leader starts, the reviewer to their left goes next, and so on, around the
table (telephonic attendees are assigned an arbitrary order).
 More discussion on Reviews: Round-Robin ReviewTraining Plan
<http://alumnus.caltech.edu/~leif/OO/ReviewTraining.html>
February 22, 2017
SE 477: Lecture 8
16 of 97
“QA” & Testing
 Testing “Phases”
 Static vs. Dynamic
 Unit
 Integration
 System
 User Acceptance
Testing
Testing
 Automated Testing
 Testing Types
 Black-box
 White-box
February 22, 2017
 Pros and cons
 Defect tracking
 Integration: 2 types
 Top down
 Bottom up
SE 477: Lecture 8
17 of 97
Defect Rates
 In general, defect rate is the number of defects over the
opportunities for errors during a specified time frame
 Defect rate found during formal machine testing is usually
positively correlated with defect rate experienced in the field
 Tracking defects and rates allow us to determine the quality
of the product and how mature it is.
February 22, 2017
SE 477: Lecture 8
18 of 97
Defect Metrics
 Open Bugs (outstanding defects)
 Ranked by severity
 Open Rates
 How many new bugs over a period of time
 Close Rates
 How many closed (fixed or resolved) over that same
period
 Ex: 10 bugs/day
 Change Rate
 Number of times the same issue updated
 Fix Failed Counts
 Fixes that didn’t really fix (still open)
 One measure of “vibration” in project
February 22, 2017
SE 477: Lecture 8
19 of 97
Defect Metrics
 Why do we measure defects? Why do we track the defect count when
monitoring the execution of software projects? What does this tell us?
 Defect counts indicate how well the system is implemented and how
effectively testing is finding defects.
 Low defect counts may mean that testing is not uncovering defects.
 Defect counts that continue to be high over time may indicate a
larger problem,
» inaccurate requirements, incomplete design and coding,
premature testing, lack of application knowledge, or inadequately
trained team.
 Defect trends provide a basis for deciding on when testing has
completed. When the number of defects found falls dramatically, given a
constant level of testing, the product is becoming stable and moving to
the next phase is feasible. Look at the next slide.
 [See also notes.]
February 22, 2017
SE 477: Lecture 8
20 of 97
The Rayleigh Distribution
Defect frequency
If we graph defects over time
they will show a Rayleigh
distribution
t e-t2/2k2
Rc =
k2
k is a constant representing
the time at which defects
peak.
Note the tail to the distribution.
k
We see this same curve in other
areas as well. Specifically in
reliability and quality.
February 22, 2017
SE 477: Lecture 8
Time
21 of 97
Basic tools of quality
 Cause-and-effect (fishbone, Ishikawa) diagram
 Shows the relationship between the effects of problems and their
causes
 See lecture 6 slide 50-52 and PMP Study Guide, p. 261
 Process flowcharts
 Graphical representation of a project process that can help identify
where problems occur
 Example on lecture 6 slide 53
February 22, 2017
SE 477: Lecture 8
22 of 97
Basic tools of quality
 Control chart
 Maps the variation of a project variable (e.g. number of defects) as
a function of time relative to a baseline value and within
boundaries of ±3σ
» Baseline may be established after sufficient project variable data
are available
 Acceptable upper and lower boundaries of variable values are
called the Upper Control Limit (UCL) and Lower Control Limit
(LCL), respectively
February 22, 2017
SE 477: Lecture 8
23 of 97
Basic tools of quality
Control Chart
Upper
Control
Limit
+3σ
Number of Defects
+2σ
+1σ
Baseline
value
x
-1σ
-2σ
-3σ
Baseline
establishment
February 22, 2017
Time
SE 477: Lecture 8
Lower
Control
Limit
24 of 97
Histogram
 A graphic representation of frequency counts of a sample or
population
 X-axis lists the unit intervals of a parameter like defect
severity level and Y-axis contains frequency counts
 Purpose is to show the distribution characteristics of the
parameter
February 22, 2017
SE 477: Lecture 8
25 of 97
Pareto Diagram
 A frequency bar chart in descending order by types of
problems or defects
 X-axis is usually the defect cause and Y-axis is the defect
count
 Identifies the few causes that account for the majority of
defects
 Commonly see a 80-20 pattern -- 80% of the defects from
20% of the causes
February 22, 2017
SE 477: Lecture 8
26 of 97
Basic tools of quality
12
100
10
Number of Defects
6
4
8
6
50
% of Defects
Number of Defects
75
4
2
25
2
Team A
Team B
Team C
Histogram
Team D
Team C
Team A
Team B
Team D
Pareto Chart
February 22, 2017
SE 477: Lecture 8
27 of 97
Run Charts
 Tracks the performance of the parameter of interest over
time
 X-axis is time and Y-axis is the value of the parameter
 Best used for trend analysis
 Especially useful if historical data is available for
comparisons with the current trend
 Frequently used for project management
 A run chart is a more general version of a control chart: it is
mostly used for trend analysis rather than project control
decisions. Look for patterns.
February 22, 2017
SE 477: Lecture 8
28 of 97
Run Chart
February 22, 2017
SE 477: Lecture 8
29 of 97
Scatter Diagram
 Vividly portrays the relationship of two variables, if any.
 For a cause-effect relationship, the X-axis is the independent variable






and the Y-axis is for the dependent variable
Each point represents an observation of both variables
x-y plot showing the relationship between two project variables
Aid in looking for relationships between two variables
A mathematical equation representing relationship between variables
can be found using regression analysis (simple or multivariate)
Scatter plots are useful for finding direct or indirect relationships which
can then be used to analyze/improve quality.
Correlation is not causation!!
February 22, 2017
SE 477: Lecture 8
30 of 97
Project Duration Scatter Diagram
3
2.5
Calendar Months
2
1.5
1
0.5
0
0
1
2
3
4
5
6
KLOC
February 22, 2017
SE 477: Lecture 8
31 of 97
Change Management
"It is not necessary to change. Survival is not
mandatory."
– W. Edwards Deming
February 22, 2017
SE 477: Lecture 8
32 of 97
Integrated Change Control
 Integrated Change Control is a project management
integration knowledge area process concerned with project
change requests
 The Perform Integrated Change Control process is carried
out from project inception through completion
 All changes must be carefully controlled to maintain the
integrity and consistency of the project plan
 Change control encompasses review, evaluation, approval/rejection,
and managing and coordinating approved changes
February 22, 2017
SE 477: Lecture 8
33 of 97
Integrated change control
 Recognizes that projects will often require changes to the
established project plan
 All changes must be carefully controlled to maintain the
integrity and consistency of the project plan
 Integrated change control encompasses all aspects of
change to the project:
 Reviewing and approving requested changes
 Managing the changes when they actually occur
 Controlling elements of the project management plan
(scope, cost, budget, schedule, and quality) in response
to changes
 Controlling changes to requirements, design, code and
documentation.
February 22, 2017
SE 477: Lecture 8
34 of 97
Change or Configuration Control
Configuration Management Plan
 Change & Version control
 Items:
» Code (source for product)
» Documents: requirements, design, test plans, user
guides
» Plans and data bases (MS project, etc.)
» Scripts for testing
» Software development plan and other process
documents
February 22, 2017
SE 477: Lecture 8
35 of 97
Integrated Change Control
 In some projects, the Integrated Change Control process
includes a change control board (CCB)
 The CCB is a formally chartered group responsible for
reviewing, evaluating, approving, delaying, or rejecting
changes to the project, and for recording and
communicating such decisions
 Note that changes have a potentially greater impact in CPM
scheduling:
 Changes on the critical path have greatest impact while those off the
critical path have less
 Changes in CCM scheduling require adjustments to buffers
 The same responses to change are needed, but the impact to the
schedule may be less severe than in CPM
February 22, 2017
SE 477: Lecture 8
36 of 97
Change Control
 Average project has 25% requirements change
 Overly detailed specs. or prolonged requirements phase are
not the answer
 Sources of change
 Change control is a process
 Change Control Board (CCB)
 Structure, process, triage
February 22, 2017
SE 477: Lecture 8
37 of 97
Control the Change – I
1. Need for change is recognized
2. Change request is submitted
as a “request for change”
(RFC) or engineering change
order (ECO)
3. Developer or PM team
evaluates: impact and
desirability
4. Change report is generated
5. Change control authority
(CCB) makes a decision to
either:
a)
Deny request.
i.
Change request is denied
ii. User is informed
b) Proceed
February 22, 2017
If change is approved:
1. Request is queued for action.
ECO (Engineering Change
Order) is generated.
2. Individuals assigned to
configuration objects.
3. Objects checked out and change
made.
4. Change audited.
5. Baseline established.
6. If it is a Software Configuration
Item (SCI)
 Perform SQA and testing
activities
7. Check-in the changed objects
SE 477: Lecture 8
38 of 97
Control the Change – II
For Software Configuration Items (SCI)
1. Promote SCI for inclusion in next release
2. Rebuild appropriate version
a) Include all changes in release
b) Review/audit the change
c) Perform Verification and Validation [testing activities]
3. Distribute new version
February 22, 2017
SE 477: Lecture 8
39 of 97
Control the Change – III
 Use a change management system (COTS) and a change tracking
system.
 Ideal if they are integrated: aka Comprehensive Software Change
Management
 SCM (Source code management)
 Perforce – multi-platform client/server solution
 ClearCase (IBM/Rational)
 Subversion
 CVS
 Issue/defect tracking software
 Perforce – multi-platform client/server solution
 ClearQuest (IBM/Rational) offers comprehensive software change
management
February 22, 2017
SE 477: Lecture 8
40 of 97
Agile Perspective:
Integrated Change Control
February 22, 2017
SE 477: Lecture 8
41 of 97
Integrated change control
 The agile change control process is not controlled by a
change review board and the project manager
 Product changes are owned and managed by the customer
 Process changes are owned by the team
 The project manager facilitates collaborative discussion of changes
between the customer and the team
☛ Integrated Change Control maps to ‘continuous backlog
management’ in an agile project
February 22, 2017
SE 477: Lecture 8
42 of 97
Summary comparison
February 22, 2017
SE 477: Lecture 8
43 of 97
Stakeholder Management
February 22, 2017
SE 477: Lecture 8
44 of 97
Introduction
 Stakeholder Management is the process of developing
appropriate management strategies for all project
stakeholders
 The process goal is to effectively engage stakeholders
throughout the project life cycle
 It analyzes their needs, interests, and potential impact on
project success
 The process provides a plan for interacting with project
stakeholders with the project's interests as its goal
February 22, 2017
SE 477: Lecture 8
45 of 97
Stakeholder Management
Inputs
 Project charter
 Procurement documents
 Enterprise environmental factors
 Organizational process assets
Tools & Techniques
 Stakeholder analysis
 Expert judgment
 Meetings
Outputs
 Stakeholder register
 Stakeholder management plan
February 22, 2017
SE 477: Lecture 8
46 of 97
Stakeholder register
 The stakeholder register is the primary output from the
Identify Stakeholders process. For each stakeholder, the
register contains:
 Name
 Position in organization
 Location
 Role in project
 Contact information
 List of stakeholder’s major requirements
 List of stakeholder’s main expectations
 Potential influence on the project
 Phase in the lifecycle of most interest
 A stakeholder classification. This may include internal/external;
supporter/neutral/resister; and high/medium/low influence/power/
impact/interest
February 22, 2017
SE 477: Lecture 8
47 of 97
Stakeholders
 Stakeholder engagement levels can be classified as:
 Unaware. Unaware of project and its potential impacts
 Resistant. Aware of project and its potential impacts and resistant to
the changes anticipated by the project
 Neutral. Aware of project and neither supportive nor resistant
 Supportive. Aware of project and its potential impacts and supportive
of the changes anticipated by the project
 Leading. Aware of project and its potential impacts and actively
engaged in ensuring the project’s success
February 22, 2017
SE 477: Lecture 8
48 of 97
Stakeholder management plan
 The stakeholder management plan identifies the
management strategies required to effectively engage
stakeholders
 The stakeholder management plan supplements the
information in the stakeholder register with:
 Desired and current engagement levels of key stakeholders
 Scope and impact of change (due to project) to stakeholders
 Identified interrelationships and potential overlap between
stakeholders
 Stakeholder communication requirements
 Information to be distributed to stakeholders, including language,
format, content, and level of detail
February 22, 2017
SE 477: Lecture 8
49 of 97
Stakeholder management plan
 The stakeholder management plan supplements the
information in the stakeholder register with (cont’d):
 Reason for the distribution of that information and the expected
impact on stakeholder engagement
 Time frame and frequency for the distribution of required information
to stakeholders
 Method for updating and refining the stakeholder management plan
as the project progresses and develops
 The stakeholder management plan contains sensitive
information—appropriate precautions are needed to
safeguard its information and prevent its inappropriate
disclosure
February 22, 2017
SE 477: Lecture 8
50 of 97
Stakeholder management plan
Adapted from Figure 13-6
PMBOK Guide, 5th Edition
February 22, 2017
SE 477: Lecture 8
51 of 97
Useful if conditions warrant
 From the agile perspective, identifying stakeholders is a
valuable process: the more inclusive your understanding of
stakeholders, the better
 Agile promotes the idea that transparency is the best policy
 Agile utilizes information radiators: information tools (e.g., a project
wiki) that make project information—including progress and
impediments—visible to all interested stakeholders
 This minimizes the chances for miscommunication and effectively
short-circuits the rumor mill
February 22, 2017
SE 477: Lecture 8
52 of 97
Useful if conditions warrant
 In some cases Stakeholder Management advocates
tailoring information access and flow to the individual
stakeholder
 Though this approach may be warranted in some
situations—volatile, highly-politicized project, for example—
it is not without its risks:
 “Project managers should be aware of the sensitive nature of the
stakeholder management plan and take appropriate precautions. For
example, information on stakeholders who are resistant to the project
can be potentially damaging, and due consideration should be given
regarding the distribution of such information.”*
 Analogies:
 Private- vs. public-key encryption mechanisms
 Proprietary vs. open-source software security
*From Ch. 13.2.3.1, PMBOK Guide, 5th Edition
February 22, 2017
SE 477: Lecture 8
53 of 97
Sidebar: Important stakeholders
February 22, 2017
SE 477: Lecture 8
54 of 97
Software Project Management
Final Stages
February 22, 2017
SE 477: Lecture 8
55 of 97
Other Final Steps
 Roll-Out
 Release Check-List
 Training
 More than just end-users
» Users, systems ops, maintenance developers, sales
 Documentation
» Many types: End-user, sales & marketing, operations,
design
 Migration
 Moving users from existing system to your new one
 Maintenance and Support
We’ll discuss each of these …
February 22, 2017
SE 477: Lecture 8
56 of 97
Rollout
 Create a “Release Checklist”
 Avoid activities falling through the cracks
 Activities by Group:
» Engineering, QA, Documentation, Operations
 Possibly sign-off signatures
 Roll-out: Must have a plan for the process
 Often on a given day (ex: a Sat.)
 Must be a very detailed plan
February 22, 2017
SE 477: Lecture 8
57 of 97
Shipping Details
 Packaging (if commercial product)
 Marketing collateral
 Security mechanisms (if commercial product)
 Licensing
 Plan
 Mechanism
February 22, 2017
SE 477: Lecture 8
58 of 97
Installation
 Scripts
 Uninstall (if not Web-based)
 If you need to install your software (as on PCs):
 Don’t underestimate:
» Time this takes to develop
» Importance of a “first impression”
 Or, if “custom” software you’re reselling
 Installation at site is often a “mini-project”
February 22, 2017
SE 477: Lecture 8
59 of 97
Training
 Often more than just end-users
 Users
 Sales & Marketing staff
 System operators
 Maintenance engineers (possibly)
 Sales engineers (possibly)
 (Technical) Support staff
February 22, 2017
SE 477: Lecture 8
60 of 97
Documentation
 Must be ready by ship-date
 Final user documentation
 On-line help
 Updates to other
 Operations documentation
 Development documentation
 Sales and marketing material
 Web site
 Test reports
 Release notes
February 22, 2017
SE 477: Lecture 8
61 of 97
Migration
Migration is the process of moving from the old
application/system to the new
 Migration Plan
 Back-out Plan
 Data Conversion
February 22, 2017
SE 477: Lecture 8
62 of 97
Migration Plan
 Includes
 Description of environment (computers, DBs, interfaces)
 Description of existing data needed
 Description of operational constraints (ex: when can we
move to the new system? Weekends only? Last week of
month only?)
 List of affected organizations and contacts
 Plan of steps to be taken
 Does it require a service interruption?
 If so, when does this happen? A weekend?
 Training?
 Is there a help-desk?
 If so, do they have “scripts” or new material?
February 22, 2017
SE 477: Lecture 8
63 of 97
Migration Strategies
 Communication with customers is crucial
 Importance of 2-way communication
 What is happening, when, and why
 “Why” should remind them of the benefits
 Not too much detail or too little
 Where do customers go for more information?
 Minimize intrusiveness
 Find-out about customer’s key dates
 When does the system absolutely need to be stable?
 Know about their important deadline dates
 They must buy-into the approach!
February 22, 2017
SE 477: Lecture 8
64 of 97
Migration Strategies
 Considerations:
 Level of business disruption
 Degree of latitude in “production” date
 How much internal opposition to system is there?
» If higher, perhaps a longer ‘adjustment’ period
 Your comfort level of system quality
» If questionable, may want to mitigate risk
February 22, 2017
SE 477: Lecture 8
65 of 97
Migration Strategies
1. Flash-Cut migration
☞ Straight-move from old system to new
A.Immediate Replacement
Fastest approach
Still want a back-out plan
Requires strong planning and testing
B.Parallel Operation
Mitigates risk
Parallel to either existing manual or system process
Cut occurs once new system “burned-in”
2. Staged migration
Replace one part of existing system at a time
February 22, 2017
SE 477: Lecture 8
66 of 97
Flash-Cut
 Immediate Replacement
 Ex: new corporate-wide calendar system
 Requires very careful planning & testing
 Still try to get some users to “try” it first if possible
 Develop a back-out plan
February 22, 2017
SE 477: Lecture 8
67 of 97
Cutover
 Criteria: What conditions must be met prior?
 Responsibility: Who decides?
 Operations: Who ‘owns’ it once it’s live?
 Rehearsals: Sometimes used.
February 22, 2017
SE 477: Lecture 8
68 of 97
Back-Out Plan
 Especially important for “conversions”
 Customers already have expectations and needs as
defined by their existing system
 Must be able to restore customer’s service ASAP
 May mean running both simultaneously “just in case”
 Leave it in place for awhile (more than a day!)
 When to fall-back?
 Mgmt: sooner, Tech: one-more-fix
 Set a time limit (ex: 3 hours of start)
 Data recovery and migration back to old system
February 22, 2017
SE 477: Lecture 8
69 of 97
Data Conversion




Most systems need this step
Most PMs forget this
Impacts both completely new and replacement systems
The “data” often more valuable than the “system”
Data Conversion Areas
 Data Sources:
 Where does it come from?
 Do you need to modify data on the way in?
 Is it accurate?
 Process Controls:
 Does it happen all at once?
 How do you guarantee it’s been done correctly?
 Completion:
 How do you handle any ‘exceptions’?
 Do you make backups? Can you restart?
February 22, 2017
SE 477: Lecture 8
70 of 97
Parallel Operation
 Multiple variations of this method
 An “adoption” period
 See telephone industry with new area codes
 Both work for a period of time
 Strategies
 Avoid flash-cuts if possible
» Start with test subjects
February 22, 2017
SE 477: Lecture 8
71 of 97
Concluding Software Projects
 Seems simple, often isn’t
 Potential Issues
 Last-minute change requests
» “One more feature”
 Disputes of fulfillment of all requirements
» Often “interpretation” issues
 Keeping the team motivated
 Difficult transition to maintenance
February 22, 2017
SE 477: Lecture 8
72 of 97
Maintenance Phase
 Need a support plan and a maintenance plan [should be
part of project plan]
 The “No respect” phase
 Less “glamorous”
 Lack of enthusiasm
 Pressure to make fixes quickly
 For “production” problems
 Software can become “hacked” “patchwork” over time
 Finding a support & test platform can be difficult
 Often the forgotten child until fixes are needed
February 22, 2017
SE 477: Lecture 8
73 of 97
Maintenance Phase
 Compare to hardware maintenance
 Not to keep state same; but changes to state
 Fixes and enhancements
 Configuration control is very important
 Fixing the “right” version; tracking branches
 Project management not always carried over
 Smaller team
 Often not a ‘dedicated team’
 Drawn from developers with other main tasks
February 22, 2017
SE 477: Lecture 8
74 of 97
Maintenance Phase
 Contracts, remember those?
 Always consider the maintenance phase here
 Often via a “labor hours” contract
» Time & materials in a “direct” scenario
 Otherwise via “maintenance contract”
» Percentage of software license fee
» Ex: 20% of original cost per year
 Corp. budget if internal/IS projects
 Often annual/monthly “maintenance” allocations
February 22, 2017
SE 477: Lecture 8
75 of 97
Project in Trouble
A student asked: “What if the project cannot meet the
schedule?”
 Level with the sponsor
 Move some features/requirements to a second phase
 Use Resource Leveling Techniques
 Fast tracking – two activities in parallel
 Activity shifting – Move start/end dates forward or backward
 Activity splitting – Break an activity into two or more pieces
 Activity stretching – Use less of a given resource continuously
 Resource substitution – Assign a different resource
 Allocating overtime – Work resources longer
 Re-evaluate tasks: effort and need
February 22, 2017
SE 477: Lecture 8
76 of 97
Project Recovery
How to save a “drowning project”
 3 Approaches
 Cut the size of the software
 Increase process productivity
 Slip the schedule, proceed with damage control
 Opportunity for decisive leadership action
 Not a time to ‘just cut corners’
 Be realistic (not foolish)
 Timing: politically important
 Not too early, not “too” late
February 22, 2017
SE 477: Lecture 8
77 of 97
Project Recovery
 First Steps
 Assess situation
» Is there a hard deadline, what’s negotiable, etc.
 Don’t do what’s been done already
 Ask team what needs to be done
 People Steps
 Morale; focus; re-assign
» Restore morale
• Sacrifice a sacred cow [See note]
– Dress code, off-site, catered meals, etc.
• Cleanup personnel problems
» Focus people’s time
• Remove non-essential work
» Reassign tasks and responsibilities
February 22, 2017
SE 477: Lecture 8
78 of 97
Project Recovery
 Process Steps
 Fix classic mistakes
» Inadequate design, shortchanged activities, etc.?
 Create “Miniature Milestones”
» Small (in day(s)), binary, exhaustive
» Boosts morale: getting things done!
 Track progress meticulously
 Recalibrate after a short time
 Manage risk painstakingly
February 22, 2017
SE 477: Lecture 8
79 of 97
Project Recovery
 Product Steps
 Stabilize the requirements
 Raise the bar on change requests
 Trim the feature set (see feature set control)
» Determine priorities, cut the low ones
 “Take out the garbage”
» Find error-prone modules; re-design
 Get to a known, stable state & build from there
February 22, 2017
SE 477: Lecture 8
80 of 97
Feature Set Control
 Minimal Specification
 Requirements Scrubbing
 Versioned Development
 Effective Change Control
 Feature Cuts
February 22, 2017
SE 477: Lecture 8
81 of 97
Software Project Management
Project Success
February 22, 2017
SE 477: Lecture 8
82 of 97
Think Small
 Keep requirements tight & focused
 One milestone at a time
 Smaller, incremental chunks
 As simple as possible but no simpler
February 22, 2017
SE 477: Lecture 8
83 of 97
Process Spectrum
Too much medicine can kill the patient
Process
Spectrum
Chaos
Bureaucracy
Balance is crucial
February 22, 2017
SE 477: Lecture 8
84 of 97
Miscellaneous
You are not Santa Claus
 Learn to say “No”
 Be polite but firm
 The Value of Versions
 “We will put that in phase 2”
 An Ounce of Prevention
Paralysis
 Analysis Paralysis
 Over-process
 Nothing gets finished
 65% of software professionals have experienced this
 Paralysis Paranoia
 Fear of over-process = process avoidance
February 22, 2017
SE 477: Lecture 8
85 of 97
Miscellaneous
 MBWA – Management by Walk About
 Shows you’re actually involved day-to-day
 Recognizes individuals may say more 1-on-1
 Allows spontaneity
 Finds personnel problems sooner
 Delegate
 Don’t be a “Control Freak”
 You need to be the “hub” but not everything
 Project Home Page
 Give your project an intranet page
 Central repository for project status, documents and other resources
February 22, 2017
SE 477: Lecture 8
86 of 97
Success Metrics
1. On schedule
 Requires good: plan; estimation; control
2. Within budget
 Again: planning, estimation & control
3. According to requirements
 Importance of good requirements
 Perception & negotiation critical
4. High quality. May or may not be same as item 3
Only real measure:
Is the customer happy?
Customer satisfaction!!
February 22, 2017
SE 477: Lecture 8
87 of 97
Success Rates
 By Industry
 Best: Retail
» Tight cost controls in general
 Worst: Government
» Least cost controls
 By Size
 Smaller is better: cost, duration, team
February 22, 2017
SE 477: Lecture 8
88 of 97
Why Do Projects Succeed?
 How to identify a project’s success potential
 What metrics could you look at?
» Project size
» Project duration
» Project team size
 Review assignment 1
February 22, 2017
SE 477: Lecture 8
89 of 97
Why Do Projects Succeed?
 Executive support
 User involvement
 Experienced project manager
 Clear business objectives
 Minimized scope
 Standard software infrastructure
 Firm basic requirements
 Formal methodology
 Reliable estimates
Standish Group “CHAOS 2001: A Recipe for Success”
February 22, 2017
SE 477: Lecture 8
90 of 97
Why Executive Support?
 Top management can help to:
 Secure adequate resources
 Get approval for unique project needs in a timely manner
 Receive cooperation from people throughout the
organization
 Provide leadership guidance
February 22, 2017
SE 477: Lecture 8
91 of 97
State of the Practice in Software Management
 Factors that may influence the success or failure of the
software projects could be:
1. Social Factors
2. Technology
February 22, 2017
SE 477: Lecture 8
92 of 97
State of the Practice in Software Management
Technologies on Unsuccessful
Projects
• No historical software measurement
•
•
•
•
•
•
•
•
•
•
•
Technologies on Successful Projects
data
Failure to use automated estimating tool
Failure to use automated planning tool
Failure to monitor progress or
milestones
Failure to use effective architecture
Failure to use effective development
methods
Failure to use design reviews
Failure to use code inspections
Failure to include formal risk
management
Informal, inadequate testing
Manual design and specification
More than 30% creep in user
requirements
February 22, 2017
•
•
•
•
•
•
•
•
•
•
•
•
•
Accurate software measurement
Early use of estimating tools
Continuous use of planning tool
Formal progress reporting
Formal architecture planning
Formal development methods
Formal design reviews
Formal code inspections
Formal risk management
Formal testing methods
Automated design and specification
Automated configuration control
Less than 10% creep in
requirements
SE 477: Lecture 8
93 of 97
State of the Practice in Software Management
Social Factors on Unsuccessful
Projects
• Excessive schedule pressure
• Executive rejection of estimates
• Severe friction with clients
• Divisive corporate politics
• Poor team communications
• Naïve senior executives
• Project management
malpractice
• Unqualified technical staff
• Generalists used for critical
tasks: quality assurance,
testing, planning, estimating
February 22, 2017
Social factors on Successful
Projects
• Realistic schedule pressure
• Executive understanding of
estimates
• Cooperation with clients
• Congruent management goals
• Excellent team communications
• Experienced senior executives
• Capable Project management
• Capable technical staff
• Specialists used for critical
tasks: quality assurance,
testing, planning, estimating
SE 477: Lecture 8
94 of 97
How to ensure a project fails
 Do the same things you did on the last project. Over and over and over.
 Don't listen to your experts. After all the last project worked out okay
(mostly)
 Don't measure progress with metrics. The only thing that counts is "did
you meet the delivery date?".
 Set delivery dates with the customer but not with the developers.
Developers can meet any schedule we ask for.
 Don't use new tools. Keep using the ones we used ten, twenty years
ago.
 Spend your time making sure people do it your way.
 Office politics and vendettas are more important than the project.
February 22, 2017
SE 477: Lecture 8
95 of 97
Next Class
Topic:
 Miscellaneous:
» Agile Project management
» Project management anti-patterns;
Reading:
 See reading list
February 22, 2017
SE 477: Lecture 8
96 of 97
Journal Exercises
Choose one:
1. Thoughts on Post Project Reviews: do they really help, does
an organization really learn from its mistakes?
2. Turnover and migration: horror stories and things that can
go wrong
3. Support: just what is this about. More than help desks?
February 22, 2017
SE 477: Lecture 8
97 of 97