BACHELOR OF SCIENCE

Joint Honours Computer and

Information System
OXFORD
BROOKES
UNIVERSITY
Coursework Submission Form
Instructions
1. Please complete the form using Capital Letters.
2. Coursework must be submitted through the Service counter and it is the responsibility of
the student to complete the Coursework Submission Log Book
AGNES MEILIANA ( ID: 018800007602; AGNESMEILIANA@YAHOO.COM;+65-990521823; ),
DANIEL NATANAEL (ID: 018800007529; HERE_IM_SEND_ME@YAHOO.COM;+65-81164775 ),
Name of Student: JASON ALERTA OBINA (ID: 018800007777; JAYOBINA@GMAIL.COM;+65-82690003 ),

E-mail Address: Contact No:

Name of Lecturer: Mr. Palaniappan

Student ID: Class Code:

Subject Code: U08784 – SPM Assignment No.: 1 T3 – 2009
No. of pages including Other CD
29 Specifications: 1 enclosed
____
this cover page :
Submission Date: 29-October-2009 Due Date: 29-October-2009
Declaration : Signature :
I declare that this assignment is my original work and that I have
acknowledged any use of published or unpublished works of other people. I
understand that I will be penalized for plagiarism and late submission.

Question Total

Marker
Internal
Moderator
External
Moderator

Marker's Comment:

U08784_QP Page 1 of 1
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 

U08784
SOFTWARE PROJECT MANAGEMENT
Assignment Part I

Group II
Members:
1. Agnes Meiliana - 018800007602
2. Daniel Natanael - 018800007529
3. Jason Alerta Obina - 018800007777

Page | 1  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Table of contents:

1. Introduction --------------------------------------------------------------------------------------- 3
2. Planning --------------------------------------------------------------------------------------- 3 - 11
2.1 Function Requirements
2.2 Assumption
3. Estimation
3.1 Function Point (FP) Analysis ---------------------------------------------------- 12 - 19
3.2 Lines of Code (LOC) Analysis -------------------------------------------------- 20 - 21
3.3 Constructive Cost Module (COCOMO) Estimation -------------------------- 21 - 24
4. Conclusions -------------------------------------------------------------------------------------- 25
5. Appendix ----------------------------------------------------------------------------------- 26 - 27
6. Reference ----------------------------------------------------------------------------------------- 28

Page | 2  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
1. INTRODUCTION
The expansion of technologies in this age has given affect for all human life aspects, including
education examination system. In this assignment, we will discuss about software size
measurement. We will act as staff of Soft Tech Pvt. Ltd and given a role as the project manager
in developing examination system for Informatics Education.
We have a scenario of a software development project about “Informatics Education
Examination” system. So we need to research and prepare information that is required by our
manager in Soft Tech Pvt. Ltd in order to create a final proposal to the customer.
In order to complete our objectives to get an estimation of the system’s size, estimation about the
cost needed to develop the system, estimation on the needed effort, and estimation on the time
duration to complete the development of the system; we will use three standard software
estimation techniques for measuring the size of the software. Therefore, this report will consist of
the workings of three software estimation methods: Function Point (FP) Analysis, Lines of
Code (LOC) Analysis, Constructive Cost Module (COCOMO) Estimation.

2. PLANNING
The current education examination system is still using the manual system to process
examination transactions. All examination transactions are doing in manual system, such as
creating a new student record, assigning student class, etc. Those systems are not efficient,
unsecure, uneasy to use, not reliable and accurate. By computerizing examination system, many
of these tasks can be doing automated and thus saves lot of productivity time.
Those are the reason for Soft Tech Pvt Ltd to make design of the examination system as flexible
to dig out maximum best within the student.

2.1 Function Requirements

After a detailed study of the user requirements; the system is determined to consist of eight
modules based on the functionality. The system context diagrams can be found in the Appendix
for reference. We justify the scenario requirements for system-required modules in each
module’s description, as shown below:
a) Login Module
This is one of the core modules of the system as it is used to allow access to users of the system.
User’s here may refer to the student services officers of the institute’s administrative office,
course lecturers, the top management, and even students. Each user will have a unique login ID
and password, and depending on their job position (for employees only) and hierarchy in the
institute, they will be given different access levels to the system. For example, a student services

Page | 3  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
officer will have access to the Exam Listings screen, but will not have access to the Exam
Grading screen. Lecturers however, will have access to the Exam Grading screen but will not
have access to the Exam Listing screen.
Below is a summarized list of functions that could be performed by users at different levels:
 Confirm student exam listings
 Add, edit and delete student details
 Add, edit and delete course details
 Add, edit and delete examination-listing details
 Insert examination results
 Generate exam entry card
 Generate consolidated reports (reports on student’s performance, etc.)
