(w13)

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
WINTER – 13 EXAMINATION
Subject Code: 12175 Model: Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Important Instructions to examiners:
1) The answers should be examined by key words and not as word-to-word as given in the model answer
scheme.
2) The model answer and the answer written by candidate may vary but the examiner may try to assess
the understanding level of the candidate.
3) The language errors such as grammatical, spelling errors should not be given more Importance (Not
applicable for subject English and Communication Skills).
4) While assessing figures, examiner may give credit for principal components indicated in the figure.
The figures drawn by candidate and model answer may vary. The examiner may give credit for any
equivalent figure drawn.
5) Credits may be given step wise for numerical problems. In some cases, the assumed constant values
may vary and there may be some difference in the candidate’s answers and model answer.
6) In case of some questions credit may be given by judgement on part of examiner of relevant answer
based on candidate’s understanding.
7) For programming language papers, credit may be given to any other program based on equivalent
concept.
1. a) Attempt any three of the following: Marks 12

i) Describe changing nature of software.
(For each type- ½ Mark, for its explanation- ½ mark, any 4(four))
Ans:
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software (e.g., inventory control, word processing, multimedia)
• Web applications
• Artificial intelligence software
• Ubiquitous computing (small, wireless devices)
• Netsourcing (net-wide computing)
• Open source (operating systems, databases, development environments)
• The ".com" marketing applications
Page 1 of 38
(Autonomous)
____________________________________________________________________________________________________
ii) Differentiate between validation and verification.

(Any four (4) points - 1 Mark each)
Ans:
Sr.
VERIFICATION VALIDATION
No.
Verification is a static practice of
1 Validation is a dynamic mechanism of
verifying documents, design, code and
validating and testing the actual product.
program.
2
It does not involve executing the code. It always involves executing the code.
3 It is human based checking of documents
It is computer based execution of program.
and files.
Verification uses methods like Validation uses methods like black box
4
inspections, reviews, walkthroughs, and (functional) testing, gray box testing, and
Desk-checking etc. white box (structural) testing etc.
Validation is to check whether software
5 Verification is to check whether the
meets the customer expectations and
software conforms to specifications.
requirements.
6 It can catch errors that validation cannot It can catch errors that verification cannot
catch. It is low level exercise. catch. It is High Level Exercise.
Target is requirements specification,
Target is actual product-a unit, a module, a
7 application and software architecture, high
bent of integrated modules, and effective
level, complete design, and database
final product.
design etc.
Verification is done by development team
8 Validation is carried out with the
to provide that the software is as per the
involvement of client and testing team.
specifications in the SRS document.
9 It, generally, comes first-done before
It generally follows after verification.
validation.
10 Question Question
Are we building the product right? Are we building the right product?
Evaluation Items
11 Evaluation Items
Plans, Requirement Specs, Design Specs,
The actual product/software.
Code, Test Cases
Activities
Activities
12 Reviews
Testing
Walkthroughs
Inspections
Page 2 of 38
(Autonomous)
____________________________________________________________________________________________________
iii) What is project scheduling and tracking?

(For each point - 1 Mark)
Ans: It is creating a network of software engineering tasks like:
1. Selecting an appropriate process model
2. Estimate the amount of work and number of people required
3. Know the deadline.
4. Consider the risks.
That will enable to get the job done on time. Software project scheduling is an activity that
distributes estimated effort across the planned project duration by allocating the effort to
specific software engineering tasks.
1. To understand the interdependency between the software engineering tasks which are
running in parallel for building a complex system
2. To asses a progress on moderator large software project.
iv) State benefits of ISO standards.

(For each point -1 Mark, any 4(four) points)
Ans: ISO 9001 is for quality management.
• Quality refers to all those features of a product (or service) which are required by the
customer.
• Quality management means what the organization does to
– ensure that its products or services satisfy the customer's quality requirements and
– Comply with any regulations applicable to those products or services.
• Quality management also means what the organization does to
– enhance customer satisfaction, and
– achieve continual improvement of its performance
• Quality assurance systems are created to help organizations ensure their products and services
satisfy customer expectations by meeting their specifications.
Page 3 of 38
(Autonomous)
____________________________________________________________________________________________________
b) Attempt any one of the following: Marks 06

i) Describe level-O-DFD with suitable example.
(Description -3 Marks, Example - 3 Marks)
Ans: DFD is refined into greater levels of detail; the analyst performs an implicit functional
decomposition of the system, thereby accomplishing the fourth operational analysis principle
for function.
At the same time, the DFD refinement results in a corresponding refinement of data
(1) The level 0 data flow diagram should depict the software/system as a single bubble;
(2) Primary input and output should be carefully noted;
(3) Refinement should begin by isolating candidate processes, data objects, and stores to be
represented at the next level;
(4) All arrows and bubbles should be labeled with meaningful names;
(5) Information flow continuity must be maintained from level to level, and
(6) One bubble at a time should be refined.
Considering the SafeHome product, a level 0 DFD for the system is shown in Figure. The
primary external entities (boxes) produce information for use by the system and consume
information generated by the system. The labeled arrows represent data objects or data object
type hierarchies. For example, user commands and data encompasses all configuration
commands, all activation/deactivation commands, all miscellaneous interactions, and all data
that are entered to qualify or expand a command.
Page 4 of 38
(Autonomous)
____________________________________________________________________________________________________
ii) State design modeling principles.

