Software Eng Solution 68-73 Ex 72 PDF

This solution is downloaded and managed
from
http://www.rajanaryal.com.np/
http://hutrajshrestha.com.np/
Visit site For bsc csit syllabus/old
question/notes/solution
You can follow the site for more notes.
Our Social Links
My Facebook Read my blog Follow me on twitter
Follow me on instagram My youtube channel My Facebook
Note : if you found any mistake on solution

then please send us a message .
(You don’t need to write long answer. Some of
our answer is very long for better
understanding so summarize yourself)
http://www.rajanaryal.com.np/index.html http://www.hutrajshrestha.com.np/soln.html
Tribhuvan University
Institute of Science and Technology
2073
Bachelor Level / Third Year /Six Semester/Science Full Marks: 100
Computer Science and Information Technology-(CSc.351) Pass Marks: 32
(Software Engineering)
1. Differentiate between software and software engineering. What

are the characteristics of software? Explain.
Ans:
Software:
Computer programs and associated documentation
•Software products may be developed for a particular customer or may be developed for a
general market
•Software products may be
–Generic - developed to be sold to a range of different customers
–Bespoke (custom) - developed for a single customer according to their specification
Software Engineering:
Software engineering is an engineering discipline which is concerned with all aspects of
software production
•Software engineers should adopt a systematic and organized approach to their work and use
appropriate tools and techniques depending on the problem to be solved, the development
constraints and the resources available.
Characteristics of Software:
1. Portable: The ability of software to perform same functions across all
environments and platforms, demonstrate its portability.
2. Maintainability: Maintenance of the software should be easy for any kind of

user.
3. Integrity: Just like medicines have side-effects, in the same way a software may
have a side-effect i.e. it may affect the working of another application. But a
quality software should not have side effects.
4. Efficiency: This characteristic relates to the way software uses the available
resources. The software should make effective use of the storage space and
execute command as per desired timing requirements.
5. Usability/Learnability: The amount of efforts or time required to learn how to

use the software should be less. This makes the software user-friendly even for
IT-illiterate people.
6. Flexibility: Changes in the software should be easy to make.
7. Modularity: Any software is said to made of units and modules which are
independent of each other.
2. What are the major phases of waterfall model and spiral

model .What are the advantages of spiral model. Explain.
Ans:
Waterfall Model:
Phases of Waterfall Model:
Spiral Model:
Phases of Spiral Model:
Process is represented as a spiral rather than as a sequence of activities with
backtracking.
●Each loop in the spiral represents a phase in the process.
● No fixed phases such as specification or design - loops in the spiral are chosen
depending on what is required.
● Risks are explicitly assessed and resolved throughout the process.
●A risk-driven software process framework (the spiral model) was proposed by Boehm
(1988).
Advantages of Spiral Model:

1) Spiral Life Cycle Model is one of the most flexible SDLC models in place. Development phases can be
determined by the project manager, according to the complexity of the project.
2) Project monitoring is very easy and effective. Each phase, as well as each loop, requires a review from
concerned people. This makes the model more transparent.
3) Risk management is one of the in-built features of the model, which makes it extra attractive
compared to other models.
4) Changes can be introduced later in the life cycle as well. And coping with these changes isn’t a very
big headache for the project manager.
5) Project estimates in terms of schedule, cost etc. become more and more realistic as the project
moves forward and loops in spiral get completed.
6) It is suitable for high risk projects, where business needs may be unstable.
7) A highly customized product can be developed using this.
3. What are the major task of requirement engineering activity?

Explain.
Ans:
Requirements engineering assesses the feasibility of a project and if deemed feasible, gleans
precise and accurate requirements which, when fulfilled, culminate in the correct system for
the customer.
It is important to build the correct system correctly and that cannot happen without defining
accurate, precise, and valid requirements. Requirements must be accurate in that they must
capture the actual meaning of customer inputs and not attempt to interpret or embellish those
inputs. Requirements must be precise in that if a customer says they want a certain detail, say
temperature displayed in degrees Fahrenheit, it is important to deliver that detail. Don't
assume that degrees in Celsius should be just as good. That is not precisely what the customer
wanted. Requirements must be valid. If the customer wants a microwave oven controller
system that is cost-effective but adequate, do not provide a controller system that is leading
edge with functionality beyond what was desired and then expect to charge the customer for
budget overruns. All of the requirements that led to the "gold-plating" were invalid. Building an
incorrect system correctly is still total failure.
The end result of the requirements engineering activities is a populated System Requirements
Specification (or SRS) and a completed System Specification.
4. Explain the concept of incremental model with example.
Ans:
5. What is the need of feasibility study? Explain the various type of
feasibility study with example.
Ans:
Importance of feasibility study:
 Improves project teams’ focus

 Identifies new opportunities
 Provides valuable information for a “go/no-go” decision
 Narrows the business alternatives
 Identifies a valid reason to undertake the project
 Enhances the success rate by evaluating multiple parameters
 Aids decision-making on the project
 Identifies reasons not to proceed
Types of feasibility study:
A feasibility study evaluates the project’s potential for s uccess; therefore,

perceived objectivity is an important factor in the credibility of the study for
potential investors and lending institutions. There are five types of feasibility
study—separate areas that a feasibility study examines, described below.
1. Technical Feasibility - this assessment focuses on the technical resources
available to the organization. It helps organizations determine whether the
technical resources meet capacity and whether the technical team is capable of
converting the ideas into working systems. Technical feasibility also involves
evaluation of the hardware, software, and other technology requirements of the
proposed system. As an exaggerated example, an organization wouldn’t want to
try to put Star Trek’s transporters in their building—currently, this project is not
technically feasible.
2. Economic Feasibility - this assessment typically involves a cost/ benefits
analysis of the project, helping organizations determine the viability, cost, and
benefits associated with a project before financial resources are allocated. It also
serves as an independent project assessment and enhances project credibility —
helping decision makers determine the positive economic benefits to the
organization that the proposed project will provide.
3. Legal Feasibility - this assessment investigates whether any aspect of the
proposed project conflicts with legal requirements like zoning laws, data
protection acts, or social media laws. Let’s say an organization wants to construct
a new office building in a specific location. A feasibility study might reveal the
organization’s ideal location isn’t zoned for that type of business. That
organization has just saved considerable time and effort by learning that their
project was not feasible right from the beginning.
4. Operational Feasibility - this assessment involves undertaking a study to
analyze and determine whether—and how well—the organization’s needs can be
met by completing the project. Operational feasibility studies also analyze how a
project plan satisfies the requirements identified in the requirements analysis
phase of system development.
5. Scheduling Feasibility - this assessment is the most important for project
success; after all, a project will fail if not completed on time. In scheduling
feasibility, an organization estimates how much time the project will take to
complete.
6. What are the different types of requirement elicitation

technique? Explain in brief.
Ans:
7. What is software requirements
specification (SRS)? Mention the principle and
characteristics of software requirements
specification (SRS).
Ans:
A software requirements specification (SRS) is a detailed description of
a software system to be developed with its functional and non-functional
requirements. The SRS is developed based the agreement between
customer and contractors. It may include the use cases of how user is going
to interact with software system. The software requirement specification
document consistent of all necessary requirements required for project
development. To develop the software system we should have clear
understanding of Software system. To achieve this we need to continuous
communication with customers to gather all requirements.
A good SRS defines the how Software System will interact with all internal
modules, hardware, communication with other programs and human user
interactions with wide range of real life scenarios. Using the Software
requirements specification (SRS) document on QA lead, managers creates
test plan. It is very important that testers must be cleared with every detail
specified in this document in order to avoid faults in test cases and its
expected results.
It is highly recommended to review or test SRS documents before start

