What is a DFD ? Draw DFDs up to 3 rd level for a ‘‘Railway Reservation System’’.

Make
necessary assumptions.

It is a graphical representation of flow of data through a system. It pictures a system as a

network of functional processes. The basis of DFD is a data flow graph, which pictorially
represents transformation on data
the external entities provide input data for the processing. During the processing, some
intermediate data is generated. After final processing, the final output data is generated.
The data store is the repository of data. The structured approach of system design requires
extensive modeling of the system. Thus, instead of making a complete model exhibiting the
functionality of system, the DFD‟s are created in a layered manner. At the first layer, the
DFD is made at block level and in lower layers, the details are shown. Thus, level “0” DFD
makes a fundamental system

DFD‟s can represent the system at any level of abstraction. DFD of “0” level views entire
software element as a single bubble with indication of only input and output data. Thus, “0”
level DFD is also called as Context diagram. Its symbols are shown in
What is a Data Dictionary ? Explain with an example.
This is another tool of requirement analysis which reduces complexity of DFD. A data
dictionary is a catalog of all elements of a system. DFD depicts flow of data whereas data
dictionary gives details of that information like attribute, type of attribute, size, names of
related data items, range of values, data structure definitions etc. The name specifies the
name of attribute whose value is collected. For example, fee deposit may be named as FD
and course opted may be named as CO.
Related data items captures details of related attributes. Range of values store total
possible values of that data. Data structure definition captures the physical structure of data
items.
Some of the symbols used in data dictionary are given below:
X= [a/b] x consists of either data element a or b
X=a x consists of an optional data element a
X=a+b x consists of data element a & b
X=y{a}z x consists of some occurrences of data elements a which are between y and z.
| Separator
** Comments
@ Identifier
( ) Options

Uses of Data Dictionary :

Used for creating the ordered list of data items
Used for creating the ordered list of a subset of the data items
Used for Designing and testing software in Software Engineering
Used for finding data items from a description in Software Engineering
Example 2: The data dictionary of payroll may include the following fields:
PAYROLL = [Payroll Details]
= @ employee name + employee + id number + employee address + Basic Salary +
additional allowances
Employee name = * name of employee *
Employee id number = * Unique identification no. given to every employee*
Basic Salary = * Basic pay of employee *
Additional allowances = * The other perks on Basic pay *
Employee name = First name + Last name Employee address = Address 1 + Address 2 +
Address 3

Explain Cleanroom Software Engineering with the help of a diagram.

Clean room software engineering is a software development approach to producing quality
software. It is different from classical software engineering as in classical software
engineering QA (Quality Assurance) is the last phase of development that occurs at the
completion of all development stages while there is a chance of less reliable and fewer
quality products full of bugs, and errors and upset client, etc. But in clean room software
engineering, an efficient and good quality software product is delivered to the client as QA
(Quality Assurance) is performed each and every phase of software development.
The cleanroom software engineering follows a quality approach to software development
which follows a set of principles and practices for gathering requirements, designing, coding,
testing, managing, etc. which not only improves the quality of the product but also increases
productivity and reduces development cost. From the beginning of the system development
to the completion of system development it emphasizes removing the dependency on the
costly processes and preventing defects during development rather than removing the
defects.
The clean room approach was developed by Dr. Harlan Mills of IBM’s Federal Systems
Division, and it was released in the year 1981 but got popularity after 1987 when IBM and
other organizations started using it.

Processes of Cleanroom development :

Clean room software development approaches consist of four key processes i.e.
Management –
It is persistent throughout the whole project lifetime which consists of project mission,
schedule, resources, risk analysis, training, configuration management, etc.
Specification –
It is considered the first process of each increment which consists of requirement analysis,
function specification, usage specification, increment planning, etc.
Development –
It is considered the second process of each increment which consists of software
reengineering, correctness verification, incremental design, etc.

Certification –
It is considered the final process of each increment which consists of usage modeling and
test planning, statistical training and certification process, etc.
While separate teams are allocated for different processes to ensure the development of
the highest quality software product.

Some of the tasks which occur in clean room engineering process:

Requirements gathering.
Incremental planning.
Formal design.
Correctness verification.
Code generation and inspection.
Statical test planning.
Statistical use testing.
Certification.
Explain any two Project Scheduling techniques with examples.

Simulation
The expected duration of the project is calculated by using a different set of tasks in
simulation. The schedule is created on the basis of assumptions, so it can be used even if the
scope is changed or the tasks are not clear enough.