(Any 6 Design Modeling Principles are expected with description - 1 Mark each)
Ans: Following are various Design Modeling Principles
Principle #1:- Design should be traceable to an analysis model
The analysis mode describes the information domain of the problem, user visible functions and
various things about system. The design model translates this information into architecture: a
set of sub systems that implement major functions, and a set of component level designs
that are the realization of analysis classes.
Principle #2: - Always consider the architecture of the system to be built
Software architecture is a skeleton of the system to be built. It affects interfaces, data structures,
program control flow and behavior, the manner in which testing can be conducted, the
maintainability of the resultant system and much more.
Principle #3: - Design of data is as important as design of processing functions
Data design is an essential element of architectural design. The manner in which data objects are
realized within the design cannot be left to chance. A well structured data design helps to
simplify program flow, makes the design and implementation of software components easier,
an d makes overall processing more efficient.
Page 5 of 38
(Autonomous)
____________________________________________________________________________________________________
Principle #4: - Interfaces must be designed with care
The manner in which data flows between the components of a system has much to do with
processing efficiency, error propagation, and design simplicity. A well designed interface makes
integration easier and assists the tester in validating component functions.
Principle #5: - User interface design should be tuned to the needs of the end-user
In every case it should stress ease of user. The user interface is the visible manifestation of the
software. No matter how sophisticated its internal functions, no matter how comprehensive its data
structures, no matter how well designed its architecture, a poor interface design often le ads to
the perception that the software is bad.
Principle #6: - Component level design should be functionally independent.
Functional independence is a measure of the ―single mindedness‖ of a software component. The
functionality that is delivered by a component should be cohesive – that is it should focus on one
and only one function or sub -function.
Principle #7: - Component should be loosely coupled to one another and to the external
environment.
Coupling is achieved in many ways – via a component interface, by messaging, through global
data. As the level of coupling increases, the likelihood or error propagation also increases
and the overall maintainability of the software decreases.
Principle #8: - Design representation should be easily understandable
The purpose of design is to communicate information to practitioners who will generate
code, to those who will test the software, and to others who may maintain the software in
the future. If the design is difficult to understand, it will not serve as an effective communication
medium.
Principle #9 The design should be developed iteratively. With each iteration the designer
should strive for greater simplicity.
Like almost all creative activities, design occurs iteratively. The first iterations works to refine the
design and correct errors, but later iterations should strive to make the design as simple as possible.
Page 6 of 38
(Autonomous)
____________________________________________________________________________________________________
2. Attempt any four of the following: Marks 16

a) Explain data objects and data attributes with suitable example.
Ans: i) Data objects.
(Definition - 1 Mark, Example - 1 Mark)
A data object is a representation of almost any composite information that must be understood by
software. By composite information, we mean something that has a number of different
properties or attributes. Therefore, width (a single value) would not be a valid data object, but
dimensions (incorporating height, width, and depth) could be defined as an object.
A data object can be an external entity (e.g., anything that produces or consumes information), a
thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a
role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a
warehouse), or a structure (e.g., a file).
For example, a person or a car (Figure 12.2) can be viewed as a data object in the sense that either
can be defined in terms of a set of attributes. The data object description incorporates the data
object and all of its attributes.
In this case, a car is defined in terms of make, model, ID numbe r, body type, color and owner.
The body of the table represents specific instances of the data object.
Object: Customer
ii) Data attribute

(Definition - 1 Mark, Example - 1 Mark)
Attributes: Attributes define the properties of a data object and take on one of three different
characteristics.
They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make
reference to another instance in another table. In addition, one or more of the attributes
must be defined as an identifier—that is, the identifier attribute becomes a "key" when we
want to find an instance of the data object. In some cases, values for the identifier(s) are
unique, although this is not a requirement. Referring to the data object car, a reasonable identifier
might be the ID number.
The set of attributes that is appropriate for a given data object is determined through an
understanding of the problem context. The attributes for car might serve well for an
application that would be used by a Department of Motor Vehicles, but these attributes would
be useless for an automobile company that needs manufacturing control software.
Page 7 of 38
(Autonomous)
____________________________________________________________________________________________________
Attributes:
name
company name
status of contact
b) Describe white-box testing.

(Any four points each carry -1 Mark)
Ans: White-box testing, sometimes called glass-box testing orcode testing, is a test case design method
that uses the control structure of the procedural design to derive test cases.
Using white-box testing methods, the software engineer can derive test cases that
1. Guarantee that all independent paths withina module have been exercised at least once.
2. Exercise all logical decisions on their true and false sides,
3. Execute all loops at their boundaries and within their operational bounds, and
4. Exercise internal data structures to ensure their validity.
Even though white box testing seems to be an ideal method for testing, it does not guarantee
failures from faulty data. Secondly it is difficult to conduct such extensive and exhaustive testing
in large organizations.
c) Explain six sigma strategy.

(For DMA - 2 Marks, For DV or IC - 2 Marks)
Ans: DMAIC
The DMAIC project methodology has five phases:
Define the system, the voice of the customer and their requirements, and the project goals,
specifically.
Measure key aspects of the current process and collect relevant data.
Analyze the data to investigate and verify cause-and-effect relationships. Determine what the
relationships are, and attempt to ensure that all factors have been considered. Seek out root cause
of the defect under investigation.
Improve or optimize the current process based upon data analysis using techniques such as design
of experiments, poka yoke or mistake proofing, and standard work to create a new, future state
process. Set up pilot runs to establish process capability.
Page 8 of 38
(Autonomous)
____________________________________________________________________________________________________
Control the future state process to ensure that any deviations from target are corrected before they
result in defects. Implement control systems such as statistical process control, production boards,
visual workplaces, and continuously monitor the process.
Some organizations add a Recognize step at the beginning, which is to recognize the right problem
to work on, thus yielding an RDMAIC methodology.
OR
DMADV or DFSS
The DMADV project methodology, known as DFSS ("Design For Six Sigma"), features five
phases:
Define design goals that are consistent with customer demands and the enterprise strategy.
Measure and identify CTQs (characteristics that are Critical To Quality), product capabilities,
production process capability, and risks.
Analyze to develop and design alternatives
Design an improved alternative, best suited per analysis in the previous step
Verify the design, set up pilot runs, implement the production process and hand it over to the
process owner(s)
d) Describe waterfall model with the help of neat diagram.

(Diagram – 2 Marks, Explanation - 2 Marks)
(Note: 2nd figure must be consider with its relevant explanation)
Ans:
OR
Page 9 of 38
(Autonomous)
____________________________________________________________________________________________________
Also know as classic life cycle or waterfall model