b) Lecturer Module
This module is mainly used for maintaining details of lecturers of the institute. Details stored
about lecturers include Lecturer ID, name, course unit(s) assigned, contact number etc. It is
mentioned in the scenario description that lecturers will be involved in the examination
invigilation. Therefore, each lecturer will also be assigned an Exam Invigilator ID for the
respective examination they will invigilate.
c) Student Module
This module will be used for maintaining details of students of the institute. Details stored about
a student would include Student ID, Name, Passport/NIC number, Phone number, Email address,
Study type (Full-time/Part-Time), Course ID (to identify what course the student is following),
Unit ID (to identify the units which the student has registered for)
d) Course Module
This module is mainly used for maintaining details of the various courses offered by the institute.
Details on each unit of each course will also be maintained here. Each course will have a unique
Course ID, Name, Awarding University, and its respective Unit ID(s), and Lecturer ID(s).
e) Exam Listing Module
As mentioned in the scenario description, exams are conducted at the end of each semester.
Students will be taking the exam papers for the units they have registered for that respective
semester.
Since there are many exams conducted during the examination period, the system will have to
organize each exam. These exams will be identified by a unique Exam ID, and include other
details such as Exam subject, Semester, Date, Time, and Room number which the exam will be
held in.

Page | 4  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
All students are required to verify their individual exam listing which will be made available to
the students one month before the actual exam date. This exam listing is based on the units the
student had registered for the semester. Here, students will register themselves to sit for the
exams of each unit. However, students will have the option of withdrawing from any exam for
the current semester and be able to re-register for that exam during the next semester. Although,
there are certain limitations as to how many times a student can withdraw from a particular
exam.
After the student has successfully completed the exam registration, an Exam Entry Card will be
generated for that particular student. This card will have a unique Entry Card Number that will
be used to uniquely identify each exam candidate. The card also holds all other information
regarding the exams, which the candidate has registered. These details include Student ID, Exam
ID, Exam subject, Exam Year, Exam Month, Date, Time, and Room number.
f) Exam Result Module – Examination Grading module
This too is one of the core modules of the system as it is used to maintain details of a students’
examination grading, assignment grading, final grading, and the student’s Grade Point Average
(GPA).
As mentioned above, this module is used to maintain information on a student’s grades for each
exam unit. It will also keep track of the number of times a student has withdrawn from a
particular exam unit as well. After a student completes (or withdraws from) an exams, a grade is
assigned to him/her. The grade assigned will be based on the marks achieved for each individual
exam unit. The grade is one of “A+, A, A-, B+, B, B-, C+, C, C-, D+, D, or F” if the student
completes the examination without withdrawing; and the grade “W” is assigned if the student
withdraws instead.
This module is also used to maintain a student’s assignment marks for each unit. After the
system has been updated with the grades of both the assignments and examinations, this module
will then be used to generate the ‘Final Grading’ of students for each unit. The grade is one of
“A+, A, A-, B+, B, B-, C+, C, C-, D+, D, or F” if the student has completed the assignment and
examination without withdrawing; and the grade “W” is assigned if the student has withdrawn
instead.
After the marking of individual scripts are completed, an exam board will be conducted to verify
and validate the student results. This exam board will consist of a group which includes both
external and internal moderators.

Page | 5  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
g) .Attendance Module
This module is mainly used to capture the attendance of students during the examination period.
Students will use their student cards to scan-in their attendance. However, in addition to
scanning-in their cards, students will also be required to sign the attendance list which will be
circulated among students while the exams are in progress, under the supervision of the exam
invigilators. It is only after a student has scanned-in and signed the attendance list that their
attendance will be verified and be marked as present for that relevant exam.
This module will also be used to extract students’ attendance for each unit (each class lecture).
The system will use this information particularly when generating the exam listings for students,
as a student with a low attendance in class will not be allowed to sit for the exam on that
particular unit.
h) Report Generation Module
It is required that the top management be able to generate certain consolidated reports to get an
overview of student’s performance from various courses.
Thus, this module will be used mainly to generate such reports. The types of reports that this
module will generate are:
 Exam Result Slip – allows students to print the result slips for their particular exam
sittings. This slip contains Student ID, Student Name, Unit ID, Unit Name, Exam Grade
and Exam Point. The system will generate this slip automatically after the lecturer enters
student assignment mark and exam mark to be calculated and has approved by
administrator as the Final Exam Mark.
 Student Overall Performance Report – allows the top management to track an individual
