Software

Engineeri
ng
1BCA
Unit 1
SOFTWARE
 Software is a collection of computer programs, procedures, rules,
and associated documentation and data.
CHARACTERISTICS / NATURE OF SOFTWARE
1) Intangible part of a computer system: software is a line of code and
data stored on hardware but it cannot be physically touched/handled.
Being intangible, it can be easily replicated and distributed digitally,
can be modified and updated, and can exist in multiple versions.
2) Intrinsically complex: Software becomes complex due to various
factors such as the need to fulfill specific client requirements and
accommodating a wide range of user inputs and scenarios, the need to
be compatible with different hardware and software environments.
3) Software does not wear out, it deteriorates: unlike the physical
hardware components, which wear out with time due to friction and
normal wear and tear, software does not wear out in the same way. It
deteriorates in terms of performance, security, and functionality if not
properly maintained or updated
4) Software is not manufactured but developed: Unlike other physical
products, the software is not manufactured but developed over time
through a creative and. iterative process, which involves different
stages such as collecting requirements, modeling, coding, testing, and
then deployment and maintenance after that.
5) software is prone to failure: Software can be prone to failure
because of various factors such as - errors and bugs, incomplete/
inaccurate requirements, compatibility issues with hardware or other
supporting software
6) costly to maintain: Maintaining software can be expensive,
especially when it is complex software. Maintenance includes- bug
fixing, issue resolution, updating security, and adding new features
based on user feedback. All these activities lead to maintenance being
costly.
ATTRIBUTES OF GOOD SOFTWARE
1) Functionality: Good software should fulfill its intended purpose
and satisfy all the user requirements. It should meet the needs for
which it was designed.
2) Reliability: Software should be consistent and work without
failures to perform the required function. Users should be able to trust
the software.
3) Usability: Usability is how easy the software is to use. Good
software should have all the features which easy to understand or use
for the users making it
4) Maintainability: Software should have well-structured code and
clear documentation so that developers. can make changes to it.
Software is maintainable when it is easy to modify or update.
5) portability: It refers to the ease with which software developers can
make software compatible to run on different platforms without
making major changes.
6) Efficiency: Efficient software is the one that uses system resources
most efficiently and effectively Software shouldn't waste memory or
storage and should run smoothly.

SOFTWARE ENGINEERING
 Software Engineering is the application of a systematic,
disciplined, quantifiable approach to the development, operation,
 and maintenance of software i.e., the application of engineering to
software.
 It is the art of developing quality software in an effective and
efficient way

TYPES OF SOFTWARE
1) System Software: A collection of programs written to service other
programs at the system level E.g., compiler operating system, etc.
2) Real-time Software: Programs that monitor/analyze, and control
real-world events as they occur.
3) Business Software: Programs that access, analyze, and process
business information.
4) Engineering and Scientific software: software that is used for
science and applications, system simulation, and computer-aided
design.
5) Internet Software: Programs that support internet access and
applications. E.g., search engines, browsers, and e-commerce
software.
6) Software Tools and CASE environment: Tools and programs that
help the construction of application software and systems. E.g.,
Test tools.

LEGACY SOFTWARE
Legacy software is the older programs that were developed decades
ago that are still in use by performing modifications to meet business
requirements. This software increase demand can cause risk as it may
require outdated hardware and operating systems to work.

SOFTWARE ENGINEERING LAYERS

1) A Quality Focus: It defines the continuous process improvement
principle of software. It means providing security to the software so
that data can be accessed by only an authorized person, no outsider
can access the data... It also focuses on maintainability and usability.
2) Process: It is the foundation or base layer which binds all the layers
together. Process defines a framework that must be established for the
effective delivery of technology. It covers all the activities, actions,
and tasks required to carry out software development.
3) Method: The method gives the answers to all "how to do "questions
in the process of software development. It has the information on all
the tasks.
4) Tools: Software Engineering tools provide a self-operating system
for processes and methods. Tools are integrated which means
information created by one tool can be used by another.

