Verification Validation

It includes checking documents, design, It includes testing and validating the actual
codes and programs. product.
Verification is the static testing. Validation is the dynamic testing.
It does not include the execution of the It includes the execution of the code.
code.
Methods used in verification are reviews, Methods used in validation are Black Box
walkthroughs, inspections and desk- Testing, White Box Testing and non-
checking. functional testing.
It checks whether the software conforms It checks whether the software meets the
to specifications or not. requirements and expectations of a
customer or not.
It can find the bugs in the early stage of the It can only find the bugs that could not be
development. found by the verification process.
The goal of verification is application and The goal of validation is an actual product.
software architecture and specification.
Quality assurance team does verification. Validation is executed on software code
with the help of testing team.
It comes before validation. It comes after verification.
It consists of checking of documents/files It consists of execution of program and is
and is performed by human. performed by computer.

Black Box Testing White Box Testing

It is a way of software testing in which the It is a way of testing the software in which
internal structure or the program or the the tester has knowledge about the internal
code is hidden and nothing is known structure or the code or the program of the
about it. software.
Implementation of code is not needed for Code implementation is necessary for white
black box testing. box testing.
It is mostly done by software testers. It is mostly done by software developers.
No knowledge of implementation is Knowledge of implementation is required.
needed.
It can be referred to as outer or external It is the inner or the internal software
software testing. testing.
It is a functional test of the software. It is a structural test of the software.
This testing can be initiated based on the This type of testing of software is started
requirement specifications document. after a detail design document.
No knowledge of programming is It is mandatory to have knowledge of
required. programming.
It is the behavior testing of the software. It is the logic testing of the software.
It is applicable to the higher levels of It is generally applicable to the lower levels
testing of software. of software testing.
It is also called closed testing. It is also called as clear box testing.
It is least time consuming. It is most time consuming.
Alpha Testing Beta Testing
Alpha testing involves both the white box Beta testing commonly uses black-box
and black box testing. testing.
Alpha testing is performed by testers who Beta testing is performed by clients who
are usually internal employees of the are not part of the organization.
organization.
Alpha testing is performed at the Beta testing is performed at the end-user
developer’s site. of the product.
Reliability and security testing are not Reliability, security and robustness are
checked in alpha testing. checked during beta testing.
Alpha testing ensures the quality of the Beta testing also concentrates on the
product before forwarding to beta testing. quality of the product but collects users
input on the product and ensures that the
product is ready for real time users.
Alpha testing requires a testing Beta testing doesn’t require a testing
environment or a lab. environment or lab.
Alpha testing may require a long execution Beta testing requires only a few weeks of
cycle. execution.
Developers can immediately address the Most of the issues or feedback collected
critical issues or fixes in alpha testing. from the beta testing will be implemented
in future versions of the product.
Multiple test cycles are organized in alpha Only one or two test cycles are there in
testing. beta testing.

Manual Testing Automation Testing

For observation manual testing allow human For observation automation testing does
factor. not allow human factor.
Manual testing checks the user-friendliness. Automation testing can not give the
guarantee of user-friendliness.
In manual testing investment is required for In automation testing investment is
humans resources because here humans test required for automation tools because
the software instead of any software tools. here testing is done by some software
tools.
Manual testing is time consuming because Automation testing is not time consuming
here process is done by humans or manual. because here process is done by some
software tools.
In manual testing, there is a chance of human In automation testing, there is no chance
errors because here testing is done by of human errors because here testing is
humans. done by tools.
In manual testing, there is a possibility of In automation testing, there is no
Exploratory testing. permission of random testing.
In manual testing, there is no need of In automation testing, there is must a need
programming knowledge. of programming knowledge.
Manual testing doesn’t use frameworks. Automation testing uses frameworks like
Data Drive, Keyword etc.
Cohesion Coupling
Cohesion is the concept of intra-module. Coupling is the concept of inter-module.
Cohesion represents the relationship Coupling represents the relationships
within a module. between modules.
Increasing cohesion is good for software. Increasing coupling is avoided for software.
Cohesion represents the functional Coupling represents the independence
strength of modules. among modules.
Highly cohesive gives the best software. Whereas loosely coupling gives the best
software.
In cohesion, the module focuses on a single In coupling, modules are connected to the
thing. other modules.
Cohesion is created between the same Coupling is created between two different
module. modules.
There are Six types of Cohesion There are Six types of Coupling
1. Functional Cohesion. 1. Common Coupling.
2. Procedural Cohesion. 2. External Coupling.
3. Temporal Cohesion. 3. Control Coupling.
4. Sequential Cohesion. 4. Stamp Coupling.
5. Layer Cohesion. 5. Data Coupling
6. Communication Cohesion. 6. Content Coupling.

Waterfall Model Incremental Model

Need for Detailed Documentation in the The need for Detailed Documentation in the
waterfall model is Necessary. incremental model is Necessary but not too
much.
In the waterfall model, early stage In an incremental model, early-stage planning
planning is necessary. is also necessary.
There is a high amount of risk in the There is a low amount of risk in the
waterfall model. incremental model.
There is a long waiting time for running There is a short waiting time for running
software in the waterfall model. software in the incremental model.
The waterfall model can’t handle large The incremental model also can’t handle large
projects. projects.
Flexibility to change in the waterfall Flexibility to change in incremental model is
model is Difficult. Easy.
The cost of the Waterfall model is Low. The cost of the incremental model is also Low.
Testing is done in the waterfall model Testing is done in the incremental model after
after the completion of the coding every iteration of the phase.
phase.
Returning to the previous stage/phase in Returning to the previous stage/phase in the
the waterfall model is not possible. incremental model is possible.
In the waterfall model, a large team is In an incremental model large team is n
required.
Waterfall Model Spiral Model
The Waterfall model is simple and easy. The spiral model is a lot more complex.
The waterfall model works in a sequential While the spiral model works in the
method. evolutionary method.
In the waterfall model errors or risks are In the spiral model errors or risks are
identified and rectified after the completion identified and rectified earlier.
of stages.
The waterfall model is adopted by While the spiral model is adopted by
customers. developers.
The waterfall model is applicable for small While the Spiral model is used for large
projects. projects.
In waterfall model requirements and early While in spiral model requirements and
stage planning is necessary. early stage planning is necessary if
required.
Flexibility to change in waterfall model is Flexibility to change in spiral model is not
Difficult. Difficult.
There is high amount risk in waterfall There is low amount risk in spiral model.
model.
Waterfall model is comparatively While cost of spiral model is very
inexpensive. expensive.
Customer involvement is minimum in In the Spiral Model Customer involvement
Waterfall Model is high.

FTR Walkthrough
A formal technical review is a software It is led by the authors.Author,guide the
quality assurance activity performed by participants through the document according to
software engineers(and others). his or her,thought process to achieve a common
understanding and to gather feedback.
In a review, a work product is examined In a Walkthrough,the producer describes the
for defects by individuals other than the product and asks for comments from the
person who produced it. participants.
A Work Product is any important Walkthroughs are usually used to examine
deliverable created during the source code as opposed to design and
requirements, design, coding, or testing requirements documents. The participants do a
phase of software development. step-by-step, line-by-line simulation of the code.
It is often performed as a peer review A walkthrough is especially useful for,higher-
without management participation. level documents, such as requirement
specifications and architectural,documents.
The FTR is actually a class of reviews Walkthrough is a type of Formal Technical
that includes walkthroughs, Review
inspections,round-robin reviews and
other small group technical
assessments of software
 Scrum Kanban