student’s performance on the course he/she is currently following.
 Student Overall Pass Rate for individual course units – allows the top management to
track performances on all students (as a whole) of a particular course unit; based on the
grades achieved for that single unit.
i) Reminder Module
This module will be used to send reminders to students; asking them to register for their
individual exam listings. Students will be required to confirm the listings with the student
services officer and whether the exam modules assigned to them by the system is correct. In
addition to reminding students about exam listings, this module will also be used to send
reminders to students regarding the result releases of exams as well.

Page | 6  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
j) Main Menu
Another important part of the system, apart from the core modules listed above would be a User-
friendly navigation environment. It is important to let users perform all the basic functions of the
system, by making those functions available and easily accessible to the users under a single
location. Therefore, this system will consist of a Main Menu, which displays all the functions
that users will be able to perform according to their access privileges. The Main Menu will be
displayed to user only after successful login to the system.
The list below shows what type of modules will be accessible by the different employees,
depending on their access levels:

 Student Service Officers - Student module, Exam listing module, Course module,
Employee module.
 Lecturers - Exam grading module, Attendance module, Profile, Help, Course module.
 Top management - Report generation module
 Administrator – Employee module, Student module, Exam Listing module, Exam Grading
module, Lecturer module, Course module, Attendance module.
 Student – Courses module, Report Generation module, Help module.

2.2 Assumptions

By carefully studying the scenario at hand, and given the limited requirements of the new
system, it was imperative that we conducted some research on similar online systems. Based on
the findings of our research we have established a list of assumptions which will sufficient to let
our team proceed to use the Function Point Analysis, and thereafter help us control the system
development accordingly.
The following is the list of established assumptions of each module:
a) Login Module
Since various employees of different hierarchies will access the system, Login and Access
Control Levels (ACL) will be implemented in order to guide users to their appropriate sections
of the system, and to protect the confidentiality of the data stored in the system (Student records,
exam grades etc).
b) Lecturer Module
Every lecturer of the institute will be involved in examination invigilation. Therefore, it is
assumed that each lecturer will be assigned an Exam Invigilator ID for the respective
examination, which they will be invigilating for.

Page | 7  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Certain lecturers will also be involved in the exam board. These lecturers will represent the
institute as internal moderators, and help the external moderators with the process. Once the
students’ results are validated, the lecturers will then be assigned with the task of entering these
results into the system.
c) Student Module
A student module will be used to maintain details of students as information such as the course
currently being followed, and units registered for the current semester will be needed to generate
the student’s exam listing.
d) Exam Listing Module
Exam listings for the current semester will be out one month before the actual exam date, and all
students are required to verify their individual exam listings. Students will register for exams
based on the units they had registered for that term.
Withdrawal from an exam is permitted, however with the exemption that the applying student
has not already applied for withdrawal for the same unit exam in any previous semesters.
Upon successfully completing exam registration, the system will generate an Exam Entry Card
for that particular student. This Exam Entry Card number is system generated.
Students will use this card as entry proof when sitting for their exams. The card will have a
unique Entry Card Number, which will be used to uniquely identify each exam candidate.
e) Exam Result Module – Examination Grading module
Grades assigned to students will be based on the marks achieved for each individual exam unit.
Depending on the marks, grades assigned will be one of “A+, A, A-, B+, B, B-, C+, C, C-, D+,
D, or F” or “W” for withdrawal from the exam.
However, students are able to apply for withdrawal from an exam to a maximum of one attempt
only. For example, a student that withdraws from an exam unit in this semester must sit for the
same exam unit during the next semester. Failure in doing so will automatically assign an “F”
grade to that student.
Final Grading is calculated based on a weight age factor and varies from unit to unit (This Final
Grade is system generated by using the student’s exam grade and assignment grade).
Finally, this module will be used to compute a student’s Grade Point Average (GPA) for each
exam sitting. Therefore, the system will also perform certain computations using the Final
Grading that a student has been given for each exam unit.

Page | 8  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
The lecturer assigned to each unit exam will act as the internal moderator of the institute, and
therefore he/she will be given access to this module and be able to update the grades of each
student.
f) Course Module
A particular lecturer can be assigned to more than one course. Therefore, it is possible that he/she
will lecture one or more course units. Due to this, under each Unit ID a corresponding Lecturer
ID will be assigned.
g) Report Generation Module
Employees from the top management will be able to login to the system and view certain reports
such as:
 A course unit student passes rate - Percentage of the number of students who have passed
