Milestone-1: Planning – Essay Furious


 

 

 

 

SE Project: Milestone-1: Planning

Course number: CMPS411

Milestone  No  : 1

Submission date  : 28-03-2013

Instructor: Dr.Khaled Khan

 

 

 

___________________________________________________

 

Software process:

It’s hard to choose which development process is better for the project. Furthermore in order to choose one, system analyzing will be required. In this case the project is a business project, as a result the incremental development could be a better choice for this particular type. On the other hand when we read the requirements of the project, it doesn’t seem like the case, so we assume that the waterfall is a better approach for this project.

Why it is not incremental development?
Incremental build weakens structure, as a matter of fact, in order to change things easily the structure should be smooth, in addition one of the major benefits of the incremental development is to use the system before it finishes, resulting in an incrementally step by step delivery. Alternatively from the customer requirements that we read, a lot of system’s functions are linked together, if the system is split to parts in order to get a convenient use of the parts, the parts will not be equal, for example if a system contains ten major functions, developing them at two steps with each one contains five function is not possible. Additionally to make the customer capable of using the system, the first development may contain eight parts so this is a major benefit for this specific model gone away.

Why it is waterfall model?  
When the requirements are read, it seems as if the customer knows exactly what he wants, the requirements are very clear and the scope is obvious. As a result a major problem of this model is gone, which is misunderstanding to the customer. Additionally this model is simple, straightforward to understand and easy to apply it correctly, just like a pure model for almost pure requirements. This model deals with one activity at a time, which is counted as an advantage in this case because focusing on one activity will make the structure strong. In addition, the reasons of choosing this model are the budget and planning, making it clear of what will exactly be done, enabling us of scheduling the project and estimating the budget without trouble. The processes are visible so the progress is quiet easy to calculate. The problem of this model is the difficulty of accommodating the changes but as an assumption based on the clear requirements, the customer will know exactly what he wants, so as an assumption even if the system is a business system, the changes will be rare, or no changes will occur at all.

The major problem is about the customer’s feedback, in order to solve this, we decided to use waterfall model with prototyping, for many reasons; to match the customer’s need in addition to some feed from him. Improve the system usability, design quality, system maintainability and to reduce the development effort.

Due to all of the previous reasons, the final result was to use waterfall model with prototyping. The prototype should not be used unless we need it.

 

Non-functional properties:
Usability:
The System should be easy to use, because the stack holders will be from different majority.

  • User document to show how the system can be used.
  • Help option that has FAQ and important methods to use.
  • An option of showing the number of empty rooms.
  • An option of showing the number of rooms that will be empty at certain day.
  • An option of making a backup of the system, because the system has important information that has to be stored easily for safety.
  • An option of importing the backup, because in this system if data are lost it will make a financial lose, so the system should be able to import the backup easily, even if there is no expert available.
  • Reservation online, to enable the customers of making the reservation online easily.

Efficacy: This means that the system should not use many resources.

  • When the recourses became less than the system want. The system should show a notification that the recourses must increase.

Response time: the response should be fast, because if the system response slowly it will lead to lose

Mentality: the system can be modified easily, and when a part of it is being modified, the other part must work without failing, each part should be indecent off the other part.

Reliability: the system should do what it was created to do without an error, the presence of an error will leads to financial lose

  • The system should not turn off due to the presence of a system problem; which means that the system should not turn off when there is a problem of the system of itself.

Security: all of the customer’s information and worker’s in addition to invoice detail should be secured and encrypted in the database, and each user has different accessibility.

Extensibility: The system should be flexible, so it can be able to expand easy in the future.

Effectiveness: the performance should be as expected and related to the effort.

Failure management: the system should save any failure occur with date and time and the reason for this failure.

Stability: the system should be stabile and changes must not affect the system base.

Availability: the system should be available all the time.

Privacy: the information should be private and not all can see it.

Other: The connection with the bank should be secure and fast. The technology is to be used in the system should be advanced and robust.

 

 

The Risk:
Requirements change:
The system conceder as a business system, because it’s a hotel system. In business system it’s naturally that requirements may change from time to time. Furthermore changes will affect the affect schedule and the quality.

Lack of time: The project is complex and needs a lot of time, so the lack of time is a major risk and its will affect the schedule. As a result the project may not finish or finish but not in the time.

Staff turnover: One of the most important risks is, the team may breakdown and some of staff my leave the team. It will affect the project and the effort from the team members will increase.
Staff with requirements: It is hard to find recruit staff with required skills for this project.
Communication: The requirements from the client may be misunderstanding, the negatively change of stakeholder interests.

Quality: The non functional (quality) of the system may be not as expected. The system may be hard to use and not efficiency.

Estimation: The estimation may be wrong, and size underestimates occur.  

Assumptions: The assumption may be invalid for the project; this is a major risk because the system may be based on something wrong.

Design: The interface design or other design may be hard or impossible to meet the client requirements, using it.

Tools: The design or code generated by the tool may be inefficient and tools can’t work together.

People: The stuff doesn’t have the skills required; also the staff may be unavailable or ill at critical times, poor relationships amongst team members.

Technology:  The technology used can’t give what was expected, and the component that was planned to reuse cannot be reuse.

Product competition: Another product is produced before the system is complete.

 

 

 

 

 

 