It defines the role of each member of the There is no role assigned to individuals.
Scrum team.
It follows the iterative method. It does not follow the iterative approach
To solve a problem, it breaks it into small It does not break a problem into sub-
tasks and then processes it further. problems.
It is a highly prescriptive approach. It is not much prescriptive as compared to
Scrum.
There is no visualization process to perform There is a visualization process to perform
tasks. tasks.
There are sprints that keep track of the They use task cards to keep track of the
progress of any project. progress of any project.
It is processed in successive sprints to It is used to optimize the task to complete a
complete a task. project.
It is not preferred when resources are It is preferred when tasks and resources
limited. are limited.
Scrum Master is the problem solver in case All the members are allowed to pick a
of a problem. problem and solve it.
The process does not get disturbed if a The flow of work gets disturbed if a team
team member leaves in between a sprint. member leaves in between.

1) What are the design principles

Following are important design principles:
1. The design process should not suffer from 'tunnel vision'.
2. 2 The design should be traceable to the analysis model.
3. The design should not reinvent the wheel.
4. The design should "minimize the intellectual distance" between the
software and the problem as it exists in the real world.
5. The design should exhibit uniformity and integration.
6. The design should be structured to accommodate change.
7. The design should be structured to degrade gently, even when unusual
data, events, or operating conditions are encountered.
8. Design is not coding, coding is not design.
9. The design should be assessed for quality as it is being created, not after
the creation.
10. The design should be reviewed to minimize conceptual (semantic) errors.
2) Waterfall model
• Waterfall model is the first approach used in software development process.
• It is also called as classical life cycle model or linear sequential model.
• In waterfall model any phase of development process begins only if previous phase is
completed.
1. Requirement Analysis:In this phase all business requirements of system are gathered
and analyzed by communication between stakeholders and customer or user.At the end
of this phase Requirement Specification Document (SRS) is created.
2. Design:Based on requirement, specification document design of system is created called
software architecture. It is blue print of system representing system's internal structure
and behavior.
3. Implementation:In implementation phase actual coding is constructed for software
architecture using hardware and software requirements of system.It is responsibility of
developer.
4. Verification / Testing:Here coding or job done by developer is verified against
requirements of user in order to ensure that software will satisfy all business
requirements of user.After the successful verification software is deployed at user's site
for their use. 5.
5. Maintenance:While using software if user faces some problems, then those problems
must be solved time to time by development team. This task comes under maintenance
of software.Maintenance also includes adding new functionalities in software as per
user requirements.

3) Incremental Model
Incremental Model is a process of software development where requirements divided
into multiple standalone modules of the software development cycle. In this model,
each module goes through the requirements, design, implementation and testing
phases. Every subsequent release of the module adds function to the previous release.
The process continues until the complete system achieved.

1. Requirement analysis: In the first phase of the incremental model, the product
analysis expertise identifies the requirements. And the system functional
requirements are understood by the requirement analysis team. To develop the
software under the incremental model, this phase performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the
design of the system functionality and the development method are finished with
success. When software develops new practicality, the incremental model uses style
and development phase.
3. Testing: In the incremental model, the testing phase checks the performance of
each existing function as well as additional functionality. In the testing phase, the
various methods are used to test the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the
development system. It involves the final coding that design in the designing and
development phase and tests the functionality in the testing phase. After
completion of this phase, the number of the product working is enhanced and
upgraded up to the final system product

4) Prototyping Model
The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models). This model is used when the customers do not know the exact project
requirements beforehand. In this model, a prototype of the end product is first developed,
tested, and refined as per customer feedback repeatedly till a final acceptable prototype is
achieved which forms the basis for developing the final product.

Steps Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in designing a prototype
model. In this phase, users are asked about what they expect or what they want from the
system.
Step 2: Quick Design: This is the second step in Prototyping Model. This model covers the
basic design of the requirement through which a quick overview can be easily described.
Step 3: Build a Prototype: This step helps in building an actual prototype from the
knowledge gained from prototype design.
Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strength and
weaknesses of the design, which was sent to the developer.

Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s
response to feedback and suggestions, the final system is approved.
Step 6: Implement Product and Maintain: This is the final step in the phase of the
Prototyping Model where the final system is tested and distributed to production, here
program is run regularly to prevent failures.

5) What are the potential problems of Prototyping Model?

1) Refining of prototype continues until user is completely satisfied, thus it is time
consuming and expensive process.
2) More involvement of user in development process is not accepted by developer
always. Refining of prototype again and again may disturb the working of
development team
3) Practically prototyping model results in increasing the complexity of system as scope
of system extende beyond original plan.
6) Spiral Model
Spiral model is a combination of iterative model and waterfall model. Spiral model has four
phases of development each of these phases is called as spiral.
1) Identification:This phase identifies all business requirements of system at the beginning.
It involves clear understanding of requirements by communication between
stakeholders and customer. In the subsequent iterations all subsystemrequirements and
unit requirements are identified.
2) Design:In first iteration, design phase develops conceptual design of system based on
initially gathered requirements.In further spirals or iterations, it develops logical design,
physical design, architectural design and final design of system.
3) Construct:Initially construct phase develops a code for conceptual design to get user
feedback.In next subsequent spirals, detailed working model of software is constructed
with increment number and are delivered to customer for feedback.
4) Evaluation and risk analysis:In this phase management risks like cost overrun are
identified and monitored, technical feasibility of system is also done.At end of each
spiral customer evaluates software for potential risks in system and provides
feedback.Spiral model can be used for projects where budget and risk evaluation are
important factors. If customers are not sure about their requirements then spiral model
is useful than waterfall model
Advantages of spiral model
1) It is more flexible to changing requirements.
2) Requirements are achieved more accurately.
3) User can see the system from 1st iteration to end of development.
4) Risk management is easier.
Disadvantages of spiral model
1) It is difficult to manage development process.
2) Not useful for small projects development.
3) Spiral can run indefinitely.
4) It requires excessive documentation work as documentation is prepared for each
iteration

Application:
1) When there is a budget constraint and risk evaluation is important.
2) For medium to high-risk projects.
3) Long-term project commitment because of potential changes to economic priorities
as the requirements change with time.
4) Customer is not sure of their requirements which is usually the case.
5) Requirements are complex and need evaluation to get clarity.
6) New product line which should be released in phases to get enough customer
feedback.
7) V-Model
V-Model also referred to as the Verification and Validation Model. In this, each phase
of SDLC must complete before the next phase starts. It follows a sequential design
process same as the waterfall model. Testing of the device is planned in parallel with
a corresponding stage of development.

Verification: It involves a static analysis method (review) done without executing

code. It is the process of evaluation of the product development process to find
whether specified requirements meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is

done by executing code. Validation is the process to classify the software after the
completion of the development process to determine whether the software meets the
customer expectations and requirements.

