Dr.

Sushruta Mishra
Dr.Sushruta Mishra
When it comes to developing a new software system, one of the first decisions to be made is whether
to build the system in-house or buy a pre-existing system.

With the build option, the organization constructs the IT capability needed from scratch. The
organization acquires an already-existing IT capability from a software vendor or other external
sources with the buy option.

Dr.Sushruta Mishra
The development of software in-house usually means that:
● The developers and the users belong to the same organization;
● The application will slot into a portfolio of existing computer-based systems;
● The methodologies and technologies are largely dictated by organizational standards and policies,
including the existing enterprise architecture.

They would need to review the methodologies and technologies to be used for
each individual project. This decision-making process has been called technical
planning by some, although here we use the term project analysis.
 Pros and cons of
Building Software
in-house Solution

v Building software in-house generally requires less upfront investment.

v Custom-built software also offers greater flexibility than packaged solutions.

v Building custom software in-house also gives you more control over security and
compliance.

v On the downside, building software in-house generally takes longer and requires
more internal resources than purchasing an off-the-shelf product. You will have to
arrange time and money to design, develop, test, and deploy your software. And you
will need to staff your own in-house team, which can be costly and time-consuming.

Dr.Sushruta Mishra
 Pros and cons of
Buying (off-the-shelf)
Software Solution

v Purchasing an off-the-shelf software package generally requires less time and money
than building software in-house.

v The off-the-shelf custom solution also offers more features than custom-built
software.

v it’s usually easier to use than custom-built software. Packaged software is typically
designed with a user-friendly interface that is easy to navigate.

v One disadvantage is that you may not be able to get the exact software that you
want or need. Packaged software is designed for a wide range of users, so it may not
include all the features that you require. Another disadvantage is that custom
software may not be as secure as software that you build in-house.

Dr.Sushruta Mishra
q When you have a number of v Look at risks and uncertainties e.g.
interesting and challenging projects
are requirement well understood?
to choose from, finding a project
that is the right fit for your team’s are technologies to be used well understood?
skill set, level of competence, and
v Look at the type of application being built e.g.
has the best chance of success is
the first step in effective project information system? embedded system?
management.
criticality? differences between target and
q Project Selection Methods offer a development environments?
set of time-tested techniques
v Clients’ own requirements
based on sound logical reasoning
to choose a project and filter out need to use a particular method
undesirable projects with a very
low likelihood of success.

Dr.Sushruta Mishra
Analysis of critical project characteristics:::::

Data-oriented or Process-oriented system to be implemented? Data-oriented systems generally mean information systems
that will have a substantial database. Process-oriented systems refer to embedded control systems.

Will the software be a general tool or application specific? An example of a general tool would be a spreadsheet or a word
processing package. An application-specific package could be, for example, an airline seat reservation system.

Are there specific tools available for implementing the particular type of application? For example:–
------ does it involve concurrent processing?
------ will the system to be created be knowledge-based?
------ will the system to be produced make heavy use of computer graphics?

Is the system to be created safety critical? For instance, could a malfunction in the system endanger human life? If so,
among other things, testing would become very important.

Is the system designed to carry out predefined services or to be engaging and entertaining? With software designed for
entertainment, design and evaluation will need to be carried out differently from more conventional software products.

Hardware/software environment in which system will operate? The environment in which the final software will operate
could be different from that in which it is to be developed.
A payroll system: Data-oriented, application specific, generic tools, safety critical, predefined services, hardware/software
environment identical.

A Bottling plant control: Process-oriented, application specific, specific features like (high bph, automatic, scalability,
durable etc), safety critical, predefined services, hardware/software environment identical.

A Water supplier system: Both Data-oriented & Process-oriented, application speciific, specific features like sustainability,
scalability, fault tolerance etc), safety critical, predefined services, hardware/software environment identical.

