PTU Software Engineering Paper May 2013

Section-A

a) Differentiate characteristics of Software and Hardware.

Hardware:
 Physical parts of the computer are called hardware.
 You can touch, see and feel hardware.
 Hardware is constructed using physical materials or components.
 Computer is hardware, which operates under the control of a software.
 If hardware is damaged, it is replaced with new one.
 Hardware is not affected by computer viruses.
 Hardware cannot be transferred from one place to another electronically
through network.
 User cannot make new duplicate copies of the hardware.

Software:
 A set of instructions given to the computer is called software.
 You cannot touch and feel software.
 Software is developed by writing instructions in programming language.
 The operations of computer are controlled through software.
 If software is damaged or corrupted, its backup copy can be reinstalled.
 Software is affected by computer viruses.
 Software can be transferred from one lace to another electronically through
network.
 User can make many new duplicate copies of the software.

b) Differentiate Function Oriented Software Design(FOD) and Object Oriented

Design(OOD).

1. FOD: The basic abstractions, which are given to the user, are real world functions.
OOD: The basic abstractions are not the real world functions but are the data
abstraction where the real world entities are represented.
2. FOD: Functions are grouped together by which a higher level function is Page on
obtained. E.g. of this technique is SA/SD.
OOD: Functions are grouped together on the basis of the data they operate since the
classes are associated with their methods.
3. FOD: In this approach the state information is often represented in a centralized
shared memory.
OOD: In this approach the state information is not represented in a centralized
memory but is implemented or distributed among the objects of the system.
4. FOD approach is mainly used for computation sensitive application,
OOD: whereas OOD approach is mainly used for evolving system which mimics a
business process or business case.
PTU Software Engineering Paper May 2013

5. In FOD – we decompose in function/procedure level

OOD: – we decompose in class level
6. FOD: Top down Approach
OOD: Bottom up approach
7. FOD: It views system as Black Box that performs high level function and later
decompose it detailed function so to be mapped to modules.
OOD: Object-oriented design is the discipline of defining the objects and their
interactions to solve a problem that was identified and documented during object-
oriented analysis.
8. FOD: Begins by considering the use case diagrams and Scenarios.
OOD: Begins by identifying objects and classes

c) What is code documentation?

Documentation is a set of documents provided on paper, or online, or on digital or

analog media, such as audio tape or CDs. Examples are user guides, white papers, on-
line help and quick-reference guides. It is becoming less common to see paper (hard-
copy) documentation.
Software documentation is written text or illustration that accompanies computer
software. It either explains how it operates or how to use it, or may mean different
things to people in different roles. Documentation is an important part of software
engineering.

d) Enumerate characteristics of good User Interface Design.

Clear and Simple : A good user interface provides a clear understanding of what is
happening behind the scenes or provides visibility to the functioning of the system.
Creative but familiar: When the users are familiar with something and know how it
behaves, navigation becomes easier.
Intuitive and consistent: The controls and information must be laid out in an
intuitive and consistent way for an interface to be easy to use and navigate.
Responsive: If the interface fails to keep up with the demands of the user, this will
significantly diminish their experience and can result in frustration, particularly when
trying to perform basic tasks.
Maintainable: A UI should have the capacity for and changes to be integrated
without causing a conflict of interest.

e) What is the purpose of Rayleigh curve?

In the study of software project scheduling, the Putnam–Norden–Rayleigh curve,

also known as the PNR curve, is an equation specifying the relationship between
applied effort and delivery time for a software project. A PNR curve can be used to
determine the least cost time for delivery up to the limit , the absolute minimal
amount of time required to complete the project no matter how many human
resources are added. The PNR curve was used to derive the Software equation.
PTU Software Engineering Paper May 2013

f) Differentiate verification and validation.

Verification Validation

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

products of a development phase to find out software at the end of the development
whether they meet the specified process to determine whether software meets
requirements. 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 testing,
Inspections. white box testing, grey 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 the
Validation. Verification.

Following items are evaluated Following item is evaluated

during Verification: Plans, Requirement during Validation: Actual product or
Specifications, Design Specifications, Code, Software under test.
Test Cases etc.,

Cost of errors caught in Verification is less Cost of errors caught in Validation is more
than errors found in Validation. than errors found in Verification.

g) Differentiate between Flowchart and Decision Tree.

PTU Software Engineering Paper May 2013

A flowchart is a prescription of what needs to be done in what order to solve a

problem. It often a basis for putting something together or for writing a computer
program. Whereas a decision tree has probabilities and costs or benefits, a flow
chart has none of these. It’s completely deterministic.
A decision tree is a decision support tool that uses a tree-like graph or model of
decisions and their possible consequences, including chance event outcomes, resource
costs, and utility. It is one way to display an algorithm.