So V-Model contains Verification phases on one side of the Validation phases on the
other side. Verification and Validation process is joined by coding phase in V-shape.
Thus it is known as V-Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product

requirements understood from the customer's side. This phase contains
detailed communication to understand customer's expectations and exact
requirements.
 2. System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements document.
3. Architecture Design: The baseline in selecting the architecture is that it should
understand all which typically consists of the list of modules, brief functionality
of each module, their interface relationships, dependencies, database tables,
architecture diagrams, technology detail, etc. The integration testing model is
carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks down into
small modules. The detailed design of the modules is specified, which is known
as Low-Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the
requirements, a suitable programming language is decided. There are some
guidelines and standards for coding. Before checking in the repository, the final
build is optimized for better performance, and the code goes through many
code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the
module design phase. These UTPs are executed to eliminate errors at code level
or unit level. A unit is the smallest entity which can independently exist, e.g., a
program module. Unit testing verifies that the smallest entity can function
correctly when isolated from the rest of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created and tested
independently can coexist and communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design
Phase. Unlike Unit and Integration Test Plans, System Tests Plans are composed
by the client?s business team. System Test ensures that expectations from an
application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement
analysis part. It includes testing the software product in user atmosphere.
Acceptance tests reveal the compatibility problems with the different systems,
which is available within the user atmosphere. It conjointly discovers the non-
functional problems like load and performance defects within the real user
atmosphere.
8) Agile Process Model
Agile software development describes an approach to software development under which
requirements and solutions evolve through the collaborative effort of self-organizing and
cross-functional teams and their customers (end users).It advocates adaptive planning,
evolutionary development, early delivery, and continual improvement. and it encourages
rapid and flexible response to change.The term Agile was popularized, in this context, by the
Manifesto for Agile Software Development. The values and principles adopted in this
manifesto were derived from and underpin a broad range of software development
frameworks, including Scrum and Kanban.There is significant subjective evidence that
adopting agile practices and values improves the agility of software professionals, teams
and organizations.
Agile software development values
Based on their combined experience of developing software and helping others do that, the
seventeen signatories to the manifesto proclaimed that they value:

• Individuals and Interactions over processes and tools.

• Working Software over comprehensive documentation.
• Customer Collaboration over contract negotiation.
• Responding to Change over following a plan.

Agility Principle
1) The Manifesto for Agile Software Development is based on twelve principles:
2) Customer satisfaction by early and continuous delivery of valuable software.
3) Welcome changing requirements, even in late development.
4) Working software is delivered frequently (weeks rather than months).
5) Close, daily cooperation between business people and developers.
6) Projects are built around motivated individuals, who should be trusted.
7) Face-to-face conversation is the best form of communication (co-location).
8) Working software is the primary measure of progress.
9) Sustainable development, able to maintain a constant pace.
10) Continuous attention to technical excellence and good design.
11) Simplicity is essential.
12) Best architectures, requirements, and designs emerge from self-organizing teams.
13) Regularly, the team reflects on how to become more effective, and adjusts
accordingly

Advantages of Agile Process

4) Stakeholder Engagement, 1) Predictable Costs and
5) Early and Predictable Delivery, Schedule,
6) Allows for Change, 2) Focuses on Business
7) Focuses on Users, Value,
8) Transparency, 3) Improves Quality.
9) Extreme Programming (XP)
• Extreme Programming (XP) is a software development methodology which is intended
to improve software quality and responsiveness to changing customer requirements
• .As a type of agile software development, it advocates frequent "releases" in short
development cycles, which is intended to improve productivity and introduce
checkpoints at which new customer requirements can be adopted.
• Other elements of extreme programming include: Programming in pairs or doing
extensive code review, unit testing of all code, avoiding programming of features until
they are actually. needed, a flat management structure, code simplicity and clarity,
expecting changes in the customer's requirements as time passes and the problem is
better understood, and frequent communication with the customer and among
programmers.
• The methodology takes its name from the idea that the beneficial elements of
traditional software engineering practices are taken to "extreme" levels.
• As an example, code reviews are considered a beneficial practice; taken to the extreme,
code can be reviewed continuously. i.e. the practice of pair programming.
10) SCRUM
• Scrum is an agile framework for managing knowledge work, with an emphasis on
software development.
• It is designed for teams of three to nine members, who break their work into actions
that can be completed within time boxed iterations, called "sprints", no longer than one
month and most commonly two weeks, then track progress and re-plan in 15-minute
stand-up meetings, called daily scrums.
• Scrum principles are mostly based on the agile manifesto and help to guide activities
regarding development inside a process which includes framework activities such as
requirements, analysis, design, evolution, and delivery.
• In all the framework activities, work tasks happen within a process pattern called a
sprint.Scrum mostly focus on the use of a bunch of software process patterns which are
proved effective for projects with restrictive timelines, changing requirements, and
business criticality. All such process patterns defines several sets of development
actions:
• Backlog A prioritized list regarding project needs or features which offer business value
for the customer. It is possible to add items to the backlog at any time. The respective
product manager assesses the backlog and changes the priorities as per necessity.
• Sprints Includes work units which are necessary to gain a requirement defined in the
backlog which should be incorporated in predefined time-box (usually thirty days).
• Modifications (such as backlog work items) are not involved during the sprint. Therefore,
team members are allowed by the sprint to work in a short-term, but stable
environment.Scrum meetings are short (usually fifteen minutes) meetings conducted on
daily basis by the Bum Madale team. Three most important key questions which are
asked and must be answered by all team members are
1) What did you do since the last team meeting 7
2) What obstacles are you encountering?
3) What do you plan to accomplish by the next team meeting?.
• A team leader, who is known as a Scrum master, handles the meeting and evaluates the
responses from each person
• The important use of Scrum meeting to the team is that it can uncover critical issues as
early as possible
• One more benefit of these daily meetings in that they lead to "knowledge socialization"
and thus encourage a self-organizing team structure.
• Demos implement the software increment at the client side (customer) so that the
newly developed functionality can be demonstrated as well as evaluated by the
customer.
• It is also possible that the demo may not able to contain all planned functionality, but
instead such functions which can be delivered within the established time-box.
11) Requirement Elicitation
In requirements engineering, requirements elicitation is the practice of researching and
discovering the requirements of a system from users, customers, and other stakeholders.
The practice is also sometimes referred to as "requirement gathering". The term elicitation
is used in books and research to raise the fact that good requirements cannot just be
collected from the customer, as would be indicated by the name requirements gathering
Requirements elicitation is non-trivial because you can never be sure you get all
requirements from the user and customer by just asking them what the system should do
OR NOT do (for Safety and Reliability).Requirements elicitation practices include interviews,
questionnaires, user observation, workshops, brainstorming, use cases, role playing and
prototyping .Before requirements can be analysed , modeled, or specified they must be
gathered through an elicitation process. Requirements elicitation is a part of the
requirements engineering process, usually followed by analysis and specification of the
requirements.
There are different ways to identify customer requirement:
1) interviews :IInterviews are important way for gathering requirements. Organization may
take various kinds of interviews such as: Structured or closed interviews in which
information to be collected from customer is decided in advance Non-structured or
open interviews in which details needs to be collected from customer are decided in
advance .Oral interviews .Written interviews .Face-to-face interviews which are held
among two people across the table. Groups of persons are participating in group
interviews They support to cover any missing requirement as number of people
participates in this process
2) Task analysis: In this technique, team of software developers and engineers may identify
the functional specifications for which the new system is needed to develop If the
customer has some software to do the particular operations then it is analyzed by this
team to find out requirements for proposed system
3) Domain Analysis :Each software put into some domain category. The experienced
persons in that domain can be a great support to study general and specific
requirements.
4) Brainstorming :Brainstorming is an informal debate held between different stakeholders
and all their suggestions are e documented for further requirement analysis.
5) Prototyping: Prototyping is a technique in which, we create user interface without
including detail functionality for C user to interpret features of desired software product.
It supports providing details about requirements ,If the client does not know its own
requirements, in such case the developer develop a prototype based on requirements
provided at initial stage. The prototype is displayed to the client and the feedback is
collected from client
6) Surveys: Organization may perform surveys of different stakeholders by questioning
them about their requirements and expectation from the proposed software system
.The advantage of this technique is that, collecting requirements is economically
beneficial because it collects requirements from a large number of persons at same time
12) Functional Requirements
The Functional requirements specification create document regarding the operations as well
activities which a system must be able to carry out In software engineering, a functional
requirement is used to define a function regarding a system or its component, in which a
function is described as a specification of behavior between outputs and inputs In the
functional requirements there may be elements such as calculations, technical details, data
manipulation and processing, and other specific functionality which define what a system is
supposed to implementAs defined in requirements engineering, functional requirements is
used to mention specific results of system a This should be contrasted with non-functional
requirements that mention overall characteristics like as cost and reliability. Functional
requirements drive the application architecture of a system, while non requirements drive
the technical architecture of a system functional
Functional Requirements should include