A project management software: Data-oriented, generic, specific features like Time tracking, Reporting, budgeting, Billing &
quotes), safety critical voluntary, engaging to various needs, diverse hardware/software environment.
Identify high-level project risks Product uncertainty: How well are the requirements understood? The
users themselves could be uncertain about what a proposed
information system is to do. The government, say, might introduce a
U nt il we h ave a n a l ys e d t h e new form of taxation but its detailed operation might not be known
users’ requirements in detail we until case law has been built up.
cannot estimate the
effortneeded to build a system Process uncertainty: The project under consideration might be the
to meet those requirements. first where an organization is using an approach like extreme
programming (XP) or a new application-building tool. Any change in
The greater the uncertainties at the way that the systems are developed introduces uncertainty.
the beginning, the greater the
risk that the project will be Resource uncertainty: The main area of uncertainty here is likely to be
unsuccessful. the availability of staff of the right ability and experience. The larger
the number of resources needed or the longer the duration of the
Uncertainty can be associated project, the more inherently
with the products, processes, or risky it will be.
resources of a project.

Some factors such as continually changing requirements

increase uncertainty, while others for instance, software
size also increase complexity. Different strategies are
needed to deal with the two distinct types of risks.
 Select general life-cycle approach

q Control systems: A real-time system will need to be implemented using an appropriate

methodology.

q Availability of users: Where the software is for the general market rather than application and
user specific, then a methodology which assumes that identifiable users exist who can be
quizzed about their needs would have to be thought about with caution.

q Specialized techniques: For example, expert system shells and logic-based programming
languages have been invented to expedite the development of knowledge-based systems.

q Hardware environment: The environment in which the system is to operate could put
constraints on the way it is to be implemented.

q Safety-critical systems: Where safety and reliability are essential, this might justify the
additional expense of a formal specification.

q Imprecise requirements: Uncertainties or a novel hardware/software platform mean that a

prototyping approach should be considered.
Software Processes and Process Models

v A software product development process usually starts when a request for the product is received from the customer.
For a generic product, the marketing department of the company is usually considered as the customer. This
expression of need for the product is called product inception.

v From the inception stage, a product undergoes a series of transformations through a few identifiable stages until it is
fully developed and released to the customer. After release, the product is used by the customer and during this time
the product needs to be maintained for fixing bugs and enhancing functionalities. This stage is called the
maintenance stage.

v When the product is no longer useful to the customer, it is retired. This set of identifiable stages through which a
product transits from inception to retirement form the life cycle of the product. The software life cycle is also
commonly referred to as Software Development Life Cycle (SDLC) and software process.

v A life cycle model (also called a process model) of a software product is a graphical or textual representation of its
life cycle. Additionally, a process model may describe the details of various types of activities carried out during the
different phases and the documents produced.
Selection Process Parameters for a Software Process Model:::::::::
Ø Requirements characteristics
Reliability of Requirements
Types & Number of require
Can the requirements be defined at an early stage
Ø Development team
Team size & Environment
Experience of developers on similar type of projects
Domain knowledge of developers
Availability of training
Ø User involvement in the project
Expertise of user in project
Involvement of user in all phases of the project
Experience of user in similar project in the past
Ø Project type and associated risk
Stability of funds
Tightness of project schedule
Availability of resources
Type & Size of project
Expected duration for the completion of project
Complexity of the project
Associated risks innvolved
Dr.Sushruta Mishra
Choice of Process Models

§ Waterfall’ also known as ‘one-shot’, ‘once-

through’

§ Incremental delivery

§ Evolutionary development

§ Also use of ‘agile methods’ e.g. extreme

programming

Dr.Sushruta Mishra
NEED FOR A SOFTWARE LIFE CYCLE MODEL

v Without using of a particular life cycle model the development of a software product would not be
in a systematic and disciplined manner.

v When a software product is being developed by a team there must be a clear understanding among
team members about when and what to do. Otherwise it would lead to chaos and project failure.

v Suppose a software development problem is divided into several parts and the parts are assigned to
the team members. From then on, suppose the team members are allowed the freedom to develop
the parts assigned to them in whatever way they like. It is possible that one member might start
writing the code for his part, another might decide to prepare the test documents first, and some
other engineer might begin with the design phase of the parts assigned to him.

v So without software life cycle model the entry and exit criteria for a phase cannot be recognized.
Without software life cycle models it becomes difficult for software project managers to monitor
the progress of the project.
Commonly used life cycle models are as follows:

Ø Classical Waterfall Model

Ø Iterative Waterfall Model

Ø Prototyping Model

Ø Evolutionary Model

Ø Spiral Model
Classical waterfall model
Ø The classical waterfall model is intuitively the most
obvious way to develop software. Though the classical
waterfall model is elegant and intuitively obvious, it is
not a practical model in the sense that it cannot be
used in actual software development projects.

