1

Component based Development

 Component based development is an approach to
software development that focuses on the design
and development of reusable components.
 The component-based development (CBD) model
incorporates many of the characteristics of the spiral
model.
 It is evolutionary in nature , demanding an iterative
approach to the creation of software. However, the
component-based development model composes
applications from prepackaged software components
(called classes).

2
Component based development
3
Unified process Model
 Unified process (UP) is an architecture centric, use
case driven, iterative and incremental development
process. UP is also referred to as the unified software
development process.
 The Unified Process is an attempt to draw on the
best features and characteristics of traditional
software process models, but characterize them in a
way that implements many of the best principles of
agile software development.

4
5
Rapid Application Development Model
 RAD model is Rapid Application Development model.
 It is an adoption of the waterfall model.
 It targets at developing software in a short span of time.
 It is a type of incremental model.
 In RAD model, the components or functions are developed
in parallel as if they were mini projects.
 The developments are time boxed, delivered and then
assembled into a working prototype.
 RAD model has following phases
1. Business Modeling 4. Application Generation
2. Data Modeling 5. Testing and Turnover
3. Process Modeling
6
RAD Model

7
Different phases of RAD model
Phases of RAD Activities performed in RAD Model
model
Business •On basis of the flow of information and distribution between various
Modeling business channels, the product is designed

Data Modeling •The information collected from business modeling is refined into a
set of data objects that are significant for the business

Process •The data object that is declared in the data modeling phase is
Modeling transformed to achieve the information flow necessary to implement a
business function

Application •Automated tools are used for the construction of the software, to
Generation convert process and data models into prototypes

Testing and •As prototypes are individually tested during every iteration, the
Turnover overall testing time is reduced in RAD.
8
When to use RAD Methodology?
 When a system needs to be produced in a short span of
time (2-3 months)
 When the requirements are known
 When the user will be involved all through the life cycle
 When technical risk is less
 When there is a necessity to create a system that can be
modularized in 2-3 months of time
 When a budget is high enough to afford designers for
modeling along with the cost of automated tools for code
generation

9
RAD Model Vs Traditional SDLC
 The traditional SDLC follows a rigid process models with high
emphasis on requirement analysis and gathering before the
coding starts. It puts pressure on the customer to sign off the
requirements before the project starts and the customer doesn’t
get the feel of the product as there is no working build available
for a long time.
 The customer may need some changes after he gets to see the
software. However, the change process is quite rigid and it may
not be feasible to incorporate major changes in the product in
the traditional SDLC.
 The RAD model focuses on iterative and incremental delivery of
working models to the customer. This results in rapid delivery to
the customer and customer involvement during the complete
development cycle of product reducing the risk of non-
conformance with the actual user requirements. 10
Advantages of the RAD Model
 Changing requirements can be accommodated.
 Progress can be measured.
 Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in a short time.
 Reduced development time.
 Increases reusability of components.
 Quick initial reviews occur.
 Encourages customer feedback.
 Integration from very beginning solves a lot of integration
issues.

11
Disadvantages of the RAD Model
 Dependency on technically strong team members for identifying
business requirements.
 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 High dependency on modeling skills.
 Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
 Management complexity is more.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.

12
Agile Modeling
 Rapid development and delivery is now often the most
important requirement for software systems
 Businesses operate in a fast –changing requirement and it is
practically impossible to produce a set of stable software
requirements
 Software has to evolve quickly to reflect changing business needs.
 Plan-driven development is essential for some types of
system but does not meet these business needs.
 Dissatisfaction with the overheads involved in software
design methods of the 1980s and 1990s led to the creation
of agile methods.
 Agile development methods emerged in the late 1990s
whose aim was to radically reduce the delivery time for
working software systems. 13
Agile Development
 Program specification, design and implementation are
inter-leaved
 The system is developed as a series of versions or
increments with stakeholders involved in version
specification and evaluation
 Frequent delivery of new versions for evaluation
 Extensive tool support (e.g. automated testing tools) used
to support development.
 Minimal documentation – focus on working code

