IT-13

Object Oriented Software Engineering

MCA- I Sem –I
(AY 23-24)
 UNIT 5
Current trends in Software Engineering
5.1. Introduction to Web Engineering
5.2. Agile Process
5.2.1. Agile Process Models
5.2.1.1. Extreme Programming (XP)
5.2.1.2. Adaptive Software Development (ASD)
5.2.1.3. Dynamic Systems Development Method (DSDM)
5.2.1.4. Scrum
5.2.1.5. Crystal
5.2.1.6. Feature Driven Development (FDD)
Extra Readings: Comparative analysis of traditional process models and agile, Agile methodology
in testing
5.1. Introduction to Web Engineering
• Web engineering focuses on the methodologies, techniques, and tools that are the foundation of Web
application development and which support their design, development, evolution, and evaluation.
• Web application development has certain characteristics that make it different from traditional software,
information system, or computer application development.
• Web engineering is multidisciplinary and encompasses contributions from diverse areas:
1. systems analysis and design,
2. software engineering,
3. hypermedia/hypertext engineering,
4. requirements engineering,
5. human-computer interaction,
6. user interface, data engineering,
7. information science, information indexing and retrieval,
8. testing, modelling and simulation, project management, and graphic design and presentation.
• Web engineering is neither a clone nor a subset of software engineering, although both involve
programming and software development.
• While Web Engineering uses software engineering principles, it encompasses new approaches,
methodologies, tools, techniques, and guidelines to meet the unique requirements of Web-based
applications.
 Web Engineeering As a discipline[edit]
• Proponents of Web engineering supported the establishment of Web engineering as a discipline at
an early stage of Web.

• Major arguments for Web engineering as a new discipline are:

1. Web-based Information Systems (WIS) development process is different and unique.[3]

2. Web engineering is multi-disciplinary; no single discipline (such as software engineering) can

provide complete theory basis, body of knowledge and practices to guide WIS development.[4]

3. Issues of evolution and lifecycle management when compared to more 'traditional' applications.

4. Web-based information systems and applications are pervasive and non-trivial. The prospect of
Web as a platform will continue to grow and it is worth being treated specifically.
Main topics of Web engineering include, but are not limited to, the following areas:
• Modeling disciplines[edit]
1. Business Processes for Applications on the Web
2. Process Modelling of Web applications
3. Requirements Engineering for Web applications
4. B2B applications

• Design disciplines, tools, and methods[edit]

1. UML and the Web
2. Conceptual Modeling of Web Applications (aka. Web modeling)
3. Prototyping Methods and Tools
4. Web design methods
5. CASE Tools for Web Applications
6. Web Interface Design
7. Data Models for Web Information Systems
• Implementation disciplines[edit]
1. Integrated Web Application Development Environments
2. Code Generation for Web Applications
3. Software Factories for/on the Web
4. Web 2.0, AJAX, E4X, ASP.NET, PHP and Other New Developments
5. Web Services Development and Deployment
• Testing disciplines[edit]
1. Testing and Evaluation of Web systems and Applications.
2. Testing Automation, Methods, and Tools.
• Applications categories disciplines[edit]
1. Semantic Web applications
2. Document centric Web sites
3. Transactional Web applications
4. Interactive Web applications
5. Workflow-based Web applications
6. Collaborative Web applications
7. Portal-oriented Web applications
8. Ubiquitous and Mobile Web Applications
9. Device Independent Web Delivery
10. Localization and Internationalization of Web Applications
11. Personalization of Web Applications
What is Agile?
• The word ‘agile’ means −
• Able to move your body quickly and easily.
• Able to think quickly and clearly.

In business, ‘agile’ is used for describing ways of planning and doing work wherein it is
understood that making changes as needed is an important part of the job.

Business‘agililty’ means that a company is always in a position to take account of the

market changes.
Ref: Cambridge Dictionaries online.

In software development, the term ‘agile’ is adapted to mean ‘the ability to respond to
changes − changes from Requirements, Technology and People.’
Agile Manifesto
• A team of software developers published the Agile Manifesto in 2001,
highlighting the importance of the development team, accommodating changing
requirements and customer involvement.

The Agile Manifesto states that −

• We are uncovering better ways of developing software by doing it and helping

others do it. Through this work, we have come to value −
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

• That is, while there is value in the items on the right, we value the items on the
left more.
Characteristics of Agility

• Agility in Agile Software Development focuses on the culture of the whole team with multi-
discipline, cross-functional teams that are empowered and self organizing.

• It fosters shared responsibility and accountability.

• Facilitates effective communication and continuous collaboration.

• The whole-team approach avoids delays and wait times.

