I

Introduction to Software Engineering

1. Introduction to Software Engineering

Software Engineering is the process of designing, developing, testing, and maintaining
software. It is a systematic and disciplined approach to software development that aims to
create high-quality, reliable, and maintainable software.
1. Software engineering includes a variety of techniques, tools, and methodologies,
including requirements analysis, design, testing, and maintenance.
2. It is a rapidly evolving field, and new tools and technologies are constantly being
developed to improve the software development process.
3. By following the principles of software engineering and using the appropriate tools and
methodologies, software developers can create high-quality, reliable, and maintainable
software that meets the needs of its users.
4. Software Engineering is mainly used for large projects based on software systems
rather than single programs or applications.
5. The main goal of Software Engineering is to develop software applications for
improving quality, budget, and time efficiency.
6. Software Engineering ensures that the software that has to be built should be
consistent, correct, also on budget, on time, and within the required requirements.

2. Components of Software

There are three main components of the software:

1. Program: A computer program is a list of instructions that tell a computer what to do.
2. Documentation: Source information about the product contained in design
documents, detailed code comments, etc.
3. Operating Procedures: Set of step-by-step instructions compiled by an organization
to help workers carry out complex routine operations.

4. Software Characteristics
Software is defined as a collection of computer programs, procedures, rules, and data.
Software Characteristics are classified into major components. Software engineering is
the process of designing, developing, testing, and maintaining software.
1. Functionality: The software meets the requirements and specifications that it was
designed for, and it behaves as expected when it is used in its intended environment.
2. Usability: The software is easy to use and understand, and it provides a positive user
experience.
3. Reliability: The software is free of defects and it performs consistently and accurately
under different conditions and scenarios.
4. Performance: The software runs efficiently and quickly, and it can handle large
amounts of data or traffic.
5. Security: The software is protected against unauthorized access and it keeps the data
and functions safe from malicious attacks.
6. Maintainability: The software is easy to change and update, and it is well-
documented, so that it can be understood and modified by other developers.
7. Reusability: The software can be reused in other projects or applications, and it is
designed in a way that promotes code reuse.
8. Scalability: The software can handle an increasing workload and it can be easily
extended to meet the changing requirements.
9. Testability: The software is designed in a way that makes it easy to test and validate,
and it has a comprehensive test coverage.

5. What is 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, and same tools even though rapidly increasing software
demand, the complexity of software, and software challenges. With the increase in
software complexity, many software problems arose because existing methods were
insufficient.
Suppose we use the same workforce, same methods, and same tools after the fast
increase in software demand, software complexity, and software challenges. In that case,
there arise some issues like software budget problems, software efficiency
problems, software quality problems, software management, and delivery problems, etc.
This condition is called a Software Crisis.

4.1 Causes of Software Crisis

Following are the causes of Software Crisis:

 The cost of owning and maintaining software was as expensive as developing the
software.
 At that time Projects were running overtime.
 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.
 Challenging to alter, debug, and enhance.
 The software complexity is harder to change.
 Software Crisis

4.2 Factors Contributing to Software Crisis

Factor Contributing to Software Crisis are:

 Poor project management.
 Lack of adequate training in software engineering.
 Less skilled project members.
 Low productivity improvements.

4.3 Solution of Software Crisis

There is no single solution to the crisis. One possible solution to a software crisis
is Software Engineering because software engineering is a systematic, disciplined, and
quantifiable approach. For preventing software crises, there are some guidelines:
 Reduction in software over budget.
 The quality of the software must be high.
 Less time is needed for a software project.
 Experienced and skilled people working on the software project.
 Software must be delivered.
 Software must meet user requirements.

[Link] Engineering Processes

Software process (also knows as software methodology) is a set of related activities that
 leads to the production of the software. These activities may involve the development of
the software from the scratch, or, modifying an existing system. Any software process
must include the following four activities:
1. Software specification (or requirements engineering): Define the main
functionalities of the software and the constrains around them.
2. Software design and implementation: The software is to be designed and
programmed.
3. Software verification and validation: The software must conforms to it’s
specification and meets the customer needs.
4. Software evolution (software maintenance): The software is being modified to
meet customer and market requirements changes.
In practice, they include sub-activities such as requirements validation, architectural
design, unit testing, …etc. There are also supporting activities such as configuration and
change management, quality assurance, project management, user experience.

6. Similarity and Differences from Conventional Engineering

Processes:
Software Engineering Process and Conventional Engineering Process, both are
processes related to computers and development.
6.1 Software Engineering Process

Software Engineering Process is an engineering process that is mainly related to

computers and programming and developing different kinds of applications through
the use of information technology.

6.2 Conventional Engineering Process

Conventional Engineering Process is an engineering process that is highly based on

empirical knowledge and is about building cars, machines, and hardware. It is a process
that mainly involves science, mathematics, etc.
Conventional Engineering is related to computers, writing programs, and implementing
them.

6.3 Similarities Between Software Engineering Process and

Conventional Engineering Process
 Both Software Engineering and Conventional Engineering Processes become
automated after some time.
 Both these processes are making our day-to-day place better.
 Both these processes have a fixed working time.
 Both processes must consist of deeper knowledge.

Difference Between Software Engineering Process and Conventional

Engineering Process

Conventional Engineering
Aspect Software Engineering Process Process

Software Engineering Process is a The conventional Engineering

process that majorly involves Process is a process that majorly
Process computer science, information involves science, mathematics,
 Conventional Engineering
Aspect Software Engineering Process Process

technology, and discrete and empirical knowledge.

mathematics.

It is mainly related to computers, It is about building cars,

programming, and writing codes machines, hardware, buildings,
Focus Area for building applications. etc.

In Software Engineering Process In Conventional Engineering

construction and development Process construction and
Cost costs are low. development cost is high.

It can involve the application of It usually applies only known and

new and untested elements in tested principles to meet product
Application software projects. requirements.

In the Software Engineering In Conventional Engineering

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

It majorly emphasizes mass

It majorly emphasizes quality.
Emphasis production.

Product development develops

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

Design requirements may change

Design Requirements are
Design throughout the development
typically well-defined upfront.
Requirement process.

Testing is an integral part of the Testing occurs mainly after

Testing development process. product completion.

Prototyping is common and helps Prototyping is less common due

Prototyping to refine requirements. to cost and time.

Maintenance and updates are

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

Software development often Conventional engineering may

Complexity involves complex logic and have more complex physical
 Conventional Engineering
Aspect Software Engineering Process Process

algorithms. properties to deal with.

Software development often Conventional engineering may

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

Conventional engineering may be

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

Conventional engineering may

Agile methodologies are commonly
use more traditional project
used in software development.
Methodologies management approaches.

7. Software Quality Attributes: Software Quality shows how good and reliable a
product is. To convey an associate degree example, think about functionally correct
software. It performs all functions as laid out in the SRS document. But, it has an
associate degree virtually unusable program. Even though it should be functionally
correct, we tend not to think about it to be a high-quality product.
Another example is also that of a product that will have everything that the users need but
has an associate degree virtually incomprehensible and not maintainable code. Therefore,
the normal construct of quality as “fitness of purpose” for code merchandise isn’t
satisfactory.

7.1 Factors of Software Quality

The modern read of high-quality associates with software many quality factors like the
following:

1. Portability: A software is claimed to be transportable, if it may be simply created to

figure in several package environments, in several machines, with alternative code
merchandise, etc.
2. Usability: A software has smart usability if completely different classes of users (i.e.
knowledgeable and novice users) will simply invoke the functions of the merchandise.
3. Reusability: A software has smart reusability if completely different modules of the
merchandise will simply be reused to develop new merchandise.
4. Correctness: Software is correct if completely different needs as laid out in the SRS
document are properly enforced.
5. Maintainability: A software is reparable, if errors may be simply corrected as and
once they show up, new functions may be simply added to the merchandise, and
therefore the functionalities of the merchandise may be simply changed, etc
6. Reliability: Software is more reliable if it has fewer failures. Since software engineers
do not deliberately plan for their software to fail, reliability depends on the number and
type of mistakes they make. Designers can improve reliability by ensuring the software
 is easy to implement and change, by testing it thoroughly, and also by ensuring that if
failures occur, the system can handle them or can recover easily.
7. Efficiency. The more efficient software is, the less it uses of CPU-time, memory, disk
space, network bandwidth, and other resources. This is important to customers in
order to reduce their costs of running the software, although with today’s powerful
computers, CPU time, memory and disk usage are less of a concern than in years
gone by.

8. Software Development Life Cycle (SDLC)

Software development life cycle (SDLC) is a structured process that is used to

design, develop, and test good-quality software. SDLC, or software development life
cycle, is a methodology that defines the entire procedure of software development step-
by-step.

8.1 Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In this Waterfall model, typically, the outcome
of one phase acts as the input for the next phase sequentially.

The following illustration is a representation of the different phases of the Waterfall Model.
The sequential phases in Waterfall model are −

 Requirement Gathering and analysis − All possible requirements of the system to

be developed are captured in this phase and documented in a requirement
specification document.
 System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
 Implementation − With inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system
is tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To
fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the customer
environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model, phases do not overlap.

Waterfall Model - Application

 Requirements are very well documented, clear and fixed.

  Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.

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

8.1.2 Waterfall Model – Disadvantages:

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

8.2 Software Prototyping Model and Phases

software Prototyping Model is a software development methodology that involves creating

an initial prototype of the software product before developing the final product. The
prototype is a working model of the software product that can be used to gather feedback
and refine the design before the final product is developed. The prototyping model is
particularly useful for projects where the requirements are not well-defined or are likely to
change over time. The prototyping model can help to reduce the risk of developing a
software product that does not meet the needs of end-users or stakeholders, while also
reducing development time and cost.

8.2.1 Prototyping Model Phases:

Prototyping Model has six SDLC phases as follows

Step-1: Requirements gathering and analysis :
Requirement analysis is the first step in developing a prototyping model. During this
phase, the system’s desires are precisely defined. During the method, system users are
interviewed to determine what they expect from the system.
Step-2: Quick design :
The second phase could consist of a preliminary design or a quick design. During this
stage, the system’s basic design is formed. However, it is not a complete design. It
provides the user with a quick overview of the system. The rapid design aids in the
development of the prototype.
Step-3: Build a Prototype :
During this stage, an actual prototype is intended to support the knowledge gained from
quick design. It is a small low-level working model of the desired system.
Step-4: Initial user evaluation :
The proposed system is presented to the client for preliminary testing at this stage. It is
beneficial to investigate the performance model’s strengths and weaknesses. Customer
feedback and suggestions are gathered and forwarded to the developer.
Step-5: Refining prototype :
If the user is dissatisfied with the current model, you may want to improve the type that
responds to user feedback and suggestions. When the user is satisfied with the upgraded
model, a final system based on the approved final type is created.
Step-6: Implement Product and Maintain :
The final system was fully tested and distributed to production after it was developed to
support the original version. To reduce downtime and prevent major failures, the
programmer is run on a regular basis.

8.2.2 Advantages of Software Prototyping :

 Users help to shape the future. As a result, errors can be discovered during the first
stage of the software development process.
 Prototyping is also considered a risk reduction function because it allows non-existent
performance to be seen, lowering the risk of failure.
 Assists team members in effectively communicating.
 Customer satisfaction exists, and he can feel the product from the start.
 There will be no risk of software loss.
 Quick user feedback aids in the development of better software solutions.
8.2.3 Disadvantages of Software Prototyping :

 Prototyping is a time-consuming and labor-intensive process.

 The cost of creating a specific type of waste is completely wasted because the
prototype is eventually discarded.
 Prototyping may result in an overabundance of change requests.
 Customers may be unwilling to commit to the iteration cycle for an extended period of
time.
 During each customer test, there may be too many variations in software requirements.
 Poor documentation as a result of changing customer needs.

8.3 Spiral Model

The spiral model, initially proposed by Boehm, is an evolutionary software process model
that couples the iterative feature of prototyping with the controlled and systematic aspects of
the linear sequential model. It implements the potential for rapid development of new
versions of the software. Using the spiral model, the software is developed in a series of
incremental releases. During the early iterations, the additional release may be a paper
model or prototype. During later iterations, more and more complete versions of the
engineered system are produced.
Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is
located on the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking,
simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made
whether to continue with a further period of the spiral. If it is determined to keep, plans are
drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if performance or
user-interface risks are treated more essential than the program development risks, the next
phase may be an evolutionary development that includes developing a more detailed
prototype for solving the risks.

The risk-driven feature of the spiral model allows it to accommodate any mixture of a
specification-oriented, prototype-oriented, simulation-oriented, or another type of approach.
An essential element of the model is that each period of the spiral is completed by a review
that includes all the products developed during that cycle, including plans for the next cycle.
The spiral model works for development as well as enhancement projects.

8.3.1 When to use Spiral Model?

o When deliverance is required to be frequent.

o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

8.3.2 Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

8.3.3 Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

8.4 What is the Evolutionary Model?

The Evolutionary development model divides the development cycle into smaller,
incremental waterfall models in which users can get access to the product at the end of
each cycle.
1. Feedback is provided by the users on the product for the planning stage of the next
cycle and the development team responds, often by changing the product, plan, or
process.
2. Therefore, the software product evolves with time.
3. All the models have the disadvantage that the duration of time from the start of the
project to the delivery time of a solution is very high.
4. The evolutionary model solves this problem with a different approach.
5. The evolutionary model suggests breaking down work into smaller chunks, prioritizing
them, and then delivering those chunks to the customer one by one.
6. The number of chunks is huge and is the number of deliveries made to the customer.
7. The main advantage is that the customer’s confidence increases as he constantly gets
quantifiable goods or services from the beginning of the project to verify and validate
his requirements.
8. The model allows for changing requirements as well as all work is broken down into
maintainable work chunks.

Evolutionary Model

8.4.1 Application of Evolutionary Model

1. It is used in large projects where you can easily find modules for incremental
implementation. Evolutionary model is commonly used when the customer wants to
start using the core features instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software development because the
system can be easily portioned into units in terms of objects.
8.4.2 Necessary Conditions for Implementing this Model

1. Customer needs are clear and been explained in deep to the developer team.
2. There might be small changes required in separate parts but not a major change.
3. As it requires time, so there must be some time left for the market constraints.
4. Risk is high and continuous targets to achieve and report to customer repeatedly.
5. It is used when working on a technology is new and requires time to learn.

8.4.3 Advantages Evolutionary Model

1. Adaptability to Changing Requirements: Evolutionary models work effectively in

projects when the requirements are ambiguous or change often. They support
adjustments and flexibility along the course of development.
2. Early and Gradual Distribution: Functional components or prototypes can be
delivered early thanks to incremental development. Faster user satisfaction and
feedback may result from this.
3. User Commentary and Involvement: Evolutionary models place a strong emphasis
on ongoing user input and participation. This guarantees that the software offered
closely matches the needs and expectations of the user.
4. Improved Handling of Difficult Projects: Big, complex tasks can be effectively
managed with the help of evolutionary models. The development process is made
simpler by segmenting the project into smaller, easier-to-manage portions.

8.4.4 Disadvantages Evolutionary Model

1. Communication Difficulties: Evolutionary models require constant cooperation and

communication. The strategy may be less effective if there are gaps in communication
or if team members are spread out geographically.
2. Dependence on an Expert Group: A knowledgeable and experienced group that can
quickly adjust to changes is needed for evolutionary models. Teams lacking
experience may find it difficult to handle these model’s dynamic nature.
3. Increasing Management Complexity: Complexity can be introduced by organizing
and managing several increments or iterations, particularly in large projects. In order to
guarantee integration and synchronization, good project management is needed.
4. Greater Initial Expenditure: As evolutionary models necessitate continual testing,
user feedback and prototyping, they may come with a greater starting cost. This may
be a problem for projects that have limited funding.

8.5 What is the Iterative Enhancement Model?

Software development uses a dynamic and adaptable method called the iterative
enhancement Model. The iterative enhancement model encourages a software product’s
ongoing evolution and improvement. This methodology is noticeable due to its
concentration on adaptability, flexibility and change responsiveness. It makes it easier
for a product to evolve because it gives developers the freedom to progressively enhance
the software, making sure that it complies with evolving specifications, user demands, and
market demands. This helps products evolve more easily.
 Life-Cycle of Iterative Enhancement Model

