SPM Tutorial King Khaled University

King Khalid University Academic Year : 2015/2016
Department of Computer Science Semester 1

Subject : Project Management Instructor: Dr Yessine HADJ KACEM
Chapter 1: Exercises
Q1: Cite the different success criteria of a software project
Deliver the software to the customer at the agreed time.

Keep overall costs within budget.
Deliver software that meets the customers requirements.
Maintain a happy and well-functioning development team
Q2: Cite the different elements that can be affect by a risk
A risk is a probability that some adverse circumstance will occur
Project risks affect schedule or resources

Product risks affect the quality or performance of the software being developed
Business risks affect the organization developing or procuring the software.
Q3: Present the different phases of risk management process
Risk identification: Identify project, product and business risks

Risk analysis: Assess the likelihood and consequences of these risks
Risk planning: Draw up plans to avoid or minimize the effects of the risk
Risk monitoring: Monitor the risks throughout the project
Q4: How risk can be planned?
Consider each risk and develop a strategy to manage that risk.

Avoidance strategies: The probability that the risk will arise is reduced
Minimization strategies: The impact of the risk on the project or product will be reduced
Contingency plans: If the risk arises, contingency plans are plans to deal with that risk
Q5: Cite some risk indicators
Technology: Late delivery of hardware or support software many reported technology

problems.
People: Poor staff morale poor relationships amongst team members high staff turnover.
Organizational: Organizational gossip lack of action by senior management.
Tools: Reluctance by team members to use tools complaints about CASE tools demands for
higher-powered workstations.
Requirements: Many requirements change requests customer complaints.
Estimation: Failure to meet agreed schedule failure to clear reported defects.
Q6: How risk can be monitored?
Assess each identified risks regularly to decide whether or not it is becoming less or more
probable
Also assess whether the effects of the risk have changed
Each key risk should be discussed at management progress meetings
PERT DIAGRAMS & CPM
Project Scheduling
1 Project Scheduling Objectives
Phases of Project Scheduling
PERT Diagrams & Dummy Activities
CPM Critical Path Method
Software Project Management
PROJECT SCHEDULING
It is part of project management within the Planning phase of
the Systems Development Life Cycle.
Project Scheduling: Allocate resources to execute all activities
in the project.
Project: Set of activities or tasks with a clear beginning and

ending points. The amount of available resources (time,
personnel and budget) to carry out the activities is usually
limited. 2

PROJECT SCHEDULING
A project is a series of activities directed to accomplishment
of a desired objective.
Plan your work first..then

work your plan

PROJECT SCHEDULING : GANTT DIAGRAM
Originated by
H.L.Gantt in 1918
Advantages Limitations
- Gantt charts are quite commonly - Do not clearly indicate details regarding
used. They provide an easy graphical the progress of activities
representation of when activities - Do not give a clear indication of
(might) take place. interrelation ship between the separate 4
activities
PROJECT SCHEDULING
Objectives:
Establish beginning, ending and duration of each activity in the
project.
Calculate overall completion time of the project given the
amount of usually limited resources.
Determine the critical path and its duration.
Determine the slack time for all non-critical activities and the
whole project.
Guide the allocation of resources other than time such
as staff and budget.

PROJECT SCHEDULING
Phases:
Define activities or tasks according to the project objectives.
A task is an individual unit of work with a clear beginning and a clear
end.
Identify precedence relationships or dependencies
Estimate time required to complete each task.
Draw an activity-on-arrow PERT diagram inserting dummy activities if
required.
Apply CPM to calculate earliest and latest starting times, earliest and
latest completion times, slack times, critical path etc.
Construct a GANTT chart.
Reallocate resources and resolve if necessary.
Continuously monitor/revise the time estimates along the project
duration. 6

PROJECT SCHEDULING
Phases:
Define activities or tasks according to the project objectives.
A task is an individual unit of work with a clear beginning and a clear
end.
Identify precedence relationships or dependencies
Estimate time required to complete each task.
Draw an activity-on-arrow PERT diagram inserting dummy activities if
required.
Apply CPM to calculate earliest and latest starting times, earliest and
latest completion times, slack times, critical path etc.
Construct a GANTT chart.
Reallocate resources and resolve if necessary.
Continuously monitor/revise the time estimates along the project
duration. 7