SOFTWARE ENGINEERING PRACTICE

1) understand the problem/communication and analysis
2) Plan a solution (modeling and software design)
3) Carry out a plan (code generation)
4) Examine the result for accuracy (testing)

GENERAL PRINCIPLES.
1) The First Principle: Any software exists for the sole purpose of
providing value to its users. All decisions regarding software
development should be made using this in mind. Before specifying
we should ask whether and decide whether anything, adds any
value or not to the system. If it doesn't it shouldn't be worked upon.

2) The Second principle: KISS (keep it simple, stupid!) software

design is not just a casual process. Many factors have to be
considered in design. All designs should be simple, but not quick.
It should take time, a lot of thought, and ideas and the result should
be a more maintainable and less error-prone software.
3) The third Principle: Maintain the vision
A clear vision is very essential It decides whether your software
project will be a success or not
4) The fourth Principle: What you produce, others consume users will
use, maintain, document, and depend on our system. So, we should
always specify, design, and implement everything knowing our
users will have to understand and be familiar with it.

5) The fifth principle: Be open to the Future

In today's evolving technological environment, specifications and
hardware change in just a few months. Software should be able to
adapt to these changes. Developers should be prepared for all
possible situations and their solutions.

6) The sixth Principle: Plan for reuse

The reuse of code and design is a major benefit of using object-
oriented technologies for developers. It saves a lot of time and
effort.
7) The seventh Principle: Think
Having clear and complete thoughts about any action to be taken
always produces better results. When we think and analyze before
actually doing the work, we are more likely to do it in the right
way, and even if it goes wrong somewhere, it can be taken as a
valuable experience.
Unit 2
Process
 Software process compromises activities performed to create a
software product. It deals with & the technical and management
aspects of software development.
It includes:
1. Task - focus on a small, specific objective.
2. Action - set of tasks that produce a major work product
3. Activities- a group of related tasks and actions for a major
objective

PROCESS FRAMEWORK ACTIVITIES

1) Communication- communicate with stakeholders and customers to
obtain the objective of the system - and requirements for the
software.
2) Planning - software projects have detailed resources needed, tasks,
and risk factors likely to occur.
3) Modelling - Architectural models and design make it better to
understand the problem and work towards the best solution.
4) Construction - Generation of code and testing of the system to
rectify errors and ensure all specified requirements are met.
5) Deployment - Entire software product or partially completed
product is delivered to the customer for evaluation and feedback

UMBRELLA ACTIVITIES
 These activities occur throughout a software process for better
management and tracking of the project
1) Software project tracking and control: compare the progress of
the project with the plan and take steps to maintain a planned
schedule.
2) Risk Management: Evaluate risks that can affect the outcome
and quality of the software project.
3) Software Quality Assurance (SQA): conduct activities to ensure
the quality of the product.
4) Technical reviews: assessment of errors and corrections done at
every stage.
5) Measurement: All the measurements of the product and product
features.
6) Software Configuration Management (SCM): controlling and
tracking software changes.
7) Reusability Management - Backup products for reuse and apply
the mechanism to achieve reusable software components.
8) Work product preparation and production: project planning and
other activities used to create work products are documented.

PROCESS FLOW
 The process flow describes how the framework activities and the
actions and tasks that occur within each framework activity are
organized concerning sequence and time.
1) A linear process flow executes each of the five framework
activities in sequence, beginning with communication and
culminating with deployment.

2) An iterative process flow repeats one or more of the activities

before proceeding to the next
 3) An evolutionary process flow executes the activities in a
“circular” manner. Each circuit through the five activities leads
to a more complete version of the software.

4) A parallel process flow executes one or more activities in

parallel with other activities (e.g., modeling for one aspect of the
software might be executed in parallel with the construction of
another aspect of the software

PROCESS PATTERN
 A process pattern describes a process-related problem that is
encountered during software engineering work, identifies the
environment in which the problem has been encountered, and
suggests one or more proven solutions to the problem.
1) Problem – Specific problem that is to be solved by the pattern.
2) Solution – Implements pattern and initial context is modified
to resolve the problem.
 3) Resulting context – Situation which will result from carrying