14
Agile Model
 Agile model is a combination of iterative and incremental
process models with focus on process adaptability and customer
satisfaction by rapid delivery of working software product.
 Agile Methods break the product into small incremental builds.
 These builds are provided in iterations.
 Each iteration typically lasts from about one to three weeks.
 Every iteration involves cross functional teams working
simultaneously on various areas like –
 Planning / Requirement gathering
 Requirements Analysis
 Design
 Coding
 Unit Testing and
 Acceptance Testing. 15
4 core values of Agile Model
 Individual and team interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

16
Agile Models
 Actually Agile model refers to a group of development
processes. These processes share some basic characteristics
but do have certain subtle differences among themselves.
 A few Agile SDLC models are given below:
 Crystal
 Atern
 Feature-driven development
 Scrum
 Extreme programming (XP)
 Lean development
 Unified process
 DSDM (Dynamic Software Development Method )
17
Principles of Agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in
the development process. Wherever possible, actively work to
eliminate complexity from the system.

18
Advantages of Agile Model
 Working through Pair programming produce well written
compact programs which has fewer errors as compared to
programmers working alone.
 It reduces total development time of the whole project.
 Customer representative get the idea of updated software
products after each iteration. So, it is easy for him to
change any requirement if needed.

19
Disadvantages of Agile Model
 Due to lack of formal documents, it creates confusion and
important decisions taken during different phases can be
misinterpreted at any time by different team members.
 Due to absence of proper documentation, when the project
completes and the developers are assigned to another
project, maintenance of the developed project can become
a problem.

20
Agile Vs Waterfall Method
Agile Model Waterfall Model
•Agile method proposes incremental and •Development of the software flows
iterative approach to software design sequentially from start point to end
point.
•The agile process is broken into •The design process is not broken into an
individual models that designers work on individual models
•The customer has early and frequent •The customer can only see the product
opportunities to look at the product and at the end of the project
make decision and changes to the project
•Agile model is considered unstructured •Waterfall model are more secure
compared to the waterfall model because they are so plan oriented
•Small projects can be implemented very •All sorts of project can be estimated and
quickly. For large projects, it is difficult to completed.
estimate the development time.

21
Agile Vs Waterfall Method
Agile Model Waterfall Model
•Error can be fixed in the middle of the •Only at the end, the whole product is
project. tested. If the requirement error is found
or any changes have to be made, the
project has to start from the beginning
•Development process is iterative, and •The development process is phased, and
the project is executed in short (2-4) the phase is much bigger than iteration.
weeks iterations. Planning is very less. Every phase ends with the detailed
description of the next phase.
•Documentation attends less priority •Documentation is a top priority and can
than software development even use for training staff and upgrade
the software with another team
•Every iteration has its own testing •Only after the development phase, the
phase. It allows implementing regression testing phase is executed because
testing every time new functions or logic separate parts are not fully functional.
are released.

22
Agile Vs Waterfall Method
Agile Model
•In agile testing when an iteration end,
shippable features of the product is
delivered to the customer. New features
are usable right after shipment.
•Testers and developers work together
•At the end of every sprint, user
acceptance is performed
•It requires close communication with
developers and together analyze
requirements and planning
Waterfall Model
•All features developed are delivered at
once after the long implementation
phase.
•Testers work separately from developers
•User acceptance is performed at the
end of the project.
•Developer does not involve in
requirement and planning process.
Usually, time delays between tests and
coding
23
Extreme programming
 A very influential agile method, developed in the late
1990s, that introduced a range of agile development
techniques.
 Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only
accepted if tests run successfully.

24
Extreme Programming Release Cycle

25
User Story Example
 As a user, I can backup my entire hard drive.
 Because an epic is generally too large for an agile team
to complete in one iteration, it is split into multiple
smaller user stories before it is worked on. The epic
above could be split into dozens (or possibly
hundreds), including these two:
 As a power user, I can specify files or folders to backup
based on file size, date created and date modified.
 As a user, I can indicate folders not to backup so that
my backup drive isn't filled up with things I don't need
saved.
26
Extreme programming practices
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’.

Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.