• Descriptions of data to be entered into the system

• Descriptions of operations performed by each screen.
• Descriptions of work-flows performed by the system.
• Descriptions of system reports or other outputs
• Persons who can enter the data into the system,
• Way the system meets applicable regulatory requirements.

Examples of Functional Requirements

Functional requirements must contain functions performed by specific screens, outlines of
work-flows performed by the system, and other business or compliance requirements the
system must meet
Interface requirements

• Field 1 accepts numeric data entry

• Field 2 only accepts dates before the current date.
• Screen I can print on-screen data to the printer
Business Requirements

• Data must be entered before a request can be approved

• Clicking the Approve button moves the request to the Approval Workflow.
• All personnel using the system will be trained.
Regulatory/Compliance Requirements

• The database will have a functional audit trail

• The system will limit access to authorized users.
• The spreadsheet can secure data with electronic signatures.
13) Non Functional Requirements (NFR)
➢ These are basically the quality constraints that the system must satisfy according to the
project contract.
➢ The priority or extent to which these factors are implemented varies from one project to
other. They are also called non-behavioral requirements. They basically deal with issues
like
• Portability
• Reliability
• Reusability
• Security
• Scalability
• Flexibility
• Maintainability
• Performance
➢ NFRs are classified into following types:
• Interface constraints
• Operating constraints
• Economic constraints
• Performance constraints: response time, security, storage space, etc.
• Life cycle constraints: maintainability, portability, etc
➢ The process of specifying non-functional requirements needs the knowledge of the
functionality of the system, and also the knowledge of the context within which the
system will operate.

Types of Non-functional Requirement:

1) Product requirements: Requirements which mention that the delivered product should
have behavior in a specific way, e.g. execution speed, reliability etc
2) Organizational requirements: Requirements that are a result of organizational policies
as well as procedures, such as process standards which has been used, implementation
necessities etc.
3) External requirements: Requirements which are generated from the factors that are
external to the system and its development process, e.g. interoperability requirements,
legislative requirement.
14) Software Requirement Specification Document Format (IEEE)
• SRS stands for Software/System Requirement Specification. SRS is a special kind of
document which contains user requirements for a system which states properties and
constraints that must be satisfied by a software system.
• IEEE defines software requirements specification as, a document that clearly and
precisely describes each of the essential requirements (functions, performance, design
constraints and quality attributes) of the software and the external interfaces,
• The outcome of the requirements gathering and analysis phase of the SDLC is Software
Requirements Specification (SRS).
• SRS is also called as requirements document
• SRS is base for software engineering actions and is generated when all requirements of
software project are gathered and analyzed.
• It is generally signed at the end of requirements engineering phase
Following are 6 requirements stated by Heninger, which SRS document should follow-

1) SRS document should specify external system behaviour.

2) SRS document should specify implementation constraints.
3) It should be easily changeable if any changes occur.
4) It should act as reference tool for maintaining the system.
5) SRS document record forethought about the lifecycle of the system i.e. predicts changes.
6) It must include acceptable response to undesired events.

Advantages of SRS
1) SRS contains the base for agreement among the client and the company who develop
the product as per expectations.
2) A SRS gives a base for verification of the completely developed product.
3) Using high-quality SRS, we can develop high-quality software product.
4) A high-quality SRS decreases the cost of development.
15) Management Spectrum, 3ps (People, Product And Process)
• The management spectrum describes the management of a software project or how
to make a project successful
• Its focus is on the three Pe; People, Product and Process Here, the manager of the
project has to control all these Ps to have a smooth flow in the project progress and
to reach the goal.
• We will see all of those three Pa of management spectrum in detail
1. The People

• People of a project includes from manager to developer, from customer to end user
• But mainly people of a project highlight the developers.
• It is so significant to have highly skilled as well as motivated developers that a PM-
CMM (People Management Capability Maturity Model) is developed by the Software
Engineering Institute to enhance the readiness of software enterprises to handle
more and more robust applications by assisting to attract, grow, motivate, deploy,
and retain the talent necessary for the improvement of their software development
capability.
• Enterprises which attain high levels of maturity in the area of people management
have a great probability of carrying efficient software engineering practices.
2. The Product

• Product is nothing but any software which has to be designed and developed. For
successful development of product there is need to set product objectives and
scope, there must be consideration of substitute solutions, and also identification of
technical and management constraints must be done.
• If there is lack of this information, it is not possible to define reasonable as well as
correct estimates of the cost, an efficient estimation of risk, a practical breakdown of
project tasks or a controllable project schedule which provides a meaningful
indication of progress
3. The Process

• A software process is used to provide the framework from which it is possible to

establish a completemplan for software development:
• There are different elements such as different tasks, milestones, work products, as
well as quality assurance points which help to enable the framework regarding
activities to be made compatible with the functionalities of the respective software
project and the related necessities of the project team.
• At last, umbrella activities handle the process model. Umbrella activities are not
dependent on any one framework activity and are carried out throughout the whole
process.
16) Functional Point (FP) Analysis
FPA provides a standardized method to functionally size the software work product. This
work product is the output of software new development and improvement projects for
subsequent releases. It is the software that is relocated to the production application at
project implementation. It measures functionality from the user’s point of view i.e. on the
basis of what the user requests and receives in return. Function Point Analysis (FPA) is a
method or set of rules of Functional Size Measurement. It assesses the functionality
delivered to its users, based on the user’s external view of the functional requirements. It
measures the logical view of an application, not the physically implemented view or the
internal technical view. The Function Point Analysis technique is used to analyze the
functionality delivered by software and Unadjusted Function Point (UFP) is the unit of
measurement.
Objectives of FPA:

