Higher Nationals

Internal verification of assessment decisions – BTEC (RQF)

INTERNAL VERIFICATION – ASSESSMENT DECISIONS
Programme title HND in Computing

Assessor Internal Verifier

Unit 35: System Analysis & Design
Unit(s)
Web based System for “Auto Cars”
Assignment title

Student’s name
List which assessment criteria Pass Merit Distinction
the Assessor has awarded.

INTERNAL VERIFIER CHECKLIST

Do the assessment criteria awarded match

those shown in the assignment brief? Y/N

Is the Pass/Merit/Distinction grade awarded

justified by the assessor’s comments on the Y/N
student work?
Has the work been assessed Y/N
accurately?
Is the feedback to the student:
Give details:
• Constructive? Y/N
• Linked to relevant assessment criteria? Y/N
Y/N
• Identifying opportunities for
improved performance?
Y/N
• Agreeing actions?
Does the assessment decision need Y/N
amending?

Assessor signature Date

Internal Verifier signature Date

Programme Leader signature (if required)
Date
Confirm action completed
Remedial action taken
Give details:

Assessor signature Date

Internal Verifier
signature Date

Programme Leader
signature (if required) Date
Higher Nationals - Summative Assignment Feedback Form
Student Name/ID

Unit Title Unit 35: System Analysis & Design

Assignment Number 1 Assessor

Date Received
Submission Date 1st submission
Date Received 2nd
Re-submission Date submission

Assessor Feedback:
LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis methodologies
Pass, Merit & Distinction P1 M1 D1
Descripts

LO2 Produce a feasibility study for a system for system to be developed to solve a business-related
problem
Pass, Merit & Distinction P2 M2
Descripts

LO3 Assess systems analysis methodologies to effectively solve business-related problems

Pass, Merit & Distinction P3 M3 D2

Descripts

LO4 Design the system to meet user and system requirements.

Pass, Merit & Distinction P4 M4
Descripts

Grade: Assessor Signature: Date:

Resubmission Feedback:

Grade: Assessor Signature: Date:

Internal Verifier’s Comments:

Signature & Date:

* Please note that grade decisions are provisional. They are only confirmed once internal and external moderation has taken place and
grades decisions have been agreed at the assessment board.
Pearson Higher Nationals in
Computing
Unit 35: Systems Analysis & Design
Assignment 01
General Guidelines

1. A Cover page or title page – You should always attach a title page to your assignment. Use
previous page as your cover sheet and make sure all the details are accurately filled.
2. Attach this brief as the first section of your assignment.
3. All the assignments should be prepared using a word processing software.
4. All the assignments should be printed on A4 sized papers. Use single side printing.
5. Allow 1” for top, bottom , right margins and 1.25” for the left margin of each page.

Word Processing Rules

1. The font size should be 12 point, and should be in the style of Time New Roman.
2. Use 1.5 line spacing. Left justify all paragraphs.
3. Ensure that all the headings are consistent in terms of the font size and font style.
4. Use footer function in the word processor to insert Your Name, Subject, Assignment No,
and Page Number on each page. This is useful if individual sheets become detached for any
reason.
5. Use word processing application spell check and grammar check function to help editing
your assignment.

Important Points:

1. It is strictly prohibited to use textboxes to add texts in the assignments, except for
compulsory information. eg: Figures, tables of comparison etc. Adding text boxes in the body
except for the before mentioned compulsory information will result in rejection of your
work.
2. Carefully check the hand in date and the instructions given in the assignment. Late
submissions will not be accepted.
3. Ensure that you give yourself enough time to complete the assignment by the due date.
4. Excuses of any nature will not be accepted for failure to hand in the work on time.
5. You must take responsibility for managing your own time effectively.
6. If you are unable to hand in your assignment on time and have valid reasons such as illness,
you may apply (in writing) for an extension.
7. Failure to achieve at least PASS criteria will result in a REFERRAL grade .
8. Non-submission of work without valid reasons will lead to an automatic RE FERRAL. You will
then be asked to complete an alternative assignment.
9. If you use other people’s work or ideas in your assignment, reference them properly using
HARVARD referencing system to avoid plagiarism. You have to provide both in-text citation
and a reference list.
10. If you are proven to be guilty of plagiarism or any academic misconduct, your grade could be
reduced to A REFERRAL or at worst you could be expelled from the course.
Student Declaration

I hereby, declare that I know what plagiarism entails, namely, to use another’s work and to present
it as my own without attributing the sources in the correct form. I further understand what it
means to copy another’s work.

1. I know that plagiarism is a punishable offence because it constitutes theft.

2. I understand the plagiarism and copying policy of Edexcel UK.
3. I know what the consequences will be if I plagiarise or copy another’s work in any of the
assignments for this program.
4. I declare therefore that all work presented by me for every aspect of my program, will be my
own, and where I have made use of another’s work, I will attribute the source in the correct
way.
5. I acknowledge that the attachment of this document signed or not, constitutes a binding
agreement between myself and Pearson , UK.
6. I understand that my assignment will not be considered as submitted if this document is not
attached to the assignment.

Student’s Signature: Date:

(Provide E-mail ID) (Provide Submission Date)
Higher National Diploma in Computing
Assignment Brief
Student Name /ID Number

Unit Number and Title Unit 35: Systems Analysis & Design

Academic Year 2022/23

Unit Tutor

Assignment Title
Issue Date

Submission Date

IV Name & Date

Submission format