The Iterative Enhancement Model creates an environment where development teams can
more effectively adjust to changing requirements by segmenting the software
development process into smaller, more manageable parts. Every iteration improves on
the one before it, adding new features and fixing problems found in earlier stages.
Members of the team, stakeholders and end users are encouraged to collaborate and
communicate continuously to make sure the software meets changing needs and
expectations. Until the software is finished being built, the iteration process is carried out,
which involves giving the user the increments.

8.5.1 Advantages of Iterative Enhancement Model

 Adaptation to changing requirements is made possible by its flexibility in accomodating

modifications and improvement during each iteration.
 Early software iterations provide clients with functional portions of the product,
facilitating prompt feedback and validation.
 Problems and risks can be identified and addressed early in the developement
process, reduces chances of issue for future stages.
 Feedback and constant client involvement are encouraged to make sure the finished
product lives up to user expectations.
 Every iteration is put through testing and improvement, leading to higher quality
product.

8.5.2 Disadvantages of Iterative Enhancement Model

 Especially in larger projects, managing several iterations at once can add complexity.
 Higher cost
 Due to constant changes, there may be delays in documentation, making it more
difficult to maintain comprehensive documentation.
 Continuous customer engagement may not be possible in all scenarios, which impacts
the effectiveness of the model.

8.5.3 Specific use cases where this model proves beneficial include
1. Mobile app developement: Updates and improvements are often needed for mobile
apps to stay current with new devices, operating system versions and user
preferences. By using an iterative process developers can release the beta versions of
their apps, get user feedback and then improve functionality of those iterations in
future release.
2. Web Application Development: The requirements for developing web applications
frequently change as a result of shifting user demand and advancements in
technology. The Iterative Enhancement Model makes it possible to developed features
incrementally and guaranteeing that the application can be modified to satisfy
changing user and market demands. In later iterations it also makes it easier to
incorporate new features based on input from users.
3. E-commerce Platforms: Developement in e-commerece field often involves constant
updates. Implementing an iterative approach enables the introduction of new
functionality.
 UNIT 2
Software Requirement Specifications (SRS)

1. Requirement Engineering

The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and

descriptive ‘System Requirements Specification’ document.

1.1 Requirement Engineering Process

It is a four step process, which includes –

 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation

Feasibility study

This feasibility study is focused towards goal of the organization. This study analyzes
whether the software product can be practically materialized in terms of implementation,
contribution of project to organization, cost constraints and as per values and objectives of
the organization. It explores technical aspects of the project and product such as usability,
maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should
be undertaken.

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the client
and end-users to know their ideas on what the software should provide and which features
they want the software to include.

Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from
various stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces,
speed of operation, response time of system, portability of software across various
platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations
etc.
SRS should come up with following features:

 User Requirements are expressed in natural language.

 Technical requirements are expressed in structured language, which is used inside
the organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this

document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost if not nipped in
the bud. Requirements can be checked against following conditions -

 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated

2. Requirement Elicitation Process

R equirement elicitation process can be depicted using the folloiwng diagram:

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

2.1 Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake
in the software system development.

There are various ways to discover requirements

Interviews

Interviews are strong medium to collect requirements. Organization may conduct several
types of interviews such as:

 Structured (closed) interviews, where every single information to gather is decided in

advance, they follow pattern and matter of discussion firmly.
 Non-structured (open) interviews, where information to gather is not decided in
advance, more flexible and less biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons across the table.
 Group interviews which are held between groups of participants. They help to
uncover any missing requirement as numerous people are involved.
Surveys

Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.

Questionnaires

A document with pre-defined set of objective questions and respective options is handed
over to all stakeholders to answer, which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Task analysis

Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied
and requirements of proposed system are collected.

Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a
great help to analyze general and specific requirements.

Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.

Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret
the features of intended software product. It helps giving better idea of requirements. If there
is no software installed at client’s end for developer’s reference and the client is not aware
of its own requirements, the developer creates a prototype based on initially mentioned
requirements. The prototype is shown to the client and the feedback is noted. The client
feedback serves as an input for requirement gathering.
Observation

Team of experts visit the client’s organization or workplace. They observe the actual
working of the existing installed systems. They observe the workflow at client’s end and how
execution problems are dealt. The team itself draws some conclusions which aid to form
requirements expected from the software.

3. Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development

project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source

4. Data Flow Diagrams

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where
data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communication tool between a system analyst and any person who plays a
part in the order that acts as a starting point for redesigning a system. The DFD is also
called as a data flow graph or bubble chart.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve any
order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box
in a DFD, suppress that urge! A diamond-shaped box is used in flow charts to
represents decision points with multiple exists paths of which the only one is taken.
This implies an ordering of events, which makes no sense in a DFD.
 4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in fig:

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data
store indicates that the data is stored which can be used at a later stage or by the other
processes in a different order. The data store can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs
or sink of system outputs.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact,
DFDs may be partitioned into levels that represent increasing information flow and
functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily
three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.

0-level DFDM
It is also known as fundamental system model, or context diagram represents the entire
software requirement as a single bubble with input and output data denoted by incoming
and outgoing arrows. Then the system is decomposed and described as a DFD with
multiple bubbles. Parts of the system represented by each of these bubbles are then
decomposed and documented as more and more detailed DFDs. This process may be
repeated at as many levels as necessary until the program at hand is well understood. It is
essential to preserve the number of inputs and outputs between levels, this concept is
called leveling by DeMacro. Thus, if bubble "A" has two inputs x 1 and x2 and one output y,
then the expanded DFD, that represents "A" should have exactly two external inputs and
one external output as shown in fig:

The Level-0 DFD, also called context diagram of the result management system is shown in
fig. As the bubbles are decomposed into less and less abstract bubbles, the corresponding
data flow may also be needed to be decomposed.

1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this

level, we highlight the main objectives of the system and breakdown the high-level process
of 0-level DFD into sub processes.
2-Level DFD

2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or
record the specific/necessary detail about the system's functioning .
 5. Entity-Relationship Diagrams

ER-modeling is a data modeling method used in software engineering to produce a

conceptual data model of an information system. Diagrams created using this ER-modeling
method are called Entity-Relationship Diagrams or ER diagrams or ERDs.

Purpose of ERD
o The database analyst gains a better understanding of the data to be contained in the
database through the step of constructing the ERD.
o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the database to users. In
particular, the ERD effectively communicates the logic of the database to users.

Components of an ER Diagrams
1. Entity

An entity can be a real-world object, either animate or inanimate, that can be merely
identifiable. An entity is denoted as a rectangle in an ER diagram. For example, in a school
database, students, teachers, classes, and courses offered can be treated as entities. All
these entities have some attributes or properties that give them their identity.

Entity Set

An entity set is a collection of related types of entities. An entity set may include entities with
attribute sharing similar values. For example, a Student set may contain all the students of a
school; likewise, a Teacher set may include all the teachers of a school from all faculties.
Entity set need not be disjoint.

2. Attributes

Entities are denoted utilizing their properties, known as attributes. All attributes have values.
For example, a student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot
be negative, etc.

There are four types of Attributes:

1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute

1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among the
entity set. For example, the roll_number of a student makes him identifiable among students.
There are mainly three types of keys:

1. Super key: A set of attributes that collectively identifies an entity in the entity set.
2. Candidate key: A minimal super key is known as a candidate key. An entity set may
have more than one candidate key.
3. Primary key: A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.

2. Composite attribute: An attribute that is a combination of other attributes is called a

composite attribute. For example, In student entity, the student address is a composite
attribute as an address is composed of other characteristics such as pin code, state,
country.

3. Single-valued attribute: Single-valued attribute contain a single value. For example,

Social_Security_Number.

4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a
multi-valued attribute. Multi-valued attributes are depicted by the double ellipse. For
example, a person can have more than one phone number, email-address, etc.
5. Derived attribute: Derived attributes are the attribute that does not exist in the physical
database, but their values are derived from other attributes present in the database. For
example, age can be derived from date_of_birth. In the ER diagram, Derived attributes are
depicted by the dashed ellipse.

3. Relationships

The association among entities is known as relationship. Relationships are represented by

the diamond-shaped box. For example, an employee works_at a department, a student
enrolls in a course. Here, Works_at and Enrolls are called relationships.
Relationship set

A set of relationships of a similar type is known as a relationship set. Like entities, a

relationship too can have attributes. These attributes are called descriptive attributes.

Degree of a relationship set

The number of participating entities in a relationship describes the degree of the

relationship. The three most common relationships in E-R models are:

1. Unary (degree1)
2. Binary (degree2)
3. Ternary (degree3)

1. Unary relationship: This is also called recursive relationships. It is a relationship

between the instances of one entity type. For example, one person is married to only one
person.

2. Binary relationship: It is a relationship between the instances of two entity types. For
example, the Teacher teaches the subject.

Ternary relationship: It is a relationship amongst instances of three entity types. In fig, the
relationships "may have" provide the association of three entities, i.e., TEACHER,
STUDENT, and SUBJECT. All three entities are many-to-many participants. There may be
one or many participants in a ternary relationship.
 In general, "n" entities can be related by the same relationship and is known as n-ary
relationship.

Cardinality
Cardinality describes the number of entities in one entity set, which can be
associated with the number of entities of other sets via relationship set.

Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity
of entity set B and vice versa. Let us assume that each student has only one
student ID, and each student ID is assigned to only one person. So, the
relationship will be one to one

Using Sets, it can be represented as:

One to many: When a single instance of an entity is associated with more than one
instances of another entity then it is called one to many relationships. For example, a client
can place many orders; a order cannot be placed by many customers.

Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than
one entity from entity set A. For example - many students can study in a single college, but
a student cannot study in many colleges at the same time.

Using Sets, it can be represented as:

Many to Many: One entity from A can be associated with more than one entity from B and
vice-versa. For example, the student can be assigned to many projects, and a project can
be assigned to many students.

Using Sets, it can be represented as:

6. Decision Table

A decision table is a good way to settle different combination inputs with their
corresponding outputs and is also called a cause-effect table.
1. The reason to call the cause-effect table is a related logical diagramming technique
called cause-effect graphing that is used to obtain the decision table.
2. The information represented in decision tables can also be represented as decision
trees or in a programming language using if-then-else and switch-case statements.

Importance of Decision Table

Decision tables are very helpful in test design techniques.

1. Helps testers to search effects of combinations: It helps testers to search the
effects of combinations of different inputs and other software states that must correctly
implement business rules.
2. Helps to start complex business rules: It provides a regular way of starting complex
business rules, that is helpful for developers as well as for testers.
3. Helps in the development process: It assists in the development process with the
developer to do a better job. Testing with all combinations might be impractical.
4. Used in testing: A decision table is basically an outstanding technique used in both
testing and requirements management.
5. Helps to prepare requirements: It is a structured exercise to prepare requirements
when dealing with complex business rules.
6. Helps to model complicated logic: It is also used to model complicated logic.
Decision Table in Test Designing
Blank Decision Table
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1
Condition 2
Condition 3
Condition 4
Decision Table: Combinations
CONDITIONS STEP 1 STEP 2 STEP 3 STEP 4
Condition 1 Y Y N N
Condition 2 Y N Y N
Condition 3 Y N N Y
Condition 4 N Y Y N

Advantages of Decision Table

1. Easy conversion of business flow to test case: Any complex business flow can be
easily converted into test scenarios and test cases using this technique.
2. Works iteratively: Decision tables work iteratively which means the table created at
the first iteration is used as input tables for the next tables. The iteration is done only if
the initial table is not satisfactory.
3. Simple to understand: Simple to understand and everyone can use this method to
design the test scenarios & test cases.
4. Provides complete test case coverage: It provides complete coverage of test cases
which helps to reduce the rework on writing test scenarios & test cases.
5. Guarantees every combination is considered: These tables guarantee that we
consider every possible combination of condition values. This is known as its
completeness property.

7. Software Requirement Specification (SRS) Document

The SRS document is reviewed by the testing person or a group of persons by using any
verification method (like peer reviews, walkthroughs, inspections, etc.). We may use
inspections due to their effectiveness and capability to produce good results. We may
conduct reviews twice or even more often. Every review will improve the quality of the
document but may consume resources and increase the cost of the software
development.
A checklist is a popular verification tool that consists of a list of critical information content
that a deliverable should contain. A checklist may also look for duplicate information,
missing information, unclear information, wrong information, etc. Checklists are used
during reviewing and may make reviews more structured and effective.

7.1 Elements of an SRS document checklist

A Software Requirement Specification (SRS) document is a vital component of software

development. It outlines the functional and non-functional requirements of the software
and serves as a reference for all stakeholders involved in the project. However, creating a
comprehensive and accurate SRS document can be a daunting task. That’s where an
SRS document checklist comes in handy.
 Elements of an SRS document checklist

 Purpose and Scope: The purpose and scope section of an SRS document should
provide a high-level overview of the software, its intended audience, and the problem it
solves. This section should also outline any constraints, assumptions, and
dependencies that may affect the software’s development.
 Functional Requirements: Functional requirements describe what the software should
do. These requirements should be specific, measurable, and testable. This section
should include details about the software’s features, user interface, and data
processing.
 Non-functional Requirements: Non-functional requirements describe how the
software should perform. These requirements should be measurable and testable. This
section should include details about the software’s performance, security, reliability,
and usability.
 System Architecture: The system architecture section should describe the high-level
design of the software. This section should include details about the software’s
components, interfaces, and data flow.
 Data Management: The data management section should describe how the software
will handle data. This section should include details about the software’s database, data
storage, and data backup and recovery processes.
 User Documentation: The user documentation section should describe how users will
interact with the software. This section should include details about the software’s user
interface, user manuals, and help documents.
 Testing Requirements
The testing requirements section should describe how the software will be tested. This
section should include details about the software’s test cases, test environment, and
test data.
 Acceptance Criteria: The acceptance criteria section should describe how the
software will be accepted by the stakeholders. This section should include details about
the software’s acceptance tests, validation criteria, and sign-off procedures.
 Project Timeline: The project timeline section should provide a timeline for the
software’s development. This section should include details about the software’s
milestones, deliverables, and deadlines.
 Stakeholder List: The stakeholder list section should identify all the stakeholders
involved in the project. This section should include details about each stakeholder’s
role, responsibilities, and contact information.

SRS document checklist

An SRS document checklist should address the following issues:

SRS document checklist

1. Correctness
 In the SRS document, every requirement stated in the document should correctly
represent an expectation from the proposed software.
 All applicable safety and security requirements must be identified.
 Also, all the inputs and outputs of each requirement are required and sufficient for the
specified processing.
2. Ambiguity
 The SRS document may contain some ambiguity in the software requirements.
 For example, If a requirement conveys more than one meaning of a thing, then it will be
a serious problem so, to avoid this ambiguity, every requirement must have a single
meaning only.
 Hence, the software requirement statement should be short, correct, precise, and clear.
The SRS document checklist must focus on ambiguous words to avoid ambiguity.
3. Completeness
 The SRS document should be complete in all aspects it must have all the important
functional requirements (like hardware faults, I/O errors, computational errors,
processing overload, buffer overflow, events failing to occur, etc.)
 Non-functional requirements needed for the software and this completeness of the SRS
document must be checked thoroughly through a checklist.
4. Consistency
 In the SRS document, the consistency of the document can be maintained if all the
stated requirements do not vary from the other stated requirements.
 Every object is referred to with a unique name and is defined by one set of
characteristics that are not in conflict with one another.
5. Verifiability
 In the SRS document, it is said to be verifiable, if and only if, every requirement stated
in the document is verifiable.
 The non-verifiable requirements include statements like ‘good interfaces’, ‘excellent
response time’, ‘usually’, ‘well’, etc, which should not be used.
 The requirements terminology like “shall”, “will”, “may”, etc. should be used. In the
document, we should only use measurable terms and must avoid all the indefinite
terms.
6. Traceability
 The SRS document can be traceable if the source of every requirement is defined
