IoT Domain Analyst

(BECE352E)
Module-1
Data Models

Dr. Biswajit Dwivedy

School of Electronics Engineering

VIT University, Vellore, India
Software life cycle
The term software life cycle has been defined to imply the different stages (or phases)
over which a software evolves from the initial customer request for it, to a fully
developed software, and finally to a stage where it is no longer useful to any user,
and is discarded.
This stage where the customer feels a need for the software and forms rough ideas
about the required features is known as the inception stage.
Starting with the inception stage, a software evolves through a series of identifiable
stages (also called phases) on account of the development activities carried out by
the developers, until it is fully developed and is released to the customers.
Once installed and made available for use, the users start to use the software. This
signals the start of the operation (also called maintenance) phase. As the users use
the software, not only do they request for fixing any failures that they might
encounter, but they also continually suggest several improvements and modifications
to the software.

02-02-2024 2
*The life cycle of a software represents the series of identifiable stages
through which it evolves during its life time.

A software development life cycle (SDLC) model (also called software life cycle
model and software development process model) describes the different activities
that need to be carried out for the software to evolve in its life cycle.

*software development life cycle (SDLC)/ software development process are used interchangeably.

An SDLC is represented graphically by drawing various stages of the

life cycle and showing on it the transitions among the stages. This
graphical model is usually accompanied by a textual description of
various activities that need to be carried out during a phase before that
phase can be considered to be complete.

02-02-2024 3
 SDLC - Overview
➢ Software Development Life Cycle (SDLC) is a process used by the
software industry to design, develop and test high quality softwares.
➢ The SDLC aims to produce a high-quality software that meets or
exceeds customer expectations, reaches completion within times and
cost estimates.
▪ It is also called as Software Development Process.
▪ SDLC is a framework defining tasks performed at each step in the
software development process.
▪ ISO/IEC 12207 is an international standard for software life-cycle
processes.
▪ It aims to be the standard that defines all the tasks required for
developing and maintaining software

02-02-2024 4
What is SDLC?
➢SDLC is a process followed for a software project, within a software
organization.
➢It consists of a detailed plan describing how to develop, maintain,
replace and alter or enhance specific software.
➢The life cycle defines a methodology for improving the quality of
software and the overall development process.

02-02-2024 5
The following figure is a graphical representation of the various stages
of a typical SDLC.

Planni
ng

Deploy Definin
ment g

SDLC
Designi
Testing
ng

Buildin
g
02-02-2024 6
Classical Waterfall Model
✓ Classical waterfall model is intuitively the most obvious way to develop
software. It is simple but idealistic.
✓ In fact, it is hard to put this model into use in any non-trivial software
development project, since developers do commit many mistakes during
various development activities many of which are noticed only during a later
phase.
✓ This requires to revisit the work of a previous phase to correct the mistakes,
but the classical waterfall model has no provision to go back to modify the
artifacts produced during an earlier phase.
✓ One might wonder if this model is hard to use in practical development
projects, then why study it at all? The reason is that all other life cycle models
can be thought of as being extensions of the classical waterfall model.
Therefore, it makes sense to first understand the classical waterfall model, in
order to be able to develop a proper understanding of other life cycle models.
02-02-2024 7
02-02-2024 8
On the average, about 60 per cent of the
total effort put in by the development
team in the entire life cycle is spent on the
maintenance activities.

However, among the development phases,

the integration and system testing phase
requires the maximum effort in a typical
development project.

FIGURE 2.2 Relative effort distribution among

different phases of a typical product.
02-02-2024 9
Feasibility study
The main focus of the feasibility study stage is to determine whether it would be financially and
technically feasible to develop the software.
✓ Development of an overall understanding of the problem: It is necessary to first develop an
overall understanding of what the customer requires to be developed. For this, only the important
requirements of the customer need to be understood and the details of various requirements such as
the screen layouts required in the graphical user interface (GUI), specific formulas or algorithms
required for producing the required results, and the databases schema to be used are ignored.
✓ Formulation of various possible strategies for solving the problem: In this activity, various
possible high-level solution schemes to the problem are determined. For example, solution in a
client-server framework and a standalone application framework may be explored.
✓ Evaluation of the different solution strategies: The different identified solution schemes are
analysed to evaluate their benefits and shortcomings. Such evaluation often requires making
approximate estimates of the resources required, cost of development, and development time
required. Once the best solution is identified, all activities in the later phases are carried out as per
this solution.