PERT DIAGRAMS
Program Evaluation and Review Technique
It is a network model that allows for randomness in activity
completion times.
Tool used to control the length of projects.
PERT was developed in the late 1950s for the US Navys
Polaris Project.
First used as a management tool for military projects
Adapted as an educational tool for business managers
It has the potential to reduce both the time and cost required
to complete a project.

PERT DIAGRAMS
A F
1 2 5 6
Single start Single finish

node node
9

PERT DIAGRAMS
Activity-on-node diagrams:
Maybe more than one single start and end node
Nodes represent activities
Arrows indicate precedence
Activity-on-arrow diagrams:
One single start and one single end node
Arrows represent activities
Nodes indicate beginning/end of activities
10

PERT DIAGRAMS
Activity-on-node
Activity-on-arrow
11

PERT DIAGRAMS
Some basic rules for Activity on-arrow:
Tasks are represented as arrows
Nodes represent the start and finish points of tasks
There is only one overall start node
There is only one overall finish node
Two tasks cannot share the same start and end node.
B
A D
2 3
C
Tasks B & C share
the same start and
end node 12

DUMMY ACTIVITIES
Sometimes it is necessary to insert dummy activities (duration zero)
in order to maintain the clarity of the diagram and the precedence
relationships between activities.
In activity-on-arrow PERT diagrams, each activity must be uniquely
identifiable by its start and end nodes.
However, sometimes multiple tasks have the same predecessors
and successors.
13

DUMMY ACTIVITIES
Case One
A task should be uniquely identifiable from its start node and finish
node
This means that two or more tasks cannot share the same start
and finish nodes
A D
1 2 3 4
Task D has C
immediate Tasks B and C
predecessors of have the same
B and C start and
finish nodes 14

DUMMY ACTIVITIES
Inserting a dummy activity can ensure that multiple
tasks have different successors.
A B D
1 2 3 5
A new node is A dummy task is

4
inserted to give C inserted to
a different finish preserve the
node to B immediate 15
predecessors of D

DUMMY ACTIVITIES
Case Two
A task should be uniquely identifiable from its start node
and finish node
This also means that a task cannot have more than one start
node and one finish node
In other words two different arrows cannot represent the
same task.

DUMMY ACTIVITIES
Possible Solution One
One option would be to insert activity E as shown below, but this
changes the precedence of E and provokes that D and E share both
start and end nodes.
Ending node of task B
and C, but task C has a
precedence ONLY task
C
Task D and E have

same start and end
nodes

DUMMY ACTIVITIES
Possible Solution Two
Another option would be to insert activity E as shown below, but
this provokes C to have two different end nodes.
Two ending nodes for

Task C

DUMMY ACTIVITIES
Correct Solution!
The solution is to insert a dummy task so that the precedence of E
is preserved and activity C remains uniquely identifiable.

CPM CRITICAL PATH METHOD
It is determined by adding the times for the activities in each
sequence.
CPM determines the total calendar time required for the project.
If activities outside the critical path speed up or slow down (within
limits), the total project time does not change.
The amount of time that a non-critical activity can be delayed
without delaying the project is called slack-time.
20

ET Earliest node time for given activity duration and precedence
relationships
LT Latest node time assuming no delays
ES Activity earliest start time

LS Activity latest start time
EF Activity earliest finishing time
LF Activity latest finishing time
Slack Time Maximum activity delay time 21

Step 1. Calculate ET for each node.
For each node i for which predecessors j are labelled with ET(j), ET(i) is
given
by:
ET(i)= maxj [ET(j)+ t(j,i)]
where t(j,i) is the duration of task between nodes (j,i).
Step 2. Calculate LT for each node.

For each node i for which successors j are labelled with LT(j), LT(i) is given
by:
LT(i)= minj [LT(j) t(i,j)]
where t(j,i) is the duration of task between nodes (i,j). 22

1 5
C(7)
3 4
23

1 5
C(7)
3 4
24

1 5
4 C(7)
3 4
25

