SOFTWARE ENGINEERING NOTES

UNIT-1
INTRODUCTION TO SOFTWARE ENGINEERING
The term software engineering is composed of two words, software and engineering. Software is more than just a
program code. A program is an executable code, which serves some computational purpose. Software is considered to
be a collection of executable programming code, associated libraries and documentations. Software, when made for a
specific requirement is called a software product. Engineering on the other hand, is all about developing products, using
well-defined, scientific principles and methods. So, we can define software engineering as an engineering branch
associated with the development of software products using well-defined scientific principles, methods and procedures.
The outcome of software engineering is an efficient and reliable software product. IEEE defines software engineering as:
The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of
software. We can alternatively view it as a systematic collection of past experience. The experience is arranged in the
form of methodologies and guidelines. A small program can be written without using software engineering principles.
But if one wants to develop a large software product, then software engineering principles are absolutely necessary to
achieve good quality software cost effectively. Without using software engineering principles, it would be difficult to
develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions.
A problem with developing such large commercial programs is that the complexity and difficulty levels of the programs
increase exponentially with their sizes. Software engineering helps to reduce this programming complexity. Software
engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. The
principle of abstraction implies that a problem can be simplified by omitting irrelevant details. In other words, the main
purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purposes and
suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the
omitted details can be taken into consideration to solve the next lower-level abstraction, and so on. Abstraction is a
powerful way of reducing the complexity of the problem. The other approach to tackle problem complexity is
decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller
problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts
will not help. The problem has to be decomposed such that each component of the decomposed problem can be solved
independently and then the solution of the different components can be combined to get the full solution. A good
decomposition of a problem should minimize interactions among various components. If the different subcomponents
are interrelated, then the different components cannot be solved separately and the desired reduction in complexity will
not be realized.

NEED OF SOFTWARE ENGINEERING

The need for software engineering arises because of the higher rate of change in user requirements and the
environment in which the software is working. Large software - It is easier to build a wall than to a house or building,
likewise, as the size of software becomes large engineering has to step to give it a scientific process. Scalability- If the
software process were not based on scientific and engineering concepts, it would be easier to re-create new software
than to scale an existing one. Cost- As hardware industry has shown its skills and huge manufacturing has lowered the
price of computer and electronic hardware. But the cost of software remains high if the proper process is not adapted.
Dynamic Nature- The always growing and adapting nature of software hugely depends upon the environment in which
the user works. If the nature of software is always changing, new enhancements need to be made in the existing one.
This is where software engineering plays a good role. Quality Management- Better process of software development
provides better and quality software product.
CHARACTERESTICS OF GOOD SOFTWARE
A software product can be judged by what it offers and how well it can be used. This software must satisfy on the
following grounds:

• Operational
• Transitional
• Maintenance

Well-engineered and crafted software is expected to have the following characteristics:

Operational

This tells us how well software works in operations. It can be measured on:

• Budget
• Usability
• Efficiency
• Correctness
• Functionality
• Dependability
• Security
• Safety

Transitional
This aspect is important when the software is moved from one platform to another: Portability

• Interoperability
• Reusability
• Adaptability

Maintenance
This aspect briefs about how well a software has the capabilities to maintain itself in the everchanging environment:
Modularity Maintainability Flexibility Scalability In short, Software engineering is a branch of computer science,
which uses well-defined engineering concepts required to produce efficient, durable, scalable, in-budget and on-time
software product.