• Frequent and continuous deliveries ensure quick feedback that in in turn enable the team align to
the requirements.

• Collaboration facilitates combining different perspectives timely in implementation, defect fixes

and accommodating changes.

• Progress is constant, sustainable, and predictable emphasizing transparency.

Software Engineering Trends
• The following trends are observed in software engineering −
• Gather requirements before development starts. However, if the requirements
are to be changed later, then following is usually noticed −
• Resistance to the changes at a later stage of development.
• There is a requirement of a rigorous change process that involves a change control board that may even
push the changes to later releases.
• The delivery of a product with obsolete requirements, not meeting the customer’s expectations.
• Inability to accommodate the inevitable domain changes and technology changes within the budget.
• Find and eliminate defects early in the development life cycle in order to cut the
defect-fix costs.
• Testing starts only after coding is complete and testing is considered as a tester’s responsibility though
the tester is not involved in development.
• Measure and track the process itself. This becomes expensive because of −
• Monitoring and tracking at the task level and at the resource level.
• Defining measurements to guide the development and measuring every activity in the development.
• Management intervention.
• Elaborate, analyze, and verify the models before development.
• A model is supposed to be used as a framework. However, focus on the model and not on the
development that is crucial will not yield the expected results.
Software Engineering Trends

• Coding, which is the heart of development is not given enough emphasis. The reasons being −
• Developers, who are responsible for the production, are usually not in constant communication with the
customers.
• Coding is viewed as a translation of design and the effective implementation in code is hardly ever looped
back into the design.
• Testing is considered to be the gateway to check for defects before delivery.
• Schedule overruns of the earlier stages of development are compensated by overlooking the test
requirements to ensure timely deliveries.
• This results in cost overruns fixing defects after delivery.
• Testers are made responsible and accountable for the product quality though they were not involved during
the entire course of development.
• Limiting resources (mainly team) to accommodate budget leads to −
• Resource over allocation
• Team burnout.
• Loss in effective utilization of team competencies.
• Attrition.
 5.2. Agile Process
• An agile methodology is an iterative approach
to software development. Each iteration of
agile methodology takes a short time interval
of 1 to 4 weeks.

• The agile development process is aligned to

deliver the changing business requirement. It
distributes the software with faster and fewer
changes.
• The single-phase software development takes
6 to 18 months. In single-phase development,
all the requirement gathering and risks
management factors are predicted initially.
• The agile software development process
frequently takes the feedback of workable
product. The workable product is delivered
within 1 to 4 weeks of iteration.
Roles in Agile
There are two different roles in a Agile methodology. These are the Scrum Master and Product
Owner.
1. Scrum Master
The Scrum Master is a team leader and facility provider who helps the team member to follow agile
practices, so that the team member meets their commitments and customers requirements.

Responsibilities of the scrum master:

• They enable the close co-operation between all the roles and functions.
• They remove all the blocks which occur.
• They safeguard the team from any disturbances.
• They work with the organization to track the progress and processes of the company.
• They ensure that Agile Inspect & adapt processes are leveraged correctly which includes
• Planned meetings
• Daily stand-ups
• Demo
• Review
• Retrospective meetings, and
• Facilitate team meetings and decision-making process.
Roles in Agile
2. Product Owner
• The Product Owner is one who runs the product from a business
perspective.
Responsibilities of the Product Owner:
• He defines the requirements and prioritizes their values.
• He sets the release date and contents.
• He takes an active role in iteration and releasing planning meetings.
• He ensures that the team is working on the most valued requirement.
• He represents the voice of the customer.
• He accepts the user stories that meet the definition of done and defined
acceptance criteria.
 Cross-functional team
• Every agile team contains self-
sufficient team with 5 to 9 team
members.
• The average experience of each
member ranges from 6 to 10 years.

• The agile team contains 3 to 4

developers, 1 tester, 1 technical lead,
1 scrum master and 1 product owner.

• The Scrum master and Product owner

are considered as a part of Team
Interface, on the other hand
remaining members are the part of
Technical Interface.
 How an Agile Team plan their work?
• An Agile methodology is not a specific set of ceremonies
or specific development techniques.
• Rather, it is a group of methodologies that demonstrate
a commitment to tight feedback cycles and continuous
improvement.
• An Agile team works in iterations to deliver the
customer requirement, and each iteration takes 10
to 15 days.
• However, the original Agile Manifesto didn't set the time
period of two-week iterations or an ideal team size.

• Each user requirement is a planned based and their

backlog prioritization and size. The team decides, how
much scope they have and how many hours available
with each team to perform their planed task.
 What is a user requirement?
