Q1) Essential di culties of software engineering

-Conformity
So ware must conform to exis ng systems and legisla on.
-Changeability
External causes dictate the need for change, or people
discover new uses for the product
-Invisibility
Visualiza on of So ware cannot be done. Although diagrams
can be drawn, it is not
possible to show all aspects simultaneously.

Q2) Veri cation and Validation

-Veri ca on:
Checks whether the so ware conforms to speci ca ons.
Manual inspec on of requirements, design etc.
-Valida on:
Checks whether so ware meets the customer expecta ons
and requirements.
Involves wri ng & running tests:
Black box (func onal)
White box (structural)
Grey box(Combina on of Black and White)
ft
fi
ti
ti
ti
fi

ti

ti

ti
ft
ffi

ti
ft

ft
ti

fi
ti
ti
ti

 Q3) Waterfall Model

- Water fall model is all about de ne before designing

and design before code
- Waterfall without loops helped to hold people
accountable.
Advantages:
- Uses clear structure. When compared with other
methodologies, Waterfall focuses most on a clear,
de ned set of steps. Its structure is simple
- Determines the end goal early

Disadvantages:
- Towards end, the model may throw some high-risk and
di culty .
ffi
fi

fi

 - When a working version is available only at the end, it

gets too late for the user to test and cri cize
- The cost may increase if an issue is iden ed at the
end.
- It’s di cult to respond to changing customer needs

Q4) Prototyping Model

Advantages:
- To understand the requirements
- Developed from a reasonable understanding of the
system
- Involves-design, coding and tes ng –but not formally
or thoroughly.
- Client gets an actual feel of the system
- Interac ons with prototype lets client understand
requirements of the desired system

ffi

ti

ti

ti
ti
fi

 - Client plays with valuable inputs to see what he

requires
- Risks associated with the project is reduced
Disadvantages:
- Development cost may become large with a prototype
- Requirements may keep changing, par cularly when
development takes long
- When prototypes are worked on, requirements are
frozen to an extent and further client requirements
may be closer to the actual system
Bene ts and Feedback:
- What is correct
- What needs to be modi ed
- What is missing
- What is not Missing!!!
A prototype model does not include:
- Excep on handling
- Recovery
- Conformance to some standards
- Formats
- Commen ng codes speci cally
- Parts that are well understood because prototype has
to be discarded
fi
ti

ti

fi

fi

ti

 Thus Development Approach is Quick.

Q5) Iterative Enhancement Model

Same as waterfall model but with fewer restric ons , the

phases occur in the same order but occurs in mul ple cycles.
Usable product is produces at the end of each cycle , with
newer func onality every new release.
Customers and developers specify as many requirements as
possible and prepare a SRS document.
Developers and customers then priori ze these requirements
Developers implement the speci ed requirements in one or
more cycles of design, implementa on and test based on the
de ned priori es.
fi
ti
ti

fi
ti
ti

ti
ti

 Q6) Evolutionary model

Evolu onary model is a combina on of Itera ve and

Incremental model of so ware development life cycle.
The same phases as the waterfall model occur here in a
cyclical fashion. This model di ers from itera ve
enhancement model in the sense that this does not require a
useable product at the end of each cycle. In evolu onary
development, requirements are implemented by category
rather than by priority.
This model is useful for projects using new technology that is
not well understood. This is also used for complex projects
where all func onality must be delivered at one me, but the
requirements are unstable or not well understood at the
beginning.
ti

ti

ft
ff
ti
ti
ti
ti
ti

 Q7) Spiral Model

The radial dimension of the model represents the cumula ve

costs. Each path around the spiral is indica ve of increased
costs.
Each loop of the spiral represents one phase.
One phase is split roughly into four sectors of major ac vi es
which are:
Planning: nd objec ves & constraints.
Risk Analysis: Analyze alterna ves and a empts to iden fy
and resolve the risks involved.
Development: Product development and tes ng product.
Assessment: Customer evalua on.
An important feature of the spiral model is that each phase is
completed with a review by the people concerned with the
project (designers and programmers)

fi

ti
ti

ti

tt
ti
ti

ti
ti
ti
ti

The advantage of this model is the wide range of op ons to

accommodate the good features of other life cycle models.