Ø Thus, this model can be considered to be a theoretical

way of developing software. But all other life cycle
models are essentially derived from the classical
waterfall model.

Shortcoming::::::
q The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the
engineers during any of the life cycle phases. However, in practical development environments, the engineers do commit
a large number of errors in almost every phase of the life cycle.

q For example, a design defect might go unnoticed till we reach the coding or testing phase. Once a defect is detected, the
engineers need to go back to the phase where the defect had occurred and redo some of the work done during that
phase and the subsequent phases to correct the defect and its effect on the later phases.
Iterative Waterfall Model Ø Here, we provide feedback paths for error correction as
& when detected later in a phase. Though errors are
inevitable, but it is desirable to detect them in the
same phase in which they occur. If so, this can reduce
the effort to correct the bug.

Ø The advantage of this model is that there is a working

m o d e l o f t h e sy s t e m a t a v e r y e a r l y s t a g e o f
development which makes it easier to find functional
or design flaws.

Shortcoming::::::

q The disadvantage with this SDLC model is that it is applicable only to large and bulky software development
projects. This is because it is hard to break a small software system into further small serviceable
increments/modules.
Prototype Model Ø A prototype is a toy implementation of the system.
A prototype usually exhibits limited functional
capabilities, low reliability, and inefficient
performance compared to the actual software.

Ø An important purpose is to illustrate the input data

formats, messages, reports, and the interactive
dialogues to the customer. Another reason for
developing a prototype is that it is impossible to
get the perfect product in the first attempt.

Ø A prototype of the actual product is preferred in

situations such as User requirements are not
complete and technical issues are not clear
Evolutionary Model Ø It is also called incremental model. At first, a simple working model is built.
Subsequently it undergoes functional improvements & we keep on adding new
functions till the desired system is built.

Applications:
Large projects where you can easily find modules for
incremental implementation. Often used when the customer
wants to start using the core features rather than waiting for
the full software. Also used in object oriented software
development because the system can be easily portioned into
units in terms of objects.

Advantages:
User gets a chance to experiment partially developed system
Reduce the error because the core modules get tested
thoroughly.

Disadvantages:
It is difficult to divide the problem into several versions that
would be accepta b le to t h e c u sto m er wh ic h ca n b e
incrementally implemented & delivered.
 Ø Each loop of the spiral represents a phase of the software process. For example, the innermost
Spiral Model loop might be concerned with feasibility study, the next loop with requirements specification, the
next one with design, and so on. Each phase in this model is split into four quadrants.

First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the
phase & Examine the risks associated with these objectives.

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk. Steps
are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.

Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the
identified risks.

Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next
The spiral model is suitable for development iteration around the spiral.
of technically challenging software products • Progressively more complete version of the software gets built with each
that are prone to several kinds of risks. iteration around the spiral
Agile Model Agile model emphasizes collaboration, flexibility, and rapid delivery
of small increments of functionality. It is well-suited for projects that
require rapid development or where requirements may change
frequently.

One of the key characteristics of Agile is the emphasis on

collaboration and frequent communication between team members,
as well as with the customer or end user. This helps to ensure that
the final product meets the needs of the user and is delivered in a
timely manner.

Shortcomings::::
v Lack of upfront planning
v Limited documentation
v Communication challenges
v Limited ability to handle large projects
Extreme Programming
Extreme Programming involves −
Agile development
Ø Writing unit tests before programming and keeping all of the
tests running at all times. The unit tests are automated and
eliminates defects early, thus reducing the costs.
Ø Starting with a simple design just enough to code the features at
hand and redesigning when required.
Ø Programming in pairs (called pair programming), with two
programmers at one screen, taking turns to use the keyboard.
While one of them is at the keyboard, the other constantly
reviews and provides inputs.
Ø Integrating and testing the whole system several times a day.
Ø Putting a minimal working system into the production quickly
and upgrading it whenever required.
Ø Keeping the customer involved all the time and obtaining
constant feedback.
Dr.Sushruta Mishra
Why is it called “Extreme?”

q Extreme Programming takes the effective principles and practices to extreme levels.

q Code reviews are effective as the code is reviewed all the time.