writing test cases and making any plan for testing. Let’s see how to test SRS
and the important point to keep in mind while testing it.
Any good requirement should have these 6 characteristics:
 Complete
 Consistent
 Feasible
 Modifiable
 Unambiguous
 Testable
Complete
The requirements must be complete, what is the meaning of completeness?
It means that all the required information to implement (read Code) the requirement. There is no
need to assume anything in order to implement the same. One of the important aspects of
completeness is to also have measuring units, if applicable.
Consistent
Consistency is an important aspect of requirements. It means that all inputs to any process, must
be processed similarly. It should not happen that processes produce different outputs for inputs
coming from different sources.
Feasible
This is one of the crucial part of requirements capturing. All the requirements included in the
SRS must be feasible to implement.
Modifiable
Every SRS document must be modifiable. In the modern software projects, requirements are
never static and don’t stop coming after the SRS document is signed off. We can’t expect the
customers to stop altering the requirements or adding new requirements as we also need to look
at business needs.
Unambiguous
Unambiguous means a single interpretation. If a requirement is defined in such a manner that it
can only be interpreted in one way, it means that the requirement is unambiguous. All subjective
words or statements must be eliminated from the requirements.
Testable
A testable requirement can be defined as a requirement, which can be tested and validated using
any of the following methods:
 Inspection
 Walkthrough
 Demonstration
 Testing
8. How software inspection improves software

quality? Explain the software inspection in
brief.
Ans:
There are various names for the same thing. Some call it software inspection, which
also could extend to the design and its documentation, some call it code inspection
which relates more to the source code. A third name would be Fagan Inspection, called
after the person who invented this quality assurance and testing method.
Code inspections are a highly efficient test method which cannot be substituted by any
other test methods. It is time consuming but according to statistics it will find up to 80%
of the contained faults, if done properly. However it all depends on the methods and
checks applied and on the diligence of the inspectors. It must not be confused with the
so called "code review" or "walk through" which is usually done in a single meeting
lasting for a couple of hours. A proper code inspection may take several days and
needs the help of tools to browse the symbols in order to find the places where they are
used. Proper inspections can be applied for almost all work products in the software life
cycle. At the first glance they may look very time consuming. But statistical evaluations
have shown that over the whole life cycle of the software development they even save
resources and thus money and improve the quality of the product.
Most people are not aware that the manual static testing methods i.e. inspection, review
and walk through are defined in the "IEEE Standard for Software Reviews". This is the IEEE
1028-1997 standard. I want to give a short overview on the main definitions in this standard,
however I will not discuss the "Management Review" which is in the widest sense a check of a
project's performance and the related documents. I will also omit a discussion of the Audits
described in the standard, which a more related to having external checks on work products and
processes. I will focus on the review techniques for technical work products as they are typically
used within a company.
9. What is Software quality assurance (SQA)? What are the various quality
concepts of SQA?
Software quality assurance (SQA) is a process that ensures that developed software meets and
complies with defined or standardized quality specifications. SQA is an ongoing process within
the software development life cycle (SDLC) that routinely checks the developed software to
ensure it meets desired quality measures.
9. What is software design? Explain the various principle
and design concepts of software design
Ans:
Software design is the process by which an agent creates a specification of a software artifact,
intended to accomplish goals, using a set of primitive components and subject to constraints.
Software design may refer to either "all the activity involved in conceptualizing, framing,
implementing, commissioning, and ultimately modifying complex systems" or "the activity
following requirements specification and before programming, as in a stylized software engineering
process.
10. Differentiate between Verification and Validation.
Verification Validation
Are we building the system right? Are we building the right system?
Verification is the process of evaluating Validation is the process of evaluating

products of a development phase to find software at the end of the development
out whether they meet the specified process to determine whether software
requirements. meets the customer expectations and
requirements.
The objective of Verification is to make sure The objective of Validation is to make sure
that the product being develop is as per the that the product actually meet up the user’s
requirements and design specifications. requirements, and check whether the
specifications were correct in the first place.
Following activities are involved Following activities are involved

in Verification: Reviews, Meetings and in Validation: Testing like black box
Inspections. testing, white box testing, gray box testing
etc.
Verification is carried out by QA team to Validation is carried out by testing team.

check whether implementation software is
as per specification document or not.
Execution of code is not comes Execution of code is comes

under Verification. under Validation.
Verification process explains whether the Validation process describes whether the
outputs are according to inputs or not. software is accepted by the user or not.
Verification is carried out before the Validation activity is carried out just after
Validation. the Verification.
12. Write short notes on:
a.) DFD
A data flow diagram (DFD) maps out the flow of information for any process or system.
It uses defined symbols like rectangles, circles and arrows, plus short text labels, to
show data inputs, outputs, storage points and the routes between each
destination. Data flowcharts can range from simple, even hand-drawn process
overviews, to in-depth, multi-level DFDs that dig progressively deeper into how the data
is handled. They can be used to analyze an existing system or model a new one. Like
all the best diagrams and charts, a DFD can often visually “say” things that would be
hard to explain in words, and they work for both technical and nontechnical audiences,
from developer to CEO. That‟s why DFDs remain so popular after all these years. While
they work well for data flow software and systems, they are less applicable nowadays to
visualizing interactive, real-time or database-oriented software or systems.
b.) Data Dictionary:
A data dictionary is a collection of descriptions of the data objects or items in a data

model for the benefit of programmers and others who need to refer to them. A first step
in analyzing a system of objects with which users interact is to identify each object and
its relationship to other objects. This process is called data modeling and results in a
picture of object relationships. After each data object or item is given a descriptive
name, its relationship is described (or it becomes part of some structure that implicitly
describes relationship), the type of data (such as text or image or binary value) is
described, possible predefined values are listed, and a brief textual description is
provided. This collection can be organized for reference into a book called a data
dictionary.
c.) Estimation technique:
In order to successful software project & proper execution of task, the Estimation
Techniques plays vital role in software development life cycle. The technique which is used
to calculate the time required to accomplish a particular task is called Estimation
Techniques. To estimate a task different effective Software Estimation Techniques can
be used to get the better estimation.
There are different Software Testing Estimation Techniques which can be used for
estimating a task.
1) Delphi Technique
2) Work Breakdown Structure (WBS)
3) Three Point Estimation
4) Functional Point Method
2071(II)
1.) What are the different phases in software development life cycle?
Explain.
Ans: There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also referred as
“Software Development Process Models” (e.g. Waterfall model, incremental model, V-
model, iterative model, RAD model, Agile model, Spiral model, Prototype model etc.). Each
process model follows a particular life cycle in order to ensure success in process of software
development.
There are following six phases in every Software development life cycle model:
1. Requirement gathering and analysis