• The user requirement defines the requirements of
the user in terms of functionalities. There may be of
two type of functionality.

1. As a <User Role> I want <Functionality> so that

<Business Value>
2. In order to <Business value> as a <User Role> I
want <Functionality>.

• During software release planning, a rough estimate

is given to a user requirement using relative scale
points.

• During iteration planning, the requirement is

broken down into tasks.
Relation between User requirement and Task

• User requirement talks about what is to be done. It defines the

needs of users.
• Task talks about how it is to be done. It defines how functionality is
implemented.
• User requirements are implemented by tasks. Every requirement is
gathering as the task.
• User requirement is divided into different tasks when it is planned in
current iteration.
• User tasks are estimated in hours based, generally it is between 2 to
12 hours.
• Requirements are validated using acceptance test.
When the requirement is completed

The Agile team decides the meaning of task done. There may be different
criteria for it:
• When the entire task (development, testing) are completed.
• When all the acceptance tests are running and are passed.
• When no defects found.
• Product owner has accepted the requirement.
• When the software product is delivered to the end user.

What is Software Acceptance Criteria?

• Acceptance Criteria is defined as the functionality, behavior, and
performance required by a product owner.
• It defines what is to be done so that the developer knows when a user
requirement is complete.
 5.2.1. Agile Process Models
• The meaning of Agile is swift or versatile."Agile process model" refers
to a software development approach based on iterative development.

• Agile methods break tasks into smaller iterations, or parts do not

directly involve long term planning.

• The project scope and requirements are laid down at the beginning of
the development process. Plans regarding the number of iterations,
the duration and the scope of each iteration are clearly defined in
advance.

Each iteration is considered as a short time "frame" in the Agile process

model, which typically lasts from one to four weeks.

• The division of the entire project into smaller parts helps to minimize
the project risk and to reduce the overall project delivery time
requirements.

• Each iteration involves a team working through a full software

development life cycle including planning, requirements analysis,
design, coding, and testing before a working product is demonstrated
to the client.
Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback
Phases of Agile Model:
1. Requirements gathering:
• Define the requirements.
• Explain business opportunities and plan the time and effort needed to build the project.
• Based on this information, you can evaluate technical and economic feasibility.
2. Design the requirements:
• When you have identified the project, work with stakeholders to define requirements.
• Use the user flow diagram or the high-level UML diagram to show the work of new
features and show how it will apply to your existing system.
3. Construction/ iteration:
• The work begins.
• Designers and developers start working on their project, which aims to deploy a working
product.
• The product will undergo various stages of improvement, so it includes simple, minimal
functionality.
Phases of Agile Model:

4. Testing:
The Quality Assurance team examines the product's performance and
looks for the bug.
5. Deployment:
The team issues a product for the user's work environment.
6. Feedback:
After releasing the product, the last step is feedback.
In this, the team receives feedback about the product and works
through the feedback.
Agile Testing Methods/Agile Process Models:
:1. Scrum
2. Crystal
3. Dynamic Software Development Method(DSDM)
4. Feature Driven Development(FDD)
5. Lean Software Development
6. eXtreme Programming(XP)
When to use the Agile Model?

• When frequent changes are required.

• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with a software team all
the time.
• When project size is small.
Advantage(Pros) of Agile Method:
• Frequent Delivery
• Face-to-Face Communication with clients.
• Efficient design and fulfils the business requirement.
• Anytime changes are acceptable.
• It reduces total development time.

Disadvantages(Cons) of Agile Model:

• Due to the shortage of formal documents, it creates confusion and crucial
decisions taken throughout various phases can be misinterpreted at any
time by different team members.
• Due to the lack of proper documentation, once the project completes and
the developers allotted to another project, maintenance of the finished
project can become a difficulty.
5.2.1.1. Extreme Programming (XP)
• XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop a
software.

• One of the most important software development frameworks of Agile models.

• Used to improve software quality and responsiveness to customer requirements.

• The extreme programming model recommends taking the best practices that have worked well in
the past in program development projects to extreme levels.

• eXtreme Programming (XP) was conceived and developed to address the specific needs of
software development by small teams in the face of vague and changing requirements.

• It provides values and principles to guide the team behavior. The team is expected to self-
organize.

• Extreme Programming provides specific core practices where −

 Each practice is simple and self-complete.
 Combination of practices produces more complex and emergent behavior.
Embrace Change
A key assumption of Extreme Programming is that the cost of changing
a program can be held mostly constant over time.

This can be achieved with −