SOFTWARE DEVELOPMENT LIFE CYCLE LIFE CYCLE MODEL

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software
life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle
phases. It also captures the order in which these activities are to be undertaken. In other words, a life cycle model maps
the different activities performed on a software product from its inception to retirement. Different life cycle models may
map the basic development activities to phases in different ways. Thus, no matter which life cycle model is followed, the
basic activities are included in all life cycle models though the activities may be carried out in different orders in different
life cycle models. During any life cycle phase, more than one activity may also be carried out.
THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without
the use of a particular life cycle model, the development of a software product would not be in a systematic and
disciplined manner. When a software product is being developed by a team there must be a clear understanding among
team members about when and what to do. Otherwise, it would lead to chaos and project failure. This problem can be
illustrated by using an example. Suppose a software development problem is divided into several parts and the parts are
assigned to the team members. From then on, suppose the team members are allowed the freedom to develop the
parts assigned to them in whatever way they like. It is possible that one member might start writing the code for his
part, another might decide to prepare the test documents first, and some other engineer might begin with the design
phase of the parts assigned to him. This would be one of the perfect recipes for project failure. A software life cycle
model defines entry and exit criteria for every. A phase can start only if its phase-entry criteria have been satisfied. So,
without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life
cycle models, it becomes difficult for software project managers to monitor the progress of the project.

Different software life cycle models Many life cycle models have been proposed so far. Each of them has some
advantages as well as some disadvantages.

A few important and commonly used life cycle models are as follows:

• Classical Waterfall Model

• Iterative Waterfall Model
• Prototyping Model
• Evolutionary Model
• Spiral Model

1. CLASSICAL WATERFALL MODEL

The classical waterfall model is intuitively the most obvious way to develop software. Though the classical waterfall
model is elegant and intuitively obvious, it is not a practical model in the sense that it cannot be used in actual software
development projects. Thus, this model can be considered to be a theoretical way of developing software. But all other
life cycle models are essentially derived from the classical waterfall model. So, in order to be able to appreciate other life
cycle models it is necessary to learn the classical waterfall model. Classical waterfall model divides the life cycle into the
following phases as shown in fig.

Feasibility study - The main aim of feasibility study is to determine whether it would be financially and technically
feasible to develop the product.
 • At first project managers or team leaders try to have a rough understanding of what is required to be done by
visiting the client side. They study different input data to the system and output data to be produced by the
system. They study what kind of processing is needed to be done on these data and they look at the various
constraints on the behavior of the system.
• After they have an overall understanding of the problem, they investigate the different solutions that are
possible. Then they examine each of the solutions in terms of what kind of resources required, what would be
the cost of development and what would be the development time for each solution.
• Based on this analysis they pick the best solution and determine whether the solution is feasible financially and
technically. They check whether the customer budget would meet the cost of the product and whether they
have sufficient technical expertise in the area of development.

Requirements analysis and specification: - The aim of the requirements analysis and specification phase is to
understand the exact requirements of the customer and to document them properly. This phase consists of two distinct
activities, namely

• Requirements gathering and analysis

• Requirements specification

The goal of the requirement gathering activity is to collect all relevant information from the customer regarding the
product to be developed. This is done to clearly understand the customer requirements so that incompleteness and
inconsistencies are removed. The requirements analysis activity begins by collecting all relevant data regarding the
product to be developed from the users of the product and from the customer through interviews and discussions. For
example, to perform the requirements analysis of a business accounting software required by an organization, the
analyst might interview all the accountants of the organization to ascertain their requirements. The data collected from
such a group of users usually contains several contradictions and ambiguities, since each user typically has only a partial
and incomplete view of the system. Therefore, it is necessary to identify all ambiguities and contradictions in the
requirements and resolve them through further discussions with the customer. After all ambiguities, inconsistencies,
and incompleteness have been resolved and all the requirements properly understood, the requirements specification
activity can start. During this activity, the user requirements are systematically organized into a Software Requirements
Specification (SRS) document. The customer requirements identified during the requirements gathering and analysis
activity are organized into an SRS document. The important components of this document are functional requirements,
the nonfunctional requirements, and the goals of implementation.

Design: - The goal of the design phase is to transform the requirements specified in the SRS document into a structure
that is suitable for implementation in some programming language. In technical terms, during the design phase the
software architecture is derived from the SRS document. Two distinctly different approaches are available: the
traditional design approach and the object-oriented design approach.

