Université du Québec ÉCOLE DE TECHNOLOGIE … Study_version_Jan… · ... Software Engineering...

All rights reserved 2006, Software Engineering Research Laboratory, École de Technologie Supérieure (Canada)

Université du Québec

ÉCOLE DE TECHNOLOGIE SUPÉRIEURE

Software Functional Size with

ISO 19761: 2003

COSMIC-FFP Measurement Method

Proposed Measurement Etalon:

********* C-Registration System *********

January 4, 2007

Updated: February 23, 2008

Source of Requirements:

Rational Unified Process 2003 – with permission

All rights reserved 2006, Software Engineering Research Laboratory, École de Technologie Supérieure (Canada) 2

Document Control

Date Reviewers (s) Modifications / Additions

2004-08-26 Adel Khelifi First Draft 2004-09-07 Alain Abran Revision 2004-09-16 Adel Khelifi Second Draft 2005-02-09 Charles Symons Revision 2005-05-19 Jean-Marc Desharnais Revision 2005-05-22 Adel Khelifi Update measurement result 2006-11-04 Alain Abran, Charles

Symons, Adel Khelifi, Fernando Machado, J. Jayakumar

Update to the measurement procedure + measurement results

2006-12-23 Alan Leterthuis, Alain Abran, Charles Symons

Updates based on comments from Metricsgroep from Netherlands

2008-02-23 Carole Dekkers, A. Abran Negative number in functional process no. 11 corrected. Small additional corrections to the totals in Tables 4 to 7. New total size = 107 Cfsu instead of 106 Cfsu.

Copyright 2006. All Rights Reserved. Software Engineering Research Laboratory of École de technologie supérieure - Université du Québec (Canada).

All rights reserved 2006, Software Engineering Research Laboratory, École de Technologie Supérieure (Canada) 3

Table of Content

1. CONTEXT OF MEASUREMENT OF THIS CASE STUDY............................................................. 4

1.1 INTRODUCTION .............................................................................................................................. 4 1.2 MEASUREMENT PURPOSE, SCOPE AND MEASUREMENT VIEWPOINT .............................. 4 1.3 ASSUMPTIONS MADE ON THE RUP REQUIREMENTS, AND MEASUREMENT STEPS ....... 5

2. C-REGISTRATION SYSTEM REQUIREMENTS............................................................................. 6

2.1 CONTEXT ......................................................................................................................................... 6 2.2 SYSTEM REQUIREMENTS............................................................................................................. 6 2.3 USE CASE DIAGRAM.................................................................................................................... 16

3. COSMIC-FFP MEASUREMENT PROCEDURE - STEP 1............................................................. 17

3.1 IDENTIFICATION OF LAYERS .................................................................................................... 17 3.2 IDENTIFICATION OF USERS ....................................................................................................... 17 3.3 BOUNDARY.................................................................................................................................... 17 3.4 IDENTIFICATION OF TRIGGERING EVENTS – STEP 1 ............................................................. 18 3.5 IDENTIFICATION OF DATA GROUPS – STEP 1 .......................................................................... 18 3.6 IDENTIFICATION OF FUNCTIONAL PROCESSES – STEP 1 ..................................................... 21 3.7 OBSERVATIONS ON THE CLARITY OF THE DOCUMENTED REQUIREMENTS ................ 23 3.8. IDENTIFY DATA MOVEMENTS – CANDIDATE FUNCTIONAL PROCESSES – STEP 1..................... 23 3.9. ANALYSIS OF MEASUREMENT RESULTS............................................................................... 35 3.10. QUESTIONS AND ANSWERS.................................................................................................... 37

4. COSMIC-FFP MEASUREMENT PROCEDURE – STEP 2 ............................................................ 42

4.1 JUSTIFICATION FOR STEP 2........................................................................................................ 42 4.2 CONSEQUENCES OF STEP 2 FOR THE FUNCTIONAL SIZE MEASUREMENT..................... 43

4

1. CONTEXT OF MEASUREMENT OF THIS CASE STUDY

1.1 INTRODUCTION

This Case Study presents the result of applying the COSMIC-FFP Functional Size Measurement method (eg. ISO 19761: 2003) to the RUP ‘C-Registration’ software system. The C-Registration System is documented in the Rational Unified Process (RUP Version 2003.06.00.65) document as an example of a Web site project. The C-Registration System will enable students to register for courses on-line. The C-Registration System also allows professors to select their teaching courses and to maintain student grades. General information about the software application to be measured: � Application domain: Business Application � Application type: PC client interacts with server over the www. Available information about the software system � Document: Requirements in a HTML format, as presented in the Release Notes Version 1.0

and Use-Cases Specification Version 2.0. Together, we refer to these as the ‘C-Registration System requirements’.

Permission was received from IBM in 2005 to use the C-Registration System requirements’ as input to this case study..

1.2 MEASUREMENT PURPOSE, SCOPE AND MEASUREMENT VIEWPOINT

Measurement Purpose: The measurement purpose is to measure all of the software functional user requirements (FUR) as documented in sections 2.2 ‘Requirements’ and 2.3 ‘Use Case Diagram’ of this case study. Measurement Scope: The measurement scope is all of the software functional processes of this C-Registration system, including the log-in functions which we assume to be added specifically for this on-line system. The measurement scope is therefore a subset of the system requirements documented in section 2 of this Case Study, that is, only those related to software, and not those related to the hardware. Measurement Viewpoint: The measurement viewpoint in this Proposed Measurement Etalon is that of the End User of a PC. Given the selected End User Measurement Viewpoint and that the Scope is ‘the whole C-Registration system’, all exchanges between the PC client and the main-frame server are invisible to the End Users.

5

1.3 ASSUMPTIONS MADE ON THE RUP REQUIREMENTS, AND

MEASUREMENT STEPS

In spite of the simple Purpose as stated in 1.2, it has been necessary to make some assumptions about the supplied RUP requirements when preparing this Case Study and to adopt a two-step approach to the measurement. The initial analysis and measurement of the requirements using COSMIC-FFP to prepare this Case Study uncovered certain anomalies, such as some inconsistencies in the terminology and some uncertainties leading to a lack of clarity in a few areas. If these points had not been addressed, it would have been very challenging to obtain one consistent size measure for the functional user requirements. The authors of this Case Study have therefore modified the requirements as given later in Section 2 in a few places as follows:

• When something is missing from the requirements in the opinion of the authors of

this Case Study, text is added in italics.

• When a section of the text is not clear, this text is put in braces [ ], followed by

addition of a clarification text in italics.

Then, with an unambiguous statement of requirements as a starting point, the Case Study presentation of the analysis and measurement is processed in two steps. Step 1 (Chapter 3 of this Case Study)

The COSMIC-FFP method is applied to the functional user requirements exactly as they are written in 2.2, subject to the clarifications introduced as described above and assuming that each event explicitly identified in the use cases triggers one functional process. Step 2 (Chapter 4 of this Case Study) The authors of the Case Study observe that the functional user requirements contain no separate ‘enquiry’ functional processes in relation to Professors, Students and Schedules, a situation that in practice is implausible. However, the ‘modify’ and ‘delete’ Use Cases for these three ‘objects of interest’ all include functionality to retrieve the existing data and to display it before modifying or deleting. But this retrieval functionality is not specified in such a way that it could be separately invoked at any time (e.g. from the Menus, as an enquiry functional process), which is also extremely unlikely in practice. As stated above, in Step 1 the Case Study shows the measurement of the functional user requirements literally as written in section 2.2. For Step 2, the Case Study authors have assumed that this enquiry functionality can be invoked at any time and that each type of enquiry corresponds to a separate functional process (whether invoked ‘stand-alone’ from the Menu, or invoked prior to an update or delete functional process). The difference in size between the solutions given for Steps 1 and 2 is only 6 Cfsu (6% of the total size), which shows how the COSMIC-FFP method is (happily) insensitive to varying

6

assumptions about splitting requirements into different functional processes (of course, as long as all the functionality is measured under each set of assumptions). In the authors’ opinion, the size in units of Cfsu given for Step 2 is much more likely to be the ‘correct’ size if these RUP requirements had been complete in including the enquiry functions, and entirely free of uncertainties. The size given for Step 1 is correct for the functional user requirements as given and with the assumptions made.

2. C-REGISTRATION SYSTEM REQUIREMENTS