1 5
4 C(7) 11
3 4
26

3
13
2
1 5
4 C(7) 11
3 4
27

3
13
8
2
1 5
4 C(7) 11
3 4
28

3
13
max
8
2
1 5
4 C(7) 11
3 4
29

0 13
1 5
4 C(7) 11
3 4
30

0 13 13
1 5
4 C(7) 11
3 4
31

0 13 13
1 5
4 C(7) 11 11
3 4
32

3 8
0 13 13
1 5
4 C(7) 11 11
3 4
33

3 8
0 13 13
1 5
4 4 C(7) 11 11
3 4
34

3 8
5
0 13 13
1 5
4 4 C(7) 11 11
3 4
35

3 8
5
0
2
0 13 13
1 5
4 4 C(7) 11 11
3 4
36

3 8
5 min
0
2
0 13 13
1 5
4 4 C(7) 11 11
3 4
37

3 8
0 0 13 13
1 5
4 4 C(7) 11 11
3 4
38

An activity with zero slack time is a critical activity and
cannot be delayed without causing a delay in the whole
project.
39

Step 3. Calculate processing times for each activity.
For each activity X with start node i and end node j:
ES(X) = ET(i)
EF(X) = ES(X) + t(X)
LF(X) = LT(j)
LS(X) = LF(X) t(X)
Slack Time (X) = LS(X) ES(X) = LF(X) EF(X)
Where t(X) is the duration of activity X.
An activity with zero slack time is a critical activity and cannot be

delayed without causing a delay in the whole project.
40

Step 3. Calculate processing times for each activity.
Task Duration ES EF LS LF Slack Critical Task
A 3 0 3 5 8 5 No
B 4 0 4 0 4 0 Yes
C 7 4 11 4 11 0 Yes
D 5 3 8 8 13 5 No
E 2 11 13 11 13 0 Yes
Reading: (Kendall&Kendall, chapter 3), (Dennis &Wixom, chapter 3) 41

3 8
0 0 13 13
1 5
4 4 C(7) 11 11
3 4
42

King Khalid University
Academic Year : 2015/2016
Department of Computer Science
Software Tasks Scheduling
Exercise 1:
1. Draw the PERT Diagram related to the following tasks
2. Draw the GANTT Diagram related to the following tasks
Tasks Duration Constraints
A 1
B 5 C
C 10 A
D 5 C
E 3 C
F 4 B and D
G 2 E and F
H 1 G
PERT DIAGRAM
GANTT DIAGRAM
-1-
Exercise 2:
Tasks and Duration Constraints

A: (30 min) B after A
B : (90 min) C and F after B
C : (30 min) E after D
D : (10 min) G after F
E : (10 min) H after C, G and E
F: (30 min)
G : (60 min)
H : (10 min)
-2-
Exercise 3:
Task Duration
-3-
King Khalid University
Calculateurs Temps
College Rel Science
of Computer
Project Management
Tutorial 4: Project Cost Estimation
Dr Yessine HADJ KACEM
yaalhaj@kku.edu.sa
Reference SEG3300 A&B W2004 R.L. Probert
KKU 2015/2016 1436/1437 1

Calculateurs Temps Rel
Motivation
The software cost estimation provides:
the vital link between the general concepts and

techniques of economic analysis and the particular
world of software engineering.
Software cost estimation techniques also provides

an essential part of the foundation for good software
management.
KKU 2015/2016 1436/1437 2

Cost of a project
The cost in a project is due to:

due the requirements for software, hardware and human
resources
the cost of software development is due to the human
resources needed
most cost estimates are measured in person-months (PM)
KKU 2015/2016 1436/1437 3

Software Cost Estimation
KKU 2015/2016 1436/1437 4

Introduction to COCOMO models
The COstructive COst Model (COCOMO) is the most

widely used software estimation model in the world.
The COCOMO model predicts the effort and duration

of a project based on inputs relating to the size of
the resulting systems and a number of "cost drives"
that affect productivity.
KKU 2015/2016 1436/1437 5

Effort
Effort Equation
PM = C * (KDSI)n (person-months)
where PM = number of person-month (=152 working hours),
C = a constant,
KDSI = thousands of "delivered source instructions" (DSI)