the particular unit.
 A student overall course performance - This report will use the concerning student’s past
examination results along with the GPA and produce an evaluation report on each of the
units taken by that student.
 The student overall pass rate – This report will use the results of all students that belong
to a particular course unit.
h) Attendance Module
The attendance module is used to capture and compute based on the information stored in the
database. Function of database just to stores all data, while the function in the attendance module
is the one doing the work for processing. Details such as Student ID, Name, Date and Time
scanned-in will be retrieved.
The exam invigilator will do verification of student attendance. Students with an attendance rate
less than 75% will not be allowed to register for that particular exam unit.
Help functions will be hardcoded into the system, and therefore remove the necessity of having
an extra storage file.
i) Reminder Module
Reminders for exam listings will be sent to students at least one month before actual
commencement of first exam date.
Reminders for result releases will be sent to students one day after the results have been updated
and grades verified by lecturers.

Page | 9  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
j) Main Menu
Upon the successful login, user will enter to a main menu screen. He/she can access the shown
options list depend on the user’s access level.
k) System In General
 We assume this system use two databases, “Informatics Database” and “Examination
Database”. In order to maintain their updated data, we assume those databases have
connection to each other.
 Help functions are hard coded in the system, thus remove the necessary of having an extra
storage file.
 System configurations of the schedule time to run the reminder module is hard coded in the
system.
 The system is developed by using 4GL default (e.g. Query Languages, Program
Generators, etc ) because the language enables the user to specify conditions and
corresponding actions (the procedural component) while at the same time encouraging the
user to indicate the desired outcome (the nonprocedural component) and then applying its
domain-specific knowledge to fill in the procedural details. This language has 20
SLOC/FP, which will affect the Source Line of Code (SLOC) calculation.
 Existing student payment system for each lesson is done outside the Informatics
Examination System, but it still the part of the system itself.

Page | 10  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
A general overview about the Informatics Education Examination system is shown by the
diagram below:

EI  ILF
EO 
EQ  ILF ILF
 
Student 
Confirm student exam result 
Add, edit, and delete student     
details  Exam Listing  Lecturer 
User  Add, edit, and delete course 
details 
Add, edit, and delete 
examination listing details 
Generate exam entry card 
Insert examination result 
Generate consolidate reports 

 
System 
Process 

 
Course 
Exam Grading 

ILF ILF
Information 
Center Database  EIF 
 
Reminder Attendance 

Examination  ILF 
ILF
Database 

Page | 11  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
3. ESTIMATION
3.1 Function Points Analysis (FPA)
Function Point Analysis is used to measure software size by analyzing the system based on the
list of functions that will be available in the system. In addition to measuring output, Function
Point is extremely useful in estimating projects, managing change of scope, measuring
productivity, and communicating functional requirements.
Calculating the Function Point involves several steps:
Step 1: Identify and count the components of information domain
The list of components will be categorized based on the modules of the system. However, there
might be a possibility that certain components will appear in more than one module, this leading
to counting a single component more than once. Therefore, in order to avoid duplication in the
counting of these components, an extra category named “General” will be created and contain a
list of components that would frequently occur in more than one module.

*Note that the following website was used in order to help us derive the list of components.
http://www.gantthead.com/process/popup.cfm?ID=23594

There are five major components of Function Point, which capture the functionality of the
application as shown below:

a. External Inputs (EIs)

External Input refers to data, which crosses the boundary from outside to inside the system. This
data may come from data input screens, electronically, or from another application. This data can
be either control information or business information. (Here, we identify buttons as input, based
on the information domain reference table found in Appendix 6.2)
List of External Input components:

Complexity 
Module  Components 
Low  Average  High 
OK button       
Cancel button       
General  Edit button       
Save button       
Print button       
Total 5  0  0 
 
Login ID       
Login module 
Password       

Page | 12  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Total 2  0  0 
 
Lecturer ID       
Lecturer Name       
Lecturer module 
Unit ID       
Invigilator ID       
Total 3  2  0 
 
Student ID       
Student Name       
Phone Number       
Email Address       
Student module  Passport Number       
Study Type (Full‐Time/Part‐
     
Time) 
Course ID       
Unit ID [2]       
Total 5  2 (+1)  0 
 
Course ID [2]       
Course Name     
Course module  Awarding University       
Unit ID [3]       
Lecturer ID [2]       
Total 2  0 (+3)  0 
 
