Sen2022 Software Engineering Analysis and Design

SEN2022 SOFTWARE ENGINEERING
ANALYSIS AND DESIGN
CHAPTER 3
Software Project Management
Prof. Dr. M. Alper TUNGA

Syllabus
Course Book:
Eric J. Braude and Michael E. Bernstein, Software Engineering: Modern Approaches, 2ed,
Wiley, ISBN 978-0-471-69208-9, 2011.
Topics Covered in SEN2022:
Introduction to Software Engineering
Software Process Models
Requirements Analysis
Software Design
Feasibility Analysis
Grading:
10% Project Report
10% Project Presentation
40% Midterm Exam
40% Final Exam
The content of these slides including the figures are mostly taken from the course book.
What is Project and Project
Management?
Project is a sequence of unique, complex, and connected
activities having one goal or purpose and that must be
completed by specific time, within budget, and according to
specification.
Project manager is the person responsible for supervising a
project from initiation to conclusion.
Software project management is the process of planning,
organizing and monitoring the development of a software
project from its inception to its completion.
It incorporates a set of tools and techniques during every phase of
development.
3/84
Software project management addresses the following activities to deliver
a qualified, fully accepted software application on time and within budget:
Project organization
Team structure
Project management tools
Risk management
Estimation
Duration and resources
Scheduling
Work plan
Documentation and monitoring
4/84
Measures of Project Success
The IS is acceptable to the customer.
The IS is delivered “on time”.
The IS is delivered “within budget”.
5/84
Software Project Organization
Project – Oriented Organization
Function – Oriented Organization
Matrix Organization
6/84
Project – Oriented Organization
Personnel are organized around the projects of the company.
Employees are dedicated to a single project.
Increases performance
Increases predictability of schedules
Engineers are isolated.
Reduces the amount of reuse
7/84
Project – Oriented Organization ...
8/84
Function – Oriented Organization
Company is organized into groups based on their functions.
Functional managers act as project managers.
Provides clear and responsible decision-making channels
Managers are responsible for multiple projects.
Shifting personnel from one project to another causes a delay
9/84
Function – Oriented Organization ...
10/84
Matrix Organization
A cross between project – and function – oriented organizations.
Employees belong to a functional group (marketing, …) but are
loaned to projects based on their expertise.
Efficient use of resources is the main advantage.
11/84
Matrix Organization ...
12/84
Team Size
A team is a group of people who work closely together on a
daily basis.
Large teams have the advantage of dividing the work into many
parts but the disadvantage of communication that is time
consuming and error prone.
The mythical man – month (by Fred Brooks):
Adding people to a failing project invariably makes matters worse.
The disadvantage of increased communication channels may outweigh
the advantage of division of labor.
13/84
Team Size
N people has N(N-1)/2 communication channels
3 people 3 communication channels
What is the optimal size of a team?
3 – 7 people
14/84
Estimation Methods
The process of estimating project costs start at the inception of a project
and continues even after coding has begun.
Project costs:
Fixed capabilities
Quality level
Schedule
Budget
Estimation methods:
Project size
Duration
Effort
15/84
Project Size Estimation
Two main project size estimation methods:
Lines of Code (LOC) approach
Physical measurement
Function Point (FP) analysis
Structural measurement
16/84
Lines of Code (LOC) Approach
Measures the physical length of the software.
When well defined, it is a simple and reliable measurement.
The most important issue is to define rules in counting lines of
code so that comparisons are valid.
Count of physical lines including blank lines
Count of all lines except blank and comment lines
Count of only executable statements
17/84
Dependent on the technology used to implement the system
Not appropriate for visual programming languages
Not appropriate for non-procedural programming languages
Unit is LOC
KLOC – thousand LOC
NLOC – non-commented LOC
LLOC – logical LOC
18/84
At very early stages of a project, LOC approach does not sound
very useful.
No codes at the beginning
Historical data is important
Successfully completed similar past projects can be found.
Comparisons may be done between present and similar past
projects.
Similarity factors are generated through these comparisons
The LOC information from past projects are used and based on the
similarity factors, a size estimation in terms of LOC can be achieved.
19/84
Function Point (FP) Analysis
Measures the amount of functionality in a system based upon
the system specifications.
A measure for the functional size of a system
Estimation before implementation
Independent of the technology used to implement the system
Unit is FP.
20/84
Analyzes user-level functionality rather than programming-level
functions
A function is equivalent of processing a screen or form on the monitor.
Sources (functional units) affecting functions:
Transactional Functions:
External Inputs (EI)
External Outputs (EO)
External Inquiries (EQ)
Data Functions:
Internal Logical Files (ILF)
External Interface Files (EIF)
21/84
Example: (The Weather Application) The following application
was designed to capture temperature and rainfall by city and
state. There is only one input screen, one file and one report.
Each field on the following input screen can be modified (add,
change or delete). All previous entries viewed by using the
scroll bar.
22/84
Function Point Calculation
Step 1: Identify the functions that the application must have.
Ex: The weather application has only one screen, so it has one
function
23/84
Function Point Calculation ...
Step 2: For each function, identify the external inputs.
EI is an elementary process in which data crosses the boundary
from outside to inside.
Ex: The weather application has add, change and delete buttons that
affect information on a file/database (an ILF)
EI = 3
24/84
Step 3: For each function, identify the external outputs.
EO is an elementary process in which derived data passes across
the boundary from inside to outside.
Additionally, an EO may update a file/database (an ILF).
Ex: The weather application has one report.