Emphasis on continuous feedback from the customer
Short iterations
Design and redesign
Coding and testing frequently
Eliminating defects early, thus reducing costs
Keeping the customer involved throughout the development
Delivering working product to the customer
Extreme Programming involves −
1. Writing unit tests before programming and keeping all of the tests running at all times. The unit
tests are automated and eliminates defects early, thus reducing the costs.

2. Starting with a simple design just enough to code the features at hand and redesigning when
required.

3. Programming in pairs (called pair programming), with two programmers at one screen, taking
turns to use the keyboard. While one of them is at the keyboard, the other constantly reviews
and provides inputs.

4. Integrating and testing the whole system several times a day.

5. Putting a minimal working system into the production quickly and upgrading it whenever
required.

6. Keeping the customer involved all the time and obtaining constant feedback.

Iterating facilitates the accommodating changes as the software evolves with the changing
requirements.
 Why is it called “Extreme?”
• Extreme Programming takes the effective principles
and practices to extreme levels.

• Code reviews are effective as the code is reviewed

all the time.

• Testing is effective as there is continuous regression

and testing.

• Design is effective as everybody needs to do

refactoring daily.

• Integration testing is important as integrate and test

several times a day.

• Short iterations are effective as the planning game

for release planning and iteration planning.
• Success in Industry
The success of projects, which follow Extreme Programming practices,
is due to −

• Rapid development.
• Immediate responsiveness to the customer’s changing requirements.
• Focus on low defect rates.
• System returning constant and consistent value to the customer.
• High customer satisfaction.
• Reduced costs.
• Team cohesion and employee satisfaction.
Extreme Programming Advantages
Extreme Programming solves the following problems often faced in the software development
projects −

1. Slipped schedules − and achievable development cycles ensure timely deliveries.

2. Cancelled projects − Focus on continuous customer involvement ensures transparency
with the customer and immediate resolution of any issues.
3. Costs incurred in changes − Extensive and ongoing testing makes sure the changes do not
break the existing functionality. A running working system always ensures sufficient time
for accommodating changes such that the current operations are not affected.
4. Production and post-delivery defects: Emphasis is on − the unit tests to detect and fix the
defects early.
5. Misunderstanding the business and/or domain − Making the customer a part of the team
ensures constant communication and clarifications.
6. Business changes − Changes are considered to be inevitable and are accommodated at
any point of time.
7. Staff turnover − Intensive team collaboration ensures enthusiasm and good will. Cohesion
of multi-disciplines fosters the team spirit.
5.2.1.2. Adaptive Software Development (ASD)
• Adaptive Software Development (ASD) is a direct outgrowth of an
earlier agile framework, Rapid Application Development (RAD).

• Moreover, it aims to enable teams to quickly and effectively adapt to

changing requirements or market needs by evolving their products with
lightweight planning and continuous learning.

• Lastly, The ability to adapt allows teams to align with organizational goals.

• The ASD approach encourages teams to develop according to a three-

phase process: speculate, collaborate, learn.
5.2.1.2. Adaptive Software Development (ASD)

• Adaptive Software Development has evolved from RAD practices.

• The team aspects also were added to these practices.

• Companies from New Zealand to Canada, for a wide range of project and product
types, have used adaptive Software Development.

• Jim Highsmith published Adaptive Software Development in 2000.

• Adaptive Software Development practices provide ability to accommodate

change and are adaptable in turbulent environments with products evolving with
little planning and learning.
 Phases of ASD Life Cycle
• Adaptive Software Development is cyclical like the
Evolutionary model, with the phase names reflecting the
unpredictability in the complex systems.
• The phases in the Adaptive development life cycle are −
1. Speculate
2. Collaborate
3. Learn
• These three phases reflect the dynamic nature of Adaptive
Software Development.
• The Adaptive Development explicitly replaces
Determinism(to do as predecided) with Emergence.
• It goes beyond a mere change in lifecycle to a deeper
change in management style.
• Adaptive Software Development has a dynamic Speculate-
Collaborate-Learn Lifecycle.
• The Adaptive Software Development Lifecycle focuses on
results, not tasks, and the results are identified as
application features.
1. Speculation:
During this phase project is initiated and planning is conducted.
• The project plan uses project initiation information like project requirements, user needs,
customer mission statement, etc, to define set of release cycles that the project wants.

The term plan :is too deterministic and indicates a reasonably high degree of certainty about the
desired result.

• The implicit and explicit goal of conformance to plan, restricts the manager's ability to steer the
project in innovative directions.

In Adaptive Software Development: the term plan is replaced by the term speculate.

• While speculating, the team does not abandon planning, but it acknowledges the reality of
uncertainty in complex problems.