and
n = a constant.
KKU 2015/2016 1436/1437 6

Productivity
Productivity equation
(DSI) / (PM)
where PM = number of person-month (=152 working hours),
DSI = "delivered source instructions"
KKU 2015/2016 1436/1437 7

Schedule
Schedule equation
TDEV = C * (PM)n (months)
where TDEV = number of months estimated for software

development.
KKU 2015/2016 1436/1437 8

Average Staffing
Average Staffing Equation

(PM) / (TDEV) (FSP)
where FSP means Full-time-equivalent Software Personnel.
KKU 2015/2016 1436/1437 9

COCOMO Models
COCOMO is defined in terms of three different

models:
the Basic model,
the Intermediate model, and
the Detailed model.
The more complex models account for more factors

that influence software projects, and make more
accurate estimates.
KKU 2015/2016 1436/1437 10

The Development mode
the most important factors contributing to a project's

duration and cost is the Development Mode
Organic Mode: The project is developed in a familiar, stable
environment, and the product is similar to previously
developed products. The product is relatively small, and
requires little innovation.
Semidetached Mode: The project's characteristics are

intermediate between Organic and Embedded.
KKU 2015/2016 1436/1437 11

The Development mode
the most important factors contributing to a project's

duration and cost is the Development Mode:
Embedded Mode: The project is characterized by tight,
inflexible constraints and interface requirements. An
embedded mode project will require a great deal of
innovation.
KKU 2015/2016 1436/1437 12

Cost=SizeOfTheProject x Productivity
Cost Estimation Process
KKU 2015/2016 1436/1437 13

Cost Estimation Process
Effort
Size Table
Development Time
Lines of Code
Estimation Process
Number of Use Case Number of Personnel
Function Point Errors
KKU 2015/2016 1436/1437 14

Project Size - Metrics
1. Number of functional requirements
2. Cumulative number of functional and non-functional requirements
3. Number of Customer Test Cases
4. Number of typical sized use cases
5. Number of inquiries
6. Number of files accessed (external, internal, master)
7. Total number of components (subsystems, modules, procedures, routines,
classes, methods)
8. Total number of interfaces
9. Number of System Integration Test Cases
10. Number of input and output parameters (summed over each interface)
11. Number of Designer Unit Test Cases
12. Number of decisions (if, case statements) summed over each routine or
method
13. Lines of Code, summed 2015/2016
KKU over each routine or method 1436/1437 15
Project Size Metrics(.)
Availability of Size Estimation Metrics:
Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13
KKU 2015/2016 1436/1437 16

Function Points
STEP 1: measure size in terms of the amount of

functionality in a system. Function points are computed
by first calculating an unadjusted function point count
(UFC). Counts are made for the following categories
External inputs those items provided by the user that describe
distinct application-oriented data (such as file names and menu
selections)
External outputs those items provided to the user that generate
distinct application-oriented data (such as reports and messages,
rather than the individual components of these)
KKU 2015/2016 1436/1437 17
Function Points(.)
External inquiries interactive inputs requiring a response

External files machine-readable interfaces to other
systems
Internal files logical master files in the system
KKU 2015/2016 1436/1437 18

Function Points(..)
STEP 2: Multiply each number by a weight factor,

according to complexity (simple, average or
complex) of the parameter, associated with that
number. The value is given by a table:
KKU 2015/2016 1436/1437 19

Function Points(...)
STEP 3: Calculate the total UFP (Unadjusted

Function Points)
STEP 4: Calculate the total TCF (Technical
Complexity Factor) by giving a value between 0 and
5 according to the importance of the following
points:
KKU 2015/2016 1436/1437 20

Function Points(....)
Technical Complexity Factors:

1. Data Communication
2. Distributed Data Processing
3. Performance Criteria
4. Heavily Utilized Hardware
5. High Transaction Rates
6. Online Data Entry
7. Online Updating
8. End-user Efficiency
9. Complex Computations
10. Reusability
11. Ease of Installation
12. Ease of Operation
13. Portability
14. Maintainability
KKU 2015/2016 1436/1437 21