• Traditional design approach -Traditional design consists of two different activities; first a structured analysis of
the requirements specification is carried out where the detailed structure of the problem is examined. This is
followed by a structured design activity. During structured design, the results of structured analysis are
transformed into the software design.
• Object-oriented design approach -In this technique, various objects that occur in the problem domain and the
solution domain are first identified, and the different relationships that exist among these objects are identified.
The object structure is further refined to obtain the detailed design.

Coding and unit testing: -The purpose of the coding phase (sometimes called the implementation phase) of software
development is to translate the software design into source code. Each component of the design is implemented as a
program module. The end-product of this phase is a set of program modules that have been individually tested. During
this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing
each module in isolation as this is the most efficient way to debug the errors identified at this stage.
Integration and system testing: -Integration of different modules is undertaken once they have been coded and unit
tested. During the integration and system testing phase, the modules are integrated in a planned manner. The different
modules making up a software product are almost never integrated in one shot. Integration is normally carried out
incrementally over a number of steps. During each integration step, the partially integrated system is tested, and a set of
previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested,
system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its
requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities:

• α – testing: It is the system testing performed by the development t team.

• β –testing: It is the system testing performed by a friendly set of customers.
• Acceptance testing: It is the system testing performed by the customer himself after the product delivery to
determine whether to accept or reject the delivered product.

System testing is normally carried out in a planned manner according to the system test plan document. The system test
plan identifies all testing-related activities that must be performed, specifies the schedule of testing, and allocates
resources. It also lists all the test cases and the expected outputs for each test case.

Maintenance: -Maintenance of a typical software product requires much more than the effort necessary to develop the
product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a
typical software product to its maintenance effort is roughly in the 40:60 ratios. Maintenance involves performing any
one or more of the following three kinds of activities:

• Correcting errors that were not discovered during the product development phase. This is called corrective
maintenance.
• Improving the implementation of the system and enhancing the functionalities of the system according to the
customer’s requirements. This is called perfective maintenance.
• Porting the software to work in a new environment. For example, porting may be required to get the software
to work on a new computer platform or with a new operating system. This is called adaptive maintenance.

2. ITERATIVE WATERFALL MODEL

To overcome the major shortcomings of the classical waterfall model, we came up with the iterative waterfall model.

Here, we provide feedback paths for error correction as & when detected later in a phase. Though errors are inevitable,
it is desirable to detect them in the same phase in which they occur. If so, this can reduce the effort to correct the bug.
The advantage of this model is that there is a working 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 us to take
corrective measures within 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.
3. PRTOTYPING MODEL
Prototype

A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low
reliability, and inefficient performance compared to the actual software. A prototype is usually built using several
shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. The shortcut implementation
of a function, for example, may produce the desired results by using a table look-up instead of performing the actual
computations. A prototype usually turns out to be a very crude version of the actual system.

Need for a prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports,
and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the
customer’s needs:

• how the screens might look like

• how the user interface would behave
• how the system would produce outputs

Another reason for developing a prototype is that it is impossible to get the perfect product at the first attempt. Many
researchers and engineers advocate that if you want to develop a good product you must plan to throw away the first
version. The experience gained in developing the prototype can be used to develop the final product.

A prototyping model can be used when technical solutions are unclear to the development team. A developed prototype
can help engineers to critically examine the technical issues associated with product development. Often, major design
decisions depend on issues like the response time of a hardware controller, or the efficiency of a sorting algorithm, etc.
In such circumstances, a prototype may be the best or the only way to resolve the technical issues. A prototype of the
actual product is preferred in situations such as:

• User requirements are not complete

• Technical issues are not clear.

4. EVOLUTIONARY MODEL
It is also called successive versions model or incremental model. At first, a simple working model is built. Subsequently it
undergoes functional improvements & we keep on adding new functions till the desired system is built.

Applications:

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

Advantages:

• User gets a chance to experiment partially developed system

• Reduce the error because the core modules get tested thoroughly.

Disadvantages:

• It is difficult to divide the problem into several versions that would be acceptable to the customer which can be
incrementally implemented & delivered.
5. SPIRAL MODEL
The Spiral model of software development is shown in fig.

The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the
spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop
might be concerned with feasibility study, the next loop with requirements specification, the next one with design, and
so on. Each phase in this model is split into four sectors (or quadrants) as shown in fig. 4.1. The following activities are
carried out during each phase of a spiral model.

First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.

• Examine the risks associated with these objectives. DEPT OF CSE & IT VSSUT, Burla

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.

• Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype
system may be developed.

Third Quadrant (Development and Validation)

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

Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration around the spiral.

• Progressively more complete versions of the software get built with each iteration around the spiral.

Circumstances to use spiral model

The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built
into this model. The spiral model is suitable for development of technically challenging software products that are prone
to several kinds of risks. However, this model is much more complex than the other models – this is probably a factor
deterring its use in ordinary projects.
Comparison of different life cycle models

The classical waterfall model can be considered as the basic model and all other life cycle models as embellishments of
this model. However, the classical waterfall model cannot be used in practical development projects, since this model
supports no mechanism to handle the errors committed during any of the phases. This problem is overcome in the
iterative waterfall model. The iterative waterfall model is probably the most widely used software development model
evolved so far. This model is simple to understand and use. However, this model is suitable only for well-understood
problems; it is not suitable for very large projects and for projects that are subject to many risks. The prototyping model
is suitable for projects for which either the user requirements or the underlying technical aspects are not well
understood. This model is especially popular for development of the user-interface part of the projects.

The evolutionary approach is suitable for large problems which can be decomposed into a set of modules for
incremental development and delivery. This model is also widely used for object-oriented development projects. Of
course, this model can only be used if the incremental delivery of the system is acceptable to the customer. The spiral
model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this
model. The spiral model is suitable for development of technically challenging software products that are prone to
several kinds of risks. However, this model is much more complex than the other models – this is probably a factor
deterring its use in ordinary projects. The different software life cycle models can be compared from the viewpoint of
the customer. Initially, customer confidence in the development team is usually high irrespective of the development
model followed. During the lengthy development process, customer confidence normally drops off, as no working
product is immediately visible. Developers answer customer queries using technical slang, and delays are announced.
This gives rise to customer resentment. On the other hand, an evolutionary approach lets the customer experiment with
a working product much earlier than the monolithic approaches. Another important advantage of the incremental
model is that it reduces the customer’s trauma of getting used to an entirely new system. The gradual introduction of
the product via incremental phases provides time to the customer to adjust to the new product. Also, from the
customer’s financial viewpoint, incremental development does not require a large upfront capital outlay. The customer
can order the incremental versions as and when he can afford them.

SYSTEM SOFTWARE COMPONENTS

Your system has three basic types of software: application programs, device drivers, and operating systems. Each type of
software performs a completely different job, but all three work closely together to perform useful work. While some
special-purpose programs do not fit neatly into any of these classes, most software does. Programs run in the memory
portion of the system. While running, programs are known as processes or jobs. The following illustration shows the
relationship between the different software programs and the hardware.

Application Programs
Application programs are the top software layer. You can perform specific tasks with these programs, such as using a
word processor for writing, a spreadsheet for accounting, or a computer-aided design program for drawing. The other
two layers, device drivers and the operating system, play important support roles. Your system might run one
application program at a time, or it might run many simultaneously.

Device Drivers
Device drivers are a set of highly specialized programs. Device drivers help application programs and the operating
system do their tasks. Device drivers (in particular, adapters), do not interact with you. They interact directly with
computer hardware elements and shield the application programs from the hardware specifics of computers.
Operating System
An operating system is a collection of programs that controls the running of programs and organizes the resources of a
computer system. These resources are the hardware components of the system, such as keyboards, printers, monitors,
and disk drives. Your AIX operating system comes with programs, called commands or utilities, that maintain your files,
send and receive messages, provide miscellaneous information about your system, and so on.