• Speculate encourages exploration and experimentation. Iterations with short cycles are
encouraged.
• Collaborate
• Complex applications are not built, they evolve. Complex applications
require that a large volume of information be collected, analyzed, and
applied to the problem. Turbulent environments have high rates of
information flow. Hence, complex applications require that a large volume
of information be collected, analyzed, and applied to the problem. This
results in diverse Knowledge requirements that can only be handled by
team collaboration.
• Collaborate would require the ability to work jointly to produce results,
share knowledge or make decisions.
• In the context of project management, Collaboration portrays a balance
between managing with traditional management techniques and creating
and maintaining the collaborative environment needed for emergence.
Learn
The Learn part of the Lifecycle is vital for the success of the project. Team has to enhance their
knowledge constantly, using practices such as −
• Technical Reviews
• Project Retrospectives
• Customer Focus Groups

Reviews should be done after each iteration.

Both, the developers and customers examine their assumptions and use the results of each
development cycle to learn the direction of the next.

The team learns −

• About product changes
• More fundamental changes in underlying assumptions about how the products are being
developed

The iterations need to be short, so that the team can learn from small rather than large mistakes.
Speculate - Collaborate - Learn Cycle as a Whole

• As you observe from the Speculate-Collaborate-Learn cycle, given

above, it is obvious that the three phases are nonlinear and overlap.
• We observe the following from an Adaptive framework.
• It is difficult to Collaborate without Learning or to Learn without
Collaborating.
• It is difficult to Speculate without Learning or to Learn without
Speculating.
• It is difficult to Speculate without Collaborating or to Collaborate
without Speculating.
5.2.1.3. Dynamic Systems Development Method
(DSDM)
• The Dynamic Systems Development technique (DSDM) is an associate degree agile code
development approach that provides a framework for building and maintaining systems.

• The DSDM philosophy is borrowed from a modified version of the sociologist principle—
80 % of An application is often delivered in twenty percent of the time it’d desire deliver
the entire (100 percent) application.

• DSDM is An iterative code method within which every iteration follows the 80% rule that
simply enough work is needed for every increment to facilitate movement to the
following increment.

• The remaining detail is often completed later once a lot of business necessities are noted
or changes are requested and accommodated.
• Below diagram describe the DSDM life cycle:
• The DSDM tool (www.dsdm.org) could be a worldwide cluster of member
companies that put together tackle the role of “keeper” of the strategy.
• The pool has outlined AN Agile Development Model, known as the DSDM life
cycle that defines 3 different unvarying cycles, preceded by 2 further life cycle
activities:
• Feasibility Study:
It establishes the essential business necessities and constraints related to the
applying to be designed then assesses whether or not the application could be a
viable candidate for the DSDM method.
• Business Study:
It establishes the use and knowledge necessities that may permit the applying to
supply business value; additionally, it is the essential application design and
identifies the maintainability necessities for the applying.
• Functional Model Iteration:
It produces a collection of progressive prototypes that demonstrate practicality
for the client.
(Note: All DSDM prototypes are supposed to evolve into the deliverable
application.) The intent throughout this unvarying cycle is to collect further
necessities by eliciting feedback from users as they exercise the paradigm.
• Design and Build Iteration:
It revisits prototypes designed throughout useful model iteration to make
sure that everyone has been designed during a manner that may alter it to
supply operational business price for finish users. In some cases, useful
model iteration and style and build iteration occur at the same time.
• Implementation:
It places the newest code increment (an “operationalized” prototype) into
the operational surroundings. It ought to be noted that:
• (a) the increment might not 100% complete or,
• (b) changes are also requested because the increment is placed into place. In either
case, DSDM development work continues by returning to the useful model iteration
activity.
• DSDM is often combined with XP to supply a mixed approach that
defines a solid method model (the DSDM life cycle) with the barmy
and bolt practices (XP) that are needed to create code increments.
additionally, the ASD ideas of collaboration and self-organizing groups
are often tailored to a combined method model.
5.2.1.4. Scrum

• Scrum is a popular agile framework used by teams to establish a hypothesis, try it

out, reflect on the experience, and make adjustments.
• Teams are also able to incorporate practices from other frameworks depending
on their requirements.
With Scrum:

• Teams can deliver deliverables efficiently

• It enables to use their time and money efficiently
• Teams have greater visibility
• Gain feedback from clients and customers
• Individual effort of team members are given focus
• Let’s now talk about the Scrum framework.
5.2.1.4. Scrum
What is Scrum?
• Scrum is a framework that helps agile teams to work together. Using it, the team members can
deliver and sustain the complex product.

• It encourages the team to learn through practice, self-organize while working on the problem.

