Software engineering

Software engineering is a systematic engineering approach to software

development. A software engineer is a person who applies the principles of software
engineering to design, develop, maintain, test, and evaluate computer software.
➢ Planning
➢ Designing
➢ Development
➢ Testing
➢ Deployment
➢ Maintenance

Software Engineering provides a standard procedure to design and develop a software.

It is made up of two words software + engineering

The software is a collection of integrated programs.

Engineering is the application of scientific and practical knowledge to invent, design, build,
maintain, and processes, etc.
Software Engineering is an engineering branch related to the evolution of software product
using well-defined scientific principles, techniques, and procedures. The result of software
engineering is an effective and reliable software product.
Why software engineering

➢ To manage large software

➢ For more scalability
➢ Cost management
➢ To manage dynamic nature of software
➢ For better quality management

Importance

➢ Reduce complexity
➢ To minimize software cost
➢ To decrease time
➢ Handline big projects
➢ Reliable software
➢ Effectiveness

Characteristics

➢ Functionality – suitability, accuracy , interoperability, compliance, security

➢ Reliability – recoverability, fault tolerance, maturity
➢ Efficiency – in time, in resource
➢ Usability – understandability, learnability, operability
➢ Maintainability – testability, stability, changebility
 ➢ Portability – Adaptability, Installability, replaceability

Phases in software development

• Requirement gathering and analysis.

• Design.
• Coding and Implementation.
• Testing.
• Deployment.
• Maintenance.

Software engineering is different from other types of engineering in a

number of ways which particularly makes software engineering difficult.

1. Intangible product
2. No standard software processes
3. Large projects are often one-off
4. Rapid change in technology

Spiral Model

The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model.

It allows incremental releases of the product or incremental refinement through each

iteration around the spiral.

Design - The spiral model has four phases. A software project repeatedly passes
through these phases in iterations called Spirals.
 ➢ Objectives determination and identify alternative solutions- with
gathering the business requirements in the baseline spiral. In the subsequent spirals
as the product matures, identification of system requirements, subsystem
requirements and unit requirements are all done in this phase. This phase also
includes understanding the system requirements by continuous communication
between the customer and the system analyst.
➢ Identify and resolve Risks or design- The Design phase starts with the
conceptual design in the baseline spiral and involves architectural design, logical
design of modules, physical product design and the final design in the subsequent
spirals.
➢ Develop next version of the Product/ Construct or build - The Construct
phase refers to production of the actual software product at every spiral. In the
baseline spiral, when the product is just thought of and the design is being
developed a POC (Proof of Concept) is developed in this phase to get customer
feedback.
➢ Review and plan for the next Phase / Evaluation and risk analysis - Risk
Analysis includes identifying, estimating and monitoring the technical feasibility and
management risks, such as schedule slippage and cost overrun. After testing the
build, at the end of first iteration, the customer evaluates the software and provides
feedback.

The following pointers explain the typical uses of a Spiral Model −

When there is a budget constraint and risk evaluation is important.
•
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to
economic priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough
customer feedback.
• Significant changes are expected in the product during the development
cycle.
Requirements Analysis Problems

➢ Customer don’t know what they want.

➢ Requirement changes during the project
➢ Timeline trouble
➢ Communication gaps
➢ Customer organisation politics
➢ Undocumented process

Requirement Elicitation
Requirements elicitation is the process of gathering and defining the
requirements for a software system. The goal of requirements elicitation is to
ensure that the software development process is based on a clear and
comprehensive understanding of the customer needs and requirements.
Requirements elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software system.
Prepare for Elicitation: The purpose here is to understand the elicitation
activity scope, select the right techniques, and plan for appropriate resources.
Conduct Elicitation: The purpose here is to explore and identify information
related to change.
Confirm Elicitation Results: In this step, the information gathered in the
elicitation session is checked for accuracy.

Techniques-

Brainstorming
This technique is used to generate new ideas and find a solution for a specific
issue. The members included for brainstorming can be domain experts, subject
matter experts. Multiple ideas and information give you a repository of
knowledge and you can choose from different ideas.

This session is generally conducted around the table discussion. All

participants should be given an equal amount of time to express their ideas.

Benefits:
• Creative thinking is the result of the brainstorming session.
• Plenty of ideas in a short time.
• Promotes equal participation.
Document Analysis/Review
This technique is used to gather business information by reviewing/examining
the available materials that describe the business environment. This analysis is
helpful to validate the implementation of current solutions and is also helpful
in understanding the business need.

Document analysis includes reviewing the business plans, technical