correctly as it may help in future development.
 Traceability may help to structure the document and should find a place in the design of
the checklist.
7. Feasibility
 In the SRS document, some of the requirements may not be feasible to implement due
to technical reasons or lack of resources so, those such requirements should be
identified and accordingly removed from the SRS document.
 A document checklist can also help us to find some other non-feasible requirements in
the software.

Advantages of SRS document

 Clarity: The SRS document provides an unambiguous description of the requirements,

which helps to reduce confusion and misinterpretation.
 Consistency: The SRS document provides a consistent and structured way to
document requirements, which helps to ensure that all requirements are covered.
 Traceability: The SRS document provides a traceable link between the requirements
and the final software product, which helps to ensure that all requirements have been
met.
 Validation: The SRS document can be used as a basis for validating the software,
which helps to ensure that the software meets the requirements.

Disadvantages of SRS document

 Time-consuming: Creating an SRS document can be time-consuming, especially if the

software system is complex and involves many stakeholders.
 Limited flexibility: Once the SRS document is created, it can be difficult to make
changes to it without affecting other parts of the document.
 Limited user involvement: If the SRS document is created before user involvement, it
may not reflect the actual needs and requirements of the users.
 Misinterpretation: Despite efforts to make the SRS document unambiguous, there
may still be some room for misinterpretation, which can lead to errors in the final
software product.

8. Software requirements specification and IEEE standards

The Institute of Electrical and Electronics Engineers publishes several dozen software
engineering standards, including IEEE Std 830-1998, "IEEE Recommended Practice for
Software Requirements Specifications." Standard 830, last revised in 1998, has since been
replaced by Standard ISO/IEC/IEEE 29148:2011, with an update in 2018.
Editor's note: IEEE 29148 covers the processes and information it recommends for a
software requirements specification (SRS) document, as well as its format. Use the
standard to understand what makes for a good software requirement, as well as how to
apply these requirements throughout the software's lifecycle. While it can be adopted
independently, IEEE 29148-2018 also includes information on how to work with standard
15288, a common framework of process descriptions related to systems' lifecycles, and
12207, a common framework for software lifecycle processes.
Like many IEEE standards for software engineering, Standard 830 includes guidance and
recommended approaches for specifying software requirements. It's not a complete tutorial
on requirements development, but it does contain some useful information. The bulk of the
text is a detailed suggested template for organizing the different kinds of requirements
information for a software product -- an SRS.
The heart of the SRS consists of descriptions of both functional and nonfunctional
requirements. The IEEE standard provides several suggestions of how to organize
functional requirements: by mode, user class, object, feature, stimulus, functional hierarchy
or combinations of these criteria. There is no single organizational approach that's best; use
whatever makes sense for your project.
 9. Software Quality Assurance (SQA) is simply a way to assure quality in the
software. It is the set of activities which ensure processes, procedures as well as
standards are suitable for the project and implemented correctly.
Software Quality Assurance is a process which works parallel to development of software. It
focuses on improving the process of development of software so that problems can be
prevented before they become a major issue. Software Quality Assurance is a kind of
Umbrella activity that is applied throughout the software process.
Software Quality Assurance has:
1. A quality management approach
2. Formal technical reviews
3. Multi testing strategy
4. Effective software engineering technology
5. Measurement and reporting mechanism
9.1 Major Software Quality Assurance Activities:

1. SQA Management Plan:

Make a plan for how you will carry out the sqa through out the project. Think
about which set of software engineering activities are the best for project. check
level of sqa team skills.

2. Set The Check Points:

SQA team should set checkpoints. Evaluate the performance of the project on the
basis of collected data on different check points.

3. Multi testing Strategy:

Do not depend on a single testing approach. When you have a lot of testing
approaches available use them.

4. Measure Change Impact:

The changes for making the correction of an error sometimes re introduces more
errors keep the measure of impact of change on project. Reset the new change to
change check the compatibility of this fix with whole project.

5. Manage Good Relations:

In the working environment managing good relations with other teams involved in
the project development is mandatory. Bad relation of sqa team with
programmers team will impact directly and badly on project. Don’t play politics.

Benefits of Software Quality Assurance (SQA):

1. SQA produces high quality software.

2. High quality application saves time and cost.
3. SQA is beneficial for better reliability.
4. SQA is beneficial in the condition of no maintenance for a long time.
5. High quality commercial software increases the market share of company.
6. Improving the process of creating software.
7. Improves the quality of the software.

Disadvantage of Software Quality Assurance (SQA)

There are a number of disadvantages of quality assurance.

 Cost: Some of them include adding more resources, which cause the more budget its
not, Addition of more resources For betterment of the product.
 Time Consuming: Testing and Deployment of the project taking more time which
cause delay in the project.
 Overhead : SQA processes can introduce administrative overhead, requiring
documentation, reporting, and tracking of quality metrics. This additional administrative
burden can sometimes outweigh the benefits, especially for smaller projects.
 Resource Intensive : SQA requires skilled personnel with expertise in testing
methodologies, tools, and quality assurance practices. Acquiring and retaining such
talent can be challenging and expensive.
 Resistance to Change : Some team members may resist the implementation of SQA
processes, viewing them as bureaucratic or unnecessary. This resistance can hinder
the adoption and effectiveness of quality assurance practices within an organization.
 Not Foolproof : Despite thorough testing and quality assurance efforts, software can
still contain defects or vulnerabilities. SQA cannot guarantee the elimination of all bugs
or issues in software products.
 Complexity : SQA processes can be complex, especially in large-scale projects with
multiple stakeholders, dependencies, and integration points. Managing the complexity
of quality assurance activities requires careful planning and coordination.

10. Verification and Validation in Software Engineering

Verification: Verification is the process of checking that software achieves its goal
without any bugs. It is the process to ensure whether the product that is developed is
right or not. It verifies whether the developed product fulfills the requirements that we
have. Verification is simply known as Static Testing .

Static Testing
Verification Testing is known as Static Testing and it can be simply termed as checking
whether we are developing the right product or not and also whether our software is
fulfilling the customer’s requirement or not.

Validation

Validation is the process of checking whether the software product is up to the mark or in
other words product has high-level requirements. It is the process of checking the
validation of the product i.e. it checks what we are developing is the right product. it is a
validation of actual and expected products. Validation is simply known as Dynamic
Testing.
Dynamic Testing
Validation Testing is known as Dynamic Testing in which we examine whether we have
developed the product right or not and also about the business needs of the client. Here
are some of the activities that are involved in Validation.
1. Black Box Testing
2. White Box Testing
3. Unit Testing
4. Integration Testing

11. Software Quality Framework :- It is a model for software quality by

connecting and integrating the different views of software quality. This framework
connects the customer view with the developer view of software quality and it treats
software as a product. The software product view describes the characteristics of a
product that bear on its ability to satisfy stated and implied needs.
This is a framework that describes all the different concepts relating to quality in a common
way measured by qualitative scale that can be understood and interpreted in a common
way. Therefore the most influential factor for the developers is the customer perception.
This framework connects the developer with the customer to derive a common interpretation
for quality.

1. Developers View:
Validation and verification are two independent methods used together for
checking that a software product meets the requirements and that it fulfills its
intended [Link] checks that the product design satisfies the
purposeful usage and verification checks for errors in the software. The primary
concern for developers is in the design and engineering processes involved in
producing software. Quality can be measured by the degree of conformance to
predetermined requirements and standards, and deviations from these standards
can lead to poor quality and low reliability. While validation and verification are
used by the developers to improve the software, the two methods don’t represent
a quantifiable quality measurement.
The developer view of software quality and customer view of software quality are
both different things.

For example the customer understands or describes the quality of operation as

meeting the requirement while the developers use different factors to describe the
software quality.
The developer view of quality in the software is influenced by many factors.
This model stresses on 3 primary ones:
1. The code:
It is measured by its correctness and reliability.
2. The data:
It is measured by the application integrity.
3. Maintainability:
It has different measures, the simplest is the mean time to change.
2. Users View:
When the user acquires software, he/she always expect a high-quality software.
When end users develop their software then quality is different. End-user
programming, a phrase popularized by which is programming to achieve the
result of a program primarily for personal, rather than public use. The important
distinction here is that software itself is not primarily intended for use by a large
number of users with varying needs.

For example, a teacher may write a spreadsheet to track students' test scores. In
these end-user programming situations, the program is a means to an end that
could be used to accomplish a goal. In contradiction to end-user programming,
professional programming has the goal of producing software for others to use.

For example, the moment a novice Web developer moves from designing a web
page for himself to designing a Web page for others, the nature of this activity has
changed.
Users find software quality as a fit between their goals and software’s
functionality. The better the quality, the more likely the user will be satisfied with
the soft-ware. When the quality is bad, developers must meet user needs or face
a diminishing demand for their software. Therefore, the user understands quality
as fitness for purpose. Avoiding complexity and keeping software simple
considerably lessens the implementation risk of [Link] some instances,
 users abandoned the implementation of a complex software because the software
developers were expecting the users to change their business and to go with the
way the software works.

3. Product View:
The product view describes quality as correlated to inherent characteristics of the
product. Product quality is defined as the set of characteristics and features of a
product that gives contribution to its ability to fulfill given requirements. Product
quality can be measured by the value-based view which sees the quality as
dependent on the amount a customer is willing to pay for it. According to the
users, a high-quality product is one that satisfies their expectations and
preferences while meeting their requirements. Satisfaction of end users of the
product represents craft to learn, use, upgrade the product and when asked to
participate in rating the product, a positive rating is given.

12. ISO 9000 Certification

ISO (International Standards Organization) is a group or consortium of 63 countries
established to plan and fosters standardization. ISO declared its 9000 series of standards in
1987. It serves as a reference for the contract between independent parties. The ISO 9000
standard determines the guidelines for maintaining a quality system. The ISO standard
mainly addresses operational methods and organizational methods such as responsibilities,
reporting, etc. ISO 9000 defines a set of guidelines for the production process and is not
directly concerned about the product itself.

Types of ISO 9000 Quality Standards

The ISO 9000 series of standards is based on the assumption that if a proper stage is
followed for production, then good quality products are bound to follow automatically. The
types of industries to which the various ISO standards apply are as follows.

1. ISO 9001: This standard applies to the organizations engaged in design,

development, production, and servicing of goods. This is the standard that applies to
most software development organizations.
2. ISO 9002: This standard applies to those organizations which do not design products
but are only involved in the production. Examples of these category industries
contain steel and car manufacturing industries that buy the product and plant designs
from external sources and are engaged in only manufacturing those products.
Therefore, ISO 9002 does not apply to software development organizations.
3. ISO 9003: This standard applies to organizations that are involved only in the
installation and testing of the products. For example, Gas companies.

How to get ISO 9000 Certification?

An organization determines to obtain ISO 9000 certification applies to ISO registrar office for
registration. The process consists of the following stages:

1. Application: Once an organization decided to go for ISO certification, it applies to

the registrar for registration.
2. Pre-Assessment: During this stage, the registrar makes a rough assessment of the
organization.
3. Document review and Adequacy of Audit: During this stage, the registrar reviews
the document submitted by the organization and suggest an improvement.
4. Compliance Audit: During this stage, the registrar checks whether the organization
has compiled the suggestion made by it during the review or not.
5. Registration: The Registrar awards the ISO certification after the successful
completion of all the phases.
6. Continued Inspection: The registrar continued to monitor the organization time by
time.

13. Software Engineering | Capability maturity model