Q8) Agile
Agile Methods
- Focus on the code rather than the design; feedback from
people rather than planning
- Are based on an itera ve approach to so ware
development
- Are intended to deliver working so ware quickly and evolve
this quickly to meet changing requirements.
- Limited Documenta on
Agile manifesto
- Individuals and interac ons over processes and tools
- Working so ware over comprehensive documenta on
- Customer collabora on over contract nego a on
- Responding to change over following a plan

Problems With Agile

- It can be di cult to keep the interest of customers
who are involved in the process.
ffi
ft

ti

ti
ti
ti

ft
ft
ti

ti

ti
ti

 - Team members may be unsuited to the intense

involvement that characterizes agile methods.
- Priori zing changes can be di cult where there are
mul ple stakeholders. Maintaining simplicity requires
extra work.
- Contracts may be a problem as with other approaches
to itera ve development.
- Scaling agile methods for large systems is di cult.
Large systems need up-front design and some
documenta on.
Agile techniques
- Wri ng requirements as user stories
- Time boxing (Forces an itera on within a xed length
of me)
- Releases (Produce completely developed and tested
features every few weeks )
- Refactoring (team look for possible so ware
improvements and make these improvements)
- Pair programming (driver and observer)
- Test driven development
- Standup Mee ngs (Time boxed to 15 min)
- Retrospec ve (At the end of each itera on, the team
discusses achievements and problems)
ti
ti
ti
ti
ti

ti

ti
ti

ti
ffi

ft
ti

fi

ffi

 Q9) SCRUM
- Scrum is an agile process for so ware development.
- A team in SCRUM consists of about 6-9 people who work
collabora vely to achieve their goals.
- The project requirements are developed in itera ve
increments called Sprints.

• A product owner creates a priori zed wish list called a

product backlog.
• During sprint planning, the team pulls a small chunk from
the top of that wishlist, a sprint backlog, and decides how to
implement those pieces.
• The team has a certain amount of me, a sprint, to
complete its work - usually two to four weeks - but meets
each day to assess its progress (daily scrum).
• A burn down chart shows work remaining.
• Along the way, the Scrum Master keeps the team focused
on its goal.
• At the end of the sprint, the work should be poten ally
shippable, as in ready to hand to a customer, put on a store
shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospec ve.
ti

ft
ti
ti

ti
ti
ti

 • As the next sprint begins, the team chooses another chunk

of the product backlog and begins working again.
Scrum team:
3 Roles:
- Product Owner
- Scrum Master
- Team
4 Ceremonies:
- Sprint planning
- Daily Scrum
- Sprint Review
- Sprint Retrospec ve
3 Ar facts:
- Product Backlog
- Sprint Backlog
- Burn down Chart
ti

ti

 Q10) Requirement Analysis

1) A context Diagram :
A context diagram is a simple model that de nes the
boundaries and interfaces of the proposed system with the
external world.
2) Develop a prototype
3) Model The Requirements
Uses graphical representa ons of the : Func ons ,Data
en es , External En es ,Rela onships between them
etc.
Models include : DFD, ER Diagram, state machine etc.
4) Finalize the Requirements
Inconsistencies and ambigui es are iden ed and
corrected.
Understand system behavior.
Flow between modules are analyzed.
Finalize and document the requirements in a prescribed
format.
ti

ti

ti

ti
ti

ti

ti

ti
fi
ti
fi

 Q11) Functional and Non-Functional Requirements

Func onal:
What speci cally the so ware has to do or the purpose of
the so ware
Non-Func onal:
Are the quality requirements of the so ware (For Users):
-Availability
-Reliability
-Usability
-Flexibility
-Portability
-Maintainability
-Testability

Q12) What is an SRS document (Short Version)

An SRS document, or So ware Requirements Speci ca on
document, is a comprehensive descrip on of the intended
func onality and behavior of a so ware system. It serves as a
formal agreement between the client and the development
team, outlining the requirements that the so ware must
meet. The SRS document typically includes informa on such
as system overview, func onal and non-func onal
ti
ti
ft

ti

fi

ft
ft
ti
ft
ft
ti
ti
ft
fi
ti
ti

 requirements, user interfaces, system constraints, and other

relevant details to guide the development process.

Q13) Why comment Codes

- Quality depends on code comments.
- Maintenance cost depends on quality as maintenance cost
increases for bad codes.
- Some programs are carefully cra ed.
- Others are quick and too many codes not arranged.

Q14) Maintenance models

