Software Engineering

Syllabus

Unit 1 : Introduction to Software Engineering Process

Unit 2 : Requirement Engineering and Analysis

Unit 3 : Design Engineering

Unit 4 : Project Planning, Management and Estimation

Unit 5 : Software Quality and Testing

Unit 6 : Formal Methods, Recent Trends in Software

Engineering
Syllabus
Unit 1 : Introduction to software Engineering Process

Software Engineering Fundamentals: Nature of Software, Software Engineering

Practice, Software Process, Software Myths.

Process Models : A Generic Process Model, Linear Sequential Development

Model, Iterative Development Model,The incremental Development Model

Agile software development: Agile manifesto, agility principles, Agile methods,

myth of planned development, Introduction to Extreme programming and
Scrum.

Agile Practices: test driven development, pair programming, continuous

integration in DevOps , Refactoring

Case Study An information system – Library Management system

Syllabus
Unit 2 : Requirements Engineering & Analysis

Requirements Engineering: User and system requirements, Functional and

non- functional requirements, requirements engineering (elicitation,
specification, validation, negotiation) prioritizing requirements (Kano
diagram), requirement traceability matrix(RTM)

Software Requirements Specification (SRS): software requirements

Specification document, Software Requirements Specification (SRS): software
requirements Specification document

Requirements Analysis: Analysis Model, data modeling, scenario based modeling,

class based modeling, Flow oriented modeling, behavioral modeling-Introduction to
UML Diagrams

Case Study : Library Management system

Syllabus

Unit 3 : Design Engineering

Design Engineering : Design Process & quality, Design Concepts, design

Model, Pattern-based Software Design. Architectural Design :Design
Decisions,Views, Patterns, Application Architectures,

Component level Design: component, Designing class based components,

conducting component-level design, User Interface Design:The golden rules,
Interface Design steps& Analysis, Design Evaluation

Case Study : Library Management system

Syllabus
Unit 4 : Project Planning, Management And Estimation

Project Planning: Project initiation, Planning Scope Management, Creating the

Work Breakdown Structure, scheduling: Importance of Project Schedules,
Developing the Schedule using Gantt Charts, PERT/ CPM

Project Management:The Management Spectrum, People, Product, Process,

Project, The W5HH Principle, Metrics in the Process and Project Domains,
Software Measurement: size & function oriented metrics(FP & LOC), Metrics for
Project

Project Estimation: Software Project Estimation, Decomposition Techniques, Cost

Estimation Tools and Techniques,Typical Problems with IT Cost Estimates.

Case Study : Project Management tool like OpenProj or MS Project

Syllabus
Unit 5 : software Quality And Testing

Quality Concepts: Quality, software quality, Quality Metrics, software quality

dilemma, achieving software quality

Software Testing: Introduction to Software Testing, Principles of Testing,Test

plan,Test case,Types of Testing,Verification & Validation,Testing strategies, Defect
Management, Defect Life Cycle, Bug Reporting, debugging.

Project Estimation: Software Project Estimation, Decomposition Techniques, Cost

Estimation Tools and Techniques,Typical Problems with IT Cost Estimates.

Case Study : Software testing tool like selenium

Syllabus

Unit 6 : Formal Methods Recent Trends In /oftware

Engineering

Recent Trends in SE : SCM, Risk Management,Technology evolution, process

trends, collaborative development, software reuse, test-driven development, global
software development challenges, CASE – taxonomy, tool-kits, workbenches,
environments, components of CASE, categories (upper, lower and integrated
CASE tools), Introduction to agile tools Jira, Kanban

Case Study : CASE software/ HP Quality Center (QC) / Jira

Text Books

1. Roger Pressman,“/oftware Engineering: A Practitioner’s Approach”,

McGraw Hill, I/BN 0-07- 337597-7

2. Rajib Mall,“Fundamentals of /oftware Engineering”,Prentice Hall

India,
I/BN-13:9788-1203- 4898-1

3. https://nptel.ac.in/courses/106/105/106105182/

4. http://www2.cs.uh.edu/~rsingh/documents/software_design/TDD.pdf
 What is
Software?
Software encompasses: (1) instructions (computer programs) that when
executed provide desired features, function, and performance; (2) data
structures that enable the programs to adequately store and manipulate
information and (3) documentation that describes the operation and use of
the programs.

10
 Software Products
⚫ Generic products
⚫ Stand-alone systems that are marketed and sold to any customer
who
wishes to buy them.
⚫ Examples – PC software such as editing, graphics programs,
project management tools; software for specific markets such as
appointments systems for dentists.
⚫ Customized products