1) The objective of FPA is to measure the functionality that the user requests and
receives.
2) The objective of FPA is to measure software development and maintenance
independently of the technology used for implementation.
3) It should be simple enough to minimize the overhead of the measurement process.
Benefits of FPA:
1) FPA is a tool to determine the size of a purchased application package by counting all the
functions included in the package.
2) It is a tool to help users discover the benefit of an application package to their
organization by counting functions that specifically match their requirements.

17) Write note on LOC

• LOC is the simplest among all metrics available to estimate project size. This metric is
very popular because it is the simplest to use.
• Using this metric, the project size is estimated by counting the number of source
instructions in the developed program.
• While counting the number of source instructions, lines used for commenting the
code and the header lines should be ignored.
• Determining the LOC count at the end of a project is a very simple job. However,
accurate estimation of the LOC count at the beginning of a project is very difficult.
• In order to estimate the LOC count at the beginning of a project, project managers
usually divide the problem into modules, and each module into sub-modules and so
on, until the sizes of the different leaf- level modules can be approximately
predicted.
• To be able to do this, past experience in developing similar products is helpful. By
using the estimation of the lowest level modules, project managers arrive at the
total size estimation
18) COCOMO Model
• Boehm proposed COCOMO (Constructive Cost Estimation Model) in
1981.COCOMO is one of the most generally used software estimation models in
the world. COCOMO predicts the efforts and schedule of a software product based
on the size of the software.
• The necessary steps in this model are:
1) Get an initial estimate of the development effort from evaluation of thousands of
delivered lines of source code (KDLOC).
2) Determine a set of 15 multiplying factors from various attributes of the project.
3) Calculate the effort estimate by multiplying the initial estimate with all the multiplying
factors i.e., multiply the values in step1 and step2.
• The initial estimate (also called nominal estimate) is determined by an equation of
the form used in the static single variable models, using KDLOC as the measure of
the size. To determine the initial effort Ei in person-months the equation used is
of the type is shown below Ei=a*(KDLOC)b
• The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1) Organic
2) Semidetached
3) Embedded
1. Organic: A development project can be treated of the organic type, if the project
deals with developing a well-understood application program, the size of the
development team is reasonably small, and the team members are experienced in
developing similar methods of projects. Examples of this type of projects are simple
business systems, simple inventory management systems, and data processing
systems.
2. Semidetached: A development project can be treated with semidetached type if
the development consists of a mixture of experienced and inexperienced staff.
Team members may have finite experience in related systems but may be
unfamiliar with some aspects of the order being developed. Example of
Semidetached system includes developing a new operating system (OS), a
Database Management System (DBMS), and complex inventory management
system.
3. Embedded: A development project is treated to be of an embedded type, if the
software being developed is strongly coupled to complex hardware, or if the
stringent regulations on the operational method exist. For Example: ATM, Air Traffic
control. For three product categories, Bohem provides a different set of expression
to predict effort (in a unit of person month)and development time from the size of
19) COHESION
Cohesion define the degree to which components of system are related to each other i.e. it
measures the strength of relationship between two components of system.Good system
design must have high cohesion between the components of system.

1. Co-incidental cohesion:An unplanned cohesion which results into decomposition of a

program into smaller components for the modularization of system is called co-
incidental cohesion.Typically these types of cohesions are never accepted.
2. Logical cohesion:When logically classified elements are combined into a single module
then it is called as logical cohesion. Here all elements of modules contribute to same
system operation.
3. Temporal cohesion:Temporal cohesion occurs when component of a system performs
more than one function and these functions must occur within same time span.It is
generally found in initiation and termination activities.
4. Procedural cohesion:When components of system are related to each other only by
sequence then there exists procedural cohesion.Loop in programming language is good
example of procedural cohesion.
5. Communication cohesion:When elements of module perform different functions but
each function accepts same input and generates same output then that module is said
to be communicational cohesive.It is sometimes acceptable if no other alternative is
easily found.
6. Sequential cohesion:A module is said to be sequentially cohesive if its functions are
related in a way such that output of one function acts as an input data to other function.
This type of cohesion is easily maintainable.
7. Functional cohesion:If elements of module are grouped together since they contribute
to a single function then such a module is functionally cohesive module.All elements of
such a module are necessary for successful execution of function.

Advantages of Cohesion
1. High cohesion among system components results in Better program design.
2. High cohesion components can be easily reused.
3. High cohesion components are more reliable.
Disadvantages of Cohesion
1. Low cohesion components are difficult to maintain
2. Low cohesion components cannot be reused.
3. Low cohesion components are difficult to understand.
4. Low cohesion components are less reliable.
20) COUPLING
Coupling is an indication of strength of interconnection between various components of a
system.Highly coupled components are more dependent on each other whereas low
coupled components are less dependent or almost independent on each other.Good design
always has low coupling between components of system
1)Data coupling:Data coupling occurs between two components of system when they pass
data to each other by parameters using argument list and each element in argument list is
used. A component becomes difficult to maintain if too many parameters are passed.
2)Control coupling:When data are passed between two components and that affects
internal there exists control coupling between those two components.It passes the control
flags between system components.
3)Common coupling:Common coupling is also called as global coupling since in these
coupling components of system communicates with each other by using global
area.Common coupling becomes difficult to track when data in global area is changed.
4)Content coupling:When one component refers to the internals of the other component
then those two components are said to be content coupled.As content coupling is worst
type of coupling it should not be used in designing.

5)External coupling:If two components of system share an externally imposed data format,
communication protocol or device interface then they are said to be externally
coupled.External coupling refers to communication between system components and
external tools or devices
6)Message coupling:Message coupling occurs between two components of system when
those components communicate with each other via message passing.In this coupling
components are independent of each other, thus it is low type coupling.
7) coupling:Stamp coupling occurs between two components of system when data between
them are passed by arguments using a data structure containing elements which may or
may not be used.Stamp coupling is also low type coupling.
Advantages of Coupling
1. Low coupling components do not force ripple effect to other components.
2. Low coupled components can be reused.
3. With low coupling among components, system can built faster.
Disadvantages of Coupling
1. High coupling components are difficult to understand.
2. High coupling components forces change in other components if one component
changes.
3. High coupling slows down the development process.
21) Software Testing
Software testing is a procedure to verify whether the actual results are same as of expected
results. Software testing is performed to provide assurance that the software system does
not contain any defects. Defects means errors which are detected by tester when actual
result of our software module is not identical as expected result. Software testing helps us
to find out whether all user requirements are fulfilled by our software or not. Software
quality depends on; at what extend software full fills user requirements and number of
defects occurred in software .Software testing is used to give assurance that we deliver
quality product to customer. To perform software testing we create test cases and test data.
Test case is collected of actions which applied on our software product to check specific
feature or functionality of it .Collected of test cases is called as test suit
Advantages Of Software Testing:
1. Testing reduces the possibility of software failure by removing errors which leads to
software failure.
2. Testing process removes maximum possible errors from software and helps to
deliver qualitative software to customer.
3. Testing ensures correctness and completeness of software along with quality