The submission should be in the form of an individual written report written in a concise,
formal business style using single spacing and font size 12. You are required to make use
of headings, paragraphs and subsections as appropriate, and all work must be supported
with research and referenced Please provide in-test citations, reference list and
bibliography using Harvard referencing system. Please also provide a bibliography using
the Harvard referencing system.
The recommended word limit is not less than 5000 words, although you will not be
penalised for exceeding the total word limit.

Unit Learning Outcomes:

LO1 Evaluate the strengths and weaknesses of the traditional and agile systems analysis
methodologies.
LO2 Produce a feasibility study for a system to be developed to solve a business-related
problem.
LO3 Assess systems analysis methodologies to effectively solve business-related problems.
LO4 Design the system to meet user and system requirements.

Assignment Brief and Guidance:

*Please note that assignment guidance is for reference only and should be more specific in
detail to meet customized needs.
Assignment brief
Case study
“Auto Cars” is a taxi service in Sri Lanka which has been in operation for several decades,
serving the customers in city and urban areas. As a result of the increased use of
information technology such as mobile phones and the internet, “Auto Cars” decided to
launch a web-based system that enables customers to reserve vehicles conveniently. This
also helps the company to gain a competitive advantage.
The main system features of the web-based system are required for “Auto Cars” to reserve
taxis for customers are:
a. Customers and drivers can use the online system to register. They will receive an
email with their username and password once they have registered.
b. Customers can book taxis via the website. When they reserve a vehicle, they will
receive an SMS on their phone with the driver's contact information and vehicle
details.
c. Customers can rate drivers based on their experiences with them on trips.
d. In addition, the company employs a phone operator who manually reserves drivers
from the system. This is the same as a customer reserving a driver, except there is
no logged in customer in the application.
e. When the operator makes a taxi reservation, she enters the customer's phone
number into the system, and the customer receives an SMS.
f. The driver closest to the customer must be assigned by the application. When a
customer or the operator reserves a vehicle, the system should display a list of
available drivers. From this list, the customer can then select the best driver.
g. The driver’s location is manually (by the driver) entered into the web-based system
or via the telephone operator. Similarly, when reserving a taxi, the customer's
location is specified (by the customer or through the operator).

Assume that you are the newly appointed system analyst for “Auto Cars” and assigned to
work on this project. Produce a professional report including the answers to the following
tasks.
Activity 01
Discuss and critically evaluate the strengths and weaknesses of the traditional and agile
systems analysis methodologies. Compare the strengths and weaknesses of the two
methodologies by referring to the proposed web system for “Auto Cars”.

Activity 2
Conduct the feasibility study for the web-based system for “Auto Cars” and produce a
feasibility report. Further, evaluate the importance of the feasibility criteria used to
investigate the feasibility of the proposed system.

Activity 3
Review the user and system requirements for the web-based system suggested in the
scenario using a suitable software development methodology and asses the effectiveness
of the methodology selected. Justify the chosen methodology for the web-based system
with relevant examples.

Activity 4
Design a system specification for the web-based system to meet end user system
requirements and assess the effectiveness of your design and the methodology used with
reference to how it meets the user requirements.
Your system design specification should include,
 Data Flow diagrams (context diagram, Level 0, level 1 , level 2 DFDs)/ Use case
diagram
 Entity Relationship diagram (ERD)
 Flow charts
 Prototypes to illustrate system interfaces and functions.
 Release plan and tools
Grading Criteria Achieved Feedback

LO1 Evaluate the strengths and weaknesses of the

traditional and agile systems analysis methodologies.

P1 Discuss the strengths and weaknesses of the traditional

and agile systems analysis methodologies.

M1 Compare and contrast the strengths and weaknesses of

the traditional and agile systems analysis methodologies with
reference to a specific business-related problem.

LO2 Produce a feasibility study for a system to be developed

to solve a business-related problem.

P2 Produce a feasibility study for a system for a

business related problem.

M2 Evaluate the importance of the feasibility criteria in the

systems investigation for the business related

problem.

LO1 & LO2

D1 Critically evaluate the strengths and weaknesses of
the traditional and agile systems methodologies and
feasibility study in solving a specific business-related problem.

LO3 Assess systems analysis methodologies to effectively

solve business-related problems

P3 Review a system using a suitable methodology for a

business-related problem.

M3 Asses the effectiveness of the methodology used in

providing a solution for a given business context.

LO4 Design a system to meet user and system

Requirements
P4 Design a fully functional system to meet user and
system requirements for the business-related
problem.

M4 Assess the effectiveness of the system design, with

reference to the methodology used and how the design
meets user and system requirements.

LO3 & 4
D2 Justify the choice of the methodology used in
the context of the business problem.
Contents
1 Activity 01........................................................................................................................................................................................................ 15
1.1 What is a system....................................................................................................................................................................................... 15
1.2 Role of a system analyst........................................................................................................................................................................... 15
1.3 What are the traditional methodologies.................................................................................................................................................. 16
1.4 Agile methodologies................................................................................................................................................................................. 27
1.5 Strength and weakness of traditional methodologies and Agile methodologies.....................................................................................35

FIGURE 1TRADITIONAL METHODOLOGIES....................................................................................................................................................................................................................... 16