02-02-2024 10
Requirements analysis and specification
The aim of the requirements analysis and specification phase is to understand the
exact requirements of the customer and to document them properly.
✓ Requirements gathering and analysis:
For this, first requirements are gathered from the customer and then the gathered
requirements are analysed. The goal of the requirements analysis activity is to weed
out the incompleteness and inconsistencies in these gathered requirements.
*Note that an inconsistent requirement is one in which some part of the requirement
contradicts some other part. On the other hand, an incomplete requirement is one in
which some parts of the actual requirements have been omitted.
Requirements specification:
✓ After the requirement gathering and analysis activities are complete, the identified
requirements are documented. This document is called a software requirements
specification (SRS) document. The SRS document is written using end-user
terminology. This makes the SRS document understandable to the customer.
✓ The SRS document normally serves as a contract between the development team and
the customer. Any future dispute between the customer and the developers can be
settled by examining the SRS document.
02-02-2024 11
Design
The goal of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some
programming language. In technical terms, during the design phase the software
architecture is derived from the SRS document.
Procedural design approach:
✓ This traditional design technique is based on data flow modelling. This is
followed by a structured design step where the results of structured analysis are
transformed into the software design.
✓ During structured analysis, the functional requirements specified in the SRS
document are decomposed into subfunctions and the data-flow among these
subfunctions is analysed and represented diagrammatically in the form of
DFDs (Data Flow Design).
✓ Structured design consists of two main activities—architectural design (also
called high-level design) and detailed design (also called Low-level design).
02-02-2024 12
 High-level design involves decomposing the system into modules, and
representing the interfaces and the invocation relationships among the
modules. A high-level software design is sometimes referred to as the
software architecture.
During the detailed design activity, internals of the individual modules
such as the data structures and algorithms of the modules are designed
and documented.

Object-oriented design approach:

✓ In this technique, various objects that occur in the problem domain
and the solution domain are first identified and the different
relationships that exist among these objects are identified.
✓ The object structure is further refined to obtain the detailed
design.

02-02-2024 13
 Coding and unit testing
✓ The purpose of the coding and unit testing phase is to translate a software
design into source code and to ensure that individually each function is
working correctly.
✓ The coding phase is also sometimes called the implementation phase, since the
design is implemented into a workable solution in this phase.
✓ Each component of the design is implemented as a program module.
✓ The end-product of this phase is a set of program modules that have been
individually unit tested.
✓ The specific activities carried out during unit testing include designing test
cases, testing, debugging to fix problems, and management of test cases.

02-02-2024 14
 Integration and system testing
Integration of different modules is undertaken soon after they have
been coded and unit tested. During the integration and system testing
phase, the different modules are integrated in a planned manner.

System testing usually consists of three different kinds of testing activities:

■a-testing: a testing is the system testing performed by the development
team.
■b-testing: This is the system testing performed by a friendly set of
customers.
■Acceptance testing: After the software has been delivered, the customer
performs system testing to determine whether to accept the delivered
software or to reject it.

02-02-2024 15
Maintenance
Many studies carried out in the past confirm this and indicate that the ratio of relative effort
of developing a typical software product and the total effort spent on its maintenance is
roughly 40:60. Maintenance is required in the following three types of situations:
■Corrective maintenance: This type of maintenance is carried out to correct
errors that were not discovered during the product development phase.
■Perfective maintenance: This type of maintenance is carried out to improve
the performance of the system, or to enhance the functionalities of the system
based on customer’s requests.
■Adaptive maintenance: Adaptive maintenance is usually required for porting
the software to work in a new environment. For example, porting may be
required to get the software to work on a new computer platform or with a
new operating system.