Function Points(.....)
STEP 5: Sum the resulting numbers too obtain DI

(degree of influence)
STEP 6: TCF (Technical Complexity Factor) by given
by the formula
TCF=0.65+0.01*DI
STEP 6: Function Points are by given by the formula

FP=UFP*TCF
KKU 2015/2016 1436/1437 22

Example
KKU 2015/2016 1436/1437 23

Example (.)
KKU 2015/2016 1436/1437 24

Example (..)
Technical Complexity Factors:

1. Data Communication 3
2. Distributed Data Processing 0
3. Performance Criteria 4
4. Heavily Utilized Hardware 0
5. High Transaction Rates 3
6. Online Data Entry 3
7. Online Updating 3
8. End-user Efficiency 3
9. Complex Computations 0
10. Reusability 3
11. Ease of Installation 3
12. Ease of Operation 5
13. Portability 3
14. Maintainability 3
DI =36(Degree of Influence)
KKU 2015/2016 1436/1437 25

Example ()
Function Points
FP=UFP*(0.65+0.01*DI)= 55*(0.65+0.01*36)=55.55
That means the is FP=55.55
KKU 2015/2016 1436/1437 26

Relation between LOC and FP
Relationship:
LOC = Language Factor * FP
where
LOC (Lines of Code)
FP (Function Points)
KKU 2015/2016 1436/1437 27

Relation between LOC and FP(.)
Assuming LOCs per FP for:

Java = 53,
C++ = 64
aKLOC = FP * LOC_per_FP / 1000
It means for the SpellChekcer Example: (Java)
2015/2016
KKU
LOC=55.55*53= 2944.15 LOC or 2.94 KLOC1436/1437 28
Effort Computation
The Basic COCOMO model computes effort as a

function of program size. The Basic COCOMO
equation is:
E = aKLOC^b
Effort for three modes of Basic COCOMO.

Mode a b
Organic 2.4 1.05

Semi- 3.0 1.12
detached
Embedded 3.6 1.20
KKU 2015/2016 1436/1437 29

Effort Computation
The intermediate COCOMO model computes effort

as a function of program size and a set of cost
drivers. The Intermediate COCOMO equation is:
E = aKLOC^b*EAF
Effort for three modes of intermediate COCOMO.

Mode a b
Organic 3.2 1.05

Semi- 3.0 1.12
detached
Embedded 2.8 1.20
KKU 2015/2016 1436/1437 30

Effort computation(.)
Effort Adjustment Factor
Cost Driver Very Low Nominal High Very Extra
Low High High
Required Reliability .75 .88 1.00 1.15 1.40 1.40
Database Size .94 .94 1.00 1.08 1.16 1.16
Product Complexity .70 .85 1.00 1.15 1.30 1.65
Execution Time Constraint 1.00 1.00 1.00 1.11 1.30 1.66
Main Storage Constraint 1.00 1.00 1.00 1.06 1.21 1.56
Virtual Machine Volatility .87 .87 1.00 1.15 1.30 1.30
Comp Turn Around Time .87 .87 1.00 1.07 1.15 1.15
Analyst Capability 1.46 1.19 1.00 .86 .71 .71
Application Experience 1.29 1.13 1.00 .91 .82 .82
Programmers Capability 1.42 1.17 1.00 .86 .70 .70
Virtual machine Experience 1.21 1.10 1.00 .90 .90 .90
Language Experience 1.14 1.07 1.00 .95 .95 .95
Modern Prog Practices 1.24 1.10 1.00 .91 .82 .82
SW Tools 1.24 1.10 1.00 .91 .83 .83
Required Dev Schedule 1.23 1.08 1.00 1.04 1.10 1,10
KKU 2015/2016 1436/1437 31

Effort Computation (..)
Total EAF = Product of the selected factors
Adjusted value of Effort: Adjusted Person

Months:
APM = (Total EAF) * PM
KKU 2015/2016 1436/1437 32

Example
KKU 2015/2016 1436/1437 33

Software Development Time
Development Time Equation Parameter Table:
Parameter Organic Semi- Embedded