Resource-Levelling Heuristics
Cutting the delivery time or avoiding under or overutilization of resources by making
adjustments with the schedule or resources is called resource leveling heuristics. Dividing
the tasks as per the available resources, so that no resource is under or over-utilized. The
only demerit of this methodology is it may increase the project’s cost and time.
Task List
The task list is the simplest project scheduling technique of all the techniques available.
Documented in a spreadsheet or word processor is the list of all possible tasks involved in a
project. This method is simple and the most popular of all methods. It is very useful while
implementing small projects. But for large projects with numerous aspects to consider task
list is not a feasible method.

Gantt chart
For tracking progress and reporting purposes, the Gantt Chart is a visualization technique
used in project management. It is used by project managers most of the time to get an idea
about the average time needed to finish a project. A project schedule Gantt chart is a bar
chart that represents key activities in sequence on the left vs time. Each task is represented
by a bar that reflects the start and date of the activity, and therefore its duration.

Calendar
Many don’t consider scheduling tasks on a calendar for their project requirements – when
they should! Most of the calendars can be curated with names of their own. In this case, you
can create one calendar per project and scheduled events for that project. The calendar
shows a timeline for the entire project. The major advantage is that it can be subjected to
change as it is shareable. While it seems to be a great technique for tracking a project, it
does have certain limitations you cannot assign tasks to certain people and you cannot see
task dependencies.

Write Examples on your own.

Explain Software Project estimation in detail with the help of a diagram.

Software project estimation is the process of estimating various resources required for the
completion of a project. Effective software project estimation is an important activity in any
software development project. Underestimating software project and under staffing it often
leads to low quality deliverables, and the project misses the target deadline leading to
customer dissatisfaction and loss of credibility to the company. On the other hand,
overstaffing a project without proper control will increase the cost of the project and reduce
the competitiveness of the company.
Software project estimation mainly encompasses the following steps:

 Estimating the size of project. There are many procedures available for estimating the size
of a project which are based on quantitative approaches like estimating Lines of Code or
estimating the functionality requirements of the project called Function point.

 Estimating efforts based on man-month or man-hour. Man-month is an estimate

of personal resources required for the project.

 Estimating schedule in calendar days/month/year based on total man-month

required and manpower allocated to the project Duration in calendar month = Total man-
months / Total manpower allocated.

 Estimating total cost of the project depending on the above and other
resources. In a commercial and competitive environment, Software project
estimation is crucial for managerial decision making.

The following Table give the relationship between various management functions
and software metrics/indicators. Project estimation and tracking help to plan and predict
future projects and provide baseline support for project management and supports decision
making.

Activity Tasks involved

Planning ---Cost estimation, planning for training of manpower, project scheduling and
budgeting the project

Controlling ---Size metrics and schedule metrics help the manager to keep control of the
project during execution

Monitoring/improving---- Metrics are used to monitor progress of the project and wherever
possible sufficient resources are allocated to improve.
Explain different techniques for Requirements Gathering.
The requirements gathering is an art. The person who gathers requirements should
have knowledge of what and when to gather information and by what resources. The
requirements are gathered regarding organisation, which include information
regarding its policies, objectives, and organisation structure, regarding user staff. It
includes the information regarding job function and their personal details, regarding
the functions of the organisation including information about work flow, work
schedules and working procedure.

The following four tools are primarily used for information gathering:

1. Record review: A review of recorded documents of the organisation is

performed. Procedures, manuals, forms and books are reviewed to see format and
functions of present system. The search time in this technique is more.

2. On site observation: In case of real life systems, the actual site visit is performed
to get a close look of system. It helps the analyst to detect the problems of existing
system.

3. Interview: A personal interaction with staff is performed to identify their

requirements. It requires experience of arranging the interview, setting the stage,
avoiding arguments and evaluating the outcome.

4. Questionnaire: It is an effective tool which requires less effort and produces a

written document about requirements. It examines a large number of respondents
simultaneously and gets customized answers. It gives person sufficient time to
answer the queries and give correct answers.

Explain the process of developing wireless application using J2ME.

Java supports mobile application development using its J2ME. J2ME stands for Java 2
Platform, Micro Edition. J2ME provides an environment under which application
development can be done for mobile phone, personal digital assistants and other
embedded devices. As like any other Java platform, J2ME includes API’s
(Application Programming Interface) and Java Virtual Machines. It includes a range
of user interfaces, provides security and supports a large number of network protocols.
J2ME also supports the concept of write once, run any where concept. Initially, an
application can be developed using J2ME targeting a specific type of devices. Then,
the same application can be used for different types of devices. Also, it is possible to
use the native capabilities of these devices. J2ME is one of the popular platforms that
is being used across the world for a number of mobile devices, embedded devices etc.