h) Explain the concept of Reverse Engineering.

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.

i) Differentiate Error, Fault and Failure.

Fault: It is a condition that causes the software to fail to perform its required
function.
Error: Refers to difference between Actual Output and Expected output.
Failure: It is the inability of a system or component to perform required function
according to its specification.

j) What are different levels of Testing?

There are generally four recognized levels of tests: unit/component

testing, integration testing, system testing, and acceptance testing. Tests are
frequently grouped by where they are added in the software development process, or
by the level of specificity of the test.
PTU Software Engineering Paper May 2013

Section-B
2. Discuss in detail the life journey of a software product.

SDLC, Software Development Life Cycle is a process used by software industry to design, develop and
test high quality software’s. The SDLC aims to produce a high quality software that meets or exceeds
customer expectations, reaches completion within times and cost estimates.
SDLC is the acronym of Software Development Life Cycle.
It is also called as Software development process.
The software development life cycle (SDLC) is a framework defining tasks performed at each step in
the software development process.
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the
standard that defines all the tasks required for developing and maintaining software.

The following figure is a graphical representation of the various stages of a typical SDLC.

A typical Software Development life cycle consists of the following

stages:

Stage 1: Planning and Requirement Analysis

PTU Software Engineering Paper May 2013

Requirement analysis is the most important and fundamental stage in SDLC. It is performed
by the senior members of the team with inputs from the customer, the sales department,
market surveys and domain experts in the industry. This information is then used to plan the
basic project approach and to conduct product feasibility study in the economical,
operational, and technical areas.
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and document the
product requirements and get them approved from the customer or the market analysts. This
is done through SRS. Software Requirement Specification document which consists of all the
product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the product architecture
SRS is the reference for product architects to come out with the best architecture for the
product to be developed. Based on the requirements specified in SRS, usually more than one
design approach for the product architecture is proposed and documented in a DDS - Design
Document Specification.
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is performed in a
detailed and organized manner, code generation can be accomplished without much hassle.
Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However this stage refers to the
testing only stage of the product where products defects are reported, tracked, fixed and
retested, until the product reaches the quality standards defined in the SRS.
Stage 6: Deployment in the Market and Maintenance
Once the product is tested and ready to be deployed it is released formally in the
appropriate market. Sometime product deployment happens in stages as per the
organizations. business strategy. The product may first be released in a limited segment and
tested in the real business environment (UAT- User acceptance testing).

3. What are the principles of Structured Analysis?

Structured analysis is a software engineering technique that uses graphical diagrams to

develop and portray system specifications that are easily understood by users. These
diagrams describe the steps that need to occur and the data required to meet the design
function of a particular software. This type of analysis mainly focuses on logical systems and
functions, and aims to convert business requirements into computer programs and hardware
specifications. Structured analysis is a fundamental aspect of system analysis.

The major steps involved in the structured analysis process are:

 Studying the current business environment

 Modeling the old logical system
 Modeling a new logical system
 Modeling a new physical environment
 Evaluating alternatives
 Selecting the best design
 Creating structured specifications
PTU Software Engineering Paper May 2013

There are three orthogonal views related to structured analysis:

 Functional View: This involves data flow diagrams, which define the work that has
been done and the flow of data between things done, thereby providing the primary
structure of a solution.
 Data View: This comprises the entity relationship diagram and is concerned with what
exists outside the system that is being monitored.
 Dynamic View: This includes state transition diagrams and defines when things
happen and the conditions under which they may happen.

4. What is the need of software planning? Explain the objectives of software

planning

Project planning is an organized and integrated management process, which focuses

on activities required for successful completion of the project. It prevents obstacles
that arise in the project such as changes in projects or organization's objectives, non-
availability of resources, and so on. Project planning also helps in better utilization of
resources and optimal usage of the allotted time for a project. The other objectives of
project planning are listed below.

 It defines the roles and responsibilities of the project management team

members.
 It ensures that the project management team works according to the business
objectives.
 It checks feasibility of the schedule and user requirements.
 It determines project constraints.

For effective project planning, some principles are followed. These principles are
listed below.

 Planning is necessary: Planning should be done before a project begins.

For effective planning, objectives and schedules should be clear and
understandable.
 Risk analysis: Before starting the project, senior management and the
project management team should consider the risks that may affect the
project. For example, the user may desire changes in requirements while the
project is in progress. In such a case, the estimation of time and cost should be
done according to those requirements (new requirements).
 Tracking of project plan: Once the project plan is prepared, it should be
tracked and modified accordingly.
 Meet quality standards and produce quality deliverables: The project
plan should identify processes by which the project management team can
ensure quality in software. Based on the process selected for ensuring quality,
the time and cost for the project is estimated.
 Description of flexibility to accommodate changes: The result of