⚫ Software that is commissioned by a specific customer to meet their

own needs.
⚫ Examples – embedded control systems, traffic monitoring systems.

11
 Features of
Software?
⚫ Its characteristics that make it different from other things human being build.

Features of such logical system:

⚫ Software is developed or engineered, it is not manufactured in the classical
sense
which has quality problem.

⚫ Software doesn't "wear out.” but it deteriorates (due to change). Hardware

has
bathtub curve of failure.
⚫ Although the industry is moving toward component-based construction ,
most
software continues to be custom-built.
12
 Failure (“Bathtub”)Curve for
Hardware
Failure Rate

Wear out

Time

13
 Wear vs. Deterioration

14
 Software Applications
⚫ System software

⚫ Application software

⚫ Engineering/scientific
software
⚫ Embedded software

⚫ Product-line software

⚫ Web-Apps

⚫ AI

15
 Software Applications
⚫ System software: such as compilers, editors, file management utilities
⚫ Application software: stand-alone programs for specific needs.
⚫ Engineering/scientific software: Characterized by “number crunching” algorithms such
as
automotive stress analysis, molecular biology, orbital dynamics etc
⚫ Embedded software resides within a product or system. (key pad control of a microwave
oven,
digital function of dashboard display in a car)
⚫ Product-line software focus on a limited marketplace to address mass consumer market.
(word
processing, graphics, database management)
⚫ WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database
and business applications.
⚫ AI software uses non-numerical algorithm to solve complex problem. Robotics, expert
16 system,
pattern recognition game playing
 Software—New Categories
⚫ Open world computing — distributed computing due to wireless

networking. How to allow mobile devices, personal computer,

enterprise system to communicate across vast network.
⚫ Netsourcing — the Web as a computing engine. How to architect simple
and
sophisticated applications to target end-users worldwide.
⚫ Open source — ”free” source code open to the computing community

⚫ Cognitive machines

17
 Software Engineering Definition
The Seminal definition:
[Software engineering is] the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and works
efficiently on real machines.

The IEEE definition:

Software Engineering: The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.

18
Importance of Software Engineering
⚫ More and more, individuals and society rely on advanced software systems.
We need to be able to produce reliable and trustworthy systems
economically and quickly.

⚫ It is usually cheaper, in the long run, to use software engineering methods

and techniques for software systems rather than just write the programs
as if it was a personal programming project. For most types of
system, the majority of costs are the costs of changing the software after
it has gone into use.

19
Software Engineering: A Layered
Technology

tools
methods
process model
a “quality”
focus
 Any engineering approach must rest on organizational commitment to
quality
which fosters a continuous process improvement culture.

20
Software Engineering: A
Layered Technology

 Process layer as the foundation defines a framework with activities

for effective delivery of software engineering technology. Establish the
context where products (model, data, report, and forms) are produced,
milestone are established, quality is ensured and change is managed.
 Method provides technical how-to’s for building software. It
encompasses many tasks including communication, requirement analysis,
design modeling, program construction, testing and support.
 Tools provide automated or semi-automated support for the process
and
methods.

21
 A Common Process Framework

Common process framework

Framework activities
Tasks
Milestones, deliverables
SQA checkpoints

Umbrella Activities

22
 Framework Activities
⚫ Communicatio
n
⚫ Planning

⚫ Modeling

⚫ Construction

⚫ Deployment

23
 Umbrella
Activities
⚫Software project tracking and control: assess progress against the plan and take actions
to maintain the schedule.
⚫ Risk management: assesses risks that may affect the outcome and quality.
⚫ Software quality assurance: defines and conduct activities to ensure quality.
⚫ Technical reviews: assesses work products to uncover and remove errors before going to
the next activity.
⚫ Measurement: define and collects process, project, and product measures to
ensure
stakeholder’s needs are met.
⚫ Software configuration management: manage the effects of change throughout the
software process.
⚫ Reusability management: defines criteria for work product reuse and establishes
mechanism
to achieve reusable components.
⚫ Work product preparation and production: create work products such as models,
24 documents,
logs, forms and lists.
 Software Myths [Management
Myths]
⚫ Myth 1: We already have a book that’s full of standards and procedures
for
building the software.

⚫ Myth 2: If we get behind the schedule, we can add more programmers

and
catch up.

⚫ Myth 3: If I decide to outsource the software project to a third party, I can