FIGURE 21.WATERFALL MODEL................................................................................................................................................................................................................................... 19
FIGURE 3INCREMENTAL MODEL................................................................................................................................................................................................................................... 22
FIGURE 4PROTOTYPE MODEL....................................................................................................................................................................................................................................... 24
FIGURE 5 SPIRAL MODEL............................................................................................................................................................................................................................................ 26
FIGURE 6 AGILE MODEL.............................................................................................................................................................................................................................................. 29
FIGURE 7 SCRUM MODEL........................................................................................................................................................................................................................................... 31
FIGURE 8 XP........................................................................................................................................................................................................................................................... 33
1 Activity 01

1.1 What is a system

A system is any entity comprised of related yet separate elements that function together to achieve a common objective. The makeup of a
typical system within information technology would basically consist of hardware, software, data, procedures, and people. In the case of
"Auto Cars," the web-based taxi reservation system is the quintessential example of a system wherein the following applies:

 Hardware: The servers and users' devices, such as computers and smartphones.
 Software: Web app, and back-end databases.
 Data: Customer Information, driver details, and booking data.
 Procedures: Reservation processes, user registrations, and driver assignments.
 People: customers, drivers, and system administrators.

1.2 Role of a system analyst

 Requirements Gathering

Understanding the need: The system analyst has to interact with the users, clients, and stakeholders through interviews,
questionnaires, and workshops in order to know their needs and expectations from the system.

Documentation: When these needs are determined, then the analyst would document these needs in a tabular form and often draws up
requirement specifications which would be serving as an avenue guide to developing such a system.

 System Design

Modeling: The system analyst will now create models and diagrams using the requirements from earlier on how the system will
perform. These could be in the form of flowcharts, data models, and wireframes. Specification: Specifications are provided in detail
 by the analyst for the system components, including user interface, data structure, and interaction. This makes sure that the design
meets the requirements. Evaluation:

Uncovering the Shortcomings of Current Systems: The analyst researches the current systems for flaws or anything that could be
improved. This may involve performance analysis, evaluation of users' responses, and technological reviews.

Recommendation: Based on the aforementioned study, the analyst may recommend tuning, re-designing, or altogether abandoning a
present system in support of one that will better fulfill the necessary business functions.

 Communication:

Bridging gaps: The system analyst bridges the gap between technical teams, such as software developers, and other non-technical
stakeholders, such as business clients. They are responsible for explaining what the technical jargon terms mean to the stakeholders
and vice versa.

Smoothening collaboration: Good communication ensures a common understanding of goals, requirements, and progress is had by all
concerned with the project.
 Testing:

Validation: This implies that the analyst participates to ensure the system will actually meet the set requirements by leading
contributing to a number of testing activities. This may also involve test planning, identification, and development of test scenarios
and test cases, which shall be utilized in the course of testing for the said system to work out as expected.
Resolution of Issues: They also contribute to the identification and resolution of any issues or defects noted during the tests to ensure
the final product is quality-assured and meets user needs.

1.3 What are the traditional methodologies

Traditional project management approaches follow a linear process that consists of five main phases nitiation, planning, execution,
monitoring, and closing. This method places a strong emphasis on thorough initial planning, documentation, and prioritization. At the very
start, it's essential to clearly define the project scope and establish the necessary requirements.
 Because of this structured approach, having a project manager or a Project Management Office (PMO) is important. This role is critical as
the project manager oversees the entire project and is responsible for achieving its goals. Once the project's scope is set and the initiation
phase begins, any changes that arise need to be carefully managed through a formal change management process to ensure everything stays
on track.

Figure 1traditional methodologies

Traditional project management methodologies are most effective under certain conditions:

1. Stability of Requirements: These approaches work best when project requirements are clearly defined and unlikely to change significantly
over time. With their sequential and predictable nature, traditional methods thrive in environments where the project's needs remain steady.
 2. Low Risk and Predictability: Traditional methodologies are suited for projects that have manageable risks, which can be easily identified
and addressed. Because these approaches involve extensive upfront planning and documentation, they are ideal for projects with established
boundaries and low uncertainty.

3. Client Preferences: Clients or stakeholders may favor traditional methods due to their familiarity or due to regulatory requirements.
Industries such as aerospace or healthcare often have strict guidelines that necessitate the use of conventional approaches to ensure
compliance.

4. Linear Progression: Traditional techniques are advantageous when project activities can be clearly outlined and executed in a linear
sequence. Each phase of the project is dependent on the successful completion of the previous one, resulting in minimal overlap or iteration
between phases.

1. Waterfall model
The Waterfall Methodology is a traditional project management approach characterized by its linear and sequential structure. It consists of
distinct phases that must be completed one after another without overlapping
Structure of Waterfall Methodology

1. Requirements Gathering: This initial phase involves collecting all the necessary requirements from stakeholders. The goal is to
have a clear understanding of what the project aims to achieve.
2. Design: In this phase, the project team develops a blueprint or design for the system based on the gathered requirements. This
includes both high-level architecture and detailed specifications.
3. Implementation: After the design is finalized, the project moves into the implementation phase, where developers begin to write
code or build the product according to the design documents.
4. Testing: Once the implementation is complete, the product enters the testing phase. Here, it is evaluated for defects, performance
issues, and compliance with the requirements.
5. Deployment: After successful testing, the product is launched and made available to users. This phase includes installation and user
training.
6. Maintenance: After deployment, maintenance involves addressing any issues that arise, making necessary updates, and improving
the product based on user feedback
Advantages
 Clarity and Structure
The linear nature provides a clear roadmap for project teams, making it easy to understand progress and responsibilities.
 Easy Monitoring
