Qatar University Computer Science and Engineering Department Software Engineering CMPS 411 Spring 2013 Group: L51

Milestone #1 28/ 03 /2013

Nour Musa

1. After a carefully reading for the specifications and requirements for the requested Hotel Reservation System a decision has been taken to choose the incremental delivery model as the development model for this project for following reasons: a. The groups main aim of this project is to meet all the requirements of Mr. Mohammeds reservation system and for this reason an incremental delivery model is suitable in order to deliver him the first increment which satisfies the most essential requirement (which is in this case reserve a room of the hotel to the customer) so the hotel staff can start using the software (as a prototype) early, test it and give some feedback about it. b. Using this model will insure in somehow the satisfaction of our client by delivering him the software in separate increments and we are reducing the percent of overall project failure. c. In addition, because of the flexibility of the requirements we can easily divide it into separate functions and increments with a proper size and in that way we overcome the problem with this model. d. Well defined requirements will provide simplicity to the task of dividing the software into increments. e. This model also provides flexibility to the system to expand it later and add more functions as needed.

2. a. b. c. d. Non-functional properties Availability: since the system is a hotel reservation system it has to be available 24/7. Backup: the system should provide a backup database for any future failure and a technique to retrieve it. Usability: the system should have a user friendly interface with help menu and frames for beginners. Security: each user should log-in to the system by his/her staff number and his/her password, the system should log-out automatically after 5 minutes if the system is not used and the staff member didnt log out. Also the system should encrypt all the information used in the system-bank communication. Efficiency: the system should use a fast searching algorithm to reduce searching time to minimum; also response time should be very high. Also the network connection with banks should be of a very high speed. Reliability: failure occurrence rate must be at minimum. Robustness: high speed restarting time after failure.

e.

f. g.

Project risks Management: - Risk identification

Risk Staff turnover Staff unavailability Hardware Unavailability Requirements Change Cost underestimate Requirements not met
Technology Change

Risk Type People People Technology Requirements Estimation Requirements

Affects Project project Project Project/Product Project/Product Project/Product

Technology

Business

Description A staff leaves the project before ending because he gets a better job. It is impossible to recruit staff with the skills required for the project. The required hardware for the project is not available The customer will change the requirements Underestimating the real cost of the project or initial budget blow up After finalizing the project specifications not meeting the requirements The technology used in this system is replaced by another technology

Justification: The risks mentioned in the People risk type its obvious that a turnover of a team member is expected and because one of the system requirements is that the staff members have to be competent personnel there is a possibility for staff unavailability risk. For the technology risk type because one of the requirements is to use an advanced technology and because the field of technology is changing rapidly the two above risks have a possibility to happen. The requirements risk type is common and could be happen in any software development and it should be expected. For the estimation the cost of the software is a critical issue and it should be considered although a good estimation technique has been used.

Risk Analysis Probability Moderate High High Moderate Low High High Effects Catastrophic Tolerable Serious Serious Serious Catastrophic Serious

Risk A staff leaves the project before ending because he gets a better job. The required hardware for the project is not available The customer will change the requirements Underestimating the real cost of the project or initial budget blow up After finalizing the project specifications not meeting the requirements It is impossible to recruit staff with the skills required for the project. The technology used in this system is replaced by another technology Justification

Any estimation taken here is based on the system specifications and requirements mentioned. A staff turnover takes a moderate probability to happen and if it happens it will hardly affects the project because all the staff employed is with high skills and its difficult to replace him/her by other staff. On the other hand, the staff unavailability has higher possibility to happen because of the required staff. Because the required technology to be used in this project is with high specifications so the probability to have a technology risk is considered to be high, and it will seriously affects the project in the side of the technology replacement but in the hardware side it could be tolerable because you can handle this issue. Changing the requirements is high possible to happen and it will serious affects the project. Also not meeting the requirements after ending the project is likely happened but in this project because the requirements are very clear so it has a low possibility to happen.

3.

a- A Gantt Chart

Figure 1: Gantt chart.

b- A dependency Table

Table 1: Dependency table.

Task Name

Duration

Start

Finish

Clients Meeting Team Meeting project planning MS1 Requirement analysis MS2 Design MS3 Implementation& testing MS4

50.13 days 65.25 days 25 days 0 days 23 days 0 days 11 days 0 days 11 days 0 days

Wed 3/13/13 Tue 2/26/13 Sun 2/24/13 Thu 3/28/13 Tue 3/26/13 Thu 4/25/13 Thu 4/25/13 Thu 5/9/13 Thu 5/9/13 Thu 5/23/13

Wed 5/22/13 Tue 5/28/13 Thu 3/28/13 Thu 3/28/13 Thu 4/25/13 Thu 4/25/13 Thu 5/9/13 Thu 5/9/13 Thu 5/23/13 Thu 5/23/13

Table 2: Dependency table.

Task Name

Duration

Start

Finish

Clients Meeting Clients Meeting 1 Clients Meeting 2 Clients Meeting 3 Clients Meeting 4 Clients Meeting 5 Clients Meeting 6 Team Meeting Team Meeting 1 Team Meeting 2 Team Meeting 3 Team Meeting 4 Team Meeting 5 Team Meeting 6 Team Meeting 7 Team Meeting 8 Team Meeting 9 Team Meeting 10 Team Meeting 11 Team Meeting 12 Team Meeting 13 Team Meeting 14 project planning MS1 Requirement analysis MS2 Design MS3 Implementation & testing MS4