The following are different steps in the process of connecting MIDlet to a servlet:
 Start Ktoolbar. This is part of J2ME wireless toolkit.
 Open the project1.
 Write the code for the MIDlet (let it be countmidlet.java) that connects to
counter servlet.
 The screen of countmidlet.java (after executing it) consists of two commands
namely Exit and Connect. Clicking on Connect will lead to the invocation of
connect( ) method that will establish a network connection. It will also transport
the result.
 The countmidlet.java should be saved to apps/project1/src directory under
J2ME wireless toolkit directory.
 Now, J2ME wireless toolkit should know that a new MIDlet is added to it. This
can be done by going to Settings MIDletsAdd. Enter countmidlet for both
the MIDlet name and class name. Click on OK.
 Go to Settings User Defined. Add the property name as countmidlet.URL.
This URL will invoke counter servlet.

‘‘Spiral Model combines the strength of various other Software Development models.’’
Justify the statement. Also explain the primary activities in this model. For what kind of
projects can we use this model ?

This model can be considered as the model, which combines the strengths of various other
models. Conventional software development processes do not take uncertainties into
account. Important software projects have failed because of unforeseen risks. The other
models view the software process as a linear activity whereas this model considers it as a
spiral process. This is made by representing the iterative development cycle as an expanding
spiral.
The following are the primary activities in this model:
 Finalising Objective: The objectives are set for the particular phase of the project.
 Risk Analysis: The risks are identified to the extent possible. They are analysed and
necessary steps are taken.
 Development: Based on the risks that are identified, an SDLC model is selected and is
followed.
 Planning: At this point, the work done till this time is reviewed. Based on the review, a
decision regarding whether to go through the loop of spiral again or not will be decided. If
there is need to go, then planning is done accordingly.
Phase
Activities performed Deliverables / Output
Name

Planning -Requirements are studied and gathered. Requirements understanding document

- Feasibility study
- Reviews and walkthroughs to streamline the Finalized list of requirements.
requirements

Risk Requirements are studied and brain storming sessions are Document which highlights all the risks
Analysis done to identify the potential risks and its mitigation plans.

Once the risks are identified , risk mitigation strategy is

planned and finalized

Engineering Actual development and testing if the software takes place Code
in this phase Test cases and test results
Test summary report and defect report.

Evaluation Customers evaluate the software and provide their Features implemented document
feedback and approval
The Spiral model is mainly used for large projects. It allows development teams to
include user feedback early on and create a highly customized product. Another
advantage of this SDLC model is how it handles risk management. Each iteration is
started after a serious analysis of potential risks and thinking through how to duck or
decrease them.
 

In a modular design, explain the functionality of Coupling and Cohesion. Write the
disadvantages of low cohesion and high coupling.

Cohesiveness measure functional relationship of elements in a module. An element

could be a instruction, a group of instructions, data definitions or reference to another
module.
Cohesion tells us how efficiently we have positioned our system to modules. It may be
noted that modules with good cohesion requires minimum coupling with other module
There are several types of cohesion arranged from bad to best.
 Coincidental : This is worst form of cohesion, where a module performs a number of
unrelated task.
 Logical : Modules perform series of action, but are selected by a calling module.
 Procedural : Modules perform a series of steps. The elements in the module must
takeup single control sequence and must be executed in a specific order.
 Communicational : All elements in the module is executed on the same data set
Software Design and produces same output data set.
 Sequential : Output from one element is input to some other element in the module.
Such modules operates on same data structure.
 Functional : Modules contain elements that perform exactly one function.
The following are the disadvantages of low cohesion:
 Difficult to maintain
 Tends to depend on other module to perform certain tasks
 Difficult to understand.

Coupling

In computer science, coupling is defined as degree to which a module interacts and

communicates with another module to perform certain task. If one module relies on
another the coupling is said to be high. Low level of coupling means a module doses not
have to get concerned with the internal details of another module and interact with another
module only with a suitable interface.

The types of coupling from best (lowest level of coupling) to worst (high level of coupling)
are described below:
 Data coupling: Modules interact through parameters. Module X passes parameter A to
module Y
 Stamp coupling: Modules shares composite data structure.
 Control coupling: One module control logic flow of another module. For example, passing
a flag to another module which determines the sequence of action to be performed in the
other module depending on the value of flag such as true or false.
 External coupling: Modules shares external data format. Mostly used in communication
protocols and device interfaces
 Common coupling: Modules shares the same global data.
 Content coupling: One module modifies the data of another module.

The following are the disadvantages of high coupling:

 Ripple effect.
 Difficult to reuse. Dependent modules must be included.
 Difficult to understand the function of a module in isolation.