Types Of Software Testing

Manual Testing:

• Manual Testing is one of the type of Software Testing in which Tester treat himself as
end user and use every module of application from login module to log out module
to checkapplication behavior according to requirement provided by user
• In manual testing, tester manually runs all the test cases without help of any
automation testing tools.
• Manual Testing in the very basic type of all testing types and supports to search the
bug (error) in the software system. First we do manual testing for any new
application before going for automation testing

Automation Testing

• Automation Testing is a process in which we use automation tools to run our test
cases to find out bugs from our software product.
• The automation software is able to enter test data into the software on which we
perform testing and it also matches the expected and actual results to create test
reports.
• Automation testing requires considerable amount of money and resources such as
employees, testing tools etc. After change in requirement or occurrence of error, we
need to make changes in code and werequire executing same test suite again and
again
• We can record test suite by using test automation tools and re-play it when needed.
22) Unit Testing
Software testing levels are the different stages of the software development lifecycle
conducted.
There are four levels of software testing: Unit >> Integration >> System >> Acceptance.

We are going to see the Unit testing in detail.

Unit Testing
Unit Testing is a level of software testing where individual units/components of a software
are tested.The purpose is to validate that each unit of the software performs as designed. A
unit is the smallest testable part of any software. It usually has one or a few inputs and
usually a single output.In procedural programming, a unit may be an individual program,
function, procedure, etc.In object-oriented programming, the smallest unit is a method,
which may belong to a base / super class, abstract class or derived/ child class. (Some treat a
module of an application as a unit.

Unit Testing Method

It is performed by using the White Box Testing method.
When is it performed?
Unit Testing is the first level of software testing and is performed prior to Integration
Testing.
Who performs it?
It is normally performed by software developers themselves or their peers. In rare cases, it
may also be performed by independent software testers.

23) Integration Testing

Integration testing is a method of software testing in which all units of software under text
are integrated and tested as a single group.
It is always done after unit testing is applied. It mainly focuses on testing data
communication among all units of system.
It makes use of mythologies as Big bang approach and incremental approach.
Incremental approach can be either top-down, bottom-up or combination of both.

The main objective of integration testing is to determine fault in communication between,

integrated units.
24) SYSTEM TESTING
System Testing is testing of entire and completely integrated software product. System
Testing is sequence of various tests whose work is to test the complete computer based
system. System testing is end-to-end testing. i.e. we test system from log in module to log
out module. System testing contains both functional (check whether requirements of user
are fulfilled or not) as well as Non-Functional testing (check whether expectations of user
are fulfilled or not), There are Two basic categories of Software Testing such as
Black Box Testing: In this type of testing, we check working of our software project by
running it. We do not need to check code of our software in this testing type. System testing
is included in black box testing
White Box Testing: In white box testing we check internal working of our code. So in this
type of testing tester need deep knowledge of programming language which is used in our
software product.

Types of System Testing

1. Regression Testing :Regression Testing is a type of software testing which is used to
check whether changes have been made in code due to some error or change in
requirement affects existing working functionality In Regression Testing, we execute
already executed test cases to give assurance that old functionalities work well after
performing changes in code. This testing is performed to give guarantee that new code
added in our software does not disturb working of existing functionalities.
2. Recovery Testing :Recovery Testing is done to specify whether system recovers itself
after the system crash due to disaster such as power failure or network not available etc
.In recovery testing, system perform rollback i.e. identify the point where the behavior
of the system was correct and then from that point again perform the operations up to
the point where system get crashed.
3. Migration Testing: Migration testing is performed to give assurance that the software
can be moved from older system Module infrastructures to current system
infrastructure without any problem. In Migration testing, we check data from old system
for the compatibility with new system.
4. Functional Testing: Functional testing is a type of software testing which checks that
every function present in the software application works as per requirements of user.
This testing includes black box testing and it does not focus on the source code of the
software application. Every functionality of the system is verified by tester using
appropriate test data and actual result is compared with expected result.If there is
difference between actual result and expected result then bug is considered. Functional
testing is done using Requirement Specification Document.
5. Hardware/Software Testing: in Hardware/Software Testing, we perform testing of
communication between the hardware and software used in our system. IBM called the
Hardware/Software Testing as "HW/SW Testing".
25) White-Box Testing
1. White Box Testing is testing process in which we verify internal coding and
infrastructure of software product under the test.
2. White box testing is based on analysing the internal implementation of system under
test. Thus programming knowledge or detailed functional knowledge of system is
major pre-requisite for tester.
3. White box testing mainly concentrates on the testing flow of inputs and outputs
through the software, strengthening security and improving design and usability of
software product.
4. White box testing is also called as Clear Box testing, Open Box testing, Structural
testing, Transparent Box testing, Code-Based testing, and Glass Box testing.
5. The term "white box" is used to indicate testing of code of software because we can
see what is present inside the box.
6. The clear box or white box term indicate the capability to see via outer part of
software into its internal workings

26) Black Box Testing

1. The software testing methods which test the functionality of an application without
knowing its internal structure, coding information and knowledge of internal paths
of the software is called black box testing.
2. In this method test cases are built based on what application is supposed to do. It is
also known as behavioural testing or specification based testing.
3. In Black Box Testing we concentrate on inputs provided to software product and
output from the software product without applying compulsion about knowledge of
the programming Input language used in software under the test.
4. Black box testing can be applied during each level of software testing process.
5. It makes use of various testing techniques like Boundary Value Analysis (BVA),
equivalence class decision models etc.

27) Basis Path Testing

Basis path testing is considered as a white-box testing It was proposed by Tom McCabe.
These tests guarantee to technique.execute every statement in the program at least once
during testing. Basic set is the set of all the execution paths of a procedure.
Flow Graph Notation:Before basic path procedure is discussed, it is important to know the
simple notation used for the representation of control flow. This notation is known as flow
graph .Flow graph depicts control flow and uses the following constructs.These individual
constructs are combined together to produce the flow graph for a particular procedure.
28) Cyclomatic Complexity
Independent path is an execution flow from the start point to the end point. Since a
procedure contains control statements, there are various execution paths depending upon
decision taken on the control

So Cyclomatic complexity provides the number of such execution independent paths. Thus it
provides a upper bound for number of tests that must be produced because for each
independent path, a test should be conducted to see if it is actually reaching the end point
of the procedure or not.
Cyclomatic Complexity for a flow graph is computed in one of three ways:

1. The numbers of regions of the flow graph correspond to the Cyclomatic complexity. 2.
2.Cyclomatic complexity, V(G), for a flow graph G is defined as
(G) = E - N + 2
where E is the number of flow graph edges and N is the number of flow graph nodes

3.Cyclomatic complexity, V(G), for a graph flow G is also defined as Where P is the number
of predicate nodes contained in the flow graph G.
V(G) = P + 1
Example: Consider the following flow graph.

Region, R = 6
Number of Nodes = 13) Number of edges = 17
Number of Predicate Nodes = 5
Cyclomatic Complexity, V(C)
V(C) = R = 6

Or
V(C) Predicate Nodes + 1
=5+1=6
Or

