Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 16

1

DESIGN A SOLUTION

Submitted to:

Submitted by:

Date:

Institute:
2

Table of Contents
Task 1...........................................................................................................................................................2
Assessment of SDLC Models....................................................................................................................2
Waterfall Model.......................................................................................................................................2
Advantages:.........................................................................................................................................3
Disadvantages:.....................................................................................................................................3
Agile Model.............................................................................................................................................3
Advantages:.........................................................................................................................................4
Suitability for Driving School Scenario:....................................................................................................4
Task 2...........................................................................................................................................................5
Importance of Investigation Techniques..................................................................................................5
Example of Investigation Technique - Interview with the Owner:............................................................5
Significance of Interview:.........................................................................................................................5
Task 3...........................................................................................................................................................6
Detailed Design Documentation..............................................................................................................6
Flow Chart:..............................................................................................................................................6
Data Flow Diagrams:................................................................................................................................7
Context/0 Level Diagram:....................................................................................................................7
Level 1 Diagram:..................................................................................................................................8
Level 2 Diagram:..................................................................................................................................8
Data Dictionaries:................................................................................................................................8
Task 4...........................................................................................................................................................9
User Interface Design Documentation.....................................................................................................9
Data Entry Forms:....................................................................................................................................9
Report Forms:........................................................................................................................................10
Hardware and Software Requirements:.................................................................................................10
Part B.........................................................................................................................................................10
Factors Affecting Success:......................................................................................................................10
Factors Affecting Failure:.......................................................................................................................11
Alignment with User Requirements:......................................................................................................12
Possible Improvements and Further Developments:.............................................................................12
Reference..................................................................................................................................................14
3

Task 1
Assessment of SDLC Models
In choosing what kind of software development life cycle (SDLC) model to use for starting a
driving school, picking the right one is very important. This part looks closely at two main types,
called Waterfall Model and Agile Model. It talks about the good points of each in a driving
school situation while also explaining their bad parts too. Then, the importance of using careful
research methods to understand what is needed in a driving school system is explained (Taylor,
2008).

Waterfall Model
The Waterfall Model is an old and straight way to make software. It has many steps that follow
each other in order, with the last step depending on what happened before it. This way has good
points, especially because it gives a simple and easy-to-understand structure (The Traditional
Waterfall Approach).

Advantages:
Sequential Approach: One of the main good things about the Waterfall Model is that it happens
in order. This simple path helps builders and interested parties understand the project's shape and
changes. The process of going in a certain order, having parts like needs, plan making, doing the
job right and fixing mistakes helps manage projects better.
Well-Defined Phases: The model has clear steps, with each part offering different tasks and a set
check process. This careful drawing out makes it clear how a project is going. This helps to
watch and check what's happening with less trouble. People involved can easily see how far the
project has come and decide if it meets what was first asked for.
Stability: The Waterfall Model's ordered way makes it easy to handle changes. Because each
part has its own set of results, changes can be easily added at the start of making things. This
reduces problems later on (Benington, 1983).

Disadvantages:
Rigidity: Even though the Waterfall Model is well-organized, people say it's too stiff. When a
step is done, it's hard to go back and change things. This inability to bend can be a big problem,
especially when things are always changing and needs frequently shift.
4

Limited User Involvement: People are asked later in the process what they think, often during
testing time. This late help can make people unhappy because users may find out later on that
their needs were not understood right or wrong after a lot of work has been done.
Time-Consuming: The Waterfall Model says that the whole project must be done before testing
starts. This can take a lot of time, and problems might only show up later. This means going back
to earlier parts that need fixing again and could make project times longer still (Benington,
1983).

Agile Model
The Agile Model, a modern and iterative approach to software development, stands in stark
contrast to the rigid structure of the Waterfall Model. It embraces change and prioritizes
collaboration and adaptability throughout the entire development life cycle (State of Agile
Development Survey Results, 2011).

Advantages:
Flexibility: Agile's main strength is its ability to be flexible. The model is open to improvements
and updates even during the later part of its development. This ability to change is very helpful in
places where needs are always changing. It often happens at fast-moving places like a driving
school, where rules and situations can quickly shift (Blanchard & Fabrycky, 2006, p. 19).
Frequent Deliveries: Agile uses cycles that happen in small parts. It gives working software at
the same time again and again, called sprints. This step-by-step delivery method makes sure that
people involved get useful results as the project goes on.
Customer Satisfaction: Agile gives a lot of importance to constant talk and getting users
involved. This way of focusing on the customer makes sure that what they get is as good or even
better than expected. Developers and users keep giving each other feedback. This helps improve
features, functions, and overall enjoyment by making them even better(Royce, 2018).

Disadvantages:

Complexity: Sometimes, the flexibility that Agile supports can cause a project structure to
become too complex. Handling many changes and updates need a skilled team that can change
quickly. The difficulty might go up as the project gets bigger and more widespread.
5

