*Module 1*

1. What is Agile software development?

Agile Software Development is an iterative and incremental approach to building

software where requirements and solutions evolve through collaboration between
cross-functional teams and customers.

Key points :

 Focuses on customer satisfaction through early and continuous delivery

 Encourages flexibility and quick response to changing requirements

 Promotes continuous feedback and improvement

 Emphasizes team collaboration over rigid processes

 Common Agile methods include Scrum, XP (Extreme Programming), Kanban

2. Five key Agile methods and practices?

Here are five key Agile methods and practices :

1. Scrum
A popular Agile framework that divides work into time-boxed sprints (usually 2–
4 weeks). It uses roles like Product Owner, Scrum Master, and Development
Team to deliver incremental product versions.

2. Extreme Programming (XP)

Focuses on high-quality code and customer satisfaction using practices like
pair programming, continuous integration, test-driven development (TDD),
and frequent releases.

3. Kanban
A visual workflow management method that uses boards to track tasks (To Do,
In Progress, Done). It emphasizes continuous delivery and limiting work in
progress (WIP).
4. Lean Software Development
Derived from Lean manufacturing principles. It aims to eliminate waste, optimize
processes, deliver faster, and focus on value to the customer.

5. Daily Stand-up Meetings

A common Agile practice where team members meet briefly (15 minutes) to
 discuss what was done, what will be done, and blockers, ensuring
transparency and quick issue resolution.

3. What are the advantages and disadvantages of Traditional Software

Development?

Traditional Software Development

Traditional software development follows a linear and sequential approach, where

each phase (requirements, design, coding, testing, deployment, maintenance) must be
completed before moving to the next.
Advantages

1. Simple and easy to understand

2. Well-defined documentation

3. Suitable for small and stable projects

4. Easy to manage

Disadvantages

1. Inflexible to changes

2. Late testing and feedback

3. Customer involvement is minimal

4. High risk for complex projects

4. Types of Feasibility Analysis?

Types of Feasibility Analysis

Feasibility analysis is the process of evaluating whether a proposed software project is

practical, viable, and worth implementing.

1. Technical Feasibility

Assesses whether the required technology, tools, hardware, and technical expertise
are available to develop the system.
2. Economic Feasibility

Evaluates the cost–benefit aspect of the project, including development cost,

operational cost, and expected benefits or return on investment.
3. Operational Feasibility

Determines whether the system will be accepted and effectively used by users,
considering organizational culture, user training, and support.
4. Legal Feasibility

Checks whether the project complies with legal and regulatory requirements, such as
data protection laws, licensing, and intellectual property rights.
5. Schedule (Time) Feasibility

Analyzes whether the project can be completed within the given time frame using
available resources.

5. What is UML?

UML (Unified Modeling Language) is a standard visual modeling language used to

design, visualize, specify, and document the structure and behavior of software
systems.
It provides a set of standardized diagrams to represent how a system is built and how
it behaves, making communication easier among developers, designers, and
stakeholders.

Key points :
 Used mainly in object-oriented software development

 Helps in system analysis and design

 Improves clarity, documentation, and communication

 Maintained by OMG (Object Management Group)

6. Types of testing?

Types of Software Testing

Software testing is the process of evaluating a system or application to ensure it

works as expected and is free from defects.
1. Unit Testing

Testing of individual components or modules to verify that each unit functions correctly.
2. Integration Testing

Testing the interaction between integrated modules to detect interface defects.

3. System Testing

Testing the complete and integrated system to ensure it meets specified requirements.
4. Acceptance Testing

Performed by the customer or end users to confirm that the system meets business
requirements.
(Types: Alpha testing, Beta testing)
5. Regression Testing

Re-testing the software after changes or bug fixes to ensure existing functionality is not
affected.
6. Black Box Testing

Testing without knowledge of internal code structure, focusing on input–output behavior.

7. White Box Testing

Testing with knowledge of internal code, focusing on logic, paths, and conditions.
8. Performance Testing

Testing system performance under load (includes load testing and stress testing).

7. What is incremental development?

Incremental Development is a software development approach in which the system is

designed, implemented, and delivered in small, manageable parts called
increments.

Each increment adds new functionality to the existing system, and every release
produces a working and usable version of the software.

