Software Engg

SOFTWARE ENGINEERING
6th Semester CSE (R-19)

Lecture – 1 Prepared by Prof. Ranjeet Kumar Panigrahi Introduction
to Softwre Engineering
WHAT IS SOFTWARE ENGINEERING?
A popular definition of software engineering is: “A systematic collection of good program
development practices and techniques”.
An alternative definition of software engineering is: “An engineering approach to develop
software”.
Based on these two point of views, we can define software engineering as follows:
Software engineering discusses systematic and cost-effective techniques for software
development. These techniques help develop software using an engineering approach.
12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 2
SOFTWARE DEVELOPMENT PROJECTS
Programs versus Products

Size:-
Programs:- they are usually small in size. They are lines of code or maybe 100 to 2000 lines codes on
little more
Software Product: Very big inside. The lines of codes are in thousands To lakhs may be more, depends
on Software Product.


User:-
Programs:- Developer himself is sole user.
Software Product: Large or vast number of users.
Developer:-
Programs: Single developer or maybe 2 developer make a program.
Software Product: A proper and well trained team of developer indulge in development.


User interface:-
Programs: There is no or lacks proper user interface.
Software Products: There is proper and full well designed user interface.
Development:-
Programs:- Unplanned, not Systematic i.e, ad hoc development.
Software Product: A well Systematic, organized, planned approach is used in development.
Functionality:-
Programs: That provide Limited functionality and less features.
Software Products: It provides more functionality as they are big in size (lines of codes) more options
and features are provided.

PROGRAM PRODUCT
SIZE SMALL LARGE
DOCUMENTATION IMPROPER / LACKING PROPER
USER HIMSELF MANY
DEVELOPER SINGLE A TRAINED TEAM
USER INTERFACE ABSENT WELL DESIGNED
DEVELOPMENT AD-HOC PLANNED
FUNCTIONALITY LIMITED MORE OPTIONS & FEATURES

SOFTWARE RISKS
Risk and importance of risk management :
Risk is uncertain activities associated with future events which have a probability of
occurrence, but it may or may not occur and if occurs it brings loss to the project.
Risk identification and management are very important task during software project
development because success and failure of any software project depends on it.

SOFTWARE RISKS
Various Kinds of Risks in Software Development :

1)Schedule Risk : Schedule related risks refers to time related risks or project delivery related planning risks. The
wrong schedule affects the project development and delivery. These risks are mainly indicates to running behind
time as a result project development doesn’t progress timely and it directly impacts to delivery of project. Finally if
schedule risks are not managed properly it gives rise to project failure and at last it affect to organization/company
economy very badly.
Factors affecting scheduled risk

Time is not estimated perfectly Improper resource allocation
Tracking of resources like system, skill, staff etc Frequent project scope expansion
Failure in function identification and its’ completion

SOFTWARE RISKS

2)Budget Risk : Budget related risks refers to the monetary risks mainly it occurs due to budget overruns.
Always the financial aspect for the project should be managed as per decided but if financial aspect of
project mismanaged then budget concerns will arise by giving rise to budget risks. So proper finance
distribution and management are required for the success of project otherwise it may lead to project
failure.
Factors affecting Budget risk

Wrong/Improper budget estimation Unexpected Project Scope
expansion
Mismanagement in budget handling Cost overruns

12/20/2023
Improper tracking of Budget
DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 9
SOFTWARE RISKS

3) Operational Risks : Operational risk refers to the procedural risks means these are the risks which
happen in day-to-day operational activities during project development due to improper process
implementation or some external operational risks.
Factors affecting Operational risk

Insufficient resources Conflict between
tasks and employees
Improper management of tasks No proper planning about
project
Less number of skilled people Lack of communication
and cooperation
SOFTWARE RISKS

4)Technical Risks : Technical risks refers to the functional risk or performance risk which means this
technical risk mainly associated with functionality of product or performance part of the software
product.
Factors affecting Technical risk

Frequent changes in requirement
Less use of future technologies
Less number of skilled employee
High complexity in implementation
Improper integration of modules

SOFTWARE RISKS

5) Programmatic Risks : Programmatic risks refers to the external risk or other unavoidable risks. These
are the external risks which are unavoidable in nature. These risks come from outside and it is out of
control of programs.
Factors affecting Programmatic risk

Rapid development of market
Running out of fund / Limited fund for project development
Changes in Government rules/policy
Loss of contracts due to any reason

DEFINING SOFTWARE
Software is:
Instructions (computer programs) that when executed provide desired features, function, and
performance;
Data structures that enable the programs to adequately manipulate information, and descriptive
information in both hard copy and virtual forms that describes the operation and use of the programs.
Software, instructions that tell a computer what to do. Software comprises the entire set of programs,
procedures, and routines associated with the operation of a computer system.
The term was coined to differentiate these instructions from hardware i.e., the physical components of
a computer system.
A set of instructions that directs a computer’s hardware to perform a task is called a program, or
software program.
SOFTWARE APPLICATION DOMAINS
A collection of programs written to service other programs. Some system software (e.g., compilers,
editors, and file management utilities) processes complex but essential information structures.
Other systems applications (e.g., operating system components, drivers, networking software,
telecommunications processors) process largely indeterminate data
Application software: stand-alone programs that solve a specific business need. Applications in this
area process business or technical data in a way that facilitates business operations or
management/technical decision making.
Engineering/scientific software: a broad array of “number-crunching programs that range from
astronomy to volcanology, from automotive stress analysis to orbital dynamics, and from computer-aided
design to molecular biology, from genetic analysis to meteorology.
Embedded software: Resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself. Embedded software can perform limited
and cryptic functions (e.g., key pad control for a microwave oven) or provide significant function and
control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and
braking systems).
Product-line software: designed to provide a specific capability for use by many different customers.
Product-line software can focus on a limited and esoteric marketplace (e.g., inventory control products)
or address mass consumer.

Web/Mobile applications: this network-centric software category spans a wide array of applications
and encompasses both browser-based apps and software that resides on mobile devices.
Artificial intelligence software: makes use of non numerical algorithms to solve complex problems
that are not amenable to computation or straightforward analysis. Applications within this area include
robotics, expert systems, pattern recognition (image and voice), artificial neural networks, theorem
proving, and game playing.

HANDLING COMPLEXITY THROUGH ABSTRACTION AND DECOMPOSITION
Abstraction
Abstraction refers to construction of a simpler version of a problem by ignoring the

details. The principle of constructing an abstraction is popularly known as modeling (or
model construction ).
Abstraction is the simplification of a problem by focusing on only one aspect of the

problem while omitting all other aspects.

HANDLING COMPLEXITY THROUGH ABSTRACTION AND DECOMPOSITION
Decomposition:
Decomposition is another important principle that is available in the catalog of a software engineer to
handle problem complexity.
This principle is generously made use by several software engineering techniques to contain the
exponential growth of the perceived problem complexity.
The decomposition principle is popularly known as the divide and conquer principle.
The decomposition principle advocates decomposing the problem into many small independent parts.
The small parts are then taken up one by one and solved separately. The idea is that each small part
would be easy to grasp and understand and can be easily solved. The full problem is solved when all the
parts are solved.

WHY STUDY SOFTWARE ENGINEERING?
The following two are possibly the most important skill you could be acquiring after
completing a study of software engineering:
The skill to participate in development of large software. You can meaningfully participate in a team
effort to develop a large software only after learning the systematic techniques that are being used in
the industry.
You would learn how to effectively handle complexity in a software development problem. In
particular, you would learn how to apply the principles of abstraction and decomposition to handle
complexity during various stages in software development such as specification, design,
construction, and testing.
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) MODEL
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.
An SDLC graphically depicts the different phases through which a software evolves.
It is usually accompanied by a textual description of the different activities that need to
be carried out during each phase.