02-02-2024 16
Waterfall Model - Advantages
The advantages of waterfall development are that it allows for departmentalization
and control. A schedule can be set with deadlines for each stage of development and
a product can proceed through the development process model phases one by one.
Some of the major advantages of the Waterfall Model are as follows −
➢Simple and easy to understand and use
➢Easy to manage due to the rigidity of the model.
➢Phases are processed and completed one at a time.
➢Works well for smaller projects where requirements are very well understood.
➢Clearly defined stages.
➢Well understood milestones.
➢Easy to arrange tasks.
➢Process and results are well documented.

02-02-2024 17
Waterfall Model - Disadvantages
➢The disadvantage of waterfall development is that it does not allow
much reflection or revision.
➢Once an application is in the testing stage, it is very difficult to go
back and change something that was not well-documented or thought
upon in the concept stage.
➢No working software is produced until late during the life cycle.
➢High amounts of risk and uncertainty.
➢Not a good model for complex and object-oriented projects.

02-02-2024 18
Waterfall Model - Disadvantages
➢Poor model for long and ongoing projects.
➢Not suitable for the projects where requirements are at a moderate to
high risk of changing. So, risk and uncertainty is high with this
process model.
➢It is difficult to measure progress within stages.
➢Cannot accommodate changing requirements.

02-02-2024 19
Iterative Waterfall Model

Iterative waterfall model.

The main change brought about by the iterative waterfall model to the classical
waterfall model is in the form of providing feedback paths from every
phase to its preceding phases.
02-02-2024 20
 Iterative Waterfall Model
• Classical waterfall model is idealistic:
–Assumes that no defect is introduced during any
development activity.

–In practice:
• Defects do get introduced in almost every phase of the life cycle.
 Iterative Waterfall Model (CONT.)

• Defects usually get detected much later in the life cycle:

–For example, a design defect might go unnoticed till the
coding or testing phase.

–The later the phase in which the defect gets detected, the
more expensive is its removal.
 Iterative Waterfall Model (CONT.)

• Once a defect is detected:

–The phase in which it occurred needs to be reworked.
– Redo some of the work done during that and all
subsequent phases.

• Therefore need feedback paths in the classical

waterfall model.
 Phase Containment of Errors (Cont...)

• Errors should be detected:

• In the same phase in which they are introduced.
• For example:
• If a design problem is detected in the design phase itself,
• The problem can be taken care of much more easily
• Than say if it is identified at the end of the integration and system
testing phase.
 Phase Containment of Errors
• Reason: rework must be carried out not only to the design but
also to code and test phases.
• The principle of detecting errors as close to its point of
introduction as possible:
– is known as phase containment of errors.
• Iterative waterfall model is by far the most widely used model.
– Almost every other model is derived from the waterfall model.
RAD Model
26
 Rapid Application Development (RAD) Model

• Sometimes referred to as the rapid prototyping model.

• Major aims:
– Decrease the time taken and the cost incurred to develop
software systems.

– Facilitate accommodating change requests as early as possible:

• Before large investments have been made in development and testing.
 Important Underlying Principle

• A way to reduce development time and cost, and yet

have flexibility to incorporate changes:

• Make only short term plans and make heavy reuse of

existing code. 28
 Methodology
• Plans are made for one increment at a time.
• The time planned for each iteration is called a time box.

• Each iteration (increment):

• Enhances the implemented functionality of the application a
29

little.
 Methodology

• During each iteration,

• A quick-and-dirty prototype-style software for some
selected functionality is developed.
• The customer evaluates the prototype and gives his
feedback.

• The prototype is refined based on the customer feedback.

 How Does RAD Facilitate Faster Development?

• RAD achieves fast creation of working prototypes.

– Through use of specialized tools.
• These specialized tools usually support the following features:
– Visual style of development.
– Use of reusable components. 31

– Use of standard APIs (Application Program Interfaces).

 For which Applications is RAD Suitable?