documents, problem reports, existing requirement documents, etc. This is
useful when the plan is to update an existing system. This technique is useful

for migration projects.

Benefits:
• Existing documents can be used to compare current and future
processes.
• Existing documents can be used as a base for future analysis.
Interface Analysis
Interface analysis is used to review the system, people, and processes. This
analysis is used to identify how the information is exchanged between the
components. An Interface can be described as a connection between two
components. This is described in the below image:

Benefits:
Provide missed requirements.
•
Determine regulations or interface standards.
•
Uncover areas where it could be a risk for the project.
•
Other techniques are – focus group, observation, prototyping, workshops.

Software Metrics
A software metric is a measure of software characteristics which are measurable or
countable. Software metrics are valuable for many reasons, including measuring software
performance, planning work items, measuring productivity, and many other uses.

Software metrics are like the four functions of management: Planning, Organization,
Control, or Improvement.

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software
product. The two important software characteristics are:

1. Size and complexity of software.

2. Quality and reliability of software.
2. Process Metrics: These are the measures of various characteristics of the software
development process. For example, the efficiency of fault detection. They are used to
measure the characteristics of methods, techniques, and tools that are used for developing
software.

Types of Metrics

Internal metrics: Internal metrics are the metrics used for measuring properties that are
viewed to be of greater importance to a software developer. For example, Lines of Code
(LOC) measure.

External metrics: External metrics are the metrics used for measuring properties that are
viewed to be of greater importance to the user, e.g., portability, reliability, functionality,
usability, etc.

Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource
metrics. For example, cost per FP where FP stands for Function Point Metric.

Project metrics: Project metrics are the metrics used by the project manager to check the
project's progress. Data from the past projects are used to collect various metrics, like time
and cost; these estimates are used as a base of new software. As quality improves, the number
of errors and time, as well as cost required, is also reduced.

Advantage of Software Metrics

In comparing and evaluating the capabilities and productivity of people involved in software
development.
In the preparation of software quality specifications.

In the verification of compliance of software systems requirements and specifications.

In getting an idea about the complexity of the code.

In taking decisions regarding further division of a complex module is to be done or not.

In guiding resource manager for their proper utilization.

Software Measurement: A measurement is a manifestation of the size,

quantity, amount, or dimension of a particular attribute of a product or
process. Software measurement is a titrate impute of a characteristic of a
software product or the software process. It is an authority within software
engineering. The software measurement process is defined and governed by
ISO Standard.

Software Measurement Principles:

The software measurement process can be characterized by five activities-

1. Formulation: The derivation of software measures and metrics
appropriate for the representation of the software that is being
considered.
2. Collection: The mechanism used to accumulate data required to
derive the formulated metrics.
3. Analysis: The computation of metrics and the application of
mathematical tools.
4. Interpretation: The evaluation of metrics resulting in insight into
the quality of the representation.
5. Feedback: Recommendation derived from the interpretation of
product metrics transmitted to the software team.

Need for Software Measurement:

• Create the quality of the current product or process.

• Anticipate future qualities of the product or process.
• Enhance the quality of a product or process.
• Regulate the state of the project in relation to budget and schedule.
Types-

Direct Measurement: In direct measurement, the product, process, or thing

is measured directly using a standard scale.
Indirect Measurement: In indirect measurement, the quantity or quality to
be measured is measured using related parameters i.e. by use of reference.
Modularization

Modularization is a technique to divide a software system into multiple discrete and

independent modules, which are expected to be capable of carrying out task(s)
independently. These modules may work as basic constructs for the entire software.
Designers tend to design modules such that they can be executed and/or compiled
separately and independently.
Modular design unintentionally follows the rules of ‘divide and conquer’ problem-
solving strategy this is because there are many other benefits attached with the
modular design of a software.
Advantage of modularization:

• Smaller components are easier to maintain

• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the program
• Components with high cohesion can be re-used again
• Concurrent execution can be made possible
• Desired from security aspect

Cohesion: Cohesion is a measure of the degree to which the elements of

the module are functionally related. It is the degree to which all elements
directed towards performing a single task are contained in the component.
Basically, cohesion is the internal glue that keeps the module together. A
good software design will have high cohesion.

Types of Cohesion:
• Functional Cohesion: Every essential element for a single
computation is contained in the component. A functional cohesion
performs the task and functions. It is an ideal situation.
 • Sequential Cohesion: An element outputs some data that