(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. All the levels except level-
1 are further described by Key Process Areas (KPA’s).

13.1 Shortcomings of SEI/CMM:

 It encourages the achievement of a higher maturity level in some cases by
displacing the true mission, which is improving the process and overall software
quality.
 It only helps if it is put into place early in the software development process.
 It has no formal theoretical basis and in fact is based on the experience of very
knowledgeable people.
 It does not have good empirical support and this same empirical support could
also be constructed to support other models.

Key Process Areas (KPA’s): Each of these KPA’s defines the basic
requirements that should be met by a software process in order to satisfy
the KPA and achieve that level of maturity.

Conceptually, key process areas form the basis for management control of
the software project and establish a context in which technical methods are
applied, work products like models, documents, data, reports, etc. are
produced, milestones are established, quality is ensured and change is
properly managed .
 The 5 levels of CMM are as follows:

Level-1: Initial –
 No KPIs defined.
 Processes followed are Ad Hoc and immature and are not well defined.
 Unstable environment for software development.
 No basis for predicting product quality, time for completion, etc.

Level-2: Repeatable –
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar natured
projects.
 Project Planning- It includes defining resources required, goals, constraints, etc.
for the project. It presents a detailed plan to be followed systematically for the
successful completion of good quality software.
 Configuration Management- The focus is on maintaining the performance of the
software product, including all its components, for the entire lifecycle.
  Requirements Management- It includes the management of customer reviews
and feedback which result in some changes in the requirement set. It also
consists of accommodation of those modified requirements.
 Subcontract Management- It focuses on the effective management of qualified
software contractors i.e. it manages the parts of the software which are developed
by third parties.
 Software Quality Assurance- It guarantees a good quality software product by
following certain rules and quality standard guidelines while developing.

Level-3: Defined –
 At this level, documentation of the standard guidelines and procedures takes
place.
 It is a well-defined integrated set of project-specific software engineering and
management processes.
 Peer Reviews- In this method, defects are removed by using a number of review
methods like walkthroughs, inspections, buddy checks, etc.
 Intergroup Coordination- It consists of planned interactions between different
development teams to ensure efficient and proper fulfillment of customer needs.
 Organization Process Definition- Its key focus is on the development and
maintenance of the standard development processes.
 Organization Process Focus- It includes activities and practices that should be
followed to improve the process capabilities of an organization.
 Training Programs- It focuses on the enhancement of knowledge and skills of the
team members including the developers and ensuring an increase in work
efficiency.

Level-4: Managed –
 At this stage, quantitative quality goals are set for the organization for software
products as well as software processes.
 The measurements made help the organization to predict the product and
process quality within some limits defined quantitatively.
 Software Quality Management- It includes the establishment of plans and
strategies to develop quantitative analysis and understanding of the product’s
quality.
 Quantitative Management- It focuses on controlling the project performance in a
quantitative manner.

Level-5: Optimizing –
 This is the highest level of process maturity in CMM and focuses on continuous
process improvement in the organization using quantitative feedback.
 Use of new tools, techniques, and evaluation of software processes is done to
prevent recurrence of known defects.
 Process Change Management- Its focus is on the continuous improvement of the
organization’s software processes to improve productivity, quality, and cycle time
for the software product.
 Technology Change Management- It consists of the identification and use of new
technologies to improve product quality and decrease product development time.
 Defect Prevention- It focuses on the identification of causes of defects and
prevents them from recurring in future projects by improving project-defined
processes.
 Unit 3
Software Design

1. Software Design
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.
For assessing user requirements, an SRS (Software Requirement Specification) document
is created whereas for coding and implementation, there is a need of more specific and
detailed requirements in software terms. The output of this process can directly be used into
implementation in programming languages.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.

Software Design Levels

Software design yields three levels of results:
 Architectural Design - The architectural design is the highest abstract version
of the system. It identifies the software as a system with many components
interacting with each other. At this level, the designers get the idea of
proposed solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple
component’ concept of architectural design into a less-abstracted view of
subsystems and modules and depicts their interaction with each other. High-
level design focuses on how the system along with all of its components can
be implemented in forms of modules. It recognizes the modular structure of
each sub-system and their relation and interaction among each other.
 Detailed Design or Low level Design- Detailed design deals with the
implementation part of what is seen as a system and its sub-systems in the
previous two designs. It is more detailed towards modules and their
implementations. It defines the logical structure of each module and their
interfaces to communicate with other modules.

1.1 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 reused again
 Concurrent execution can be made possible
 Desired from security aspect

1.2 Structure Charts

Structure Chart represents the hierarchical structure of modules. It breaks down the
entire system into the lowest functional modules and describes the functions and
sub-functions of each module of a system in greater detail.

Symbols in Structured Chart

1. Module
It represents the process or task of the system. It is of three types:

 Control Module: A control module branches to more than one submodule.

 Sub Module: Sub Module is a module which is the part (Child) of another module.
 Library Module: Library Module are reusable and invokable from any module.

2. Conditional Call
It represents that control module can select any of the sub module on the basis of some
condition.
 3. Loop (Repetitive call of module)
It represents the repetitive execution of module by the sub module. A curved arrow
represents a loop in the module.

All the sub modules cover by the loop repeat execution of module .

4. Data Flow
It represents the flow of data between the modules. It is represented by a directed arrow
with an empty circle at the end.
 5. Control Flow
It represents the flow of control between the modules. It is represented by a directed arrow
with a filled circle at the end.

7. Physical Storage
It is that where all the information are to be stored.

Example
Structure chart for an Email server
 1.3 Pseudo Code
A Pseudocode is defined as a step-by-step description of an algorithm. Pseudocode does
not use any programming language in its representation instead it uses the simple English
language text as it is intended for human understanding rather than machine reading.
Pseudocode is the intermediate state between an idea and its
implementation(code) in a high-level language.

What is the need for Pseudocode

Pseudocode is an important part of designing an algorithm, it helps the programmer in
planning the solution to the problem as well as the reader in understanding the approach
to the problem. Pseudocode is an intermediate state between algorithm and program that
plays supports the transition of the algorithm into the program.

Pseudocode is an intermediate state between algorithm and program

Example:
This program will print first N numbers of Fibonacci series.
 Use standard programming structures such as if-else, for, while, and cases the way
we use them in programming. Indent the statements if-else, for, while loops as they are
indented in a program, it helps to comprehend the decision control and execution
mechanism. It also improves readability to a great extent.
Example:
IF “1”
print response
“I AM CASE 1”
IF “2”
print response
“I AM CASE 2”
 Use appropriate naming conventions. The human tendency follows the approach of
following what we see. If a programmer goes through a pseudo code, his approach will
be the same as per that, so the naming must be simple and distinct.
 Reserved commands or keywords must be represented in capital letters.
Example: if you are writing IF…ELSE statements then make sure IF and ELSE be in
 capital letters.
 Check whether all the sections of a pseudo code are complete, finite, and clear to
understand and comprehend. Also, explain everything that is going to happen in the
actual code.
 Don’t write the pseudocode in a programming language. It is necessary that the
pseudocode is simple and easy to understand even for a layman or client, minimizing
the use of technical terms.

1.4 Flowchart
Flowchart is a diagrammatic representation of sequence of logical steps of a program.
Flowcharts use simple geometric shapes to depict processes and arrows to show
relationships and process/data flow.

Flowchart Symbols

Here is a chart for some of the common symbols used in drawing flowcharts.

Symbol Symbol Name Purpose

Used at the beginning and end of the
Start/Stop algorithm to show start and end of the
program.

Indicates processes like mathematical

Process
operations.

Used for denoting program inputs and

Input/ Output
outputs.

Stands for decision statements in a

Decision program, where answer is usually
Yes or No.

Shows relationships between different

Arrow
shapes.

Connects two or more parts of a

On-page Connector flowchart, which are on the same
page.

Connects two parts of a flowchart

Off-page Connector which are spread over different
pages.

Guidelines for Developing Flowcharts

These are some points to keep in mind while developing a flowchart −

  Flowchart can have only one start and one stop symbol
 On-page connectors are referenced using numbers
 Off-page connectors are referenced using alphabets
 General flow of processes is top to bottom or left to right
 Arrows should not cross each other

Example

Here is a flowchart to calculate the average of two numbers.

2. Coupling and Cohesion

When a software program is modularized, its tasks are divided into several modules based
on some characteristics. As we know, modules are set of instructions put together in order
to achieve some tasks. They are though, considered as single entity but may refer to each
other to work together. There are measures by which the quality of a design of modules and
their interaction among them can be measured. These measures are called coupling and
cohesion.

Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module. The greater the cohesion, the better is the program design.
There are seven types of cohesion, namely –
  Co-incidental cohesion - It is unplanned and random cohesion, which might be
the result of breaking the program into smaller modules for the sake of
modularization. Because it is unplanned, it may serve confusion to the
programmers and is generally not-accepted.
 Logical cohesion - When logically categorized elements are put together into a
module, it is called logical cohesion.
 Temporal Cohesion - When elements of a module are organized such that
they are processed at a similar point in time, it is called temporal cohesion.
 Procedural cohesion - When elements of a module are grouped together,
which are executed sequentially in order to perform a task, it is called
procedural cohesion.
 Communicational cohesion - When elements of a module are grouped
together, which are executed sequentially and work on the same data
(information), it is called communicational cohesion.
 Sequential cohesion - When elements of a module are grouped because the
output of one element serves as input to another and so on, it is called
sequential cohesion.
 Functional cohesion - It is considered to be the highest degree of cohesion,
and it is highly expected. Elements of module in functional cohesion are
grouped because they all contribute to a single well-defined function. It can
also be reused.

Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a
program. It tells at what level the modules interfere and interact with each other. The lower
the coupling, the better the program.
There are five levels of coupling, namely -
 Content coupling - When a module can directly access or modify or refer to the
content of another module, it is called content level coupling.
 Common coupling- When multiple modules have read and write access to
some global data, it is called common or global coupling.
 Control coupling- Two modules are called control-coupled if one of them
decides the function of the other module or changes its flow of execution.
 Stamp coupling- When multiple modules share a common data structure and
work on different parts of it, it is called stamp coupling.
 Data coupling- Data coupling is when two modules interact with each other by
means of passing data (as parameter). If a module passes data structure as
parameter, then the receiving module should use all its components.

Ideally, no coupling is considered to be the best.

Design Verification
The output of software design process is design documentation, pseudo codes, detailed
logic diagrams, process diagrams, and detailed description of all functional or non-functional
requirements.
The next phase, which is the implementation of software, depends on all outputs mentioned
above.
It then becomes necessary to verify the output before proceeding to the next phase. The
earlier any mistake is detected, the better it is or it might not be detected until testing of the
product. If the outputs of the design phase are in formal notation form, then their associated
tools for verification should be used otherwise a thorough design review can be used for
verification and validation.
By structured verification approach, reviewers can detect defects that might be caused by
overlooking some conditions. A good design review is important for good software design,
accuracy and quality.
Differences between Coupling and Cohesion

The differences between cohesion and coupling are given below:

Aspect Cohesion Coupling

Coupling refers to the degree of

Cohesion refers to the degree interdependence between software
to which elements within a modules. High coupling means that
module work together to fulfill modules are closely connected and
a single, well-defined purpose. changes in one module may affect
Definition other modules.

Module Cohesion is the concept of an Coupling is the concept of inter-

Dependency intro-module. module.

Cohesion represents the Coupling represents the relationships

Purpose relationship within a module. between modules.

Increasing cohesion is good Increasing coupling is avoided for

Quality for software. software.

Cohesion represents the

Coupling represents the independence
functional strength of
among modules.
Focus modules.

Highly cohesive gives the best Whereas loosely coupling gives the
Relationship software. best software.

In cohesion, the module In coupling, modules are connected to

Example focuses on a single thing. the other modules.

Cohesion is created between Coupling is created between two

Creation the same module. different modules.

Types of Cohesion Types of Coupling

1. Functional Cohesion. 1. Data Coupling
2. Procedural Cohesion. 2. Stamp Coupling
3. Temporal Cohesion. 3. Control Coupling
4. Sequential Cohesion. 4. External Coupling
5. Layer Cohesion. 5. Common Coupling
Types 6. Communication Cohesion. 6. Content Coupling
In software engineering, the coupling is the degree of interdependence between software
modules. Two modules that are tightly coupled are strongly dependent on each other.
However, two modules that are loosely coupled are not dependent on each other.
Uncoupled modules have no interdependence at all within them.
The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of
relations between the modules. That is, the coupling increases as the number of calls
between modules increase or the amount of shared data is large. Thus, it can be said that a
design with high coupling will have more errors.
Cohesion is an ordinal type of measurement and is generally described as "high cohesion"
or "low cohesion."
3. Software design Strategies
Software design is a process to conceptualize the software requirements into software
implementation. Software design takes the user requirements as challenges and tries to find
optimum solution. While the software is being conceptualized, a plan is chalked out to find
the best possible design for implementing the intended solution.
There are multiple variants of software design. Let us study them briefly:

Structured Design
Structured design is a conceptualization of problem into several well-organized elements of
solution. It is basically concerned with the solution design. Benefit of structured design is, it
gives better understanding of how the problem is being solved. Structured design also
makes it simpler for designer to concentrate on the problem more accurately.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem is
broken into several small problems and each small problem is individually s olved until the
whole problem is solved.
The small pieces of problem are solved by means of solution modules. Structured design
emphasis that these modules be well organized in order to achieve precise solution.
These modules are arranged in hierarchy. They communicate with each other. A good
structured design always follows some rules for communication among multiple modules,
namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.

3.1 Function Oriented Design

In function-oriented design, the system is comprised of many smaller sub-systems known
as functions. These functions are capable of performing significant task in the system. The
system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide and
conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which provides
means of abstraction by concealing the information and their operation.. These functional
modules can share information among themselves by means of information passing and
using information available globally.
Another characteristic of functions is that when a program calls a function, the function
changes the state of the program, which sometimes is not acceptable by other modules.
Function oriented design works well where the system state does not matter and
program/functions work on input rather than on a state.
Design Process
 The whole system is seen as how data flows in the system by means of data
flow diagram.
 DFD depicts how functions changes data and state of entire system.
 The entire system is logically broken down into smaller units known as
functions on the basis of their operation in the system.
 Each function is then described at large.

3.2 Object Oriented Design

Object oriented design works around the entities and their characteristics instead of
functions involved in the software system. This design strategies focuses on entities and its
characteristics. The whole concept of software solution revolves around the engaged
entities.
Let us see the important concepts of Object Oriented Design:
 Objects - All entities involved in the solution design are known as objects. For
example, person, banks, company and customers are treated as objects.
Every entity has some attributes associated to it and has some methods to
perform on the attributes.
 Classes - A class is a generalized description of an object. An object is an
instance of a class. Class defines all the attributes, which an object can have
and methods, which defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are
defined by means of methods or procedures.
 Encapsulation - In OOD, the attributes (data variables) and methods (operation
on the data) are bundled together is called encapsulation. Encapsulation not
only bundles important information of an object together, but also restricts
access of the data and methods from the outside world. This is called
information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical manner
where the lower or sub-classes can import, implement and re-use allowed
variables and methods from their immediate super classes. This property of
OOD is known as inheritance. This makes it easier to define specific class and
to create generalized classes from specific ones.
 Polymorphism - OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned same name.
This is called polymorphism, which allows a single interface performing tasks
for different types. Depending upon how the function is invoked, respective
portion of the code gets executed.
Design Process
Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the
following steps involved:
 A solution design is created from requirement or previous used system and/or
system sequence diagram.
 Objects are identified and grouped into classes on behalf of similarity in
attribute characteristics.
 Class hierarchy and relation among them is defined.
 Application framework is defined.

4. Software Design Approaches

Here are two generic approaches for software designing:
4.1 Top Down Design
We know that a system is composed of more than one sub-systems and it contains a
number of components. Further, these sub-systems and components may have their on set
of sub-system and components and creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then decomposes it to
achieve more than one sub-system or component based on some characteristics. Each
sub-system or component is then treated as a system and decomposed further. This
process keeps on running until the lowest level of system in the top-down hierarchy is
achieved.
Top-down design starts with a generalized model of system and keeps on defining the more
specific part of it. When all components are composed the whole system comes into
existence.
Top-down design is more suitable when the software solution needs to be designed from
scratch and specific details are unknown.
4.2 Bottom-up Design
The bottom up design model starts with most specific and basic components. It proceeds
with composing higher level of components by using basic or lower level components. It
keeps creating higher level components until the desired system is not evolved as one
single component. With each higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing
system, where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used.

5. Halstead Software Science

Halstead’s Software Metrics

A computer program is an implementation of an algorithm considered to be a collection of
tokens which can be classified as either operators or operands. Halstead’s metrics are
included in a number of current commercial tools that count software lines of code. By
counting the tokens and determining which are operators and which are operands, the
following base measures can be collected :
n1 = Number of distinct operators.
n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.
In addition to the above, Halstead defines the following :
n1* = Number of potential operators.
n2* = Number of potential operands.
Halstead refers to n1* and n2* as the minimum possible number of operators and operands
for a module and a program respectively. This minimum number would be embodied in the
programming language itself, in which the required operation would already exist (for
example, in C language, any program must contain at least the definition of the function
main()), possibly as a function or as a procedure: n1* = 2, since at least 2 operators must
appear for any function or procedure : 1 for the name of the function and 1 to serve as an
assignment or grouping symbol, and n2* represents the number of parameters, without
repetition, which would need to be passed on to the function or the procedure.

Halstead metrics –
Halstead metrics are :

 Halstead Program Length – The total number of operator occurrences and the
total number of operand occurrences.
N = N1 + N2
And estimated program length is, N^ = n1log2n1 + n2log2n2
The following alternate expressions have been published to estimate program
length:
o NJ = log2(n1!) + log2(n2!)
o NB = n1 * log2n2 + n2 * log2n1
o NC = n1 * sqrt(n1) + n2 * sqrt(n2)
o NS = (n * log2n) / 2
 Halstead Vocabulary – The total number of unique operator and unique operand
occurrences.
n = n1 + n2
 Program Volume – Proportional to program size, represents the size, in bits, of
space necessary for storing the program. This parameter is dependent on specific
algorithm implementation. The properties V, N, and the number of lines in the
code are shown to be linearly connected and equally valid for measuring relative
program size.
V = Size * (log2 vocabulary) = N * log2(n)
The unit of measurement of volume is the common unit for size “bits”. It is the
actual size of a program if a uniform binary encoding for the vocabulary is used.
And error = Volume / 3000
 Potential Minimum Volume – The potential minimum volume V* is defined as the
volume of the most succinct program in which a problem can be coded.
V* = (2 + n2*) * log2(2 + n2*)
Here, n2* is the count of unique input and output parameters
 Program Level – To rank the programming languages, the level of abstraction
provided by the programming language, Program Level (L) is considered. The
higher the level of a language, the less effort it takes to develop a program using
that language.
L = V* / V
The value of L ranges between zero and one, with L=1 representing a program
 written at the highest possible level (i.e., with minimum size).
And estimated program level is L^ =2 * (n2) / (n1)(N2)
 Program Difficulty – This parameter shows how difficult to handle the program is.
D = (n1 / 2) * (N2 / n2)
D=1/L
As the volume of the implementation of a program increases, the program level
decreases and the difficulty increases. Thus, programming practices such as
redundant usage of operands, or the failure to use higher-level control constructs
will tend to increase the volume as well as the difficulty.
 Programming Effort – Measures the amount of mental activity needed to translate
the existing algorithm into implementation in the specified program language.
E = V / L = D * V = Difficulty * Volume

 Language Level – Shows the algorithm implementation program language level.

The same algorithm demands additional effort if it is written in a low-level program
language. For example, it is easier to program in Pascal than in Assembler.
L’ = V / D / D
lambda = L * V* = L2 * V

 Intelligence Content – Determines the amount of intelligence presented (stated) in

the program This parameter provides a measurement of program complexity,
independently of the program language in which it was implemented.
I=V/D
 Programming Time – Shows time (in minutes) needed to translate the existing
algorithm into implementation in the specified program language.
T = E / (f * S)
The concept of the processing rate of the human brain, developed by the
psychologist John Stroud, is also used. Stoud defined a moment as the time
required by the human brain requires to carry out the most elementary decision.
The Stoud number S is therefore Stoud’s moments per second with:
5 <= S <= 20. Halstead uses 18. The value of S has been empirically developed
from psychological reasoning, and its recommended value for programming
applications is 18.
Stroud number S = 18 moments / second
seconds-to-minutes factor f = 60

Counting rules for C language –

1. Comments are not considered.

2. The identifier and function declarations are not considered
3. All the variables and constants are considered operands.
4. Global variables used in different modules of the same program are counted as
multiple occurrences of the same variable.
5. Local variables with the same name in different functions are counted as unique
operands.
6. Functions calls are considered as operators.
7. All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control
statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
 8. In control construct switch ( ) {case:…}, switch as well as all the case statements
are considered as operators.
9. The reserve words like return, default, continue, break, sizeof, etc., are considered
as operators.
10. All the brackets, commas, and terminators are considered as operators.
11. GOTO is counted as an operator and the label is counted as an operand.
12. The unary and binary occurrence of “+” and “-” are dealt separately. Similarly “*”
(multiplication operator) are dealt separately.
13. In the array variables such as “array-name [index]” “array-name” and “index” are
considered as operands and [ ] is considered as operator.
14. In the structure variables such as “struct-name, member-name” or “struct-name ->
member-name”, struct-name, member-name are taken as operands and ‘.’, ‘->’
are taken as operators. Some names of member elements in different structure
variables are counted as unique operands.
15. All the hash directive are ignored.

Example – List out the operators and operands and also calculate the values of software
science measures like

int sort (int x[ ], int n)

{
int i, j, save, im1;
/*This function sorts array x in ascending order */
If (n< 2) return 1;
for (i=2; i< =n; i++)
{
im1=i-1;
for (j=1; j< =im1; j++)
if (x[i] < x[j])
{
Save = x[i];
x[i] = x[j];
x[j] = save;
}
}
return 0;
}

Explanation –

operators occurrences operands occurrences

int 4 sort 1
() 5 x 7

, 4 n 3

[] 7 i 8

if 2 j 7

< 2 save 3

; 11 im1 3

for 2 2 2

= 6 1 3

– 1 0 1

<= 2 – –

++ 2 – –

return 2 – –
{} 3 – –

n1=14 N1=53 n2=10 N2=38

Therefore,
N = 91
n = 24
V = 417.23 bits
N^ = 86.51
n2* = 3 (x:array holding integer
to be sorted. This is used both
as input and output)
V* = 11.6
L = 0.027
D = 37.03
L^ = 0.038
T = 610 seconds

Advantages of Halstead Metrics:

 It is simple to calculate.
 It measures overall quality of the programs.
 It predicts the rate of error.
 It predicts maintenance effort.
 It does not require the full analysis of programming structure.
 It is useful in scheduling and reporting projects.
 It can be used for any programming language.

Disadvantages of Halstead Metrics:

 It depends on the complete code.

 It has no use as a predictive estimating model.

Function Point (FP) is an element of software development which helps to approximate the
cost of development early in the process. It may measures functionality from the user's point
of view.
Counting Function Point (FP):
Step-1:
F = 14 * scale
Scale varies from 0 to 5 according to character of Complexity Adjustment Factor (CAF).
Below table shows scale:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
 5 - Essential
 Step-2: Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + ( 0.01 * F )
 Step-3: Calculate Unadjusted Function Point (UFP).
TABLE (Required)

Function Units Low Avg High

EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10

 Multiply each individual function point to corresponding values in TABLE.

 Step-4: Calculate Function Point.
FP = UFP * CAF

Example:
Given the following values, compute function point when all complexity adjustment factor
(CAF) and weighting factors are average.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Explanation:
Step-1: As complexity adjustment factor is average (given in question), hence,
scale = 3.
 F = 14 * 3 = 42
  Step-2:
CAF = 0.65 + ( 0.01 * 42 ) = 1.07
 Step-3: As weighting factors are also average (given in question) hence we will
multiply each individual function point to corresponding values in TABLE.
UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
 Step-4:
Function Point = 628 * 1.07 = 671.96
This is the required answer.

Program to calculate Function Point is as follows :-

#include <bits/stdc++.h>
using namespace std;

// Function to calculate Function Point

void calfp(int frates[][3], int fac_rate)
{

// Function Units
string funUnits[5] = {
"External Inputs",
"External Outputs",
"External Inquiries",
"Internal Logical Files",
"External Interface Files"
};

// Weight Rates
string wtRates[3] = { "Low", "Average", "High" };

// Weight Factors
int wtFactors[5][3] = {
{ 3, 4, 6 },
{ 4, 5, 7 },
{ 3, 4, 6 },
{ 7, 10, 15 },
{ 5, 7, 10 },
};

int UFP = 0;

// Calculating UFP (Unadjusted Function Point)

for (int i = 0; i < 5; i++) {

for (int j = 0; j < 3; j++) {

int freq = frates[i][j];

UFP += freq * wtFactors[i][j];

}
}

// 14 factors
string aspects[14] = {
"reliable backup and recovery required ?",
"data communication required ?",
"are there distributed processing functions ?",
"is performance critical ?",
"will the system run in an existing heavily utilized operational environment ?",
"on line data entry required ?",
"does the on line data entry require the input transaction to be built over
multiple screens or operations ?",
"are the master files updated on line ?",
 "is the inputs, outputs, files or inquiries complex ?",
"is the internal processing complex ?",
"is the code designed to be reusable ?",
"are the conversion and installation included in the design ?",
"is the system designed for multiple installations in different organizations ?",
"is the application designed to facilitate change and ease of use by the user ?"
};

/*
Rate Scale of Factors
Rate the following aspects on a scale of 0-5 :-
0 - No influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
*/

int sumF = 0;

// Taking Input of factors rate

for (int i = 0; i < 14; i++) {

int rate = fac_rate;

sumF += rate;
}

// Calculate CFP
double CAF = 0.65 + 0.01 * sumF;

// Calculate Function Point (FP)

double FP = UFP * CAF;

// Output Values
cout << "Function Point Analysis :-" << endl;

cout << "Unadjusted Function Points (UFP) : " << UFP << endl;

cout << "Complexity Adjustment Factor (CAF) : " << CAF << endl;

cout << "Function Points (FP) : " << FP << endl;

}

// driver function
int main()
{
int frates[5][3] = {
{ 0, 50, 0 },
{ 0, 40, 0 },
{ 0, 35, 0 },
 { 0, 6, 0 },
{ 0, 4, 0 }
};

int fac_rate = 3;

calfp(frates, fac_rate);

return 0;
}
Output:
Function Point Analysis :-
Unadjusted Function Points (UFP) : 628
Complexity Adjustment Factor (CAF) : 1.07
Function Points (FP) : 671.96

6. Cyclomatic Complexity
 Difficulty Level : Easy
 Last Updated : 27 Jul, 2022

Read

Discuss

Cyclomatic complexity of a code section is the quantitative measure of the number of

linearly independent paths in it. It is a software metric used to indicate the complexity
of a program. It is computed using the Control Flow Graph of the program. The nodes
in the graph indicate the smallest group of commands of a program, and a directed
edge in it connects the two nodes i.e. if second command might immediately follow
the first command.
For example, if source code contains no control flow statement then its cyclomatic
complexity will be 1 and source code contains a single path in it. Similarly, if the source
code contains one if condition then cyclomatic complexity will be 2 because there will be two
paths one for true and the other for false.
Mathematically, for a structured program, the directed graph inside control flow is the edge
joining two basic blocks of the program as control may pass from first to second.
So, cyclomatic complexity M would be defined as,

M = E – N + 2P
where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components

Steps that should be followed in calculating cyclomatic complexity and test cases design are:

Construction of graph with nodes and edges from code.

Identification of independent paths.
Cyclomatic Complexity Calculation
  Design of Test Cases

Let a section of code as such:

A = 10
IF B > C THEN
A =B
ELSE
A=C
ENDIF
Print A
Print B
Print C

Control Flow Graph of above code

The cyclomatic complexity calculated for above code will be from control flow graph. The
graph shows seven shapes(nodes), seven lines(edges), hence cyclomatic complexity is 7-
7+2 = 2.
Use of Cyclomatic Complexity:

 Determining the independent path executions thus proven to be very

helpful for Developers and Testers.
 It can make sure that every path have been tested at least once.
 Thus help to focus more on uncovered paths.
 Code coverage can be improved.
 Risk associated with the program can be evaluated.
 These metrics being used earlier in the program helps in reducing the risks.

Advantages of Cyclomatic Complexity:.

 It can be used as a quality metric, giving relative complexity of various designs.

 It is able to compute faster than Halstead's metrics.
 It is used to measure the minimum effort and best areas of concentration for
testing.
 It is able to guide the testing process.
 It is easy to apply.

Disadvantages of Cyclomatic Complexity:

 It is the measure of the program's control complexity and not the data complexity.
 In this, nested conditional structures are harder to understand than non-nested
structures.
 In case of simple comparisons and decision structures, it may give a misleading
figure.

Control Flow Graph (CFG)

 Difficulty Level : Easy
 Last Updated : 15 May, 2019

Read

Discuss

A Control Flow Graph (CFG) is the graphical representation of control flow or computation
during the execution of programs or applications. Control flow graphs are mostly used in
static analysis as well as compiler applications, as they can accurately represent the flow
inside of a program unit. The control flow graph was originally developed by Frances E.
Allen.
Characteristics of Control Flow Graph:

 Control flow graph is process oriented.

 Control flow graph shows all the paths that can be traversed during a program
execution.
 Control flow graph is a directed graph.
 Edges in CFG portray control flow paths and the nodes in CFG portray basic
blocks.

There exist 2 designated blocks in Control Flow Graph:

1. Entry Block:
Entry block allows the control to enter into the control flow graph.
2. Exit Block:
Control flow leaves through the exit block.

Hence, the control flow graph is comprised of all the building blocks involved in a flow
diagram such as the start node, end node and flows between the nodes.
General Control Flow Graphs:
Control Flow Graph is represented differently for all statements and loops. Following images
describe it:
1. If-else:
2. while:

3. do-while:
 4. for:

Example:

if A = 10 then
if B > C
A=B
else A = C
endif
endif

print A, B, C

Flowchart of above example will be:

Control Flow Graph of above example will be:

Advantage of CFG:

There are many advantages of a control flow graph. It can easily encapsulate the
information per each basic block. It can easily locate inaccessible codes of a program and
syntactic structures such as loops are easy to find in a control flow graph.
 Important Question
1) What is Software Engineering?