27
 Extreme programming practices
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.

Collective ownership The pairs of developers work on all areas of the system, so that no
islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.

Continuous integration As soon as the work on a task is complete, it is integrated into the
whole system. After any such integration, all the unit tests in the
system must pass.

Sustainable pace Large amounts of overtime are not considered acceptable as the
net effect is often to reduce code quality and medium term
productivity

On-site customer A representative of the end-user of the system (the customer)

should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.

28
XP and agile principles
 Incremental development is supported through small,
frequent system releases.
 Customer involvement means full-time customer
engagement with the team.
 People not process through pair programming, collective
ownership and a process that avoids long working hours.
 Change supported through regular system releases.
 Maintaining simplicity through constant refactoring of
code.

29
Influential XP practices
 Extreme programming has a technical focus and is not
easy to integrate with management practice in most
organizations.
 Consequently, while agile development uses practices
from XP, the method as originally defined is not widely
used.
 Key practices
 User stories for specification
 Refactoring
 Test-first development
 Pair programming

30
User stories for requirements
 In XP, a customer or user is part of the XP team and is
responsible for making decisions on requirements.
 User requirements are expressed as user stories or
scenarios.
 These are written on cards and the development team
break them down into implementation tasks. These tasks
are the basis of schedule and cost estimates.
 The customer chooses the stories for inclusion in the next
release based on their priorities and the schedule
estimates.

31
A ‘prescribing medication’ story

32
 As an Acquisition Gateway User, I need to access
the Acquisition ordering platform behind a secure
login so that I can purchase products.

 As an Acquisition Gateway User, I need to access

the Acquisition ordering platform behind a secure
login so that I can purchase products.

 As an Acquisition Gateway User, I need to review

my previous bids in the Acquisition ordering
platform so that I can remove expired bids.

33
We require an automated gate control system that
should be able to identify a legitimate user at the
entrance and after validation it should give access in the
university.

As a faculty I need to enter in the university via security

gate a need an automated gate control system which will
open once my car enters in the close proximity of gate.

34
 Example 2

 Epic: As a Marketing Lead, I want to have a content

management system so that I can manage and provide
quality content and experience to my readers.

 Story1: As a Content Owner, I want to be able to

create product content so that I can provide
information and market to customers.

 Story 2: As an Editor, I want to review content before

it is published so that I can assure it is optimized with
correct grammar and tone.

35
Story 2: As an Editor, I want to review content before it
is published so that I can assure it is optimized with
correct grammar and tone.

 log in to the content management system

 view existing content page
 edit / update page of content
 add markup comments- save changes
 save changes
 re-assign to Content Owner to make updates
 schedule content publish

36
Examples of task cards for prescribing
medication

37
Refactoring
 Conventional wisdom in software engineering is to design for
change. It is worth spending time and effort anticipating changes
as this reduces costs later in the life cycle.
 XP, however, maintains that this is not worthwhile as changes
cannot be reliably anticipated.
 Rather, it proposes constant code improvement (refactoring) to
make changes easier when they have to be implemented.
 Programming team look for possible software improvements and
make these improvements even where there is no immediate
need for them.
 This improves the understandability of the software and so
reduces the need for documentation.
 Changes are easier to make because the code is well-structured
and clear.
38
Step 1
Find two methods in sub-classes which perform similar steps
Find two methods and extract the parts of each method which
differ in both methods into new methods.
Step 2
Unify the names of the now identical methods
Unify the names of the methods which are now identical.
Step 3
Consolidate method in the parent class
Move one of the identical methods to the parent class and remove
the other one from the sub-class.
Step 4
Create abstract methods in the parent class
Create abstract methods in the parent class for each of the
different methods in sub-classes.

http://www.cs.unc.edu/~stotts/COMP723-s15/refactor/chap1.html
39
Test-first development
 Testing is central to XP and XP has developed an approach where
the program is tested after every change has been made.
 XP testing features:
 Test-first development.
 Incremental test development from scenarios.
 User involvement in test development and validation.
 Automated test harnesses are used to run all component tests each