detached
C 2.5 2.5 2.5
D 0.38 0.35 0.32
Development Time, TDEV = C * (APM **D)
Number of Personnel, NP = APM / TDEV
KKU 2015/2016 1436/1437 34

Distribution of Effort
A development process typically consists of the

following stages:
- Requirements Analysis
- Design (High Level + Detailed)
- Implementation & Coding
- Testing (Unit + Integration)
KKU 2015/2016 1436/1437 35

Distribution of Effort (.)
The following table gives the recommended percentage

distribution of Effort (APM) and TDEV for these stages:
Percentage Distribution of Effort and Time Table:

Req Design, Implementation Testing
Analysis HLD + DD
Effort 23% 29% 22% 21% 100%
TDEV 39% 25% 15% 21% 100%
KKU 2015/2016 1436/1437 36

Error Estimation
Calculate the estimated number of errors in your design, i.e.total errors found
in requirements, specifications, code, user manuals, and bad fixes:
Adjust the Function Point calculated in step1
AFP = FP ** 1.25
Use the following table for calculating error estimates
Error Type Error / AFP

Requirements 1
Design 1.25
Implementation 1.75
Documentation 0.6
Due to Bug Fixes 0.4
KKU 2015/2016 1436/1437 37
Software Cost Estimation
Exercise:
Consider software project with the following inputs and outputs.
Users Inputs (Simple) 4

Users Outputs (Simple) 3
User Requests (Simple) 3
Files (Simple) 2
External Interfaces (Simple) 2
Weight factors are represented in the table below:
Parameter Simple Average Complex

Users Inputs 3 4 6
Users Outputs 4 5 7
User Requests 3 4 6
Files 7 10 15
External Interfaces 5 7 10
Q1: Calculate UFP (Unadjusted Function Points)
UFP=4*3+3*4+3*3+2*7+2*5=12+12+9+14+10=57
Q2: Consider the Technical Complexity Factors presented in the table below
1 Data Communication 3
2 Distributed Data Processing 2
3 Performance Criteria 0
4 Heavily Utilized Hardware 2
5 High Transaction Rates 3
6 Online Data Entry 4
7 Online Updating 2
8 End-user Efficiency 4
9 Complex Computations 2
10 Reusability 2
11 Ease of Installation 3
12 Ease of Operation 2
13 Portability 3
14 Maintainability 1
Calculate the Degree of Influence DI

DI= 3+2+...+3+1=33
Q3: Calculate the Function Points
FP=UFP*(0.65+0.01*DI)=57*(0.65+0.01*33)= 55.86
Q4: Assuming that this software is written in JAVA and the LOCs per FP for java is equal to
53, calculate the LOC and the qKLOC.
LOC= FP * LOC_per_FP = 55.86*53= 2960.58
qKLOC = FP * LOC_per_FP /1000=2.96058

Quality Management: Code Inspection
Exercise1: Inspect the following code and find the errors

int factorial(int n) f must be initialized at 1
{
int f; f is long not int
while (n >= 0)do
{
Additional step in the loop, n
n = n-1;
f = f*n; start from 1
}
return n; False counter
}
Return f not n
long factorial(int n)
{
long f = 1;
while (n > 0)
{
f = f*n;
n = n-1;
}
return f;
}
Exercise2: Inspect the following code and find the errors

int tab[] ; /*The size of the table is size*/
unsigned sortTest(unsigned size) /*This function checks if a
table is sorted or not*/
{
unsigned i, res;
res=1;
i=1; i starts from 0
while (i<= size && res=1)do
{
if (tab[i] > Tab[i+1]) Comparison ==
res=0;
= affectation
i++;
}
return res; Array bound is size-2
}
int tab[] ; /*The size of the table is size*/

unsigned sortTest(unsigned size){
unsigned i, res;
res=1;
i=0;
while (i<= size-2 && res==1)do
{
if (tab[i] > Tab[i+1])
res=0;
i++;
}
return res;
}
Software Testing: Defect Testing
Overview
Defect Testing
The goal of defect testing is to discover defects in programs.