EO = 1
25/84
Step 4: For each function, identify the external inquiries.
EQ is an elementary process with both input and output components
that result in data retrieval from one or more ILFs and EIFs.
no updates and no derived data.
If you get data from another application and add it to a file in your
application, this is a combination of get and add (EQ and EI).
Ex: The weather application has one scroll bar which gets data about
previous entries.
EQ = 1
26/84
Step 5: For each function, identify the internal logical files.
A user identifiable group of logically related data that resides entirely
within the application boundary and is maintained through EIs.
Ex: The weather application has one file/database that stores city,
state, temperature, rain fall, and date information.
ILF = 1
27/84
Step 6: For each function, identify the external interface files.
A user identifiable group of logically related data that is used for
reference purposes only.
The EIF is an internal logical file for another application.
Ex: The weather application has no interface file that provides a

communication with another application.
EIF = 0
28/84
Step 7: Specify the functional complexity of each external input
as low, average or high.
The complexity ranking of EIs is based upon two quantities in that
function:
The files updated or referenced by a transaction
FTR – File Type Referenced
Unique user recognizable, non-repetitive fields
DET – Data Element Type
29/84
Step 7: ...
An FTR must be either an ILF and/or EIF.
DETs:
Data Input Fields
Calculated Values or Derived Data that are stored
Error Messages
Confirmation Messages
Recursive fields are only counted as one DET.
Action keys (command buttons such as OK, Next, so on and so forth)
Multiple Action Keys that perform the same function are counted only as
one DET.
30/84
Step 7: ...
Complexity ranking table of EIs:
31/84
Step 7: ...
Ex: The weather application has 3 EIs (add, change, delete buttons)
and each EI has
6 DETs (5 data input fields + 1 multiple action key)
1 FTR (1 file referenced)
Each EI is ranked as LOW.
32/84
Step 8: Specify the functional complexity of each external
output as low, average or high.
The complexity ranking of EOs is based upon two quantities in that
function:
33/84
Step 8: ...
DETs:
Data Input Fields
Error Messages
one DET.
34/84
Step 8: ...
Complexity ranking table of EOs:
35/84
Step 8: ...
Ex: The weather application has one report and the report has
7 DETs (5 fields + 2 calculated values – averages)
0 FTRs
The EO is ranked as LOW.
36/84
inquiry as low, average or high.
The complexity ranking of EQs is based upon two quantities in that
function:
37/84
Step 9: ...
DETs:
Data Input Fields
Error Messages
one DET.
38/84
Step 9: ...
Complexity ranking table of EQs:
39/84
Step 9: ...
Ex: The weather application has one scroll bar and it has
6 DETs (5 data input fields + 1 multiple action key)
1 FTR (1 file referenced)
The EQ is ranked as LOW.
40/84
Step 10: Specify the functional complexity of each internal
logical file as low, average or high.
The complexity ranking of ILFs is based upon two quantities in that
function:
A subgroup of data elements within an ILF
RET – Record Element Type
41/84
Step 10: ...
RETs:
DETs:
Count a DET for each unique user recognizable, nonrecursive field on the ILF.
Fields that are redundant and appear more than one time are only counted
one time.
Count a DET for each piece of data in an ILF that exists because the user
requires a relationship with another ILF to be maintained (key information).
42/84
Step 10: ...
Complexity ranking table of ILFs:
43/84
Step 10: ...
Ex: The weather application has one file/database and it has
5 DETs (5 fields)
1 RETs (single group of data)
The ILF is ranked as LOW.
44/84
interface file as low, average or high.
The complexity ranking of EIFs is based upon two quantities in that
function:
A subgroup of data elements within an EIF
RET – Record Element Type
45/84
Step 11: ...
RETs:
DETs:
Count a DET for each unique user recognizable, nonrecursive field on the ILF.
Fields that are redundant and appear more than one time are only counted
one time.
Count a DET for each piece of data in an ILF that exists because the user
requires a relationship with another ILF to be maintained (key information).
46/84
Step 11: ...
Complexity ranking table of EIFs:
47/84
Step 11: ...
Ex: The weather application has no EIFs.
No ranking for EIF.
48/84
Step 12: Calculate the Unadjusted Funtion Point (UFP).
Use the ratings from the table.
Multiply the total number of each functional unit by the corresponding
complexity rating.
Add the results of these multiplications.
49/84
Step 12: ...
Ex: The weather application has the following UFP.
UFP = (3 * 3) + (1 * 4) + (1 * 3) + (1 * 7)
UFP = 23 FPs
50/84
Step 13: Calculate Value Adjustment Factor (VAF).
Consider the general system characteristics (GSC) given in the table
Assign a weight between 0 and 5 to each GSC
Needs experience in assigning these weights
Compute the total weight.
51/84
52/84
Step 13: ...
Ex: The weather application has VAF = 45 as an assumption.
53/84
Step 14: Calculate the Adjusted Funtion Point (AFP).
AFP = UFP * (0.65 + 0.01 * VAF)
54/84
Step 14: ...
Ex: The weather application has the following AFP.
AFP = 23 * (0.65 + 0.01 * 45)
AFP = 23 * 1.10
AFP = 25.3 FPs ≈ 25 FPs
55/84
Conversion Between FP and LOC
Example:
53 LOC = 1 FP for Java
29 FPs for C# = 1566 LOC in average
56/84
Conversion Between FP and LOC
Use the gearing factors given in the table.
The gearing factor is simply the average number of LOC per FP in the
completed project.
Average is obtained by summing the gearing factors and then
dividing by the number of gearing factors included in that sum.
Median is the data point that lies in the center of an ordered list of
gearing factors.
Low is corresponding to the lowest gearing factor for each
language.
High is corresponding to the highest gearing factor for each
language.
57/84
Effort and Duration Estimation
Estimating Effort and Duration from LOC
COCOMO I
COCOMO II
Estimating Effort and Duration from FP
Engineering Rules
The unit of Effort is person-months.