V(C) = E - N + 2
17-13+2=6
29) Explain software reverse engineering in detail
1. It is a procedure to get system specification by analyzing and understanding the existing
system. This procedure can be reverse software development life cycle model, i.e. go
from maintenance phase to requirement gathering phase.
2. Reverse engineering is the procedure that recognizes an object, a device, or technical
properties of system through analysis of architecture of system, functions and
operations.
3. Consider an existing system has design about which we do not know anything. System
designers perform reverse engineering by analyzing the source code and attempt to get
the design. With the help of design, designer attempt to make conclusion about
specifications of software product.
4. Reverse engineering is a process of analyzing an object to observe how software works
in order to duplicate or add new features in the object.
5. Idea of reverse engineering is invented in older industries and now many times it is used
in computer hardware and software generation.
6. Software reverse engineering includes reversing a machine code of program which is in
the format of the sequence of Os and 1s. It is transformed into the source code.
7. Software reverse engineering is performed to find out the source code of a program
since the source code need to study how the program do specific tasks, to enhance the
performance of a program, to repair a bug i.e. correct an error detected in the program
or to detect unsecure contents from program like virus

30) Software Maintenance

Maintenance is required to give assurance that the software has ability to satisfy the
changing requirements of user.

Maintenance is important phase for software product which is developed using any SDLC
model such as waterfall, spiral or iterative model etc.
Due to corrective and non corrective software actions, we need to make changes in
Software products.

Following are the needs of maintenance:

1. To correct the defects found in software product.
2. To improve the design of software.
3. To improve performance of software product.
4. To add new features.
5. To improve communication with other software.
6. To transfer legacy software system into new software system.
7. To replace the old software by new software.
31) Risk Analysis And Management
Risk is the possibility of suffering loss. In the project development, the loss illustrates the
impact to the project which could be in the form of diminished quality of the end product,
increased costs, delayed completion, or failure.Various Kinds of Risks Associated with
Software Project Management are as follows
1. Schedule/Time-Related/Delivery Related Planning Risks:These risks are related to
running behind schedule and are essential time-related risks, which directly impact the
delivery of the project. Some of the reasons for such risks are: Incorrect Time Estimation,
and consequently an incorrect project schedule. Improper Resource Allocation.
Underutilization of Resources. Superficial Understanding of Project Complexities.
2. Budget/Financial Risks: These are the monetary risks which are associated with budget
overruns. Some of there are:

• Improper Budget Estimation.

• Cost Overruns due to underutilization of resources.
• Expansion of Project Scope.
• Improper Tracking of Finances.

Underutilization of resources especially happens when resources are shared between

projects because it becomes difficult to effectively manage such resources and a certain
amount of productivity may go waste.
3. Operational/Procedural Risks: These are risks which are associated with the day-to-day
operational activities of the project. These could be due to any of the below reasons:
Improper Process Implementation .Sile approach followed by software development teams
leading to conflicts Conflicting Priorition. Lack of conflict resolution /team spirit Lack of
clarity in responsibilities .Breakdown in communications. Lack of sufficient training
4. Technical/Functional/Performance Risks: These are technical risks associated with the
functionality of the software or with respect to the software performance .In order to
compensate for excessive budget overruns and schedule overruns, companies sometimes
reduce the functionality of the software.Software testing is a downstream stage in the
software development lifecycle and as the project falls behind schedule, downstream
activity times are shrunk in order to meet delivery dates which results in insufficient
software testing.
5.Other Unavoidable Risks:All the risks described above are those which can be anticipated
to certain extend and planned for in advance. However there are certain risks which are
unavoidable in nature. The reasons for such unavoidable risks are described below. Changes
in government policy, Obsolescence (becoming outdated) of software due to new
technology from a rival company. Loss of contracts due to changes at customers end Risk
Management is a software engineering practice with processes, methods, and tools for
managing risks in a project.
32) Monitoring And Projection Plan (RMMM)
The main aim of all of the risk analysis related activities is to guide the project team in
forming a strategy for dealing with risk. In an effective strategy there are three important
issues risk aveidance (mitigation), risk monitoring, and risk management and contingency
planning If proactive approach to risk is accepted by a software team, avoidance is
considered as always the best strategy. This is accomplished by setting a plan for risk
mitigation. For example, consider that high staff turnover is marked as a project risk r. As
per previmis history and management instinct, the likelihood Is of high turnover is guessed
to be 0.70 (70 percent, rather high) and the impact xa is projected as critical It indicates that
there will be critical impact of high turnover on project cost and schedule. To mitigate this
risk, a strategy can be developed to decrease turnover.
Among the possible steps to be taken are:

• Communicate with current staff to decide reasons for turnover (eg, poor working
conditions, low pay, competitive job market).
• Mitigate these reasons that are controllable prior to the project starts. and develop
• After commencement of project, assume there will be occurrence of turnover
techniques to take care of continuity when people leave.
• Organize project teams to widely disperse the information regarding each
development activity
• Define work product standards and set system to assure that all the respective
models and documents are developed in expected time duration.
• Allocate a backup staff for all the critical technologists.

The factors are monitored by the project manager which may give a signal of whether the
risk is becoming more or less likely. In the case when there is high staff turnover, the
common attitude of team members depends upon project pressures, communication
among team members, potential problems with compensation as well as benefits. Besides
monitoring these factors, a project manager has also responsibility to maniter the efficiency
of risk mitigation steps For example, a risk mitigation step which is pointed here is called for
the definition of work product standards and mechanisms to assure that there is no time
delay in development of work products It is responsibility of the project manager to monitor
all the respective work products cautiously to assure that each can stand on its own and
that each conveys data that would be essential if a newcomer were forced to join the
existing software team in their work in the middle of the project. Risk management and
contingency planning considers that there is failure in mitigation efforts and that the risk is
really occurred. Continuing the example, the execution of project is going smoothly and
some team members announce they will be leaving. If there is implementation of
mitigation strategy, backup is on hand, information is well-documented .that and
knowledge has been dispersed across the team. Additionally, one can for the time being
refocus resources land manage the project schedule again) to such functions which are
completely staffed, enabling newcomers whose introduction in the team is necessary to
"get up to speed”.
33) Change Control (Configuration Control)
• Changes occur at all phases in the software lifecycle. Design or implementation changes
may be necessary if requirements change, or when deficiencies are identified in the
design or implementation approach to a stable requirement.
• Testing may uncover defects that require changes in the code or the design and
requirements Changes must be made to the right version of the code, testing must
verify performance of the change and the integrity of the remaining software, and all
associated documentation must be updated to be consistent with the final code.
• A mechanism is needed to process change requests (e.g., discrepancies, failure reports,
requests for new features) from a variety of sources throughout the development
process and during operation and support of the software product.
• This mechanism should extend to a definition of a process to track, evaluate, and
implement change requests into a new version and new release of the software.
• Generally, no single procedure can meet the needs of all levels of change management
and approval levels.
• The minimum activities needed for processing changes include:
1. Defining the information needed for approving the requested change.
2. Identifying the review process and
3. routing of information.
4. Describing the control of the libraries
5. used to process the change.
6. Developing a procedure for implementing each change in the code, the
documentation, and the released software product.

34) Version Control