• Scum is a work done through the framework and continuously shipping values to customers.

• Its principle and lessons can be applied to all kinds of teamwork.

• Why is Scrum popular : Due to its policy and experiences

• The Scrum describes a set of tools, meetings, and roles that help the teams structure. It also
manages the work done by the team
The framework
• Scrum and agile are not the same thing because Scrum focused on continuous improvement,
which is a core foundation of agile.
• Scrum framework focuses on ongoing getting work done.
What are sprints?
• With scrum, a product is built in a series of repetition called sprints. It breaks down big complex
projects into bite-size pieces.

• It makes projects more manageable, allows teams to ship high quality, work faster, and more
frequently.

• The sprints give them more flexibility to adapt to the changes.

• Sprints are a short, time-boxed period for Scrum team that works to complete a set amount of
work.

• Sprints are the core component of Scrum and agile methodology.

• The right sprints will help our agile team to ship better software.
What is sprint plan?

• Sprint plan is an action in Scrum that kicks off the sprint.

The primary purpose of sprint plan is to define what can deliver in the sprint.

• It also focuses on how the work will be achieved. It is done in combination

with the whole Scrum team members.

• The sprint is a set of the period where all the work to be done. Before we
start the development, we have to set up the sprint.

• We need to describe how long time is required to achieve the sprint goal
and where we are going to start.
Factors affecting Sprint planning
• The What: The product owner describes the goal of the
sprint and the backlog items which contribute to achieve
that goal.

• The How: Agile development team plans its necessary

work on how to achieve and deliver the sprint goal.

• The Who: The product owner defines the goal based on

the value that the customers seek. And the developer
needs to understand how they can or cannot deliver that
goal.

• The Inputs: The product backlog provides the list of input

stuff that could potentially be part of the current sprint.
The team looks over the existing work done in incremental
ways.

• The Outputs: The critical outcome of sprint planning is to

meet described team goal. The product set the goal of
sprint and how they will start working towards the goal.
What is the product backlog?
• A product backlog is a registered list of work for the development team.
• It is driven from the roadmap and its requirements. The essential task is represented at the top of
the product backlog so that the team member knows what to deliver first.
• The developer team doesn't work through the backlog from the product owner's side and product
owner doesn't push the work to the developer team.
• The developer team pulls work from the product backlog.
Backlog starts with the two "R"s
• The fundamental product backlog is provided by a team's roadmap and requirements. Roadmap
repetition breaks down into several epics, and each epic will have several requirements and user
stories.
• The product owner organizes each of the customer stories into a single list. This story is organized
for the development team. The product owner chooses to deliver first complete epic.

• The factors that influence a product owner's prioritization

 Priority of customer
 Importance of getting feedback
 Relative implementation difficulty
 Symbiotic relationships between work items
 Retrospective : looking back on or dealing with past events or situations.

Scrum Framework
Let’s talk about each of these steps.
1. Product Backlog
A list of tasks that need to be completed to
achieve the stakeholders' goals is set up.
2. Sprint Planning
The team determines the tasks from the
product catalog they aim to work on during
the sprint.
3. Sprint Backlog
The tasks discussed during the sprint
planning process are added to the sprint
backlog.
4. Scrum Team
A team of 5 to 9 members work on the
tasks.
5. Daily Scrum
The team has daily scrum meetings of 15
minutes, where the team members
synchronize their activities and plan what
they plan to do for the next 24 hours.
6. Sprint Review
Once the sprint is complete, a sprint review
takes place. This review involves the scrum
master, product owner, and stakeholders.
During this meeting, the team shows off what
they accomplished during the sprint. During this
time, questions are asked, observations are
made, feedback and suggestions are also given.
7. Product Backlog (2)
The product owner presents the product
backlog to the stakeholders to get their
feedback for upcoming sprints and other related
product backlogs.
8. Sprint Retrospective
After the review is done, a meeting called sprint
retrospective takes place. During this meeting,
past mistakes, potential problems, and new
ways to handle issues are identified. Data from
here is incorporated into the new sprint.
9. Increment
A workable output is given to the stakeholders.
 Scrum
Agile

It’s a set of principles that are iterative It’s an implementation of an agile

Methodology
and incremental methodology

It’s best suited for projects that involve It’s used in projects where the
Projects
a small team of experts requirements are changing constantly

The project head takes care of all There’s no leader. The Scrum master and
Leadership
tasks and is vital to the project the team addresses the issues

Flexibility Changes cannot be handled frequently Teams can react to changes quickly

The methodology provides frequent With each sprint, builds are delivered to
Delivery
delivery to the end-user other clients for feedback