Key points:

 Development is divided into multiple increments

 Each increment goes through analysis, design, coding, and testing

  Working software is delivered frequently

 User feedback from each increment is used to improve the next one

 Reduces risk and allows early detection of errors

Example:

A library system may first deliver user login, then book search, followed by
issue/return features in later increments.

8. What is Test Driven Development (TDD)?

Test Driven Development (TDD) is a software development practice in which tests

are written before the actual code.

Development follows a short, repeated cycle called Red–Green–Refactor:

 Red – Write a test and see it fail

 Green – Write the minimum code to pass the test

 Refactor – Improve the code without changing functionality

Key points :

 Tests are created before implementation

 Ensures high code quality and fewer defects

 Encourages simple, modular, and maintainable code

 Widely used in Agile and Extreme Programming (XP)

9. What is Traditional Software Development? Explain the Waterfall Model.

(5M / 10M)
Traditional Software Development

Traditional Software Development follows a sequential and structured approach,

where the entire software development process is divided into distinct phases. Each
phase must be completed fully before moving to the next, with little scope for
changes once a phase is finished.
The Waterfall Model is the most widely used traditional model.
Waterfall Model

The Waterfall Model is a linear and sequential software development model where
progress flows steadily downwards like a waterfall through well-defined phases.
Phases of the Waterfall Model

1. Requirement Analysis

o Collects and documents all user requirements

o Requirements are frozen before development starts

2. System Design

o Defines system architecture, data flow, and interfaces

o Converts requirements into technical design

3. Implementation (Coding)

o Actual coding of the software based on design

o Each module is developed separately

4. Testing

o Identifies and fixes defects

o Ensures the system meets requirements

5. Deployment

o Software is delivered and installed for users

6. Maintenance

o Handles bug fixes, updates, and enhancements

Advantages of the Waterfall Model

 Simple and easy to understand

 Clear documentation and milestones

 Easy to manage due to fixed phases

Disadvantages of the Waterfall Model

 Inflexible to requirement changes

 Testing occurs late in the cycle

  Not suitable for complex or evolving projects

10. What is Lean Software Development? Explain its seven principles.(5m)

Lean Software Development

Lean Software Development is an Agile methodology adapted from Lean

manufacturing (Toyota Production System) that focuses on delivering maximum
value to the customer by eliminating waste and improving efficiency in the software
development process.
Seven Principles of Lean Software Development

1. Eliminate Waste

Remove anything that does not add value, such as unnecessary features, delays,
rework, and excessive documentation.
2. Build Quality In

Ensure quality at every stage through practices like continuous testing, code reviews,
and automation, instead of fixing defects later.

3. Create Knowledge

Encourage learning through experimentation, feedback, and iteration, helping teams

make better decisions.
4. Defer Commitment

Make important decisions as late as possible to allow flexibility and adapt to changing
requirements.
5. Deliver Fast

Release software quickly in small increments to get early feedback and reduce risk.

6. Respect People

Empower team members, encourage collaboration, and trust individuals to make

decisions.
7. Optimize the Whole
Focus on improving the entire system, not just individual components or teams.

11. Explain the core components of Scrum and its flow (7 steps). (5M / 10M)
Scrum

Scrum is an Agile framework used to manage and develop complex software products
through iterative and incremental development using time-boxed sprints.
Core Components of Scrum

Scrum is built around three main components: Roles, Artifacts, and Events.

1. Roles

 Product Owner – Defines and prioritizes product requirements in the Product

Backlog.
 Scrum Master – Facilitates Scrum practices and removes impediments.

 Development Team – Designs, develops, tests, and delivers the product

increment.
2. Artifacts

 Product Backlog – Ordered list of all features and requirements.

 Sprint Backlog – Subset of items selected for the current sprint.

 Increment – A potentially shippable product produced at the end of each sprint.

3. Events

 Sprint – Fixed time period (1–4 weeks) to complete selected work.

 Sprint Planning – Decides what work will be done in the sprint.

 Daily Scrum – Short daily meeting to track progress.

 Sprint Review – Demonstrates the completed increment.

 Sprint Retrospective – Reflects on improvements for the next sprint.

Scrum Flow – 7 Steps

1. Create Product Backlog