2) What are the characteristics of the software?

3) What are different Software Development Lifecycle Models?

4) What is Software Development Life Cycle? (SDLC)

5) Explain the different phases involved in waterfall life cycle.

6) What are the prototyping methods in software process?

7) What are the various categories of software?

8) What is feasibility study? What are the contents we should contain in the feasibility report?

9) What are the purposes of Data Flow diagrams, Entity-Relationship diagrams? Give an example
diagram of each.

10) List the process maturity levels in SEIs CMM.

11) What are the different types of Cohesion?

12) What is coupling? What are the various types of coupling?

13) What are the metrics computed during error tracking activity?

14) How to compute the cyclomatic complexity?

15) Distinguish between verification and validation

 Unit – IV
Objectives of Software Testing

The main goal of software testing is to find bugs as early as possible and fix bugs and make
sure that the software is bug-free. The goals of software testing may be classified into three
major categories as follows:

1. Immediate Goals
2. Long-term Goals
3. Post-Implementation Goals

1. Immediate Goals: These objectives are the direct outcomes of testing. These
objectives may be set at any time during the SDLC process. Some of these are covered in
detail below:

 Bug Discovery: This is the immediate goal of software testing to find errors at
any stage of software development. The number of bugs is discovered in the
early stage of testing. The primary purpose of software testing is to detect flaws at
any step of the development process. The higher the number of issues detected
at an early stage, the higher the software testing success rate.

 Bug Prevention: This is the immediate action of bug discovery,that occurs as

a result of bug discovery. Everyone in the software development team learns how
to code from the behavior and analysis of issues detected, ensuring that bugs are
not duplicated in subsequent phases or future projects.

2. Long-Term Goals: These objectives have an impact on product quality in the long
run after one cycle of the SDLC is completed. Some of these are covered in detail below:
 Quality: This goal enhances the quality of the software product. Because
software is also a product, the user’s priority is its quality. Superior quality is
ensured by thorough testing. Correctness, integrity, efficiency, and reliability are
all aspects that influence quality. To attain quality, you must achieve all of the
above-mentioned quality characteristics.
 Customer Satisfaction: This goal verifies the customer’s satisfaction with a
developed software product. The primary purpose of software testing, from the
user’s standpoint, is customer satisfaction. Testing should be extensive and
thorough if we want the client and customer to be happy with the software
product.
 Reliability: It is a matter of confidence that the software will not fail. In short,
reliability means gaining the confidence of the customers by providing them with a
quality product.
 Risk Management: Risk is the probability of occurrence of uncertain events in
the organization and the potential loss that could result in negative
consequences. Risk management must be done to reduce the failure of the
product and to manage risk in different situations.
3. Post Implemented Goals : After the product is released, these objectives become
critical. Some of these are covered in detail below:

 Reduce Maintenance Cost: Post-released errors are costlier to fix and difficult to
identify. Because effective software does not wear out, the maintenance cost of
any software product is not the same as the physical cost. The failure of a
software product due to faults is the only expense of maintenance. Because they
are difficult to discover, post-release mistakes always cost more to rectify. As a
result, if testing is done thoroughly and effectively, the risk of failure is lowered,
and maintenance costs are reduced as a result.

 Improved Software Testing Process: These goals improve the testing

process for future use or software projects. These goals are known as post-
implementation goals. A project’s testing procedure may not be completely
successful, and there may be room for improvement. As a result, the bug
history and post-implementation results can be evaluated to identify
stumbling blocks in the current testing process that can be avoided in future
projects.

Types of Software Testing

Testing is the process of executing a program to find errors. To make our software perform
well it should be error-free. If testing is done successfully it will remove all the errors from
the software.

Principles of Testing:-

(i) All the tests should meet the customer requirements.

(ii) To make our software testing should be performed by a third party.
(iii) Exhaustive testing is not possible. As we need the optimal amount of testing based on
the risk assessment of the application.
(iv) All the tests to be conducted should be planned before implementing it
(v) It follows the Pareto rule(80/20 rule) which states that 80% of errors come from 20% of
program components.
(vi)Start testing with small parts and extend it to large parts.

Types of Testing:-

1. Unit Testing

It focuses on the smallest unit of software design. In this, we test an individual unit or group
of interrelated units. It is often done by the programmer by using sample input and
observing its corresponding outputs.
Example:

a) In a program we are checking if the loop, method, or function is working fine

b) Misunderstood or incorrect, arithmetic precedence.

c) Incorrect initialization
 2. Integration Testing

The objective is to take unit-tested components and build a program structure that has
been dictated by design. Integration testing is testing in which a group of components is
combined to produce output. Integration testing is of four types: (i) Top-down (ii) Bottom-up
(iii) Sandwich (iv) Big-Bang

Example:

(a) Black Box testing:- It is used for validation. In this, we ignore internal working
mechanisms and focus on what is the output?

(b) White box testing:- It is used for verification. In this, we focus on internal mechanisms
i.e how the output is achieved?

3. Regression Testing

Every time a new module is added leads to changes in the program. This type of testing
makes sure that the whole component works properly even after adding components to the
complete program.

Example

In school, record suppose we have module staff, students and finance combining these
modules and checking if on integration of these modules works fine in regression testing

4. Smoke Testing

This test is done to make sure that the software under testing is ready or stable for further
testing It is called a smoke test as the testing of an initial pass is done to check if it did not
catch the fire or smoke in the initial switch on.
Example:

If the project has 2 modules so before going to the module make sure that module 1 works
properly.

5. Alpha Testing

This is a type of validation testing. It is a type of acceptance testing which is done before the
product is released to customers. It is typically done by QA people.
Example:

When software testing is performed internally within the organization

6. Beta Testing

The beta test is conducted at one or more customer sites by the end-user of the software.
This version is released for a limited number of users for testing in a real-time environment
Example:

When software testing is performed for the limited number of people.

 7. System Testing

This software is tested such that it works fine for the different operating systems. It is
covered under the black box testing technique. In this, we just focus on the required input
and output without focusing on internal working.
In this, we have security testing, recovery testing, stress testing, and performance testing
Example:

This includes functional as well as nonfunctional testing

8. Stress Testing

In this, we give unfavorable conditions to the system and check how they perform in those
conditions.
Example:

(a) Test cases that require maximum memory or other resources are executed
(b) Test cases that may cause thrashing in a virtual operating system
(c) Test cases that may cause excessive disk requirement

