Software Engineering

So ware engineering is an engineering branch associated with development of so ware

product using well-de ned scien c principles, methods and procedures. The outcome of
so ware engineering is an e cient and reliable so ware product.

Software Characteristics
Functionality: Refers to the degree of performance of the software against its intended
purpose.
Reliability: Refers to the ability of the software to provide desired functionality under
the given conditions.
• Usability: Refers to the extent to which the software can be used with ease.
• Efficiency: Refers to the ability of the software to use system resources in the most
effective and efficient manner.
• Maintainability: Refers to the ease with which the modifications can be made in a
software system to extend its functionality, improve its performance, or correct errors.
• Portability: Refers to the ease with which software developers can transfer software
from one platform to another, without (or with minimum) changes. In simple terms, it
refers to the ability of software to function properly on different hardware and software
platforms without making any changes in it.
In addition to the above mentioned characteristics, robustness and integrity are also
important. Robustness refers to the degree to which the software can keep on
functioning in spite of being provided with invalid data while integrity refers to the
degree to which unaxuthorized access to the software or data can be prevented.

Feasibility Study
ft
ft
fi
ffi
ti
fi
ft
ft
feasibility study is performed by a company when they want to know whether a project is
possible given certain circumstances. Feasibility studies are undertaken under many
circumstances - to find out whether a company has enough money for a project, to find out
whether the product being created will sell, or to see if there are enough human resources for the
project. A good feasibility study will show the strengths and deficits before the project is planned
or budgeted for. By doing the research beforehand, companies can save money and resources in
the long run by avoiding projects that are not feasible.

· Technical Feasibility - Does the company have the technological resources to undertake the
project? Are the processes and procedures conducive to project success?
· Schedule Feasibility - Does the company currently have the time resources to undertake the
project? Can the project be completed in the available time?
· Economic Feasibility - Given the financial resources of the company, is the project something
that can be completed? The economic feasibility study is more commonly called the cost/benefit
analysis.
· Cultural Feasibility - What will be the impact on both local and general cultures? What sort
of environmental implications does the feasibility study have?
· Legal/Ethical Feasibility - What are the legal implications of the project? What sort of ethical
considerations are there? You need to make sure that any project undertaken will meet all legal
and ethical requirements before the project is on the table.
· Resource Feasibility - Do you have enough resources, what resources will be required, what
facilities will be required for the project, etc.
· Operational Feasibility - This measures how well your company will be able to solve
problems and take advantage of opportunities that are presented during the course of the project
· Marketing Feasibility - Will anyone want the product once its done? What is the target
demographic? Should there be a test run? Is there enough buzz that can be created for the
product?
· Real Estate Feasibility - What kind of land or property will be required to undertake the
project? What is the market like? What are the zoning laws? How will the business impact the
area?
 What is SDLC:
SDLC is a process followed for a so ware project, within a so ware organiza on. It consists of a detailed
plan describing how to develop, maintain, replace and alter or enhance speci c so ware.

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by
the senior members of the team with inputs from the customer, the sales department, market
surveys and domain experts in the industry. This information is then used to plan the basic
project approach and to conduct product feasibility study in the economical, operational and
technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the
project is also done in the planning stage.
Stage 2: De ining Requirements
Once the requirement analysis is done the next step is to clearly de ne and document the product
requirements and get them approved from the customer or the market analysts. This is done through an
SRS (So ware Requirement Speci ca on) document which consists of all the product requirements to
be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

This DDS is reviewed by all the important stakeholders and based on various parameters as risk
assessment, product robustness, design modularity, budget and time constraints, the best design
approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its
communication and data flow representation with the external and third party modules (if any).
ft
f
fi
ft
ti
ft
fi
ti
fi
ft
 Stage 4: Building or Developing the Product
evelopers must follow the coding guidelines de ned by their organiza on and programming tools like
compilers, interpreters, debuggers, etc. are used to generate the code. Di erent high level programming
languages such as C, C++, Pascal, Java and PHP are used for coding.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the tes ng ac vi es are
mostly involved in all the stages of SDLC. However, this stage refers to the tes ng only stage of the
product where product defects are reported, tracked, xed and retested, un l the product reaches the
quality standards de ned in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market.
Some mes product deployment happens in stages as per the business strategy of that organiza on. The
product may rst be released in a limited segment and tested in the real business environment (UAT-
User acceptance tes ng).