Product Owner prepares and prioritizes requirements.
2. Sprint Planning
Team selects items from the Product Backlog to work on.
3. Create Sprint Backlog
Selected items are broken into tasks.
 4. Sprint Execution
Development team works on tasks during the sprint.
5. Daily Scrum Meeting
Team meets daily to discuss progress and obstacles.
6. Sprint Review
Completed work is demonstrated to stakeholders.
7. Sprint Retrospective
Team analyzes performance and plans improvements.

12. Explain the core practices of XP. (10M)(100%)

Extreme Programming (XP)

Extreme Programming (XP) is an Agile software development methodology that

emphasizes high-quality code, customer satisfaction, and rapid delivery.
It focuses on continuous feedback, simplicity, and teamwork.

Core Practices of XP

XP is based on several core practices that help developers write better code,
respond to changes, and improve collaboration. Key practices include:

1. Planning Game
 Customer and developers collaborate to plan iterations.

 Requirements are prioritized, and small, achievable goals are set for each
iteration.
2. Small Releases

 Deliver frequent, incremental releases of working software.

 Early delivery allows customer feedback and reduces risks.

3. Metaphor

 Use a shared system metaphor or simple analogy to describe how the system
works.
 Helps team members understand the architecture and design.

4. Simple Design

 Design the simplest solution that works.

  Avoid over-engineering and unnecessary features.
5. Test-Driven Development (TDD)

 Write automated tests before code.

 Ensures high code quality and early detection of errors.

6. Refactoring

 Continuously improve code structure without changing behavior.

 Keeps code clean, maintainable, and efficient.

7. Pair Programming

 Two developers work together on the same code:

o Driver writes code

o Observer/Navigator reviews and guides

 Improves code quality and knowledge sharing.

8. Collective Code Ownership

 Everyone can change any code in the system.

 Encourages team responsibility and faster bug fixes.

9. Continuous Integration

 Integrate and test code frequently (several times a day).

 Detects integration problems early.

10. Sustainable Pace (40-Hour Week)

 Maintain a healthy work pace to avoid burnout.

 Promotes long-term productivity and quality.

11. Customer On-Site

 A real customer representative works with the team daily.

 Ensures requirements are clear and updated continuously.

12. Coding Standards

 Follow consistent coding conventions.

 Improves readability and maintainability of code.

 13. What is Rational Unified Process (RUP)? Explain its four phases. Explain
its workflows.(10M)
Rational Unified Process (RUP)

RUP is an iterative and incremental software development process framework

developed by Rational Software.
It provides a disciplined approach to assigning tasks and responsibilities within a
software development project and ensures high-quality software that meets user
requirements.
Four Phases of RUP

1. Inception

o Define project scope, objectives, and feasibility.

o Identify key requirements and risks.

2. Elaboration

o Analyze requirements in detail.

o Establish the core system architecture.

o Reduce major technical risks.

3. Construction

o Develop the system iteratively.

o Includes coding, integration, and testing.
4. Transition

o Deploy the system to end users.

o Conduct user training, acceptance testing, and bug fixes.

Core Workflows of RUP

RUP defines nine core workflows (also called disciplines) that span the development
lifecycle. They are divided into Engineering Workflows and Supporting Workflows:

1. Business Modeling

 Understand the business context and processes where the system will
operate.
  Create business use-case models to guide development.

2. Requirements

 Capture, analyze, and manage functional and non-functional requirements.

 Use use-case models to define system behavior.

3. Analysis and Design

 Develop software architecture and detailed design.

 Transform requirements into models and components.

4. Implementation

 Actual coding of the system based on the design.

 Break work into components and integrate incrementally.

5. Test

 Verify and validate the system against requirements.

 Includes unit, integration, system, and acceptance testing.

6. Deployment

 Deliver the system to users.

 Includes installation, user training, and deployment of updates.

7. Configuration and Change Management

 Manage changes to requirements, code, and documents.

 Maintain version control and system integrity.

8. Project Management

 Plan, monitor, and control the project.

 Track progress, manage risks, and allocate resources.

9. Environment
 Provide tools, processes, and infrastructure to support development.

 Includes IDEs, modeling tools, and automation support.

*Module 2*

1. People in an Agile team. (2M)

The people in an Agile team typically include:

1. Product Owner (PO) – Represents the customer, manages the product backlog,
and ensures the team delivers value.
2. Scrum Master – Facilitates the Agile process, removes obstacles, and ensures
the team follows Agile practices.
3. Development Team Members – Cross-functional members (developers, testers,
designers, etc.) who build and deliver the product increment.
These are the three key roles in a standard Agile (Scrum) team.

Characteristics of an Agile team.(2m)

Cross-functional – Members have diverse skills (development, testing, design) to
deliver a complete product increment.
1. Self-organizing – The team manages its own work without heavy supervision.

2. Collaborative – Strong communication and teamwork within the team and with
stakeholders.
 3. Flexible and Adaptive – Can quickly respond to changing requirements or
priorities.
4. Committed to Continuous Improvement – Regularly reflects on performance
and adapts processes.

These points capture the key traits of an Agile team.

2. Setting up an Agile team. (2M / 5M)

Define Roles and Responsibilities:

 Product Owner: Manages backlog, represents stakeholders.

 Scrum Master: Facilitates Agile practices, removes obstacles.

 Development Team: Cross-functional members who design, develop, test, and

deliver product increments.

Select Team Members:

 Choose members with complementary skills.

 Ensure mix of developers, testers, designers, and any other required expertise.
Determine Team Size:

 Keep it small (5–9 members) for better communication and efficiency.

Establish Collaboration and Communication:

 Promote daily stand-ups, sprint planning, and retrospectives.

 Use Agile tools (like Jira, Trello) for tracking work.
Foster Agile Mindset:

 Encourage self-organization, adaptability, and continuous improvement.

 Train the team in Agile principles and practices if needed.

3. Developing team skills and why teams should be trained together.

1. Developing Team Skills:

  Agile teams require both technical skills (coding, testing, design) and soft skills
(communication, collaboration, problem-solving).

 Skills are developed through:

o Workshops and training on Agile practices and tools.

o Pair programming or mentoring to share knowledge.

o Hands-on experience in sprints and projects.

o Continuous learning and feedback during retrospectives.

2. Why Teams Should Be Trained Together:

 Promotes Collaboration: Team members learn to work cohesively rather than

as individuals.
 Builds Shared Understanding: Everyone understands Agile principles, roles,
and workflows consistently.
 Enhances Communication: Reduces misunderstandings and improves
coordination.
 Encourages Team Cohesion: Fosters trust and collective responsibility for
project success.
In short: Training together strengthens both skills and team dynamics, making the
Agile team more effective.

4. What is planning? Explain PERT and Gantt charts. (5M)(100%)

Planning is the process of defining project goals, tasks, schedules, and resources
required to achieve the objectives efficiently. It involves deciding what to do, how to do
it, who will do it, and when it will be done. Planning ensures that projects are
completed on time, within budget, and with desired quality.

1. PERT Chart (Program Evaluation and Review Technique):

 A PERT chart is a network diagram used to plan, schedule, and control

complex projects.
 Purpose: Helps identify the critical path (longest sequence of dependent tasks)
to estimate the minimum project duration.
 Features:

o Tasks are represented as nodes or arrows.

 o Shows task dependencies and time estimates (optimistic, most likely,
pessimistic).
o Useful for uncertain or complex projects.
2. Gantt Chart:

 A Gantt chart is a bar chart that represents the project schedule over time.

 Purpose: Shows start and finish dates of tasks and helps track progress.

 Features:

o Tasks are listed vertically; time is shown horizontally.

o Bars represent task duration.

o Can show dependencies, milestones, and completed work.

Difference:

Feature PERT Chart Gantt Chart

Type Network diagram Bar chart

Focus Task dependencies, critical path Task schedule and duration

Best for Complex/uncertain projects Simple scheduling and tracking

Visualization Nodes/arrows Horizontal bars

5. Appreciative Inquiry (AI) – Explain the 4-D cycle. (5M)

Appreciative Inquiry (AI):

 AI is a positive approach to organizational change that focuses on identifying

strengths, successes, and opportunities rather than problems.

 It encourages collaboration, innovation, and continuous improvement by

asking “What works well?” instead of “What’s wrong?”
The 4-D Cycle of AI:

1. Discovery (D1) – Identify what works well

o Focus on the strengths and best practices of the organization or team.