9. Performance Testing

It is designed to test the run-time performance of software within the context of an

integrated system. It is used to test the speed and effectiveness of the program. It is also
called load testing. In it we check, what is the performance of the system in the given load.

Example: Checking several processor cycles.

10. Object-Oriented Testing

This testing is a combination of various testing techniques that help to verify and validate
object-oriented software. This testing is done in the following manner:
 Testing of Requirements,
 Design and Analysis of Testing,
 Testing of Code,
 Integration testing,
 System testing,
 User Testing.

11. Acceptance Testing

Acceptance testing is done by the customers to check whether the delivered products
perform the desired tasks or not, as stated in requirements.

Functional testing (Black-Box Testing)

The technique of testing without having any knowledge of the interior workings of the
application is called black-box testing. The tester is oblivious to the system architecture and
does not have access to the source code. Typically, while performing a black-box test, a
tester will interact with the system's user interface by providing inputs and examining
outputs without knowing how and where the inputs are worked upon.
The following table lists the advantages and disadvantages of black-box testing.

Advantages Disadvantages

Well suited and efficient for large code segments. Limited coverage, since only a
selected number of test scenarios
is actually performed.

Code access is not required. Inefficient testing, due to the fact

that the tester only has limited
knowledge about an application.

Clearly separates the user's perspective from the Blind coverage, since the tester
developer's perspective through visibly defined cannot target specific code
roles. segments or error prone areas.

Large numbers of moderately skilled testers can The test cases are difficult to
test the application with no knowledge of design.
implementation, programming language, or
operating systems.

Structural Testing (White-Box Testing)

White-box testing is the detailed investigation of internal logic and structure of the code.
White-box testing is also called glass testing or open-box testing. In order to perform white-
box testing on an application, a tester needs to know the internal workings of the code. The
tester needs to have a look inside the source code and find out which unit/chunk of the code
is behaving inappropriately.

The following table lists the advantages and disadvantages of white-box testing.

Advantages Disadvantages
As the tester has knowledge of the source Due to the fact that a skilled tester is needed
code, it becomes very easy to find out to perform white-box testing, the costs are
which type of data can help in testing the increased.
application effectively.

It helps in optimizing the code. Sometimes it is impossible to look into every

nook and corner to find out hidden errors that
may create problems, as many paths will go
untested.

Extra lines of code can be removed which It is difficult to maintain white-box testing, as it
can bring in hidden defects. requires specialized tools like code analyzers
and debugging tools.

Due to the tester's knowledge about the

code, maximum coverage is attained during
test scenario writing.

Grey-Box Testing

Gray-box testing is a technique to test the application with having a limited knowledge of the
internal workings of an application. In software testing, the phrase the more you know, the
better carries a lot of weight while testing an application.
Mastering the domain of a system always gives the tester an edge over someone with
limited domain knowledge. Unlike black-box testing, where the tester only tests the
application's user interface; in grey-box testing, the tester has access to design documents
and the database. Having this knowledge, a tester can prepare better test data and test
scenarios while making a test plan.

The following table lists the advantages and disadvantages of Gray-box testing.

Advantages Disadvantages

Offers combined benefits of black-box and Since the access to source code is not
white-box testing wherever possible. available, the ability to go over the code
and test coverage is limited.
Grey box testers don't rely on the source The tests can be redundant if the software
code; instead they rely on interface definition designer has already run a test case.
and functional specifications.

Based on the limited information available, a Testing every possible input stream is
gray-box tester can design excellent test unrealistic because it would take an
scenarios especially around communication unreasonable amount of time; therefore,
protocols and data type handling. many program paths will go untested.

The test is done from the point of view of the

user and not the designer.

A Comparison of Testing Methods

The following table lists the points that differentiate black-box testing, grey-box
testing, and white-box testing.

Black-Box Testing Grey-Box Testing White-Box Testing

The internal workings of an The tester has limited Tester has full knowledge
application need not be knowledge of the internal of the internal workings of
known. workings of the application. the application.

Also known as closed-box Also known as translucent Also known as clear-box

testing, data-driven testing, testing, as the tester has testing, structural testing,
or functional testing. limited knowledge of the or code-based testing.
insides of the application.

Performed by end-users and Performed by end-users and Normally done by testers

also by testers and also by testers and and developers.
developers. developers.

Testing is based on external Testing is done on the basis of Internal workings are fully
expectations - Internal high-level database diagrams known and the tester can
behavior of the application is and data flow diagrams. design test data
unknown. accordingly.
It is exhaustive and the least Partly time-consuming and The most exhaustive and
time-consuming. exhaustive. time-consuming type of
testing.

Not suited for algorithm Not suited for algorithm Suited for algorithm
testing. testing. testing.

This can only be done by Data domains and internal Data domains and internal
trial-and-error method. boundaries can be tested, if boundaries can be better
known. tested.

Software Testing – Boundary Value Analysis (used for test stubs)

Functional testing is a type of software testing in which the system is tested against the
functional requirements of the system. It is conducted to ensure that the requirements are
properly satisfied by the application. Functional testing verifies that each function of the
software application works in conformance with the requirement and specification. Boundary
Value Analysis (BVA) is one of the functional testing methods.

Boundary Value Analysis

Boundary Value Analysis is based on testing the boundary values of valid and invalid
partitions. The behavior at the edge of the equivalence partition is more likely to be incorrect
than the behavior within the partition, so boundaries are an area where testing is likely to
yield defects.
It checks for the input values near the boundary that have a higher chance of error. Every
partition has its maximum and minimum values and these maximum and minimum values
are the boundary values of a partition.
Note:

 A boundary value for a valid partition is a valid boundary value.

 A boundary value for an invalid partition is an invalid boundary value.
 For each variable we check-
o Minimum value.
o Just above the minimum.
o Nominal Value.
o Just below Max value.
o Max value.

Example: Consider a system that accepts ages from 18 to 56.

 Boundary Value Analysis(Age accepts 18 to 56)

Invalid
Invalid Valid
(max +
(min -1) (min, min + 1, nominal, max – 1, max)
1)

18, 19, 37, 55, 56 57

17

Valid Test cases: Valid test cases for the above can be any value entered greater

than 17 and less than 57.

 Enter the value- 18.

 Enter the value- 19.
 Enter the value- 37.
 Enter the value- 55.
 Enter the value- 56.

Invalid Test Cases: When any value less than 18 and greater than 56 is entered.

 Enter the value- 17.

 Enter the value- 57.

Single Fault Assumption: When more than one variable for the same application is
checked then one can use a single fault assumption. Holding all but one variable to the
extreme value and allowing the remaining variable to take the extreme value. For n variable
to be checked:
Maximum of 4n+1 test cases
Problem: Consider a Program for determining the Previous Data.
Input: Day, Month, Year with valid ranges as-
1 ≤ Month≤12
1 ≤ Day ≤31
1900 ≤ Year ≤ 2000
Design Boundary Value Test Cases.
Solution: Taking the year as a Single Fault Assumption i.e. year will be having values
varying from 1900 to 2000 and others will have nominal values.

Test Cases Month Day Year Output

 1 6 15 1990 14 June 1990

2 6 15 1901 14 June 1901

3 6 15 1960 14 June 1960

4 6 15 1999 14 June 1999

5 6 15 2000 14 June 2000

Taking Day as Single Fault Assumption i.e. Day will be having values varying from 1
to 31 and others will have nominal values.

Test Case Month Day Year Output

6 6 1 1960 31 May 1960

7 6 2 1960 1 June 1960

8 6 30 1960 29 June 1960

9 6 31 1960 Invalid day

Taking Month as Single Fault Assumption i.e. Months will have values varying from 1

to 12 and others will have nominal values

Test Case Month Day Year Output

10 1 15 1960 14 Jan 1960

11 2 15 1960 14 Feb 1960

12 11 15 1960 14 Nov 1960

13 12 15 1960 14 Dec 1960

For the n variable to be checked Maximum of 4n + 1 test case will be required. Therefore,
for n = 3, the maximum test cases are-
4 × 3 + 1 =13
The focus of BVA: BVA focuses on the input variable of the function. Let’s define two
variables X1 and X2, where X1 lies between a and b and X2 lies between c and d.

Showing legitimate domain

The idea and motivation behind BVA are that errors tend to occur near the extremes of the
variables. The defect on the boundary value can be the result of countless possibilities.

Typing of Languages: BVA is not suitable for free-form languages such as COBOL and
FORTRAN, These languages are known as weakly typed languages. This can be useful
and can cause bugs also.
PASCAL, ADA is the strongly typed language that requires all constants or variables
defined with an associated data type.

Limitation of Boundary Value Analysis:

 It works well when the product is under test.

 It cannot consider the nature of the functional dependencies of variables.
 BVA is quite rudimentary.

Equivalence Partitioning:

It is a type of black-box testing that can be applied to all levels of software testing. In this
technique, input data are divided into the equivalent partitions that can be used to derive
test cases-
 In this input data are divided into different equivalence data classes.
 It is applied when there is a range of input values.

Example: Below is the example to combine Equivalence Partitioning and Boundary

Value. Consider a field that accepts a minimum of 6 characters and a maximum of 10
characters. Then the partition of the test cases ranges 0 – 5, 6 – 10, 11 – 14.
Test Scenario Test Description Expected Outcome
 1 Enter value 0 to 5 character Not accepted

2 Enter 6 to 10 character Accepted

3 Enter 11 to 14 character Not Accepted

Why Combine Equivalence Partitioning and Boundary Analysis Testing: Following

are some of the reasons why to combine the two approaches:

 In this test cases are reduced into manageable chunks.

 The effectiveness of the testing is not compromised on test cases.
 Works well with a large number of variables.

Static Testing is a type of a Software Testing method which is performed to check the
defects in software without actually executing the code of the software application.
Whereas in Dynamic Testing the code is executed to detect the defects.
Static testing is performed in the early stage of development to avoid errors as it is easier to
find sources of failures and it can be fixed easily. The errors that can’t not be found using
Dynamic Testing, can be easily found by Static Testing.
Static Testing Techniques:
There are mainly two type techniques used in Static Testing:

1. Review:
In static testing review is a process or technique that is performed to find the potential
defects in the design of the software. It is a process to detect and remove errors and defects
in the different supporting documents like software requirements specifications. People
examine the documents and sort out errors, redundancies and ambiguities.

Review is of four types:

 Informal:
In informal review the creator of the documents put the contents in front of the
audience and everyone gives their opinion and thus defects are identified in the
early stage.
 Walkthrough:
It is basically performed by an experienced person or expert to check the defects
so that there might not be problems further in the development or testing phase.
 Peer review:
Peer review means checking documents of one-another to detect and fix the
defects. It is basically done in a team of colleagues.
 Inspection:
Inspection is basically the verification of documents by higher authority like the
verification of software requirement specifications (SRS).

2. Static Analysis:

Static Analysis includes the evaluation of the code quality that is written by developers.
Different tools are used to do the analysis of the code and comparison of the same with the
standard.
It also helps in following identification of following defects:
(a) Unused variables
(b) Dead code
(c) Infinite loops
(d) Variable with undefined value
(e) Wrong syntax
Static Analysis is of three types:
 Data Flow:
Data flow is related to stream processing.
 Control Flow:
Control flow is basically how the statements or instructions are executed.
 Cyclomatic Complexity:
Cyclomatic complexity is the measurement of the complexity of the program that
is basically related to the number of independent paths in the control flow graph of
the program.

Note:- Exhaustive testing is not possible.

 Unit - V
Software Maintenance:- Software Maintenance is the process of modifying a software
product after it has been delivered to the customer. The main purpose of software
maintenance is to modify and update software applications after delivery to correct faults
and to improve performance.
Software maintenance is also an important part of the Software Development Life
Cycle(SDLC). To update the software application and do all modifications in software
application so as to improve performance is the main focus of software maintenance.
Software is a model that run on the basis of real world. so, whenever any change requires in
the software that means the need of real world changes wherever possible.

Need for Maintenance

Software Maintenance must be performed in order to:

 Correct faults.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system
features, and telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.
 Requirement of user changes.
 Run the code fast

Challenges in Software Maintenance:

The various challenges in software maintenance are given below:

 The popular age of any software program is taken into consideration up to ten to
fifteen years. As software program renovation is open ended and might maintain
for decades making it very expensive.
 Older software programs, which had been intended to paintings on sluggish
machines with much less reminiscence and garage ability cannot maintain
themselves tough in opposition to newly coming more advantageous software
program on contemporary-day hardware.
 Changes are frequently left undocumented which can also additionally reason
greater conflicts in future.
 As era advances, it turns into high priced to preserve vintage software program.
 Often adjustments made can without problems harm the authentic shape of the
software program, making it difficult for any next adjustments.
 There is lack of Code Comments.

Categories of Software Maintenance –

Maintenance can be divided into the following:

1. Corrective maintenance:
Corrective maintenance of a software product may be essential either to rectify some
bugs observed while the system is in use, or to enhance the performance of the
 system.

2. Adaptive maintenance:
This includes modifications and updations when the customers need the product to
run on new platforms, on new operating systems, or when they need the product to
interface with new hardware and software.

3. Perfective maintenance:
A software product needs maintenance to support the new features that the users
want or to change different types of functionalities of the system according to the
customer demands.

4. Preventive maintenance:
This type of maintenance includes modifications and updations to prevent future
problems of the software. It goals to attend problems, which are not significant at this
moment but may cause serious issues in future.

Reverse Engineering –

Reverse Engineering is processes of extracting knowledge or design information from

anything man-made and reproducing it based on extracted information. It is also called back
Engineering. The main objective of reverse-engineering is to check out how the system
works. There are many reasons to perform reverse engineering. Reverse engineering is
used to know how the thing works. Also, reverse engineering is to recreate the object by
adding some enhancements.

Software Reverse Engineering –

Software Reverse Engineering is the process of recovering the design and the requirements
specification of a product from an analysis of it’s code. Reverse Engineering is becoming
important, since several existing software products, lack proper documentation, are highly
unstructured, or their structure has degraded through a series of maintenance efforts.
Why Reverse Engineering?

 Providing proper system documentation.

 Recovery of lost information.
 Assisting with maintenance.
 Facility of software reuse.
 Discovering unexpected flaws or faults.
 Implements the innovative processes for specific use.
 Easy to document the things how the efficiency and power can be improved.

Uses of Software Reverse Engineering –

 Software Reverse Engineering is used in software design, reverse engineering

enables the developer or programmer to add new features to the existing software
with or without knowing the source code.
 Reverse engineering is also useful in software testing, it helps the testers to study or
detect the virus and other malware code.

Software Maintenance Cost Factors

There are two types of cost factors involved in software maintenance.
These are

 Non-Technical Factors
 Technical Factors

Non-Technical Factors

1. Application Domain

 If the application of the program is defined and well understood, the system
requirements may be definitive and maintenance due to changing needs minimized.
 If the form is entirely new, it is likely that the initial conditions will be modified
frequently, as user gain experience with the system.

2. Staff Stability

 It is simple for the original writer of a program to understand and change an

application rather than some other person who must understand the program by the
study of the reports and code listing.
 If the implementation of a system also maintains that systems, maintenance costs
will reduce.
 In practice, the feature of the programming profession is such that persons change
jobs regularly. It is unusual for one user to develop and maintain an application
throughout its useful life.

3. Program Lifetime

 Programs become obsolete when the program becomes obsolete, or their original
hardware is replaced, and conversion costs exceed rewriting costs.
4. Dependence on External Environment

 If an application is dependent on its external environment, it must be modified as the

climate changes.
 For example:
 Changes in a taxation system might need payroll, accounting, and stock control
programs to be modified.
 Taxation changes are nearly frequent, and maintenance costs for these programs
are associated with the frequency of these changes.
 A program used in mathematical applications does not typically depend on humans
changing the assumptions on which the program is based.

5. Hardware Stability

 If an application is designed to operate on a specific hardware configuration and that

configuration does not changes during the program's lifetime, no maintenance costs
due to hardware changes will be incurred.
 Hardware developments are so increased that this situation is rare.
 The application must be changed to use new hardware that replaces obsolete