Quick Fix Model: The Quick Fix Model refers to a
maintenance approach where issues or bugs in so ware or
systems are addressed with temporary or immediate
solu ons. This model is typically used to address cri cal
issues that require urgent a en on to restore system
func onality. The quick x is o en followed by a more
comprehensive and permanent solu on in subsequent
maintenance cycles.

Itera ve Enhancement Model: The Itera ve Enhancement

Model, also known as the Incremental Model, is an itera ve
so ware development approach that involves mul ple cycles
ft
ti
ti
ti

fi

tt
ft
ti
ft
ti

ti
ft
ti

ti

ti
 of development, tes ng, and maintenance. In this model, a
basic version of the so ware is ini ally developed, and then
addi onal features and enhancements are added in
subsequent itera ons or increments. Each itera on builds
upon the previous version, and feedback from users or
stakeholders is incorporated into the subsequent itera ons.

Reuse-Oriented Model: The Reuse-Oriented Model

emphasizes the reuse of exis ng so ware components or
modules to expedite development and maintenance
processes. This model promotes the crea on, cataloging, and
management of reusable so ware assets. Reusable
components can range from code snippets and libraries to
en re subsystems or frameworks. By leveraging exis ng
components, organiza ons can reduce development e ort,
improve consistency, and enhance the maintainability of
so ware systems.

Boehm's Model: Boehm's Model, also known as the So ware

Maintenance Model, was proposed by Barry Boehm. It
outlines four categories of so ware maintenance ac vi es:
correc ve, adap ve, perfec ve, and preven ve. The model
emphasizes that maintenance e orts should be priori zed
and managed based on the type of maintenance required.
Correc ve maintenance addresses defects or issues, adap ve
maintenance adapts the so ware to changing environments
or requirements, perfec ve maintenance enhances system
ft
ti
ti
ti
ti
ti
ti

ti
ti
ft
ti
ft
ti
ft
ti
ft
ff
ti
ft
ti
ti
ti
ti
ti
ti
ti
ff
ti
ft
ti

 func onality, and preven ve maintenance aims to prevent

future issues or failures.

Taute Maintenance Model: The Taute Maintenance Model is

a so ware maintenance model proposed by Peter Taute. This
model focuses on addressing so ware maintenance
challenges and improving the overall maintenance process.
The Taute Maintenance Model emphasizes the importance of
understanding the system architecture, documen ng the
so ware, and establishing e ec ve communica on channels
among the development team. It also emphasizes the need
for con nuous monitoring, bug tracking, and feedback loops
to iden fy and resolve issues promptly.

Q15) Reengineering and reverse engineering

Reengineering: Reengineering, also known as so ware
reengineering or so ware rejuvena on, refers to the process
of transforming or restructuring an exis ng so ware system
to improve its quality, maintainability, and performance. It
involves modifying the so ware's structure, architecture, or
implementa on while preserving its external behavior and
func onality. Reengineering is o en undertaken to address
issues such as outdated technology, poor code quality, or
changing business requirements.
ft
ft
ti
ti
ti
ti
ti
ft

ti
ft
ff
ti
ft
ft

ti

ti
ft
ti
ft
ti
 The goals of reengineering typically include enhancing the
system's maintainability, scalability, and extensibility, as well
as reducing complexity, improving performance, and aligning
the so ware with current standards or best prac ces.
Reengineering may involve ac vi es such as code refactoring,
redesigning the so ware architecture, upda ng libraries or
dependencies, improving documenta on, or migra ng to a
new pla orm or framework.
Reverse Engineering: Reverse engineering is the process of
analyzing and understanding an exis ng so ware system or
component to extract informa on about its design, structure,
behavior, or func onality. It involves examining the so ware's
ar facts, such as its source code, binaries, or documenta on,
and deducing the underlying design principles or inten ons.
Reverse engineering is o en employed in scenarios where
the original design or documenta on of a so ware system is
either unavailable, incomplete, or poorly understood. It can
be useful for various purposes, such as understanding legacy
systems, integra ng with external components, iden fying
security vulnerabili es, or crea ng interoperable
implementa ons.
Reverse engineering techniques may include decompiling
binaries to obtain source code, analyzing network tra c or
system interac ons, reconstruc ng architectural diagrams, or
performing dynamic analysis to observe the so ware's
behavior. It's important to note that reverse engineering
ti
ft
tf
ti
ti
ti
ti

ft
ti
ft

ti
ti
ti
ti
ti
ti
ti
ti
ft
ti
ft
ft
ti
ti
ti
ffi
ft
ti
ti

 should be conducted with legal and ethical considera ons,