The information in section 2 of this Case Study is derived from the vision document of the Course Registration System – version 1.0 (for more details, please check this link : http://people.cs.uct.ac.za/~jkr/SoftwareEng/vision_v1.htm. It presents the same document used for these sections.

2.1 CONTEXT

The functional requirements below describe the behaviour of a project that will replace the entire front-end of the existing course registration system with a state-of-the-art on-line system that allows students and professors access through PC clients. The current registration system has been in use since 1985 and lacks the capacity to handle the student and course load projected for the year 2000. In addition, the current system is outdated mainframe technology, which only supports access through the clerks in the Registration Office. The new system will enable all professors and students to access the system through PCs connected to the Wylie College computer network and through any personal computer connected through the Internet. The new system will bring Wylie College to the leading edge in course registration systems thus improving the image of the College, attracting more students, and streamlining administrative functions.

2.2 SYSTEM REQUIREMENTS

Note: The requirements as supplied have been reorganized in the following sequence:

1. Login (by all users) 2. Maintain professor information (by the registrar) 3. Select courses to teach (by professors) 4. Maintain student information (by the registrar) 5. Register for courses (by students) 6. Monitor for course full (by the application) 7. Close registration (by the registrar) 8. Submit grades (by professors) 9. View report card (by students)

1. Login

1.1. Brief Description This use case describes how a user logs into the Course Registration System. The actors starting this use case are Student, Professor, and Registrar.

7

1.2. Flow of Events The use case begins when the actor types his/her name and password on the login form. 1.2.1 Basic Flow - Login The system validates the actor’s password and logs him/her into the system. The system displays the Main Form and the use case ends. 1.2.2 Alternative Flows 1.2.2.1 Invalid Name / Password If in the basic flow the system cannot find the name or the password is invalid, an error message is displayed. The actor can type in a new name or password or choose to cancel the operation, at which point the use case ends. 2. Maintain Professor Information 2.1. Brief Description This use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system. The actor of this use case is the Registrar. 2.2. Flow of Events The use case begins when the Registrar selects the "maintain professor" activity from the Main Form. (We assume that the result of selecting ‘maintain professor’ is that the sub-options to

‘add professor, ‘modify a professor’ and ‘delete a professor’ are displayed for selection.

Similarly, we assume that selecting any of the other options on the Main Form, as described

below, results in displaying corresponding sub-options for selection.)

2.2.1 Basic Flow – Add a Professor The Registrar selects "add a professor."

The system displays a blank professor form. The Registrar enters the following information for the professor: name, date of birth, social security number, status, and department. The system validates the data to insure the proper data format and searches for an existing professor with the specified name. If the data is valid the system creates a new professor and assigns a unique system-generated id number. This number is displayed, so it can be used for subsequent uses of the system. Steps 2-4 are repeated for each professor added to the system. When the Registrar is finished adding professors to the system the use case ends. 2.2.2 Alternative Flows 2.2.2.1 Modify a Professor

The Registrar selects "Modify a professor." The system displays a blank professor form. The Registrar types in the professor id number he/she wishes to modify The system retrieves the professor information and displays it on the screen The Registrar modifies one or more of the professor information fields: name, date of birth, social security number, status, and department. When changes are complete, the Registrar selects "save." (Note that this step of ‘Save’ is mentioned only in this ‘Modify a Professor’ Use Case, except for

the Use Case 5.2.2.3 ‘Save a Schedule’ which has a specific effect) The system updates the professor information.

8

Steps 2-7 are repeated for each professor the Registrar wants to modify. When edits are complete, the use case ends. 2.2.2.2 Delete a Professor

The Registrar selects "Delete a Professor." The system displays a blank professor form. The Registrar types in the professor id number for the professor that’s being deleted. The system retrieves the professor and displays the professor information in the form. The Registrar selects "delete." The system displays a delete verification dialog confirming the deletion. The Registrar selects "yes." The professor is deleted from the system. Steps 2-8 are repeated for each professor the Registrar wants to modify. When the Registrar has finished deleting professors from the system, the use case ends. 2.2.2.3 Professor Already Exists If in the "Add a Professor" sub-flow, a professor already exists with the specified name, an error message, "Professor Already Exists", is displayed. The Registrar can either change the name, choose to create another professor with the same name, or cancel the operation at which point the use case ends. 2.2.2.4 Professor Not Found If in the "Modify a Professor" sub-flow or "Delete a Professor" sub-flow, a professor with the specified id number does not exist, the system displays an error message, "Professor Not Found". Then the Registrar can type in a different id number or cancel the operation at which point the use case ends. 3. Select/De-select Courses to Teach 3.1. Brief Description This use case allows a professor to select the course offerings (date- and time- specific courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester.

The actor starting this use case is the Professor. The Course Catalog System is an actor within the use case. 3.2. Flow of Events The use case begins when the professor selects the "select courses to teach" activity from the Main Form. 3.2.1 Basic Flow – Select Courses to Teach The system retrieves and displays the list of course offerings the professor is eligible to teach for the current [upcoming] semester. The system also retrieves and displays [the list of courses the professor has previously selected to teach.] (This sentence could be interpreted as either the

courses selected over all semesters, or courses selected within the current semester, where we

assume ‘current’ = ‘upcoming’. For this case study, the following clarification is made for

measurement purposes: courses selected to teach for the upcoming semester).

The professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcoming semester. The system removes the professor from teaching the de-selected course offerings.

9

The system verifies that the selected offerings do not conflict (i.e., have the same dates and times) with each other or any offerings the professor has previously signed up to teach. If there is no conflict, the system updates the course offering information for each offering the professor selects. (It is not clear from the specification where the updated course offering information with the

assigned professor is saved – on the Course Catalog or on the CRS.

We assume that it is important for the students to know which professor has signed up for each

course and so the updated course information must be sent back to the Course Catalog so that

the information is available for when a student creates or modifies his/her schedule.

Note that in this Use Case, unlike the others, no clear distinction is made between a Create,

Modify or Delete for the link between a course offering and a professor. Paragraph 3.2.2.3

below implies that a Professor may change the initial selection of courses to teach as long as

registration for the current semester has not closed)

3.2.2 Alternative Flows 3.2.2.1 No Courses Available If in the basic flow the professor is not eligible to teach any courses in the upcoming semester the system will display an error message. The professor acknowledges the message and the use case ends. 3.2.2.2 Schedule Conflict If the system finds a schedule conflict when trying to establish the course offerings the Professor should take, the system will display an error message indicating that a schedule conflict has occurred. The system will also indicate which are the conflicting courses. The professor can either resolve the schedule conflict (i.e., by cancelling his selection to teach one of the course offerings) or cancel the operation, in which case any selections will be lost and the use case ends. 3.2.2.3 Course Registration Closed If, when the Professor selects "select courses to teach", registration for the current semester has been closed, a message is displayed to the Professor and the use case terminates. Professors cannot change the course offerings they teach after registration for the current semester has been closed. If a professor change is needed after registration has been closed, it is handled outside the scope of this system. 4. Maintain Student Information

4.1. Brief Description This use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying, and deleting students from the system. The actor for this use case is the Registrar. 4.2. Flow of Events The use case begins when the Registrar selects the "maintain student" activity from the Main Form. 4.2.1 Basic Flow – Add Student

The Registrar selects "add student."

10

The system displays a blank student form. The Registrar enters the following information for the student: name, date of birth, social security number, status, and graduation date. The system validates the data to insure the proper format and searches for an existing student with the specified name. If the data is valid the system creates a new student and assigns a unique system-generated id number. (Note that the system-generated student id number is apparently not required to be displayed,

unlike that of the Professor in the use case above.)

Steps 2-4 are repeated for each student added to the system. When the Registrar is finished adding students to the system the use case ends. 4.2.2 Alternative Flows 4.2.2.1 Modify a Student

The Registrar selects "modify student." The system displays a blank student form. The Registrar types in the student id number he/she wishes to modify. The system retrieves the student information and displays it on the screen. The Registrar modifies one or more of the student information fields: name, date of birth, social security number, student id number, status, and graduation date. When changes are complete, the Registrar selects "save." The system updates the student information. Steps 2-7 are repeated for each student the Registrar wants to modify. When edits are complete, the use case ends. 4.2.2.2 Delete a Student

The Registrar selects "delete student." The system displays a blank student form. The Registrar types in the student id number for the student that’s being deleted. The system retrieves the student and displays the student information in the form. The Registrar selects "delete." The system displays a delete verification dialog confirming the deletion. The Registrar selects "yes." The student is deleted from the system. Steps 2-8 are repeated for each student deleted from the system. When the Registrar is finished deleting students to the system the use case ends. (Apparently a student can be deleted without any checks on whether he/she has a Student/Course

Registration and without deleting any associated Schedule(s) or Report Card(s)

4.2.2.3 Student Already Exists If in the "Add a Student" sub-flow the system finds an existing student with the same name an error message is displayed "Student Already Exists". The Registrar can either change the name, create a new student with the same name, or cancel the operation at which point the use case ends. 4.2.2.4 Student Not Found If in the "Modify a Student" or "Delete a Student" sub-flows the student name is not located, the system displays an error message, "Student Not Found". The Registrar can then type in a different id number or cancel the operation at which point the use case ends.

11

5. Register for Courses

5.1. Brief Description This use case allows a Student to register for course offerings in the current semester. The Student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester. The main actor of this use case is the Student. The Course Catalog System is an actor within the use case. 5.2. Flow of Events The use case begins when the Student selects the "maintain schedule" activity from the Main Form. 5.2.1 Basic Flow – Create a Schedule

The Student selects "create schedule." The system displays a blank schedule form. The system retrieves a list of available course offerings from the Course Catalog System. The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available offerings. Once the selections are complete the Student selects "submit." The "Add Course Offering" sub-flow is performed at this step for each selected course offering. The system saves the schedule. 5.2.2 Alternative Flows 5.2.2.1 Modify a Schedule

The Student selects "modify schedule." The system retrieves and displays the Student’s current schedule (e.g., the schedule for the current semester). The system retrieves a list of all the course offerings available for the current semester from the Course Catalog System. The system displays the list to the Student. The Student can then modify the course selections by deleting and adding new courses. The Student selects the courses to add from the list of available courses. The Student also selects any course offerings to delete from the existing schedule. Once the edits are complete the Student selects "submit". The "Add Course Offering" sub-flow is performed at this step for each selected course offering. The system saves the schedule. 5.2.2.2 Delete a Schedule

The Student selects the "delete schedule" activity. The system retrieves and displays the Student current schedule. The Student selects "delete." The system prompts the Student to verify the deletion. The Student verifies the deletion. The system deletes the schedule. 5.2.2.3 Save a Schedule

[At any point], the Student may choose to save a schedule without submitting it by selecting "save". The current schedule is saved, but the student is not added to any of the selected course offerings. The course offerings are marked as "selected" in the schedule.

12

We assume that (at any point) means that this Save action can occur whilst performing a Create

or Modify functional process. A Save cannot be performed unless a Schedule already exists and

is displayed to the Student. So a Save is not a separate functional process, but an optional step

in a Create or Modify functional process. It makes no sense for a Save to be needed during a

Delete functional process. Note that this Save action by a Student is not the same action as the

Save of a Schedule by the System.

5.2.2.4 Add Course Offering The system [verifies that the Student has the necessary prerequisites] and that the course offering is open (The detailed rules, and corresponding data groups for checking that the student has the

necessary prerequisites, are not described in the specifications; for this measurement scope, it is

taken as a given that the rule is simple and involves reading a single data group; we have called

this a ‘Schedule history record’ and assumed it is held in the C-Registration system). The system then adds the Student to the selected course offering (assuming both tests are passed

successfully). The course offering is marked as "enrolled in" in the schedule. (Note also that the distinction between when a course is ‘available’ and when it is ‘open’ is not

clear in the Specification. We have assumed for simplicity that these are synonyms)

5.2.2.5 Unfulfilled Prerequisites or Course Full If in the "Add Course" sub-flow the system determines that the Student has not satisfied the necessary prerequisites or that the selected course offering is full, an error message is displayed. The Student can either select a different course offering or cancel the operation, at which point the use case is restarted. 5.2.2.6 No Schedule Found If in the "Modify a Schedule" or "Delete a Schedule" sub-flows the system is unable to retrieve the Student’s schedule, an error message is displayed. The Student acknowledges the error and the use case is restarted. 5.2.2.7 Course Catalog System Unavailable If, the system is unable to communicate with the Course Catalog System after a specified number of tries, the system will display an error message to the Student. The Student acknowledges the error message and the use case terminates. 5.2.2.8 Course Registration Closed If, when the student selects "maintain schedule", registration for the current semester has been closed, a message is displayed to the Student and the use case terminates. Students cannot register for courses after registration for the current semester has been closed. 6. Monitor for Course Full [The system shall ensure] that no course is filled beyond the limit of 10 students. In the specifications it is not clear whether the requirement is to do this once at the closure of

registration, or that this is done every time a student adds a course to his schedule. For this case

study, we have assumed that the requirement is to verify this condition every time a student

adds/modifies a course to his schedule. Otherwise many students could sign up for courses that

were already over-booked, which would not be the best way to proceed.

For this to be possible the C-Registration system must communicate back to the Course

Catalogue every time a student adds, modifies or deletes a course offering on his schedule, so

13

that the Course Catalog record for each course offering always contains the latest data on the

number of students enrolled. We have assumed this requirement.

With these assumptions, this monitoring occurs as part of the create, modify and delete Schedule

functional processes and is not itself a separate functional process.

7. Close Registration

7.1. Brief Description This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering. The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case. 7.2. Flow of Events The use case begins when the Registrar selects the "close registration" activity from the Main Form. 7.2.1 Basic Flow – Successful Close Registration [The system checks to see if a Registration is in progress]. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress. (It is not clear how the check on whether a registration

is in progress can be carried out. If it is performed by the C-Registration application, then there

must be communication between the ‘Register for Courses’ Use Cases and this ‘Close

Registration’ Use Case. But this functionality is not described, so we have ignored it in this

analysis

For each open course offering, the system [checks if three students have registered] and a professor has signed up to teach the course offering. If so, the system closes the course offering and sends a transaction to the billing system for each student enrolled in the course offering. (As with previous Use Cases, we assume that the count of the number of students signed up for

each course is maintained on the Course Catalog system.)

7.2.2 Alternate Flows 7.2.2.1 Less Than Three Students in the Course Offering If in the basic flow less than three students signed up for the course offering, the system will cancel the course offering. The Cancel Course Offering sub-flow is executed at this point. 7.2.2.2 Cancel Course Offering The system cancels the course offering. For each student enrolled in the cancelled course offering, the system will modify the student’s schedule. The first available alternate course selection will be substituted for the cancelled course offering. If no alternates are available, then no substitution will be made. Control returns to the Main flow to process the next course offering for the semester. (The way in which the system deals with students’ alternative course selections is unclear in this

specification. The specification appears to state that courses with less than three students

enrolled are cancelled and only then are alternatives examined – which might reveal that many

students have chosen the course as an alternative but, too late, it has already been cancelled.

14

Fortunately for the functional sizing the sequence of the logic is immaterial.)

Once all schedules have been processed for the current semester, the system will notify all students, by mail, of any changes to their schedule (e.g., cancellation or substitution). 7.2.2.3 No Professor for the Course Offering If in the basic flow there is no professor signed up to teach the course offering, the system will cancel the course offering. The Cancel Course Offering sub-flow is executed at this point. 7.2.2.4 Billing System Unavailable If the system is unable to communicate with the Billing System, the system will attempt to re-send the request after a specified period. The system will continue to attempt to re-send until the Billing System becomes available. (There is another functional process implied in 7.2.2.4 which has been ignored in this Step 1 of

the measurement. Logically, the functionality of ‘sending a transaction to the billing system for

each student enrolled in the course offering’ as described in 7.2.1 above cannot take place until

the processing of all selections of all students for all courses has been completed. So the ‘Close

Registration’ process must create a file of billing data and a separate functional process must

send the data to the Billing System, triggered either by the end of the ‘Close Registration’

process or, if previous attempts to transit have failed because the Billing System is unavailable.

by a ‘try again’ time signal in the C-Registration system.)

8. Submit Grades

8.1. Brief Description This use case allows a Professor to submit student grades for one or more classes completed in the previous semester. (We assume this means ‘the semester just ended’.)

The actor in this use case is the Professor. 8.2. Flow of Events The use case begins when the Professor selects the "submit grades" activity from the Main Form. 8.2.1 Basic Flow – Submit Grades The system displays a list of course offerings the Professor taught in the previous semester. The Professor selects a course offering. The system retrieves a list of all students who were registered for the course offering. The system also retrieves the grade information for each student in the offering (i.e. that was

previously assigned for the offering. Note that the specification for this Use Case does not

distinguish clearly the ‘Add’ and ‘Modify’ cases). The system displays each student and any grade that was previously assigned for the offering. For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The system records the student’s grade for the course offering. If the Professor wishes to skip a particular student, the grade information can be left blank and filled in at a later time. The Professor may also change the grade for a student by entering a new grade. 8.2.2 Alternative Flows 8.2.2.1 No Courses Taught If in the basic flow, the Professor did not teach any course offerings in the previous semester the system displays an error message and the use case ends.

15

8.2.2.2 Course Cancelled If too many students withdrew from the course during the add/drop period and the course was cancelled after the beginning of the semester, the system displays an error message. If the Professor chooses to cancel the operation the use case terminates, otherwise is restarted at step 2 of the basic flow. 9. View Report Card

91. Brief Description This use case allows a Student to view his/her report card for the previously completed semester. The Student is the actor of this use case. 9.2. Flow of Events The use case begins when the Student selects the "view report card" activity from the Main Form 9.2.1 Basic Flow – View Report Card The system retrieves the grade information for each of the courses the Student completed during the previous semester. The system prepares, formats, and displays the grade information. When Student is finished viewing the grade information the Student selects "close." 9.2.2 Alternative Flows 9.2.2.1 No Grade Information Available If in the basic flow the system cannot find any grade information from the previous semester for the Student, a message is displayed. Once the Student acknowledges the message the use case terminates.

16

2.3 USE CASE DIAGRAM

View Report Card

Student

Register for Courses

Submit Grades

Course Catalog

Professor

Select Courses to Teach

Maintain Student Information

Maintain Professor Information

Billing System

Registrar

Close Registration

User

Login

Figure 1. Course Registration System - Use Case Diagram – RUP 2003

17

3. COSMIC-FFP MEASUREMENT PROCEDURE - STEP 1

3.1 IDENTIFICATION OF LAYERS

There is a single software layer for this set of requirements

3.2 IDENTIFICATION OF USERS

The users who interact with this software: a) Users who send information to the software:

- Wylie College Users: - Students, - Professors, - Course Registrar

- Course Catalog system b) Users who receive information from the software:

- Wylie College Users: - Students, - Professors, - Course Registrar

- Course Catalog system - Billing System - Mail subsystem

3.3 BOUNDARY

This measurement is limited to the software product functionalities; neither quality nor performance requirements are considered. Based on the written requirements from section 2, the following software boundary is identified - Figure 2.

Figure 2. Application Boundary

Boundary

C-Registration System

Student schedule

Wylie College Users (Students, Professors, Course Registar)

Course Catalog System

Billing system

Mail system

18

3.4 IDENTIFICATION OF TRIGGERING EVENTS – Step 1

From the textual descriptions of the requirements, 14 candidate triggering event(s) are identified as listed in Table 1.

Table 1: List of candidate triggering events – Step 1

No Main Form Menu selection 14 Triggering events

1 Actor access the login form

1- Actor types his/her name and password on the login form

2 Registrar selects the "maintain professor" activity from the Main Form

2- Add a Professor 3- Modify a Professor 4- Delete a Professor

3 Professor selects the "select courses to teach" activity from the Main Form

5- Professor selects his/her courses to teach

4 Registrar selects the "maintain student" activity from the Main Form

6- Add a Student 7- Modify a Student 8- Delete a Student

5 Register for course: Student selects the "maintain schedule" activity from the Main Form

9- Create a Schedule 10- Modify a Schedule 11- Delete a Schedule

6 Registrar selects the "close registration" activity from the Main Form

12- Registrar starts the Close Registration functional process

7 The Professor selects the "submit grades" activity from the Main Form

13- Professor submit grades

8 The Student selects the "view report card" activity from the Main Form

14- Student View Report Card

3.5 IDENTIFICATION OF DATA GROUPS – Step 1

From the documented requirements, seven objects of interest are identified. These are listed in Table 2 together with their most significant data groups. Note that an accurate data analysis is not possible given some uncertainties in the documentation of the FUR. No Entity-Relationship model or Third Normal Form model analysis is available in the available documentation. Table 2 does not show any data groups corresponding to exchanges between the PC client and the main-frame server because these exchanges are invisible to End Users when the Scope of the measurement is defined as ‘the whole C-registration system’.

19

Table 2: List of Objects of Interest and Data Groups – Step 1

Source/

Destination

of data

Object of

Interest

Data

groups

Data attributes Comments

Users User* User data User ID User Name Password

Registrar Professor* Professor data

Prof. ID, name, date of birth, social security number, status, and department

Registrar Student* Student data

Student’s ID, name, date of birth, social security number, status, and graduation date.

Course Catalog System

Course Course data

All information relevant to a course registered in the Course Catalog

See Note 1 below

Course Catalogue System

Course- offering

Course offering data

Course offering ID No. of students signed-up Professor ID signed-up

This data relates to the current semester

Student Schedule item*

Schedule item data

Student ID Course offering ID Primary/alternate course preference indicator Selected/enrolled status

Professor Schedule item*

Student grade

Student ID. Course offering ID Grade

Note that ‘Student grade’ is another data group of the object of interest ‘Schedule item’

Previous cycles of the C-Reg System?

Schedule history item*

Schedule history record

Student ID Course offering ID Date of course Grade (for previous courses)

Mail System Schedule item*

Student schedule changes message

Student ID Course offering ID (for each change to a Student’s schedule)

Not all data attributes are specified in the documentation

Billing System

Schedule item*

Invoice-item

Student ID Course offering ID Fee payable (for each course offering that the student has been accepted for)

Not all data attributes are specified in the documentation

C-Reg System

’System’ Error Message

See Note 4

20

* From the requirements, we conclude that data about the five asterisked objects of interest are stored persistently on the C-Registration system. Data about the ‘Course’ and ‘Course offering’ objects of interest are stored persistently on the Course Catalog system. Note 1 It might be that the Course Catalog system distinguishes data held about each ‘Course’ from data held about each ‘Course-offered-in-the-current-seminar’, i.e. there are two objects of interest. The former would have time-independent data about the course, e.g. course description, pre-requisites, etc. The latter would have, for example, attributes such as the ID of the professor signed up to teach the course this semester, the total number of students signed up so far, etc. We have no information in the specification on whether the Course Catalog system makes this distinction, but it seems more logical that it does than that it does not. So we have assumed that two objects of interest exist, namely the ‘Course’ and the ‘Course offering’, where the latter has data about the course for the current semester. But an assumption that there is only one object of interest (‘course-offering’) would also be valid. This assumption affects the measured size because we have assumed that some functional processes need only ‘Course-offering’ data (e.g. when a student creates a ‘Schedule’) whereas other functional processes need ‘Course’ attributes as well (e.g. to check the pre-requisites for a particular course). But these assumptions might be wrong. For example, it might be that a student needs to see the ‘Course’ data as well as ‘Course offering’ data when creating a Schedule. Note 2 The ‘Student Schedule’ is not a separate object of interest. There is no data held about a Student Schedule. It is a collection of up to six occurrences of a data group for each student showing the course-offerings that he/she has signed up for as ‘primary or alternate’ and as ‘selected or enrolled’. We have named each of these data groups ‘schedule item data’, to distinguish it from the name of the object of interest (‘schedule item’) of the group. The complete Student Schedule appears, for example, when a student displays the collection of up to six courses that he/she has signed up for. Note 3. The ‘List of professors’ is not a separate object of interest of data group. See Note 2 : No data are held about the list. Note 4. The ‘System’ is not really an object of interest. All we know is that the software produces error messages. There is no need to identify an object of interest, just as there is no value in identifying the object of interest of a pure command data movement Definitions of the 7 Objects of interest (in alphabetic order)

Course: A standard series of lectures, etc on a specific subject from the College Course Catalogue Key: (Course ID). Other attributes (assumed): Course name, description, Pre-requisite Course ID Note: Registration by a Student for a particular Course Offering may depend on successful attendance at (i.e. passing) a ‘pre-requisite’ course. Course-offering: A Course that is available for students to enrol during a particular Semester

21

Key: (Course ID, Semester ID). Other attributes: dates, times, locations of the lectures, etc., availability indicator (open/closed/cancelled), assigned Professor, number of students enrolled Professor: A person who may register to deliver a Course-offering in the current Semester, for a Course which he is eligible to teach. Key: (Professor ID). Other attributes: name, address, date of birth, SSN, status, Department, phone, fax, e-mail Student: A person who can register to attend a Course-offering Key: (Student ID). Other attributes: name, DOB, status, graduation date Schedule item: One of the maximum of six entries in a Student Schedule when a Student selects or enrols in a Course-offering Key: (Student ID, Course-offering ID). Other attributes: Student preference status (primary, alternate), registration status (selected, enrolled in), grade awarded, fee payable, etc Schedule history item: An instance of a specific student having attended a specific Course-offering during a previous semester Key: (Student ID, Course-offering ID, Semester date). Other attributes: Grade awarded User: Any person (Registrar, Professor or Student) that is authorised to use the C-Registration system Key: User ID. Other attributes: User name, password

3.6 IDENTIFICATION OF FUNCTIONAL PROCESSES – Step 1

From the documented requirements with each triggering event, there are 14 candidate functional processes.

14 Candidate Functional Processes – Step 1

1- Actor types his/her name and password on the login form 2- Add a Professor 3- Modify a Professor 4- Delete a Professor 5- Professor selects/de-selects his/her courses to teach 6- Add a Student 7- Modify a Student 8- Delete a Student 9- Create a Schedule 10- Modify a Schedule 11- Delete a Schedule 12- Registrar starts the Close Registration functional process 13- Professor submit grades 14- Student View Report Card

The measurement procedure must assess whether a candidate functional process is a COSMIC-FFP one or not.

22

Each candidate process must satisfy the following questions in order to be validated as a COSMIC-FFP functional process: � Does it operate on a unique cohesive and independently executable set of data movements

performing a set of FUR? � Is it triggered by an event (triggering event)? � Does the triggering event occur outside the boundary of the software? � Does the process execute all that is required to be done in response to the triggering event? These questions are investigated next. Analyses of only 3 functional processes out of 14 are presented next in order to minimize redundancy and reduce the document’s size. Functional Process 1 = Logon Question Answer Comments

Does it operate on a unique cohesive and independently executable set of data movements performing a set of FURs?

Yes

Is it triggered by an event? Yes Actor types his/her name and password on the login form

Does the triggering event occur outside the boundary of the software?

Yes Actor is outside the boundary

Does the process execute all that is required to be done in response to the triggering event?

Yes

The Logon process is therefore a COSMIC-FFP functional process. Functional Process 2 = Add a professor Question Answer Comments


Yes

Is it triggered by an event? Yes Registrar selects the "add professor"

Does the triggering event occur outside the boundary of the software?

Yes Registrar is outside the boundary


Yes

The Add a professor process is therefore a COSMIC-FFP functional process. Functional Process 3 = Modify a professor Question Answer Comments


Yes

Is it triggered by an event? Yes Registrar selects the

23

"modify professor" Does the triggering event occur outside the boundary of the software?

Yes Registrar is outside the boundary


Yes

The Modify a professor process is therefore a COSMIC-FFP functional process. Note Data groups will be associated with identified functional processes in the next section in a detailed manner.

3.7 OBSERVATIONS ON THE CLARITY OF THE DOCUMENTED REQUIREMENTS

Even though the documented requirements used for this Case Study are coming from the Rational Unified Process, there is no mention about the quality of these requirements. IEEE Std 830-1998 recommends that requirements meet the following quality criteria: - Correct; - Unambiguous; - Complete; - Consistent; - Ranked for importance and/or stability; - Verifiable; - Modifiable; - Traceable. In the RUP documentation, there is no claim that their sets of documented requirements meet the quality criteria specified in IEEE 830. The Use Cases diagram has been taken ‘as is’ from the RUP training section on RATIONAL web site. In some instances, some text in the Requirements has been added in italics to complement missing information; Similarly, when a section of the text of the Requirements was unclear, it was put into brackets, and complementary text was added in italics. The measurement results in this section of this document are based taking into account only:

- the written Requirements as in Section 2 of this document - the assumptions and clarifications documented in italics in Section 2 - the Use Case diagram as in Section 2 of this document.

3.8. IDENTIFY DATA MOVEMENTS – Candidate functional processes – Step 1

For all functional processes in the previous steps, all data movements of a data group must be identified. Important: the reader is reminded of paragraph 1.3 where it is stated that in this Step 1, the requirements are interpreted literally and analysed assuming each explicitly identified event triggers only one functional process. The detailed analysis in Step 2 identifies, however, that in some cases there should almost certainly be more than one functional process from what would

24

have initially appeared to be a single triggering event. When this happens, this will be noted in Table 3 by using a dashed line to indicate where one functional process might end and the next start. These dashed lines are only relevant to the discussion in Step 2. In table 3, the numbers in the ID Process column refer to the numbers in the Requirements section of this document.

25

Table 3. List of COSMIC-FFP data movements – Functional Processes – Step 1

No ID. of

Require

ments

Process

descriptions

Triggering event Sub-process Description Data Group Data

movement

Type

Cfsu ΣCfsu

1 1.2 Logon Actor types his/her name and password on the login form

Actor enters name and password System E 1

Read name and password User data R 1 Display error message Messages X 1 3

Maintain Professor Information 2 2.2.1

Add a professor

Registrar selects the "add a Professor" activity

Registrar enters information for the Professor

Professor data E 1

2.2.2.3 The system validates the entered data and checks if a professor of the same name exists already

Professor data R 1

The system creates a new Professor Professor data W 1 Display the system generated Professor ID

number Professor ID

X 1

Display error message Messages X 1 5

3 2.2.2.1

Modify a professor

Registrar selects the "modify a Professor" activity

Registrar enters Professor ID Professor ID E 1

2.2.2.4 The system retrieves the Professor information

Professor data R 1

The system displays the Professor information

Professor data X 1

The Registrar enters the modified Professor data

Professor data E 1

26

When changes are complete, the Registrar selects ‘Save’

This is not a distinct data movement. It only indicates that the Entry of the data (see above) is completed

This will be omitted from now on in all other use cases

0

The system updates the Professor information

Professor data W 1

Display error message Message X 1 6

4 2.2.2.2

Delete a Professor

Registrar selects the "delete a Professor" activity

Registrar enters Professor ID Professor ID E 1

2.2.2.4 The system retrieves the Professor information

Professor data R 1


Professor data X 1

Registrar enters the delete command for the selected Professor

Professor ID E 1

The system prompts the Registrar to confirm the deletion

System prompt command

n/a (not a data group movement)

0

The Registrar confirms the deletion

Professor ID n/a (repetition of Delete Entry above)

0

Professor is deleted from the system Professor data W 1 Display error message Message X 1 6

5 3.2 Select /De- Professor selects/de-select Start the ‘select courses to teach’ process ‘Select courses E 1

27

3.2.2.3 select Courses to Teach

the "select courses to teach" activity from the Main Form

to teach’ command

3.2.2.1 3.2.2.2

The system requests (from the Course Catalog database) the list of courses the professor has previously selected to teach and others that he is eligible to teach


X 1

The system receives the requested data Course offering data

E 1

The system displays the requested data Course offering data

X 1

The Professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcoming semester

Course offering data E 1

The system sends the Professor’s selected or de-selected course offerings to the Course Catalog system

Course offering data X 1

The Course Catalog system verifies that the selected offerings do not conflict and returns any conflicting pairs


Conflicting pairs of courses are displayed Course offering data

X 1


Maintain Student Information 6 4.2.1

Add a student

Registrar selects "add student"

Registrar enters student data Student data E 1

4.2.2.3 The system validates the data and checks if a student of the same name already exists

Student data R 1

The system creates a new student Student data W 1 Display error message Messages X 1

28

4

7 4.2.2.1

Modify a student

Registrar selects "modify student"

Registrar enters student ID Student ID E 1

4.2.2.4 The system retrieves the student information

Student data R 1

The system displays student information Student data X 1 Registrar modifies one or more of the

student information fields Student data

E 1

The system stores the modified data Student data W 1 Display error message Message X 1 6

8 4.2.2.2

Delete a Student

Registrar selects "delete student"

Registrar enters student ID Student ID E 1

4.2.2.4 The system retrieves the student information

Student data R 1

The system displays student information Student data X 1 Registrar enters ‘delete’ command Student id E 1 The system prompts the Registrar to

confirm the deletion System prompt command

n/a (Not a data group movement)

0

The Registrar confirms the deletion Confirmation message

n/a (repetition of Delete Entry command above)

0

Student is deleted from the system Student data W 1 Display error message Message X 1 6

Register for Course 9 5.2.1 Create a

Schedule Student selects "create a schedule"

Student enters "create schedule" Start create schedule command

E 1

29

Request the course offerings from the Course Catalog System


X 1

Receive the available course offerings from the Course Catalog System for the current semester


The system displays the list of available course offerings


X 1

The student selects 4 primary courses and 2 alternate courses and submits them (to this application i.e. C-Reg system)

Schedule item data E 1

The system verifies with the Course Catalog system what pre-requisites are needed

Course data 1 x X 1 x E

1 1

5.2.2.4 The system verifies whether the Student has satisfied the necessary prerequisites


1 x R 1

Validated Schedule items are returned to the Course Catalog system so that it can maintain the student count for each course

Schedule item data X 1

6. The Course Catalog system verifies that the course offering is still open and that less than 10 students are enrolled

(N/A – not part of the C-Reg system)

0

Schedule items are marked as "enrolled in" and are made persistent in the Student’s schedule on the C-Reg system

Schedule item data W 1

The system saves the schedule (This happens when the Schedule items are made persistent by the Write above)

N/A 0

5.2.2.3 Student may choose to save a schedule without submitting it by selecting "save"

Schedule item data

E 1

The course offerings are marked as "selected" in the schedule and it is saved

Schedule item data

W 1

Display error message Messages X 1

30

13

10 5.2.2.1

Modify a Schedule

Student selects the "modify schedule" activity from the Main Form

Student enters ‘modify a schedule’ command

Modify a schedule command

E 1

5.2.2.6 The system retrieves the Student’s current schedule

Schedule item data

R 1

The system displays the Student’s current schedule

Schedule item data

X 1

The system retrieves all the course offerings available for the current semester from the Course Catalog System


1 x X 1 x E

2

The system displays the list of available course offerings


X 1

The student enters the modifications to his Schedule item(s)

Schedule item data

E 1


Course data 1 x X 1 x E

1 1

5.2.2.4 The system verifies whether the Student has the necessary prerequisites


1 x R 1

Validated Schedule items are returned to the Course Catalog system so that it can maintain the student count for each course


6. The Course Catalog system verifies that there are less than 10 students enrolled and that the course offering is still open

(N/A) 0

Schedule items are marked as "enrolled in" and are made persistent in the Student’s schedule on the C-Reg system, when saved by the system

Schedule item data

W 1

5.2.2.3 Student may choose to save a schedule without submitting it by selecting "save"

Schedule item data

E 1

The course offerings are marked as Schedule item W 1

31

"selected" in the schedule and it is saved data Display error message Messages X 1 15

11 5.2.2.2 Delete a Schedule

Student selects the "delete schedule" activity from the Main Form

Student enters ‘delete schedule’ command Delete Schedule command

E 1

5.2.2.6 The system retrieves the student’s current schedule

Schedule item data

R 1

The system displays the student’s current schedule

Schedule item data

X 1

The student enters the deletion command for the schedule

Delete Schedule command

E 1

The system prompts the Student to verify the deletion

System Prompt Command

(N/A) 0

The student confirms the deletion Schedule item data

N/A (Repeat of Entry above)

0

The system updates the student’s schedule Schedule item data

W 1

6. The system sends the deleted schedule items to the Course Catalog system so that the latter can update the number of students enrolled for each course

Schedule item data

X 1


12 7.2 Close Registration

Registrar selects the "close registration" activity from the Main Form

Registrar enters ‘Close Registration’ Close registration command

E 1

32

Read if a Registration is in progress System N/A see 7.2.1 in section 2 (not enough details for measurement purposes)

0

Display error message Message X 1 Obtain Course offering data (with no. of

students enrolled, etc) from the Course Catalog

Course offering’

1 x X 1 x E

2

Read Schedule items to obtain the ‘enrolled’ and ‘alternate’ course selections

Schedule item data

R 1

Check that at least three students signed up: if not cancel course and examine student’s alternatives

Data manipulation (N/A)

Send info for a billing transaction for each student accepted for each course

Invoice item X 1

Update the course offerings on the Course Catalog


X 1

Update each student’s schedule Schedule item data

W 1

Send info on any schedule changes to students through mail subsystem

Student schedule changes message

X 1

9

13 8.2 Submit Grades

The Professor selects the "submit grades" activity from the Main Form

The Professor decides to submit grades Start the ‘submit grades’ process

E 1

The system retrieves the courses the professor taught from the Course Catalog


1 x X 1 x E

2

33

Course offerings are displayed Course offering data

X 1

The Professor selects a course offering Course offering selection

E 1

For each course offering, selected in turn, the system retrieves the schedule items for all students who were registered for each course offering

Schedule item data

R 1

The system also retrieves the grade information for each student in the course offering that had been entered previously (if any)

Grade is the second data group within the Schedule item data Object of Interest

R 1

The system displays each schedule item for each student including any grade that was previously assigned for the offering

Schedule item data and Grade 2 X 2

The professor enters or changes the student’s grade for the course offering

Schedule item data

E 1

The system records the student’s grade for the course offering

Schedule item data

W 1


14 9.2 View Report Card

The Student selects the "view report card" activity from the Main Form

The Student selects the "view report card" activity from the Main Form

Start ‘view report card’ process

E 1

The system retrieves the grade information for each of the courses the Student completed during the previous semester

Schedule item data Grade

2 R 2

34

The system prepares, formats, and displays the grade information

Schedule item data & grade

2 X 2

When Student is finished viewing the grade information the Student selects "close"

Students Grades

A control command, not a separate data movement

0


Total functional size in Cfsu = ΣCfsu 107

Important

Note 1: The above measurement results have taken into consideration the assumptions indicated in italics in the requirements of section 2.2. Any change to these assumptions can have an impact to the functional size. Note 2: The above measurement results are based on the information available at the Requirements level. It is feasible that more information is added at the Specifications level which would add further data groups; this would most certainly impact the functional size. It is also plausible that the detailed specifications lead to additional functional processes and/or the addition of sub-processes. Again, this could lead to changes to the functional size in order to take into account these additions Note 3: It is the responsibility of the measurer to identify, within the documented requirements, what he considers as ambiguities and omissions and to document the assumptions he made that led to the measurement results he produced and documented. The comments documented by the measurer represent value added during the measurement process. These comments should next be reviewed by the project manager who should then address these comments prior to proceeding further with the project.

35

3.9. ANALYSIS OF MEASUREMENT RESULTS

For this software application, the total functional size is obtained with the addition of all data movements within its single functional process, that is 106 Cfsu (ISO 19761: 2003), as indicated at the bottom of Table 4.

Table 4. Distribution of size units - Course Registration application

No Requirements ID Functional Processes Data Movements Cfsu

E X R W 1 1.2 Logon 1 1 1 3 2 2.2.1 Add a professor 1 2 1 1 5 3 2.2.2.1 Modify a professor 2 2 1 1 6 4 2.2.2.2 Delete a Professor 2 2 1 1 6 5 3.2 Select Courses to Teach 4 5 9 6 4.2.1 Add a student 1 1 1 1 4 7 4.2.2.1 Modify a student 2 2 1 1 6 8 4.2.2.2 Delete a Student 2 2 1 1 6 9 5.2.1 Create a schedule 5 5 1 2 13 10 5.2.2.1 Modify a schedule 5 6 2 2 15 11 5.2.2.2 Delete a schedule 2 4 2 1 7 12 7.2 Close registration 2 6 2 1 9 13 8.2 Submit Grades 4 5 2 1 12 14 9.2 View Report Card 1 3 2 4 TOTAL 14 33 43 17 13 107 Cfsu The contribution of functional processes to total Cfsu size is presented in Table 5.

Table 5. Contribution of functional process to total size (% rounded to the integer)

No Requirements ID Functional Processes Cfsu %*

1 1.2 Logon 3 3 2 2.2.1 Add a professor 5 5 3 2.2.2.1 Modify a professor 6 6 4 2.2.2.2 Delete a Professor 6 6 5 3.2 Select Courses to Teach 9 9 6 4.2.1 Add a student 4 4 7 4.2.2.1 Modify a student 6 6 8 4.2.2.2 Delete a Student 6 6 9 5.2.1 Create a schedule 13 13 10 5.2.2.1 Modify a schedule 15 15 11 5.2.2.2 Delete a schedule 7 7 12 7.2 Close registration 9 8 13 8.2 Submit Grades 12 8 14 9.2 View Report Card 6 4 TOTAL 14 107 Cfsu 100%

36

The percentages of size by data movement types are presented in Table 4 and Figure11.

Table 6. Percentage of the Cosmic-FFP data movement types

Data Movement Types Cfsu %

Entry (E) 34 32 Exit (X) 43 40 Read (R) 17 16 Write (W) 13 12 Total : 107 (Cfsu) 100 (%)

31%

41%

15%

13%

Entry

Exit

Read

Write

Figure 3. Ratio of COSMIC FFP data movement types

37

3.10. QUESTIONS AND ANSWERS

Question 1

Often, the ‘Logon’ process is a functional process provided by the software environment and is not measured in the software application itself. Why is it included in the measurement boundary in this case study? Answer 1: It is documented in the Requirements that the old system was mainframe based accessed only by a clerk. The ‘new system’ requires this log-in for access by the students and professors, for instance. It is also included in the Use Case diagram. Question 2

Can one triggering event (Registrar selects the “maintain professor” activity from Main Form) trigger more than one functional process (Add, Modify, Delete and View a Professor)? Answer 2: There is no such event as ‘maintain professor’ in this RUP case study. In the real world of the Registrar there are events like:

� A new professor starts work � Something changes for a professor, so the data to be stored about him must be

changed � A professor leaves or dies or whatever, so we must remove him from the

database. These three types of event lead to the corresponding types of functional processes (i.e. add, modify and delete) respectively. ‘Maintain professor’ is a group of functional process types. Selection of this group by the Registrar is a control command, not measured in the End User Measurement Viewpoint – see the Business Application Guideline, because it does not start one functional process. Question 3

The ‘Maintain Professor’ Use Case alternative flow 2.2.2.3 ‘Professor Already Exists’ says “…The Registrar can… choose to create another professor with the same name…” Why is this not an Entry data movement? Answer 3: Within this functional process, there is already an Entry of this data group. The de-duplication rule specifies that a data movement must not be taken into account twice within the same functional process - it is logically the same data movement.

38

Question 4

The Use Case alternative flow 3.2.2.2 ‘Schedule Conflict’ says that when the Course Catalog finds a schedule conflict between two courses, they are sent back to the C-Registration system and the Professor may either cancel his selection to teach one of the courses, or cancel the whole operation. Why doesn’t the solution given show all the data movements associated with this requirement? Answer 4. It appears from the requirements that the data movements to return and display two conflicting courses from the Course Catalog system to the C-Registration system are different from other data movements earlier in this functional process. So these two data movements are identified. (The earlier return and display of courses is a list of courses that the Professor either has already selected to teach, or that he is eligible to teach. The latter return and display is of two courses that are linked by a schedule conflict.) But the following actions by the Professor to select or deselect one of the conflicting courses and send the choice back to the Course Catalog system appear to be functionally identical to the earlier cycle of selections and sending back courses. If this interpretation is correct, according to the ‘de-duplication’ rule, these two data movements (an Entry and an Exit) should be identified only once. Cancelling the whole operation is a Control command and should not be identified. Question 5

The Functional process Delete a Schedule has a requirement: “The system prompts the Student to verify the deletion” entry data movements. Confirmations like this one appear on other functional processes like Delete a Professor. Why are these not identified as data movements? Answer 5: In the Business Application Guidelines the rule is given in 5.6.1 that clicking ‘OK’ to confirm some entered data should be ignored as a Control command. (This is a reasonable rule. The confirmation involves a repeat of some logic and we do not take into account repeats of the same logic two or more times in a functional process.) We have shown this logic in the case of ‘Delete a Schedule’, but not in other cases, since it should not identified and counted in any of them. Question 6

Observations and questions sent by a user of this case study: “The requirements for the

Logon functionality are practically useless from a security point of view in that anyone

can log-on by entering ‘a new name and password’, which apparently is not stored.

Further, there is no requirement for an explicit link between any registration (e.g. of a

39

Student by the Registrar) and the Logon procedure. The Logon authorisation also does

not explicitly prevent that any role may carry out the tasks of any other role, eg. a that a

student can enter his own grades.” Answer 6: The questions are relevant. However, all these points have not been documented in the requirements. The purpose of the measurement for the case study being to measure the requirements as documented, we have not taken this case into account here. However, should the purpose of measurement be different, an analyst might then correct and expand the requirements, and these additions should then be added to the size. Question 7

In 2.2.1, ‘Add a Professor’ it reads ‘The system validates the data …’. When modifying a professor, this validation is missing in the Requirements at section 2.2.2.1 Answer 7: The observation is relevant. However, even if this data validation had been specified (which it should be), it would not result in any more data movements, so no change to the measured functional size. The ‘data validation’ is already taken into account in the following data movements included in the measurements: Read (info about the professor), Exit (Display) and Exit (error message). Question-Observation 8. In 2.2.2.2, ‘Delete a Professor’, there is no check whether the Professor has signed to teach a Course, so deleting the professor would leave a Course with no-one to teach it. Answer 8 The observation is relevant, but the authors of this measurement case study do not know how this obvious check should be handled (and it is not specified in the requirements), so we have chosen not to attempt to account for the omission. The consequences of the check failing could be quite complicated, e.g. resulting in a need to inform all students signed up for the affected courses of the change, finding an alternative Professor, cancelling the courses, etc. All consequences would require additional functionality and hence this would lead to a greater size Question 9

In Table 3, section 4 for ‘Delete a Professor’, the Registrar enters a delete command, which is identified as an Entry. However, the Professor has been selected by a first Entry (by entering the Professor ID). So why is the delete command identified as an Entry and not as a control command? The delete command just says ‘delete the present professor’; it does not convey data about an object of interest. This same comment applies to several functional processes.

40

Answer 9. The delete command DOES convey data about a specific object of interest, the already-identified Professor, so this must be identified as an Entry. It may be that no attribute such as a specific Professor ID must be explicitly entered by the Registrar, but the specific ID is certainly implied in this command. This is quite different from a real ‘control ‘command’ (as defined in the ‘Guideline for Sizing Business Application Software’, paragraph 5.6.1), such as ‘page-up’ or ‘page down’. Question 10

In 5.2.1 ‘Create a schedule’ there are 2 Writes. Why no de-duplication here? Answer 10: In practice, this set of requirements includes not 1 but 3 functional processes, which must be executed in sequence. I will find a way to clarify this, by adding a note in the ‘Functional Process column, and putting a ‘dashed line’ between the two FP. Therefore, the duplication applies within a Functional Process, not across 2 Functional Processes, as it is the case here. Question 11

In 5.2.2.1, what is the difference between the 2 X’s? Why no de-duplication? Answer 11: In practice, this set of requirements includes not 1 but 3 functional processes, which must be executed in sequence. I will find a way to clarify this, by adding a note in the ‘Functional Process column, and putting a ‘dashed line’ between the two FP. Therefore, the duplication applies within a Functional Process, not across 2 Functional Processes, as it is the case here. Question 12

In Functional Process no 4 – Delete a professor, there is a first step to view a professor (with an Entry, Read and Exit), and then a second step to Delete the professor (with an Entry, Write and Exit). Why is this considered as only 1 Functional Process and not 2 Functional Processes since the user has to enter again information (Is this a second triggering event starting a second Functional Process)? Answer 12: A functional process is triggered when a functional user detects an event, or makes an independent decision outside the software. Examples are: - there is a new student, and as a userI must enter data about him;

41

- The student needs to enquire on the schedule of courses the student has enrolled for, to check something. Once started down that process, there may be decision points which take the student down different paths in the software, depending on the input data, but the student only starts a new functional process if he makes a new independent decision. An example in the C-Reg case where there might be some debate is in the 'Create Schedule' Functional Process, where the student can decide 'at any point' to 'save' a Schedule, with status 'selected' rather than the 'enrolled' status if the Functional Process is continued to normal completion. This option is necessary because a student may start to enter his schedule and then find a course he wants is fully-booked, or he doesn't like the professor, or whatever, so the option exists to 'park' his entry while he goes away and thinks what to do. This 'save' as the start of a new fp, but rather an option of the 'create' (or add or delete) fp. If in any Functional Process, we were to say that if a user decides to take a break, or change his mind and back out, or make a check-point, he must be starting a new Functional Process, then this could multiply the size very rapidly. The definition of a Functional Process says something like that it is 'not complete until it has done all that was needed to respond to the event that triggered the fp.' Changing your mind part-way through responding to the event does not signify the start of a new Functional Process. It is what you do after you have finished the current Functional Process that starts a new one. The points in this C-Reg case where such decisions are possible are very few, but actually very common in real-life systems. An example might be in entry of data to a life assurance system where in a Functional Process to establish a new life assurance policy, having entered the data about the applicant's sex, different paths must be followed on entering medical history depending on whether the applicant is male or female. But these different paths do not indicate the start of a new Functional Process.

42

4. COSMIC-FFP MEASUREMENT PROCEDURE – Step 2

4.1 JUSTIFICATION FOR STEP 2

As outlined in section 1.3, Step 2 of this Case Study shows the measurement results of Step 1 modified by a further assumption about the requirements of section 2.2, namely that any practical system would require separate functions to enquire on Professors, Students and Schedules. The authors of this Case Study then adopt the viewpoint of an experienced functional size measurement expert and conclude the following consequences for the effects of making this assumption about the requirements and of applying a COSMIC-FFP Rule1 given in the ‘Measurement Manual’, v2.2:

a) In the requirements given in section 2.2, each of the Use Cases for modifying and deleting Professors, Students and Schedules begins with the sub-processes needed to retrieve the particular data that the user wishes to modify or delete. Naturally, a user cannot carry out a modify or delete operation unless he/she first retrieves the data to be modified or deleted (in the latter case at least for sight validation that the correct record has been selected for deletion).

b) The functionality needed for the retrieval phase is identical for the modify and