2. Design
3. Implementation or coding
4. Testing
5. Deployment
6. Maintenance
1) Requirement gathering and analysis: Business requirements are gathered in this phase.
This phase is the main focus of the project managers and stake holders. Meetings with managers,
stake holders and users are held in order to determine the requirements like; Who is going to use
the system? How will they use the system? What data should be input into the system? What
data should be output by the system? These are general questions that get answered during a
requirements gathering phase. After requirement gathering these requirements are analyzed for
their validity and the possibility of incorporating the requirements in the system to be
development is also studied.
Finally, a Requirement Specification document is created which serves the purpose of guideline
for the next phase of the model. The testing team follows the Software Testing Life Cycle and
starts the Test Planning phase after the requirements analysis is completed.
2) Design: In this phase the system and software design is prepared from the requirement
specifications which were studied in the first phase. System Design helps in specifying hardware
and system requirements and also helps in defining overall system architecture. The system
design specifications serve as input for the next phase of the model.
In this phase the testers comes up with the Test strategy, where they mention what to test, how
to test.
3) Implementation / Coding: On receiving system design documents, the work is divided in

modules/units and actual coding is started. Since, in this phase the code is produced so it is the
main focus for the developer. This is the longest phase of the software development life cycle.
4) Testing: After the code is developed it is tested against the requirements to make sure that
the product is actually solving the needs addressed and gathered during the requirements phase.
During this phase all types of functional testing like unit testing, integration testing, system
testing, acceptance testing are done as well as non-functional testing are also done.
5) Deployment: After successful testing the product is delivered / deployed to the customer for
their use.
As soon as the product is given to the customers they will first do the beta testing. If any
changes are required or if any bugs are caught, then they will report it to the engineering team.
Once those changes are made or the bugsare fixed then the final deployment will happen.
6) Maintenance: Once when the customers starts using the developed system then the actual
problems comes up and needs to be solved from time to time. This process where the care is
taken for the developed product is known as maintenance.
2.) Explain the software process model with example.

Ans:
A software process model is an abstract representation of a process.

It presents a description of a process from some particular perspective.
Examples of process perspectives:
Workflow perspective - represents inputs, outputs and dependencies
Data-flow perspective - represents data transformation activities
Role/action perspective - represents the roles/activities of the people involved in the
software process
Generic process models
1. The waterfall model
Plan-driven model. Separate and distinct phases of specification and development.
2. Incremental (exploratory) development
Specification, development and validation are interleaved. May be plan-driven or agile.
3. Reuse-oriented software engineering
The system is assembled from existing components. May be plan-driven or agile.
3.) Explain the software specification, software validation and

software evolution with example.
Ans:
Software Specification:
The process of establishing what services are required and the constraints on the
system‟s operation and development.
Requirements engineering process
Feasibility study
• Is it technically and financially feasible to build the system?
Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
Requirements specification
• Defining the requirements in detail
Requirements validation
• Checking the validity of the requirements
Software Verification and validation

Verification and validation (V & V) is intended to show that a system conforms to its
specification and meets the requirements of the system customer.
•Involves checking and review processes and system testing.
•System testing involves executing the system with test cases that are derived from the
specification of the real data to be processed by the system.
Software evolution
Software is inherently flexible and can change.
•As requirements change through changing business circumstances, the software that supports
the business must also evolve and change.
•Although there has been a demarcation between development and evolution (maintenance)
this is increasingly irrelevant as fewer and fewer systems are completely new.
4.) What do you mean by project management? Explain the project

planning and project scheduling with example.
Ans: Project management is the discipline of using established principles, procedures
and policies to manage a project from conception through completion. It is often
abbreviated as PM.
Project management oversees the planning, organizing and implementing of a project.

A project is an undertaking with specific start and end parameters designed to produce
a defined outcome, such as a new computer system. A project is different from ongoing
processes, such as a governance program or an asset management program.
Project Planning:
Project planning is a discipline for stating how to complete a project within a certain
timeframe, usually with defined stages, and with designated resources. One view of
project planning divides the activity into:
 Setting objectives (these should be measurable)
 Identifying deliverables
 Planning the schedule
 Making supporting plans
Supporting plans may include those related to: human resources, communication
methods, and risk management.
Computer hardware and software project planning within an enterprise is often done
using a project planning guide that describes the process that the enterprise feels has
been successful in the past.
Project Scheduling:
Project scheduling is a mechanism to communicate what tasks need to get done and
which organizational resources will be allocated to complete those tasks in what
timeframe. A project schedule is a document collecting all the work needed to deliver
the project on time.
But when it comes to creating a project schedule, well, that’s something few have deep
experience with.
What and who is being scheduled, and for what purposes, and where is this scheduling
taking place, anyway?
A project is made up of many tasks, and each task is given a start and end (or due date),
so it can be completed on time. Likewise, people have different schedules, and their
availability and vacation or leave dates need to be documented in order to successfully
plan those tasks.
For example, most tools have task lists, which enable the manager to schedule multiple
tasks, their due dates, sometimes the planned effort against that task, and then assign
that task to a person. The software might also have resource scheduling, basically the
ability to schedule the team’s availability, but also the availability of non-human
resources like machines or buildings or meeting rooms.
Because projects have so many moving parts, and are frequently changing, project
scheduling software automatically updates tasks that are dependent on one another,
when one scheduled task is not completed on time. It also generates automated email
alerts, so team members know when their scheduled tasks are due or overdue, and to let
the manager know when someone’s availability has changed.
5.) What do you mean by software requirement? Explain the
requirements engineering process with example.
Ans: The software requirements are description of features and
functionalities of the target system. Requirements convey the expectations
of users from the software product. The requirements can be obvious or
hidden, known or unknown, expected or unexpected from client’s point of
view.
Requirement Engineering
The process to gather the software requirements from client, analyze and
document them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain

sophisticated and descriptive ‘System Requirements Specification’
document.
Requirement Engineering Process

It is a four step process, which includes –
 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation
Feasibility study
When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the
software must perform and which all features are expected from the
software.
Referencing to this information, the analysts does a detailed study about

whether the desired system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study
analyzes whether the software product can be practically materialized in
terms of implementation, contribution of project to organization, cost
constraints and as per values and objectives of the organization. It explores
technical aspects of the project and product such as usability,
maintainability, productivity and integration ability.
Requirement Gathering
If the feasibility report is positive towards undertaking the project, next
phase starts with gathering requirements from the user. Analysts and
engineers communicate with the client and end-users to know their ideas
on what the software should provide and which features they want the
software to include.
Software Requirement Specification

SRS is a document created by system analyst after the requirements are
collected from various stakeholders.
SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of
software across various platforms, maintainability, speed of recovery after
crashing, Security, Quality, Limitations etc.
Software Requirement Validation

After requirement specifications are developed, the requirements mentioned
in this document are validated. User might ask for illegal, impractical
solution or experts may interpret the requirements incorrectly. This results
in huge increase in cost if not nipped in the bud. Requirements can be
checked against following conditions -
 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
6.) Define formal specification. Explain the formal specification

method used in software process.
Ans:
Techniques for the unambiguous specification of software. In computer science, formal
specifications are mathematically based techniques whose purpose are to help with
the implementation of systems and software. They are used to describe a system, to
analyze its behavior, and to aid in its design by verifying key properties of interest
through rigorous and effective reasoning tools. These specifications are formal in the
sense that they have a syntax, their semantics fall within one domain, and they are able
to be used to infer useful information.
Objectives
●To explain why formal specification techniques help discover problems in system
requirements
●To describe the use of algebraic techniques for interface specification
●To describe the use of model-based techniques for behavioral specification
Formal methods
● Formal specification is part of a more general collection of techniques that are known
as „formal methods‟
●These are all based on mathematical representation and analysis of software
● Formal methods include
• Formal specification
• Specification analysis and proof
• Transformational development
• Program verification
Acceptance of formal methods