out the process pattern solution.
4) Related patterns – A list of patterns related to the current one
is documented for further reference.
5) Known uses or examples – Indicates where or how the
process pattern is applicable.

PROCESS MODELS
1) Waterfall Model
In the Waterfall model the development of software proceeds linearly
and sequentially from requirement analysis to design, coding, testing,
integration, implementation, and maintenance. So, it is also known as
a Linear Sequential model.

2) V-Shaped SDLC Model

A variant of the Waterfall model that emphasizes the verification and
validation of the product. Testing of the product is planned in parallel
with a corresponding phase of development
3) Evolutionary Development
When specifications provided by the user are not clear, it is advisable
to create a model of the software before the actual software is
developed. The model created for understanding the specifications of
the final software is known as the ‘prototype’ of the software
 Exploratory development
o The development of the product starts with the part of the
system which is well understood by the developer.
o This product is exposed to the user to get more features.
o These new features are added to the product and the process
continues until a final acceptable product is built.

 Throw-away prototyping
o Start with poorly understood requirements to clarify what is
needed. It is then designed and exposed to the user to get
more refined requirements.
 o The reviewing, revising specifications, and implementing
continue until final specifications are documented.

4) Process Iteration
The requirement of a large system evolves during the
development process. This necessitates the process iteration as
certain steps of the process are repeated during the evolution of
the system.
 Incremental Development
o Rather than deliver the system as a single delivery, the
development and delivery are broken down into increments
with each increment delivering part of the required
functionality.
o User requirements are prioritized and the highest priority
requirements are included in early increments.

 Spiral Development
 o It combines the development activities with risk management
to minimize and control the risks

5) RAD Model
It Stands for the Rapid Application Development model and
Facilitates the reuse of modules in different projects. The modules can
be stored off the shelf and may be used in the future which Saves
efforts of development and well as time of development.

DIFFERENCE BETWEEN WATERFALL AND SPIRAL

Unit 3
REQUIREMENT ENGINEERING
 The broad spectrum of tasks and techniques that lead to an
understanding of requirements is called requirements
engineering.
 From a software process perspective, requirements engineering is a
major software engineering action that begins with the
communication activity and continues into the modeling activity.

TYPES OF REQUIREMENTS
1) Normal requirements ( Functional ): These requirements are the
objectives and goals stated for a product or system during meetings
with the customer
2) Expected requirements (Non-Functional Requirements): These
requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them
3) Exciting requirements: These requirements are for features that go
beyond the customer's expectations and prove to be very satisfying
when present.

REQUIREMENT PROCESS PHASES

1) Inception: At inception, you establish a basic understanding of the
problem, the people who want a solution, the nature of the solution
that is desired, and the effectiveness of preliminary communication
and collaboration between the other stakeholders and the software
team.

2) Elicitation: ask the customer, the users, and others what the
objectives for the system or product are, what is to be
accomplished, how the system or product fits into the needs of the
business, and finally, how the system or product is to be used on a
day-to-day basis.
3) Elaboration: the software engineer takes the information obtained
and begins to expand and refine it Elaboration focuses on
developing a refined technical model of Software functions,
features, and constraints. It is an analysis modeling task
o Use cases are developed
o Domain classes are identified
o State machine diagrams are used to capture the life on an
object

4) Negotiation: Customers, users, and other stakeholders are asked to

rank requirements and then discuss conflicts in priority.
 Using an iterative approach that prioritizes requirements, assesses
their cost and risk, and addresses internal conflicts, requirements
are eliminated, combined, and/or modified so that each party
achieves some measure of satisfaction.

5) Specification: A specification is the final work product produced by

the requirements engineer. It is normally in the form of a software
requirements specification It serves as the foundation for
subsequent software engineering activities. It describes the
function and performance of a computer-based system and the
constraints that will govern its development

6) Validation: Requirements validation examines the specification to