PROCESS VERSUS METHODOLOGY
Though the terms process and methodology are at time used interchangeably, there is a
subtle difference between the two.
First, the term process has a broader scope and addresses either all the activities taking place during
software development, or certain coarse grained activities such as design (e.g. design process), testing
(test process),etc.
Further, a software process not only identifies the specific activities that need to be carried out, but may
also prescribe certain methodology for carrying out each activity.
A methodology, on the other hand, prescribes a set of steps for carrying out a specific life cycle activity.
It may also include the rationale and philosophical assumptions behind the set of steps through which
the activity is accomplished.
PROCESS VERSUS METHODOLOGY
A software development process has a much broader scope as compared to a software

development methodology. A process usually describes all the activities starting from
the inception of a software to its maintenance and retirement stages, or at least a chunk
of activities in the life cycle. It also recommends specific methodologies for carrying
out each activity. A methodology, in contrast, describes the steps to carry out only a
single or at best a few individual activities.

Requirements Definition: done by customers

Analysis: analyze requirements to form an
initial software model
Design: Detailed definition of inputs/outputs
and processes including data structures,
software structure, etc.

Coding: Design translated into code.

Coding includes SQA activities such as
inspections, unit tests and integration tests
Many takeoffs from this: These tests done
by developers: individual (unit), group or
team (integration tests….)

System Tests: Goal: to discover errors /

correct errors to achieve an acceptable level of
quality. Carried out by developers prior to
delivery.
Sometimes ‘acceptance tests’ carried out by
customer or in conjunction with developer

Installation / Conversion:
After testing, system is installed and/or
replaces an existing system;
Requires software / data conversion
Important to not interrupt daily activities
during conversion process.
Install incrementally, run in parallel; turn
switch and live with it, etc.

Operations and Maintenance:

Hopefully done for years.
Maintenance:
Corrective
Adaptive
Perfective
Lots of variations to the classic SDLC
many in response to problems….
Notice the feedback loops?


PROCESS MODELS
WATERFALL MODEL AND ITS EXTENSIONS
ITERATIVE WATERFALL MODEL
PROTOTYPING MODEL
EVOLUTIONARY MODEL
SPIRAL MODEL
RAD MODEL
AGILE MODEL

WATERFALL MODEL
The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to understand
and use. In a waterfall model, each phase must be completed before the next phase
can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software
development.
The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins only
if the previous phase is complete. In this waterfall model, the phases do not overlap.
WATERFALL MODEL - DESIGN Waterfall approach was first SDLC

Model to be used widely in Software
Engineering to ensure success of the
project. In "The Waterfall" approach,
the whole process of software
development is divided into separate
phases. In this Waterfall model,
typically, the outcome of one phase
acts as the input for the next phase
sequentially.
Requirement Analysis:
Feasibility Study:
Development of an overall understanding of the problem
Formulation of the various possible strategies for solving the problem
Evaluation of the different solution strategies
Requirements specification: Documentation (Acts as a contract between the

customer and developer) – Popularly known as SRS(Software requirement specification)
document.

Design:
 Procedural design approach
 Object oriented design approach
CODING AND UNIT TESTING

 Designing test cases
 Debugging to fix problems
 Management of test cases
Integration and system testing:

 α testing: the system testing performed by the development team.
 β testing: the system testing performed by a friendly set of customers
 Acceptance testing

Mantainance
 Corrective maintenance: to correct errors that were not discovered during development
 Perfective maintenance: to improve the performance of the system.
 Adaptive maintenance : Portive the software to work in a new environment

WATERFALL MODEL PHASES
Every software developed is different and requires a suitable SDLC approach to be

followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are :
Requirements are very well documented, clear and fixed.
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.

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.
Development moves from concept, through design, implementation, testing,

installation, troubleshooting, and ends up at operation and maintenance. Each phase of
development proceeds in strict order.

WATERFALL MODEL ADVANTAGES
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. Each phase has specific deliverables and a review
process.
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
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.
The major disadvantages of the Waterfall Model are as follows :

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.
Poor model for long and ongoing projects.
WATERFALL MODEL DISADVANTAGES
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.
Adjusting scope during the life cycle can end a project.
Integration is done as a "big-bang”. at the very end, which doesn't allow identifying
any technological or business bottleneck or challenges early.

ITERATIVE WATERFALL MODEL
The main changes brought

about the iterative waterfall
model to the classical
waterfall model is in the form
of providing feedback paths
from every phase to its
preceding phases.

ITERATIVE WATERFALL MODEL
In the Iterative model, iterative process starts with a simple implementation of a
small set of the software requirements and iteratively enhances the evolving
versions until the complete system is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just
part of the software, which is then reviewed to identify further requirements. This
process is then repeated, producing a new version of the software at the end of each
iteration of the model.
ITERATIVE MODEL - DESIGN
Iterative process starts with a simple implementation of a subset of the software

requirements and iteratively enhances the evolving versions until the full system is
implemented.
At each iteration, design modifications are made and new functional capabilities are
added. The basic idea behind this method is to develop a system through repeated
cycles (iterative) and in smaller portions at a time (incremental)

The following illustration is a representation of the Iterative and Incremental model :

Iterative and Incremental development is a combination of both iterative design or iterative method
and incremental build model for development.
"During software development, more than one iteration of the software development cycle may be in
progress at the same time." This process may be described as an "evolutionary acquisition" or
"incremental build" approach.
In this incremental model, the whole requirement is divided into various builds. During each iteration,
the development module goes through the requirements, design, implementation and testing phases.
Each subsequent release of the module adds function to the previous release. The process continues till
the complete system is ready as per the requirement.

ITERATIVE MODEL - APPLICATION
Like other SDLC models, Iterative and incremental development has some specific
applications in the software industry. This model is most often used in the following
scenarios
Requirements of the complete system are clearly defined and understood.
Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.

ITERATIVE MODEL - APPLICATION
There is a time to the market constraint.

A new technology is being used and is being learnt by the development team while
working on the project.
Resources with needed skill sets are not available and are planned to be used on
contract basis for specific iterations.
There are some high-risk features and goals which may change in the future.

ITERATIVE MODEL - PROS AND CONS
The advantage of this model is that there is a working model of the system at a very
early stage of development, which makes it easier to find functional or design flaws.
Finding issues at an early stage of development enables to take corrective measures in a
limited budget.
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.

ITERATIVE MODEL - PROS

The advantages of the Iterative and Incremental SDLC Model are as follows −
 Some working functionality can be developed quickly and early in the life cycle.
 Results are obtained early and periodically.
 Parallel development can be planned.
 Progress can be measured.
 Less costly to change the scope/requirements.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
 Easier to manage risk - High risk part is done first.
 With every increment, operational product is delivered.

ITERATIVE MODEL - PROS
Issues, challenges and risks identified from each increment can be utilized/applied to
the next increment.
Risk analysis is better.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical projects.
During the life cycle, software is produced early which facilitates customer
evaluation and feedback.

ITERATIVE MODEL - CONS
The disadvantages of the Iterative and Incremental SDLC Model are as follows :
More resources may be required.
Although cost of change is lesser, but it is not very suitable for changing
requirements.
More management attention is required.
System architecture or design issues may arise because not all requirements are
gathered in the beginning of the entire life cycle.
Defining increments may require definition of the complete system
ITERATIVE MODEL - CONS
Not suitable for smaller projects.

Management complexity is more.
End of project may not be known which is a risk.
Highly skilled resources are required for risk analysis.
Projects progress is highly dependent upon the risk analysis phase.