● Formal methods have not become mainstream software development techniques as
was once predicted
• Other software engineering techniques have been successful at increasing system
quality. Hence the need for formal methods has been reduced
• Market changes have made time-to-market rather than software with a low error count
the key factor. Formal methods do not reduce time to market
• The scope of formal methods is limited. They are not well-suited to specifying and
analyzing user interfaces and user interaction
• Formal methods are hard to scale up to large systems
7.) Explain the software maintenance and its types.

Ans:
Software maintenance is widely accepted part of SDLC now a days. It
stands for all the modifications and updations done after the delivery of
software product. There are number of reasons, why modifications are
required, some of them are briefly mentioned below:
 Market Conditions - Policies, which changes over the time, such as
taxation and newly introduced constraints like, how to maintain
bookkeeping, may trigger need for modification.
 Client Requirements - Over the time, customer may ask for new
features or functions in the software.
 Host Modifications - If any of the hardware and/or platform (such as

operating system) of the target host changes, software changes are
needed to keep adaptability.
 Organization Changes - If there is any business level change at

client end, such as reduction of organization strength, acquiring
another company, organization venturing into new business, need to
modify in the original software may arise.
Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It
may be just a routine maintenance tasks as some bug discovered by some
user or it may be a large event in itself based on maintenance size or
nature. Following are some types of maintenance based on their
characteristics:
 Corrective Maintenance - This includes modifications and updations

done in order to correct or fix problems, which are either discovered
by user or concluded by user error reports.
 Adaptive Maintenance - This includes modifications and updations

applied to keep the software product up-to date and tuned to the ever
changing world of technology and business environment.
 Perfective Maintenance - This includes modifications and updates

done in order to keep the software usable over long period of time. It
includes new features, new user requirements for refining the
software and improve its reliability and performance.
 Preventive Maintenance - This includes modifications and updations

to prevent future problems of the software. It aims to attend
problems, which are not significant at this moment but may cause
serious issues in future.
8.) Explain the clean room software development with example.
Ans:
Cleanroom software engineering is a process for developing high-quality
software with certified reliability. Originally developed by Harlan Mills, the
"cleanroom" name was borrowed from the electronics industry, where clean
rooms help prevent defect during fabrication. In that sense, cleanroom
software engineering focuses on defect prevention, rather than defect
removal, and formal verification of a program's correctness. The Cleanroom
Reference Model provides guidelines for defining development teams and
project roles, most importantly, the distinction between testers and
developers. Having testing and development in the same group is a conflict
of interest, while splitting them into separate groups allows for natural
competition to push the project toward higher quality results.
Following tasks occur in cleanroom engineering:
1. Incremental planning
 In this task, the incremental plan is developed.
 The functionality of each increment, projected size of the increment and the
cleanroom development schedule is created.
 The care is to be taken that each increment is certified and integrated in
proper time according to the plan.
2. Requirements gathering
 Requirement gathering is done using the traditional techniques like analysis,
design, code, test and debug.
 A more detailed description of the customer level requirement is developed.
3. Box structure specification
 The specification method uses box structure.
 Box structure is used to describe the functional specification.
 The box structure separate and isolate the behavior, data and procedure in
each increment.
4. Formal design
 The cleanroom design is a natural specification by using the black box
structure approach.
 The specification is called as state boxes and the component level diagram
called as the clear boxes.
5. Correctness verification
 The cleanroom conducts the exact correctness verification activities on the
design and then the code.
 Verification starts with the highest level testing box structure and then
moves toward the design detail and code.
 The first level of correctness takes place by applying a set of 'correcting
questions'.
 More mathematical or formal methods are used for verification if
correctness does not signify that the specification is correct.
6. Code generation, inspection and verification
 The box structure specification is represented in a specialized language and
these are translated into the appropriate programming language.
 Use the technical reviews for the syntactic correctness of the code.
7. Statistical test planning
 Analyzed, planned and designed the projected usages of the software.
 The cleanroom activity is organized in parallel with specification, verification
and code generation.
8. Statistical use testing
 The exhaustive testing of computer software is impossible. It is compulsory
to design limited number of test cases.
 Statistical use technique execute a set of tests derived from a statistical
sample in all possible program executions.
 These samples are collected from the users from a targeted population.
9. Certification
 After the verification, inspection and correctness of all errors, the
increments are certified and ready for integration.
9.) Explain the validation planning steps.

Ans:
Software validation confirms that certain specifications coincide with user needs, the software
is meeting intended use and requires objective evidence that the requirements can be
consistently fulfilled. This is required for any company covered by the Food, Drug and Cosmetic
Act and 21 CFR Parts 210 and 211. Also, if a company is keeping current Good Manufacturing
Practice (cGMP) data electronically and relying on that information to make cGMP decisions,
they are required to perform software validation. Manufacturers who continue to see increased
enforcement of these regulations include pharmaceutical, nutritional supplement and cosmetic
companies. For small to mid-sized manufacturing companies, software validation
1. USER REQUIREMENTS DOCUMENT
Create a user requirements document that contains a quick list of one or two-line sentences identifying
the functionality that is required for your business. This is not to be confused with a Request for
Proposal (RFP). Typically, RFP documents are all inclusive and geared toward larger companies. Gather
your validation team together and brainstorm what functionality you require. Examples of user
requirements include: “System must be able to track lot numbers for raw materials and manufactured
product” or “An item needs to be able to be tracked with different quality control status.” Preparing the
user requirements document prior to your software selection process will help to ensure that you select
a product that will best fit your needs.
2. PROJECT PLAN
In creation of the project plan you will identify who, what, where and when the validation will occur. A
validation team will oversee the entire process, and typically includes the project manager, technical
lead, quality assurance lead, validation lead and a support lead. Responsibilities of each team position
should be explained in the project plan. The project plan should also include a system description,
purpose, environment specifications, assumptions, exclusions, limitations, testing, acceptance criteria,
error resolution and system documentation. There are various websites with samples and templates
available to get you started.
3. FUNCTIONAL SPECIFICATIONS DOCUMENT
Create a functional specifications document that is an extension of the user requirements, but contains
slightly more information. Each requirement now expands to three or four sentences. Let’s refer to the
user requirements example of “System must be able to track lot numbers for raw materials and
manufactured product.” The system will assign the internal lot number automatically upon receipt of a
raw material. Manufactured item lot numbers will be assigned automatically based on the batch ticket
number. A link is desired between the user and functional requirements as it will certify the testing
prerequisites. The end result is an accountability matrix that will allow you to trace your tests back to
the requirements.
4. GAP ANALYSIS
A review of the functional specifications occurs and a gap analysis is created. The gap analysis is used to
determine risk, or the difference between the desired performance and the existing performance. These
risks should be documented and prioritized. If a gap is identified as a high risk, it becomes important to
ensure that your procedures will mitigate the risk.
5. INSTALLATION PROTOCOL
The installation protocol document outlines how the software should be installed. This would
customarily be provided by your vendor. The document may also include hardware specifications and
installation instructions. Typically, it will include areas to document verification of specifications for the
hardware and software.
6. INSTALLATION REPORT
This document serves as evidence that the software was installed correctly according to the vendor
recommendations and design. If your vendor performed the installation, they will provide you with this
information.
7. TESTING PROTOCOL
The testing protocol document outlines the specific objectives, procedures, data sets, test scenarios,
expected results and acceptance criteria for the system testing process. These protocols should test the
software components your company will utilize. It is not necessary to test every setting available. The
software vendor should have already tested the various setting combinations. The testing protocol
should simply include evidence that a test was performed. Evidence might include screen shots and
report print outs documenting the projected result. This information will be used to generate the testing
report.
8. TESTING REPORT
The testing report is an outline of the testing that has occurred. Typically, it will include an executive
summary of the test execution that addresses adherence to test procedures, acceptability of results, as
well as any unexpected results.
9. SYSTEM RELEASE/GO-LIVE
The system release allows the software to be used in production. By this time, the users have been
trained, data has been entered and business scenarios have been completed. The users can now begin
using the software.
10. VALIDATION COMPLETE
Once the validation is complete, the system must be maintained in a validated state. Maintaining this
state requires that standard operating procedures are in place for addressing problematic concerns and
resolution, change control, record retirement, etc. If changes are required within the system, the
changes should be reviewed and assessed for risk. Necessary changes should be authorized,
documented, tested and approved before implementation occurs.
10.) Explain the security assessment.
Ans:
Security assessment
•Security assessment has something in common with safety assessment.
•It is intended to demonstrate that the system cannot enter some state (an unsafe or an
insecure state) rather than to demonstrate that the system can do something.
•However, there are differences
–Safety problems are accidental; security problems are deliberate;
–Security problems are more generic - many systems suffer from the same problems; Safety
problems are mostly related to the application domain
11.) Explain the software quality standard with example.