Gantt chart:  

 

 

 

 

 

 

Dependency table:

Task Duration Dependencies
Requirements elicitation (T1) 2  
Software development method (T2) 3 T1
Project schedule (T3) 5 T2
Risk analysis (T4) 3  
Define non-functional properties (T5) 3  
Project Estimation (T6) 2  
Documentation (T7) 2 T3, T4, T5, T6
Review (T8) 2 T7
RAD (M1) 0 T8
Collect information (T9) 2 T8 (M1)
Use case diagram (T10) 2 T9
Use case specification (T11) 4 T10
Activity diagram (T12) 3 T11
System sequence diagram (T13) 2 T11
Domain model (T14) 2 T11
Documentation (T15) 1 T12, T13, T14
Review (T16) 1 T15
RAD(M2) 0 T16
Class Design (T17) 3 T16(M2)
Design sequence diagram (T18) 3 T17
State diagram (T19) 2 T17
Architecture design (T20) 2 T18, T19
Interface  design (T21) 3 T20
Database design(T22) 2 T21
Documentation (T23) 1 T22
Review (T24) 1 T23
RAD(M3) 0 T24
Use pattern (T25) 2 T24(M3)
Architecture (T26) 2 T24(M3)
Programming(T27) 7 T26,T25
Testing(T28) 1 T27
Documentation (T29) 1 T28
Review (T30) 1 T29
RAD  (M4) 0 T30

 

 

 

 

 

 

 

Dependency Graph:

 

Intermediate COCOMO Calculation:

Effort calculation:

 

Code of cost Driven Rating Effort multiplier
RELY high 1.15
DATA very high 1.16
CPLX Nominal 1
TIME very high 1.3
STOR high 1.06
VIRT Nominal 1
TURN Nominal 1
ACAP Nominal 1
AEXP Nominal 1
PCAP Nominal 1
VEXP low 1.1
LEXP high 0.95
MODP very high 0.82
TOOL very high 0.83
SCED high 1.04

TDEV Calculation:

Average Staffing Required Calculation:

Cost of the project Calculation:

 

Function Point Calculation:

  T number low Avg High UFC point
External Input 25 14 6 5 96
External output 30 5 15 10 165
Logical file 28 8 20 0 256
External Interface 5 0 2 3 44
Inquiry 20 12 5 3 74

 

 

  1. Data communications –strong influence throughout 5
  2. Distributed functions – no influence 0
  3. Performance – strong influence throughout 5
  4. Heavily used configuration – no influence 0
  5. Transaction rate – strong influence throughout 5
  6. On-line data entry – average influence 3
  7. End-user efficiency – average influence 3
  8. On-line update – average influence 3
  9. Complex processing – average influence 3
  10. Reusability – average influence 3
  11. Installation ease – strong influence throughout 5
  12. Operational ease – significant influence 4
  13. Multiple sites – no influence 0
  14. Facilitation of change – average influence 3

 

 

 

 

 

 

 

Assumption:
From the scenario we read that the requirements are clear and the customer knows exactly what he wants, according to that, we assume that there will be rare changes in the requirements. Additionally it seems that the customer wants the software to be delivered as fast as possible, but we assumed that the incremental deliver is unneeded.

From the qualities’ point of view we assume that some of non-functional options should be in the software. In the usability we assume that a help option and user manual should exist, in addition to the backup which should be easy to import and export, to make things easier for the user also to be secured that no financial lost will occur.

The performance should be as expected and related to the effort. In addition to the failure management function to save any failures and the reasons of that failure, so the reports can be used as a feed back to improve the system later. We assume that the system should be available all the time because it is a hotel system, so the work will never stop. Furthermore we assume that the privacy should be high and the system should be stable; because it is a business system.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Comprehensive report:
This is the first time for us to plan for a project. In the past, we used to read the scenario and then start coding immediately, then we do the test, the test was based on the function (method) itself. On the other hand this project has complex requirements, so it was hard to start coding, even to know objects are hard. Furthermore it was necessary to apply the concept of software engineering.

The first part was to decide which development method we will use, actually it was a hard task because it is our first time, in addition of the many existing process’s, such as the waterfall model, incremental model, rational unified process and spiral model. According to that we did some comparison between them, so we learnt what is the advantages and disadvantages of all the models.

In the second part, we learnt how to do the risk analysis. On the other hand we faced a lot of problems in this project, some of risks we faced it in the first milestone such as people risks, lack of time and experience. Alternatively we learned how to manage people and how to minimize the effect of the risk.

The third part was long but useful, we learned a lot of stuff the most important things we learned, how to plan for the schedule like planning for the activities, tasks and the duration time, another one is how to divide the effort between the team members. The second task was to use the tools to create the schedule, we used Microsoft Project which is a good tool, enabled us of saving a lot of time. Additionally for dependency graph it was hard to create it using word, so we found a good tool called Microsoft Visio.

Finally we learned how to apply the Intermediate COCOMO81 and the function point. In conclusion, this millstone was new and the difficulties we faced were so useful, as a result we gained good experience.

 

WE’VE HAD A GOOD SUCCESS RATE ON THIS ASSIGNMENT. PLACE THIS ORDER OR A SIMILAR ORDER AND GET AN AMAZING DISCOUNT