Progress can be easily tracked through the distinct phases, making project management straightforward.
 Well-Suited for Simple Projects
It works well for projects with well-defined and stable requirements, such as construction projects or system upgrades.
Disadvantages
 Inflexibility: Once a phase is completed, going back to make changes can be costly and time-consuming. This makes it challenging to
adapt to evolving requirements.
 Late Testing: Testing only occurs after implementation, which can lead to discovering significant issues late in the process.
 Assumes Perfect Understanding: It relies heavily on understanding requirements from the beginning, which may not always be possible
in complex projects.
Figure 21.Waterfall model

2. Incremental model
The Incremental Model is a project management and software development approach that breaks down a project into smaller,
manageable components or increments. Each increment builds upon the previous one, allowing for partial implementation and testing
of features.

Features of the Incremental Model

1. Phased Development: The project is divided into segments or increments, with each increment representing a functional piece
of the overall system.
 2. Iterative Process: After each increment is developed, it undergoes design, implementation, and testing before moving to the
next increment. This iteration allows for adjustments based on feedback.

3. Partial Delivery: As increments are completed, they can be delivered to users for use. This allows stakeholders to start
utilizing some functionalities early in the process, rather than waiting until the entire system is complete.

4. Enhanced Flexibility: Because the project is broken into increments, it’s easier to make changes or adaptations based on user
feedback and evolving requirements after each stage.

Phases in the Incremental Model

1. Requirement Analysis: Like the Waterfall model, the initial phase involves gathering and documenting requirements.
However, in the Incremental Model, requirements may be revisited as new increments are developed.

2. Design: The system is designed incrementally, focusing on the specific requirements for each increment. High-level
architecture may be established at the beginning, but detailed designs are created as increments are developed.

3. Implementation: The team develops the first increment based on the specified requirements, followed by coding, resulting in a
functional part of the system.

4. Testing: After the first increment is implemented, it is thoroughly tested. Once any issues are resolved, the next increment is
planned, designed, and developed in a similar manner.

5. Deployment: Completed increments are deployed to users, often resulting in a system that is usable after just a few
increments, with full functionality realized over time.

6. Maintenance and Iteration: Feedback gathered from users after each increment can inform improvements and changes for
subsequent increments.

Advantages
  Early Delivery: Users can start using system components while the project is still in progress, increasing user
satisfaction.
 Reduced Risk: By developing and testing smaller increments, risks can be identified and addressed earlier in the
project.
 Flexibility and Adaptability: The model allows for mid-course corrections and adjustments based on user feedback and
changing requirements.
Disadvantages
 Integration Issues: As increments are developed separately, integrating them into a cohesive system can sometimes be
complex.
 Requires Good Planning: While changes can be made, without proper planning, the overall direction of the project can
become unclear.
 Documentation Challenges: Because the system evolves through increments, maintaining up-to-date documentation
may be more challenging.
Figure 3incremental model

3. Prototype Model
An early model of the product is created to help gather user feedback. After users interact with the prototype, their insights are used
to make improvements before the final product is developed. This method is beneficial in industries like software development or
product design, where understanding user needs is crucial.

Features
1. Iterative Development: The Prototype Model involves iterative cycles of creating, refining, and testing prototypes, allowing
for continuous user feedback and improvements.
 2. User Involvement: Users are actively engaged throughout the prototyping process. Their input is crucial for building a product
that meets their needs, which helps in clarifying requirements.

3. Explorative Nature: Prototypes help explore design concepts and gather user reactions, making it easier to identify what works
well and what does not.

Phases in the Prototype Model

1. Requirements Gathering: Initial requirements are collected from stakeholders. Unlike the Waterfall approach, this stage does
not require exhaustive detail since the prototype will be used to clarify and refine requirements.

2. Quick Design: A simple prototype (often a scaled-down version or a mock-up) is designed based on the initial requirements.
This prototype focuses on important features rather than the complete functionality.

3. Prototype Development: The prototype is built quickly, using rapid development techniques. It may not have full functionality
but should demonstrate core features.

4. User Evaluation: The prototype is presented to users for feedback. They interact with it to provide insights on what they like
or dislike, which helps highlight any misunderstandings or missing features.

5. Refinement: Based on user feedback, the prototype is refined and updated. This may involve revisiting the requirements and
making adjustments to the design.

6. Repeat: Steps 3 to 5 are repeated until the prototype adequately reflects user needs and expectations. Developers may create
multiple iterations of the prototype, gradually enhancing and incorporating additional features.

7. Final Development: Once a satisfactory prototype is achieved, the final system is developed using the refined requirements
and designs, often building on the prototype structure.

Advantages
 Better User Input: Frequent feedback and user involvement lead to a product that is more closely aligned with user needs and
expectations.
  Early Detection of Issues: Users can identify issues early in the process, reducing the likelihood of major revisions later.
 Reduced Development Time: By clarifying requirements through prototypes, the final system can be developed more
efficiently.
Disadvantages
 Potential for Scope Creep: User feedback may lead to continuous changes and additions, making it difficult to finalize
requirements and potentially extending the project timeline.
 Limited Functionality: Early prototypes may lack full functionality, which may cause misunderstandings regarding the final
product’s capabilities.
 Overemphasis on User Feedback: While user input is essential, relying too heavily on it can lead to neglecting other factors
like technical feasibility or performance considerations.

Figure 4prototype model