ensure that all software requirements have been stated
unambiguously; that inconsistencies, omissions, and errors have
been detected and corrected; and that the work products conform to
the standards established for the process, the project, and the
product.

7) Requirements Management: Requirements for computer-based

systems change, and the desire to change requirements persists
throughout the life of the system. This is a set of activities that help
the project team identify, control, and track requirements and
changes to requirements at any time as the project proceeds.

INCEPTION
• During inception, the requirements engineer asks a set of questions
to establish…
– A basic understanding of the problem
– The people who want a solution
– The nature of the solution that is desired
 – The effectiveness of preliminary communication and
collaboration between the customer and the developer

• Through these questions, the requirements engineer needs to…

– Identify the stakeholders
– Recognize viewpoints
– Work toward collaboration
– Break the ice and initiate the communication

• These questions enable the requirements engineer to gain a better

understanding of the problem and allow the customer to voice his
or her perceptions about a solution
– How would you characterize "good" output that would be
generated by a successful solution?
– What problem(s) will this solution address?
– Can you show me (or describe) the business environment in
which the solution will be used?
– Will special performance issues or constraints affect the way the
solution is approached?

• These questions focus on the effectiveness of the communication

activity itself
– Are you the right person to answer these questions? Are your
answers "official"?
– Are my questions relevant to the problem that you have?
– Am I asking too many questions?
– Can anyone else provide additional information?
 – Should I be asking you anything else

ELICITATION
 several problems are encountered as elicitation occurs
o Problems of scope - The boundary of the system is ill-defined
or the customers/users specify unnecessary technical detail
that may confuse overall system objectives.
o Problem of understanding - The customers/users are not
completely sure of what is needed, and have a poor
understanding of the capabilities and limitations of their
computing environment.
o Problems of volatility - The requirements change over time.
 Elicitation may be accomplished through two activities
a. Collaborative requirements gathering: The goal is to identify
the problem, propose elements of the solution, negotiate
different approaches, and specify a preliminary set of
solution requirements
– Meetings are conducted and attended by software
engineers, customers, and other interested stakeholders
– An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the
free flow of ideas

b. Quality function deployment: Quality function deployment

(QFD) is a quality management technique that translates the
needs of the customer into technical requirements for
software.
– QFD “concentrates on maximizing customer satisfaction
from the software engineering process”.
 – To accomplish this, QFD emphasizes an understanding of
what is valuable to the customer and then deploys these
values throughout the engineering process

Unit 4
SOFTWARE DESIGN
 Once software requirements have been analyzed and modeled,
software design is the last software engineering action within the
modeling activity and sets the stage for construction (code
generation and testing).
 Each of the elements of the requirements model provides
information that is necessary to create the four design models
required for a complete specification of design.

QUALITY GUIDELINES
1. A design should exhibit an architecture that has been created using
recognizable styles or patterns, is composed of components that
exhibit good design, and can be implemented evolutionarily,
thereby facilitating implementation and testing.
2. A design should be modular; that is, the software should be
logically partitioned into elements or subsystems.
3. A design should contain distinct representations of data,
architecture, interfaces, and components.
4. A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data
patterns.
5. A design should lead to components that exhibit independent
functional characteristics.
6. A design should lead to interfaces that reduce the complexity of
connections between components and with the external
environment.
7. A design should be derived using a repeatable method that is driven
by information obtained during software requirements analysis.
8. A design should be represented using a notation that effectively
communicates its meaning.

QUALITY ATTRIBUTES
1. Functionality is assessed by evaluating the feature set and
capabilities of the program, the generality of the functions that are
delivered, and the security of the overall system.
2. Usability is assessed by considering human factors , overall
aesthetics, consistency, and documentation.
3. Reliability is evaluated by measuring the frequency and severity of
failure, the accuracy of output results, the mean-time-to-failure
(MTTF), the ability to recover from failure, and the predictability
of the program.
4. Performance is measured by considering processing speed,
response time, resource consumption, throughput, and efficiency.
5. Supportability combines the ability to extend the program
(extensibility), adaptability, serviceability.