Exam ID       
Exam Subject       
Exam Semester     
Date       
Exam Listing module  Time       
Confirmation 
     
(Register/Withdraw) 
Generate Exam Entry Card 
     
button 
Total 7  0  0 
 
Exam Mark       
Withdrawn Attempts       
Exam Grading module 
Assignment Mark       
Final Grade    
Total 3  1  0 
 
Attendance module  Student ID [2]       

Page | 13  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Student Name [2]      
Date [2]       
Time [2]       
Verify Attendance button       
Total 1 (+3)  0 (+1)  0 
 
Student Performance Report 
     
button 
Report Generation module  Attendance Report button       
Final Exam Grade Report 
     
button 
Total 3  0  0 
 
Main Menu  Exam Listing button       
Exam Grading button       
Reports button     
Attendance button       
Lecturer button       
Student button       
Course button       
Total 7  0  0 
 

b. External Outputs (EOs)

External Input refers to data which crosses the boundary from inside to outside the system. The
data creates reports or output files sent to other applications. (Here, we identify screens as output,
based on the information domain reference table found in Appendix 6.2)

List of External Output components:

Module  Components  Complexity 
Low  Average  High 
General  Login screen       
Main Menu screen       
Error report screen       
Total 2  0  1 
 
 Student module  Student details screen       
Student details entry form    
Total 1  1  0 
 
Lecturer module  Lecturer details screen       
Lecturer details entry form       
Total 1  1  0 

Page | 14  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
 
Course module  Course details screen       
Course details entry form       
Total 1  1  0 
 
Exam Listing module  Exam Listing form/sheet       
Exam Entry Card slip       
Exam Timetable       
Total 1  2  0 
 
Exam Grading module  Exam grading screen       
Total 1  0  0 
 
Student examination 
     
attendance sheet 
Attendance module 
Student class attendance 
     
report 
Total 0  2  0 
 
Exam result slip       
Report Generation module  Student performance report       
Unit performance report       
Total 0  3  0 

Exam listing reminder letter       
Reminder module  Exam result release reminder 
     
letter 
Total 2  0  0 
 

c. External Inquiries (EQs)

Through this part, we identify an elementary process with both input and output components that
results in data retrieval from one or more internal logical files and external interface files. (Here,
we identify screens as output, based on the information domain reference table found in
Appendix 6.2)

Page | 15  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
List of External Queries components:

Complexity 
Module  Components 
Low  Average  High 
Selection of Menu screens       
Get Login data       
Get Student data       
General 
Get Lecturer data  
Get Course data       
Get Exam listing data       
Total 1  5  0 
 
Exam Grade module  Get exam grading data       
  Get GPA data       
  Get Final grade data       
Total 1 2  0
 
Attendance module  Get attendance data       
Total 1  0  0 
 
Report Generation module  Get result slip data       
  Get exam grade data        
Total 0  2  0 
 
Reminder module  Get exam listing reminder data  
  Get exam result release data   
Total 1  1  0 
 
Help module  Get Help data       
Total 0  0  1 
 

d. Internal Logical File (ILF)

In this part, we identify internal group of logically related data that resides entirely within the
application boundary and is maintained through External Inputs. (Here, we identify screens as
output, based on the information domain reference table found in Appendix 6.2)
List of Internal Logical File:

Complexity 
ILF 
Low  Average  High 
Student       

Page | 16  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Lecturer      
Course       
Exam Listing      
Exam Grading      
Attendance       
Reminder       
Total  5  2  0 

e. External Interface File (EIF)

We indentify EIF through all machine-readable interfaces and sheet that contains data (e.g.,
student card, attendance sheet) that are used to transmit information to examination system.

List of EIF component:

EIF  Complexity 
Low  Average  High 
Informatics Central database      
Examination database      
Total  2  0  0 

Step 2: Compute the complexity weights of the information domain’s components to get the
Unadjusted Function Point Count

Before calculation of the Unadjusted Function Point Count is done, we are required to identify
the degree of complexity of each component of the information domain.

 
COMPLEXITY WEIGHT FACTORS 

TOTAL 
ITEM  TOTAL  SIMPLE  AVERAGE  COMPLEX 
WEIGHT 

EXTERNAL INPUT (EI)  46  3 x (38)  4 x (5)  5 x (0)  134 

EXTERNAL OUTPUT (EO)  20  4 x (9)  5 x (10)  7 x (1)  93 

EXTERNAL QUERY (EQ)  15  3 x (4)  4 x (10)  6 x (1)  58 

INTERNAL LOGICAL FILE (ILF)  7  7 x (5)  10 x (2)  15 x(0)  55 