just
relax and let that firm built it.
25
 Software Myths [Practitioner’s Myths]

⚫ Myth 1: Once we write the program and get it to work, our job is done.

⚫ Myth 2: Until I get the program running, I have no way of assessing its
quality.

⚫ Myth 3: software engineering will make us create voluminous and

unnecessary
documentation and will invariably slow us down.

26
 Software Myths [Customer
Myths]
⚫ Myth 1: A general statement of objectives is sufficient to begin
writing
programs- We can fill in the details later.

⚫ Myth 2: Software requirements continually change, but the change can

be
easily accommodated because software is flexible.

27
 Process Models

28
 A Generic Process Model

29
 The Waterfall Model

Communicat
ion Plannin
requirement
project gat
init iat ion g Modelin
hering
estimating g
trackin Const ruct
schedulin design
g analysis ioncode Deployment
g
t est delivery
support
f
eedbac
k

30
 The Waterfall Model

The waterfall process model is oldest paradigm for the software engineering.

Disadvantages:
⚫ Real projects rarely follow the sequential flow.

⚫ It is often difficult for customer to state all requirements explicitly.

⚫ The customer must have patience. A working version of program(s) will not
be
available until late in the project time span.

31
 The Incremental Model

increment # n
Co m m u n i c a t i o n
Pl a n n i n g
M o d e l i n g
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e r
y
fe e d b a c k

d e l i v e ry of
nt h i n cre me n t
increment # 2

Co m m u n i c a t i o n
Pl a n n i n g
M o d e l i n g
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e
n t d e l i v e r y of
t es t d e l i v e ry

increment # 1 fe e d b a c k 2 n d i n cre me n t

Co m m u n i c a i o n
Pl a n n i n g
M o d e l i n g
analy s is Co n s t ru c t i o n
des ign
c ode
n t
De p l o y m e
d e l i v e r y of
t es t d e l i v e ry
fe e d b a c k 1st i n cremen t

project calendar t ime

32
 The Incremental Model

Advantages:
⚫ Useful when staffing is unavailable. Early increments can be implemented
with
fewer people. More staff may be added later in the process.

⚫ Increments can be planned to manage technical risks. (eg. availability date

of new hardware is uncertain)

33
 The Iterative Process Flow

34
 The Evolutionary Process Flow

35
 Evolutionary Models: Prototyping

Qu ick p lan

Communicat ion

Mo d e l in g
Qu ick d e sig
n

Deployment
De live ry
& Fe e Const ruct ion
dback of
prot ot ype

36
 Evolutionary Models: Prototyping
Advantages:
⚫ The prototyping serves as a mechanism for identifying software
requirements.

⚫ Prototype can serve as “ the first system”

Disadvantages:

⚫ Prototype is built quickly without considering overall software quality

, maintainability.

⚫ Inappropriate tools/ programming languages may be used.

37
 Evolutionary Models: The Spiral

38
 Evolutionary Models: The Spiral

planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback
test

39
 Evolutionary Models: The Spiral
Advantages:

⚫ Realistic approach to the development of large scale systems.

⚫ Uses prototyping as risk reduction mechanism.

Disadvantages:

⚫ It may be difficult to convince customers that the evolutionary approach

is
controllable.

40
 The Parallel Process Flow

41
 The RAD Model
Team # n
M o d e lin g
business m odeling
data m odeling
process m odeling

Co n st ru ct io n
com ponent reuse
Team # 2 autom atic code
Communicat ion generation
t esting
Mo d eling
bu si ness m o d el i n g
d a t a m o d el i n g
process m o d el i n g

Planning
Co nst ruct io n De ployme nt
Team # 1 com p o n e n t reuse int egrat ion
a u t om at ic code
g e n e r at ion
delivery
Mode ling t est ing feedback
business modeling
dat a modeling
process modeling

Const ruct ion

component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days

42
 The RAD Model
Advantages:
⚫ Quick development of software products.

Disadvantages:
⚫ High skilled resources required.

⚫ Proper modularization of project required.

⚫ Difficult to manage

⚫ Not appropriate when technical risks are

high.

43
 Agile Software
Development

44
 Agile Software Development

⚫ Classical methods of software development

⚫ huge effort during the planning phase

⚫ poor requirements conversion in a rapid changing

environment
⚫ treatment of staff as a factor of production

⚫ New methods:

Agile Software Development Methodology

45
 The Manifesto for Agile Software
Development
⚫ “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.”

46
 What is “Agility”?

⚫ Effective (rapid and adaptive) response to change