Version control integrates the procedures with tools for the purpose of managing different
versions regarding the configuration objects which are generated throughout the software
process. Following are the important capabilities which a version control system implements
or is straightforwardly integrated with:

• A project database (repository) which holds all the appropriate configuration

objects,
• A version management capability which holds all the relevant versions of a
configuration object,
• A make facility which helps to get all respective configuration objects and build a
particular version of the software.
Additionally, version control as well as change control systems usually implement an
issues/bugs tracking capability which helps the team to record and track the status
regarding all of the important issues related with each and every configuration object.Most
of the version control systems create a change set of all the respective changes which are
necessary to build a particular version of the software.
35) Formal Technical Review (FTR)
A formal technical review is a process performed to give assurance of software quality.This
testing activity is done by software engineers and other persons.
The objectives of the Formal Technical Review are:

1. To find out errors in function, logic, or coding in the software.

2. To check that the software fulfils the requirements for which it is built.
3. To give assurance that software has been designed as per customer requirements. .
4. To create software developed in uniform order
5. To create more manageable project.

The Formal Technical Review is used while providing training and it is also used as an
example for junior developers to study different ways for software analysis, design, and
development. The Formal Technical Reviews is a class of reviews that contains
walkthroughs, inspections, round- robin reviews and other small technical assessments of
software.Every Formal Technical Review is performed as a meeting.If Formal Technical
Reviews is planned, controlled, and attended in correct way then only it becomes successful

Steps In FTR
The review meeting
Every review meeting should be conducted by considering the following constraints:
Involvement of people: Between 3 to 5 people should be involve in the review. Advance
preparation Advance preparation should occur but it should be very short most 2 hours of
work for each person can be spent in this preparation Short duration: The duration of the
review meeting should be less than two hours Rather than attempting to review the entire
design, walkthrough are conducted for modules small group of modules or for The focus of
the FTI in on work product (a software component to be reviewed). The review meeting is
attended by the review leader, all reviewers and the producer. material are then distributed
to reviewers.The review leader is responsible for evaluating the product for its deadlines.
The copies of product The producer organizes walkthrough" for the product, explaining the
material, while the reviewers raise the issues based on their advance preparation.

Review Reporting and Record Keeping

During the FTR, a reviewer (the recorder) actively records all issues that have been raised.
These are summarized at the end of the review meeting, and a review issues list is
produced. In audition, a formal technical review summary report is completed.

A review summary report answers three questions?

1. What was reviewed?
2. Who reviewed it?
3. What were the findings and conclusiona?
The review summary report is a single page form (with possible attachinents).
36) Walkthrough
➢ Walkthrough is a Review meeting but it is different from Inspection as it is not a formal
process
➢ Generally it is started by the author of code.
➢ In walkthrough, document or code is read by author and others can write note on the
defects and suggestions about it.
➢ Walkthrough is informal way of testing so there is no need of moderator while
performing walkthrough. We can call it as Open Ended discussion because preparation
before meeting and creation of a list of observation is not necessary.
➢ It is the informal way of review so it does not focus on documentation. Defect tracking is
challenging task in walkthroughs.
The following are the objectives of Walkthrough:

• Understand and learn the development of software product till date.

• Detecting defects in the developed software product.
• To explain information present in the document
• To verify and discuss about the validity of the proposed system.
• Reporting the suggestions given by the others (other employees).

37) 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).
Shortcomings of SEI/CMM:
1. 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.
2. It only helps if it is put into place early in the software development process.
3. It has no formal theoretical basis and in fact is based on the experience of very
knowledgeable people.
4. It does not have good empirical support and this same empirical support could
also be constructed to support other models
38) Service-Oriented Software Engineering (SOSE):
• Service-oriented software engineering (SOSE) is a software engineering paradigm that
aims to support the development of rapid, low-cost and easy composition of distributed
applications even in heterogeneous environments. It utilizes services as fundamental
elements for developing applications and solutions.
• Important areas of research within SOSE include service foundations, service
composition, service management and monitoring and service-oriented engineering.
Service foundations provide service oriented communication technologies to support
run time service-oriented infrastructure and connect heterogeneous systems and
applications. These communication technologies provide the communication
mechanisms between service providers and service requesters; they differ with respect
to service description techniques and messaging functions.
• Service composition encompasses necessary roles and functionality to support service
composition.The dynamic composition feature in SOSE makes QoS a major challenge.
Different initiatives have emerged such as orchestration and choreography.
• Service management encompasses the control and monitoring of SOA-based
applications throughout life cycle.
• A key element in SOSE is the service-oriented interaction pattern, i.e. serviceoriented
architecture (SOA), which enables a collection of services to communicate with each
other. SOA is a way of designing a software system to provide services to applications or
other services through published and discoverable interfaces.
• The basic elements of service-oriented architecture are illustrated in Figure 1.
39) User Interface Design
User interface is the front-end application view to which user interacts in
order to use the software. The software becomes more popular if its user
interface is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interface screens There are two types of User
Interface:
Command Line Interface: Command Line Interface provides a command
prompt, where the user types the command and feeds to the system. The
user needs to remember the syntax of the command and its use.
Graphical User Interface: Graphical User Interface provides the simple
interactive interface to interact with the system. GUI can be a combination of
both hardware and software. Using GUI, user interprets the software.
User Interface Design Process:

The analysis and design process of a user interface is iterative and can be
represented by a spiral model. The analysis and design process of user
interface consists of four framework activities.
1. User, task, environmental analysis, and modeling: Initially, the focus is
based on the profile of users who will interact with the system, i.e.
understanding, skill and knowledge, type of user, etc, based on the user’s
profile users are made into categories. From each category requirements
are gathered. Based on the requirements developer understand how to
develop the interface. Once all the requirements are gathered a detailed
analysis is conducted. In the analysis part, the tasks that the user
performs to establish the goals of the system are identified, described
and elaborated. The analysis of the user environment focuses on the
physical work environment. Among the questions to be asked are:
a. Where will the interface be located physically?
b. Will the user be sitting, standing, or performing other tasks
unrelated to the interface?
c. Does the interface hardware accommodate space, light, or noise
constraints?
d. Are there special human factors considerations driven by
environmental factors?
2. Interface Design: The goal of this phase is to define the set of interface
objects and actions i.e. Control mechanisms that enable the user to
perform desired tasks. Indicate how these control mechanisms affect the
system. Specify the action sequence of tasks and subtasks, also called a
user scenario. Indicate the state of the system when the user performs a
particular task. Always follow the three golden rules stated by Theo
Mandel. Design issues such as response time, command and action
structure, error
a. handling, and help facilities are considered as the design
model is refined. This phase serves as the foundation for the
implementation phase.
3. Interface construction and implementation: The implementation activity
begins with the creation of prototype (model) that enables usage
scenarios to be evaluated. As iterative design process continues a User
Interface toolkit that allows the creation of windows, menus, device
interaction, error messages, commands, and many other elements of an
interactive environment can be used for completing the construction of
an interface.
4. Interface Validation: This phase focuses on testing the interface. The
interface should be in such a way that it should be able to perform tasks
correctly and it should be able to handle a variety of tasks. It should
achieve all the user’s requirements. It should be easy to use and easy to
learn. Users should accept the interface as a useful one in their work.