EXTERNAL INTERFACE FILE (EIF)  2  5 x (2)  7 x (0)  10 x (0)  10 

Page | 17  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
UNADJUSTED FUNCTION POINT         
350 
COUNT (UFP) 

Table 1.1

Step 3: Tabulate the General System Characteristics (GSC) to generate the Total Degree of
Influence (TDI)
Degree of influence:

0 – No influence 2 – Moderate 4 – Significant

1 – Incidental 3 – Average 5 - Essential

Degree of 
No  Factor  Comments 
Influence 
While a student’s record is updated, there is a possibility that an 
error  could  occur.  Hence,  those  unfinished  transactions  must  be 
Backup and 
1  rolled back. For data protection (from media failure for example),  5 
recovery 
the  backup  copy  of  informatics  database  is  needed  for 
restoration; so that there will be no need for a roll back. 
The  system  consists  of  two  databases;  therefore  it  needs  data 
communication  to  provide  the  rules  and  regulations  that  allow 
Data 
2  computers  with  different  disk  operating  systems,  languages,  4 
communication 
cabling and locations to share resources. Due to these reasons this 
application will support online data collection. 
The  processes  of  this  application  will  be  divided  into  several 
smaller processes in order to help the system work efficiently. The 
Distributed  system consists of many components which will interact with each 
3  4 
processing  other, while this examination system will also rely on distributed 
processing  for  handling  data  occurrences  between  the  two 
databases.  
The  criticality  of  system  performance  is  quite  high  as  users  will 
Performance 
4  rely  heavily  on  the  system  response  and  throughput  in  order  to  4 
critical 
achieve their application objectives.   
Existing operating  There is no existing environment for this system. 
5  0 
environment 
Most of the modules require large amounts of information to be 
6  On‐line data entry  entered  into  the  system  via  on‐line  data  entry,  thus  making  it  5 
essential to the system.   
Input transaction  This  system  requires  transaction  over  multiple  screens  for  the 
7  over multiple  Exam Grading and Result process.  3 
screens 
Master files  The master files updater on‐line will help the administrator keep 
8  4 
updated on‐line  up‐to‐date even the administrator is not in the office. 
9  Information domain  Since  most  transactions  are  updated  over  multiple  files  the  3 

Page | 18  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
values complex  complexity of the system is quite moderate. 
The  system  consists  of  16  inquiries  in  total  and  most  modules 
Internal processing 
10  require  heavy  processing.  Therefore,  the  internal  processing  3 
complex 
complexity is fairly moderate. 
The reusable code design can reduce the cost and time of making 
Code designed for 
11  the project. Beside it will make the user easier to understand how  3 
reuse 
to use the software. Because it likes updating the software itself. 
Conversion /  It  is  assumed  that  there  is  no  existing  system;  hence  there  is  no 
12  installation in  need for any conversions or installations.  0 
design 
Since  the  application  will  be  mainly  used  by  the  administrative 
Multiple 
13  department,  installations  in  multiple  locations  will  not  be  2 
installations 
necessary. 
The  application  itself  must  be  designed  for  easy  to  be  changed, 
Application 
because  if  the  application  hard  it  be  updated  for  short  period 
14  designed for  3 
maybe there will be no problem, but for long period it will be the 
change 
major problem for the application itself. 
Total Degree of   
  43 
Influence (TDI) 

Step 4: Calculate the Complexity Adjustment Factor (CAF)

CAF = 0.65 + (0.01 x TDI)

= 0.65 + (0.01 x 43)
= 0.65 + 0.43
= 1.08

Step 5: Calculate the Final Function Point Count (FPC)

AFP = UFP * CAF

= 350 * 1.08
= 378

Page | 19  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
3.2 Lines of Code (LOC) Analysis

Details  Values
Assumed Productivity (AP)  10 Function Point Per Month
Average Monthly Salary of Employee (SE)  $4,000.00
Average Monthly Salary Divided by Assumed Productivity 
Per Month  SE / AP
Cost Per Function Point (CFP) 

$400.00
Final Function Point Divided by Assumed Productivity FFP 
/ AP
Effort (E) 

37.8 Person – Months
Average Monthly Salary of Employee Multiplied by  Effort

Overall Cost Estimated (OCE)  AP * E

$151,200.00
Final Function Point Multiplied by Standard Value of FP 
for 4GL such as .NET
Estimated Lines Of Code (LOC) 

7560
Overall Cost Divided by Estimated Lines of Code  OCE / 
LOC
Cost per LOC  