PROTOTYPING MODEL
Prototyping is defined as the process of developing a working replication of a product or system that
has to be engineered.
The prototype model requires that before carrying out the development of actual software, a working
prototype of the system should be built.
A prototype is a toy implementation of the system. A prototype usually turns out to be a very crude
version of the actual system, possible exhibiting limited functional capabilities, low reliability, and
inefficient performance as compared to actual software.
In many instances, the client only has a general view of what is expected from the software product. In
such a scenario where there is an absence of detailed information regarding the input to the system, the
processing needs, and the output requirement, the prototyping model may be employed.

Steps of Prototype Model
Requirement Gathering and Analyst

Quick Decision
Build a Prototype
Assessment or User Evaluation
Prototype Refinement
Engineer Product

PROTOTYPE MODEL

Advantages of Prototyping Model
Reduce the risk of incorrect user requirement

Good where requirement are changing/uncommitted
Regular visible process aids management
Support early product marketing
Reduce Maintenance cost.
Errors can be detected much earlier as the system is made side by side.

Disadvantages of Prototyping Model
An unstable/badly implemented prototype often becomes the final product.

Require extensive customer collaboration
 Costs customer money
 Needs committed customer
 Difficult to finish if customer withdraw
 May be too customer specific, no broad market
Difficult to know how long the project will last.

Disadvantages of Prototyping Model
Easy to fall back into the code and fix without proper requirement analysis, design,
customer evaluation, and feedback.
Prototyping tools are expensive.
Special tools & techniques are required to build a prototype.
It is a time-consuming process.

Evolutionary Process Model
Evolutionary process model resembles the iterative enhancement model. The same
phases are defined for the waterfall model occurs here in a cyclical fashion.
This model differs from the iterative enhancement model in the sense that this does
not require a useful product at the end of each cycle. In evolutionary development,
requirements are implemented by category rather than by priority.
For example, in a simple database application, one cycle might implement the
graphical user Interface (GUI), another file manipulation, another queries and another
updates. All four cycles must complete before there is a working product available.

Evolutionary process model resembles the iterative enhancement model. The same phases are defined
for the waterfall model occurs here in a cyclical fashion.
This model differs from the iterative enhancement model in the sense that this does not require a useful
product at the end of each cycle. In evolutionary development, requirements are implemented by category
rather than by priority.
For example, in a simple database application, one cycle might implement the graphical user Interface
(GUI), another file manipulation, another queries and another updates. All four cycles must complete
before there is a working product available.
GUI allows the users to interact with the system, file manipulation allow the data to be saved and
retrieved, queries allow user to get out of the system, and updates allows users to put data into the system.

Rough Requirement Specification
Identify the core and other parts to be developed incrementally
Develop the core part using an iterative waterfall model
Collect customer feedback and modify requirements
Develop the next identified features using an Iterative Waterfall

model
Maintenance

Benefits of Evolutionary Process

Model
Use of EVO brings a significant reduction in risk for software projects.
EVO can reduce costs by providing a structured, disciplined avenue for
experimentation.
EVO allows the marketing department access to early deliveries, facilitating the
development of documentation and demonstration.

Benefits of Evolutionary Process

Model
Better fit the product to user needs and market requirements.
Manage project risk with the definition of early cycle content.
Uncover key issues early and focus attention appropriately.
Increase the opportunity to hit market windows.
Accelerate sales cycles with early customer exposure.
Increase management visibility of project progress.
Increase product team productivity and motivations.

Disadvantages Evolutionary Process Model

The main disadvantages of the successive versions model are as follows:
Feature division into incremental parts can be non-trivial: For many development
projects, especially for small-sized projects, it is difficult to divide the required features
into several parts that can be incrementally implemented and delivered.
 Further, even for larger problems, often the features are so intertwined and dependent
on each other that even an expert would need considerable effort to plan the incremental
deliveries.

Disadvantages Evolutionary Process Model

Ad hoc design: Since at a time design for only the current increment is done, the
design can become ad hoc without specific attention being paid to maintainability and
optimality. Obviously, for moderate sized problems and for those for which the customer
requirements are clear
The iterative waterfall model can yield a better solution.

Applicability of the evolutionary model

The evolutionary model is normally useful for very large products, where it is easier t
o find modules for incremental implementation. Often evolutionary model is used when
the customer prefers to receive the product in increments so that he can start using the
different features as and when they are delivered rather than waiting all the time for the
full product to be developed and delivered.

Another important category of projects for which the evolutionary model is suitable,
is projects using object oriented development.
Applicability of the evolutionary model

Evolutionary model is appropriate for object-oriented development project, since it is
easy to partition the software into stand alone units in terms of the classes. Also, classes
are more or less self contained units that can be developed independently

Spiral Model
The spiral model, initially proposed by Boehm, is an evolutionary software process
model that couples the iterative feature of prototyping with the controlled and
systematic aspects of the linear sequential model.
It implements the potential for rapid development of new versions of the software.
Using the spiral model, the software is developed in a series of incremental releases.
During the early iterations, the additional release may be a paper model or prototype.
During later iterations, more and more complete versions of the engineered system are
produced.


Spiral Model
Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the
various alternatives that are possible for achieving the targets, and the constraints that exists.
Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located on the risk
perception for the project.
Development and validation: The next phase is to develop strategies that resolve uncertainties and
risks. This process may include activities such as benchmarking, simulation, and prototyping.

Spiral Model
Planning: Finally, the next step is planned. The project is reviewed, and a choice made
whether to continue with a further period of the spiral. If it is determined to keep, plans
are drawn up for the next step of the project.
The development phase depends on the remaining risks. For example, if performance
or user-interface risks are treated more essential than the program development risks, the
next phase may be an evolutionary development that includes developing a more detailed
prototype for solving the risks.
Spiral Model
The risk-driven feature of the spiral model allows it to accommodate any mixture of a
specification-oriented, prototype-oriented, simulation-oriented, or another type of
approach. An essential element of the model is that each period of the spiral is completed
by a review that includes all the products developed during that cycle, including plans for
the next cycle. The spiral model works for development as well as enhancement projects.

When to use Spiral Model?
When to use Spiral Model?

When deliverance is required to be frequent.
When the project is large
When requirements are unclear and complex
When changes may require at any time
Large and high budget projects

Advantages and Disadvantages
Advantages:
High amount of risk analysis
Useful for large and mission-critical projects.
Disadvantages:
Can be a costly model to use.
Risk analysis needed highly particular expertise
Doesn't work well for smaller projects.

RAD (Rapid Application Development)

Model
RAD is a linear sequential software development process model that emphasizes a
concise development cycle using an element based construction approach. If the
requirements are well understood and described, and the project scope is a constraint, the
RAD process enables a development team to create a fully functional system within a
concise time period.


Model
RAD (Rapid Application Development) is a concept that products can be developed
faster and of higher quality through:
Gathering requirements using workshops or focus groups
Prototyping and early, reiterative user testing of designs
The re-use of software components
A rigidly paced schedule that refers design improvements to the next product version
Less formality in reviews and other team communication


Model


Model
The various phases of RAD are as follows:
1.Business Modeling: The information flow among business functions is defined by
answering questions like what data drives the business process, what data is
generated, who generates it, where does the information go, who process it and so on.
2. Data Modeling: The data collected from business modeling is refined into a set of
data objects (entities) that are needed to support the business. The attributes
(character of each entity) are identified, and the relation between these data objects
(entities) is defined.