•Customized product developed for one or two

customers only.

•Performance and reliability are not critical.

•The system can be split into several independent

32

modules.
 For Which Applications RAD is Unsuitable?

• Few plug-in components are available

• High performance or reliability required

• No precedence for similar products exists

• The system cannot be modularized.

 Prototyping versus RAD

In prototyping model:
• The developed prototype is primarily used to gain insights into
the solution
• Choose between alternatives
• Elicit customer feedback.
34

• The developed prototype:

• Usually thrown away.
 Prototyping versus RAD
• In contrast:
• In RAD the developed prototype evolves into
deliverable software.

• RAD leads to faster development compared to

traditional models:
• However, the quality and reliability would possibly be
poorer.
 RAD versus Iterative Waterfall Model

• In the iterative waterfall model,

– All product functionalities are developed together.
• In the RAD model on the other hand,
– Product functionalities are developed incrementally through heavy
code
and design reuse.
– Customer feedback is obtained on the developed prototype after
each iteration:
• Based on this the prototype is refined.
 RAD versus Iterative Waterfall Model

• The iterative waterfall model:

– Does not facilitate accommodating requirement change requests.
• Iterative waterfall model does have some
important advantages:
– Use of the iterative waterfall model leads to production of good
documentation.
– Also, the developed software usually has better quality and
reliability than that developed using RAD.
02-02-2024 38
 Spiral Model
• Proposed by Boehm in 1988.
• Each loop of the spiral represents a phase of the software
process:
– the innermost loop might be concerned with system feasibility,
– the next loop with system requirements definition,
– the next one with system design, and so on.
• There are no fixed phases in this model, the phases
shown in the figure are just examples.
 Spiral Model (CONT.)
• The team must decide:
– how to structure the project into phases.
• Start work using some generic model:
– add extra phases
• for specific projects or when problems are identified during a
project.
• Each loop in the spiral is split into four sectors (quadrants).
 Spiral Model

Identify &
Determine Resolve Risks
Objectives

Customer Develop Next

Evaluation of Level of Product
Prototype
 Objective Setting (First Quadrant)

• Identify objectives of the phase,

• Examine the risks associated with these objectives.
–Risk:
• Any adverse circumstance that might hamper
successful completion of a software project.

• Find alternate solutions possible.

 Risk Assessment and Reduction (Second Quadrant)

• For each identified project risk,

–a detailed analysis is carried out.
• Steps are taken to reduce the risk.
• For example, if there is a risk that requirements are
inappropriate:
–A prototype system may be developed.
 Spiral Model (CONT.)
• Development and Validation (Third quadrant):
– develop and validate the next level of the product.
• Review and Planning (Fourth quadrant):
– review the results achieved so far with the customer and plan
the next iteration around the spiral.
• With each iteration around the spiral:
– progressively more complete version of the software gets built.
• Subsumes all discussed models:
– a single loop spiral represents waterfall model. Spiral Model as
– uses an evolutionary approach -- a Meta Model
• iterations over the spiral are evolutionary levels.
– enables understanding and reacting to risks during each iteration
along the spiral.
– Uses:
• prototyping as a risk reduction mechanism
• retains the step-wise approach of the waterfall model.
Agile Models
46
02-02-2024 47
 What is Agile Software Development?

• Agile: Easily moved, light, nimble, active software

processes

• How agility achieved?

– Fitting the process to the project

– Avoidance of things that waste time

 Agile Model
• To overcome the shortcomings of the waterfall model of
development.
– Proposed in mid-1990s
• The agile model was primarily designed:
– To help projects to adapt to change requests
• In the agile model:
– The requirements are decomposed into many small incremental parts
that can be developed over one to four weeks each.
 Ideology: Agile Manifesto

• Individuals and interactions over

– process and tools
• Working Software over
– comprehensive documentation
• Customer collaboration over
– contract negotiation
• Responding to change over
– following a plan
 Agile Model: Principal Techniques