respec ng intellectual property rights and licenses.
While reengineering focuses on improving and transforming
exis ng so ware systems, reverse engineering is primarily
concerned with understanding and extrac ng knowledge
from exis ng systems. Both concepts are valuable in di erent
so ware engineering contexts and can complement each
other in the overall so ware development lifecycle.

Q16) Testing
Tes ng refers to the process of evalua ng a so ware system
or component to iden fy any defects, errors, or
discrepancies. It involves execu ng the so ware with the
intent of nding bugs or con rming that it behaves as
expected. The primary goal of tes ng is to ensure the quality
and reliability of the so ware.
Tes ng is typically performed at di erent levels of the
so ware development life cycle (SDLC), including unit tes ng,
integra on tes ng, system tes ng, and acceptance tes ng.
3 TYPES OF TESTING
Alpha Test: Alpha tes ng is an early stage of tes ng
performed on a so ware system or product by the internal
development team or a group of selected users. It is typically
conducted in a controlled environment, such as within the
organiza on or with a limited set of external testers. The
ft
ft
ti
ti
ti
ti
ti
ti
fi
ti
ft
ti
ft

ti
ti
ft
ft
fi
ti

ti
ti
ff
ti
ti
ft
ft
ti

ti
ti
ff
ti

 purpose of alpha tes ng is to assess the so ware's

func onality, iden fy bugs or defects, and gather feedback
for further improvements before releasing it to a larger
audience.
Beta Test: Beta tes ng is the next phase of tes ng that takes
place a er alpha tes ng. It involves releasing the so ware to
a larger audience, which can include external users or
customers who are willing to test the product in their real-
world environments. Beta tes ng helps evaluate the
so ware's performance, usability, and compa bility with
di erent systems. Feedback from beta testers is collected to
uncover any remaining issues, gather user insights, and make
nal re nements before the o cial release.
Acceptance Test: Acceptance tes ng, also known as user
acceptance tes ng (UAT), is the nal stage of tes ng before
the so ware is accepted for deployment or produc on use. It
is typically performed by the end users or stakeholders to
ensure that the so ware meets their speci c requirements
and business needs. The focus of acceptance tes ng is on
valida ng the so ware's func onality, usability, and
adherence to the desired business processes. Successful
comple on of acceptance tes ng indicates that the so ware
is ready for deployment or release.
3 LEVELS OF TESTING
Unit testing, Integration testing and System
testing.
fi
ff
ft
ti
ti
ft
fi
ft
ti

ti
ft
ti
ft
ti
ti
ti


ti
ti
ti
ffi
fi
ti

fi
ft

ti
ti
ti
ti
ti
ft
ft
 Q17) What is an SRS document
An SRS (So ware Requirements Speci ca on) document is a
comprehensive document that outlines the func onal and
non-func onal requirements of a so ware system. It serves
as a formal agreement between the stakeholders (clients,
users, development team, etc.) and the so ware
development team. The SRS document acts as a founda on
for the so ware development process by providing a clear
understanding of what the so ware should accomplish.
Here are the key components typically found in an SRS
document:
Introduc on: Provides an overview of the so ware system,
its purpose, and the intended audience of the document.
Scope: De nes the boundaries and limita ons of the
so ware system, including its features, func onali es, and
interfaces.
Func onal Requirements: Describes the speci c behaviors
and func ons that the so ware system should exhibit. This
sec on outlines the system's inputs, outputs, processes, and
any constraints or dependencies.
Non-func onal Requirements: Speci es the quality
a ributes or characteris cs that the so ware system should
possess, such as performance, reliability, security, usability,
and scalability.
tt
ft
ti
ti
ti
ti
ti
ti
ft
fi

ft

ti
ft
ft

ft
fi
fi
ft
ti
ti
ft
ti
ft
fi
ti
ti
ti

 User Interfaces: Describes the graphical user interfaces

(GUIs), command-line interfaces, or other interfaces that
users will interact with.
System Interfaces: Iden es the external systems,
components, or databases with which the so ware system
needs to interact.
Constraints: Speci es any constraints or limita ons that must
be taken into account during the so ware development
process, such as me, budget, or technology restric ons.
The SRS document acts as a reference for the development
team to design, implement, and test the so ware system. It
also serves as a basis for project planning, es ma on, and
tracking.

ti

fi

ti
fi
ft
ft
ti
ft
ti
ti
ti

FP = UFP * CAF