Resource Intensive: Working together and talking all the time is good but it might need extra
help. Having a strong team with lots of skills during the development process needs more
resources than models where teams don't interact so often.
Documentation Challenges: Often, Agile puts working software before heavy
documentation. Even though this method helps us respond fast to changes, it can make keeping
records complete difficult (Dr. Joahn Gouws, 2007).

Suitability for Driving School Scenario:


Because driving schools can change a lot, the Agile method is better for handling those
changes. Its ability to change often matches well with the changing needs of driving school. The
skill to use ongoing input makes sure that the made system stays closely focused on what's
needed by driving school and its learners. Here, the idea of putting customers first and being able
to change quickly in Agile model is helpful. This helps make software making better and faster
(State of Agile Development Survey Results, 2011).

Task 2
Importance of Investigation Techniques
The thorough understanding of user needs and system requirements is paramount in crafting an
effective and efficient driving school system. Utilizing appropriate investigation techniques is
crucial in this context, as it allows for a comprehensive exploration of the current processes,
challenges, and aspirations of stakeholders. By employing diverse methods such as interviews,
observations, and questionnaires, a holistic and accurate requirements specification can be
formulated (Cunningham, 2009, p. 49).

Example of Investigation Technique - Interview with the Owner:


Conducting an interview with the driving school owner is a pivotal step in gathering insights into
high-level business goals and expectations. Through structured questioning, the owner can
elucidate overarching objectives, preferred system functionalities, and key performance
indicators. For instance, in an interview, the owner may express the need for a centralized
6

scheduling system to optimize lesson allocation or a robust reporting feature to monitor


instructor performance (Royce, 2018).

Significance of Interview:
• High-Level Vision: Interviews give a chance to talk about the boss's big ideas for how driving
schools should work. This knowledge is basic to match the growth process with main business
goals.
• Clarification of Ambiguities: Talks can help in understanding confusing parts better and make
sure everyone agrees on the main things needed. This stops wrong understandings later when
building something is happening.
• Establishing Rapport: Making friends with the boss helps to create a team-like setting. This
raises the chances of getting honest and important details (Saff & Snider, 2020).

Incorporating a variety of investigation techniques ensures a multifaceted understanding of


requirements, thereby contributing to a more accurate, comprehensive, and user-centric
specifications document for the driving school system. Examples of interviews, observations,
and questionnaires can be included in an appendix to provide transparency into the investigative
process and validate the robustness of the gathered requirements(Petersen et al., 2009).

Task 3
Detailed Design Documentation
The chosen methodology is Agile.
7

Flow Chart:

Start

Input:

Student name

Validation

Checks

Valid: Invalid:
Record student Error
booking

Agile sprint
cycle

Iterative

Development

End

Next sprint
8

Data Flow Diagrams:


Context/0 Level Diagram:

Agile Development

Level 1 Diagram:

Student booking agile


process

Level 2 Diagram:

User Input

Validation

Record
keeping
9

Data Dictionaries:
Data Name: StudentName

Type: String

Field Size: 50

Source: User input

Input Method: Text field

Validation Checks: Alphabetic characters only

Scope and Constraints: The system encompasses student booking, instructor records, and test
management. Constraints include budget limitations and a timeline for implementation.

Recommended Solution: Implement an Agile development process with regular sprint cycles
and continuous user feedback.

Task 4
User Interface Design Documentation
The UI plan for the driving educational system has been exactingly made to ensure an intuitive
and viable experience for clients. The plan incorporates data entry structures, report designs, and
examinations for hardware and programming necessities.

Data Entry Forms:


Layout and Structure: The information passage structures are planned with a clean and easy to
use design. Each structure understands a legitimate grouping, directing clients through the
essential data section focuses. Tabs or segments isolate various classes of information, for
example, understudy subtleties, illustration appointments, and educator records, adding to an
outwardly coordinated interface (Weinstein, 2020).

Proposed Fields: The data entry structures are arranged with a perfect and simple to utilize plan.
Each construction comprehends a real gathering, coordinating clients through the fundamental
10

information segment centers. Tabs or portions disengage different classes of data, for instance,
student nuances, outline arrangements, and instructor records, adding to an obviously planned
interface.

Data Entry Methods: Client input is worked with through direct text fields, dropdown menus,
and date/time pickers were pertinent. Input endorsement checks, for instance, ensuring alphabetic
characters for names or real date plans, add to data precision. The arrangement emphasizes
straightforwardness to oblige clients with changing particular capacity.

Report Forms:
The revealing structures are intended to introduce data extensively and naturally. Example plans
give a visual portrayal of booked illustrations, classified by educator and date. Understudy
progress reports offer itemized experiences into individual execution and achievements
accomplished. The design of these reports is organized to work with speedy translation and
decision-production for the two educators and the board (Weinstein, 2020).