An application program relies on the operating system to perform many detailed tasks associated with the internal
workings of the computer. The operating system also accepts commands directly from you to manage files and security.
There are many extensions to the AIX operating system that allow you to customize your environment.

Root-User Processes
Root-user processes are programs that can be run only by a user with root authority. A system administrator has root
authority for all processes.

Root-user processes include:

• Read or write any object

• Call any system function
• Perform certain subsystem-control operations

When you are not allowed to run a command, the system displays a message saying you do not have the correct
permissions or you are not allowed to run that command. The system administrator may be the only person who can log
in as root on your system. The system administrator can also set you up to use particular commands, giving you some
control over processes.

SOFTWARE CRISIS

Software Crisis is a term used in computer science for the difficulty of writing useful and efficient computer
programs in the required time. The software crisis was due to using the same workforce, same methods, same
tools even though rapidly increasing in software demand, the complexity of software, and software
challenges. With the increase in the complexity of software, many software problems arise because existing
methods were insufficient. If we will use the same workforce, same methods, and same tools after the fast
increase in software demand, software complexity, and software challenges, then there arise some problems
like software budget problems, software efficiency problems, software quality problems, software managing
and delivering problem, etc. This condition is called a software crisis.
Causes of Software Crisis:
• The cost of owning and maintaining software was as expensive as developing the software
• At that time Projects were running over-time
• At that time Software was very inefficient
• The quality of the software was low quality
• Software often did not meet user requirements
• The average software project overshoots its schedule by half
• At that time Software was never delivered
• Non-optimal resource utilization.
• Difficult to alter, debug, and enhance.
• The software complexity is harder to change.
THE SOFTWARE ENGINEERING PROCESSES
The software engineering process is a set of activities carried out during a software product development.
These procedures ensure that the final product meets the client’s requirements specification. These tasks are
typically performed by software engineers and other experts. It’s also referred to as the software
development life cycle.
Some of the activities include software specification to ensure that the software’s functionality and constraints
are defined. It also includes software validation, in which engineers validate the software to ensure that it
adheres to the client’s requirements.
It also includes the software development process, which ensures that the software adheres to the blueprint
established by the client during the early stages. Finally, the software must evolve to meet the client’s ever-
changing needs.

Software engineering processes save money and time. When the development team adheres to the client’s
requirements and their own research, the risk of the project being rejected by the client at completion is
reduced. This would be a waste of resources and time. Here are some other benefits of software engineering
processes.

• Provides quick solutions. Ensuring that software engineering teams adhere to the process allows them
to clearly understand the requirements and provide updates to the customer as needed. They will also
identify potential issues earlier in the project and provide accurate estimates based on the client’s
business requirements. It identifies the issue and makes it easier to solve.
• Streamlines the process. When software engineering teams follow the process, they spend time
meeting with the client and developing the software idea in the early stages. During this time, the
team can go over the entire process and eliminate any steps that do not add value to the software
development process.
• Prevent issues during software development. Following the software engineering processes can help
to prevent problems from arising. For example, the end result may be unattainable if the client and the
software engineering team do not communicate effectively. The client must be involved in the process
from the start. When they collaborate, they can create software that meets and exceeds its intended
purpose.
Software engineering processes are divided into five stages, which must be completed in a specific order
unless special circumstances dictate otherwise. The stages include planning system analysis and design, coding
and development, testing, and implementation. When software engineering teams adhere to this progression,
they can create software that meets the client’s needs.
Planning
This phase begins with identifying the problem that the software is designed to solve and gathering the
necessary information to build it. It also entails going over all the available data and streamlining the entire
project. This is the most important phase because it eliminates potential problems that may arise later in the
project.
The software engineering team gathers information about what they need to proceed with and obtains a
detailed description of the software during this stage. It is crucial to obtain this information, so that project
managers do not waste resources on software that the client does not need.
When the software engineering team is better informed, they can avoid serious problems and take correct
steps to solve mistakes. This is why they conduct various interviews and surveys to ensure that they get both
user and client requirements.