Model
3. Process Modeling: The information object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or retrieving a data
object.
4. Application Generation: Automated tools are used to facilitate construction of the
software; even they use the 4th GL techniques.
5. Testing & Turnover: Many of the programming components have already been tested
since RAD emphasis reuse. This reduces the overall testing time. But the new part must
be tested, and all interfaces must be fully exercised.
When to use RAD Model?
When the system should need to create the project that modularizes in a short span
time (2-3 months).
When the requirements are well-known.
When the technical risk is limited.
When there's a necessity to make a system, which modularized in 2-3 months of
period.
Advantages of RAD Model
This model is flexible for change.
In this model, changes are adoptable.
Each phase in RAD brings highest priority functionality to the customer.
It reduced development time.
It increases the reusability of features.

Disadvantages of RAD Model
It required highly skilled designers.
All application is not compatible with RAD.
For smaller projects, we cannot use the RAD model.
On the high technical risk, it's not suitable.
Required user involvement.

Agile Model
Agile SDLC 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.

Agile Model
Each iteration typically lasts from about one to three weeks. Every iteration involves
cross functional teams working simultaneously on various areas like:
Planning
Requirements Analysis
Design
Coding
Unit Testing and
Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and important stakeholders.

What is Agile?
Agile model believes that every project needs to be handled differently and the existing
methods need to be tailored to best suit the project requirements.
 In Agile, the tasks are divided to time boxes (small time frames) to deliver specific
features for a release.
Iterative approach is taken and working software build is delivered after each iteration.
Each build is incremental in terms of features; the final build holds all the features
required by the customer.

Agile Model

Agile Model
The most popular Agile methods include Rational Unified Process (1994), Scrum
(1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development,
Feature Driven Development, and Dynamic Systems Development Method (DSDM)
(1995).
These are now collectively referred to as Agile Methodologies, after the Agile Manifesto
was published in 2001.

Agile Model
Individuals and interactions: In Agile development, self-organization and motivation are important,
as are interactions like co-location and pair programming.
Working software: Demo working software is considered the best means of communication with the
customers to understand their requirements, instead of just depending on documentation.
Customer collaboration: As the requirements cannot be gathered completely in the beginning of the
project due to various factors, continuous customer interaction is very important to get proper product
requirements.
Responding to change: Agile Development is focused on quick responses to change and continuous
development
Agile Model - Pros and Cons

Is a very realistic approach to software development.
Promotes teamwork and cross training.
Functionality can be developed rapidly and demonstrated.
Resource requirements are minimum.
Suitable for fixed or changing requirements
Delivers early partial working solutions.
Good model for environments that change steadily.
Minimal rules, documentation easily employed.
Enables concurrent development and delivery within an overall planned context.
Little or no planning required.
Easy to manage.
Gives flexibility to developers.
Disadvantages Cons
Not suitable for handling complex dependencies.
More risk of sustainability, maintainability and extensibility.
An overall plan, an agile leader and agile PM practice is a must without which it will not
work.
Strict delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines.
Depends heavily on customer interaction, so if customer is not clear, team can be driven
in the wrong direction.
There is a very high individual dependency, since there is minimum documentation
generated.
Transfer of technology to new team members may be quite challenging due to lack of
documentation.
Comparision (Agile Vs RAD.)

AGILE RAD
Emphasizes systematic development of each Designing quick and dirty prototypes and then
incremental feature refined into production of quality code
Logically breakdown the solutions into features that Focus on developing all the features of an
are incrementally developed and delivered application by first doing it badly and then
improving it over time
Demonstrate completed work to the customer Demonstrate to customers screen mock ups and
prototypes which may be based on table look ups
rather than actual parmeters.

PROJECT Planning
Project planning is undertaken and completed before any development activity starts.
Estimation: The following project attributes are estimated
Project size: What will be problem complexity in terms of the effort and time required to
develop the product?
Cost: How much is it going to cost to develop the project?
Duration: How long is it going to take to complete development?
Effort: How much effort would be required?
The effectiveness of the subsequent planning activities is based on the accuracy of these
estimations.
PROJECT Planning

SPMP
1. Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraints
2. Project Estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost, and Project Duration Estimates
3. Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation

SPMP
4. Project Resources
(a) People
(b) Hardware and Software
(c) Special Resources
5. Staff Organization
(a) Team Structure
(b) Management Reporting
6. Risk Management Plan
(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures
SPMP
7. Project Tracking and Control Plan
a) Metrics to be tracked
b) Tracking Plan
c) Control Plan
8. Miscellaneous Plans
(a) Process Tailoring
(b) Quality Assurance Plan
(c) Configuration Management Plan
Version 2 CSE IIT, Kharagpur
(d) Validation and Verification
(e) System Testing Plan
(f) Delivery, Installation, and Maintenance Plan
METRICS FOR PROJECT SIZE

ESTIMATION
Lines of code (LOC)
 LOC is a measure of coding activity alone
 LOC count depends on the choice of specific instruction
 LOC measure correlates poorly with the quality and efficiency
 LOC metric penalizes use of high level programming languages and code reuse
 LOC metric measures the lexical complexities of a program and does not address the
more important issues of logical and structural complexities
 It’s very difficult to accurately estimate LOC of the final program from problem
specification
FUNCTION POINT (FP)

METRICS
 The conceptual idea behind the function
point metric is that the size of a software
product is directly dependent on the number
of different functions or features it supports.
 Besides using the number of input and
output data values, function point metric
computes the size of a software product (in
units of functions points or FPs) using three
other characteristics of the product
FUNCTION POINT (FP)

METRICS
 Number of inputs: Each data item input by the user is counted. Data inputs should be
distinguished from user inquiries, where as a group of related inputs are considered as
a single input.
For example, while entering the data concerning an employee to an employee pay roll
software
 Number of outputs: The outputs considered refer to reports printed, screen outputs,
error messages produced, etc. While outputting the number of outputs the individual
data items within a report are not considered, but a set of related data items is counted
as one input.
 Number of inquiries: Number of inquiries is the number of distinct interactive queries
which can be made by the users. These inquiries are the user commands which require
specific action by the system.

FUNCTION POINT (FP)

METRICS
 Number of files: Each logical file is counted. A logical file means groups of logically related data. Thus,
logical files can be data structures or physical files.
 Number of interfaces: Here the interfaces considered are the interfaces used to exchange information
with other systems. Examples of such interfaces are data files on tapes, disks, communication links with
other systems etc.
UFP (Unadjusted Function Point) = (Number of inputs)*4 + (Number of outputs)*5 + (Number of

inquiries)*4 + (Number of files)*10 + (Number of interfaces)*10
Type Simple Average Complex
Input 3 4 6
Output 4 5 7
Enquiry 3 4 6
Number of files 7 10 15
Number of interfaces 5 7 10
What is Estimation ?
Estimation is attempt to determine how much money, effort, resources & time it will take to build a specific software
based system or project.
Estimation involves answering the following questions:
1. How much effort is required to complete each activity?
2. How much calendar time is needed to complete each activity?
3. What is the total cost of each activity?
Project cost estimation and project scheduling are normally carried out together.
The costs of development are primarily the costs of the effort involved, so the effort computation is used in both the cost
and the schedule estimate.
Do some cost estimation before detailed schedules are drawn up. These initial estimates may be used to establish a budget
for the project or to set a price for the software for a customer.
There are three parameters involved in computing the total cost of a software
development project:
 Hardware and software costs including maintenance
 Travel and training costs
 Effort costs (the costs of paying software engineers).
The following costs are all part of the total effort cost:
 Costs of providing heating and lighting office space
 Costs of support staff such as accountants, administrators, system managers,
cleaners and technicians.
 Costs of networking and communications.
 Costs of central facilities such as a library or recreational facilities
 Costs of Social Security and employee benefits such as pensions and health
insurance etc.

Factors affecting software pricing