Ans:
12.) Write short notes on (any two) :

a.) CASE tools
b.) Reverse Engineering
c.) Reliability validation
Ans:
a.) Computer-Aided Software Engineering (CASE) technologies are tools that provide automated
assistance for software development. The goal of introducing CASE tools is the reduction of the
time and cost of software development and the enhancement of the quality of the systems
developed. The interest in CASE tools and environments is based on expectations about
increasing productivity, improving product quality, facilitating maintenance, and making
software engineers' task less odious and more enjoyable. A survey of the CASE tool
market showed that the annual worldwide market for CASE fools was $4.8 billion in 1990 and
grew to $12.11 billion in 1995. Behind such a prosperous CASE market, however, another result
gained from the real investigation about the use of CASE tools revealed that CASE tools seem to
be sparsely used after being bought in many enterprises.
CASE is the use of computer-based support in the software development process; a CASE tool is
a computer-based product aimed at supporting one or more software engineering activities
within a software development process; a CASE environment is a collection of CASE tools and
other components together with an integration approach that supports most or all of the
interactions that occur among the environment components, and between the users of the
environment and the environment itself.
b.) Reverse engineering is taking apart an object to see how it works in order to
duplicate or enhance the object. The practice, taken from older industries, is now
frequently used on computer hardware and software. Software reverse engineering
involves reversing a program's machine code (the string of 0s and 1s that are sent to
the logic processor) back into the source code that it was written in, using program
language statements.
Software reverse engineering is done to retrieve the source code of a program because
the source code was lost, to study how the program performs certain operations, to
improve the performance of a program, to fix a bug (correct an error in the program
when the source code is not available), to identify malicious content in a program such
as a virus or to adapt a program written for use with one microprocessor for use with
another.
c.)
Reliability validation involves exercising the program to assess whether or not it has reached
the required level of reliability.
•This cannot normally be included as part of a normal defect testing process because data for
defect testing is (usually) atypical of actual usage data.
•Reliability measurement therefore requires a specially designed data set that replicates the
pattern of inputs to be processed by the system.
Reliability validation activities
•Establish the operational profile for the system.
•Construct test data reflecting the operational profile.
•Test the system and observe the number of failures and the times of these failures.
•Compute the reliability after a statistically significant number of failures have been observed.
2071
1.) What is software? Discuss generic products and bespoke products

with example. Discuss functional and non-functional system
properties with example.
Ans:
Software is a general term for the various kinds of programs used to operate computers
and related devices. (The term hardware describes the physical aspects of computers
and related devices.)
Generic
- developed to be sold to a range of different customers e.g. PC software such as Excel
or Word. In this the organization that develops the software controls the software
specification.
● Bespoke (Customized)
- developed for a single customer according to their specification. For example air traffic
control system. In this the client organization that is buying the software controls the
software specification.
Functional requirements
•Describe functionality or system services
•Depend on the type of software, expected users and the type of system where the software is
used
•Functional user requirements may be high-level statements of what the system should do but
functional system requirements should describe the system services in detail
Examples of functional requirements

•The user shall be able to search either all of the initial set of databases or select a subset from
it.
•The system shall provide appropriate viewers for the user to read documents in the document
store.
•Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to
copy to the account’s permanent storage area.
Non-functional requirements
•Define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.
•Process requirements may also be specified mandating a particular CASE system, programming
language or development method
•Non-functional requirements may be more critical than functional requirements. If these are
not met, the system is useless
Non-functional requirements examples

•Product requirement
–4.C.8 It shall be possible for all necessary communication between the APSE and the user to
be expressed in the standard Ada character set
• Organizational requirement
–9.3.2 The system development process and deliverable documents shall conform to the
process and deliverables defined in XYZCo-SP-STAN-95
•External requirement
–7.6.5 The system shall not disclose any personal information about customers apart from their
name and reference number to the operators of the system
2.) What is software process model? Discuss reuse-oriented

development in detail.
Ans:
A software process model is an abstract representation of a process.

It presents a description of a process from some particular perspective.
Examples of process perspectives:
Workflow perspective - represents inputs, outputs and dependencies
Data-flow perspective - represents data transformation activities
Role/action perspective - represents the roles/activities of the people involved in the
software process
Generic process models
1. The waterfall model
Plan-driven model. Separate and distinct phases of specification and development.
2. Incremental (exploratory) development
Specification, development and validation are interleaved. May be plan-driven or agile.
3. Reuse-oriented software engineering
The system is assembled from existing components. May be plan-driven or agile.
Process iteration
•System requirements ALWAYS evolve in the course of a project so process iteration where
earlier stages are reworked is always part of the process for large systems.
•Iteration can be applied to any of the generic process models.
•Two (related) approaches
–Incremental delivery;
–Spiral development.
Incremental delivery
•Rather than deliver the system as a single delivery, the development and delivery is broken
down into increments with each increment delivering part of the required functionality.
•User requirements are prioritized and the highest priority requirements are included in early
increments.
•Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve.
3.) Discuss the importance of project management. What are the

different sections of project plan?
Ans:
1. Strategic Alignment
Project management is important because it ensures what is being delivered, is right, and will deliver
real value against the business opportunity.
Every client has strategic goals and the projects that we do for them advance those goals. Project
management is important because it ensures there’s rigor in architecting projects properly so that they
fit well within the broader context of our client’s strategic frameworks Good project management
ensures that the goals of projects closely align with the strategic goals of the business.
2. Leadership
Project management is important because it brings leadership and direction to projects.
Without project management, a team can be like a ship without a rudder; moving but without direction,
control or purpose. Leadership allows and enables a team to do their best work. Project management
provides leadership and vision, motivation, removing roadblocks, coaching and inspiring the team to do
their best work.
3. Clear Focus & Objectives
Project management is important because it ensures there’s a proper plan for executing on strategic
goals.
As project managers, we position ourselves to prevent such a situation and drive the timely
accomplishment of tasks, by breaking up a project into tasks for our teams. Oftentimes, the foresight to
take such an approach is what differentiates good project management from bad. Breaking up into
smaller chunks of work enables teams to remain focused on clear objectives, gear their efforts towards
achieving the ultimate goal through the completion of smaller steps and to quickly identify risks,
since risk management is important in project management.
4. Realistic Project Planning
Project management is important because it ensures proper expectations are set around what can be
delivered, by when, and for how much.
Without proper project management, budget estimates and project delivery timelines can be set that
are over-ambitious or lacking in analogous estimating insight from similar projects. Ultimately this
means without good project management, projects get delivered late, and over budget.
5. Quality Control
Projects management is important because it ensures the quality of whatever is being delivered,
consistently hits the mark.
6. Risk Management
Project management is important because it ensures risks are properly managed and mitigated against
to avoid becoming issues.
4.) Discuss requirements elicitation and analysis activity of