ARCHITECTURE
 architecture is the structure or organization of program components
(modules), the manner in which these components interact, and the
structure of data that are used by the components.
 A set of architectural patterns enables a software engineer to solve
common design problems.
 The architectural design can be represented using one or more of a
number of different models :
o Structural models - represent architecture as an organized
collection of program components.
o Framework models - increase the level of design abstraction
by attempting to identify repeatable architectural design
frameworks that are encountered in similar types of
applications.
o Dynamic models - address the behavioral aspects of the
program architecture, indicating how the structure or system
configuration may change as a function of external events.
o Process models - focus on the design of the business or
technical process that the system must accommodate.
o Functional models - can be used to represent the functional
hierarchy of a system.

PATTERNS
 A design pattern describes a design structure that solves a
particular design problem within a specific context and amid
“forces” that may have an impact on how the pattern is applied and
used.
 each design pattern intends to provide a description that enables a
designer to determine
1) whether the pattern is applicable to the current work,
2) whether the pattern can be reused (hence, saving design time),
and
3) whether the pattern can serve as a guide for developing a
similar, but functionally or structurally different pattern.
SEPARATION OF CONCERNS
 Separation of concerns is a design concept that suggests that any
complex problem can be more easily handled if it is subdivided
into pieces that can each be solved and/or optimized independently.
 A concern is a feature or behavior that is specified as part of the
requirements model for the software.
 By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time to solve.

Unit 5
SOFTWARE TESTING
 the process of evaluating a system by manual or automated means
to verify that it satisfies specified requirements or to identify
differences between expected and actual results
WHY TEST SOFTWARE
 It removes errors, which prevent software from producing o/p
according to user requirements
 It removes errors that lead to software failure
 It determines whether the system meets business and user needs
 It ensures that the software is developed according to user
requirements
 It improves the quality of the software by removing the maximum
possible errors from it

VERIFICATION AND VALIDATION

 Verification: refers to checking or testing of items, including
software, for conformance and consistency with an associated
specification.
o Techniques like reviews, analysis, and inspections are
commonly used for verification.
o Are we developing the software, right? The discovery of
defects in the system
 Validation: refers to the process of checking that the developed
software meets the requirements specified by the user.
o Are we developing the right software? The assessment of
whether or not the system is usable in an operational situation
WHY ARE ERRORS FOUND IN SOFTWARE?
 Programming errors: Programmers can make mistakes while
developing the source code
 Unclear requirements: The user is not clear about the desired
requirements or the developers are unable to understand the user
requirements in a clear manner
 Software complexity: The complexity of current s/w can be
difficult to comprehend for someone who does not have prior
experience in s/w development
 Changing requirements: The user may not understand the effects
of change.
 Time pressures: When deadlines are not met, the attempt to speed
up the work causes errors
 Poorly documented code: It is difficult to maintain and modify a
code that is badly written or poorly documented, may lead to error

WHO SHOULD TEST YOUR PROGRAM

 The task should be assigned to an independent test group which is
responsible to detect errors that may have been neglected by the
software developers.

GUIDELINES OF SOFTWARE TESTING

 Define the expected Output:
 Inspect Output
 Include Test cases for Invalid and Unexpected Conditions:
 Test the Modified program to check its expected performance

TEST CASE
 A test case is a set of conditions or variables under which a tester
will determine whether an application or software system is
working correctly or not.
 there must be at least two test cases for each requirement:
o Positive test case
o negative test case

TESTING LEVEL
 Unit Testing
 Integration Testing
o Big Bang Testing
o Bottom-Up Testing
o Top-Down Testing
 System Testing
o Recovery testing
o Security testing
o Stress testing
o Performance testing
 Acceptance Testing

TESTING TECHNIQUES
 White Box Testing
o Control structure testing
o Basis path testing
o Mutation testing
 Black Box Testing