Cost Estimation Process
Effort
Size
Table
Lines of Development
Code Estimation Time
Number of Use Process Number of
Case Personnel
Function Errors
Point

Software Cost
Estimation
Distribution of Effort
A development process typically
consists of the following stages:
• Requirements Analysis
• Design (High Level
+Detailed)
• Implementation & Coding
• Testing (Unit + Integration)

Software Cost
Estimation
Three main approaches to estimation:
 Empirical
 Heuristic
 Analytical
Empirical techniques: Empirical estimation techniques are based on making an

educated guess of the project parameters based on past experience.
Ex: Expert judgment is one of the most widely used estimation techniques.
Software Cost
Estimation
Heuristic techniques:
Heuristic estimation models can be divided into the following two classes:
 single variable model
 multi variable model.
o Single variable estimation models provide a means to estimate the desired characteristics
of a problem, using some previously estimated basic (independent) characteristic of the
software product such as its size.
Estimated Parameter = c1 * ed1
In the above expression, e is the characteristic of the software which has already been
estimated (independent variable). Estimated Parameter is the dependent parameter to be
estimated. The dependent parameter to be estimated could be effort, project duration, staff
size, etc. c1 and d1 are constants. The values of the constants c1 and d1 are usually
determined using data collected from past projects (historical data).
Software Cost
Estimation
A multivariable cost estimation model takes the following form:
Estimated Resource = c1*e1d1 + c2*e2d2 + ...
Where e1, e2, … are the basic (independent) characteristics of the software already
estimated, and c1, c2, d1, d2, … are constants. Multivariable estimation models are
expected to give more accurate estimates compared to the single variable models

Function points Analysis

Function Point Analysis (FPA) is a method or set of rules of Functional Size
Measurement. It assesses the functionality delivered to its users, based on the
user’s external view of the functional requirements. It measures the logical
view of an application not the physically implemented view or the internal
technical view.
The Function Point Analysis technique is used to analyse the functionality

delivered by software and Unadjusted Function Point (UFP) is the unit of
measurement.


Objectives of FPA:
• The objective of FPA is to measure functionality that the user requests and
receives.
• The objective of FPA is to measure software development and maintenance
independently of technology used for implementation.
• It should be simple enough to minimize the overhead of the measurement
process.
• It should be a consistent measure among various projects and organizations.


Types of FPA:
Transactional Functional Type –
(i) External Input (EI): EI processes data or control information that comes from
outside the application’s boundary. The EI is an elementary process.
(ii) External Output (EO): EO is an elementary process that generates data or control
information sent outside the application’s boundary.
(iii) External Inquiries (EQ): EQ is an elementary process made up of an input-output
combination that results in data retrieval.
Data Functional Type –
(i) Internal Logical File (ILF): A user identifiable group of logically related data or
control information maintained within the boundary of the application.
(ii) External Interface File (EIF): A group of user recognizable logically related data
allusion to the software but maintained within the boundary of another software.
COCOMO Model
Software development:
software development project can be classified into one of the following three categories
based on the development complexity:
 Organic
 Semidetached
 Embedded.
Organic: A development project can be considered of organic type, if the project deals with
developing a well understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar types of
projects.
COCOMO Model
Semidetached: A development project can be considered of semidetached type, if the

development consists of a mixture of experienced and inexperienced staff. Team members
may have limited experience on related systems but may be unfamiliar with some aspects of
the system being developed.
Embedded: A development project is considered to be of embedded type, if the software

being developed is strongly coupled to complex hardware, or if the stringent regulations on
the operational procedures exist.
COCOMO Model
COCOMO (Constructive Cost Estimation Model) was proposed by Boehm [1981].
According to Boehm, software cost estimation should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete COCOMO.
Basic COCOMO Model
The basic COCOMO model gives an approximate estimate of the project parameters. The
basic COCOMO estimation model is given by the following expressions:
Effort = a1 х (KLOC)a2 PM
Tdev = b1 x (Effort)b2 Months

COCOMO Model
Where
• KLOC is the estimated size of the software product expressed in Kilo
Lines of Code,
• a1, a2, b1, b2 are constants for each category of software products,
• Tdev is the estimated time to develop the software, expressed in months,
• Effort is the total effort required to develop the software product,
expressed in person months (PMs).
COCOMO Model
• The effort estimation is expressed in units

of person-months (PM).
• It should be carefully noted that an effort of 100 PM does not imply that 100 persons
should work for 1 month nor does it imply that 1 person should be employed for 100
months, but it denotes the area under the person-month curve
According to Boehm, every line of source text should be calculated as one LOC irrespective of the actual
number of instructions on that line. Thus, if a single instruction spans several lines (say n lines), it is
considered to be nLOC.
COCOMO Model
Estimation of development effort
For the three classes of software products, the formulas for estimating the effort based on
the code size are shown below:
Organic : Effort = 2.4(KLOC)1.05 PM
Semi-detached : Effort = 3.0(KLOC)1.12 PM
Embedded : Effort = 3.6(KLOC)1.20 PM
Estimation of development time
For the three classes of software products, the formulas for estimating the development time
based on the effort are given below:
Organic : Tdev = 2.5(Effort)0.38 Months
Semi-detached : Tdev = 2.5(Effort)0.35 Months
Embedded : Tdev = 2.5(Effort)0.32 Months
COCOMO Model
 From the effort estimation, the project cost can be obtained by multiplying the required
effort by the manpower cost per month. But, implicit in this project cost computation is
the assumption that the entire project cost is incurred on account of the manpower cost
alone.
 In addition to manpower cost, a project would incur costs due to hardware and software
required for the project and the company overheads for administration, office space, etc.
 It is important to note that the effort and the duration estimations obtained using the
COCOMO model are called as nominal effort estimate and nominal duration estimate.
COCOMO Model
Assume that the size of an organic type software product has been estimated to be 32,000
lines of source code. Assume that the average salary of software engineers be Rs. 15,000/-
per month. Determine the effort required to develop the software product and the nominal
development time.
From the basic COCOMO estimation formula for organic software:
Effort = 2.4 х (32)1.05 = 91 PM
Nominal development time = 2.5 х (91)0.38 = 14 months
Cost required to develop the product = 14 х 15,000 x 91 = 19134050
Intermediate COCOMO model

 In order to obtain an accurate estimation of the effort and project duration, the effect of
all relevant parameters must be taken into account.
 The intermediate COCOMO model recognizes this fact and refines the initial estimate
obtained using the basic COCOMO expressions by using a set of 15 cost drivers
(multipliers) based on various attributes of software development.
 For example, if modern programming practices are used, the initial estimates are scaled
downward by multiplication with a cost driver having a value less than 1. If there are
stringent reliability requirements on the software product, this initial estimate is scaled
upward.
Intermediate COCOMO model

In general, the cost drivers can be classified as being attributes of the following items:
 Product: The characteristics of the product that are considered include the inherent complexity of the
product, reliability requirements of the product, etc.
 Computer: Characteristics of the computer that are considered include the execution speed required,
storage space required etc.
 Personnel: The attributes of development personnel that are considered include the experience level of
personnel, programming capability, analysis capability, etc.
 Development Environment: Development environment attributes capture the development facilities
available to the developers. An important parameter that is considered is the sophistication of the
automation (CASE) tools used for software development.

Complete COCOMO model

A major shortcoming of both the basic and intermediate COCOMO models is that they
consider a software product as a single homogeneous entity. However, most large systems
are made up several smaller sub-systems with different characteristics.
(For example, some subsystems may be considered as organic type, some semidetached, and some
embedded and also with different reliability requirements)
The complete COCOMO model considers these differences in characteristics of the