The LSM suggests a systematic, sequential approach to software development that begins at the
system level and progresses through analysis, design, coding, testing, and support.
System/information Engineering and Modeling :-◦
o Encompasses requirement gathering at system level with a small amount of top level design
and analysis.
o Information engineering encompasses requirement gathering at the strategic business level
and at the business area level.
Software Requirement Analysis :-
o Requirement gathering process is intensified and focused on software.
o Analyst must understand the information domain for the software as well as required
function, behavior, performance and interface.
o Requirements must be documented and reviewed with the customer.
Design
o Multistep process focuses on four distinct attributes of a program:
Data structure
Software architecture
Interface representation
Procedural (algorithmic) detail
o Design process translates requirements into representation of the software
Page 10 of 38
(Autonomous)
____________________________________________________________________________________________________
Code Generation
o Design is translated into machine readable form.
Testing
o Focuses on the logical internals of the software ensuring that all the statements have been
tested.
o Focuses on functional externals that is conducting test to uncover errors and to ensure that
defined input will produce actual agreed result.
Support
o Accommodate changes.
o Change is encountered because:
Error Encountered
Accommodate external environment (New OS or Peripheral devices)
Enhance performance/functional enhancements.
e) Explain seven major task of requirement engineering.

(For Each Task - ½ Mark)
Ans: Requirements engineering tasks
1. Inception: -
Inception means beginning. It is usually said that requirement engineering is a communication
intensive activity. The customer and developer meet and they decide the overall scope and nature
of the problem statements. By having proper inception phase the developer will have clear
idea about the system and as a result of that better understanding of a system can be achieved.
Once the system is clear to the developer they can implement a system with better efficiency.
2. Elicitation: -
Elicitation task will help the customer to define the actual requirement of a system. To know the
objectives of the system or the project to be developed is a critical job. This phase will help
people to determine the goal of a system and clear idea about the system can be achieved.
3. Elaboration:-
The information obtained from the customer during inception and elicitation is expanded
and refined during elaboration. This requirement engineering activity focuses on developing a
refined technical model of software functions, features and constraints.
Page 11 of 38
(Autonomous)
____________________________________________________________________________________________________
4. Negotiation: -
This phase will involve the negotiation between what user actual expects from the system and
what is actual feasible for the developer to build. Often it is seen that user always expect lot of
things from the system for lesser cost. But based of the other aspect and feasibility of a
system the customer and developer can negotiate on the few key aspect of the system and
then they can proceed towards the implementation of a system
5. Specification
A specification can be a re-written document, a set of graphical models, a formal mathematical
model, a collection of usage scenario, a prototype, or any combinations of these. The
specification is the final work product produced by the requirement engineers. It serves as
the foundation for subsequent software engineering activities. It describes the function and
performance of a computer based system and the constraints that will govern its development.
6. Validation
The work products produced as a consequence of requirements engineering are assessed for
quality during a validation step. Requirements validation examines the specification to
ensure that all software requirements have been stated unambiguously; that inconsistencies,
omissions and errors have been detected and corrected, and that the work products
conform to the standards established for the process, the project, and the product.
7. Requirements management
Requirement management begins with identification. Each requirement is assigned a unique
identifier. Once requirement have been identified, traceability tables are developed.
f) Explain characteristics of software testing.

(For each point – 1 Mark, any four(4))
Ans: To perform effective testing, a software team should conduct effective formal technical
reviews. By doing this many errors will be eliminated before testing commences.
Testing begins at the component level and works outwards towards the integration of the
entire computer based system.
Different testing techniques are appropriate at different points in time.
Testing is conducted by the developer of the software and an independent test group.
Page 12 of 38
(Autonomous)
____________________________________________________________________________________________________
Testing and Debugging are different activities, but debugging must be accommodated in
any testing strategy.
OR
Testability:
– Software testability is simply how easily [a computer program] can be tested.
Operability
– "The better it works, the more efficiently it can be tested."
– The system has few bugs (bugs add analysis and reporting overhead to the test process).
– No bugs block the execution of tests.
– The product evolves in functional stages (allows simultaneous development and testing)
Observability
– "What you see is what you test."
– Distinct output is generated for each input.
– System states and variables are visible or queriable during execution.
– Past system states and variables are visible or queriable (e.g., transaction logs).
– All factors affecting the output are visible.
– Incorrect output is easily identiifed.
– Internal errors are automatically detected through self-testing mechanisms.
– Internal errors are automatically reported.
– Source code is accessible
Simplicity
– "The less there is to test, the more quickly we can test it."
– Functional simplicity (e.g., the feature set is the minimum necessary to meet requirements)
– Structural simplicity (e.g., architecture is modularized to limit the propagation of faults).
– Code simplicity (e.g., a coding standard is adopted for ease of inspection and maintenance)
Stability
– "The fewer the changes, the fewer the disruptions to testing."
– Changes to the software are infrequent.
– Changes to the software are controlled.
– Changes to the software do not invalidate existing tests.
– The software recovers well from failures.
Page 13 of 38
(Autonomous)
____________________________________________________________________________________________________
Decomposability
– "By controlling the scope of testing, we can more quickly isolate the errors and conduct smart
testing.
– The software system is built from independent modules.
– Software modules can be tested independently
Understandability
– "The more information we have, the smarter we will test."
– The design is well understood.
– Dependencies between internal, external, and shared components are well understood.
– Changes to the design are communicated.
– Technical documentation is instantly accessible.
– Technical documentation is well organized.
– Technical documentation is speciﬁc and detailed.
– Technical documentation is accurate
Controllability
– "The better we can control the software, the more the testing can be optimized―
– All possible outputs can be generated through some combination of input.
– All code is executable through some combination of input.
– Software and hardware states and variables can be controlled directly by the test engineer.
– Input and output formats are consistent and structured.
– Tests can be conveniently speciﬁed, automated, and reproduced
3. Attempt any four the following: Marks 16

a) What is reactive and proactive risk strategies?
Ans: Reactive risk strategies
(Reactive risk strategies: Explanation- 2 Marks)
1. Reactive risk strategies follows that the risks have to be tackled at the time of their
occurrence.
2. No precautions are to be taken as per this strategy.
3. They are meant for risks with relatively smaller impact.
Page 14 of 38
(Autonomous)
____________________________________________________________________________________________________
4. "Don't worry, I'll think of something".
5. The majority of software teams and managers rely on this approach.
6. Nothing is done about risks until something goes wrong.
7. The team then flies into action in an attempt to correct the problem rapidly (fire fighting
mode).
8. Crisis management is the choice of management techniques.
Proactive risk strategies