delete Use Cases for each of these three objects of interest, so it is identified twice in measuring the functional size in the Step 1 analysis of the requirements. An experienced functional size measurer would say ‘you should really include this functionality only once in the size measurement, not once for every time it happens to be written down in the requirements’.

c) This same retrieval functionality is basically identical to that which would be

needed for any separate enquiry functions on Professors, Students and Schedules that could be called independently, e.g. from the menus (if these enquiries had been specified in the Requirements).

d) Therefore, if a separate functional process (e.g. ‘Enquire on Professor’) is to be

included in the size measurement, the equivalent identical retrieve functionality should be removed from the ‘Modify Professor’ and ‘Delete Professor’ Use Cases. Otherwise, the same functionality would be included three times in the size measurement.

1 The Rule on “Read and Write Data Movements in ‘Update’ Functional Processes” says that ‘most commonly’ a retrieve-before-update is a separate functional process from the update functional process in on-line business application software.

43

e) The effect of such a change in the way the Requirements are interpreted is that there are now three functional processes, each triggered by entirely separate triggering events. From the user’s viewpoint, these are:

� ‘I want to retrieve data about a given Professor’ (after which I might continue to modify or delete the data, or move on to another enquiry, or stop altogether)’

� ‘I want to modify the data I have just retrieved’ � ‘I want to delete the data I have just retrieved’