equipment.

Technical Factors

Technical Factors include the following:

Module Independence
It should be possible to change one program unit of a system without affecting any other
unit.
Programming Language
Programs written in a high-level programming language are generally easier to understand
than programs written in a low-level language.
Programming Style
The method in which a program is written contributes to its understandability and hence, the
ease with which it can be modified.
Program Validation and Testing

 Generally, more the time and effort are spent on design validation and program
testing, the fewer bugs in the program and, consequently, maintenance costs
resulting from bugs correction are lower.
 Maintenance costs due to bug's correction are governed by the type of fault to be
repaired.
 Coding errors are generally relatively cheap to correct, design errors are more
expensive as they may include the rewriting of one or more program units.
 Bugs in the software requirements are usually the most expensive to correct because
of the drastic design which is generally involved.

Documentation

 If a program is supported by clear, complete yet concise documentation, the

functions of understanding the application can be associatively straight-forward.
 Program maintenance costs tends to be less for well-reported systems than for the
system supplied with inadequate or incomplete documentation.

Configuration Management Techniques

 One of the essential costs of maintenance is keeping track of all system documents
and ensuring that these are kept consistent.
 Effective configuration management can help control these costs.

Software Re-engineering
Software Re-engineering is a process of software development which is done to improve
the maintainability of a software system. Re-engineering is the examination and alteration of
a system to reconstitute it in a new form. This process encompasses a combination of sub-
processes like reverse engineering, forward engineering, reconstructing etc.
Re-engineering is the reorganizing and modifying existing software systems to make them
more maintainable.

Objectives of Re-engineering:

 To describe a cost-effective option for system evolution.

 To describe the activities involved in the software maintenance process.
 To distinguish between software and data re-engineering and to explain the
problems of data re-engineering.
Steps involved in Re-engineering:

1. Inventory Analysis
2. Document Reconstruction
3. Reverse Engineering
4. Code Reconstruction
5. Data Reconstruction
6. Forward Engineering

Diagrammatic Representation:

Re-engineering Cost Factors:

 The quality of the software to be re-engineered

 The tool support available for re-engineering
 The extent of the required data conversion
 The availability of expert staff for re-engineering

Advantages of Re-engineering:
  Reduced Risk: As the software is already existing, the risk is less as compared to
new software development. Development problems, staffing problems and
specification problems are the lots of problems which may arise in new software
development.
 Reduced Cost: The cost of re-engineering is less than the costs of developing
new software.
 Revelation of Business Rules: As a system is re-engineered , business rules that
are embedded in the system are rediscovered.
 Better use of Existing Staff: Existing staff expertise can be maintained and
extended to accommodate new skills during re-engineering.

Disadvantages of Re-engineering:

 Practical limits to the extent of re-engineering.

 Major architectural changes or radical reorganizing of the systems data
management has to be done manually.
 Re-engineered system is not likely to be as maintainable as a new system
developed using modern software Re-engineering methods.

Software Configuration Management