System Analysis and Design

The system analysis stage comes next, and it includes a feasibility study on the client’s ideas to determine its
viability. The primary objective here is to view the software concept through the users’ eyes to avoid
developing software that does not adhere to general standards.

The design phase is the project’s official flag and it entails creating a fully developed software design. This
stage is where the design work is done so that the development stage can finish the work. While the design is
being worked on, the development process can be set in motion as the engineering team installs critical
systems and gathers the resources needed to make the process run smoothly.

Development
This stage kicks off the main software development process. The software engineering team begins by writing
code, establishing infrastructure, and starting the documentation process to demonstrate how the system
operates to others. At this point, the team collaborates with designers to ensure that the designs are
implemented. If a problem arises, they cooperate to find a solution.

The software engineering team builds the software using the wireframe in the second stage. They verify the
specifications and features and then put everything together. The initial steps become a reality at this point,
and they can begin testing and preparing the system for launch.
Testing
The testing stage begins after the development stage to ensure that the software works properly before being
released to the public. Hence, software quality assurance is performed. This team uses automated testers to
examine the software’s features to identify any issues.
The quality control department looks for code errors that could malfunction the software. Tests are
considered successful when the experts identify and correct flaws during tests. After that, they check for
errors repeatedly. If it passes the test, the software engineering team will implement it.
Implementation
After testing, the software will be prepared for release. This is the implementation stage. The teams
collaborate to resolve any issues that customers may encounter. They collect user feedback to determine
which issues should be addressed in the software. They are also open to updating ideas that would benefit
users.
The first users of the software are companies and clients that would adopt it when it is launched. As a result,
the software engineering team initiates a beta testing phase in which these companies test the software and
provide feedback.
If there are errors that were not detected during the testing stage, the software will be returned for repair.
After some time, the software will run without errors, and it will be ready to be released to the general public.
SOFTWARE QUALITY ATTRIBUTES
1. Adaptability
Adaptability can be defined as the case where a software system is assessed for interactive ability, and it
adapts every action performed on the application to be matching with the individual user’s needs. The
validation for adaptability is said to be passed when a possible issue in the software is captured and tested for
precision. On the other hand, one can say that it is not probable to foresee the wants of the types of users and
to point out the one finest system arrangement for the said situation. Hence, there comes a need for various
combinations of users and patterns of usage, to go with the existing functionality.
2. Compatibility
Compatibility is an important attribute to be validated for making the software system a high-quality product.
The term compatible can be explained as a scenario where more than one item can co-exist and function well
when connected with one another. The malfunctions here include the issues, the conflicts, the interferences,
etc., and these issues are not supposed to be occurring for a product to be of good quality.
3. Durability
Durability is an attribute typically verified upon the database system connected to the software application,
and it is performed as a part of the ACID property validation of the database management system. The ACID
here stands for Atomicity, Consistency, Isolation and finally, the Durability test, where the Durability attribute
is validated when a database transaction is declared or committed, the commit remains the same inside the
system. This is not changed even when there is a mishap on the database, like a server crash or data collapse.
4. Transparency
One of the most essential attributes to be checked for the Software Quality validation is the application’s
Transparency from the end-user point of view. These are not direct requirement specifications, instead it is
derived based on the tester’s observation. The observations are gathered over time, to form a list of scenarios
to keep the application transparent for usage. This aspect of the system is used for keeping the software to be
user friendly, so that the users can access the application without any guide from an external element.
5. Flexibility
Flexibility can be defined as a characteristic of high quality software, where the application has the capability
to act in response to latent changes that can affect the product value with respect to the requirement
specification provided. It is performed with a given time span, and a reasonable cost. It is confirmed by
watching the system response to ambiguous situations for the application to maintain its worth. Indecisive
functional flow can lead to many risks in terms of usability, security, performance, etc., and so the Flexibility of
the application is important to be met for the Software to have its quality assurance.
6. Efficiency