4. Spiral Model
The Spiral Model is a software development methodology that integrates aspects of both iterative and incremental development approaches. It
is designed to address the evolving nature of project requirements by emphasizing risk management and continuous refinement. The model is
structured around repeated cycles, known as "spirals," which each consist of four key phases: Planning, Risk Analysis, Engineering, and
Evaluation. During the Planning phase, project objectives and requirements are defined and detailed. In the Risk Analysis phase, potential risks
are identified and assessed, and strategies are developed to mitigate them. The Engineering phase involves the actual development and
engineering of the system, incorporating feedback from previous cycles. Finally, the Evaluation phase involves reviewing the progress,
obtaining user feedback, and planning for the next cycle. Each spiral allows for iterative improvements and adjustments based on insights
gained, enabling the project to evolve and adapt over time. This approach provides flexibility and proactive risk management, making it well-
suited for complex and high-risk projects, though it can be more resource-intensive and require careful management to avoid scope creep.
Features
1. Iterative and Incremental: The Spiral Model promotes the development of prototypes and incremental releases throughout the project
lifecycle. Each spiral represents a full development cycle that results in a refined version of the product.

2. Focus on Risk Management: One of the most significant aspects of the Spiral Model is its strong focus on identifying, assessing, and
mitigating risks at every phase. This helps ensure that potential problems are addressed early in the process.

3. User Involvement: Like the Prototype Model, the Spiral Model encourages user feedback and involvement. Users are consulted
during each spiral, helping to refine requirements and features continuously.

Phases in the Spiral Model

The Spiral Model consists of four key phases that are repeated in each spiral:

1. Planning:

Define objectives, gather requirements, and determine project scope.

Assess risks and plan risk mitigation strategies. This stage also involves creating schedules and setting deliverables for the current
iteration.
2. Risk Analysis:

Evaluate technical, operational, and financial risks, and assess how they could impact the project.
Develop strategies for mitigating identified risks, which may involve testing prototypes, conducting feasibility studies, and more.
 3. Engineering:

Design and develop the next increment of the system. This includes building prototypes, implementing features, and conducting
thorough testing.
The focus is on developing a functioning version of the product that addresses user feedback and risk concerns.
4. Evaluation and Planning for the Next Iteration:

In this phase, the developed increment is evaluated by stakeholders to gather feedback.

Based on this feedback, plan for the next spiral, revising objectives, requirements, and risk assessments as needed.
Advantages
 Risk Management: The continuous assessment of risks allows teams to identify potential issues early and adapt accordingly, reducing
the likelihood of project failure.
 User Feedback: Frequent involvement of users ensures that the product evolves in line with their needs, enhancing user satisfaction.
 Flexibility: The model allows for flexibility and adaptability, making it suitable for projects with complex requirements that may
change over time.

Disadvantages
 Complexity: Managing multiple iterations and ensuring effective risk management can complicate project management and require
specialized knowledge.
 Cost: Due to the iterative nature and emphasis on risk assessment, the Spiral Model can be more resource-intensive than other
methodologies.
 Difficulties in Management: Projects can become lengthy and challenging to manage effectively, especially if requirements continue to
evolve.
 Figure 5 spiral model

1.4 Agile methodologies

Agile methodologies are a group of principles and practices that emphasize iterative development, collaboration, and flexibility in managing
projects, especially in software development. Unlike traditional methods, Agile focuses on continuously adjusting to customer feedback and
changing requirements. Key practices include working in short development cycles (called iterations or sprints), holding regular team
meetings for feedback, and delivering functional software quickly and frequently. The goal is to ensure that the final product meets the user's
needs while allowing for adaptability and constant improvement throughout the process.
Key Principles of Agile
1. Customer Collaboration: Agile emphasizes working closely with customers to understand their requirements and feedback, ensuring
the product meets their needs.

2. Iterative Progress: Projects are divided into small, manageable units called iterations or sprints. Each iteration results in a potentially
shippable product increment.

3. Flexibility and Adaptability: Agile teams are encouraged to adapt plans and priorities based on feedback and changing circumstances,
making it easy to respond to evolving customer needs.

4. Cross-Functional Teams: Agile promotes collaboration among diverse team members (developers, testers, designers) to enhance
problem-solving and innovation.

5. Continuous Improvement: After each iteration, teams reflect on their processes in retrospectives to identify areas for improvement.

Common Agile Frameworks

1. Scrum: A framework that divides work into sprints (usually 2-4 weeks). It features specific roles (Scrum Master, Product Owner,
Development Team) and ceremonies (sprint planning, daily stand-ups, sprint reviews and retrospectives).

2. Kanban: Focuses on visualizing the workflow and limiting work in progress. It helps manage and optimize the flow of tasks through
the system.

3. Extreme Programming (XP): Emphasizes engineering practices to improve software quality, such as pair programming, continuous
integration, and test-driven development.

4. Lean Software Development: Adapts principles from Lean manufacturing to minimize waste and focus on delivering value.
 5. Feature-Driven Development (FDD): Centres around designing and building features in a structured, systematic way, ideal for larger
teams or projects.

Advantages of Agile
 Faster Time to Market: By delivering small increments of work frequently, teams can get features to market quicker.
 Improved Quality: Continuous testing and feedback cycles lead to higher quality products.
 Greater Transparency: Frequent updates and meetings enhance visibility for stakeholders.
 Higher Customer Satisfaction: Regular releases and the ability to adapt to feedback improve alignment with customer expectations.