⚫ Effective communication in structure and attitudes among all team

members,
technological and business people, software engineers and managers 。
⚫ Drawing the customer into the team. Eliminate “us and them” attitude.

⚫ Planning in an uncertain world has its limits and plan must be flexible.

⚫ Organizing a team so that it is in control of the work performed

47
 Agility Principles - I
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference
to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team
is
face–to–face conversation.

48
 Agility Principles - II
7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self–organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

49
 Agile Methods

⚫ Scrum

⚫ Extreme Programming

⚫ Adaptive Software Development (ASD)

⚫ Dynamic System Development Method

(DSDM)

50
 Human Factors
⚫ the process molds to the needs of the people and team, not the other way around

⚫ key traits must exist among the people on an agile team and the team itself:

⚫ Competence. ( talent, skills, knowledge)

⚫ Common focus. ( deliver a working software increment )

⚫ Collaboration. ( peers and stakeholders)

⚫ Decision-making ability. ( freedom to control its own destiny)

⚫ Fuzzy problem-solving ability.(ambiguity and constant changes, today problem may not be
tomorrow’s problem)

⚫ Mutual trust and respect.

⚫ Self-organization. ( themselves for the work done, process for its local environment, the
work schedule)

51
 Extreme Programming
(XP)
⚫ The most widely used agile process, originally proposed by Kent Beck in 2004. It uses an object-
oriented
approach.
⚫ XP Planning

⚫ Begins with the listening, leads to creation of “user stories” that describes required output,
features, and functionality. Customer assigns a value(i.e., a priority) to each story.
⚫ Agile team assesses each story and assigns a cost (development weeks. If more than 3 weeks,
customer
asked to split into smaller stories)
⚫ Working together, stories are grouped for a deliverable increment next release.

⚫ A commitment (stories to be included, delivery date and other project matters) is made. Three ways:
1. Either all stories will be implemented in a few weeks, 2. high priority stories first, or 3. the riskiest
stories will be implemented first.
⚫ After the first increment “project velocity”, namely number of stories implemented during the
first release is used to help define subsequent delivery dates for other increments. Customers
can add stories, delete existing stories, change values of an existing story, split stories as
development work proceeds.
52
 Extreme Programming (XP)
spike solut ions
simple design
prot ot ypes
CRC cards
user st ories
values
accept ance t est crit eria
it erat ion plan

refact oring

pair
programming

Release
software increment unit t est
project velocity computed cont inuous int egrat ion

accept ance t est ing

53
 Extreme Programming
(XP)
⚫ XP Design
⚫ Follows the KIS principle (keep it simple) Nothing more nothing less than the story.

⚫ Encourage the use of CRC (class-responsibility-collaborator) cards in an object-oriented

context. The only design work product of XP. They identify and organize the classes that
are relevant to the current software increment.

⚫ For difficult design problems, suggests the creation of “spike solutions”—a design
prototype for that portion is implemented and evaluated.

⚫ Encourages “refactoring”—an iterative refinement of the internal program design. Does

not alter the external behavior yet improve the internal structure. Minimize chances of
bugs. More efficient, easy to read.

54
 Extreme Programming
(XP)
⚫ XP Coding
⚫ Recommends the construction of a unit test for a story before coding commences. So
implementer can focus on what must be implemented to pass the test.
⚫ Encourages “pair programming”. Two people work together at one workstation. Real time
problem solving, real time review for quality assurance.Take slightly different roles.

⚫ XP Testing
⚫ All unit tests are executed daily and ideally should be automated. Regression tests are
conducted to test current and previous components.
⚫ “Acceptance tests” are defined by the customer and executed to assess customer
visible
functionality

55
 The XP Debate

⚫ Requirements volatility: customer is an active member of XP team, changes to requirements are

requested informally and frequently.

⚫ Conflicting customer needs: different customers' needs need to be assimilated. Different vision or
beyond their authority.

⚫ Requirements are expressed informally: Use stories and acceptance tests are the only
explicit manifestation of requirements. Formal models may avoid inconsistencies and errors before the
system is built. Proponents said changing nature makes such models obsolete as soon as they are
developed.

⚫ Lack of formal design: XP deemphasizes the need for architectural design. Complex systems need
overall structure to exhibit quality and maintainability. Proponents said incremental nature limits
complexity as simplicity is a core value.

56
 SCRUM
⚫ Scrum is an agile process that allows us to focus on delivering the highest business value in
the
shortest time.