time that a new release is built.
 Writing tests before code clarifies the requirements to be implemented.
 Tests are written as programs rather than data so that they can be
executed automatically. The test includes a check that it has executed
correctly.
 Usually relies on a testing framework such as Junit.
 All previous and new tests are run automatically when new
functionality is added, thus checking that the new functionality has not
40
introduced errors.
41
Example of a “table reservation system” used in the
restaurant.
 Cancellation can be done by two types of user:
1. If a user is an admin
2. A user who has made the reservation.

 Based on the user types we need to test three scenarios:

• Cancellation request will be accepted if a user is an admin
• Cancellation request will be accepted if a user who made
the reservation wants to cancel
• Cancellation request will not be accepted for all other
users
42
 Step 1: Write the test case

public void CanBecancelledBy_UserIsAdmin_ReturnsTrue()

{
var reservation= new Reservation();
var result = reservation.CanBecancelledBy(new user {
IsAdmin = true });

Assert.IsTrue (result);
}

43
Problems with test-first development
 Programmers prefer programming to testing and
sometimes they take short cuts when writing tests. For
example, they may write incomplete tests that do not check
for all possible exceptions that may occur.
 Some tests can be very difficult to write incrementally. For
example, in a complex user interface, it is often difficult to
write unit tests for the code that implements the ‘display
logic’ and workflow between screens.
 It difficult to judge the completeness of a set of tests.
Although you may have a lot of system tests, your test set
may not provide complete coverage.

44
Pair programming
 Pair programming involves programmers working in pairs,
developing code together.
 This helps develop common ownership of code and spreads
knowledge across the team.
 It serves as an informal review process as each line of code
is looked at by more than 1 person.
 It encourages refactoring as the whole team can benefit
from improving the system code.

45
Pair programming
 In pair programming, programmers sit together at the same
computer to develop the software.
 Pairs are created dynamically so that all team members
work with each other during the development process.
 The sharing of knowledge that happens during pair
programming is very important as it reduces the overall
risks to a project when team members leave.
 Pair programming is not necessarily inefficient and there is
some evidence that suggests that a pair working together is
more efficient than 2 programmers working separately.

46
Scrum
 Scrum is an agile method that focuses on managing
iterative development rather than specific agile
practices.
 Originally proposed by Schwaber and Beedle.
 There are three phases in Scrum.
 The initial phase is an outline planning phase where you
establish the general objectives for the project and design the
software architecture.
 This is followed by a series of sprint cycles, where each cycle
develops an increment of the system.
 The project closure phase wraps up the project, completes
required documentation such as system help frames and user
manuals and assesses the lessons learned from the project.
47
Scrum terminology
Scrum term Definition

Development team A self-organizing group of software developers, which should be no more

than 7 people. They are responsible for developing the software and other
essential project documents.
Potentially The software increment that is delivered from a sprint. The idea is that this
shippable product should be ‘potentially shippable’ which means that it is in a finished state
increment and no further work, such as testing, is needed to incorporate it into the
final product. In practice, this is not always achievable.

Product backlog This is a list of ‘to do’ items which the Scrum team must tackle. They may
be feature definitions for the software, software requirements, user stories
or descriptions of supplementary tasks that are needed, such as
architecture definition or user documentation.

Product owner An individual (or possibly a small group) whose job is to identify product
features or requirements, prioritize these for development and
continuously review the product backlog to ensure that the project
continues to meet critical business needs. The Product Owner can be a
customer but might also be a product manager in a software company or
other stakeholder representative.
48
Scrum terminology
Scrum term Definition
Scrum A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting that includes the whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she is
responsible for interfacing with the rest of the company and for ensuring
that the Scrum team is not diverted by outside interference. The Scrum
developers are adamant that the ScrumMaster should not be thought of
as a project manager. Others, however, may not always find it easy to
see the difference.

Sprint A development iteration. Sprints are usually 2-4 weeks long.

Velocity An estimate of how much product backlog effort that a team can cover
in a single sprint. Understanding a team’s velocity helps them estimate
what can be covered in a sprint and provides a basis for measuring
improving performance.