(Proactive risk strategies: Explanation - 2 Marks)
– Steps for risk management are followed:
1. Identify possible risks; recognize what can go wrong.
2. Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage)
that it will do if it does occur.
3. Rank the risks by probability and impact.
- Impact may be negligible, marginal, critical, and catastrophic.
4. Develop a contingency plan to manage those risks having high probability and high impact.
– Primary objective is to avoid risk and to have a contingency plan in place to handle
unavoidable risks in a controlled and effective manner.
b) Explain unit testing in detail.

(Explanation – 2 Marks and Diagram – 2 Marks)
Ans:
• Testing of individual software "units" (i.e., classes, routines).
• Usually done by the engineer who wrote the unit.
• The traditional approach is to write unit test cases after the code is written.
• Stub is the dummy sub-program attached to the main module to be tested.
• Stub is simple implementation of the module that is slower, less accurate, or somehow less
capable than the real module.
• Drivers invoke the module with fixed inputs.
• Driver compares actual outputs with expected outputs.
Page 15 of 38
(Autonomous)
____________________________________________________________________________________________________
OR
c) Define and explain clean-room approach.

(Definition – 1Mark, List of the strategy- 2 Marks, Explanation- 1 Mark)
Ans: Clean-room software engineering strategy is used in integrating all processes involved in crafting
high quality software.
It uses the strategy:
1. Increment Planning —adopts the incremental strategy
2. Requirements Gathering —defines a description of customer level requirements (for each
increment)
3. Box Structure Specification —describes the functional specification
4. Formal Design —specifications (called ―black boxes‖) are iteratively refined (with an
increment) to become analogous to architectural and procedural designs (called ―state boxes‖
and ―clear boxes,‖ respectively).
5. Correctness Verification —verification begins with the highest level box structure
(specification) and moves toward design detail and code using a set of ―correctness questions.‖
If these do not demonstrate that the specification is correct, more formal (mathematical)
methods for verification are used.
6. Code Generation, Inspection and Verification —the box structure specifications, represented in
a specialized language, are transmitted into the appropriate programming language.
7. Statistical Test Planning —a suite of test cases that exercise of ―probability distribution‖ of
usage are planned and designed
Page 16 of 38
(Autonomous)
____________________________________________________________________________________________________
8. Statistical Usage Testing —execute a series of tests derived from a statistical sample (the
probability distribution noted above) of all possible program executions by all users from a
targeted population
9. Certification —once verification, inspection and usage testing have been completed (and all
errors are corrected) the increment is certified as ready for integration.
(Note: Figure carry- 2 Marks if drawn else its optional)
d) Explain different principles of software project scheduling.

(Any four principles each carry – 1Mark)
Ans:
Compartmentalization
– The project must be compartmentalized into a number of manageable activities,
actions, and tasks; both the product and the process are decomposed.
Interdependency
– The interdependency of each compartmentalized activity, action, or task must be
determined.
– Some tasks must occur in sequence while others can occur in parallel.
Page 17 of 38
(Autonomous)
____________________________________________________________________________________________________
– Some actions or activities cannot commence until the work product produced by
another is available.
Time allocation
– Each task to be scheduled must be allocated some number of work units.
– In addition, each task must be assigned a start date and a completion date that are a
function of the interdependencies.
– Start and stop dates are also established based on whether work will be conducted on a
full-time or part-time basis.
Effort validation
– Every project has a defined number of people on the team.
– As time allocation occurs, the project manager must ensure that no more than the
allocated number of people have been scheduled at any given time.
Defined responsibilities
– Every task that is scheduled should be assigned to a specific team member.
Defined outcomes
– Every task that is scheduled should have a defined outcome for software projects such
as a work product or part of a work product.
– Work products are often combined in deliverables.
Defined milestones
– Every task or group of tasks should be associated with a project milestone.
– A milestone is accomplished when one or more work products has been reviewed for
quality and has been approved.
e) Explain COCOMO II model in detail.

(Each Point - 1 Marks (Any 4 Points))
Ans: Constructive Cost Model
 A hierarchy of estimation models
 Addresses the following areas
– Application composition model
– Early design stage model
– Post-architecture stage model
Page 18 of 38
(Autonomous)
____________________________________________________________________________________________________
 Three different sizing options are available
– Object points
– Function points
– Lines of source code
 The COCOMO II application composition model uses object points.
 Object point is computed using counts of the number of
– Screens (at the user interface)
– Reports
– Components likely to be required to build the application
 NOP = (object points) [(100-%reuse)/100]
– NOP = New Object Points
– Object Points = Weighted Total
– %reuse = Percent of reuse
 Estimated effort = NOP/PROD
– PROD = Productivity Rate
– PROD = NOP/person-month
Page 19 of 38
(Autonomous)
____________________________________________________________________________________________________
4. a) Attempt any three of the following: Marks 12
i) Explain software decomposition technique.
(Any two Technique with explanation - 2 Marks each)
Ans: Three different points of view for the decomposition approach
 Software Sizing
 Decomposition of the problem
 Decomposition of the process
1. Software Sizing
o Size refers to a quantifiable outcome of the software project.
o If a direct approach is taken, size can be measured in LOC.
o If an indirect approach is chosen, size is represented as FP.
Four different approaches to the sizing problem:
a. “Fuzzy logic” sizing:
This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy
logic.
To apply this approach, the planner must identify the type of application, establish its magnitude
on a qualitative scale, and then refine the magnitude within the original range.
b. Function point sizing:
The planner develops estimates of the information domain characteristics.
c. Standard component sizing:
Software is composed of a number of different ―standard components‖ that are generic to a
particular application area.
For example, the standard components for an information system are screens, reports, batch
programs, files.
The project planner estimates the number of occurrences of each standard component and then
uses historical project data to determine the delivered size per standard component.
d. Change sizing :
This approach is used when a project encompasses the use of existing software that must be
modified in some way as part of a project.
The planner estimates the number and type (e.g., reuse, adding code, changing code, and
deleting code) of modifications that must be accomplished.
Page 20 of 38
(Autonomous)
____________________________________________________________________________________________________
Using an ―effort ratio‖ for each type of change, the size of the change may be estimated.
2. Problem decomposition
– Example of baseline productivity metrics are LOC/pm or FP/pm
– Making the use of single baseline productivity metric is discouraged
– the planner may choose another component for sizing such as classes or objects.
– In general, LOC/pm or FP/pm averages should be computed by project domain
– Local domain averages should be used
– Statistical approach – three-point or expected-value estimate
S = (sopt + 4sm + spess)/6
S = expected-value for the estimation variable (size)
sopt = optimistic value
sm = most likely value
spess = pessimistic value
Example LOC-Based Estimation and FP-Based Estimation
3. Process decomposition
– Based on the types of process used in the project and size and compolexity of the project
estimate the best process model suitable for the project.
– If the project deadline is tight go for incremental model.
– If the project deadline is very tight go for RAD model.
ii) Describe integrating testing approaches:

i) Top –down integration
ii) Bottom-up integration.
(Each approach Explanation -1 Mark, Diagram – 1 Mark)
Ans: Top-down approach:
– In this approach the testing is done in top to down direction.
– The main module is tested first and then the stub are replaced with the original module
and then integrated with the main module and then tested.
– Same process is repeated again until all stubs are replaced with original modules and
they are completely tested.
Page 21 of 38
(Autonomous)
____________________________________________________________________________________________________
Bottom-up approach:
In this approach,
– The low level modules are integrated into clusters.
– The clusters are entirely tested by the drivers.
– Once the testing is over the driver is removed and cluster is integrated with the main
module and tested.
– The same is repeated until all the hierarchy is tested.
Page 22 of 38
(Autonomous)
____________________________________________________________________________________________________
iii) Explain four principles of analysis modeling.

(List - 2 Marks and Explanation -2 Marks)
Ans:
1. The information domain of a problem must be represented and understood.
– define data objects
– describe data attributes
– establish data relationships
2. The functions that the software is to perform must be defined.
– Identify functions that transform data objects
3. The behavior of the software (as a consequence of external events) must be represented.
– indicate different states of the system
– specify events that cause the system to change state
4. The models that depict information function and behavior must be partitioned in a
manner that uncovers detail in a layered (or hierarchical) fashion.
– Refine each model to represent lower levels of abstraction
– refine data objects
– create a functional hierarchy represent behavior at different levels of detail
5. The analysis process should move from essential information toward implementation
detail.
Page 23 of 38
(Autonomous)
____________________________________________________________________________________________________
iv) Describe debugging process.

(Diagram - 2 Marks and Explanation- 2 Marks)
Ans:
– Debugging occurs as a consequence of successful testing

– It is still very much an art rather than a science
– Good debugging ability may be an innate human trait
– Large variances in debugging ability exist
– The debugging process begins with the execution of a test case
– Results are assessed and the difference between expected and actual performance is
encountered
– This difference is a symptom of an underlying cause that lies hidden
– The debugging process attempts to match symptom with cause, thereby leading to error
correction
Page 24 of 38
(Autonomous)
____________________________________________________________________________________________________
b) Attempt any one of the following: Marks 06

i) Describe CMMI.
(For each level-1 Mark)
Ans: CMMI (Capability Maturity Model Integration) is a proven industry framework to improve
product quality and development efficiency for both hardware and software
– Sponsored by US Department of Defence in cooperation with Carnegie Mellon University and
the Software Engineering Institute (SEI)
• Representation as:
– Staged
– Continuous
• Level 0: Incomplete—the process area (e.g., requirements management) is either not
performed or does not achieve all goals and objectives defined by the CMMI for level 1
capability for the process area.
• Level 1: Performed—all of the specific goals of the process area (as defined by the CMMI)
have been satisfied. Work tasks required to produce defined work products are being
conducted.
• Level 2: Managed—all capability level 1 criteria have been satisfied. In addition, all work
associated with the process area conforms to an organizationally defined policy; all people
doing the work have access to adequate resources to get the job done; stakeholders are
actively involved in the process area as required; all work tasks and work products are
―monitored, controlled, and reviewed; and are evaluated for adherence to the process
description‖.
• Level 3: Defined—all capability level 2 criteria have been achieved. In addition, the process is
―tailored from the organization’s set of standard processes according to the organization’s
tailoring guidelines, and contributes work products, measures, and other process-improvement
information to the organizational process assets‖ .
• Level 4: Quantitatively managed—all capability level 3 criteria have been achieved. In
addition, the process area is controlled and improved using measurement and quantitative
assessment. ―Quantitative objectives for quality and process performance are established and
used as criteria in managing the process‖ .
Page 25 of 38
(Autonomous)
____________________________________________________________________________________________________
• Level 5: Optimized—all capability level 4 criteria have been achieved. In addition, the
process area is adapted and optimized using quantitative (statistical) means to meet changing
customer needs and to continually improve the efficacy of the process area under
consideration.
ii) Explain spiral model with diagram.

(Diagram - 2 Marks, Explanation - 3 Marks, Advantages and disadvantages - 1 Mark)
Ans:
Traditional method or model of software development