• User stories:
– Simpler than use cases.
• Metaphors:
– Based on user stories, developers propose a common vision of what is
required.
• Spike:
– Simple program to explore potential solutions.
• Refactor:
– Restructure code without affecting behavior, improve efficiency, structure, etc.
 Agile Model: Nitty Gritty
• At a time, only one increment is planned, developed,
deployed at the customer site.
– No long-term plans are made.
• An iteration may not add significant functionality,
– But still a new release is invariably made at the end of each
iteration

– Delivered to the customer for regular use.

 Methodology
• Face-to-face communication favoured over
written documents.
• To facilitate face-to-face communication,
– Development team to share a single office space.
– Team size is deliberately kept small (5-9 people)
– This makes the agile model most suited to the development of
small projects.
 F a c e -to -fa c e
at w h i t e b o a r d
Effectiveness of F a c e -to -fa c e
co n v e rs a tion
Communication Modes V i d e o
c o n v e rs a tion
Communication Effectiveness

M o d e ling
P h o n e
O p t i o n s
co n v e rs a tion

V i d e ota p e
E m a i l
c o n v e r s a t i o n

A u d i o t a p e
D o c u m e nta tion
O p t i o n s
P a p e r
54

C o l d H ot
R i c h n e s s of C o m m u n i c a t i o n C h a n n e l
C o p y r i g h t 2 0 0 2 - 2 0 0 5 Scott W . A m b l e r
Original D i a g r a m C o p y r i g h t 2 0 0 2 Alistair C o c k b u r n
 Agile Model: Principles

• The primary measure of progress:

– Incremental release of working software
• Important principles behind agile model:
– Frequent delivery of versions --- once every few weeks.
– Requirements change requests are easily accommodated.
– Close cooperation between customers and developers.
– Face-to-face communication among team members.
 Agile Documentation
• Travel light:
– You need far less documentation than you think.
• Agile documents:
– Are concise
– Describe information that is less likely to change
– Describe “good things to know”
– Are sufficiently accurate, consistent, and detailed
• Valid reasons to document:
– Project stakeholders require it
– To define a contract model
– To support communication with an external group
– To think something through
151
 Agile Software Requirements Management
H ig h { E a c h i t e r a t i o n i m p l e m e n t t h e h i g h e s t -
P r io r ity p r i o r i ty r e q u i r e m e n t s

E a c h n e w r e q u i r e m e n t is
p r i o r i t i z e d a n d a d d e d t o
t h e s t a c k

R e q u i r e m e n t s m a y b e
r e p r i o r i t i z e d a t a n y t i m e

R e q u i r e m e n t s m a y b e
r e m o v e d a t a n y t i m e

L o w
P r io r ity
R e q u ir e m e n ts
 Adoption Detractors

• Sketchy definitions, make it possible to have

– Inconsistent and diverse definitions
• High quality people skills required
• Short iterations inhibit long-term perspective
• Higher risks due to feature creep:
– Harder to manage feature creep and customer expectations
– Difficult to quantify cost, time, quality.
 Agile Model Shortcomings

• Derives agility through developing tacit knowledge

within the team, rather than any formal document:
– Can be misinterpreted…
– External review difficult to get…
– When project is complete, and team disperses,
maintenance becomes difficult…
 Agile Model versus Iterative Waterfall Model

• The waterfall model steps through in a planned sequence:

– Requirements-capture, analysis, design, coding, and testing .
• Progress is measured in terms of delivered artefacts:
– Requirement specifications, design documents, test plans, code
reviews, etc.
• In contrast agile model sequences:
– Delivery of working versions of a product in several increments.
 Agile Model versus Iterative Waterfall Model

• As regards to similarity:
– We can say that Agile teams use thewaterfall model on
a small scale.
 Agile versus RAD Model

• Agile model does not recommend developing

prototypes:
– Systematic development of each incremental feature
is emphasized.
• In contrast: 62

– RAD is based on designing quick-and-dirty prototypes,

which are then refined into production quality code.
02-02-2024 63