Disadvantages of Agile Methodologies

 Requires Cultural Shift: Transitioning to Agile may be challenging for organizations used to traditional methods. It requires a cultural
change and willingness to embrace flexibility and collaboration.

 Less Predictability: Due to the iterative nature and changing requirements, it can be harder to predict timelines and costs accurately.

 Scope Creep: Without proper management, Agile can lead to scope creep as continuous input from stakeholders may change project
requirements frequently.

 Team Dependency: Agile relies heavily on the team’s discipline and commitment. If team members are not fully engaged or skilled, it
can impact the project's success.

 Overhead in Meetings: The regular Scrum ceremonies (like daily stand-ups, sprint planning, etc.) can become cumbersome if not well-
facilitated, impacting productivity
Figure 6 agile model

Here are few agile methodologies explain in follow

1. Scrum
Whether Scrum is a framework, a methodology or an Agile process and whether it contains a process within this framework often
spawns a lot of negatives. From its origin, Scrum is described by its practitioners and promoters as a simple, Integration lean, and in
complete process frame work which captures the essence of the framework rightly. It describes what the teams should do to be effective
and efficient in order to implement scrum by following the principles of unity, inspection, and adaptation. Despite the fact that Scrum is
not always effective with comprehensive teams, especially with the existence of a project manager, it is reasonable to adapt Scrum for a
couple of cycles to determine whether the team requires it and meets its goals Scrum is implemented in organizations, teams, and
project managers and professionals of all fields. The framework is in its best use with small teams that develop work or projects with
shifting deliverables, unknown solutions, and regular dealings with the client or end-user. Scrum does not prefer substantial and
successive approaches so it allows fast and frequent production of functional products.

Advantages of Scrum
 Flexibility and Adaptability: Scrum allows teams to respond quickly to changes in requirements, making it suitable for projects
with evolving specifications.

 Increased Transparency: Daily meetings and regular reviews ensure everyone is informed about the project's status, which
fosters open communication.

 Empowered Teams: Scrum promotes autonomy and collaborative decision-making within the team, increasing motivation and
ownership of the work.

 Frequent Feedback: Regular interactions with stakeholders allow for continuous feedback, ensuring that the product aligns with
user needs.

 Improved Quality: With practices like continuous integration and regular retrospectives, teams can identify and address issues
early, enhancing product quality.

 Predictable Delivery: Time-boxed sprints facilitate planning and make it easier to predict delivery timelines based on completed
work.

Disadvantages of Scrum
 Requires Experienced Teams: Scrum can be challenging for teams without a solid understanding of Agile principles, resulting in
ineffective implementation.

 Overhead of Meetings: The frequency of meetings (daily scrums, sprint planning, retrospectives, etc.) can feel burdensome and
may disrupt workflow.
  Role Conflicts: Ambiguity in roles and responsibilities may lead to confusion, especially if team members are unsure about their
specific duties.

 Dependency Management: Coordinating dependencies between teams can be complex and may hinder productivity, especially
in larger organizations.

 Inconsistent Commitment: If team members are not fully committed to the process or to the sprint goals, it can impact the
overall effectiveness of Scrum.

 Not Suitable for All Projects: Scrum works best for projects that can benefit from iterative development and frequent feedback.
It may not be ideal for projects with fixed requirements or strict regulatory environments.

Figure 7 scrum model

 2. Extreme Programming (XP)
Extreme Programming or XP remains as an Agile project management technique whose main tenets entail speed and simplicity by embracing
short development cycles as well as avoiding most documents. Organizes around five of value process, five rules and twelve of XP practices
that we shall discuss later on this article. XP, as any other Agile methodology, divides the software development process into work sprints. In
these prints, there are two cycles, the first is to fill and read the framework where after every cycle it has to be modified for efficient use and
also as per the changing needs. As in any other Agile method, XP supports developers and helps them provide immediate responses to
customer stories and act on them in an improvised manner. However, it clearly stands out because of the disciplined approach taken, which
uses as many code reviews and unit tests to help enable fast changes. In addition, XP concept is centres on creativity and knowledge workers
where teamwork is encouraged at every phase of development

Advantages of XP
 High Quality: Continuous testing and feedback help identify defects early, resulting in better-quality software.
 Flexibility: Frequent delivery and customer involvement make it easier to adapt to changing requirements.
 Enhanced Collaboration: Practices like pair programming and collective ownership foster a strong team dynamic and knowledge
sharing.
 Customer Satisfaction: Regular releases and close collaboration with customers lead to a product that better meets actual user needs.
Disadvantages of XP
 Cultural Shift Required: Transitioning to XP may require significant changes in team dynamics and corporate culture, which can be
challenging.
 Intensive Communication: The emphasis on collaboration means that communication overhead can be high, which may not suit every
team or project.
  Not Suitable for All Projects: Projects with fixed requirements or regulatory constraints might find XP less effective, as the approach
thrives on adaptability and variability.
 Dependency on Customer Availability: The success of XP heavily relies on the active involvement of customers, which may not always
be feasible.

Figure 8 XP
 3. Scale agile framework
The Scaled Agile Framework (SAFe) is a detailed system designed to assist organizations in expanding Agile practices across various teams
that work on large-scale projects. Its structured approach helps ensure that all teams remain aligned with the organization’s overall strategic
goals while working together to complete tasks in a synchronized manner. SAFe integrates essential principles from Agile methodologies, Lean
thinking, and product development flow, making it adaptable to numerous industries. Through SAFe, organizations can optimize processes,
enhance team collaboration, and manage intricate projects more effectively, all while retaining the flexibility and adaptability that Agile
promotes.Advantages of SAFe

 Alignment and Transparency: SAFe promotes alignment between teams, departments, and organizational goals, providing visibility into