subsystems and estimates the effort and development time as the sum of the estimates for
the individual subsystems. The cost of each subsystem is estimated separately. This
approach reduces the margin of error in the final estimate.
Complete COCOMO model (A Case Study)

A distributed Management Information System (MIS) product for an organization having
offices at several places across the country can have the following sub-components:
• Database part
• Graphical User Interface (GUI) part
• Communication part
Of these, the communication part can be considered as embedded software. The database
part could be semi-detached software, and the GUI part organic software. The costs for
these three components can be estimated separately, and summed up to give the overall cost
of the system.
Requirements Engineering
The process of establishing the services that the customer requires from a system and
the constraints under which it operates and is developed.
The requirements themselves are the descriptions of the system services and constraints
that are generated during the requirements engineering process.

What is a Requirement?
The software requirements are
description of features and
functionalities of the target system.
Requirements convey the
expectations of users from the software
product.
The requirements can be obvious or
hidden, known or unknown, expected
or unexpected from client’s point of
Requirements Analysis and specification

Requirements Analysis and specification phase mainly involves carrying out the following
two important activities:
 Requirements gathering
 Studying existing documentation
 Interview
 Task Analysis
 Form Analysis
 Requirement analysis: Anomaly, Inconsistency, Incompleteness

Functional Requirements
In software engineering, a functional requirement defines a system or its component.
It describes the functions a software must perform. A function is nothing but inputs, its behavior, and
outputs. It can be a calculation, data manipulation, business process, user interaction, or any other specific
functionality which defines what function a system is likely to perform.
Functional software requirements help you to capture the intended behavior of the system.
This behavior may be expressed as functions, services or tasks or which system is required to perform

Examples of functional requirements

Authentication of user whenever he/she logs into the system.
System shutdown in case of a cyber attack.
Verification email is sent to user whenever he/she registers for the first time on some software system.
Business Rules
Transaction corrections, adjustments and cancellations
Administrative functions
Authorization levels
Audit Tracking
External Interfaces
Certification Requirements
Reporting Requirements
Historical Data
Legal or Regulatory Requirements
Non-functional requirements
A non-functional requirement defines the quality attribute of a software system. They

represent a set of standards used to judge the specific operation of a system.
A non-functional requirement is essential to ensure the usability and effectiveness of the
entire software system. Failing to meet non-functional requirements can result in systems
that fail to satisfy user needs.
Non-functional Requirements allows you to impose constraints or restrictions on the
design of the system across the various agile backlogs.

Non-functional requirements examples
Emails should be sent with a latency of no greater than 12 hours from such an activity.
The processing of each request should be done within 10 seconds
The site should load in 3 seconds when the number of simultaneous users are > 10000
 Performance – for example Response Time, Throughput, Utilization, Static Volumetric
Scalability
Capacity
Availability
Reliability
Non-functional requirements examples

Recoverability
Maintainability
Serviceability
Security
Regulatory
Manageability
Environmental
Data Integrity
Usability
Interoperability

Functional VS Non-functional requirements
Functional Requirements Non-Functional Requirements
They define a system or its component. They define the quality attribute of a system
It specifies, “How should the system fulfill the

It specifies, “What the system should do?” functional requirements?”
Non-functional requirement is specified by technical

peoples e.g. Architect, Technical leaders and software
User specifies functional requirement. developers.
It is mandatory to meet these requirements. It is not mandatory to meet these requirements.

Functional VS Non-functional requirements
Functional Requirements Non-Functional Requirements
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a whole system.
Helps you to verify the functionality of the Helps you to verify the performance of the
software. software.
Functional Testing like System, Integration, End Non-Functional Testing like Performance, Stress,
to End, API testing, etc are done. Usability, Security testing, etc are done.
Usually easy to define. Usually more difficult to define.

User requirements
Should describe functional and non-functional requirements so that they are
understandable by system users who don’t have detailed technical knowledge
User requirements are defined using natural language, tables and diagrams.
Often referred to as user needs, describe what the user does with the system, such as
what activities that users must be able to perform.

System requirements
System requirements are the required specifications a device must have in order to use
certain hardware or software
More detailed specifications of user requirements Serve as a basis for designing the
system
Before purchasing a software program or hardware device, you can check the system
requirements to make sure the product is compatible with your system.
Typical system requirements for a software program include:

System requirements
Operating system
Minimum CPU or processor speed
Minimum GPU or video memory
Minimum system memory (RAM)
Minimum free storage space
Audio hardware (sound card, speakers, etc)
System requirements listed for a hardware device may include:
Operating system
Available ports (USB, Ethernet, etc)
Wireless connectivity
Minimum GPU (for displays and graphics hardware)
Software Requirements Specification

What is software requirement specification
After the analyst has gathered all the required information regarding the software to be
developed, and has removed all incompleteness, inconsistencies, and anomalies from the
specification, he starts to systematically organize the requirements in the form of an SRS
document.
The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called a requirements document).
SRS is a formal report, which acts as a representation of software that enables the
customers to review whether it (SRS) is according to their requirements.
Purpose of SRS document?
SRS establishes basis of agreement between the user and the supplier.
Users needs have to be satisfied, but user may not understand software
Developers will develop the system, but may not know about problem domain
SRS is
The medium to bridge the communications gap, and
Specifies user needs in a manner both can understand

Need for SRS…
Helps user understand his needs.

users do not always know their needs
must analyze and understand the potential
The requirement process helps clarify needs
SRS provides a reference for validation of the final

product
Clear understanding about what is expected.
Need for SRS…
High quality SRS essential for high Quality SW

Requirement errors get manifested in final sw
To satisfy the quality objective, must begin with high quality SRS
Requirements defects cause later problems

25% of all defects in one study; 54% of all defects found after user testing
defects often found in previously approved SRS.

Characteristics of an SRS
Correct
Complete
Unambiguous
Consistent
Verifiable
Traceable
Modifiable
Ranked for importance and/or stability
Correctness
 Each requirement accurately represents some desired feature in the final system
Completeness
 All desired features/characteristics specified
 Hardest to satisfy
 Completeness and correctness strongly related
Unambiguous
 Each requirement has exactly one meaning
 Without this errors will creep in
 Important as natural languages often used

Verifiability
There must exist a cost effective way of checking if sw satisfies requirements
Consistent
two requirements don’t contradict each other
Traceable
The origin of the req, and how the req relates to software elements can be determined
Ranked for importance/stability

Needed for prioritizing in construction
To reduce risks due to changing requirements
Components of an SRS
What should an SRS contain ?
Clarifying this will help ensure completeness
An SRS must specify requirements on

Functionality
Performance
Design constraints
External interfaces

Functional Requirements
Heart of the SRS document; this forms the bulk of the specs
Specifies all the functionality that the system should support
Outputs for the given inputs and the relationship between them
All operations the system is to do
Must specify behavior for invalid inputs too

Performance Requirements
All the performance constraints on the software system
Generally on response time , throughput etc => dynamic
Capacity requirements => static
Must be in measurable terms (verifiability)

Eg resp time should be xx 90% of the time

Design Constraints
Factors in the client environment that restrict the choices

Some such restrictions
 Standard compliance and compatibility with other systems
 Hardware Limitations
 Reliability, fault tolerance, backup req.
 Security

External Interface
All interactions of the software with people, hardware, and sw

User interface most important
General requirements of “friendliness” should be avoided
These should also be verifiable

Specification Language
Language should support desired characteristics of the SRS
Formal languages are precise and unambiguous but hard
Natural languages mostly used, with some structure for the document
Formal languages used for special features or in highly critical systems

Structure of an SRS
Introduction
 Purpose , the basic objective of the system
 Scope of what the system is to do , not to do
 Overview