Hardware and Software Requirements:


The driving educational system is intended to be adaptable regarding equipment and
programming similarity. It is online, guaranteeing openness across various gadgets like work
areas, PCs, and tablets. The UI is upgraded for famous internet browsers, advancing a consistent
encounter for clients independent of their working framework inclinations. The framework's
basic foundation prerequisites are negligible, guaranteeing simplicity of organization and
versatility (Weinstein, 2020)

Part B
The good or bad results on a computer code project depend on many things that are important.
These include risks, money control, getting partners involved and skills of the team who make
it. In this full review, we look closely at the main parts that can make a winning driving school or
cause it to fail.
11

Factors Affecting Success:


Risk Management: Ordinary gamble appraisals and the plan of compelling moderation
procedures stand as key parts for progress. Recognizing likely difficulties and tending to them
proactively guarantees that the undertaking explores through vulnerabilities, hence adding to task
consummation inside the designated financial plan.

Costs and Time Constraints: Adherence to monetary and course of events limitations is basic
for project achievement. A careful monetary arrangement and a sensible venture plan act as
directing points of support. Observing consumptions and timetable adherence all through the
improvement life cycle forestalls spending plan invades and delays, encouraging a smooth
movement toward project objectives.

Change Management and User Involvement: A powerful framework like a driving school
requests an elevated degree of flexibility. Proactive change the board is essential to guarantee
that alterations and improvements are consistently incorporated. Nonstop client contribution is
similarly principal, as it adjusts the framework intimately with end-client needs. This iterative
cooperation limits the gamble of fostering a framework that doesn't meet client assumptions.

Staff Skills: The capability of the improvement group is a foundation of progress. Guaranteeing
that colleagues have the imperative abilities and mastery in Spry philosophies, programming
advancement dialects, and the particular area of the driving educational system is essential. A
skillful group contributes not exclusively to the effectiveness of the improvement cycle yet
additionally to the nature of the eventual outcome.

Factors Affecting Failure:


Poor Risk Management: Insufficient gamble the executives can be a harbinger of
disappointment. Inability to recognize, evaluate, and relieve dangers can prompt flowing
outcomes, including project postponements and financial plan overwhelms. Unanticipated
difficulties that are not tended to as soon as possible might heighten, imperiling the general
outcome of the task (Weinstein, 2020).

Inadequate User Involvement: Absence of constant client contribution remains as a risky


entanglement. Inability to connect with end-clients all through the improvement life cycle might
12

bring about a framework that veers off from client assumptions. This misalignment can prompt
disappointment and dismissal of the executed arrangement, eventually comprising a
disappointment in conveying a framework that meets its planned reason (Sloane, 2018).

Lack of Staff Skills: Ineptitude inside the improvement group represents a considerable danger.
A group coming up short on the imperative abilities might battle with framework plan, execution,
and support, prompting sub-par improvement results. Inadequately created and kept up with
frameworks can turn into a wellspring of dissatisfaction for clients and may require broad
modify, adding to project disappointment.

Finally, the driving school system's success or failure depends on careful balance of these
things. A well-handled risk area, sticking to money and time limits, flexible change planning,
always involving users and a good development group all together make the base for winning
project results. On the other hand, mistakes in these areas like bad risk handling, not enough
users involved and workers having low skills can lead to possible project failure. In dealing with
these things, a careful and thought-out way is needed. This makes sure that everything important
gets looked at carefully as the project goes on (Sloane, 2018).

Alignment with User Requirements:


Flexibility through Agile Methodology: The social event of the agile model is a conscious
decision to address the extraordinary idea of the driving tutoring framework. This model thinks
about steady changes and updates generally through the improvement cycle, lifting versatility to
propelling necessities. The planned instances of Agile work with unremitting data, guaranteeing
that the framework remains positively open to the impelling necessities of both the driving
school and its understudies (Gaughan, 2009).

User-Centric Design: The UI arrangement, including information portion structures for


understudy subtleties, model plans, and teacher records, has been conceptualized with a client
driven approach. By blending client investigation and recollecting that them for the course of
action cycle, the framework is interestingly intended to be typical and fruitful. This approach
fosters a positive client experience, head for a construction that consolidates different assistants
like understudies, instructors, and regulatory staff.
13

Comprehensive Reporting: The announcing highlights, including frame plans and understudy
progress reports, address the data needs of the two instructors and the pioneers. These reports
give basic experiences into portrayal plans, understudy execution, and in ordinary framework
capacity. By offering a degree of organizing choices, the plan guarantees that accessories can get
to basic and gigantic data easily (OEIS Index, 2020).

Possible Improvements and Further Developments:


Enhanced User Feedback Mechanism: While the Agile technique innately includes client
criticism, further enhancements can be made by carrying out a more organized and exhaustive
input system. Customary reviews, center gathering conversations, or client testing meetings
could be integrated to assemble nitty gritty bits of knowledge. This would add to refining the
framework ceaselessly founded on client inclinations and assumptions (Gaughan, 2009).

Integration of Advanced Analytics: To lift the examination of delineations taken and structure
execution, the system could be updated with state-of-the-art assessment limits. This could
incorporate merging data portrayal gadgets or simulated intelligence estimations to get further
pieces of information from the data accumulated. This would empower the driving school with
insightful examination and example assessment for better free course.

Expansion of Mobile Accessibility: Considering the rising reliance on PDAs, expanding the
system's accessibility through dedicated convenient applications can further develop client
solace. Students and teachers could without a doubt get to and manage their plans, track
progress, and pass immaculately on through versatile stages, propelling a more apt and in a rush
client experience (OEIS Index, 2020).

Taking everything into account, the plan of the driving educational system really meets the
distinguished client necessities by embracing Agile standards and focusing on client driven plan.
Be that as it may, there is dependably opportunity to get better. Carrying out a more criticism
component, incorporating progressed examination, and growing versatile openness can move the
framework higher than ever, guaranteeing a consistently developing and versatile arrangement
that stays in front of client assumptions (OEIS Index, 2020).
14

Reference
Agile modeling (AM) home page, effective practices for modeling and documentation

"State of Agile Development Survey Results, 2011". Archived from the original on 2015-07-17.
Retrieved 2014-06-26.

Algraphy, Hessa Abdulrahman A.; Lano, Kevin Charles (January 2017). "The Integration of
Agile Development and Model Driven Development: A Systematic Literature Review". The 5th
International Conference on Model-Driven Engineering and Software Development: 451–
458. doi:10.5220/0006207004510458. ISBN 978-989-758-210-3. S2CID 11369604.

Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). "The Waterfall Model in Large-Scale
Development". In Bomarius, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka
(eds.). Product-Focused Software Process Improvement. Lecture Notes in Business Information
Processing. Vol. 32. Berlin, Heidelberg: Springer. pp. 386–
400. Bibcode:2009pfsp.book..386P. doi:10.1007/978-3-642-02152-7_29. ISBN 978-3-642-
02152-7.

"The Traditional Waterfall Approach". www.umsl.edu. Retrieved 2022-02-23.

Benington, Herbert D. (1 October 1983). "Production of Large Computer


Programs" (PDF). IEEE Annals of the History of Computing. IEEE Educational Activities
Department. 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. S2CID 8632276. Retrieved 2011-
03-21. Archived July 18, 2011, at the Wayback Machine
15

United States, Navy Mathematical Computing Advisory Panel (29 June 2019), Symposium on
advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval
Research, Dept. of the Navy, OCLC 10794738

Royce, Winston (2018), "Managing the Development of Large Software


Systems" (PDF), Proceedings of IEEE WESCON, 26 (August): 1–9

Weisstein, Eric W. "Sequence". mathworld.wolfram.com. Archived from the original on 2020-


07-25. Retrieved 2020-08-17.

Index to OEIS Archived 2022-10-18 at the Wayback Machine, On-Line Encyclopedia of Integer
Sequences, 2020-12-03

Sloane, N. J. A. (ed.). "Sequence A005132 (Recamán's sequence)". The On-Line Encyclopedia


of Integer Sequences. OEIS Foundation. Retrieved 26 January 2018.

Gaughan, Edward (2009). "1.1 Sequences and Convergence". Introduction to Analysis. AMS
(2009). ISBN 978-0-8218-4787-9.

Edward B. Saff & Arthur David Snider (2020). "Chapter 2.1". Fundamentals of Complex
Analysis. Prentice Hall. ISBN 978-01-390-7874-3. Archived from the original on 2023-03-23.
Retrieved 2015-11-15.

Taylor, G.D. (2008). Introduction to Logistics Engineering. CRC Press. pp. 12.6–
12.18. ISBN 9781420088571.

^ "Chapter 5". Information Systems Control and Audit (PDF). Institute of Chartered Accountants
of India. August 2013. p. 5.28.

^ Radack, S. (n.d.). "The system development life cycle (SDLC)" (PDF). National Institute of
Standards and Technology.

^ Blanchard and Fabrycky (2006). Systems Engineering and Analysis, Fourth Edition. Prentice
Hall. p. 19.

^ Dr. Joahn Gouws (2007). Introduction to Engineering, System Engineering. Melikon Pty Ltd.

^ Cunningham, James. "HERC Maintenance". Fargo. XXI (North Avenue): 49. Archived
from the original on 21 January 2013. Retrieved 13 May 2009.
16

You might also like