CS1002 – Software Engineering

Submitted by: Unzillah Adan Shahid

Roll No. : 014
Class Section: BSEE19

“On my honor, as student of Sir Syed CASE Institute Islamabad, I have

neither given nor received unauthorized assistance on this academic
work.”

Submitted to:
Mam Anum Amjad
DATE
16/3/2023
Question: Answer the following questions using your knowledge of Agile
Methods.
 Q1 You are in the middle of the sprint and the product owner has come with
one new requirement from the customer, what you do? What is the best way
to handle this?
As a developer, if the product owner comes up with a new requirement in the
middle of the sprint, the first step is to assess the impact of this requirement
on the sprint and the product as a whole. To handle this situation, the best
approach would be to have a discussion with the product owner to understand
the requirement thoroughly. It's essential to ask questions to clarify the
requirement and to identify if there are any dependencies or conflicts with the
existing tasks in the sprint. Once the requirement is understood, the next step
is to assess its impact on the current sprint. The team should discuss the
feasibility of incorporating the new requirement into the current sprint,
including the time and resources required to implement it. The team should
also consider the potential impact of the new requirement on the overall
product timeline and budget. After evaluating the impact, the team should
determine the best course of action, which could include:
1. Adding the new requirement to the current sprint if it's feasible and
won't significantly impact the sprint's timeline or budget.
2. Adding the new requirement to the backlog for future sprints if it's too
complex or requires too many resources to implement in the current
sprint.
3. Rejecting the new requirement if it's not feasible or if it conflicts with
existing requirements.
It's important to remember that any changes made to the sprint should be
communicated to the entire team, including the product owner, so that everyone
is aware of any adjustments and the impact on the sprint. Open communication
and collaboration are essential in managing changes effectively in the middle of a
sprint.
Q2 How does Agile Testing Methodology be different from traditional testing?
Agile Testing Methodology is different from traditional testing in several ways.
Here are some of the key differences:
 1. Iterative and incremental: Agile Testing is an iterative and incremental
approach to testing, which means that testing is performed throughout the
development process and not just at the end of the project. Traditional
testing, on the other hand, is typically performed at the end of the project.
2. Collaborative: Agile Testing is a collaborative effort between the
developers, testers, and the product owner. The testers work closely with
the developers to ensure that the software is tested throughout the
development process. In traditional testing, the testers work independently
of the developers.
3. Continuous feedback: Agile Testing provides continuous feedback on the
quality of the software being developed. This feedback allows the team to
make necessary adjustments early in the development process, which helps
to avoid costly rework later on. In traditional testing, feedback is typically
provided at the end of the project.
4. Test automation: Agile Testing emphasizes test automation, which means
that tests are automated wherever possible. This allows the team to run
tests more frequently and detect issues early in the development process.
Traditional testing relies more on manual testing, which can be time-
consuming and error-prone.
5. Flexibility: Agile Testing is more flexible than traditional testing. The team
can adjust testing requirements and priorities as needed based on feedback
and changes to the software being developed. Traditional testing is typically
more rigid and inflexible.
Overall, Agile Testing is a more collaborative, iterative, and flexible approach
to testing that emphasizes continuous feedback, test automation, and early
detection of issues. These differences help to ensure that the software being
developed meets the needs of the users and is of high quality.
Q3 When the Agile manifesto says ‘People over Process’, why do we still
need a Scrum Master, a role meant to enforce the Scrum process?
The Agile manifesto emphasizes that people are more important than processes,
which means that the focus should be on individuals and their interactions rather
than just following a set of procedures. However, this does not mean that
processes are not important, but rather that they should be designed to support
the people and their interactions.
In an Agile project, a Scrum Master plays a critical role in facilitating the Scrum
process, but their primary responsibility is to serve the team and help remove any
obstacles that may be hindering their progress. The Scrum Master is not there to
enforce the Scrum process but to ensure that the team understands and follows
the process effectively. They act as a coach, mentor, and facilitator for the team.
The Scrum Master's role is to help the team work together more effectively,
communicate more clearly, and deliver high-quality products. They also help the
team stay focused on the goal and help identify any areas for improvement in the
process. This ensures that the team is working collaboratively and efficiently
towards the project's objectives.
In summary, the agile manifesto emphasizes people over process, but it does not
mean that processes are not important. The Scrum Master plays a crucial role in
facilitating the Scrum process, but their primary focus is on serving the team and
helping them to work together more effectively. By doing this, the Scrum Master
ensures that the process is being followed efficiently and effectively, leading to
better outcomes for the project
Q4 Have you faced any situation where your delivery team is not getting along?
Which stage are they in? How to handle this situation?
If such a situation occurs, it's essential to address it early on by promoting open
communication, collaboration, and trust within the team.
The first step is to understand at which stage of development the team is
in. If it's early in the project, team-building activities can be organized to
build trust and collaboration. These activities could include group outings,
team-building exercises, or other activities that help team members get to
know each other better.
If the team is further along in the project, specific issues causing conflict within
the team must be identified and addressed. Facilitating open communication
allows team members to voice their concerns and develop a plan to address them
collaboratively.
It's crucial to address team conflicts early on to maintain productivity and
motivation and ensure that high-quality results are delivered.
Q5 What type of Requirements did you use for your project? Make an
assumption for the requirement chosen. If the customer wants to change the
requirement in the middle of the sprint, how to handle this as a Tester and
Developer?
Requirements are the foundation of any software development project, and they
define what the software should do and how it should behave. Requirements can
be categorized as functional and non-functional requirements.
Functional requirements describe the software's behavior, such as the features,
functions, and capabilities that the software must provide to meet the customer's
needs. Non-functional requirements describe the software's qualities, such as
performance, scalability, reliability, and security.
Assuming a requirement has been chosen, if the customer wants to change the
requirement in the middle of the sprint, it is essential to handle it carefully to
avoid any negative impact on the project's progress. As a tester or developer, the
first step would be to assess the impact of the change and communicate it to the
product owner and the rest of the team.
If the change is minor and can be accommodated within the sprint, the team can
work together to implement the change. However, if the change is significant and
cannot be accommodated within the current sprint, the product owner may need
to prioritize the change for the next sprint.
In any case, it is essential to document the change and communicate it to the
entire team, so everyone is aware of the change and its impact. The team should
also ensure that the change does not negatively impact any previously completed
work or the overall quality of the software. Communication, collaboration, and
flexibility are key to successfully handling changes to requirements in the middle
of a sprint.