f) The same arguments apply for a Student and for a Schedule.

4.2 CONSEQUENCES OF STEP 2 FOR THE FUNCTIONAL SIZE

MEASUREMENT

The three functional processes for a Professor, as defined in Section 4.1 e), can be sized as follows. No ID Process

description

Triggering

Event

Sub-process

Description

Data

Group

Data Mvt.

type Cfsu

Tot.

Cfsu

3 2.2.1 Enquire on a Professor

Select the “enquire on a Professor"

Registrar enters Professor ID

Professor ID E 1

The system retrieves the Professor information

Professor data

R 1


Professor data

X 1

Display error message

Message X 1

4

Modify a Professor

Registrar decides to “modify a Professor"

The Registrar enters the modified Professor data

Professor data

E 1

The system updates the Professor information

Professor data

W 1


Message X 1

3

Delete a Professor

Registrar decides to “delete a Professor"

Registrar enters the delete command for the selected

Professor ID

E 1

44

Professor The system

prompts the Registrar to confirm the deletion

System prompt command

n/a (not a data group movement)

0

The Registrar confirms the deletion

Professor ID

n/a (repetition of Delete Entry above)

0

Professor is deleted from the system

Professor data W 1


Message X 1

3

Total functional size in Cfsu of the three functional processes 10