⚫ It allows us to rapidly and repeatedly inspect actual working software (every two weeks to
one
month).

⚫ The business sets the priorities. Our teams self-manage to determine the best way to deliver the
highest priority features.

⚫ Every two weeks to a month anyone can see real working software and decide to release it as is
or
continue to enhance for another iteration.

57
 SCRUM
⚫ A software development method Originally proposed by Schwaber and Beedle (an activity
occurs during a rugby match) in early 1990.
⚫ Scrum—distinguishing features

⚫ Development work is partitioned into “packets”

⚫ Testing and documentation are on-going as the product is constructed

⚫ Work units occurs in “sprints” and is derived from a “backlog” of existing changing
prioritized
requirements
⚫ Changes are not introduced in sprints (short term but stable) but in backlog.

⚫ Meetings are very short (15 minutes daily) and sometimes conducted without chairs ( what did
you do since last meeting? What obstacles are you encountering? What do you plan to
accomplish by next meeting?)
⚫ “demos” are delivered to the customer with the time-box allocated. May not
contain all functionalities. So customers can evaluate and give feedbacks.

58
 Characteristics
⚫ Self-organizing teams

⚫ Product progresses in a series of month-long “sprints”

⚫ Requirements are captured as items in a list of “product backlog”

⚫ No specific engineering practices prescribed

⚫ Uses generative rules to create an agile environment for delivering

projects

⚫ One of the “agile processes”

59
 How Scrum Works?

60
 Scrum

61
 Sprints
⚫ Scrum projects make progress in a series of “sprints”

⚫ Analogous to XP iterations

⚫ Target duration is one month

⚫ + / - a week or two
⚫ But, a constant duration leads to a better
rhythm

⚫ Product is designed, coded, and tested during the

sprint

62
 No changes during the sprint

Change

Inputs Sprint Tested Code

⚫ Plan sprint durations around how long you can commit to keeping change out of the
sprint

63
 Scrum Framework

⚫ Roles : Product Owner, Scrum Master,Team

⚫ Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, &

Daily
Scrum Meeting

⚫ Artifacts : Product Backlog, Sprint Backlog.

64
 Product Owner
⚫ Define the features of the product

⚫ Decide on release date and content

⚫ Be responsible for the profitability of the product

(ROI)

⚫ Prioritize features according to market value

⚫ Adjust features and priority every iteration, as needed

⚫ Accept or reject work results.

65
 The Scrum Master

⚫ Represents management to the project

⚫ Responsible for enacting Scrum values and practices

⚫ Ensure that the team is fully functional and

productive

⚫ Enable close cooperation across all roles and

functions

⚫ Shield the team from external interferences

66
 Scrum
Team
⚫ Typically 5-10 people

⚫ Cross-functional

⚫ QA, Programmers, UI Designers, etc.

⚫ Members should be full-time

⚫ May be exceptions (e.g., System Admin,

etc.)

⚫ Teams are self-organizing

⚫ Membership can change only between sprints

67
 Ceremonies
⚫ Sprint Planning
Meeting

⚫ Sprint

⚫ Daily Scrum

⚫ Sprint Review Meeting

68
 Spring Planning Meeting

Product Backlog

Team Capabilities
Sprint Goal
Sprint Planning
Business Conditions
Meeting Sprint Backlog
Technology

Current Product

69
 Parts of Sprint Planning Meeting

⚫ 1st Part:

⚫ Creating Product Backlog

⚫ Determining the Sprint Goal.

⚫ Participants: Product Owner, Scrum Master, Scrum

Team

⚫ 2nd Part:

⚫ Participants: Scrum Master, Scrum Team

⚫ Creating Sprint Backlog

70
 Pre-Project/Kickoff
Meeting
⚫ A special form of Sprint Planning Meeting

⚫ Meeting before the begin of the Project

Sprint
⚫ A month-long iteration, during which is incremented a product
functionality

⚫ NO outside influence can interfere with the Scrum team during the Sprint

⚫ Each Sprint begins with the Daily Scrum Meeting

71
 Daily
Scrum
⚫ Parameters

⚫ Daily

⚫ 15-minutes

⚫ Stand-up

⚫ Not for problem solving

⚫ Three questions:

1. What did you do yesterday

2. What will you do today?

3. What obstacles are in your

way?
72
 Daily
Scrum
⚫ Is NOT a problem solving session

⚫ Is NOT a way to collect information about WHO is behind the schedule

⚫ Is a meeting in which team members make commitments to each other and

to
the Scrum Master