o Ask questions like: “When have we been at our best?”

 o Goal: Discover the positive core that can be leveraged.
2. Dream (D2) – Envision the future

o Imagine what the organization or team could become if its strengths are
fully utilized.

o Encourage creativity and vision-building.

o Goal: Create a shared vision of an ideal future.

3. Design (D3) – Plan and prioritize actions

o Develop strategies, processes, and structures to achieve the dream.

o Decide what needs to change or be implemented to reach the envisioned

future.

o Goal: Design the systems and processes aligned with the vision.
4. Destiny/Delivery (D4) – Implement and sustain

o Take action to achieve the designed strategies.

o Foster continuous learning, empowerment, and ownership within the

team.

o Goal: Sustain positive change and build momentum for ongoing

improvement.

5. Techniques for requirement elicitation and developing the requirement

documents. (5M)

Techniques for Requirement Elicitation and Developing Requirement Documents

1. Requirement Elicitation Techniques

Requirement elicitation is the process of gathering the needs and expectations of

stakeholders for a system or project. Common techniques include:
1. Interviews:

o Conduct one-on-one or group discussions with stakeholders.

o Helps understand their expectations, pain points, and requirements.

2. Questionnaires/Surveys:

o Useful for gathering input from a large group.

 o Helps identify common requirements and priorities.
3. Workshops:

o Collaborative sessions with stakeholders and development team.

o Encourages discussion, clarification, and consensus on requirements.

4. Observation:

o Study the current system or processes in use.

o Helps identify real needs and inefficiencies.

5. Prototyping:

o Create a working model or mock-up of the system.

o Stakeholders provide feedback, helping refine requirements.

6. Brainstorming:

o Team members generate ideas freely to explore potential requirements.

7. Document Analysis:

o Study existing documents, manuals, and reports to gather requirements.

2. Developing Requirement Documents

After elicitation, requirements are documented clearly to guide development. Key steps:
1. Requirement Specification:

o Functional Requirements: What the system should do (features,

operations).
o Non-Functional Requirements: Performance, usability, security,
reliability.
2. Requirement Prioritization:

o Categorize requirements as Must-have, Should-have, Could-have,

Won’t-have (MoSCoW method).

3. Use Cases / User Stories:

o Describe interactions between users and the system.

o Helps developers understand real-world scenarios.

 4. Requirement Review and Validation:

o Conduct reviews with stakeholders to ensure completeness, clarity, and

correctness.
o Update the document based on feedback.
5. Requirement Documentation Tools:

o Word, Excel, Jira, Confluence, or specialized requirement management

tools.

6. Team behavior in Extreme Programming (XP). (10M)

Extreme Programming (XP) is an Agile software development methodology that

emphasizes customer satisfaction, continuous feedback, and teamwork. In XP,
team behavior plays a crucial role in ensuring project success.

1. Key Aspects of Team Behavior in XP

1. Collaborative and Cooperative:

o XP teams work closely together, including developers, testers, and

customers.
o Encourages pair programming where two developers work together on
the same code, sharing knowledge and improving quality.
2. Communication:

o Open and frequent communication is essential.

o Daily stand-ups and informal conversations ensure that everyone is aware

of progress and issues.
3. Collective Ownership:

o All team members share responsibility for the codebase.

o Any developer can modify any part of the code, encouraging

accountability and teamwork.
4. Sustainable Pace:
o XP promotes a work-life balance to maintain productivity.

o Teams avoid overtime to prevent burnout, ensuring long-term efficiency.

5. Continuous Feedback:
 o Regular customer feedback and peer code reviews help identify
improvements early.

o Teams are responsive and adapt quickly to changing requirements.

6. Respect and Trust:

o Team members respect each other’s opinions and expertise.

o Trust allows smooth collaboration and quick decision-making.

7. Learning and Improvement:

o Teams are committed to continuous learning through retrospectives and

experiments.

o Encourage improvement of coding practices, testing, and team dynamics.

2. Practices Supporting Team Behavior in XP

 Pair Programming: Enhances collaboration and knowledge sharing.

 Collective Code Ownership: Builds shared responsibility.

 Continuous Integration: Promotes teamwork and reduces integration issues.

 On-site Customer: Improves communication and quick feedback loops.

 Refactoring: Encourages shared understanding of code and quality

improvement.