It can be seen that the two Use Cases to modify and delete a Professor sized in Step 1 as 12 Cfsu have been replaced in Step 2 by three functional processes of total size 10 Cfsu. The reduction in size is the result of eliminating the retrieval functionality which was included twice in Step 1. Similarly, when the two Use Cases of Step 1 to modify and delete a Student are replaced by the three functional processes to enquire on, modify and delete a Student in Step 2, the total functional size is also reduced from 12 to 10 Cfsu. The corresponding change for replacing the two Use Cases ‘Modify Schedule’ and ‘Delete Schedule’ of Step 1 by the three functional processes ‘Enquire on Schedule’, ‘Modify Schedule’ and ‘Delete Schedule’ results in a similar change of functional size in spite of the greater complexity of these Use Cases. The Step 2 analysis is given below. No ID Process

Descripti

on

Triggering

Event

Data movement

Description

Data

Group

Data

Mvt.

Type

Cfsu

Tot.

Cfsu

10 5.2.2.1

Enquire on a Schedule

Select the "enquire on a schedule"

Student enters ‘enquire on a schedule’ command

‘Enquire on a schedule’ command

E 1

The system retrieves the Student’s current schedule

Schedule item data R 1

The system displays the Student’s current schedule



45

Modify a Schedule

Student decides to ‘modify a schedule’

