Assessment 1 – Systems Development
Table of Contents
2. Approach to Systems Development 1
2.1 Developing system for Ryan Aviation. 1
2.2 Justification of chosen system development approach. 1
3.1 Functional Requirements. 2
3.2 Non-Functional Requirements. 3
4. Project Cost Benefit Analysis. 3
6. System Information Requirement Investigation Techniques. 7
6.2 Investigation Techniques. 7
7. Reflections and Conclusions. 8
1. Introduction
The main aim of Ryan Aviation is to develop an Online System which can provides online reports. The problem Ryan Aviation encountered was that all data were kept manually which use to consume lots of time and labour cost.
The main objective of system are:
- Helicopter: Flights, Types, Capacity, Licence level, Engine hours and Ratings
- Staff: Pilot rating, Skills and flight time log.
- Spare parts: Part number, Description, Price.
- Retardant and Water sources: Location, Litres and Retardant price.
- Scheduling: Passenger, Helicopters, Staff, Fire operations and associated support.
- Booking, Billing and Payments.
- Tracking: Fire retardant, Water.
- Aircraft Maintenance: Detail of parts.
- Staff scheduling: Timesheets, Staff, Pilots, Leaves and Payroll.
2. Approach to Systems Development
2.1 Developing system for Ryan Aviation
There are various approaches available to create a new good system to develop a good system for Ryan Aviation, such as Rapid Application Development, Joint Application Design, Agile, Waterfall model, etc. But above all Waterfall model approach is my preferable choice. Since, Ryan Aviation use to keep records manually data collected were not so accurate and consume lots of time and labour cost. To build Ryan Aviation’s online system, we need to consider and define the criteria, analysis and scope determination, and the best alternative to use.
2.2 Justification of chosen system development approach
First of all, to understand any kind of solution, we need to know what the main issues currently are and what the criteria we need to create a good programme are. Ryan Aviation has a problem with comprehensive manual knowledge. Therefore, to please all employees involved, they need a programme.
The waterfall model, also referred to as the classic life cycle, implies a systematic, sequential approach to software development that starts with customer requirement specification and progresses through planning, design, construction and implementation, resulting in continuous support of the completed software (Pressman, R., 2014). Some of the advantages are:
- It’s easy to understand and easy to use.
- Cost of this model is cheap in compare to other model.
- The durability of the platform makes it easy to handle. – Waterfall model step has a specific outcome and a review process.Every Phases are processed and completed one at a time.
- Deadlines may be set for each and every stage of development.
3. Systems Requirements
Mainly there are two types of system requirements: first, functional and second, non-functional. Here, functional requirements address the framework needs to be built, while non-functional requirements address quality and safety (Kendall and Kendall, 2011).
3.1 Functional Requirements
Functional Requirements are the bridge between the business and technical teams and provide a definition of what the system needs to do for its users, which in turn will meet business objectives (Sparx System and Stephen Magurie, 2016).
1. Registration Subsystem
- Registration of pilot, staff and any member who want to use system.
- Collecting details of pilots, staff and other users.
2. Tracking and maintenance Subsystem
- Able to locate water resources, maintenance stock level of parts and fire-retardant materials.
3. Inventory Subsystem
- Database to keep details of pilot and staff working.
- Provide availability and non-availability pilot and staffs.
- Provide accurate details.
4. Financial Subsystem
- Maintain all transaction record Provide accurate details.
- Manage employee’s payroll after every transition.
5. Control and management Subsystem
- Update as per received client feedback.
- Manage details of all employee’s.
- Maintaining timetables of every flight.
3.2 Non-Functional Requirements
Non-functional specifications define the performance of a device when it is running. They usually describe or limit how the entire system will behave, including characteristics such as how well it operates, how stable it is, how many times it develops a fault, and how easily it can be expanded (Sparx System and Stephen Magurie, 2016).
- Safety and security are necessary for every system.
- Faster data retrieve, storage and update.
- Payment is safe and secure.
- Century of accurate reporting.
4. Project Cost Benefit Analysis
There are many well-known methods to compare the proposed system’s costs and benefits. These provide analysis of break-even, payback, analysis of cash-flow and analysis of present value. All of these techniques provide simple ways to provide decision-makers with information about the value of the proposed system (Kendall and Kendall, 2011).
The cost-benefit analysis is carried out in the Ryne Aviation project to test economic feasibility. To find Ryan Aviation Benefit Analysis, we had to measure NPV (Net Present Value), BEA (Break Even Analysis), ROI (Return on Investment) and one-time costs. The worksheets shown excel indicate the overall costs and benefits involved during the entire development of the project. In this project Ryan Aviation has earmarked a budget of $200,000 for this project with a discount rate of 9% with reducing cost by $8,500 per month as well as maintenance cost of $1500 per month. With the help of this data Cost Benefit Analysis is calculated.
Table: Cost Benefits Analysis
https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-4462760071454301 (adsbygoogle = window.adsbygoogle || []).push({});5. Project Schedule
Divide the project into activities that can be handled. During the project planning process, this task is important. There, you have to split the entire project into manageable tasks and then logically order them to ensure that projects grow smoothly. The description and sequence of tasks is referred to as the framework of job breakdown (WBS) (Valacich, Gearge and Hoffer, 2016).
Figure 1 demonstrates the Ryne Aviation project’s job breakdown structure. It separates activities into specifications, system design, implementation, installation and testing, delivery and maintenance. Such tasks are also further categorised as a display diagram into various sub-tasks.
Figure 1: Work Break down structure
Figure 2: Gantt chart
Figure 2 describes the Gantt chart of Ryne Aviation project. Here total days required to complete task is 23 days. Since, delay can occur in the project the task in red colour indicate the critical path in Gantt chart.
6. System Information Requirement Investigation Techniques
6.1 Stakeholders
Any person or group that influences or is influenced by research is a stakeholder. This broad, inclusive definition includes anyone, or any entity, directly or indirectly affected by a project, as well as those who may have interest in a project and/or the ability to influence its outcome, either positively or negatively. To order to be impacted by them, a stakeholder does not need to be a primary recipient of or directly affected by project results. (Durham E., Baker H., Smith M., Moore E. & Morgan V., 2014).
As for Ryne Aviation Stakeholders may be both internal and external.
Internal Stakeholders: Internal stakeholders influence the business internally meaning internally involve persons or organizations. During this Ryne Aviation internal stakeholders as workers, manager, Owner, IT employees and technicians.
External Stakeholders: External stakeholders are those who are involve in outside activities of the system functions. In this Ryne Aviation internal stakeholders are customer, client and income tax office.
6.2 Investigation Techniques
1 Interviewing and Listening:
Interviewing is one of the primary ways for researchers to collect information about a project for information systems. You collect facts, perceptions, and assumptions during the interview and analyse the language of the body, attitudes, and other indicators of what people want and how they evaluates current systems (Valacich, Gearge and Hoffer, 2016).
Usefulness: If any confusion are there it can be clarified instantly since, it is face to face interview.
2. Questionnaire:
One way to get all the information you want is to receive it from the manufacturer about a software package. Some of this material may be found in the professional marketing literature and software documentation (Valacich, Gearge and Hoffer, 2016).
Usefulness: This method is easy to analyse, cost-effective, easy to gather information.
3. Observation:
Nonetheless, the purpose behind collecting system documents and direct observation is the same, and that is to obtain more first-hand and accurate measurements of interaction between employees and information systems (Valacich, Gearge and Hoffer, 2016).
Usefulness: This method is quick and fast methods in ordered to gather information. It creates real time working scenario and data can be easily analysis.
7. Reflections and Conclusions
Main constrains I found regarding this project is select wrong parts like unrelated data. It needs vital activity and time to search out unrelated data. Conducting various meetings between departments and bad communication between user and developers are the main problems. Biggest achievement achieved was customer satisfaction and cost of developing project was very low in compare to other.
Hence, this system will remove old manual system. It will generate accurate details as per customer needs. Paper work is reduced and search of knowledge would be a lot of correct and simple to find. Therefore, time and cost are also reduced.
8. References
Kendall, K, & Kendall, J 2011, Systems Analysis And Design, Upper Saddle River, N.J Pearson, [2010] c2011.
Pressman, R. (2014). Software engineering. 7th ed. New York: Mcgraw-Hill, p.39.
Sparx, S. and Stephen, M. (2016). Software requirements engineering. 1.0 ed. Enterprise Architect.
Valacich, Gearge and Hoffer 2016. Essential of system analysis and design.5th ed. p.54.
Durham E., Baker H., Smith M., Moore E. & Morgan V. (2014). The BiodivERsA Stakeholder Engagement Handbook. BiodivERsA, Paris (108 pp).
Uni Assignments For MIT students 