The unit of Duration is months.
58/84
COCOMO I
COnstructive COst MOdel
The main idea is that the labor required to develop applications
tends to increase faster than the application's size.
Observations show that the duration increases exponentially with
the effort.
After a certain size, additional required effort has only a gradual
lengthening effect on the time it takes to complete the project.
59/84
COCOMO I
Software applications are classified in three different types:
Organic applications are smaller projects with a known
environment and a small experienced team.
Ex: Standalone applications such as non-web-enabled ones.
Semi-detached applications are medium size projects.
Ex: web-enabled application
Embedded applications are integral to hardware-software systems
with tight and inflexible environments.
Ex: antilock braking system
60/84
COCOMO I
61/84
Engineering Rules
62/84
Example
We have a project to develop a web-enabled information system that has 15 simple
and 8 average inputs, 7 simple and 6 average outputs, 3 average and 2 complex
databases, 5 average and 11 complex interfaces, 30 simple and 15 average and 7
complex inquiries.
The system will have the following characteristics with the corresponding
contribution levels:
backup requirement – average, data communications need – significant,
critical performance – essential, on-line data entry requirement – significant,
ease-of-use by the users – significant, online update - essential
It is planned to use Java (60%), PL/SQL (25%) and Perl (15%) in the development
process. (1 FP = 53 LOC for Java, 1 FP = 37 LOC for PL/SQL, 1 FP = 24 for Perl )
Find the duration and the weighted effort needed to complete the project. (Use
weigths as follows: 7 for Engineering Rules and 3 for COCOMO I relations)
63/84
Example
UFP = (15*3+8*4) + (7*4+6*5) + (3*10+2*15)
+ (5*7+11*10) + (30*3+15*4+11*6)
UFP = 77 + 58 + 60 + 145 + 216 = 556 FPs
VAF = 3 + 4 + 5 + 4 + 4 + 5 = 25
AFP = 556 * (0.65 + 0.01 * 25) = 556 * 0.90 = 500.4 FPs
AFP ≈ 500 FPs
A web-enabled IS ==> Average Project
or
size < 500 FPs ==> Simple Project
500FPs <= size < 1000 FPs ==> Average Project
size >= 1000 FPs ==> Complex Project
64/84
Example
Duration = 5000.4 = 12.01 months ≈ 12 months
Staff = 500 / 150 = 3.33 persons ≈ 3 persons
Effort = 3 * 12 = 36 person-months
60% Java:
Size = 500 * 0.60 * 53 = 15900 LOC
25% PL/SQL:
Size = 500 * 0.25 * 37 = 4625 LOC
15% Perl:
Size = 500 * 0.15 * 24 = 1800 LOC
Total LOC = 22325 LOC = 22.3 KLOC
65/84
Example
E = 3.0 * 22.31.12 = 97.10 person-months
E ≈ 97 person-months
D = 2.5 * 970.35 = 12.40 months