49
Scrum Sprint Cycle

50
51
Scrum Sprint Cycle
 Sprints are fixed length, normally 2–4 weeks.
 The starting point for planning is the product backlog, which is the list
of work to be done on the project.
 The selection phase involves all of the project team who work with the
customer to select the features and functionality from the product
backlog to be developed during the sprint.
 Once these are agreed, the team organize themselves to develop the
software.
 During this stage the team is isolated from the customer and the
organization, with all communications channelled through the so-
called ‘Scrum master’.
 The role of the Scrum master is to protect the development team from
external distractions.
 At the end of the sprint, the work done is reviewed and presented to
stakeholders. The next sprint cycle then begins.
52
Advantages of Scrum
 The product is broken down into a set of manageable and
understandable chunks.
 Unstable requirements do not hold up progress.
 The whole team have visibility of everything and
consequently team communication is improved.
 Customers see on-time delivery of increments and gain
feedback on how the product works.
 Trust between customers and developers is established and
a positive culture is created in which everyone expects the
project to succeed.

53
Practical problems with agile methods
 The informality of agile development is incompatible with
the legal approach to contract definition that is commonly
used in large companies.
 Agile methods are most appropriate for new software
development rather than software maintenance. Yet the
majority of software costs in large companies come from
maintaining their existing software systems.
 Agile methods are designed for small co-located teams yet
much software development now involves worldwide
distributed teams.

54
Agile methods and software maintenance
 Most organizations spend more on maintaining
existing software than they do on new software
development. So, if agile methods are to be successful,
they have to support maintenance as well as original
development.
 Two key issues:
 Are systems that are developed using an agile approach
maintainable, given the emphasis in the development
process of minimizing formal documentation?
 Can agile methods be used effectively for evolving a
system in response to customer change requests?
 Problems may arise if original development team
cannot be maintained. 55
Agile maintenance
 Key problems are:
 Lack of product documentation
 Keeping customers involved in the development process
 Maintaining the continuity of the development team
 Agile development relies on the development team
knowing and understanding what has to be done.
 For long-lifetime systems, this is a real problem as the
original developers will not always work on the system.

56
Dynamic System Development Method
 The Dynamic Systems Development technique (DSDM) is an
associate degree agile code development approach that provides a
framework for building and maintaining systems.
 The DSDM philosophy is borrowed from a modified version of the
sociologist principle—80% of An application is often delivered in
twenty percent of the time it’d desire deliver the entire (100 percent)
application.
 DSDM is a Rapid Application Development (RAD) approach to
software development and provides an agile project delivery
framework.
 The important aspect of DSDM is that the users are required to be
involved actively, and the teams are given the power to make decisions.
 Frequent delivery of product becomes the active focus with DSDM.

57
DSDM Life Cycle
 DSDM life cycle that defines 3 different unvarying cycles, preceded by 2
further life cycle activities:
 Feasibility Study: It establishes the essential business necessities and
constraints related to the applying to be designed then assesses
whether or not the application could be a viable candidate for the
DSDM method.
 Business Study: It establishes the use and knowledge necessities that
may permit the applying to supply business value; additionally, it is the
essential application design and identifies the maintainability
necessities for the applying.
 Functional Model Iteration: It produces a collection of progressive
prototypes that demonstrate practicality for the client. The intent
throughout this unvarying cycle is to collect further necessities by
eliciting feedback from users as they exercise the paradigm.

58
DSDM Life Cycle
 Design and Build Iteration: It revisits prototypes designed
throughout useful model iteration to make sure that everyone has been
designed during a manner that may alter it to supply operational
business price for finish users. In some cases, useful model iteration
and style and build iteration occur at the same time.
 Implementation: It places the newest code increment (an
“operationalized” prototype) into the operational surroundings. It
ought to be noted that:
(a) the increment might not 100% complete or,
(b) changes are also requested because the increment is placed into place.
 In either case, DSDM development work continues by returning to the
useful model iteration activity.

59
60
Thank You

61