project planning is recorded in the form of a project plan, which should allow
new changes to be accommodated when the project is in progress.
PTU Software Engineering Paper May 2013

Ques 5. What are size metrics? How is the function point metric advantages over the LOC
metric? Explain.
Ans 5. Size‐oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced.
•A set of simple size‐oriented metrics can be developed for each project:
• Errors per KLOC (thousand lines of code).
• Defects4 per KLOC.
• $ per LOC.
• Page of documentation per KLOC.
Size‐oriented metrics are not universally accepted as the best way to measure the process of
software development

Drawbacks of LOC

1. It is defined on code. For example it cannot measure the size of specification.

2. It characterise only one specific view of size, namely length, it takes no account of
functionality or complexity
3. Bad software design may cause excessive line of code
4. It is language dependent
5. Users cannot easly understand it

FP data is used in two ways:

1. as an estimation variable that is used to "size" each element of the software,

2. as baseline metrics collected from past projects and used in conjunction with
estimation variables to develop cost and effort projections.

The approach is to identify and count a number of unique function types:

 external inputs (e.g. file names)

 external outputs (e.g. reports, messages)
 queries (interactive inputs needing a response)
 external files or interfaces (files shared with other software systems)
 internal files (invisible outside the system)

Advantages of FP
i. It is not restricted to code
ii. Language independent
iii. The necessary data is available early in a project. We need only a detailed
specification.
iv. More accurate than estimated LOC.

6. Why the characteristics of requirements play significant role in selecting a

model?
Selecting a Software Development Life Cycle (SDLC) methodology is a challenging task for
many organizations.
Selecting the right SDLC is a process in itself that organization can implement internally or
consult for. There are some steps to get the right selection:
PTU Software Engineering Paper May 2013

STEP 1: Learn the about SDLC Models

SDLCs are the same in their usage, advantages, and disadvantages. In order to select the right
SDLC, one must have experience and be familiar with the SDLCs that will be chosen.

STEP 2: Assess the needs of Stakeholders

We must study the business domain, user requirements, business priorities, and technology
constraints to be able to choose the right SDLC against their selection criteria.

STEP 3: Define the criteria

Some of the selection criteria or questions that you may use to select an SDLC are:

 Is the SDLC appropriate for the size of our team and their skills?
 Is the SDLC appropriate with the selected technology we use for implementing the
solution?
 Is the SDLC appropriate with client and stakeholders need and priorities
 Is the SDLC appropriate for the geographical situation (co-located or geographically
dispersed)?
 Is the SDLC appropriate for the size and complexity of our software?
 Is the SDLC appropriate for the type of projects we dos?
 Is the SDLC appropriate for our engineering capability?

Section-C
Ques.7 What is a DFD? Discuss various levels of DFD. Explain with the help of
some examples.
Ans. A data flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system, modelling its process aspects. A DFD is often used as a preliminary
step to create an overview of the system without going into great detail, which can later be
elaborated. DFDs can also be used for the visualization of data processing (structured
design).
A DFD shows what kind of information will be input to and output from the system, how the
data will advance through the system, and where the data will be stored. It does not show
information about the timing of process or information about whether processes will operate
in sequence or in parallel unlike a flowchart which also shows this information.

Types of DFD
Data Flow Diagrams are either Logical or Physical.

 Logical DFD - This type of DFD concentrates on the system process, and flow of
data in the system. For example, in a Banking software system, how data is moved
between different entities.
PTU Software Engineering Paper May 2013

 Physical DFD - This type of DFD shows how the data flow is actually implemented
in the system. It is more specific and close to the implementation.

DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components -

 Entities - Entities are source and destination of information data. Entities are
represented by a rectangle with their respective names.
 Process - Activities and action taken on the data are represented by Circle or Round-
edged rectangles.
 Data Storage - There are two variants of data storage - it can either be represented as
a rectangle with absence of both smaller sides or as an open-sided rectangle with only
one side missing.
 Data Flow - Movement of data is shown by pointed arrows. Data movement is shown
from the base of arrow as its source towards head of the arrow as destination.

Levels of DFD

 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the
entire information system as one diagram concealing all the underlying details. Level
0 DFDs are also known as context level DFDs.

 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1
DFD depicts basic modules in the system and flow of data among various modules.
Level 1 DFD also mentions basic processes and sources of information.
PTU Software Engineering Paper May 2013

 Level 2 - At this level, DFD shows how data flows inside the modules mentioned in
Level 1.

Higher level DFDs can be transformed into more specific lower level DFDs with
deeper level of understanding unless the desired level of specification is achieved.

Data Flow Diagram: Example

The Food Order System Data Flow Diagram example contains three processes, four external
entities and two data stores.
PTU Software Engineering Paper May 2013