Student enters ‘modify schedule’

Start modify schedule command

E 1

The system requests and receives available course offerings from the Course Catalog for the current semester


1 x X 1 x E

2

Display the course offering data


X 1

The student enters the modifications to his Schedule item(s) and submits them to the C-Reg system

Schedule item data

E 1


Course data

1 x X 1 x E

2

The system verifies that the Student has the necessary prerequisites


R 1

Validated Schedule items are returned to the Course Catalog so that it can maintain the student count for each course

Schedule item data

X 1

The Course Catalog system verifies that the course offering is still open and that there are less than 10 students registered

(N/A) 0

Schedule items are marked as "enrolled in" in the Student’s schedule and are made persistent in the C-Reg system

Schedule item data

W 1

Student may choose to save a schedule without submitting it by selecting "save"

Schedule item data

E 1

Schedule items are Schedule W 1

46

marked as "selected" in the schedule and it is saved

item data


Delete a Schedule

Student decides to "delete schedule"

The student enters the deletions for selected item(s)

Schedule item data

E 1

The system prompts the Student to verify the deletion

System Prompt Command

N/A 0

The student confirms the deletion

Schedule item data

N/A (Repeat of Entry above)

0

The system updates the student’s schedule

Schedule item data

W 1

The system sends the deleted schedule items to the Course Catalog system so that the latter can update the number of students enrolled for each course

