Course Objectives

To learn the principles of Software Engineering.

To learn and understand methods of capturing, specifying, visualizing and
analyzing software requirements.

To know design principles to software project development.

To learn basics of IT project management.

To understand software quality attributes and testing principles.

To introduce formal methods and recent trends in Software Engineering.

 Course Outcomes

Classify various software application domains.

Analyze software requirements by using various modeling techniques.

Translate the requirement models into design models.

Apply planning and estimation to any project.

Use quality attributes and testing principles in software development life cycle.

Discuss recent trends in Software engineering by using CASE and agile tools.
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 Software 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, “Software Engineering: A Practitioner’s Approach”,

McGraw Hill, ISBN 0-07- 337597-7

2. Rajib Mall, “Fundamentals of Software Engineering”,Prentice Hall India,

ISBN-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.

12
 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.

13
13
 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.

14
 Failure (“Bathtub”)Curve for Hardware
Failure Rate

Wear out

Time

15
 Wear vs. Deterioration

16
 Software Applications
 System software

 Application software

 Engineering/scientific software

 Embedded software

 Product-line software

 Web-Apps

 AI

17
 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 system,
pattern recognition game playing

18
 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

19
 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.

20
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.

21
21
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.

22
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.

23
 A Common Process Framework

Common process framework

Framework activities
Tasks
Milestones, deliverables
SQA checkpoints

Umbrella Activities

24
 Framework Activities
 Communication

 Planning

 Modeling

 Construction

 Deployment

25
 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, documents,
logs, forms and lists.

26
 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.

27
 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.

28
 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.

29
 Process Models

30
 A Generic Process Model

31
 The Waterfall Model

Communicat ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deployment
code
t est delivery
support
f eedback

32
 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.

33
 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
a n a ly s i s Co n s t ru c t i o n
d e s ig n
c od e De p l o y m e n t
t es t d e l i v e ry
fe e d b a c k

deliv ery of
nt h increment
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
a n a ly s i s Co n s t ru c t i o n
d e s ig n c o de De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
deliv ery of
increment # 1 2nd increment

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
a n a l y s is Co n s t ru c t i o n
d es i gn c od e
t es t
De p l o y m e n t
d e l i v e ry deliv ery of
fe e d b a c k

1st increment

project calendar t ime

34
 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)

35
 The Iterative Process Flow

36
 The Evolutionary Process Flow

37
 Evolutionary Models: Prototyping

Qu ick p l an

Co m m unicat ion

Mo d e l in g
Qu i ck d e sig n

Deployment
De live r y
& Fe e dback Co nst r uct ion
of
pr ot o t yp e

38
 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.

39
 Evolutionary Models: The Spiral

40
 Evolutionary Models: The Spiral

planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

41
 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.

42
 The Parallel Process Flow

43
 The RAD Model
Team # n
M o d e lin g
business m odeling
dat a m odeling
proces s m odeling

C o n s t ru c t io n
com ponent reuse
Team # 2 aut om at ic code
Com m unicat ion generat ion
t es t ing
Mo d el i ng
b u si ne ss m od e l i n g
d a t a m od e l in g
p ro cess m o de l in g

Planning
Co nst r uct i o n De ploym e nt
Team # 1 co m p on e n t re use
int egrat ion
au t om a t i c co d e
ge n e ra t io n
deliv ery
Mode ling t e st i n g f eedback
business modeling
dat a modeling
process modeling

Const r uct ion

component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days

44
 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.

45
 Agile Software Development

46
 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

47
 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.”

http://www.agilemanifesto.org

48
 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

49
 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.

50
 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.

51
 Agile Methods

 Scrum

 Extreme Programming

 Adaptive Software Development (ASD)

 Dynamic System Development Method (DSDM)

52
 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)

53
 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.

54
 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

ref act oring

pair
programming

Release
sof t ware increment
unit t est
project velocit y comput ed cont inuous int egrat ion

accept ance t est ing

55
 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.

56
 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

57
 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.

58
 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.

59
 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.

60
 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”

61
 How Scrum Works?

62
 Scrum

63
 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

64
 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

65
 Scrum Framework

 Roles : Product Owner, Scrum Master,Team

 Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, & Daily

Scrum Meeting

 Artifacts : Product Backlog, Sprint Backlog, and Burndown Chart

66
 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.

67
 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

68
 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

69
 Ceremonies
 Sprint Planning Meeting

 Sprint

 Daily Scrum

 Sprint Review Meeting

70
 Spring Planning Meeting

Product Backlog

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

Current Product

71
 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

72
 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

73
 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?

74
 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

75
 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

76
 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

77
 Sprint Retrospective Meeting

 Scrum Team only

 Feedback meeting

 Three questions

 Start

 Stop

 Continue

 Don’t skip for the first 5-6 sprints!!!

78
 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.

79
 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

80
 Sample Product Backlog

81
 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

82
 Sample Sprint Backlog

83
 Sprint Burn down Chart

 Depicts the total Sprint Backlog hours remaining per day

 Shows the estimated amount of time to release

 Ideally should burn down to zero to the end of the Sprint

 Actually is not a straight line

84
 Sprint Burn down Chart

Progress
900

800
752 762
700
664
619
600
Remaining Effort in Hours

500

400

300

200

85
 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.

86
 Test Driven Development
Benefits

 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.

87
 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.

88
 Is this Pair Programming?

89
 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.

90
 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?

91
 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
a snapshot of your build.

92
 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.

93
 Thank You

94