becomes the input for other element, i.e., data flow between the
parts. It occurs naturally in functional programming languages.
• Communicational Cohesion: Two elements operate on the same
input data or contribute towards the same output data. Example-
update record in the database and send it to the printer.
• Procedural Cohesion: Elements of procedural cohesion ensure
the order of execution. Ex- calculate student GPA, print student
record, calculate cumulative GPA, print cumulative GPA.
• Temporal Cohesion: The elements are related by their timing
involved. A module connected with temporal cohesion all the tasks
must be executed in the same time span
• Logical Cohesion: The elements are logically related and not
functionally. Ex- A component reads inputs from tape, disk, and
network.
• Coincidental Cohesion: The elements are not related(unrelated).
The elements have no conceptual relationship other than location in
source code.

Coupling: Coupling is the measure of the degree of interdependence

between the modules. A good software will have low coupling.

Types of Coupling:
• Data Coupling: If the dependency between the modules is based
on the fact that they communicate by passing only data, then the
modules are said to be data coupled. Example-customer billing
system.
• Stamp Coupling In stamp coupling, the complete data structure is
passed from one module to another module.
• Control Coupling: If the modules communicate by passing control
information, then they are said to be control coupled.
• External Coupling: In external coupling, the modules depend on
other modules, external to the software being developed or to a
particular type of hardware. Ex- protocol, external file, device
format, etc.
• Common Coupling: The modules have shared data such as global
data structures. The changes in global data mean tracing back to all
modules which access that data to evaluate the effect of the
change
• Content Coupling: In a content coupling, one module can modify
the data of another module, or control flow is passed from one
module to the other module.
Regression Testing –

Regression testing is a software testing practice that ensures an application

still functions as expected after any code changes, updates, or improvements.
Regression testing is responsible for the overall stability and functionality of
the existing features.
Regression testing involves testing existing software to verify that working
features are not broken by new development work. Regression testing is
important because it can help catch defects very early on when the cost of
remediation is still very low.Generally, an application goes through multiple
tests before the changes are integrated into the main development branch.
Regression testing is the final step, as it verifies the product behaviors as a
whole.

When to apply regression testing

• A new requirement is added to an existing feature

• A new feature or functionality is added
• The codebase is fixed to solve defects
• The source code is optimized to improve performance
• Patch fixes are added
• Changes in configuration

Detect Changes in the Source Code

Detect the modification and optimization in the source code; then identify the
components or modules that were changed, as well as their impacts on the
existing features.

Prioritize Those Changes and Product Requirements

Next, prioritize these modifications and product requirements to streamline

the testing process with the corresponding test cases and testing tools.

Determine Entry Point and Entry Criteria

Ensure whether your application meets the preset eligibility before the
regression test execution.

Determine Exit Point

Determine an exit or final point for the required eligibility or minimum

conditions set in step three.
Schedule Tests

Finally, identify all test components and schedule the appropriate time to
execute.
Tools for regression testing

➢ Selenium - Selenium offers a set of features used to automate web

applications. It remains among the top tools for browser-based and
cross-platform regression testing. Selenium supports automated test
scripts that cycle through data sets and data-driven tests.
➢ Watir - Watir, or Web Application Testing in Ruby, is an open-source
library using the Ruby programming language. It supports writing tests
that are easy to read and maintain on a lightweight and flexible user
interface.

Issues and difficulties-

➢ Large scope and coverage

➢ Regression suite visibility - Product requirements/flows and code changes,
lack of communication between team members.
➢ Execution takes time
➢ Regression test suite cost

What is Risk –
"Tomorrow problems are today's risk, "risk" is a problem that could cause some loss or
threaten the progress of the project, but which has not happened yet.

These potential issues might harm cost, schedule or technical success of the project and
the quality of our software device, or project team morale.

Risk Management is the system of identifying, addressing and eliminating these problems
before they can damage the project.

Risk management

A software project can be concerned with a large variety of risks. to systematically

identify the significant risks which might affect a software project, it is essential to classify
risks into different classes. The project manager can then check which risks from each
class are relevant to the project.

1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Since the software is intangible, it is very tough to monitor and control
a software project. It is very tough to control something which cannot be identified. For
any manufacturing program, such as the manufacturing of cars, the plan executive can
recognize the product taking shape.

2. Technical risks: Technical risks concern potential method, implementation,

interfacing, testing, and maintenance issue. Most technical risks appear due to the
development team's insufficient knowledge about the project.

3. Business risks: This type of risks contains risks of building an excellent product that
no one need, losing budgetary or personnel commitments, etc

Principle of Risk Management

1. Global Perspective: In this, we review the bigger system description, design, and
implementation. We look at the chance and the impact the risk is going to have.
2. Take a forward-looking view: Consider the threat which may appear in the
future and create future plans for directing the next events.
3. Open Communication: This is to allow the free flow of communications between
the client and the team members so that they have certainty about the risks.
4. Integrated management: In this method risk management is made an integral
part of project management.
5. Continuous process: In this phase, the risks are tracked continuously throughout
the risk management paradigm.