UNIT TESTING
Unit testing is a testing in which the individual units of the software
are tested in isolation from other parts of a program.
Advantage :
o To catch the defects that occur at the early stage of software
development.
o To minimize the ratio of defects before moving to the next level

INTEGRATION TESTING
The purpose of integration testing is to ensure that all the modules
continue to work in accordance with customer requirements even after
integration.
1. Big Bang Testing : A type of integration in which software
components of an application are combined all at once into a
overall system according to this approach
 Advantage :
o Communication between various modules is checked
 Disadvantage:
o It is possible that a set of errors is detected, but difficult to
correct these errors as the pgm is very large.
2. Buttom-Up Integration Testing: the lower level model is tested
in isolation first, then the next set of higher level modules are
tested with the previously tested lower modules.

3. Top-down Integration Testing: only one module known as the

main control module is tested. Then all the modules called by it
are combined with it and tested. This process continues till all
the modules in the software are integrated and tested.

SYSTEM TESTING
 System testing of software or hardware is a testing conducted on a
complete, integrated system to evaluate the system's compliance
with its specified requirements
 It compares the system with the non-functional system
requirements, such as security, speed, accuracy and reliability.
1. Recovery Testing : It forces the system to fail in different ways
and verifies that the software recovers from expected or
unexpected events without loss of data.
2. Security Testing: This testing is performed which identifies
and removes software flaws that may potentially lead to
security violations
o Application security: verifies that the user can access only
those data and functions for which the user of system has
given permissions
o System security: verifies that only the users, who have
permission to access the system, are accessing it.
3. Stress Testing : It tests the s/w in abnormal situations. It is
conducted to evaluate a system or component at or beyond the
limit of its specified requirements.
4. Performance Testing: This testing is used to verify the load,
and response time defined by the requirements. Like
o speed: this refers to the capability of a system to respond to
users as quickly as possibly
o Scalability: the capability of a system to handle the load
given to it
o stability: capability of a system, to prevent itself from
failure as long as possible

ACCEPTANCE TESTING
formal testing concerning user needs, requirements, and business
processes conducted to determine whether or not a system satisfies
the acceptance criteria and to enable the user, customer or other
authorised entity to determine whether or not to accept the system
WHITE BOX TESTING
 The Major objective of white-box testing is to focus on internal
program structure and discover all internal program errors.
 The goal is to:
o Guarantee that all independent paths within a module have
been exercised at least once.
o Exercise all logical decisions on their true and false sides.
o Execute all loops at their boundaries and within their
operational bounds.
o Exercise internal data structures to ensure their validity.
o Exercise all data defined and used paths.
Control Structure Testing
 Condition testing: This ensures that the logical conditions and
decision statements are free from errors. The errors present in
logical conditions can be incorrect Boolean operators, missing
parenthesis, errors in relational operators, arithmetic expressions,
and so on.
 Data-flow testing: in this test cases are designed to execute the
definition and uses of variables in the pgm. This ensures that all
variables are used properly in a pgm.
 Loop testing: is used to check the validity of loops present in the
pgm modules.
Basis Path Testing
 in this test cases are generated to make sure that every statement in
a pgm has been executed at least once. The number of independent
paths present in the pgm is calculated using McCabe cyclomatic
complexity.
Mutation Testing
 where errors are purposely inserted into a pgm to verify whether
the existing test case can detect the error or not. In this testing,
mutants of the pgm are created by making some changes in the
original pgm. The objective is to check whether each mutant
produces an o/p that is different from the o/p produced by the
original pgm

BLACK BOX TESTING

 The functionality is determined by observing the o/p to the
corresponding i/p.
Equivalence Class Partitioning
 Input values to a program are partitioned into equivalence classes.
 Partitioning is done such that: the program behaves in similar ways
to every input value belonging to an equivalence class.
Boundary Value Analysis
 Some typical programming errors occur at boundaries of
equivalence classes or might be purely due to psychological
factors.
 Programmers often fail to see special processing required at the
boundaries of equivalence classes and may improperly use <
instead of <=
 select test cases at the boundaries of different equivalence classes.