requirements engineering process.
Ans:
Elicitation and analysis

• Sometimes called requirements elicitation or requirements discovery
• Involves technical staff working with customers to find out about the application domain, the
services that the system should provide and the system’s operational constraints
•May involve end-users, managers, engineers involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders
Requirements discovery
The process of gathering information about the required and existing systems and
distilling the user and system requirements from this information.
Interaction is with system stakeholders from managers to external regulators.
Systems normally have a range of stakeholders.
Requirement discovery methods:
● Interview
● Questionnaire
● Survey
Interviewing
Types of interview
● Closed interviews based on per-determined list of questions
● Open interviews where various issues are explored with stakeholders.
5.) Discuss evolutionary prototyping and throw-away prototyping in
the software process.
Ans:
Throwaway prototyping model:
Throwaway Prototyping Model is especially useful when the project needs are vaguely and
poorly laid out. It functions by providing proof that something can indeed be done in terms of
systems and strategies. Throwaway Prototyping Model is used for certain projects and will
eventually be discarded after the project has been completed. It is also known as Close-Ended
Prototyping.
There are 5 phases involved when using Throwaway Prototyping model.
• Identification of requirements and materials to be used
Although most requirements are unknown because the process works through “discovery
method”, the basics should be identified so that the project can begin.
• Planning
The ability of the project management team to plan well is necessary for Throwaway Prototyping
model to work. The team is a huge factor for its success; with this model you can expect
numerous surprises coming your way so having the skills necessary to resolve problems is a
must.
• Implementation, Prototyping and Verification
Once planning has been completed, implementation of the project will then take place.
Prototypes will be created and introduced to end users who will utilize them for testing and
evaluation purposes. At this time, they will be providing feedback, clarify needs and relay
requirements.
• Prototype Enhancements and Revisions
As per requirements of end users derived through feedback and testing, the prototypes will be
continuously altered until such time it has reached near-perfection.
• Finalization
Once everything has been set and issues have been properly addressed, the prototype will then
be “thrown away” and a product or service will be developed, taking into consideration the
feedback derived during the verification process.
6.) Why do we need formal specification? Discuss behavioral

specification in detail.
Ans:
A formal specification should
• add clarity and understanding by giving a description of the system which is – complete –
unambiguous – easily analyzed;
• lead to better code that is – reliable – accurate – maintainable – reusable – verified.
7.) What are the advantages of designing and documenting software
architecture? What is repository model?
Ans:
Advantages:
1. Stakeholder communication: The architecture is a high-level presentation of the
system that may be used as a focus for discussion by a range of different stakeholders.
2. System analysis: Making the system architecture explicit at an early stage in the
system development requires some analysis. Architectural design decisions have a
profound effect on whether or not the system can meet critical requirements such as
performance, reliability, and maintainability.
3. Large-scale reuse: A model of system architecture is a compact, manageable
description of how a system is organized and how the components interoperate. The
system architecture is often the same for systems with similar requirements and so can
support large-scale software reuse.
Repository model:
Subsystems making of a system must exchange information, so that they can work together
effectively. There are two fundamental ways in which this can be done.
 All shared data is held in a central database that can be accessed by all subsystems.
 Each subsystem maintains its own database. Data is interchanged with other subsystem
by passing massage to them.
This model is suitable to the application when data is gathered by one subsystem and used by
another subsystem.
8.) Discuss the use of control models. Differentiate between

centralized control and event based control.
9.) Discuss sequence diagram with suitable example.
Ans:
Sequence Diagram
Sequence diagrams describe interactions among classes in terms of an exchange of messages
over time. They're also called event diagrams. A sequence diagram is a good way to visualize
and validate various runtime scenarios. These can help to predict how a system will behave and
to discover responsibilities a class may need to have in the process of modeling a new system.
Basic Sequence Diagram Notations
Class Roles or Participants
Class roles describe the way an object will behave in context. Use the UML object symbol to
illustrate class roles, but don't list object attributes.
Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a task. When an object is busy
executing a process or waiting for a reply message, use a thin gray rectangle placed vertically on
its lifeline.
Messages
Messages are arrows that represent communication between objects. Use half-arrowed lines to
represent asynchronous messages. Asynchronous messages are sent from an object that will not
wait for a response from the receiver before continuing its tasks. For message types, see below.
Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.
Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X. This
object is removed from memory. When that object's lifeline ends, you can place an X at the end
of its lifeline to denote a destruction occurrence.
Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for
exiting the loop at the bottom left corner in square brackets
10.) What is verification and validation? Briefly explain verification

and validation planning.
Ans:
Verification
It is an act of reviewing, inspection, testing, checking, auditing or otherwise establishing and
documenting whether items, processes, services or documents conform to specific
requirements.
It can also be defined as the process of evaluating a system or component to determine
whether the products of a give development phase satisfy the conditions imposed at eh start of
the phase.
Validation
Validation is the process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies specified requirements. Validation is,
therefore, ‘end-to-end’ verification. Validation occurs through the utilization of various testing
approaches.
Planning verification and validation:
The development of a V & V plan is essential to the success of a project. The plan must
be development early in the project. Careful planning is required to get the most out of
testing and inspection process. Effective V & V plan requires many considerations that
are:
1. Identification of V & V Goals:

V & V goals must be identified from the requirements and specifications. These
goals must address those attributes of the product that correspond to its user
expectations.
2. Selection of V & V Techniques:

Specific techniques must be selected for each of the project‟s evolving products.
3. Organizational Responsibilities:
The organizational structure of a project is a key planning consideration for
project managers. An important aspect of this structure is a delegation of V & V
activities to various organizations.
4. Integrating V & V Approaches:

Once a set of V & V objectives has been identified, an overall integrated V & V
approach must be determined. This approach involves the integration of
techniques applicable to the various life cycle phases as a delegation of these
tasks among the project‟s organizations. The planning of this integrated V & V
approach is very dependent upon the nature of the product and the process used
to develop it. Traditional integrated V & V approaches have followed the
“Waterfall model”.
5. Problem Tracking:
Software V & V plan to develop a mechanism for documenting problems
o When the problem occurred
o Where the problem occurred
o Evidence of the problem
o Priority for solving problem
11.) What is integration testing? Differentiate between top-down and