The Quality Assurance of a software application is very much dependent on the product’s efficiency, which can
also help with the system performance while being used by the designated user. It helps in evaluating the
software to the extent by which the various connected resources, such as the server memory, processing
capability, response time of every element, application navigation route, etc.

7. Robustness
Robustness can be defined as the software quality assurance aspect, which is used for evaluating the
application’s capacity to handle the errors that occur during execution. The testing for this is carried out by
entering a range of incorrect inputs, and recording the system’s reaction for each such input. This evaluation
can be applied on different areas of a computer, like the internal programming, the hardware works, security
features, the integrity of the systems, exception handling ability, error management ability, etc.
8. Scalability
Scalability of a Software application can be defined as the system facility where it allows the application to
accommodate an increasing amount of efforts, by keeping additional room for new incoming resources to the
software system. This increased task can be of any type, namely the data related contents like newly added
login/ user profile data to the database, newly connected integrated applications from other platforms, newly
added systems to the network connectivity, newly added functional elements to the user interface, newly
added web elements to the middleware applications, etc. This attribute of the software gives plenty of leeway
when the software is expected to have future goals for growth and expansion. This gives greater benefits in
terms of the cost spent for expansion, in addition to the other elements of the software.

9. Modularity
Lately, Modularity has become another essential attribute for software to be qualified to be of remarkable
quality, as it makes the software more flexible and adaptive to the incoming changes. Modularity can be
defined as a property that lets the software to be seen as a group of multiple smaller units of functional
elements, instead of being handled as one big unit. This attribute is preferred by most organizations, as in case
of any mishap, only the affected module needs to be fixed, and there is no need to look into other modules.

DIFFERENCE BETWEEN SOFTWARE ENGINEERING PROCESS AND CONVENTIONAL ENGINEERING

PROCESS :

S.No. Software Engineering Conventional Engineering

Process Process

Software Engineering Process is Conventional Engineering

a process which majorly Process is a process which
1. involves computer science, majorly involves science,
information technology and mathematics and empirical
discrete mathematics. knowledge.

It is mainly related with

It is about building cars,
computers, programming and
2. machines, hardware,
writing codes for building
buildings etc.
applications.

In Software Engineering Process In Conventional Engineering

3. construction and development Process construction and
cost is low. development cost is high.
 It can involve the application of It usually applies only known
4. new and untested elements in and tested principles to meet
software projects. product requirements.

In Software Engineering In Conventional Engineering

Process, most development Process, most development
5.
effort goes into building new efforts are required to change
designs and features. old designs.

It majorly emphasize on mass

6. It majorly emphasize on quality.
production.

Product development develops

Product development develops
7. tangible products (e.g. bridges,
intangible products (software)
buildings)

Design requirements may

Design Requirements are
8. change throughout
typically well-defined upfront
development process.

Testing is an integral part of the Testing occurs mainly after

9.
development process. product completion.

Prototyping is common and Prototyping is less common due

10.
helps to refine requirements. to cost and time

Maintenance and updates are

Maintenance is typically
11. necessary to keep software
scheduled or reactive.
relevant.

Software development often Conventional engineering may

12. involves complex logic and have more complex physical
algorithms. properties to deal with.

Software development often Conventional engineering may

13. follows established standards have well-established
and frameworks. regulations and standards.

Conventional engineering may

Software development is
14. be more expensive to start due
typically less expensive to start,
to materials and construction,
 but costs may increase with but may have lower
maintenance and updates. maintenance costs.

Agile methodologies are Conventional engineering may

15. commonly used in software use more traditional project
development. management approaches.