Risk management steps –

• Risk Identification
• Risk analysis
• Risk Planning
• Risk Monitoring

Software configuration management

When we develop software, the product (software) undergoes many changes in their
maintenance phase; we need to handle these changes effectively.

The elements that comprise all information produced as a part of the software process are
collectively called a software configuration

Therefore, SCM is the discipline which

o Identify change
o Monitor and control change
 o Ensure the proper implementation of change made to the item.
o Auditing and reporting on the change made.

Configuration Management (CM) is a technic of identifying, organizing, and controlling

modification to software being built by a programming team.

The objective is to maximize productivity by minimizing mistakes (errors).

Importance

1. It is practical in controlling and managing the access to various SCIs

2. It provides the tool to ensure that changes are being properly implemented.
3. It has the capability of describing and storing the various constituent of software.
4. SCM is used in keeping a system in a consistent state by automatically producing
derived version upon modification of the same component.

SCM Process

It uses the tools which keep that the necessary

change has been implemented adequately to the
appropriate component.

1. Identification of objects in the software

configuration
2. Version Control
3. Change Control
4. Configuration Audit
5. Status Reporting

Software Quality Assurance-

Quality defines to any measurable characteristics such as correctness, maintainability,

portability, testability, usability, reliability, efficiency, integrity, reusability, and
interoperability.

Quality of Design: Quality of Design refers to the characteristics that designers specify
for an item. The grade of materials, tolerances, and performance specifications that all
contribute to the quality of design.

Quality of conformance: Quality of conformance is the degree to which the design

specifications are followed during manufacturing. Greater the degree of conformance, the
higher is the level of quality of conformance.
Quality Assurance: Quality Assurance is the preventive set of activities that provide greater
confidence that the project will be completed successfully.

Software quality assurance is a planned and systematic plan of all actions necessary to
provide adequate confidence that an item or product conforms to establish technical
requirements.

A set of activities designed to calculate the process by which the products are developed
or manufactured.

SQA Encompasses
o A quality management approach
o Effective Software engineering technology (methods and tools)
o Formal technical reviews that are tested throughout the software process
o A multitier testing strategy
o Control of software documentation and the changes made to it.
o A procedure to ensure compliances with software development standards
o Measuring and reporting mechanisms.

Following activities are performed by an independent SQA group:

1. Prepares an SQA plan for a project:

2. Participates in the development of the project's software process description:
3. Reviews software engineering activities to verify compliance with the defined
software process:
4. Audits designated software work products to verify compliance with those
defined as a part of the software process:
5. Ensures that deviations in software work and work products are documented and
handled according to a documented procedure:
6. Records any noncompliance and reports to senior management:

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.
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.

Reasons for failure waterfall model:

The traditional waterfall model suffers from various shortcomings, basically
we can’t use it in real projects, but we use other software development
lifecycle models which are based on the classical waterfall model.
1. One way street:
This model is just like the one-way street. Once phase X is
completed and next phase Y has started then there is no way to
going back on the previous phase
2. Overlapping:
The waterfall model has lacked an overlapping among phase.The
waterfall model recommends that new phase can start only after the
completion of the previous phase. But in real projects, this can’t be
maintained. To increase the efficiency and reduce the cost, phases
may overlap.
3. Interaction:
The waterfall model has lacked interaction among phase. Users
have little interaction with project them. This feedback is not taken
during development. After a development process starts, changes
can not accommodate easily.
4. Support delivery of system:
The waterfall model does not support delivery of system in pieces.
After a development process starts, changes cannot accommodate
easily.
 5. Feedback path:
The waterfall model has no feedback path.
6. Not Flexible:
Difficult to accommodate change requests. The waterfall model
assumes that all the customer requirements can be completely and
correctly defined at the beginning of the project, but actually
customers’ requirements keep on changing with time. After the
requirements specification phase is completed difficult to
accommodate any change requests.

CMM
CMM was developed by the Software Engineering Institute (SEI) at Carnegie
Mellon University in 1987.
• It is not a software process model. It is a framework that is used to
analyze the approach and techniques followed by any organization
to develop software products.
• It also provides guidelines to further enhance the maturity of the
process used to develop those software products.
• It is based on profound feedback and development practices
adopted by the most successful organizations worldwide.
• This model describes a strategy for software process improvement
that should be followed by moving through 5 different levels.
• Each level of maturity shows a process capability level