Also encompasses all the essential development phases:
o Requirements analysis
o Design
o Code
o Test
o Maintenance
Explicitly addresses the issue of quality assurance by performing the development process
in a ―step-wise refinement‖ method
Page 26 of 38
(Autonomous)
____________________________________________________________________________________________________
Each step produces a ―deliverable‖ which embodies the structure or sequential nature of
the process
This process naturally focuses on a high degree of customer or stakeholder involvement
during the development process
In this diagram, ―Communication‖ refers to the Requirements and analysis process,
―Planning‖ corresponds to preliminary design and scheduling, ―Modeling‖ is the detailed
design, ―Construction‖ refers to code/debug/integration, and ―Deployment‖ is the delivery to
the customer and the feedback process.
Software is developed in a series of evolutionary releases
o During early iterations, the release might be a paper model or prototype
o During later iterations, increasingly more complete versions of the engineered
system are produced
o The final iteration produces the complete software product
First circuit around the spiral might result in the development of the product specification;
might result in a CoDR review by the customer
Next iteration might produce a prototype, containing the GUI, for example; the customer
might want to see this, so there could be a PDR and/or CDR at this time
Third time around might be used to fill in more detailed functionality, and release a
preliminary working model
Fourth circuit might result in a complete alpha release, which the customer could
―hammer on‖ for a while to test robustness and provide feedback to the solution provider
about the product’s strengths and weaknesses
Fifth iteration might be a beta test, or it could be the final build for initial release (if the
previous circuit was satisfactory enough to warrant this)
Problem with the spiral model: may not appear controllable to the customer, particularly if
the customer is more accustomed to the waterfall model
Page 27 of 38
(Autonomous)
____________________________________________________________________________________________________
5. Attempt any two of the following: Marks 16
a) Describe communication practices in engineering. Explain briefly its different principles.
(Description - 2 Marks, Any 6 Principles with their explanation - 1 Mark each)
Ans: Before customer requirements can be analyzed, modeled, or specified they must be gathered
through the communication activity. A customer has a problem that may be amenable to a
computer-based solution. You respond to the customer’s request for help. Communication has
begun. But the road from communication to understanding is often full of potholes.
Effective communication (among technical peers, with the customer and other stakeholders, and
with project managers) is among the most challenging activities that you will confront. In this
context, I discuss communication principles as they apply to customer communication. However,
many of the principles apply equally to all forms of communication that occur within a software
project.
Principle 1. Listen. Try to focus on the speaker’s words, rather than formulating your response to
those words. Ask for clarification if something is unclear, but avoid constant interruptions. Never
become contentious in your words or actions (e.g., rolling your eyes or shaking your head) as a
person is talking.
Principle 2. Prepare before you communicate. Spend the time to understand the problem before
you meet with others. If necessary, do some research to understand business domain jargon. If you
have responsibility for conducting a meeting, prepare an agenda in advance of the meeting.
Principle 3. Someone should facilitate the activity. Every communication meeting should have a
leader (a facilitator) to keep the conversation moving in a productive direction, (2) to mediate any
conflict that does occur, and (3) to ensure than other principles are followed.
Principle 4. Face-to-face communication is best. But it usually works better when some other
representation of the relevant information is present. For example, a participant may create a
drawing or a ―strawman‖ document that serves as a focus for discussion.
Principle 5. Take notes and document decisions. Things have a way of falling into the cracks.
Someone participating in the communication should serve as a ―recorder‖ and write down all
important points and decisions.
Principle 6. Strive for collaboration. Collaboration and consensus occur when the collective
knowledge of members of the team is used to describe product or system functions or features.
Page 28 of 38
(Autonomous)
____________________________________________________________________________________________________
Each small collaboration serves to build trust among team members and creates a common goal for
the team.
Principle 7. Stay focused; modularize your discussion. The more people involved in any
communication, the more likely that discussion will bounce from one topic to the next. The
facilitator should keep the conversation modular, leaving one topic only after it has been resolved.
Principle 8. If something is unclear, draw a picture. Verbal communication goes only so far. A
sketch or drawing can often provide clarity when words fail to do the job.
Principle 9. (a) Once you agree to something, move on. (b) If you can’t agree to something, move
on. (c) If a feature or function is unclear and cannot be clarified at the moment, move on.
Communication, like any software engineering activity, takes time. Rather than iterating endlessly,
the people who participate should recognize that many topics require discussion (see Principle 2)
and that ―moving on‖ is sometimes the best way to achieve communication agility.
Principle 10. Negotiation is not a contest or a game. It works best when both parties win. There
are many instances in which you and other stakeholders must negotiate functions and features,
priorities, and delivery dates. If the team has collaborated well, all parties have a common goal.
Still, negotiation will demand compromise from all parties.
b) Explain SCM scenario and also explain SCM features.

(Description - 4 Marks, Any 4 features with their explanation - 1 Mark each))
Ans: A typical CM operational scenario involves a project manager who is in charge of a software
group, a configuration manager who is in charge of the CM procedures and policies, the software
engineers who are responsible for developing and maintaining the software product, and the
customer who uses the product. In the scenario, assume that the product is a small one involving
about 15,000 lines of code being developed by a team of six people. (Note that other scenarios of
smaller or larger teams are possible, but, in essence, there are generic issues that each of these
projects face concerning CM.)
At the operational level, the scenario involves various roles and tasks. For the project manager, the
goal is to ensure that the product is developed within a certain time frame. Hence, the manager
monitors the progress of development and recognizes and reacts to problems. This is done by
generating and analyzing reports about the status of the software system and by performing reviews
on the system.
Page 29 of 38
(Autonomous)
____________________________________________________________________________________________________
The goals of the configuration manager are to ensure that procedures and policies for creating,
changing, and testing of code are followed, as well as to make information about the project
accessible. To implement techniques for maintaining control over code changes, this manager
introduces mechanisms for making official requests for changes, for evaluating them (via a Change
Control Board that is responsible for approving changes to the software system), and for
authorizing changes. The manager creates and disseminates task lists for the engineers and basically
creates the project context. Also, the manager collects statistics about components in the software
system, such as information determining which components in the system are problematic.
For the software engineers, the goal is to work effectively. This means engineers do not
unnecessarily interfere with each other in the creation and testing of code and in the production of
supporting work products. But, at the same time, they try to communicate and coordinate
efficiently. Specifically, engineers use tools that help build a consistent software product. They
communicate and coordinate by notifying one another about tasks required and tasks completed.
Changes are propagated across each other’s work by merging files. Mechanisms exist to ensure
that, for components that undergo simultaneous changes, there is some way of resolving conflicts
and merging changes. A history is kept of the evolution of all components of the system along with
a log with reasons for changes and a record of what actually changed.
SCM Features:
To support SCM, the repository must have a tool set that provides support for the following
features:
Versioning. As a project progresses, many versions of individual work products will be created.
The repository must be able to save all of these versions to enable effective management of product
releases and to permit developers to go back to previous versions during testing and debugging. The
repository must be able to control a wide variety of object types, including text, graphics, bit maps,
complex documents, and unique objects like screen and report definitions, object files, test data, and
results.
Dependency tracking and change management. The repository manages a wide variety of
relationships among the data elements stored in it. These include relationships between enterprise
entities and processes, among the parts of an application design, between design components and
the enterprise information architecture, between design elements and deliverables, and so on. Some
Page 30 of 38
(Autonomous)
____________________________________________________________________________________________________
of these relationships are merely associations, and some are dependencies or mandatory
relationships.
Requirements tracing. This special function depends on link management and provides the ability
to track all the design and construction components and deliverables that result from a specific
requirements specification (forward tracing). In addition, it provides the ability to identify which
requirement generated any given work product (backward tracing).
Configuration management. A configuration management facility keeps track of a series of
configurations representing specific project milestones or production releases.
Audit trails. An audit trail establishes additional information about when, why, and by whom
changes are made. Information about the source of changes can be entered as attributes of specific
objects in the repository. A repository trigger mechanism is helpful for prompting the developer or
the tool that is being used to initiate entry of audit information (such as the reason for a change)
whenever a design element is modified.
c) Describe RAD process model with neat diagram and its advantages.
(Description -2 Mark, Diagram -2 Marks, Stages- 2 Marks,
Advantages & Disadvantages- 2 Marks)
Ans: RAD Model
Page 31 of 38
(Autonomous)
____________________________________________________________________________________________________
Rapid application development (RAD) is an incremental software development process model