SWDLC Models
SWDLC -
Waterfall Model
The Waterfall Model was the rst Process Model to be introduced. It is also referred to as a linear-
sequen al 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.

Waterfall Model - Application

• Requirements are very well documented, clear and fixed.
ti
ti
fi
ti
fi
fi
fi
fi
ti
ff
ti
ti
ti
ti
ti
ti
 • Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
Waterfall Model – Advantages
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and
a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Waterfall Model – Disadvantages
The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.
 Prototype Model

In this process model, the system is par ally implemented before or during the analysis phase thereby
giving the customers an opportunity to see the product early in the life cycle. The process starts by
interviewing the customers and developing the incomplete high-level paper model. This document is
used to build the ini al prototype suppor ng only the basic func onality as desired by the customer.
Once the customer gures out the problems, the prototype is further re ned to eliminate them
fi
ti
ti
ti
ti
fi
he advantages of the Prototyping Model are as follows −
• Increased user involvement in the product even before its implementation.
• Since a working model of the system is displayed, the users get a better understanding of
the system being developed.
• Reduces time and cost as the defects can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily.
• Confusing or difficult functions can be identified.
The Disadvantages of the Prototyping Model are as follows −
• Risk of insufficient requirement analysis owing to too much dependency on the
prototype.
• Users may get confused in the prototypes and actual systems.
• Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
• Developers may try to reuse the existing prototypes to build the actual system, even when
it is not technically feasible.
• The effort invested in building prototypes may be too much if it is not monitored
properly.
 Evolu onary_Process_Model

The evolution model divides the development cycle into smaller, "Incremental Waterfall Model"
in which users are able to get access to the product at the end of each cycle.
ti
 The users provide feedback on the product for planning stage of the next cycle and the
development team responds, often by changing the product,plans or process.
These incremental cycles are typically two or four weeks in duration and continue until the
product is shipped.
• These models are more suited to object oriented systems.
• They are iterative in Process.
• They enable the software developer to develop increasingly more Complex versions of the
software.
• Like all Complex systems, software involve over period of the time and hence evolutionary
models are more suited to software development.
• Requirements gets changed while the software is under development.
Advantages of Evolu onary Model:-
Error reduc on: As the version is tested with customer which reduces the error throughlly.
User sa sfac on: User gets satisfied and he gets the full chance of experimenting partially
developed system.
Business bene t: Successful use of this model can benefit not only business result but marketing
and the internal operations as well.
High quality: As you should get satisfied with every version, it produces the high quality product.
Low risk: There is significant reduction of risk as a versions is implemented. This risk may be
associated with
• missing schedule deadline
• wrong feature sets
• poor quality
Reduc on Cost: Some design issues are cheaper to resolve through experimentation than through
analysis. It reduces cost by providing structured and disciplined avenue for experimentation.
Disadvantages of Evolu onary Model:-
Several version release: Developer has to make table version which increases their Efforts.
Dividing so ware: It is difficult to "divide the software and the problems in several versions that
would be acceptable to the customer which can be implemented and delivered incrementally.
Uncertain nature of customer needs: A confused user has uncertainty over his requirements, so
giving him several version may change his requirement Rapidly.
Time And Cost:As this model reduces "Time And Cost" but requirement is not gathered
correctly. It will subsequently time, cost and efforts.
ti
ti
ft
ti
ti
fi
ti
ti
Confusion by several version: An user might get "confused by several versions of the software.
It will affect on the final product.
Incremental Model
Characteristics of an Incremental module includes
• System development is broken down into many mini development projects
• Partial systems are successively built to produce a final total system
• Highest priority requirement is tackled first
• Once the incremented portion id developed, requirements for that increment are froze.
When to use Incremental models?
• Requirements of the system are clearly understood
• When demand for an early release of a product arises
• When software engineering team are not very well skilled or trained
• When high-risk features and goals are involved
• Such methodology is more in use for web application and product based companies