Schedule item data

X 1


Total functional size in Cfsu of the three functional processes 21

It can be seen that the two Use Cases to modify and delete a Schedule sized in Step 1 as 23 Cfsu have been replaced in Step 2 by three functional processes of total size 21 Cfsu. The reduction in size is the result of eliminating the retrieval functionality which was included twice in Step 1. (It could be argued that the ‘Save Schedule’ Use Case in the Requirements which says that ‘[At any point], the Student may choose to save a schedule without submitting it by selecting "save", and which must apply to the ‘Create Schedule’ and ‘Modify Schedule’ Use Cases, should also be included in the size measurement only once. The authors of this Case Study have assumed that this ‘Save Schedule’ functionality cannot result from a separate triggering event decision by the Student, and that it occurs as an optional branch in both the ‘Create Schedule’ and ‘Modify Schedule’ functional processes, and should therefore be included in the functional size of both of these functional processes. The general teaching point is that functionality that occurs in multiple functional processes should be identified only once if that functionality can be separately triggered and hence identified as a separate functional process.) Overall, therefore, the reduction in size from Step 1 to Step 2 through introducing the separate enquiry functional processes and eliminating the duplicated retrieval

47

functionality in the modify and delete Use Cases for these three objects of interest is 2 + 2 + 2 = 6 Cfsu. The total size of these requirements following the analysis of Step 2 is therefore 100 Cfsu.

Date post:	15-Feb-2018
Category:	Documents
Upload:	tranque
View:	212 times
Download:	0 times

Université du Québec ÉCOLE DE TECHNOLOGIE … Study_version_Jan… · ... Software Engineering...

Documents