Professional Documents
Culture Documents
Software Project Slides
Software Project Slides
DEFINITION
S:
“A finite endeavor having specific start and completion
dates undertaken to create a quantifiable deliverable.”
“Unique process, consisting of a set of coordinated and
controlled activities with start and finish dates,
undertaken to achieve an objective conforming to
specific requirements, including constraints of time, cost
and resources”
4
SIMILAR, BUT WITH THE FOLLOWING
CHARACTERISTICS:
Invisibility
Complexity
Flexibility
5
Examp e Activities
PHASES
6
DISTINGUISHING DIFFERENT TYPES OF PROJECT IS
IMPORTANT AS DIFFERENT TYPES OF TASK NEED
DIFFERENT PROJECT APPROACHES E.G.
7
SOFTWARE DEVELOPMENT PACKAGE
IMPLEMENTATION SYSTEM ENHANCEMENT
SYSTEMS MIGRATION
Infrastructure implementation
8
SIMILAR TO OTHER ‘CONSTRUCTION’ PROJECTS
9
QUICKER AND CHEAPER THAN BUILDING A SYSTEM MAIN
DIFFICULTIES:
11
MAIN
ISSUES:
◦ Intangibility of the ‘product’
◦ Difficult to estimate realistically
◦ Shifting the scope of the project.
12
MOVING EXISTING SYSTEM TO NEW PLATFORM.
USERS JUDGE SUCCESS BY LACK OF INTERRUPTIONS.
MAY INVOLVE SOME RETRAINING OF USERS.
MAY ALSO INVOLVE SOME SOFTWARE DEVELOPMENT
FOR INTERFACES.
13
INSTALLATION OF HARDWARE AND/OR
COMPUTER SUITES
14
THIS INVOLVES THE
FOLLOWING ACTIVITIES:
Planning – deciding what is to be done
Organizing – making arrangements
Staffing – selecting the right people for the job
Directing – giving instructions
Monitoring – checking on progress
Controlling – taking action to remedy hold-ups
Innovating – coming up with solutions when
problems emerge
Representing – liaising with clients, users,
developers and other stakeholders 15
ANSWERING THE QUESTION ‘WHAT DO WE HAVE
TO DO TO HAVE A SUCCESS?’
17
INFORMALLY, THE OBJECTIVE OF A PROJECT CAN
The projectBYwill
BE DEFINED be regarded
COMPLETING as a
THE STATEMENT:
success if………………………………..
18
THESE ARE STEPS ALONG THE WAY TO ACHIEVING THE
OBJECTIVE. INFORMALLY, THESE CAN BE DEFINED BY
COMPLETING THE SENTENCE…
Objective X will be achieved
IF the following goals are all achieved
A……………
B……………
C…………… etc
19
OFTEN A GOAL CAN BE ALLOCATED TO AN INDIVIDUAL.
INDIVIDUAL
ObjectiveMAY HAVE
– user THE CAPABILITY
satisfaction OF ACHIEVING
with software product
GOAL, BUT NOT THE OBJECTIVE ON THEIR OWN E.G.
Analyst goal – accurate requirements
R elevant , the objective must relevant to the true purpose of the project
18
HOW DO WE KNOW THAT THE GOAL OR
OBJECTIVE HAS BEEN ACHIEVED?
21
THESE ARE PEOPLE WHO HAVE A STAKE OR INTEREST IN
THE PROJECT
IN GENERAL, THEY COULD BE USERS/CLIENTS OR
developers/implementers
22
27
Figure 18.1 Stakeholders and the exchange relationship
Source: Charles W. L. Hill and Gareth R. Jones, Strategic Management: An Integrated Approach, Fifth Edition. Copyright © 2001 by Houghton Mifflin Company. Adapted with permission
BENEFITS OF DELIVERED PROJECT MUST OUTWEIGH
COSTS
Costs include:
-Development
-Operation
Benefits
-Quantifiable
-Non-quantifiable
25
POOR ESTIMATES
30
1.1 IDENTIFY OBJECTIVES AND MEASURES OF
EFFECTIVENESS
40
System products
Module products
Management products
41
42
PRODUCT
IDENTITY
Description - what Relevant standards
is it? Quality criteria
Derivation - what is
it based on?
Composition - what
does it contain?
Create a PD for
Format
‘test data’
43
PRODUCT FLOW
DIAGRAM
44
Identify the activities needed to create each
product in the PFD
More than one activity might be needed to
create a single product
Hint: Identify activities by verb + noun but
avoid ‘produce…’ (too vague)
Draw up activity network
45
Design Code
module A module A
Design Code
module A module A
46
Design Code
module C module C
5.1 CARRY OUT BOTTOM-UP
ESTIMATES
◦ distinguish carefully between effort and elapsed
time
5.2. Revise plan to create controllable
activities
◦ break up very long activities into a series of
smaller ones
◦ Long activity make a project difficult to control
◦ If an activity involving testing is totake 12w 47
6.1.IDENTIFY AND QUANTIFY RISKS FOR
ACTIVITIES
◦ damage if risk occurs (measure in time lost or
money)
48
6.3 ADJUST OVERALL PLANS AND ESTIMATES
TO TAKE ACCOUNT OF RISKS
◦ e.g. add new activities which reduce risks
associated with other activities
49
7.1 IDENTIFY AND ALLOCATE RESOURCES
TO ACTIVITIES
50
TESTER
TA = testing assistant
Week
MARCH APRIL
commencing
5 12 19 26 2 9 16
Plan testing LT
Select subjects
TA
Design
questionnaire LT
Book machine
TA
Conduct tests
TA
Analyse
LT
results
51
LT
Draft changes
8.1 REVIEW QUALITY ASPECTS OF PROJECT
PLAN
8.2 Document plan and obtain agreement
52