⚫ Is a good way for a Scrum Master to track the progress of the Team

73
 Scrum FAQs

⚫ Why daily?

⚫ “How does a project get to be a year late?”

⚫ “One day at a time.”

⚫ Can Scrum meetings be replaced by emailed status

reports?
⚫ No

⚫ Entire team sees the whole picture every day

⚫ Create peer pressure to do what you say you’ll do

74
 Sprint Review Meeting
⚫ Team presents what it accomplished during the sprint

⚫ Typically takes the form of a demo of new features or underlying

architecture
⚫ Informal

⚫ 2-hour prep time rule

⚫ Participants

⚫ Customers

⚫ Management

⚫ Product Owner

⚫ Other engineers

75
 Sprint Retrospective Meeting

⚫ Scrum Team only

⚫ Feedback meeting

⚫ Three questions

⚫ Start

⚫ Stop

⚫ Continue

⚫ Don’t skip for the first 5-6

sprints!!!

76
 Product
Backlog
⚫ A list of all desired work on the project

⚫ Usually a combination of

⚫ story-based work (“let user search and replace”)

⚫ task-based work (“improve exception handling”)

⚫ List is prioritized by the Product Owner

⚫ Typically a Product Manager, Marketing, Internal Customer,

etc.

77
 Product
Backlog
⚫ Requirements for a system, expressed as a prioritized list of Backlog
Items

⚫ Is managed and owned by a Product Owner

⚫ Spreadsheet (typically)

⚫ Usually is created during the Sprint Planning Meeting

⚫ Can be changed and re-prioritized before each PM

78
 Sprint Backlog
⚫ A subset of Product Backlog Items, which define the work for a Sprint

⚫ Is created ONLY by Team members

⚫ Each Item has it’s own status

⚫ Should be updated every day

⚫ No more than 300 tasks in the list

⚫ If a task requires more than 16 hours, it should be broken down

⚫ Team can add or subtract items from the list. Product Owner is not allowed to do
it

79
 Test Driven Development
⚫ We produce well-designed, well-tested, and well-factored code in
small,
verifiable steps.

⚫ Test-driven development, or TDD, is a rapid cycle of testing, coding,

and
refactoring

⚫ If you do this correctly and in incremental steps you can reduce the defects
in
your system.
80
 Test Driven Development
Benefit
s
⚫ Makes finding mistakes easy.

⚫ You express your intent twice, once with a test and another with
production
code.

⚫ All these tests are checked in and become part of your continuous
integration.

81
 Test Driven Development-
Challenges
⚫ It will increase your effort. But should reduce effort at the end of
delivery
cycle.

⚫ If you have legacy code extra effort and time is required to place hooks
for TDD.

⚫ The basic steps of TDD are easy to learn, but the mindset takes a while
to
master.

⚫ This is a skill and requires continuous practice to get better.

82
 Is this Pair Programming?

83
 Pair
Programming
⚫ We help each other succeed.This practice comes from xP.

⚫ When you pair, one person codes—the driver.The other person is the navigator, whose job is to
think

⚫ The driver focuses on writing syntactically correct code.

⚫ The navigator sometimes works on understanding how the current work fits in the over-all design
and
sometimes thinks of the next task.

⚫ Since we are trying to do simple design things are evolving the developers require a lot of
discipline
and pair programming enforces this.

⚫ Above all it allows and forces individuals to collaborate and share knowledge.

84
 Pair Programming- Challenges
⚫ Pair programming can be uncomfortable in the beginning, especially if you
are
not used to collaborating.

⚫ Comfort needs repeating.

⚫ Communication issues.

⚫ Isn’t it more expensive?

85
 Continuous
Integration
⚫ We keep our code ready to ship

⚫ The ultimate goal of continuous integration is to be able to deploy all code.

⚫ Although you won’t release in the middle of a sprint, the point is to be technologically ready, even
if
you are not functionally.

⚫ With Continuous integration, you are integrating in short cycle and thus have smaller changes to
deal
with as you integrate.

⚫ Continuous integration does not make sense unless it’s automated, has a short turn around time
(fast
builds).

⚫ You need tests to fail or pass a build. Tests are the backbone that give you a green or a red light to
take
86 a snapshot of your build.
 Continuous Integration- Challenges
⚫ CI also requires some setup, if you don’t have one.

⚫ Keeping build times short. This might require some serious effort and

might show you the deficiency of your builds.

⚫ And you need a good version control system – VC systems like subversion

that allows atomic check-in.

87
 Thank
You

88