Advantages and Disadvantages of Incremental Model

Advantages Disadvantages
• The software will be generated quickly • It requires a good planning designing
during the software life cycle
• Problems might cause due to system
• It is flexible and less expensive to architecture as such not all
change requirements and scope requirements collected up front for the
entire software lifecycle
 • Thought the development stages • Each iteration phase is rigid and does
changes can be done not overlap each other
• Rectifying a problem in one unit
• This model is less costly compared to
requires correction in all the units and
others
consumes a lot of time
• A customer can respond to each
building
• Errors are easy to be identified

Spiral Model
The spiral model is similar to the incremental model, with more emphasis placed on risk analysis.
Planning, Risk Analysis, Engineering and Evalua on.

When to use Spiral model:

• When costs and risk evalua on is important
• For medium to high-risk projects
• Long-term project commitment unwise because of poten al changes to economic priori es
• Users are unsure of their needs
• Requirements are complex
• New product line
• Signi cant changes are expected (research and explora on)
Advantages of Spiral model:
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-cri cal projects.
• Strong approval and documenta on control.
• Addi onal Func onality can be added at a later date.
• So ware is produced early in the so ware life cycle.
Disadvantages of Spiral model:
• Can be a costly model to use.
• Risk analysis requires highly speci c exper se.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects
ft
ti
fi
ti
ti
ti
ti
fi
ft
ti
ti
ti
ti
ti
 WIN-WIN Spiral Model
The Win-Win spiral approach is an extension of the spiral approach. The phase in this approach is same
as the phase in the spiral approach. The only di erence is that at the me of the iden fying the
requirements, the development team and the customer hold discussion and nego ate on the
requirements that need to be included in the current itera on of the so ware.

The approach is called Win-Win because it is a winning situa on for the development team and also for
the customer. The customer wins by ge ng the product that ful ls most of the requirements while the
development team wins by delivering so ware which is developed with all the requirements established
a er nego a ons with the customer. The Win-Win approach is generally used when you have me-
bound releases.

Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.

• Good for large and mission-cri cal projects.
• Strong approval and documenta on control.
ft
ti
ti
ti
ti
tti
ft
ff
ti
ti
fi
ti
ft
ti
ti
ti
 • Addi onal Func onality can be added at a later date.
• So ware is produced early in the so ware life cycle.
Disadvantages of Spiral model:
• Can be a costly model to use.
• Risk analysis requires highly speci c exper se.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

Component of SRS

Completeness of specifications is difficult to achieve and even more difficult to verify.

Having guidelines about what different things an SRS should specify will help in
completely specifying the requirements. Here we describe some of the system properties
than an SRS should specify.

The basic issues an SRS must address

1. Functionality
2. Performance
3. Design constraints imposed on an implementation
4. External interfaces
ft
ti
ti
fi
ft
ti
Functional Requirements
1. Which outputs should be produced from the given inputs?
2. Relationship between the input and output.
3. A detailed description of all the data inputs and their source, the units of measure.
4. The range of valid inputs.
Design Constraints

1. Standards that must be followed.

2. Resource limits & operating environment.
3. Reliability
4. Security requirement
5. Policies that may have an impact on the design of the system.
Standards Compliance:

This specifies the requirements for the standards that the system must follow.
Hardware Limitations:

The software may have to operate on some existing or predetermined hardware thus
imposing restrictions on the design.
Reliability and Fault Tolerance:
Fault tolerance requirements can place a major constraint on how the system is to be
designed. Fault tolerance requirements often make the system more complex and
expensive.
Security:

Security requirements are particularly significant in defense systems and

many database systems. Security requirements place restrictions on the use of certain
commands, control access to data, provide different kinds of access requirements for
different people require the use of passwords and cryptography techniques and
maintain a log of activities in the system.

External Interface Requirements:

All the possible interactions of the software with people, hardware and other software
should be clearly specified. For the user interface, the characteristics of each user
interface of the software product should be specified. User interface is becoming
increasingly important and must be given proper attention. A preliminary user manual
should be created with all use commands, screen formats and explanation of how the
system will appear to the user, and feedback and error message.
Like other specifications these requirements should be precise and verifiable. So a
statement likes “the system should be no longer than six characters” or command names
should reflect the function they perform used. If the software is to execute on existing
hardware or on predetermined hardware, all the characteristics of the hardware,
including memory restrictions, should be specified. In addition, the current use and load
characteristics of the hardware should be given.

Difference between Verification and Validation

Commonly confused by the readers, the two hold a different meaning in context of software
testing as mentioned below:

Verification
• It is a process of assessing a software product during a particular development phase to
determine if it meets the requirements/ conditions specified at the beginning of that
particular phase.
• One of the most important phases of software development, verification is static and
includes substantiation of all the necessary documents, code, design and program.

• This phase includes all the activities that ensure the delivery of best quality product such
as design analysis, inspection and specification analysis.

• Some common methods of conducting verification are meetings, inspection and review.

Validation
• Validation is the process of testing a software product after its development process gets
completed

• It is conducted to determine whether a particular product meets the requirements that

were specified for the product
• It is a dynamic process that evaluates a product on parameters that help assess whether it
meets the expectations and requirements of the customers

• Some common methods of conducting validation are black box testing, white box
testing and gray box testing
Difference between Verification and Validation
Gaining an understanding of the difference between the two is important as this can help
ensure the development of the best quality software product.
1. Aim
The process of verification aims at confirming whether a particular product meets the
requirements specified at the beginning of the development phase. Whereas, the aim of
validation is to check whether the final product conforms to the set requirements and
standards.

2. Type of mechanism
Verification is a kind of static process that involves assessing of design, documents, program
and code. On the other hand, validation is a dynamic process that validates and tests the
quality of the final product.

3. Execution of code
Since verification is a static process, it does not involve execution of code. Whereas,
validation is a dynamic process that cannot be completed without implementing a code.

4. Scope of automation
Verification is a manual process that cannot be completed without intervention by a human.
On the other hand, validation is machine-dependent and can be completed solely using
computers.

5. Level
Verification is a low-level exercise that enables an easy identification of errors that cannot be
trapped using validation. On the other hand, validation is a high-level exercise that ensures
optimum product quality as well as easy identification of errors that often go unidentified
using process of verification.
6. Execution
The QA team is responsible to carry out the process of verification and ensure that the
software being developed is at par to the requirements specified in the document. On the
contrary, the process of validation is carried out by the testing team.

7. Hierarchy
The process of verification is to be completed before validation. Whereas, validation
generally follows after the process of verification.

8. Cost of errors
The errors caught during the process of verification leads to lesser cost and expenses to the
company as compared to the ones found during the process of validation.

9. Items evaluated
 The process of verification evaluates plans that were made for the product, requirements that
were specified, specifications related to design, test cases, etc. Whereas, validation enables
the evaluation of the product or software that has been developed by the team.

10. Target
Verification commonly targets on things like specifications, database design, architecture,
product design, etc. On the other hand, validation tests and targets things like product’s unit,
module, integrated modules and the final product.

OR

Veri ca on Valida on
• Verifying process includes • It is a dynamic mechanism of
checking documents, design, testing and validating the actual
code and program product
• It does not involve executing the • It always involves executing the
code code
• Verification uses methods like • It uses methods like Black Box
reviews, walkthroughs, Testing ,White Box Testing and
inspections and desk- checking non-functional testing
etc.
• Whether the software conforms • It checks whether software
to specification is checked meets the requirements and
expectations of customer
• It finds bugs early in the • It can find bugs that the
development cycle verification process can not
catch
• Target is application and • Target is actual product
software architecture,
specification, complete design,
high level and data base design
etc.
• QA team does verification and • With the involvement of testing
make sure that the software is team validation is executed on
as per the requirement in the software code.
SRS document.
• It comes before validation • It comes after verification
fi
ti
ti
• Validation: Are we building the right system?
• Verification: Are we building the system right?