Face-to-face interaction takes places The daily stand-up meeting enables

Collaboration
across cross-functional teams collaboration between the team members

The design and execution can be

Design The design and execution is simple
innovative and experimental
5.2.1.5. Crystal

Crystal methods in Agile Development/Framework:

• The crystal method is an agile framework that is considered a lightweight or agile methodology that focuses
on individuals and their interactions.
• A lightweight methodology is a software development method that has only a few rules and practices, or
only ones that are easy to follow.
• The methods are color-coded to significant risk to human life.
• It is mainly for short-term projects by a team of developers working out of a single workspace.
• Among a few Agile Software Development Life Cycle (SDLC) models crystal is considered as one of the Agile
SDLC models.

Two core beliefs of the Crystal method:

• Find your own way and methods to optimize workflow.
• Make use of unique methods to make the project unique and dynamic.
History of the Crystal Method:
• Developed by an American scientist named Alistair Cockburn who
worked at IBM.
• He decided not to focus on step-by-step developmental strategies,
but to develop team collaboration and communication.

Some of the traits of Cockburn’s Crystal method were:

• Human-powered i.e. the project should be flexible and people
involved in preferred work.
• Adaptive i.e. approaches don’t have any fixed tools but can be
changed anytime to meet the team’s specific needs.
• Ultra-light i.e. this methodology doesn’t require much documentation.
Properties of Crystal Agile Framework:
• Frequent Delivery- It allows you regularly deliver the products and test
code to real users. Without this, you might build a product that nobody
needs.

• Reflective Improvement- No matter how good you have done or how bad
you have done. Since there are always areas where the product can be
improved, so the teams can implement to improve their future practices.

• Osmotic Communication- Alistair stated that having the teams in the same
physical phase is very much important as it allows information to flow in
between members of a team as in osmosis.

• Personal Safety- There are no bad suggestions in a crystal team, team

members should feel safe to discuss ideas openly without any fear.
• Properties of Crystal Agile Framework:

• Focus- Each member of the team knows exactly what to do, which enables them to focus
their attention. This boosts team interaction and works towards the same goal.

• Easy access to expert users- It enhances team communication with users and gets
regular feedback from real users.

• Technical tooling- It contains very specific technical tools which to be used by the
software development team during testing, management, and configuration. These tools
make it enable the team to identify any error within less time.

• Continuous learning – The framework emphasizes on continuous learning, enabling

team members to acquire new skills and knowledge, and apply them in their work.

• Teamwork – The framework stresses on the importance of teamwork, promoting

collaboration, and mutual support among team members.

• Timeboxing – The framework adopts timeboxing to manage project deadlines, ensuring

that the team delivers within set timelines.
Properties of Crystal Agile Framework:

• Incremental development – The framework promotes incremental development,

enabling the team to deliver working software frequently, and adapt to changes as they
arise.

• Automated testing – The framework emphasizes on automated testing, enabling the

team to detect and fix bugs early, reducing the cost of fixing errors at later stages.

• Customer involvement – The framework emphasizes on involving customers in the

development process, promoting customer satisfaction, and delivering products that
meet their needs.

• Leadership – The framework encourages leadership, enabling team members to take

ownership of their work and make decisions that contribute to the success of the
project.
How does Crystal function?

• Till now, we got to know that crystal is a family of various

developmental approaches, and it is not a group of prescribed
developmental tools and methods.

• In the beginning, the approach is set by considering the business

requirements and the needs of the project.

• Various methodologies in the Crystal family also known as weights of