With the help of a suitable example program, explain the ‘‘Boundary Value Analysis’’ testing
strategy by deriving boundary conditions

Test Case Selection Guidelines for Boundary Value Analysis

The following set of guidelines is for the selection of test cases according to the principles of
boundary value analysis. The guidelines do not constitute a firm set of rules for every case.
You will need to develop some judgement in applying these guidelines.
1. If an input condition specifies a range of values, then construct valid test cases for the
ends of the range, and invalid input test cases for input points just beyond the ends of the
range.
 2. If an input condition specifies a number of values, construct test cases for the minimum
and maximum values; and one beneath and beyond these values.
3. If an output condition specifies a range of values, then construct valid test cases for the
ends of the output range, and invalid input test cases for situations just beyond the ends of
the output range.
4. If an output condition specifies a number of values, construct test cases for the minimum
and maximum values; and one beneath and beyond these values.
5. If the input or output of a program is an ordered set (e.g., a sequential file, linear list,
table), focus attention on the first and last elements of the set.

Example 1: Boundary Value Analysis for the Triangle Program Consider a simple program to
classify a triangle. Its input consists of three positive integers (say x, y, z) and the data types
for input parameters ensures that these will be integers greater than zero and less than or
equal to 100. The three values are interpreted as representing the lengths of the sides of a
triangle. The program then prints a message to the standard output that states whether the
triangle, if it can be formed, is scalene, isosceles, equilateral, or right-angled.
Solution: Following possible boundary conditions are formed:
1. Given sides (A; B; C) for a scalene triangle, the sum of any two sides is greater than the
third and so, we have boundary conditions A + B > C, B + C > A and A + C > B.
2. Given sides (A; B; C) for an isosceles triangle two sides must be equal and so we have
boundary conditions A = B, B = C or A = C.
3. Continuing in the same way for an equilateral triangle the sides must all be of equal
length and we have only one boundary where A = B = C.
4. For right-angled triangles, we must have A 2+B2 = C 2

Construct DFDs up to level 3 for a ‘‘Hospital Management System’’. Make necessary

assumptions.
Explain the Software Change Request format, Engineering Change Order format and
Software Change Report format.

Software Change Request Format

1.0 Change request Identification
1.1 Name, identification and description of software configuration item(s):
The name, version numbers of the software configuration is provided. Also, a
brief description of the configuration item is provided.
1.2 Requester and contact details: The name of the person requesting the change
and contact details
1.3 Date, location, and time when the change is requested
2.0 Description of the change
2.1 Description : This section specifies a detailed description of the change
request.
2.1.1 Background Information, Background information of the request.
2.1.2 Examples: Supporting information, examples, error report, and screen
shoots
2.1.3 The change : A detailed discussion of the change requested.
2.2 Justification for the change : Detailed justification for the request.
2.3 Priority : The priority of the change depending on critical effect on system
Functionalities
Software Change Report Format
1.0 Change report Identification
1.1 Name, identification and description of software configuration item(s): The
name, version numbers of the software configuration item and a brief
description of it.
1.2 Requester: The name and contact details of the person requesting the change.
1.3 Evaluator : The name of the person or team who evaluated the change request.
1.4 Date and time : When change report was generated.
2.0 Overview of changes required to accommodate request
2.1 Description of software configuration item that will be affected
2.2 Change categorization : Type of change, in a generic sense
2.3 Scope of the change : The evaluator's assessment of the change.
2.3.1 Technical work required including tools required etc. A description of
the work required to accomplish the change including required tools
or other special resources are specified here
2.3.2 Technical risks : The risks associated with making the change are
described.
3.0 Cost Assessment : Cost assessment of the requested change including an
estimate of time required.
4.0 Recommendation
4.1 Evaluator’s recommendation : This section presents the evaluator's
recommendation regarding the change
4.2 Internal priority: How important is this change in the light of the business
operation and priority assigned by the evaluator.

Engineering Change Order Format

1.0 Change order Identification
1.1 Name, identification and description of software configuration item(s) : The name,
version numbers including a brief description of software configuration items is provided.
1.2 Name of Requester
1.3 Name of Evaluator
2.0 Description of the change to be made
2.1 Description of software configuration(s) that is affected
2.2 Scope of the change required The evaluator's assessment of scope of the change in the
configuration item(s).
2.2.1 Technical work and tools required : A description of the work and tools required to
accomplish the change.
2.3 Technical risks: The risks associated with making the change are described in this
section.
3.0 Testing and Validation requirements A description of the testing and review approach
required to ensure that the change has been made without any undesirable side effects.
3.1 Review plan : Description of reviews that will be conducted.
3.2 Test plan