50.13 days 1 hr 1 hr 1 hr 1 hr 1 hr 1 hr 65.25 days 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 2 hrs 25 days 0 days 23 days 0 days 11 days 0 days 11 days 0 days

Wed 3/13/13 Wed 3/13/13 Wed 3/27/13 Wed 4/10/13 Wed 4/24/13 Wed 5/8/13 Wed 5/22/13 Tue 2/26/13 Tue 2/26/13 Tue 3/5/13 Tue 3/12/13 Tue 3/19/13 Tue 3/26/13 Tue 4/2/13 Tue 4/9/13 Tue 4/16/13 Tue 4/23/13 Tue 4/30/13 Tue 5/7/13 Tue 5/14/13 Tue 5/21/13 Tue 5/28/13 Sun 2/24/13 Thu 3/28/13 Tue 3/26/13 Thu 4/25/13 Thu 4/25/13 Thu 5/9/13 Thu 5/9/13 Thu 5/23/13

Wed 5/22/13 Wed 3/13/13 Wed 3/27/13 Wed 4/10/13 Wed 4/24/13 Wed 5/8/13 Wed 5/22/13 Tue 5/28/13 Tue 2/26/13 Tue 3/5/13 Tue 3/12/13 Tue 3/19/13 Tue 3/26/13 Tue 4/2/13 Tue 4/9/13 Tue 4/16/13 Tue 4/23/13 Tue 4/30/13 Tue 5/7/13 Tue 5/14/13 Tue 5/21/13 Tue 5/28/13 Thu 3/28/13 Thu 3/28/13 Thu 4/25/13 Thu 4/25/13 Thu 5/9/13 Thu 5/9/13 Thu 5/23/13 Thu 5/23/13

c- A dependency Graph (Network Diagram)

Figure 2: Dependency graph.

4. a. (i)

Software size = 20 KDSI MM = 3.2 (20)1.05 = 74.34 Effort Estimation = Nominal Effort Estimate * Effort Adjustment Factor Calculating the Effort Adjustment Factor Rating High Very High Nominal Very High High Very High Effort Multiplier 1.15 1.16 1 0.82 0.91 1.10

Cost Drivers RELY DATA CPLX MODP TOOL SCED

The rest of cost drivers are Nominal with effort multiplier of 1 Effort Adjustment Factor = 1.15 * 1.16 * 1 * 0.82 * 0.91 * 1.10 = 1.095 So, Effort Estimation = 74.34 * 1.095 = 81.4 MM (ii) Development Schedule (TDEV) = 2.5(MM)0.38 = 2.5 (81.4)0.38 = 13.3 So we need more than 13 months to finish the project. (iii) Staffing Required = MM / TDEV = 81.4 / 13.3 = 6.12

So we need more than 6 team members. (iv) Cost = MM * cost per MM = 81.4 * 120,000 = QR 9,768,000

a. Calculating UFC Average 6 *4 = 24 15 * 5 = 75 20 * 10 = 200 2 * 7 = 14 5 * 4 = 20 High 5 * 6 = 30 10 * 7 = 70 0 * 15 = 0 3 * 10 = 30 3 * 6 = 18 96 165 256 44 74

Functions\Components Low External Input 14 * 3 = 42 External Output 5 * 4 = 20 Logical Files 8 * 7 = 56 External Interfaces 0*5=0 Inquiry 12 * 3 = 36 *Table constants in Red

UFC = 96 + 165 + 256 + 44 + 74 = 635 - Calculating VAF Data communications - 5 Distributed functions - 0 Performance - 5 Heavily used configuration - 0 Transaction rate - 5 On-line data entry - 3 End-user efficiency - 3 On-line update - 3 Complex processing - 3 Reusability - 3 Installation ease - 5 Operational ease 4 Multiple sites - 0 Facilitation of change 3 VAF = (5 * 4) + (3 * 6) + 4 = 42 - Calculating TCF *To find the TCF value which is lie between (0.65 1.35) so if we find the average value of the 14 general system characteristics which is 42/14 = 3 so if we take the average for Fi = 2.5 (which doesnt exist!) AVG = 1.35 0.65 = 0.7/2 = 0.35 and because our average is 3 not 2.5 we will add 0.5 so TCF = 1.05 TCF = 1.05 + 0.01 (42) = 1.47 (*1.05 is an estimated value) - Calculating FP FP = UFC * TCF = 635 * 1.25 = 793.75 (FP)

5. a. For the first part which concern about the suitable development model used to do the project a clear justifications mentioned in the same part. b. About the second part, the non-functional properties are somehow clear and straight forward and one can extract them from the system specifications and requirements. c. The risk management part there was some estimations about the appropriate risks for this project, some of these risks are mentioned in the Golden Software Report, and the justifications mentioned in that section of the report. d. The calculation part which use COCOMO and FP techniques there is no estimations all the required information are mentioned in the Golden Software Report. Except one estimation which is about the value of TCF and a proper justification also mentioned in the same part.

6. Doing milstone-1 we experienced many things. We created a report that was based on studies and decisions about what a real life project would need. We developed analysis skills and decision making skills as well as communication skills. We encountered some difficult parts during this process like learning how to use new software to document our plans and ideas, and how to deal risks that might arise during the process. It was a little difficult to show weve learned in class and link it to this project. We divided the work among us we decided which member should do what task and then we shared ideas and discussed the progress. Based on the deliverables weve divided the parts among ourselves.