progress and priorities.

 Scalability: The framework is designed to support large enterprises, allowing multiple teams to work cohesively on large projects
without sacrificing Agile principles.

 Improved Collaboration: SAFe facilitates collaboration across teams through clear roles, ceremonies, and communication channels,
reducing silos within organizations.

 Focus on Customer Value: By prioritizing work based on customer feedback and business priorities, SAFe ensures that teams are
delivering value that meets customer needs.

 Risk Mitigation: Regular reviews and adaptations at multiple levels help identify and address risks early in the development process.

 Holistic Approach: SAFe integrates Lean thinking with Agile practices, promoting a culture of continuous improvement and efficiency.

Disadvantages of SAFe
 Complexity: The framework can be complex and may require considerable training and adaptation, which can overwhelm teams that are
new to Agile.
  Overhead: The structured layers of roles, ceremonies, and artifacts can introduce overhead, potentially reducing the agility that the
framework aims to promote.

 Risk of Misinterpretation: Organizations may misapply SAFe principles, leading to a focus on process rather than outcomes or true
agility.

 Resistance to Change: Implementing SAFe may face cultural resistance from teams accustomed to traditional project management
methodologies.

 Time and Resources: Successfully implementing SAFe requires time, resources, and commitment, which may not be feasible for all
organizations.

 Not One-Size-Fits-All: While SAFe can be beneficial, it may not work for every organization or project type, especially those that are
smaller or less complex.

4. LEAN software development

Lean Software Development is an Agile methodology that focuses on minimizing waste, streamlining processes, and delivering customer
value as efficiently as possible. Drawing inspiration from Lean manufacturing, it emphasizes continuous improvement, effective use of
resources, and empowering teams to make informed decisions. The core goal of Lean is to maximize value by eliminating unnecessary steps
and optimizing workflow.

Eliminating waste: Removing activities that don't directly add value to the customer.
Building quality in: Embedding quality throughout the development process, rather than relying only on post-production testing.
Creating knowledge: Encouraging learning and experimentation to foster innovation.
Deferring commitment: Allowing teams to delay decisions until the latest responsible moment, offering flexibility.
Delivering fast: Prioritizing quick, incremental releases to provide value to customers faster.
Respecting people: Empowering teams and promoting collaboration.
Optimizing the whole: Focusing on improving the entire system, not just isolated parts.
These principles combine to make Lean a highly efficient, value-driven development approach.

Advantages of Lean Software Development

Greater Efficiency: By eliminating waste and optimizing workflows, Lean ensures better use of resources, reducing unnecessary steps and
costs.
Faster Delivery: Lean’s focus on continuous improvement and customer value leads to faster product and feature delivery.
Customer Focused: Prioritizing customer value results in higher satisfaction.
Continuous Improvement: Encourages a culture of ongoing learning and improvement, leading to better long-term outcomes.
Empowered Teams: Teams are given the authority to make decisions, which improves morale, collaboration, and innovation.

Disadvantages of Lean Software Development

Requires Discipline: Effective waste elimination requires a high degree of discipline and experience, which can be challenging.
Overemphasis on Efficiency: Excessive focus on efficiency may neglect other important factors like long-term innovation or employee
satisfaction.
Limited Structure for Large Projects: Lean may lack the necessary framework for managing large or complex projects with multiple
dependencies.
Difficult to Measure Waste: Identifying and eliminating waste can be subjective and challenging to measure consistently across projects.
 When to Use Lean Software Development

Resource Optimization: Ideal for optimizing time and resources by eliminating waste and improving processes.
Cost Reduction: Effective in reducing costs by removing non-value-added tasks and enhancing efficiency.
Customer-Focused Projects: Perfect for projects aimed at delivering features that directly meet customer needs.
Continuous Improvement: Suitable for organizations committed to ongoing development, as Lean helps in identifying inefficiencies and
continuously improving processes and products.

1.5 Strength and weakness of traditional methodologies and Agile methodologies

Aspect Traditional Agile Methodologies
Methodologies
Structure Follows a Iterative and flexible, with frequent
rigid, linear adjustments based on feedback (e.g.,
sequence of Scrum).
phases (e.g.,
Waterfall).
Documentation Emphasizes Focuses more on working software,
detailed with minimal but necessary
documentation at documentation.
every stage of
development.
Flexibility Inflexible; Highly flexible; changes can be easily
 changes are integrated at any point in the
difficult and development process.
costly once a
phase is
completed.
Customer Limited customer Continuous customer involvement
Involvement involvement until throughout the development process.
the final stages of
the project.
Time to Market Takes longer as Quicker delivery through
the system is incremental releases, with functional
delivered after all software delivered early.
phases are
completed.
Risk Risks are Risks are managed continuously with
Management managed in the frequent testing and feedback,
early phases, but reducing late-stage surprises.
late-stage issues
can be costly.
Team Suitable for large, complex projects Works best for small to medium-sized
Collaboration with clear requirements. projects, though scalable with
frameworks like SAFe.
Cost Control Less collaborative; each team works Highly collaborative, with cross-
on its specific phase. functional teams working together
throughout.
Easier to estimate costs upfront if Costs are harder to predict as the
Quality Assurance requirements are fixed. project evolves with changing
requirements.