bottom up integration testing.
Ans:
Integration testing is a software testing methodology used to test individual software
components or units of code to verify interaction between various software components
and detect interface defects. Components are tested as a single group or organized in
an iterative manner. After the integration testing has been performed on the
components, they are readily available for system testing.
NO Top- Down Testing Bottom-UP Testing
Top-Down testing conducted from main-module Bottom-Up testing conducted from sub module to
1
to sub module. main module.
If sub module is not developed a temporary If main module is not developed a temporary
2 program called Stub is used for simulate the program called Driver is used to simulate the
submodule. main module.
Top -Down testing good if major flaws occur Bottom-Up Testing good if major flaws occur
3
toward the top of the program. toward the bottom of the program.
4 In this test condition difficult to create. In this test condition easy to create.
5 Observation of test output is more difficult. Observation of test output is easier.
12.) Write short notes on:

a.) Functional Point
A function point is a unit of measurement to express the amount of business
functionality an information system provides to a user. The cost (in dollars or hours) of a
single unit is calculated from past projects.
A function point is a "unit of measurement" to express the amount of business functionality
an information system (as a product) provides to a user. Function points are used to compute a
functional size measurement (FSM) of software.
b.) Source Code Translation
2069
1.) Explain the software and its characteristics.

Ans: See in 2073 Q1.
2.) Explain the prototyping model of software development.
Ans:
3.) Define the COCOMO model with example.
Ans: The Constructive Cost Model (COCOMO) is an algorithmic software cost
estimation model developed by Barry Boehm. The model uses a basic
regression formula, with parameters that are derived from historical project
data and current project characteristics.
COCOMO was first published in 1981 Barry W. Boehm's Book Software

engineering economics[1] as a model for estimating effort, cost, and
schedule for software projects. It drew on a study of 63 projects at TRW
Aerospace where Barry Boehm was Director of Software Research and
Technology in 1981. The study examined projects ranging in size from 2,000
to 100,000 lines of code, and programming languages ranging from
assembly to PL/I. These projects were based on the waterfall model of
software development which was the prevalent software development
process in 1981.
An empirical model based on project experience.

•Well-documented, ‘independent’ model which is not tied to a specific software vendor.
•Long history from initial version published in 1981 (COCOMO*-81) through various
instantiations to COCOMO 2.
•COCOMO 2 takes into account different approaches to software development, reuse, etc.
COCOMO 81 was developed with the assumption that a waterfall process would be used and
that all software would be developed from scratch.
•Since its formulation, there have been many changes in software engineering practice and
COCOMO 2 is designed to accommodate different approaches to software development.
4.) Why an evolutionary prototyping is used in software

development? Explain.
Ans: See 2071 Q5.
5.) What do you mean by behavioral specification?
Ans: See 2071 Q6.
6.) Why modular decomposition is used in architectural design?
Explain.
Ans:
7.) Explain the sequence diagram with example.

Ans:See 2071 Q9.
8.) Explain the clean room software development with example.
Ans: See in 2071( II) Q8.
9.) What are the types of software testing? Explain.
Ans:
Types of testing
There are many types of testing like
 Unit Testing
 Integration Testing
 Functional Testing
 System Testing
 Stress Testing
 Performance Testing
 Usability Testing
 Acceptance Testing
 Regression Testing
 Beta Testing
Unit Testing
Unit testing is the testing of an individual unit or group of related units. It falls under the class of
white box testing. It is often done by the programmer to test that the unit he/she has implemented
is producing expected output against given input.
Integration Testing
Integration testing is testing in which a group of components are combined to produce output. Also,
the interaction between software and hardware is tested in integration testing if software and
hardware components have any relation. It may fall under both white box testing and black box
testing.
Functional Testing
Functional testing is the testing to ensure that the specified functionality required in the system
requirements works. It falls under the class of black box testing.
System Testing
System testing is the testing to ensure that by putting the software in different environments (e.g.,
Operating Systems) it still works. System testing is done with full system implementation and
environment. It falls under the class of black box testing.
Stress Testing
Stress testing is the testing to evaluate how system behaves under unfavorable conditions. Testing is
conducted at beyond limits of the specifications. It falls under the class of black box testing.
Performance Testing
Performance testing is the testing to assess the speed and effectiveness of the system and to make
sure it is generating results within a specified time as in performance requirements. It falls under the
class of black box testing.
Usability Testing
Usability testing is performed to the perspective of the client, to evaluate how the GUI is user-
friendly? How easily can the client learn? After learning how to use, how proficiently can the client
perform? How pleasing is it to use its design? This falls under the class of black box testing.
Acceptance Testing
Acceptance testing is often done by the customer to ensure that the delivered product meets the
requirements and works as the customer expected. It falls under the class of black box testing.
Regression Testing
Regression testing is the testing after modification of a system, component, or a group of related
units to ensure that the modification is working correctly and is not damaging or imposing other
modules to produce unexpected results. It falls under the class of black box testing.
Beta Testing
Beta testing is the testing which is done by end users, a team outside development, or publicly
releasing full pre-version of the product which is known as beta version. The aim of beta testing is to
cover unexpected errors. It falls under the class of black box testing.
10.) Explain the reliability validation with example.

11.) What is USE CASE diagram? Explain with example.
Ans:
Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions
(use cases) that some system or systems (subject) should or can perform in collaboration with
one or more external users of the system (actors). Each use case should provide some observable
and valuable result to the actors or other stakeholders of the system.
Note, that UML 2.0 to 2.4 specifications also described use case diagram as a specialization of
a class diagram, and class diagram is a structure diagram.
Use case diagrams are in fact twofold - they are both behavior diagrams, because they describe
behavior of the system, and they are also structure diagrams - as a special case of class diagrams
where classifiers are restricted to be either actors or use cases related to each other
with associations.
Use case diagrams are used to specify:
 (external) requirements, required usages of a system under design or analysis (subject) - to
capture what the system is supposed to do;
 the functionality offered by a subject – what the system can do;
 requirements the specified subject poses on its environment - by defining how environment
should interact with the subject so that it will be able to perform its services.
Major elements of the UML use case diagram are shown on the picture below.
12.) Write short notes on (any two):-
a.) User Interface Prototyping
Ans: User interface (UI) prototyping is an iterative analysis technique in which users are
actively involved in the mocking-up of the UI for a system. UI prototypes have several
purposes:
 As an analysis artifact that enables you to explore the problem space with your
stakeholders.
 As a requirements artifact to initially envision the system.
 As a design artifact that enables you to explore the solution space of your
system.
 A vehicle for you to communicate the possible UI design(s) of your system.
 A potential foundation from which to continue developing the system (if you
intend to throw the prototype away and start over from scratch then you don't
need to invest the time writing quality code for your prototype).
b.) Software Inspection (see in 2073 Q8.)
c.) Source Code Translation (See in 2071 Q12)
2068
1. Explain the software engineering and its role in Nation Development.

Ans:
Software Engineers are very important to the technology world today. They create software that we use
every day, such as Microsoft Office, E-mail, Games, or anything that involves the use of computer
systems or mobile system software’s. Designing software for the consumers takes much time and detail
in order to get the software perfectly made. Depending on the company they work for, they could be
designing software from little games to software that could possibly change how computer systems
operate. Software Engineers are the heart behind the making of computer applications and mobile
applications, this career offers internships, where you earn on-the-job training; they create and design
software to meet consumer’s needs, the job offers high pay and the possibility for advancements
throughout your career.
Software Engineers create software for computer systems, so they can run smoothly and properly.
These engineers also test and evaluate software for each type of computer platform. They create
software for computer operating systems such as, Windows and Mac. Types of software include games,
spreadsheets, databases, and accounting software (Kirk 35). In order to design these types of software
for businesses and consumers, software engineers must know how to use programming languages such
as, C, C++, and Java
2. Explain the waterfall model with its merits and demerits.