Overall description
 Product perspective
 Product functions
 User characteristics
 Assumptions
 Constraints
Structure of an SRS
Specific requirements
External interfaces
Functional requirements
Performance requirements
Design constraints
Acceptable criteria
desirable to specify this up front.
This standardization of the SRS was done by IEEE.

Requirements engineering processes

The processes used for RE vary widely depending on the application domain, the
people involved and the organisation developing the requirements.
However, there are a number of generic activities common to all processes
 Requirements elicitation
 Requirements analysis
 Requirements validation
 Requirements management

Requirements engineering processes

Feasibility studies
A feasibility study decides whether or not the proposed system is useful.

A short focused study that checks
 If the system contributes to organisational objectives
 If the system can be engineered using current technology and within budget
 If the system can be integrated with other systems that are used

Feasibility study implementation

Based on information assessment (what is required), information collection and
report writing
Questions for people in the organisation
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?

Types of feasibility study
1)Technical Feasibility –
In Technical Feasibility current resources both hardware software along with
required technology are analyzed/assessed to develop project.
This technical feasibility study gives report whether there exists correct required
resources and technologies which will be used for project development.
Along with this, feasibility study also analyzes technical skills and capabilities of
technical team, existing technology can be used or not, maintenance and up-gradation
is easy or not for chosen technology etc.

Types of feasibility study

2) Operational Feasibility
 In Operational Feasibility degree of providing service to requirements is analyzed along with how
much easy product will be to operate and maintenance after deployment.
Along with this other operational scopes are determining usability of product, Determining suggested
solution by software development team is acceptable or not etc.
3) Economic Feasibility –
In Economic Feasibility study cost and benefit of the project is analyzed.
under this feasibility study a detail analysis is carried out what will be cost of the project for
development which includes all required cost for final development like hardware and software resource
required, design and development cost and operational cost and so on.
After that it is analyzed whether project will be beneficial in terms of finance for organization or not.
Requirement elicitation
Requirements elicitation is the practice of researching and discovering

the requirements of a system from users, customers, and other stakeholders.
The practice is also sometimes referred to as "requirement gathering".
Requirement elicitation process can be depicted using the following diagram:

Requirement elicitation
Requirements gathering: The developers discuss with the client and end users and know their
expectations from the software.
Organizing Requirements: The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.
Negotiation & discussion: If requirements are ambiguous or there are some conflicts in requirements of
various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may
then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are
discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.
Documentation: All formal & informal, functional and non-functional requirements are documented and
made available for next phase processing.

Requirement Elicitation Techniques

1) Interviews
Interviews are strong medium to collect requirements. Organization may conduct
several types of interviews such as:
Structured (closed) interviews, where every single information to gather is decided in
advance, they follow pattern and matter of discussion firmly.
Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
Oral interviews
Written interviews

One-to-one interviews which are held between two persons across the table.
Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.
2)Surveys
Organization may conduct surveys among various stakeholders by querying about
their expectation and requirements from the upcoming system.
3)Questionnaires
 A document with pre-defined set of objective questions and respective options is
handed over to all stakeholders to answer, which are collected and compiled.

 A shortcoming of this technique is, if an option for some issue is not mentioned in
the questionnaire, the issue might be left unattended.
4)Task analysis
Team of engineers and developers may analyze the operation for which the new
system is required. If the client already has some software to perform certain operation,
it is studied and requirements of proposed system are collected.
5)Domain Analysis
Every software falls into some domain category. The expert people in the domain can
be a great help to analyze general and specific requirements.

6)Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.
7)Prototyping
If there is no software installed at client’s end for developer’s reference and the client
is not aware of its own requirements, the developer creates a prototype based on
initially mentioned requirements.
The prototype is shown to the client and the feedback is noted. The client feedback
serves as an input for requirement gathering.
8)Observation
Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at client’s end and
how execution problems are dealt.
The team itself draws some conclusions which aid to form requirements expected from
the software

Requirements Analysis
Requirements Analysis, determining whether the stated requirements are clear, complete, consistent and
unambiguous.
After requirements gathering is complete, the analyst analyses the gathered requirements to form a clear
understanding of the exact customer requirements and to clear out any problems in the gathered
requirements.
The data collected from various stakeholders to contain several contradictions, ambiguities, and
incompleteness, since each stakeholder typically has only a partial and incomplete view of the software.
Therefore, it is necessary to identify all the problems in the requirements and resolve them through further
discussions with the customer.

A stakeholder is either an individual, group or organization who is impacted by the outcome of a project.
They have an interest in the success of the project, and can be within or outside the organization that is
sponsoring the project.
Stakeholder Identification
Stakeholders are people or organizations that have a valid interest in the system. They may be affected
by it directly or indirectly.
Stake holders may include:
 Anyone who operates the system
 Anyone who benefits from the system
 Anyone involved in purchasing or procuring the system
 People opposed to the system (negative stakeholders)
 Organizations responsible for the system
The following basic questions pertaining to the project should be clearly understood by the
analyst before carrying out analysis:
1. What is the problem?
2. Why is it important to solve the problem?
3. What exactly are the data input to the system and what exactly are the data output by the system?
4. What are the possible procedures that need to be followed to solve the problem? What are the likely
complexities that might arise while solving the problem?
5. If there are external software or hardware with which the developed software has to interface, then what
should be the data interchange formats with the external systems?

After the analyst has understood the exact customer requirements, he proceeds to identify and resolve
the various problems that he detects in the gathered requirements.
During requirements analysis, the analyst needs to identify and resolve the following types of problems
in the requirements:
Atomic
Uniquely identified
Complete
Consistent and unambiguous
Traceable
Prioritized
Testable
Requirement Quality Example of bad requirement Example of good requirement
Atomic Students will be able to enroll to undergraduate Students will be able to enroll to
and post graduate courses undergraduate courses
Students will be able to enroll to post-
graduate courses
Uniquely identified Students will be able to enroll to undergraduate Course Enrolment

courses1- Students will be able to enroll to Students will be able to enroll to
post-graduate courses undergraduate courses
Students will be able to enroll to post-
graduate courses
Complete A professor user will log into the system by A professor user will log into the system
providing his username, password, and other by providing his username, password and
relevant information department code
Requirement Quality Example of bad requirement Example of good requirement
Consistent and unambiguous A student will have either undergraduate courses A student will have either under-graduate
or post-graduate courses but not both. Some or post graduates but not both
courses will be open to both under-graduate and
post-graduate
Traceable Maintain student information-mapped to BRD Maintain student information-Mapped to

req.ID? BRD req ID 4.1
Prioritized Registered student-Priority-1 Register Student-Priority-1

Maintain User Information-Priority-1 Maintain User Information-Priority-2
Enroll courses-Priority-1 Enroll courses-Priority-1
View Report Card-Priority -1 View Report Card-Priority-3
Testable Each page of the system will load in an Register student and enroll courses pages
12/20/2023 acceptable time-frame of the system

DEPARTMENT OF CSE, GIET UNIVERSITY, will load within 5 seconds
GUNUPUR 169
Techniques for representing complex Logic

There are two main techniques available to analyse and represent complex processing logic:
Decision Tree
Decision table
Decision Tree
A decision tree gives a graphic view of the processing logic involved in decision making and the
corresponding action taken. Decision tables specify which variables are to be tested and based on this
what actions are to be taken depending upon the outcome of the decision making logic and the order in
which decision making is performed.
The edges of a decision tree represent conditions and the leaf nodes represent the actions to be performed
depending on the outcome of testing the condition.

Decision Tree for LMS
New Member Ask for Members Name, address, etc.

Creates membership record
Print Bill
Renewal Ask Membership detail
s Update expiry date
Ye Print Bill
Valid Actions Cancel Membership Ask Membership detail
No Delete Membership record