$20 
Estimated Effort Divided by Number by Number of  
Assumed Developers

E / 5

37.8 / 5
Project Duration  
5.4

= 7.56

A team of 5 Developers would finish this project in 
approximately 8 months

Page | 20  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Justification for Estimated LOC
Module  Estimate LOC  LOC Per Month $ / LOC  Total Cost ($)  Effort per  Month 
Main Menu  400  175 $15 $6000  2.3
Login  400  175 $20 $8000  2.3
Lecturer  700  175 $20 $14000  4
Student  700  175 $20 $14000  4
Course  700  175 $20 $14000  4
Exam Listing  1100  250 $20 $22000  4.4
Exam Result  600  175 $20 $12000  3.4
Attendance  800  200 $20 $16000  4
Report 
1000  225 $15 $15000  4.4
Generation 
Reminder  1200  250 $25 $30000  4.8
Total  7600      $152,000  37.6

3.3 Constructive Cost Module (COCOMO) Estimation

Step 1: Estimating Software Development Cost Drivers

Under the Software Development there are four classes of attributes that fall into COCOMO
model and these are Product Attributes, Computer Attributes, Personnel Attributes and Project
Attributes. Each of these attributes has several cost drivers and ratings that are specifically rated
from Very Low to Extra High and it used for the development of a software project.

  VL  L  N  H  VH  XH 

LEGEND 
Product attributes  
Very Low  Required software reliability    0.75  0.88  1.00  1.15  1.40   
VL 
L  Low  Size of application database    0.94  1.00  1.08  1.16   

N  Nominal  Complexity of the product     0.70  0.85  1.00  1.15  1.30  1.65

High  Hardware attributes  
H 
VH  Very High  Run‐time performance constraints                 1.00  1.11  1.30  1.66

XH  Extra High  Memory constraints                        1.00  1.06  1.21  1.56

  Virtual machine volatility             0.87  1.00  1.15  1.30   

Computer Turnaround Time    0.87  1.00  1.07  1.15   
Personnel attributes             
Analyst capability   1.46  1.19  1.00  1.19  0.71   

Page | 21  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Software engineer capability   1.29  1.13  1.00  0.91  0.82   
Applications experience   1.42  1.17  1.00  0.86  0.70   
Virtual machine experience     1.21  1.10  1.00  0.90     
Programming language experience   1.14  1.07  1.00  0.95     
Project attributes              
 Modern Programming Practices   1.24  1.10  1.00  0.91  0.82   

Figure 1.0

Step 2: Estimating the value of EAF (Effort Adjustment Factor)

Based on the above chart (Figure 1.0) we must get the value of the overall value of EAF and
therefore must multiply all the multiplier which is rated below and higher than the Nominal
value (effort multiplier of 1.00).
Efforts are rated as follows. All others are nominal to 1.0
Cost Drivers  Level  EAF 
Complexity  High  1.15 
Storage  High  1.08 
Run‐time performance constraints  High  1.11 
Virtual machine volatility  Low  0.87 

EAF = 1.15 * 1.08 * 1.15 * 0.87 = 1.379

Step 3: Estimating the KLOC, Effort, Cost and Duration

COCOMO'81 models depend on the two main equations:

b
 Development effort: Effort = EAF * a * size based on MM - man-month / person
month / staff-month is one month of effort by one person. In COCOMO'81, there are 152
hours per Person month. According to organization this values may differ from the standard
by 10% to 20%.
 Effort and development time (TDEV): TDEV = 2.5 * MM c

Page | 22  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
The coefficients a, b and c depend on the mode of the development. There are three modes of
development:

Development Mode  Project Development 
  Size  Innovation  Deadline/Constraints  Dev. Environment 
Organic  Small  Little  Not Tight  Stable 
Semi‐Detached  Medium  Medium  Medium  Medium 
Embedded  Greater  Tight  Complex Hardware/Customer 
Large 
Interfaces 

According to our study, we have decided that, Semi-Detached is the most appropriate mode of
development, and based on the Boehm proposed three levels of the model, Intermediate would
be used.

Intermediate COCOMO Model 
Software Project  a  b  c 
Organic  3.2  1.05  0.38 
Semi‐detached  3.0  1.12  0.35 
Embedded  2.8  1.20  0.32 

Based on the above depiction, the project is judged to be Semi-detached

(So a = 3.0, b = 1.12). And therefore, the details are as follows:

Effort = EAF * a * size b

=1.379 * 3.0 * 7.6 1.12