When we develop software, the product (software) undergoes many changes in their
maintenance phase; we need to handle these changes effectively.
Several individuals (programs) work together to achieve these common goals. This
individual produces several work products (SC Items) e.g., Intermediate version of modules
or test data used during debugging, parts of the final product.
The elements that comprise all information produced as a part of the software process are
collectively called a software configuration.
As software development progresses, the number of Software Configuration elements
(SCI's) grow rapidly.
These are handled and controlled by SCM. This is where we require software configuration
management.
A configuration of the product refers not only to the product's constituent but also to a
particular version of the component.
Therefore, SCM is the discipline which

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

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

modification to software being built by a programming team.
The objective is to maximize productivity by minimizing mistakes (errors).
CM is used to essential due to the inventory management, library management, and
updating management of the items essential for the project.

Why do we need Configuration Management?

Multiple people are working on software which is consistently updating. It may be a method
where multiple version, branches, authors are involved in a software project, and the team
is geographically distributed and works concurrently. It changes in user requirements, and
policy, budget, schedules need to be accommodated.

Importance of SCM
It is practical in controlling and managing the access to various SCIs e.g., by preventing the
two members of a team for checking out the same component for modification at the same
time.
It provides the tool to ensure that changes are being properly implemented.
It has the capability of describing and storing the various constituents of software.
SCM is used in keeping a system in a consistent state by automatically producing derived
version upon modification of the same component.

Change Control Process

What is Change Control?

Change Control is the process that a company uses to document, identify and authorize
changes to an IT environment. It reduces the chances of unauthorized alterations,
disruption and errors in the system.

Why Change Control?

Whenever any new or different changes are requested for the system, especially by
stakeholders, it is neither optional nor ignorable. It has to be implemented without affecting
other components of the system. This is when the change control comes handy. It helps
project teams to modify the scope of the project using specified controls and policies.
Change Control is practiced whenever a project is not progressing as planned.
It is mandatory that a formal document for change request is completed and reviewed in
order to keep control of change requests.
Number of question one might encounter while analyzing Change Control like
 Who will approve the change?
 Does it require to run through a change control board?
 How much time will be required to research and implement the change?
 What are the impacts of changes to other components of the system (schedules,
cost, resources, etc.)?
 Is there any threshold under which the project management can approve it?

Different factors of Change Control process

There are various factors that a Change Control process should consider
Steps in Change Control Process Action taken in Change Control

 Change request initiation  Request for changes should be standardized and

and Control subject to management review
 Change requestor should be kept informed
  Impact Assessment  Make sure that all requests for change are
assessed in a structured way for analyzing
possible impacts

 Control and  A change log should be maintained that tells the

Documentation of date, person details who made changes and
Changes changes implemented
 Only authorized individual should be able to
make changes
 A process for rolling back to the previous version
should be identified

 Documentation and  Whenever system changes are implemented the

Procedures procedures and associated document should
update accordingly

 Authorized Maintenance  System access right should be controlled to avert

unauthorized access

 Testing and User signoff  Software should be thoroughly tested

 Version Control  Control should be placed on production source

code to make sure that only the latest version is
updated

 Emergency Changes  A verbal authorization should be obtained, and

the change should be documented as soon as
possible

Process of Change Control

Before we look into what is involved in Change Control process, we will get familiarize with
what documents are used in Change Control. While carrying out Change Control, there are
mainly two documents involved
 Change Log: A change log is a document that list the details about all the Change
Requests like project number, PCR (project change request) ID, priority, Owner
details, Target date, status and status date, raised by, date when raised etc.
 

Version Control Systems

Version control systems are a category of software tools that helps in recording changes
made to files by keeping a track of modifications done in the code.
Why Version Control system is so Important?
As we know that a software product is developed in collaboration by a group of developers
they might be located at different locations and each one of them contributes to some
specific kind of functionality/features. So in order to contribute to the product, they made
modifications to the source code(either by adding or removing). A version control system is
a kind of software that helps the developer team to efficiently communicate and
manage(track) all the changes that have been made to the source code along with the
information like who made and what changes have been made. A separate branch is
created for every contributor who made the changes and the changes aren’t merged into
the original source code unless all are analyzed as soon as the changes are green signaled
they merged to the main source code. It not only keeps source code organized but also
improves productivity by making the development process smooth.
Basically Version control system keeps track on changes made on a particular software and
take a snapshot of every modification. Let’s suppose if a team of developer add some new
functionality in an application and the updated version is not working properly so as the
version control system keeps track of our work so with the help of version control system we
can omit the new changes and continue with the previous version.
Benefits of the version control system:

 Enhances the project development speed by providing efficient collaboration,

 Leverages the productivity, expedites product delivery, and skills of the
employees through better communication and assistance,
 Reduce possibilities of errors and conflicts meanwhile project development
through traceability to every small change,
 Employees or contributors of the project can contribute from anywhere
irrespective of the different geographical locations through this VCS,
 For each different contributor to the project, a different working copy is maintained
and not merged to the main file unless the working copy is validated. The most
popular example is Git, Helix core, Microsoft TFS,
 Helps in recovery in case of any disaster or contingent situation,
  Informs us about Who, What, When, Why changes have been made.

Use of Version Control System:

 A repository: It can be thought of as a database of changes. It contains all the

edits and historical versions (snapshots) of the project.
 Copy of Work (sometimes called as checkout): It is the personal copy of all the
files in a project. You can edit this copy, without affecting the work of others and
you can finally commit your changes to a repository when you are done making
your changes.
 Working in a group: Consider yourself working in a company where you are asked
to work on some live project. You can’t change the main code as it is in
production, and any change may cause inconvenience to the user, also you are
working in a team so you need to collaborate with your team to adapt their
changes. Version control helps you with merging different requests to the main
repository without making any undesirable changes. You may test the
functionalities without putting it live, and you don’t need to download and set up
each time, just pull the changes and do the changes, test it and merge it back. It
may be visualized as.

Types of Version Control Systems:

 Local Version Control Systems

 Centralized Version Control Systems
 Distributed Version Control Systems

Local Version Control Systems: It is one of the simplest forms and has a database that
kept all the changes to files under revision control. RCS is one of the most common VCS
tools. It keeps patch sets (differences between files) in a special format on disk. By adding
up all the patches it can then re-create what any file looked like at any point in time.
Centralized Version Control Systems: Centralized version control systems contain just
one repository globally and every user need to commit for reflecting one’s changes in the
repository. It is possible for others to see your changes by updating.
Two things are required to make your changes visible to others which are:
 You commit
 They update

The benefit of CVCS (Centralized Version Control Systems) makes collaboration amongst
developers along with providing an insight to a certain extent on what everyone else is
doing on the project. It allows administrators to fine-grained control over who can do what.
It has some downsides as well which led to the development of DVS. The most obvious is
the single point of failure that the centralized repository represents if it goes down during
that period collaboration and saving versioned changes is not possible. What if the hard disk
of the central database becomes corrupted, and proper backups haven’t been kept? You
lose absolutely everything.

Distributed Version Control Systems: Distributed version control systems contain multiple
repositories. Each user has their own repository and working copy. Just committing your
changes will not give others access to your changes. This is because commit will reflect
those changes in your local repository and you need to push them in order to make them
visible on the central repository. Similarly, When you update, you do not get others’ changes
unless you have first pulled those changes into your repository.
To make your changes visible to others, 4 things are required:
 You commit
 You push
 They pull
 They update
The most popular distributed version control systems are Git, and Mercurial. They help us
overcome the problem of single point of failure.

Purpose of Version Control:

 Multiple people can work simultaneously on a single project. Everyone works on
and edits their own copy of the files and it is up to them when they wish to share
the changes made by them with the rest of the team.
 It also enables one person to use multiple computers to work on a project, so it is
valuable even if you are working by yourself.
 It integrates the work that is done simultaneously by different members of the
team. In some rare cases, when conflicting edits are made by two people to the
same line of a file, then human assistance is requested by the version control
system in deciding what should be done.
 Version control provides access to the historical versions of a project. This is
insurance against computer crashes or data loss. If any mistake is made, you can
easily roll back to a previous version. It is also possible to undo specific edits that
too without losing the work done in the meanwhile. It can be easily known when,
why, and by whom any part of a file was edited.

CASE
CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.

CASE Tools
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to
develop software system.
There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management tools,
Database Management tools, Documentation tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result and
helps to uncover flaws before moving ahead with next stage in software development.

Components of CASE Tools

CASE tools can be broadly divided into the following parts based on their use at a particular
SDLC stage:
 Central Repository - CASE tools require a central repository, which can serve
as a source of common, integrated and consistent information. Central
repository is a central place of storage where product specifications,
requirement documents, related reports and diagrams, other useful information
regarding management is stored. Central repository also serves as data
dictionary.

 Upper Case Tools - Upper CASE tools are used in planning, analysis and
design stages of SDLC.
 Lower Case Tools - Lower CASE tools are used in implementation, testing
and maintenance.
 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of
SDLC, from Requirement gathering to Testing and documentation.

CASE tools can be grouped together if they have similar functionality, process
activities and capability of getting integrated with other tools.

Scope of Case Tools

The scope of CASE tools goes throughout the SDLC.

Case Tools Types

Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow among various
software components and system structure in a graphical form. For example, Flow Chart
Maker tool for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to develop the
software. Process modeling tools help the managers to choose a process model or modify it
as per the requirement of software product. For example, EPF Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project execution with every mentioned
step in software project management. Project management tools help in storing and sharing
project information in real-time throughout the organization. For example, Creative Pro
Office, Trace Project, Base camp.
Documentation Tools
Documentation in a software project starts prior to the software process, goes throughout all
phases of SDLC and after the completion of the project.
Documentation tools generate documents for technical users and end users. Technical
users are mostly in-house professionals of the development team who refer to system
manual, reference manual, training manual, installation manuals etc. The end user
documents describe the functioning and how-to of the system such as user manual. For
example, Do oxygen, Dr Explain, Adobe Robot Help for documentation.

Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example,
Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total
analysis.
Design Tools
These tools help software designers to design the block structure of the software, which
may further be broken down in smaller modules using refinement techniques. These tools
provide detailing of each module and interconnections among modules. For example,
Animated Software Design
Configuration Management Tools
An instance of software is released under one version. Configuration Management tools
deal with –
 Version and revision management
 Baseline configuration management
 Change control management

CASE tools help in this by automatic tracking, version management and release
management. For example, Fossil.
Software Cost Estimation
For any new software project, it is necessary to know how much it will cost to develop and
how much development time will it take. These estimates are needed before development is
initiated, but how is this done? Several estimation procedures have been developed and are
having the following attributes in common.

1. Project scope must be established in advanced.

2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule
estimates.
6. Acquire one or more automated estimation tools.

Uses of Cost Estimation

1. During the planning stage, one needs to choose how many engineers are required
for the project and to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.

Cost Estimation Models

A model may be static or dynamic. In a static model, a single variable is taken as a key
element for calculating cost and time. In a dynamic model, all variable are interdependent,
and there is no basic variable.

Static, Single Variable Models: When a model makes use of single variables to calculate
desired values such as cost, time, efforts, etc. is said to be a single variable model. The
most common equation is:
C=aLb
Where C = Costs
L= size
a and b are constants
The Software Engineering Laboratory established a model called SEL model, for estimating
its software production. This model is an example of the static, single variable model.
E=1.4L0.93
DOC=30.4L0.90
 D=4.6L0.26
Where E= Efforts (Person Per Month)
DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code
Static, Multivariable Models: These models are based on method (1), they depend on
several variables describing various aspects of the software development environment. In
some models, several variables are needed to describe the software development process,
and the selected equation combines these variables to give the estimate of time & cost.
These models are called multivariable models.
WALSTON and FELIX develop the models at IBM provide the f ollowing equation gives a
relationship between lines of source code and effort:
E=5.2L0.91

In the same manner duration of development is given by

D=4.1L0.36
The productivity index uses 29 variables which are found to be highly correlated productivity
as follows:

Where W i is the weight factor for the ith variable and Xi ={-1,0,+1} the estimator gives Xi one
of the values -1, 0 or +1 depending on the variable decreases, has no effect or increases
productivity.
Example: Compare the Walston-Felix Model with the SEL model on a software development
expected to involve 8 person-years of effort.

a. Calculate the number of lines of source code that can be produced.

b. Calculate the duration of the development.
c. Calculate the productivity in LOC/PY
d. Calculate the average manning

Solution:
The amount of manpower involved = 8PY=96 persons-months
(a)Number of lines of source code can be obtained by reversing equation to give:

Then
L (SEL) = (96/1.4)1⁄0.93=94264 LOC
L (SEL) = (96/5.2)1⁄0.91=24632 LOC
(b)Duration in months can be calculated by means of equation
D (SEL) = 4.6 (L) 0.26
= 4.6 (94.264)0.26 = 15 months
D (W-F) = 4.1 L0.36
= 4.1 (24.632)0.36 = 13 months
(c) Productivity is the lines of code produced per persons/month (year)
(d)Average manning is the average number of persons required per month in the project

COCOMO Model:-Cocomo (Constructive Cost Model) is a regression model based on

LOC, i.e number of Lines of Code. It is a procedural cost estimate model for software
projects and is often used as a process of reliably predicting the various parameters
associated with making a project such as size, effort, cost, time, and quality. It was
proposed by Barry Boehm in 1981 and is based on the study of 63 projects, which makes it
one of the best-documented models. The key parameters which define the quality of any
software products, which are also an outcome of the Cocomo are primarily Effort &
Schedule:
 Effort: Amount of labor that will be required to complete a task. It is measured in
person-months units.
 Schedule: Simply means the amount of time required for the completion of the
job, which is, of course, proportional to the effort put in. It is measured in the units
of time such as weeks, and months.

Different models of Cocomo have been proposed to predict the cost estimation at
different levels, based on the amount of accuracy and correctness required. All of
these models can be applied to a variety of projects, whose characteristics
determine the value of the constant to be used in subsequent calculations. These
characteristics pertaining to different system types are mentioned below. Boehm’s
definition of organic, semidetached, and embedded systems:

1. Organic – A software project is said to be an organic type if the team size

required is adequately small, the problem is well understood and has been solved
in the past and also the team members have a nominal experience regarding the
problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the
vital characteristics such as team size, experience, and knowledge of the various
programming environment lie in between that of organic and Embedded. The
projects classified as Semi-Detached are comparatively less familiar and difficult
to develop compared to the organic ones and require more experience and better
guidance and creativity. Eg: Compilers or different Embedded Systems can be
considered of Semi-Detached types.
3. Embedded – A software project requiring the highest level of complexity,
creativity, and experience requirement fall under this category. Such software
requires a larger team size than the other two models and also the developers
need to be sufficiently experienced and creative to develop such complex models.

1. Basic COCOMO Model

 2. Intermediate COCOMO Model
3. Detailed COCOMO Model

4. Basic Model –

1. The above formula is used for the cost estimation of for the basic COCOMO model,
and also is used in the subsequent models. The constant values a,b,c and d for
the Basic Model for the different categories of system:

Software Projects a b c d

Organic 2.4 1.05 2.5 0.38

Semi Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

1. The effort is measured in Person-Months and as evident from the formula is

dependent on Kilo-Lines of code. The development time is measured in months.
These formulas are used as such in the Basic Model calculations, as not much
consideration of different factors such as reliability, expertise is taken into
account, henceforth the estimate is rough. Below is the C++ program for Basic
COCOMO

 CPP
 Python3
// C++ program to implement basic COCOMO

#include <bits/stdc++.h>

using namespace std;

// Function
// For rounding off float to int
int fround(float x)
{
int a;
x = x + 0.5;
a = x;
return (a);
}

// Function to calculate parameters of Basic COCOMO

void calculate(float table[][4], int n, char mode[][15],
int size)
{
float effort, time, staff;

int model;

// Check the mode according to size

if (size >= 2 && size <= 50)

model = 0; // organic

else if (size > 50 && size <= 300)

model = 1; // semi-detached

else if (size > 300)

model = 2; // embedded

cout << "The mode is " << mode[model];

// Calculate Effort
effort = table[model][0] * pow(size, table[model][1]);

// Calculate Time
time = table[model][2] * pow(effort, table[model][3]);

// Calculate Persons Required

staff = effort / time;

// Output the values calculated

cout << "\nEffort = " << effort << " Person-Month";

cout << "\nDevelopment Time = " << time << " Months";
 cout << "\nAverage Staff Required = " << fround(staff)
<< " Persons";
}

int main()
{
float table[3][4] = { 2.4, 1.05, 2.5, 0.38, 3.0, 1.12,
2.5, 0.35, 3.6, 1.20, 2.5, 0.32 };

char mode[][15]
= { "Organic", "Semi-Detached", "Embedded" };

int size = 4;

calculate(table, 3, mode, size);

return 0;
}
Output:
The mode is Organic
Effort = 10.289 Person-Month
Development Time = 6.06237 Months
Average Staff Required = 2 Persons
 1. Intermediate Model – The basic Cocomo model assumes that the effort is only a
function of the number of lines of code and some constants evaluated according
to the different software systems. However, in reality, no system’s effort and
schedule can be solely calculated on the basis of Lines of Code. For that, various
other factors such as reliability, experience, Capability. These factors are known
as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost
estimation. Classification of Cost Drivers and their attributes: (i) Product attributes
–
1. Required software reliability extent
2. Size of the application database
3. The complexity of the product
4. Run-time performance constraints
5. Memory constraints
6. The volatility of the virtual machine environment
7. Required turnabout time
8. Analyst capability
9. Software engineering capability
10. Applications experience
11. Virtual machine experience
12. Programming language experience
13. Use of software tools
14. Application of software engineering methods
15. Required development schedule
2. Detailed Model – Detailed COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s impact on each step
of the software engineering process. The detailed model uses different effort
multipliers for each cost driver attribute. In detailed COCOMO, the whole
software is divided into different modules and then we apply COCOMO in
different modules to estimate effort and then sum the effort. The Six phases of
detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model

Putnam Resource Allocation Model

The Lawrence Putnam model describes the time and effort required to finish a software
project of a specified size. Putnam makes a use of a so-called The Norden/Rayleigh Curve
to estimate project effort, schedule & defect rate as shown in fig:
Putnam noticed that software staffing profiles followed the well known Rayleigh distribution.
Putnam used his observation about productivity levels to derive the software equation:

The various terms of this expression are as follows:

K is the total effort expended (in PM) in product development, and L is the product estimate
in KLOC .
td correlates to the time of system and integration testing. Theref ore, td can be relatively
considered as the time required for developing the product.
Ck Is the state of technology constant and reflects requirements that impede the
development of the program.
Typical values of C k = 2 for poor development environment
Ck= 8 for good software development environment
Ck = 11 for an excellent environment (in addition to following software engineering
principles, automated tools and techniques are used).
The exact value of C k for a specific task can be computed from the historical data of the
organization developing it.
Putnam proposed that optimal staff development on a project should follow the Rayleigh
curve. Only a small number of engineers are required at the beginning of a plan to carry out
planning and specification tasks. As the project progresses and more detailed work is
necessary, the number of engineers reaches a peak. After implementation and unit testing,
the number of project staff falls.

Effect of a Schedule change on Cost

Putnam derived the following expression:

Where, K is the total effort expended (in PM) in the product development
L is the product size in KLOC
t corresponds to the time of system and integration testing
d

C Is the state of technology constant and reflects constraints that impede the progress of
k

the program
Now by using the above expression, it is obtained that,

For the same product size, C =L / C

3 3
k is a constant.

(As project development effort is equally proportional to project development cost)

From the above expression, it can be easily observed that when the schedule of a project is
compressed, the required development effort as well as project development cost increases
in proportion to the fourth power of the degree of compression. It means that a relatively
small compression in delivery schedule can result in a substantial penalty of human effort as
well as development cost.
For example, if the estimated development time is 1 year, then to develop the product in 6
months, the total effort required to develop the product (and hence the project cost)
increases 16 times.

Risk Management:
A risk is a probable problem- it might happen or it might not. There are main two
characteristics of risk
Uncertainty- the risk may or may not happen that means there are no 100% risks.
loss – If the risk occurs in reality , undesirable result or losses will occur.
Risk management is a sequence of steps that help a software team to understand , analyze
and manage uncertainty. Risk management consists of

 Risk Identification
 Risk analysis
 Risk Planning
 Risk Monitoring

A computer code project may be laid low with an outsized sort of risk. so as to be ready to
consistently establish the necessary risks which could have an effect on a computer code
project, it’s necessary to reason risks into completely different categories. The project
manager will then examine the risks from every category square measure relevant to the
project.
There square measure 3 main classes of risks that may have an effect on a computer code
project:
1. Project Risks:
Project risks concern various sorts of monetary funds, schedules, personnel,
resource, and customer-related issues. A vital project risk is schedule slippage. Since
computer code is intangible, it’s terribly tough to observe and manage a computer
code project. it’s terribly tough to manage one thing that can not be seen. For any
producing project, like producing cars, the project manager will see the merchandise
taking form.
For example, see that the engine is fitted, at the moment the area of the door unit
fitted, the automotive is obtaining painted, etc. so he will simply assess the progress
of the work and manage it. The physical property of the merchandise being
developed is a vital reason why several computer codes come to suffer from the
danger of schedule slippage.

2. Technical Risks:
Technical risks concern potential style, implementation, interfacing, testing,
and maintenance issues. Technical risks conjointly embody ambiguous
specifications, incomplete specification, dynamic specification, technical
uncertainty, and technical degeneration. Most technical risks occur thanks to
the event team’s lean information concerning the project.

3. Business Risks:
This type of risk embodies the risks of building a superb product that
nobody needs, losing monetary funds or personal commitments, etc.

Risk Management Steps in Software Engineering

Risk Management is an important part of project planning activities. It involves identifying

and estimating the probability of risks with their order of impact on the project .
Risk Management Steps:

There are some steps that need to be followed in order to reduce risk. These steps
are as follows:
1. Risk Identification:

Risk identification involves brainstorming activities. it also involves the preparation of

a risk list. Brainstorming is a group discussion technique where all the stakeholders
meet together. this technique produces new ideas and promotes creative thinking.
Preparation of risk list involves identification of risks that are occurring continuously
in previous software projects.

2. Risk Analysis and Prioritization:

It is a process that consists of the following steps:

  Identifying the problems causing risk in projects
 Identifying the probability of occurrence of problem
 Identifying the impact of problem
 Assigning values to step 2 and step 3 in the range of 1 to 10
 Calculate the risk exposure factor which is the product of values of step 2 and
step 3
 Prepare a table consisting of all the values and order risk on the basis of risk
exposure factor

For example,
TABLE (Required)

Probability of
Risk Impact of Risk
Problem occurrence of Priority
No problem exposure
problem

Issue of incorrect
R1 2 2 4 10
password

Testing reveals a
R2 1 9 9 7
lot of defects

Design is not
R3 2 7 14 5
robust

3. Risk Avoidance and Mitigation:

The purpose of this technique is to altogether eliminate the occurrence of risks. so the
method to avoid risks is to reduce the scope of projects by removing non-essential
requirements.

4. Risk Monitoring:

In this technique, the risk is monitored continuously by reevaluating the risks, the
impact of risk, and the probability of occurrence of the risk.
This ensures that:
 Risk has been reduced
 New risks are discovered
 Impact and magnitude of risk are measured

Risk Analysis
Risk analysis in project management is a sequence of processes to identify the factors that
may affect a project’s success. These processes include risk identification, analysis of risks,
risk management and control, etc. Proper risk analysis helps to control possible future
events that may harm the overall project. It is more of a pro-active than a reactive process.
How to Manage Risk?
Risk Management in Software Engineering primarily involves following activities:

Plan risk management

It is the procedure of defining how to perform risk management activities for a project.

Risk Identification
It is the procedure of determining which risk may affect the project most. This process
involves documentation of existing risks.
The input for identifying risk will be
 Risk management plan
 Project scope statement
 Cost management plan
 Schedule management plan
 Human resource management plan
 Scope baseline
 Activity cost estimates
 Activity duration estimates
 Stakeholder register
 Project documents
 Procurement documents
 Communication management plan
 Enterprise environmental factor
 Organizational process assets
 Perform qualitative risk analysis
 Perform quantitative risk analysis
 Plan risk responses
 Monitor and control risks

The output of the process will be a

 Risk register

Perform qualitative risk analysis

It is the process of prioritizing risks for further analysis of project risk or action by combining
and assessing their probability of occurrence and impact. It helps managers to lessen the
uncertainty level and concentrate on high priority risks.
Plan risk management should take place early in the project, it can impact on various
aspects for example: cost, time, scope, quality and procurement.
The inputs for qualitative Project Risk Analysis and Management includes
 Risk management plan
 Scope baseline
 Risk register
 Enterprise environmental factors
 Organizational process assets
The output of this stage would be
 Project documents updates

Quantitative risk analysis

It is the procedure of numerically analyzing the effect of identified risks on overall project
objectives. In order to minimize the project uncertainty, this kind of analysis are quite helpful
for decision making.

Risk Management Matrix

The input of this stage is

 Risk management plan
 Cost management plan
 Schedule management plan
 Risk register
 Enterprise environmental factors
 Organizational process assets
While the output will be
 Project documents updates

Plan risk responses

To enhance opportunities and to minimize threats to project objectives plan risk response is
helpful. It addresses the risks by their priority, activities into the budget, schedule, and
project management plan.

The inputs for plan risk responses are

 Risk management plan
 Risk register
While the output are
 Project management plan updates
 Project documents updates
Control Risks
Control risk is the procedure of tracking identified risks, identifying new risks, monitoring
residual risks and evaluating risk.
The inputs for this stage includes
 Software Project management plan
 Risk register
 Work performance data
 Work performance reports
The output of this stage would be
4. Work performance information
5. Change requests
6. Project management plan updates
7. Project documents updates
8. Organizational process assets updates
Printed Pages: 02 Sub Code: KCA- 302

Paper Id: 2 3 2 3 5 3 Roll No.

MCA
(SEM III) THEORY EXAMINATION 2022-23
SOFTWARE ENGINEERING
Time: 3 Hours Total Marks: 100
Note: Attempt all Sections. If you require any missing data, then choose
suitably.

SECTION A

1. Attempt all questions in brief. 2 x 10 = 20

(a) List 2 reasons for software crisis.
(b) “Software is developed or engineered; it is not manufactured in classical
sense”.
Explain
(c) Describe 2 characteristics of SRS.
(d) Describe ER Diagram
(e) Describe structure chart.
(f) List two disadvantages of Lines of Code.
(g) What are the two main activities of regression testing?
(h) Differentiate between test drivers and test stubs
(i) Define need of maintenance.
(j) Discuss the ways to avoid risk.

SECTION B

2. Attempt any three of the following: 10 x 3 = 30

(a) Discuss the prototype model. What is the effect of designing a
prototype on the overall cost of the software project?
(b) What is feasibility study? What are the contents we should contain in the
 feasibility report?
Draw a DFD for result preparation automation system of MCA Courses of
AKTU
(c) University. Clearly describe the working of that system, also mention
all assumptions made by you.
(d) What is integration testing? Explain different types of integration testing
(e) Discuss risk management? Explain how to select the best risk reduction
technique when there are many ways of reducing a risk.

SECTION C

3. Attempt any one part of the following: 10 x 1 = 10

(a) What is Software development life cycle? Discuss the process for
Spiral model. Current trends in Software Engineering are moving
away from the waterfall model
(b) for large projects and moving toward iterative methods? What are
we gaining and losing as a result? Explain with suitable examples.

4. Attempt any one part of the following: 10 x 1 = 10

(a) Discuss the significance of requirement engineering. Also write the
various steps with requirement engineering with proper explanation.
(b) What do you understand with the term “requirement elicitation”?
Discuss any two techniques.
5. Attempt any one part of the following: 10 x 1 = 10
Define Cohesion. What is Functional Cohesion? Does Functional Cohesion within
a
(a) module bring about good software design? Give an example. What
type of coupling and cohesion between/among modules is preferred
for good quality software?
(b) What is a formal technical review? What ate the objectives of formal
technical review? Give a comparative study of code inspection, reviews
and walk-through.

6. Attempt any one part of the following: 10 x 1 = 10

Consider the following source code:
void sort (int *a, int
n) { inti, j, t;
if (n < 2) return;
for (i=0; i< n-1;
i++) { for (j=i+1; j
< n; j++) { if (a[i]
> a[j]) {
(a) (b)
t ula of Halstead Analysis for Volume and Difficulty-level of the code?
Write the difference between black-box testing and white-box testing.
= Consider a program which computes the square root of an input integer
between 0 and 5000. Determine the equivalence class test cases. Determine
a the test cases using boundary value analysis also.
[
i
]
;

a
[
i
]

a
[
j
]
;

a
[
j
]

t
;
}
}
}
}
C
a
l
c
u
l
a
t
e

t
h
e

f
o
r
m
7. Attempt any one part of the following: 10 x 1 = 10
(a) Categorize the use of case tools in software engineering with their
advantages and disadvantages.
(b) What are the benefits of Software Configuration Management (SCM)?
Elaborate the activities for SCM performed during SDLC?