Oues.8 What is the need for software maintenance? How are these maintained
for client server architecture environment?

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.
PTU Software Engineering Paper May 2013

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

Ques.9 Explain the followings:

a. Use-Case diagrams.
b. Software metrics.
c. Data Dictionary.
d. Feasibility Study.
Ans.

A. Use-Case diagrams:

Use case diagrams are considered for high level requirement analysis of a system. So when
the requirements of a system are analyzed the functionalities are captured in use cases.
PTU Software Engineering Paper May 2013

So we can say that use cases are nothing but the system functionalities written in an
organized manner. Now the second things which are relevant to the use cases are the actors.
Actors can be defined as something that interacts with the system.

The actors can be human user, some internal applications or may be some external
applications. So in a brief when we are planning to draw an use case diagram we should
have the following items identified.

 Functionalities to be represented as an use case

 Actors

 Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient
use case diagram.

 The name of a use case is very important. So the name should be chosen in such a
way so that it can identify the functionalities performed.

 Give a suitable name for actors.

 Show relationships and dependencies clearly in the diagram.

 Do not try to include all types of relationships. Because the main purpose of the
diagram is to identify requirements.

 Use note when ever required to clarify some important points.

The following is a sample use case diagram representing the order management system. So
if we look into the diagram then we will find three use cases (Order, SpecialOrder and
NormalOrder) and one actor which is customer.

The SpecialOrder and NormalOrder use cases are extended from Order use case. So they
have extends relationship. Another important point is to identify the system boundary which
is shown in the picture. The actor Customer lies outside the system as it is an external user
of the system.
PTU Software Engineering Paper May 2013

B. Software metrics:

A software metric is a standard of measure of a degree to which a software system or

process possesses some property. Even if a metric is not a measurement (metrics are
functions, while measurements are the numbers obtained by the application of metrics), often
the two terms are used as synonyms. Since quantitative measurements are essential in all
sciences, there is a continuous effort by computer science practitioners and theoreticians to
bring similar approaches to software development. The goal is obtaining objective,
reproducible and quantifiable measurements, which may have numerous valuable
applications in schedule and budget planning, cost estimation, quality assurance testing,
software debugging, software performance optimization, and optimal personnel task
assignments.

C. Data Dictionary:

Data dictionary is the centralized collection of information about data. It stores meaning and
origin of data, its relationship with other data, data format for usage etc. Data dictionary has
rigorous definitions of all names in order to facilitate user and software designers.

Data dictionary is often referenced as meta-data (data about data) repository. It is created
along with DFD (Data Flow Diagram) model of software program and is expected to be
updated whenever DFD is changed or updated.
PTU Software Engineering Paper May 2013

Requirement of Data Dictionary

The data is referenced via data dictionary while designing and implementing software. Data
dictionary removes any chances of ambiguity. It helps keeping work of programmers and
designers synchronized while using same object reference everywhere in the program.

Data dictionary provides a way of documentation for the complete database system in one
place. Validation of DFD is carried out using data dictionary.

Contents
Data dictionary should contain information about the following

 Data Flow
 Data Structure
 Data Elements
 Data Stores
 Data Processing
Data Flow is described by means of DFDs as studied earlier and represented in algebraic
form as described.

= Composed of

{} Repetition

() Optional

+ And

[/] Or

Example
Address = House No + (Street / Area) + City + State

Course ID = Course Number + Course Name + Course Level + Course Grades

Data Elements
Data elements consist of Name and descriptions of Data and Control Items, Internal or
External data stores etc. with the following details:

 Primary Name
 PTU Software Engineering Paper May 2013

 Secondary Name (Alias)

 Use-case (How and where to use)
 Content Description (Notation etc. )
 Supplementary Information (preset values, constraints etc.)
Data Store
It stores the information from where the data enters into the system and exists out of the
system. The Data Store may include -

 Files
o Internal to software.
o External to software but on the same machine.
o External to software and system, located on different machine.
 Tables
o Naming convention
o Indexing property
Data Processing
There are two types of Data Processing:

 Logical: As user sees it

 Physical: As software sees it

D. Feasibility Study:

Feasibility is defined as the practical extent to which a project can be performed

successfully. To evaluate feasibility, a feasibility study is performed, which determines
whether the solution considered to accomplish the requirements is practical and workable in
the software. Information such as resource availability, cost estimation for software
development, benefits of the software to the organization after it is developed and cost to be
incurred on its maintenance are considered during the feasibility study. The objective of the
feasibility study is to establish the reasons for developing the software that is acceptable to
users, adaptable to change and conformable to established standards. Various other objectives
of feasibility study are listed below:

 To analyze whether the software will meet organizational requirements

 To determine whether the software can be implemented using the current technology and
within the specified budget and schedule
 PTU Software Engineering Paper May 2013

 To determine whether the software can be integrated with other existing software.