that emphasizes an extremely short development cycle. The RAD model is a ―high-speed‖
adaptation of the linear sequential model in which rapid development is achieved by using
component-based construction. If requirements are well understood and project scope is
constrained, the RAD process enables a development team to create a ―fully functional system‖
within very short time periods (e.g., 60 to 90 days). Used primarily for information systems
applications, the RAD approach encompasses the following phases.
Business modeling: - The information flow among business functions is modeled in a way that
answers the following questions: What information drives the business process? What
information is generated? Who generates it? Where does the information go? Who processes it?
Data modeling: - The information flow defined as part of the business modeling phase is refined
into a set of data objects that are needed to support the business. The characteristics (called
attributes) of each object are identified and the relationships between these objects defined. Data
modeling is considered in.
Process modeling: - The data objects defined in the data modeling phase are transformed to
achieve the information flow necessary to implement a business function. Processing descriptions
are created for adding, modifying, deleting, or retrieving a data object.
Application generation: - RAD assumes the use of fourth generation techniques (Section 2.10).
Rather than creating software using conventional third generation programming languages the
RAD process works to reuse existing program components (when possible) or create reusable
components (when necessary). In all cases, automated tools are used to facilitate construction of
the software.
Testing and turnover: - Since the RAD process emphasizes reuse, many of the program
components have already been tested. This reduces overall testing time. However, new
components must be tested and all interfaces must be fully exercised.
Advantages:-
1. Faster implementation of Project
2. Parallel implementation
3. Projects divided into small teams results into better implementation
Page 32 of 38
(Autonomous)
____________________________________________________________________________________________________
Disadvantage:-
1. Limited Time for system implementation results into inadequate analysis of project.
2. Less time for testing.
3. If user is unclear with the system project may fail.
6. Attempt any four of the following: Marks 16

a) Differentiate between alpha and beta testing.
(Any four (4) points -1 Mark each)
Ans:
ALPHA TESTING BETA TESTING

Alpha Testing Conducted at Developer Site by Beta Testing is conducted at User site by End
End user. user.
Alpha Testing is Conducted in Control Beta Testing is conducted in Un-control

Environment as Developer is present Environment as Developer is Absent
Less Chances of Finding an error as Developer More Chances of Finding an error as

usually guides user. Developer can use system in any way
It is kind of mock up testing The system is tested as Real application
Error/Problem may be solved in quick time if The user has to send difficulties to the
possible. developer who then corrects it.
Short process. Lengthy Process
b) Describe software engineering as a layered technology.

(Description - 3 Marks, Diagram - 1 Mark)
Ans: Software Engineering – A Layered Technology approach.
Software engineering is a layered technology. Referring to Figure any engineering approach
(including software engineering) must rest on an organizational commitment to quality. Total
quality management and similar philosophies foster a continuous process improvement culture,
and this culture ultimately leads to the development of increasingly more mature approaches to
software engineering. The bedrock that supports software engineering is a quality focus.
The foundation for software engineering is the process layer. Software engineering process is the
glue that holds the technology layers together and enables rational and timely development of
Page 33 of 38
(Autonomous)
____________________________________________________________________________________________________
computer software. Process defines a framework for a set of key process areas that must be
established for effective delivery of software engineering technology. The key process areas form
the basis for management control of software projects and establish the context in which technical
methods are applied, work products (models, documents, data, reports, forms, etc.) are produced,
milestones are established, quality is ensured, and change is properly managed.
Software engineering methods provide the technical how-to's for building software. Methods
encompass a broad array of tasks that include requirements analysis, design, program
construction, testing, and support. Software engineering methods rely on a set of basic principles
that govern each area of the technology and include modeling activities and other descriptive
techniques.
Software engineering tools provide automated or semi-automated support for the process and the
methods. When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided software
engineering, is established.
c) Describe people factor in s/w management spectrum.

(Description - 3 Marks, Various teams associated with project -1 Mark)
Ans: The People
The ―people factor‖ is so important that the Software Engineering Institute has developed a
people management capability maturity model (PM-CMM), ―to enhance the readiness of software
organizations to undertake increasingly complex applications by helping to attract, grow,
motivate, deploy, and retain the talent needed to improve their software development capability‖.
The people management maturity model defines the following key practice areas for software
Page 34 of 38
(Autonomous)
____________________________________________________________________________________________________
people: recruiting, selection, performance management, training, compensation, career
development, organization and work design, and team/culture development. Organizations that
achieve high levels of maturity in the people management area have a higher likelihood of
implementing effective software engineering practices. The PM-CMM is a companion to the
software capability maturity model that guides organizations in the creation of a mature software
process.
Following are the various categories of people associated with the project.
 The Stakeholders: - This include
Senior managers, Project (technical) managers, Practitioners, Customers, End user
 Team Leaders: - Leaders of various teams associated with the project
 The Software Team:- Entire software team
 Agile Teams: - Temporary teams associated with software
 Coordination and Communication Issues:
d) What are McCall’s quality factors?