the Crystal approach are represented by different colors of the
spectrum.
• Crystal family consists of many variants like Crystal Clear, Crystal Yellow,
Crystal Red, Crystal Sapphire, Crystal Red, Crystal Orange Web, and Crystal
Diamond.
• Crystal Clear- The team consists of only 1-6 members that is suitable for
short-term projects where members work out in a single workspace.
• Crystal Yellow- It has a small team size of 7-20 members, where feedback is
taken from Real Users. This variant involves automated testing which
resolves bugs faster and reduces the use of too much documentation.
• Crystal Orange- It has a team size of 21-40 members, where the team is
split according to their functional skills. Here the project generally lasts for
1-2 years and the release is required every 3 to 4 months.
• Crystal Orange Web- It has also a team size of 21-40 members were the
projects that have a continually evolving code base that is being used by the
public.
• It is also similar to Crystal Orange but here they do not deal with a single
project but a series of initiatives that required programming.
• Crystal Red- The software development is led by 40-80 members where the
teams can be formed and divided according to requirements.
• Crystal Maroon- It involves large-sized projects where the team size is 80-200
members and where methods are different and as per the requirement of the
software.
• Crystal Diamond & Sapphire- This variant is used in large projects where there
is a potential risk to human life.
Benefits of using the Crystal Agile Framework :
• Facilitate and enhance team communication and accountability.
• The adaptive approach lets the team respond well to the demanding requirements.
• Allows team to work with the one they see as the most effective.
• Teams talk directly with each other, which reduces management overhead.
• Faster delivery – The framework enables the team to deliver working software faster, which can
help gain a competitive advantage in the market.
• Higher quality – The framework emphasizes on quality, enabling the team to detect and fix
defects early in the development process, resulting in a higher quality product.
• Improved customer satisfaction – The framework promotes customer involvement, enabling the
team to deliver products that meet customer needs, resulting in higher customer satisfaction.
• Increased productivity – The framework enables the team to focus on delivering the highest
value features, which can increase productivity and reduce waste.
• Flexibility – The framework is highly adaptable, enabling the team to adjust to changing
requirements, and make decisions based on real-time feedback.
• Empowerment – The framework promotes empowerment, enabling team members to take
ownership of their work, and make decisions that contribute to the success of the project.
• Reduced risk – The framework promotes risk management, enabling the team to identify and
mitigate potential risks early in the development process, reducing the likelihood of project
failure.
Drawbacks of using the Crystal Agile Framework :
• A lack of pre-defined plans may lead to confusion and loss of focus.
• Lack of structure may slow down inexperienced teams.
• Not clear on how a remote team can share knowledge informally.
• Lack of predictability – The framework’s emphasis on adaptability and flexibility may result in a
lack of predictability, making it difficult to plan and estimate project timelines and budgets.
• Lack of documentation – The framework’s emphasis on communication and collaboration may
result in a lack of documentation, making it difficult to track progress and maintain a record of
decisions.
• Limited scalability – The framework may not be suitable for large or complex projects, as the lack
of structure and predefined plans may make it difficult to manage teams at scale.
• Dependence on team expertise – The framework relies heavily on the expertise and skills of the
development team, which may not be suitable for teams with limited experience or knowledge.
• Lack of clarity on roles and responsibilities – The framework’s emphasis on self-organizing teams
may result in a lack of clarity on roles and responsibilities, leading to confusion and a loss of focus.
• Inability to handle regulatory requirements – The framework may not be suitable for projects
with strict regulatory requirements, as the lack of documentation and structure may not meet
compliance standards.
• Potential for informal knowledge sharing – The framework’s emphasis on osmotic
communication may result in informal knowledge sharing, which may be difficult to track and
monitor for accuracy and completeness.
• The Crystal Method is expandable.

• May be used by small teams or large teams to work on simple or complex

objects.

• Places importance on developmental skills and interactions which in turn

encourage the exchange of ideas.

• Also beneficial for the clients as it delivers the most important

components of the product first.

• But on the other hand, the Crystal Method does not plan based on the
requirements of the projects.
5.2.1.6. Feature Driven Development (FDD)

• Feature Driven Development (FDD) is an agile framework that, as its

name suggests, organizes software development around making
progress on features.

• Features in the FDD context, though, are not necessarily product

features in the commonly understood sense.

• They are, rather, more akin to user stories in Scrum. In other words,
“complete the login process” might be considered a feature in the
Feature Driven Development (FDD) methodology.
History
• FDD was first applied in the year 1997 on a real-world application by Jeff
De Luca for large software development with specific needs of 15-month
and 50 persons and published as a discussion in book Java Modeling in
Color with UML in the year 1999.
• FDD Lifecycle
• Build overall model
• Build feature list
• Plan by feature
• Design by feature
• Build by feature
Characteristics of FDD
• Short iterative: FDD lifecycle works in simple and short iterations to efficiently finish the work on
time and gives good pace for large projects.
• Customer focused: This agile practice is totally based on inspection of each feature by client and
then pushed to main build code.
• Structured and feature focused: Initial activities in lifecycle builds the domain model and features
list in the beginning of timeline and more than 70% of efforts are given to last 2 activities.
• Frequent releases: Feature-driven development provides continuous releases of features in the
software and retaining continuous success of the project.
Advantages of FDD
• Reporting at all levels leads to easier progress tracking.
• FDD provides continuous success for larger size of teams and projects.
• Reduction in risks is observed as whole model and design is build in smaller segments.
• FDD provides greater accuracy in cost estimation of the project due to feature segmentation.
Disadvantages of FDD
• This agile practice is not good for smaller projects.
• There is high dependency on lead programmers, designers and mentors.
• There is lack of documentation which can create an issue afterwards.