3. What are the important activities that are carried out during the
feasibility study phase? Explain.
4. What are the different categories of software development projects
according to the COCOMO estimation model? Explain.
5. What are the five desirable characteristics of a good software
requirements specification (SRS) document?
Ans:See in 2073 Q7.
6. What are the main advantages of using an object-oriented design
approach over a function-oriented approach? Explain.
Ans:
Object-oriented databases make the promise of reduced maintenance, code reusability, real world
modeling, and improved reliability and flexibility. However, these are just promises and in the
real world some users find that the object-oriented benefits are not as compelling as they
originally believed. For example, what is code reusability? Some will say that they can reuse
much of the object-oriented code that is created for a system, but many say there is no more code
reusability in object-oriented systems than in traditional systems. Code reusability is a subjective
thing, and depends heavily on how the system is defined. The object-oriented approach does
give the ability to reduce some of the major expenses associated with systems, such as
maintenance and development of programming code. Here are some of the benefits of the
object-oriented approach:
Reduced Maintenance: The primary goal of object-oriented development is the assurance that
the system will enjoy a longer life while having far smaller maintenance costs. Because most of
the processes within the system are encapsulated, the behaviors may be reused and incorporated
into new behaviors.
Real-World Modeling: Object-oriented system tend to model the real world in a more
complete fashion than do traditional methods. Objects are organized into classes of objects, and
objects are associated with behaviors. The model is based on objects, rather than on data and
processing.
Improved Reliability and Flexibility: Object-oriented system promise to be far more reliable
than traditional systems, primarily because new behaviors can be "built" from existing objects.
Because objects can be dynamically called and accessed, new objects may be created at any
time. The new objects may inherit data attributes from one, or many other objects. Behaviors
may be inherited from super-classes, and novel behaviors may be added without effecting
existing systems functions.
High Code Reusability: When a new object is created, it will automatically inherit the data
attributes and characteristics of the class from which it was spawned. The new object will also
inherit the data and behaviors from all superclasses in which it participates. When a user creates
a new type of a widget, the new object behaves "wigitty", while having new behaviors which are
defined to the system.
7. Differentiate between black box testing and white box testing.

Ans:
# Black Box Testing White Box Testing
Black box testing is the Software White box testing is the software testing
testing method which is used to test method in which internal structure is being
1 the software without knowing the known to tester who is going to test the
internal structure of code or program. software.
This type of testing is carried out by Generally, this type of testing is carried out
2 testers. by software developers.
Implementation Knowledge is not

Implementation Knowledge is required to
3 required to carry out Black Box
carry out White Box Testing.
Testing.
Programming Knowledge is not

Programming Knowledge is required to carry
4 required to carry out Black Box
out White Box Testing.
Testing.
Testing is applicable on higher levels

Testing is applicable on lower level of testing
5 of testing like System Testing,
like Unit Testing, Integration testing.
Acceptance testing.
Black box testing means White box testing means structural test or
6 functional test or external testing. interior testing.
In White Box testing is primarily concentrate

In Black Box testing is primarily
on the testing of program code of the
7 concentrate on the functionality of the
system under test like code structure,
system under test.
branches, conditions, loops etc.
8. What do you mean by functional and non-functional requirements?

Explain.
9. Explain the rapid prototyping techniques.
10. Differentiate between interface specification and behavioral
specification.
11. Explain class diagram with example.
Ans:
Many people consider class diagrams a bit more complicated to build compared with
ER diagrams. Most of the time it‟s because of the inability to understand the different
relationships between class diagram. This article explains how to correctly determine
and implement the different class diagram relationships that are applicable in object-
oriented modeling. What‟s more, you can easily create class diagrams using our
diagramming tool.
Relationships in UML class diagrams
What are Class Diagrams?
Class diagrams are the main building block in object-oriented modeling. They are used
to show the different objects in a system, their attributes, their operations and the
relationships among them.
The following figure is an example of a simple class:
Simple class diagram with attributes and operations
In the example, a class called “loan account” is depicted. Classes in class diagrams are
represented by boxes that are partitioned into three:
1. The top partition contains the name of the class.

2. The middle part contains the class‟s attributes.
3. The bottom partition shows the possible operations that are associated with the
class.
12. Write short notes on ( any two):

a. Software inspection (See in 2073 Q8.)
b. Software validation (See in 2069 Q12(b))
c. Reverse Engineering (See in 2071 Q12(b))

Software Eng Solution 68-73 Ex 72 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Eng Solution 68-73 Ex 72 PDF

Transféré par

Droits d'auteur :

Formats disponibles

This solution is downloaded and managed

Follow me on instagram My youtube channel My Facebook

Note : if you found any mistake on solution

Institute of Science and Technology

Computer Science and Information Technology-(CSc.351) Pass Marks: 32

1. Differentiate between software and software engineering. What

2. Maintainability: Maintenance of the software should be easy for any kind of

5. Usability/Learnability: The amount of efforts or time required to learn how to

6. Flexibility: Changes in the software should be easy to make.

2. What are the major phases of waterfall model and spiral

Phases of Waterfall Model:

Advantages of Spiral Model:

7) A highly customized product can be developed using this.

3. What are the major task of requirement engineering activity?

 Improves project teams’ focus

Types of feasibility study:

A feasibility study evaluates the project’s potential for s uccess; therefore,

6. What are the different types of requirement elicitation

It is highly recommended to review or test SRS documents before start

Any good requirement should have these 6 characteristics:

The requirements must be complete, what is the meaning of completeness?

Unambiguous means a single interpretation. If a requirement is defined in such a manner that it

8. How software inspection improves software

10. Differentiate between Verification and Validation.

Verification is the process of evaluating Validation is the process of evaluating

Following activities are involved Following activities are involved

Verification is carried out by QA team to Validation is carried out by testing team.

Execution of code is not comes Execution of code is comes

12. Write short notes on:

b.) Data Dictionary:

A data dictionary is a collection of descriptions of the data objects or items in a data

Institute of Science and Technology

Computer Science and Information Technology-(CSc.351) Pass Marks: 32

1. Requirement gathering and analysis

3) Implementation / Coding: On receiving system design documents, the work is divided in

2.) Explain the software process model with example.

A software process model is an abstract representation of a process.

3.) Explain the software specification, software validation and

Software Verification and validation

4.) What do you mean by project management? Explain the project

Project management oversees the planning, organizing and implementing of a project.

 Setting objectives (these should be measurable)

 Planning the schedule

 Making supporting plans

The goal of requirement engineering is to develop and maintain

Requirement Engineering Process

Referencing to this information, the analysts does a detailed study about

Software Requirement Specification

Software Requirement Validation

 If they can be practically implemented

6.) Define formal specification. Explain the formal specification

Acceptance of formal methods

7.) Explain the software maintenance and its types.

 Host Modifications - If any of the hardware and/or platform (such as

 Organization Changes - If there is any business level change at

 Corrective Maintenance - This includes modifications and updations

 Adaptive Maintenance - This includes modifications and updations

 Perfective Maintenance - This includes modifications and updates

 Preventive Maintenance - This includes modifications and updations

Following tasks occur in cleanroom engineering:

9.) Explain the validation planning steps.

11.) Explain the software quality standard with example.

12.) Write short notes on (any two) :