Adaptability to Poor adaptability; any changes Excellent adaptability, allowing

Change require revisiting completed phases. changes based on user feedback and
evolving requirements.
1.5.1 Strengths & Weaknesses of Traditional and Agile Methodologies
Traditional system development methodologies, including Waterfall, Incremental, and Spiral, follow a well-defined, step-by-step process
where each phase must be completed before moving on to the next. This linear approach is based on the assumption that system requirements
can be clearly established at the beginning of the project. These methodologies emphasize structure and order, ensuring that each stage, such as
planning, analysis, design, implementation, and testing, is fully addressed before progressing. This method works well for projects with stable,
predictable requirements but can be less flexible when changes are needed later in development.

Strengths:
Clear Structure: Traditional methodologies, such as Waterfall, follow a clearly defined sequence of phases—planning, analysis, design,
implementation, and testing. Each phase must be completed before moving on to the next. This structured approach ensures that all necessary
steps are followed systematically and provides clear milestones for accountability and progress tracking.
Comprehensive Documentation: Traditional approaches place a strong emphasis on detailed documentation throughout the development
process. This thorough documentation includes requirements, design specifications, and testing protocols. Such documentation is valuable for
future maintenance, helps with regulatory compliance, and serves as a reference for understanding the system's design and functionality.
Predictability: With requirements established early in the project and a structured development process, traditional methodologies allow for
more accurate predictions of timelines and costs. This predictability is beneficial for managing budgets and schedules, especially in projects
where requirements are unlikely to change significantly.
Better for Large, Complex Systems: Traditional methodologies are well-suited for large and complex projects where each phase requires
careful planning and review. The sequential nature allows for thorough examination of each component, making it easier to manage intricate
systems with numerous interdependencies and detailed requirements.

Weaknesses of Traditional Methodologies

Inflexibility: Traditional methodologies are rigid and structured, which makes adapting to changing requirements difficult once the
development process has commenced. If changes or new requirements arise, revisiting and revising earlier stages of development can be
necessary, often leading to increased complexity and additional costs.
Late Feedback: In traditional approaches, customer feedback is typically gathered late in the development cycle, often during or after the
testing phase. This delay in receiving feedback can lead to misunderstandings or misalignments with the actual needs and expectations of the
users. By the time feedback is incorporated, significant development work may already be completed, making adjustments more challenging
and costly.
Delayed Results: Traditional methodologies usually involve completing the entire system before releasing it. As a result, stakeholders may
not see any tangible results until the end of the project. This delayed delivery can be problematic if early validation or incremental
improvements are needed, potentially impacting stakeholder satisfaction and market responsiveness.
High Risk: Traditional methods carry a high risk because mistakes or oversights in the early stages, such as incomplete or inaccurate
requirements, can have significant repercussions later in the development process. Correcting these issues after extensive work has been done
can be both expensive and time-consuming, as it often requires substantial rework and redesign.

1. Agile Methodologies
Agile methodologies, such as Scrum, XP (Extreme Programming), and Lean, adopt an iterative approach that emphasizes flexibility, ongoing
collaboration, and frequent customer feedback. Instead of delivering the entire system at once, Agile methods focus on producing small,
functional increments of the system. This approach allows for continuous improvements and adjustments based on feedback throughout the
development process.
2. Strengths:
1. Flexibility: Agile methodologies excel in adapting to changing requirements. As customer needs or market conditions evolve, Agile
teams can modify the system accordingly. This adaptability minimizes the risk of project failure due to unforeseen changes and reduces
the need for extensive rework.
2. Continuous Feedback: Agile places a strong emphasis on involving customers and stakeholders throughout the development process.
This frequent feedback ensures that the product is aligned with user expectations and allows for early detection and resolution of issues.
Regular reviews help keep the project on track and ensure that the final product meets the desired outcomes.
3. Faster Time to Market: Agile’s iterative approach allows for incremental delivery of functional system components. By releasing
smaller, usable parts of the system early, users can start benefiting from the product sooner, and further improvements can be made based
on their experiences and feedback.
4. Improved Collaboration: Agile promotes close collaboration between development teams, stakeholders, and customers. Frequent
communication and teamwork help ensure that all parties are aligned with the project’s goals, improving overall efficiency and
effectiveness.

3. Weaknesses:
4. Less Predictable: Due to its iterative and adaptive nature, Agile methodologies can make it challenging to predict the final timeline and
budget with high accuracy. The constant evolution of requirements and scope changes can lead to variability in project outcomes, making
it harder to manage expectations and resources.
5. Less Documentation: Agile methodologies prioritize working software over comprehensive documentation. While this can streamline
the development process, it may result in less detailed records of design decisions and system functionality. This can pose challenges for
future maintenance, onboarding new team members, or understanding the system’s history.
6. Requires Experienced Teams: Agile’s success relies on a high level of team coordination, self-management, and a deep understanding
of Agile principles. Teams need to be experienced and skilled in Agile practices to effectively manage the iterative process and maintain
productivity.
7. Challenging for Large, Complex Systems: While Agile is well-suited for smaller projects and teams, scaling Agile practices for large,
complex systems can be difficult. Managing dependencies, integrating multiple teams, and ensuring consistency across a broad scope
may require additional frameworks like SAFe (Scaled Agile Framework) to address these challenges effectively.