(Any 8 factors shall be consider - ½ Marks for each factor, Diagram is optional)
Ans: The factors that affect software quality can be categorized in two broad groups: (1) factors that can
be directly measured (e.g., defects per function-point) and (2) factors that can be measured only
indirectly (e.g., usability or maintainability). In each case measurement must occur. We must
compare the software (documents, programs, data) to some datum and arrive at an indication of
quality.
Page 35 of 38
(Autonomous)
____________________________________________________________________________________________________
Referring to the factors noted in Figure above, McCall and his colleagues provide the following
descriptions:
1. Correctness: - The extent to which a program satisfies its specification and fulfills the customer's
mission objectives.
2. Reliability: - The extent to which a program can be expected to perform its intended function
with required precision. [It should be noted that other, more complete definitions of reliability
have been proposed
3. Efficiency: - The amount of computing resources and code required by a program to perform its
function.
4. Integrity: - Extent to which access to software or data by unauthorized persons can be controlled.
5. Usability: - Effort required learning, operating, preparing input, and interpreting output of a
program.
6. Maintainability: - Effort required locating and fixing an error in a program.
7. Flexibility: - Effort required modifying an operational program.
8. Testability: - Effort required testing a program to ensure that it performs its intended function.
9. Portability: - Effort required transferring the program from one hardware and/or software system
environment to another.
10. Reusability: - Extent to which a program [or parts of a program] can be reused in other
applications—related to the packaging and scope of the functions that the program performs.
11. Interoperability: - Effort required to couple one system to another.
e) Describe regression testing and smoke testing.

(Regression testing- 2 Marks, Smoke Testing- 2 Marks)
Ans: Regression Testing: -
Each time a new module is added as part of integration testing, the software changes. New data
flow paths are established, new I/O may occur, and new control logic is invoked. These changes
may cause problems with functions that previously worked flawlessly. In the context of an
integration test strategy, regression testing is the reexecution of some subset of tests that have
already been conducted to ensure that changes have not propagated unintended side effects.
Page 36 of 38
(Autonomous)
____________________________________________________________________________________________________
In a broader context, successful tests (of any kind) result in the discovery of errors, and errors
must be corrected. Whenever software is corrected, some aspect of the software configuration (the
program, its documentation, or the data that support it) is changed. Regression testing is the
activity that helps to ensure that changes (due to testing or for other reasons) do not introduce
unintended behavior or additional errors.
Regression testing may be conducted manually, by re-executing a subset of all test cases or using
automated capture/playback tools. Capture/playback tools enable the software engineer to capture
test cases and results for subsequent playback and comparison.
The regression test suite (the subset of tests to be executed) contains three different classes of test
cases:
A representative sample of tests that will exercise all software functions.
Additional tests that focus on software functions that are likely to be affected by the
change.
Tests that focus on the software components that have been changed.
Smoke Testing: -
Smoke testing is an integration testing approach that is commonly used when ―shrinkwrapped‖
software products are being developed. It is designed as a pacing mechanism for time-critical
projects, allowing the software team to assess its project on a frequent basis. In essence, the
smoke testing approach encompasses the following activities:
1. Software components that have been translated into code are integrated into a ―build.‖ A
build includes all data files, libraries, reusable modules, and engineered components that
are required to implement one or more product functions.
2. A series of tests is designed to expose errors that will keep the build from properly
performing its function. The intent should be to uncover ―show stopper‖ errors that have
the highest likelihood of throwing the software project behind schedule.
3. The build is integrated with other builds and the entire product (in its current form) is
smoke tested daily. The integration approach may be top down or bottom up.
Page 37 of 38
(Autonomous)
____________________________________________________________________________________________________
The smoke test should exercise the entire system from end to end. It does not have to be
exhaustive, but it should be capable of exposing major problems. The smoke test should be
thorough enough that if the build passes, you can assume that it is stable enough to be tested more
thoroughly.
Smoke testing provides a number of benefits when it is applied on complex, time critical software
engineering projects:
1. Integration risk is minimized.
2. The quality of the end-product is improved.
3. Error diagnosis and correction are simplified.
4. Progress is easier to assess.
Page 38 of 38

(w13)

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

(w13)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(w13)

Uploaded by

Copyright:

Available Formats

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION

1. a) Attempt any three of the following: Marks 12

ii) Differentiate between validation and verification.

iii) What is project scheduling and tracking?

iv) State benefits of ISO standards.

b) Attempt any one of the following: Marks 06

ii) State design modeling principles.

2. Attempt any four of the following: Marks 16

ii) Data attribute

b) Describe white-box testing.

c) Explain six sigma strategy.

d) Describe waterfall model with the help of neat diagram.

Also know as classic life cycle or waterfall model

e) Explain seven major task of requirement engineering.

f) Explain characteristics of software testing.

3. Attempt any four the following: Marks 16

Proactive risk strategies

b) Explain unit testing in detail.

c) Define and explain clean-room approach.

(Note: Figure carry- 2 Marks if drawn else its optional)

d) Explain different principles of software project scheduling.

e) Explain COCOMO II model in detail.

 NOP = (object points) [(100-%reuse)/100]

– NOP = New Object Points

– Object Points = Weighted Total

– %reuse = Percent of reuse

 Estimated effort = NOP/PROD

– PROD = Productivity Rate

Example LOC-Based Estimation and FP-Based Estimation

ii) Describe integrating testing approaches:

iii) Explain four principles of analysis modeling.

iv) Describe debugging process.

– Debugging occurs as a consequence of successful testing

b) Attempt any one of the following: Marks 06

ii) Explain spiral model with diagram.

Traditional method or model of software development

b) Explain SCM scenario and also explain SCM features.

Rapid application development (RAD) is an incremental software development process model

6. Attempt any four of the following: Marks 16

ALPHA TESTING BETA TESTING

Alpha Testing is Conducted in Control Beta Testing is conducted in Un-control

Less Chances of Finding an error as Developer More Chances of Finding an error as

It is kind of mock up testing The system is tested as Real application

Short process. Lengthy Process

b) Describe software engineering as a layered technology.

c) Describe people factor in s/w management spectrum.

d) What are McCall’s quality factors?

e) Describe regression testing and smoke testing.

You might also like