A successful defect test is a test that causes a program to behave in an
anomalous way.
Tests show the presence, not the absence, of defects.
Defect testing
Black box vs. white box
Equivalence partitions
Path testing
Black box
An approach to testing where the program is considered as a black box (i.e.,

one cannot see inside of it)
The program test cases are based on the system specification, not the internal
workings (e.g., algorithms) of the program.
Test planning can begin early in the software process.
Equivalence partitions
Input data and output results often fall into different classes where all members of a
class are related.
Each of these classes is an equivalence partition where the program behaves in an

equivalent way for each class member.
Test cases should be chosen from each partition.
Exercise1:
Write a C function that allows you to calculate the minimum value in a
given array.
int minimum(int t[], unsigned n)
{
unsigned i;
int min;
for(min=t[0],i=1;i<n;i++)
if(t[i]<min)
min=t[i];
return min;
}
Write a C function that allows you to test the previous function knowing
that the minimum can be in the begin, in the middle or in the end of a table
#include <stdio.h>
#include <assert.h>
void main()
{
/*Create table in which the minimum is in the begin*/
int begin[5]={-1,2,0,14,5};
/* Create table in which the minimum is in the middle */
int middle[5]={15,2,0,3,1};
/* Create table in which the minimum is in the end */
int end[5]={7,3,2,14,1};
assert(minimum(begin,5)==-1);
assert(minimum(middle,5)==0);
assert(minimum(end,5)==1);
}
Exercise2:
Elaborate some data test that allows you to test a program which search a
number in a set of sorted values
Correction
Array T
{True, false}
Array size n Binary search
Value v
Two classes of equivalence can be considered
Class 1: V in T (positive issue)

Class2: V not in T (negative issue)
Class 1: V in T (positive issue)
Ordinary case: DT 1 : (20, {10,15,17,20,24,116})
Boundary cases
DT 2 : (10, {10,15,17,20,24,116})
DT 3 : (15, {10,15,17,20,24,116})
DT 4 : (24, {10,15,17,20,24,116})
DT 5 : (116, {10,15,17,20,24,116})
Class2: V not in T (negative issue)
Ordinary case: DT6 = (18, {10,15,17,20,24,116})
Boundary cases
DT 7 : (8, {10,15,17,20,24,116}) v < the value in the first index
DT 8 : (200, {10,15,17,20,24,116}) v > the value in the last index
DT 9 : (12, {10,15,17,20,24,116}) v is between the second and the first value
DT 10 : (40, {10,15,17,20,24,116}) v is between the before last and the last value
#include <stdio.h>
#include <assert.h>
void main()
{
/*Create a table for test*/
int DT[6]= {10,15,17,20,24,116};
/*we suppose that we have a function named binary_search wich

returns the index of a value v. When the value does not exist, it
returns -1*/
assert(binary_search(DT, 6, 20) ==3);
assert(binary_search(DT, 6,18) ==-1);
assert(binary_search(DT, 6, 8) ==-1);
}

SPM Tutorial King Khaled University

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SPM Tutorial King Khaled University

Caricato da

Copyright:

Formati disponibili

King Khalid University Academic Year : 2015/2016

Department of Computer Science Semester 1

Q1: Cite the different success criteria of a software project

Deliver the software to the customer at the agreed time.

Q2: Cite the different elements that can be affect by a risk

A risk is a probability that some adverse circumstance will occur

Project risks affect schedule or resources

Q3: Present the different phases of risk management process

Risk identification: Identify project, product and business risks

Q4: How risk can be planned?

Consider each risk and develop a strategy to manage that risk.

Q5: Cite some risk indicators

Technology: Late delivery of hardware or support software many reported technology

Q6: How risk can be monitored?

Project: Set of activities or tasks with a clear beginning and

Software Project Management

Plan your work first..then

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Single start Single finish

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

A new node is A dummy task is

Software Project Management

Software Project Management

Task D and E have

Software Project Management

Two ending nodes for

Software Project Management

Software Project Management

Software Project Management

ES Activity earliest start time

Software Project Management

where t(j,i) is the duration of task between nodes (j,i).

Step 2. Calculate LT for each node.

LT(i)= minj [LT(j) t(i,j)]

where t(j,i) is the duration of task between nodes (i,j). 22

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Software Project Management

Where t(X) is the duration of activity X.