D ≈ 12 months
Weighted Effort = (7 * 36 + 3 * 97) / 10 = 54.3 person-months
Weighted Effort ≈ 54 person-months
66/84
Other Estimation Techniques
Object Point (OP) Analysis
An alternative to FP analysis used for a 4GL development
1 GLs: low-level machine languages
Assembly
2 GLs: low-level machine languages
NASM, S1F
3 GLs: high-level machine languages
C, Fortran
4 GLs: database scripts
SQL
5 GLs: visual PLs
Visual Basic
Use-Case Point (UCP) Analysis
Use-Case scenarios
67/84
Scheduling
Schedules are developed to know what to expect, what to do,
and when to do it.
Project estimates are the inputs for constructing project
schedules.
Scheduling tools:
Work Breakdown Structure (WBS)
A graphical tool that shows the hierarchical decomposition of the
project into phases, activities and tasks
A task must be accomplished within 40 working hours.
A task may be broken down to at most six subtasks.
68/84
Scheduling
Scheduling tools: ...
PERT Chart
A graphical network model that shows the interdependencies
between tasks.
GANTT Chart
A bar chart that shows the tasks against a calendar.
Overlapping tasks can be observed clearly.
The bars visualize the percentage completion of tasks.
69/84
70/84
71/84
PERT Chart
72/84
GANTT Chart
73/84
Monitor and Control Progress
Expectations Management
Expectations management matrix
Schedule adjustment
Critical path analysis
74/84
Expectations Management Matrix
A tool used to understand the dynamics and impact of changing
the parameters of a project.
To establish expectations, some priorities are assigned to cost,
schedule, scope and quality.
75/84
Example: Expectations management of the Lunar Project which
is about landing a man on the moon and get him back safely.
Constraints:
Cost: $20 billion
can be increased, if necessary
Schedule: Dec 31, 1969
an important deadline since there is a competition with Russia
Scope and Quality: Land a man on the moon and get him back
safely
76/84
Example: Expectations management of the Lunar Project which
is about landing a man on the moon and get him back safely.
77/84
Critical Path Analysis
Some tasks are more sensitive to schedule delays than others.
Project managers must become aware of the critical path and
slack times for the project.
The critical path is the sequence of tasks with the largest sum
of most likely durations.
Determines the earliest completion time of the project.
The slack time for any noncritical task is the amount of delay
that can be tolerated between starting and completion time of a
task without causing a delay in the entire project.
78/84
Critical path analysis steps:
Step 1: Use intertask dependencies and determine every possible path through
the project.
Step 2: Draw a network diagram
Step 3: Make forward processing on the network diagram.
Evaluate the earliest completion time (T E) of each task.
The longest time needed to complete the task.
Step 4: Make backward processing on the network diagram.
Evaluate the latest completion time (T L) of each task.
The shortest time needed to complete the task.
Step 5: Calculate slack time (ST) for each task
The tasks with zero slack time must be on the critical path.
Step 6: The duration determined at the end is the duration of the project.
79/84
Example: Consider the following case and determine the critical
path and the duration of the given project.
80/84
2 5 8
D=4 D=5.5 D=1
1 4
D=5 D=2
3 6 7
D=6 D=5 D=3
81/84
2 5 8
D=4 D=5.5 D=1
TE=9 TE=18.5 TE=22
1 4
D=5 D=2
TE=5 3 TE=13 6 7
D=6 D=5 D=3
TE=11 TE=18 TE=21
82/84
2 5 8
D=4 D=5.5 D=1
TE=9 TE=18.5 TE=22
1 4
TL=11 TL=21 TL=22
D=5 D=2
TE=5 3 TE=13 6 7
TL=5 TL=13
D=6 D=5 D=3
TE=11 TE=18 TE=21
TL=11 TL=18 TL=21
83/84
2 5 8
D=4 D=5.5 D=1
TE=9 TE=18.5 TE=22
1 4
TL=11 TL=21 TL=22
D=5 D=2
TE=5 3 TE=13 6 7
TL=5 TL=13
D=6 D=5 D=3
TE=11 TE=18 TE=21
TL=11 TL=18 TL=21
ST = 2 for Task#2 ST = 2.5 for Task#5
==> Task#2 and Task#5 are not on the critical path
Critical Path is 1 – 3 – 4 – 6 – 7 – 8
84/84

Sen2022 Software Engineering Analysis and Design

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sen2022 Software Engineering Analysis and Design

Uploaded by

Copyright:

Available Formats

SEN2022 SOFTWARE ENGINEERING

ANALYSIS AND DESIGN

Prof. Dr. M. Alper TUNGA

Ex: The weather application has one report.

Ex: The weather application has no interface file that provides a

Each EI is ranked as LOW.

The EO is ranked as LOW.

The EQ is ranked as LOW.

The ILF is ranked as LOW.

No ranking for EIF.

AFP = UFP * (0.65 + 0.01 * VAF)

AFP = 23 * (0.65 + 0.01 * 45)

AFP = 25.3 FPs ≈ 25 FPs

The unit of Effort is person-months.

D = 2.5 * 970.35 = 12.40 months

Weighted Effort = (7 * 36 + 3 * 97) / 10 = 54.3 person-months

Weighted Effort ≈ 54 person-months

ST = 2 for Task#2 ST = 2.5 for Task#5

==> Task#2 and Task#5 are not on the critical path

You might also like