= 1.379 * 3.0 * 9.69

= 40.09 Man-months

To estimate the cost of the overall project we must multiple the values of effort and the salary
given per person which is $4000.

Cost = Effort * Salary

= 40.09 * $4000

= $160.386

The overall cost of the project is more or less than $160,000.

Page | 23  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Duration
Once estimation is acquired for the Effort (Person Months) we must determine the calendar-time
duration of the project and the people should be doing a particular job.
Calculating Duration:
We had 40.09 person-months for estimating the effort for this software project. And therefore
the project was subjected Semi-detached project.
TDEV=2.5 * MM c
Duration = 2.5 * (40.09) 0.35
Duration = 2.5 * 3.63
Duration = 9.09
Roughly 9.09 months to complete the project.
How many people should we hire?
40.09 person-months = 4.4 persons, roughly 5 team members needed.
9.09 months

Page | 24  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
4. CONCLUSION

Technique  Overall cost ($)  Effort (Person‐Months)  Duration (Months) 

Function Point Analysis  151,200  37.80  8 
LOC Analysis  157,000  38.00  8 
COCOMO Estimation  160,386  40.09  9 

According to our Function Point and LOC analysis, this project will cost around $150,000-
$157,000 in order to pay a 5-member team of IT professionals, having a capability of 10 FP/M,
with an average salary of $4000 per month. Further calculations suggest that an estimated 38
months per single programmer, or 38 programmers for one month will be required to complete
the estimated 7600 lines of code in the system, using a 4GL (.NET) Programming Language.

In addition, our COCOMO analysis has further strengthened the estimated values of cost, effort,
and time derived from the previous Function Point and LOC analysis techniques, by having
differences in values which are not greater than 0.8%.

In conclusion, based on the average total of all three of our analysis techniques, it is expected
that the “Informatics Examination System” is supposed to cost in the region of $156,200. The
average estimated effort is around 38 person-months. Therefore, taking all these into
consideration, we come to a conclusion that development of this project is expected to be
completed in 9 months by a development team consisting of 5 people.

Page | 25  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
5. APPENDIX

Group Report
There are some task that completed by different person in our group, so we divide our work
so we can finish this assignment faster. But there are some part that we combine doing some
part/task, this method is to avoid or minimize the problem. Not only that, this method also
gives us a better change to get the best idea that our member have.

Table of completed tasks

No  Tasks  M1  M2  M3 

1  Informatics Education Examination Planning     
2  Assumptions for Each System Module     
3  General Overview How the System Works     
4  Function Point Analysis   RV  RV 
5  Final Function Point Count   RV  RV 
6  Value of CAF      
7  Calculation of Cost, Effort, and Time Estimation  RV  RV  
8  LOC Analysis  RV  RV  
9  COCOMO Estimation  RV  RV  
10  Documentation: Introduction and the Planning Chapter   RV  RV 
11  Final Documentation     

LEGEND
M1  Agnes Meiliana 
M2  Daniel Natanael 
M3  Jason Alerta Obina 
RV  Reviewed by 

Page | 26  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
Full Form Table
FP  Function Point 
LOC  Line of Codes 
COCOMO  Constructive Cost Module  
FPA  Function Point Analysis 
EIs  External Inputs 
EOs  External Outputs 
EQs  External Inquiries 
ILF  Internal Logical File 
EIF  External Interface File 
GSC  General System Characteristics 
TDI  Total Degree Influence 
CAF  Complexity Adjustment Factor 
FPC  Final Function Point Count 
MM  Man‐Month 
EAF  Effort Adjustment Factor 
TDEV  Effort and development time  

Page | 27  
 
 U08784 – Software Project Management
Term 3, 2009, Assignment Part I
 
 
 
5. REFERENCES
 Software engineering Lan Sommerville Fifth edition Addison‐wesley  page [592‐ 608] 
 Fifth  Edition,  Software  Engineering  by  Ian  Sommerville,  Addison‐Wesley  Publishing  Company, 
[599 – 604] 
 Software Engineering: A Practitioner’s Approach, Third Edition, Roger S. Pressman [83 – 87] 
Information System Design Study Guide Version 1 

 http://www.ecfc.u‐net.com/cost/cocomo.htm 

 http://www2.enel.ucalgary.ca/People/Smith/619.94/prev689/1997.94/reports/farshad.htm 

 http://sunset.usc.edu/events/2000/oct24‐27‐00/index.html 

 http://cost.jsc.nasa.gov/COCOMO.html 

 U08784 – Software Project Management Study Guide 

Page | 28