q Testing is effective as there is continuous regression and testing.

q Design is effective as everybody needs to do refactoring daily.

q Integration testing is important as integrate and test several times a day.

 Dynamic System Development Method (DSDM)

DSDM is an agile framework that follows an iterative

approach to system development, which, as the name
suggests, develops the system dynamically.

It uses incremental prototyping. This method is

particularly useful for the systems to be developed in
short time span and where the requirements cannot
be frozen at the start of the application building.

Whatever requirements are known at a time, design

for them is prepared and incorporated into system. In
DSDM, analysis, design and development phase can
overlap. Like at one time some people will be working
on some new requirements while some will be
developing something for the system.

In Dynamic System Development Method (DSDM),

requirements evolve with time.

Dr.Sushruta Mishra
o Feasibility Study: In this phase the problem is defined and the technical feasibility of the desired application is
verified. Apart from these routine tasks, it is also checked whether the application is suitable for Rapid Application
Development (RAD) approach or not.

o Business Study: In this phase the overall business study of the desired system is done. The business requirements
are specified at a high level and the information requirements out of the system are identified. Once this is done, the
basic architectural framework of the desired system is prepared.

o Functional Model Iteration: The main focus in this phase is on building the prototype iteratively and getting it
reviewed from the users to bring out the requirements of the desired system. The prototype is improved through
demonstration to the user, taking the feedback and incorporating the changes. This cycle is repeated until a part of
functional model is agreed upon.

o Design and Build Iteration: This phase stresses upon ensuring that the prototypes are satisfactorily and
properly engineered to suit their operational environment. The software components designed during the functional
modeling are further refined till they achieve a satisfactory standard. The product of this phase is a tested system ready
for implementation.

o Implementation: Implementation is the last and final development stage in this methodology. In this phase the
users are trained and the system is actually put into the operational environment.
Dr.Sushruta Mishra
DSDM Model Limitations:::::

• It is a relatively new model. It is not very common. So it is difficult to understand.

DSDM Model Advantages:::::

• Active user participation throughout the project and iterative nature of development improves quality of the product.
• DSDM ensures rapid deliveries.
• Both of the above factors result in reduced project costs
 IF uncertainty is high
THEN use Spiral approach

IF complexity is high but uncertainty is not

‘rules of thumb’ THEN use Incremental approach

about approach IF uncertainty and complexity both low

THEN use Waterfall approach
to be used IF schedule is tight
THEN use Agile approach

Dr.Sushruta Mishra
Dr.Sushruta Mishra
q Classical Waterfall Model: The Classical Waterfall q Evolutionary Model: The Evolutionary model is suitable for
model can be considered as the basic model and all large projects which can be decomposed into a set of modules for
other life cycle models are based on this model. It is an incremental development and delivery. This model is widely used
ideal model. However, the Classical Waterfall model in object-oriented development projects. This model is only used
cannot be used in practical project development, since if incremental delivery of the system is acceptable to the customer.
this model does not support any mechanism to correct
the errors that are committed during any of the phases
but detected at a later p h as e. Th is p rob lem is q Spiral Model: The Spiral model is considered as a meta-model
overcome by the Iterative Waterfall model through the as it includes all other life cycle models. Flexibility and risk
inclusion of feedback paths. handling are the main characteristics of this model. The spiral
model is suitable for the development of technically challenging
q Iterative Waterfall Model: The Iterative Waterfall and large software that is prone to various risks that are difficult
model is probably the most used software
to anticipate at the start of the project. But this model is more
development model. This model is simple to use and
complex than the other models.
understand. But this model is suitable only for well-
understood problems and is not suitable for the
development of very large projects and projects that
suffer from a large number of risks.
q Agile Model: The Agile model was designed to incorporate
change requests quickly. In this model, requirements are
q Prototyping Model: The Prototyping model is decomposed into small parts that can be incrementally developed.
suitable for projects, which either the customer But the main principle of the Agile model is to deliver an
requirements or the technical solutions are not well increment to the customer after each Time-box. The end date of
understood. This risks must be identified before the an iteration is fixed, it can’t be extended. This agility is achieved
project starts. This model is especially popular for the by removing unnecessary activities that waste time and effort.
development of the user interface part of the project.

Dr.Sushruta Mishra
Dr.Sushruta Mishra