Print Cheque
Display error
message

Decision Table
A decision table shows the decision making logic and the corresponding action taken in
a tabular or a matrix form. The upper rows of the table specify the variables or
conditions to be evaluated and the lower rows specify the actions to be taken when an
evaluation test is satisfied. A column in the table is called a rule. A rule implies that if a
certain condition combination is true, then the corresponding action is executed.
Let’s take LMS

Decision
Table Conditions
Valid Selection NO YES YES YES
New Member -- YES NO NO
Renewal -- NO YES NO
Cancellation -- NO NO YES
Actions
Display Error Message X
Ask Member name, etc. X
Build Customer’s record X
Generate Bill X X
Ask Membership Details X X
Update Expiry Date X
Print Cheque X
Delete Record X
Requirements Specifications
Requirements Specification is the direct result of a requirement analysis and can refer to:
 Software Requirements Specification
 Hardware Requirements Specification
Requirements Validation
Validation (& Verification), is the process of checking whether the requirements, as identified, do not
contradict the expectations about the system of various stakeholders and do not contradict each other.
It is Requirements Quality Control.
It’s a process of ensuring the specified requirements meet the customer needs. It’s concerned with
finding problems with the requirements.
These problems can lead to extensive rework costs when these they are discovered in the later stages,
or after the system is in service.
During the requirements validation process, different types of checks should be carried out on the
requirements. These checks include:
Validity checks: The functions proposed by stakeholders should be aligned with what the system needs
to perform. You may find later that there are additional or different functions are required instead.
Consistency checks: Requirements in the document shouldn’t conflict or different description of the
same function
Completeness checks: The document should include all the requirements and constrains.
Realism checks: Ensure the requirements can actually be implemented using the knowledge of existing
technology, the budget, schedule, etc.
Verifiability: Requirements should be written so that they can be tested. This means you should be able
to write a set of tests that demonstrate that the system meets the specified requirements.
There are some techniques you can use to validate the requirements.
1.Requirements Reviews
A team of system customer, those who interact with the customer to gather requirements, and system
developers start reading the requirements in the document.
Investigation is done to check for errors, inconsistency, conflicts, and any ambiguity. Then they may
negotiate with the customer on how to solve the problems and errors found.
2.Prototyping
In this approach to validation, an executable model of the system is demonstrated to the customer and
end users to validate, and ensure if it meets their needs.
Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of the
system to validate the requirements. If it fails, we then refine it, and check again, until it meets the
customer needs.
This definitely will decrease the cost as a result of having a clear, understandable, consistent
requirements.

3.Test-case Generation
The requirements need to be testable. If the tests for the requirements are added as part of the validation
process, this often reveals requirements problems.
If the test is difficult or impossible to design, this usually means that the requirements will be difficult
to implement and should be reconsidered.
The term “tests” here doesn’t mean to write and run some code for every function. It means to write a
textual description of the “inputs”, “expected value”, and “steps taken” to perform each function.

What is Requirements Management?

 Requirements Management is an iterative set of activities that help ensure that elicitation,
documentation, refinement, and changes of requirements is adequately dealt with during a lifecycle,
with a view toward satisfying the overall mission or need in a quality manner and to the customers’
satisfaction.
 Whether part of a project management plan or standalone, a Requirements Management Plan (RMP)
describes the requirements artifacts, requirement types (including attributes), the requirements
management process, and the metrics and tools to be used for measuring, reporting, and controlling
changes to the requirements.
 For example, in a fictitious library system, a requirement could be that "the library system allows
people to check-in and check-out books". Requirements management is the process of capturing and
managing all of the different ‘needs’ that different stakeholders have in a system. Sometimes the needs
relate to the functionality (the system needs to do X), other times it may be technical need (the system
needs to run on specific web browsers, database servers, etc.)

Why Manage Requirements?
Studies have shown that requirements management improves all major aspects of organizational strategy
(portfolio, programs, and projects) or operations management (day-to-day business) by:
Reducing cost
Improving quality
Decreasing time taken
Decreasing risks
Enabling effective scope management

Structured system analysis
Structured Analysis is a development method that allows the analyst to understand the system and its
activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an
existing system and develop a new system specification which can be easily understandable by user.
It has following attributes −
It is graphic which specifies the presentation of application.
It divides the processes so that it gives a clear picture of system flow.
It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware.
It is an approach that works from high-level overviews to lower-level details

Structured Analysis Tools
During Structured Analysis, various tools and techniques are used for system development. They are −
Data Flow Diagrams
Data Dictionary
Decision Trees
Decision Tables
Structured English
Pseudo code


Data Flow Diagrams (DFD) or Bubble Chart
It is a technique developed by Larry Constantine to express the requirements of system in a graphical
form.
It shows the flow of data between various functions of system and specifies how the current system is
implemented.
It is an initial stage of design phase that functionally divides the requirement specifications down to the
lowest level of detail.
Its graphical nature makes it a good communication tool between user and analyst or analyst and
system designer.
It gives an overview of what data a system processes, what transformations are performed, what data
are stored, what results are produced and where they flow.

Basic Elements of DFD
DFD is easy to understand and quite effective when the required design is not clear and the user wants a
notational language for communication. However, it requires a large number of iterations for obtaining
the most accurate and complete solution.


Software Engg

Uploaded by

Copyright:

Available Formats

You might also like

Software Engg

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engg

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING

6th Semester CSE (R-19)

WHAT IS SOFTWARE ENGINEERING?

A popular definition of software engineering is: “A systematic collection of good program

development practices and techniques”.

An alternative definition of software engineering is: “An engineering approach to develop

SOFTWARE DEVELOPMENT PROJECTS

Programs versus Products

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 3

SOFTWARE DEVELOPMENT PROJECTS

Programs versus Products

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 4

SOFTWARE DEVELOPMENT PROJECTS

Programs versus Products

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 5

SOFTWARE DEVELOPMENT PROJECTS

SIZE SMALL LARGE

DOCUMENTATION IMPROPER / LACKING PROPER

USER HIMSELF MANY

DEVELOPER SINGLE A TRAINED TEAM

USER INTERFACE ABSENT WELL DESIGNED

DEVELOPMENT AD-HOC PLANNED

FUNCTIONALITY LIMITED MORE OPTIONS & FEATURES

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 6

Risk and importance of risk management :

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 7

Various Kinds of Risks in Software Development :

Factors affecting scheduled risk

Failure in function identification and its’ completion

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 8

Various Kinds of Risks in Software Development :

Factors affecting Budget risk

Mismanagement in budget handling Cost overruns

Various Kinds of Risks in Software Development :

Factors affecting Operational risk

Various Kinds of Risks in Software Development :

Factors affecting Technical risk

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 11

Various Kinds of Risks in Software Development :

Factors affecting Programmatic risk

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 12

SOFTWARE APPLICATION DOMAINS

SOFTWARE APPLICATION DOMAINS

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 15

SOFTWARE APPLICATION DOMAINS

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 16

HANDLING COMPLEXITY THROUGH ABSTRACTION AND DECOMPOSITION

Abstraction refers to construction of a simpler version of a problem by ignoring the

Abstraction is the simplification of a problem by focusing on only one aspect of the

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 17

HANDLING COMPLEXITY THROUGH ABSTRACTION AND DECOMPOSITION

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 18

WHY STUDY SOFTWARE ENGINEERING?

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) MODEL

12/20/2023 DEPARTMENT OF CSE, GIET UNIVERSITY, GUNUPUR 20

PROCESS VERSUS METHODOLOGY

PROCESS VERSUS METHODOLOGY

A software development process has a much broader scope as compared to a software