2017 Summer Model Answer Paper

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
MODEL ANSWER
SUMMER - 2017 EXAMINATION
Subject: Software Engineering Subject Code: 17513
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 tryto
assess the understanding level of the candidate.
3) The language errors such as grammatical, spelling errors should not be given moreImportance
(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.
Q. Sub Answer Marking

No Q.N. Scheme
.
1. Attempt any FIVE of the following: 20
a) What is software? What is embedded software? 4M
Ans. Software is
(1) Instructions (computer programs) that when executed provide Definitio
desired function and n or
performance, concept
(2) Data structures that enable the programs to adequately of
manipulate information, and software
(3) Documents that describe the operation and use of the programs 2M
Embedded software: Intelligent products have become

commonplace in nearly every consumer and industrial market. Embedd
Embedded software resides in read-only memory and is used to ed
control products and systems for the consumer and industrial software
markets. Embedded software can perform very limited and esoteric 2M
functions (e.g., keypad control for a microwave oven) or provide
signiﬁcant function and control capability (e.g., digital functions in
an automobile such as fuel control, dashboard displays, and braking
Page 1/34
(Autonomous)
MODEL ANSWER
systems).
A function point extension called feature points. It is a superset of
the function point measure that can be applied to systems and
engineering software applications. The feature point measure
accommodates applications in which algorithmic complexity is high.
Real-time, process control and embedded software applications tend
to have high algorithmic complexity and are therefore amenable to
the feature point.
b) Explain the term scrum. 4M
Ans. Scrum is a management and controls process that cuts through
complexity to focus on building software that meets business needs.
Scrum itself is a framework for effective team collaboration on Definitio
complex software projects. They need real time and fast decision n or
making process which is need for getting accurate information and on concept
actual events. Teams in the organization work together in a team of scrum
focusing on the organizational goals that they need to achieve. The 2M
team is hard working and goal oriented even though it is a small team
work.
Scrum is a repetitive and incremental framework for project
management majorly used in very active software development.
Scrum methodology gives premium to functional software, the
freedom to change along with new business realities, collaboration
and communication. It is a flexible, holistic strategy of product
development in which a team of developers works as a unit in order Explana
to accomplish an objective that is common to them all, challenging tion 2M
assumptions of the “traditional, sequential approach” to product
development.
The scrum methodology requires openness and trust in the team,
which these five values of Scrum support
 Openness: Members of the team and their stakeholders consent to
be open about their work and any issues they encounter.
 Commitment: Members of the team individually promise to reach
their team goals, in every Sprint.
 Courage: Team members know they are courageous to work
through disagreement and issues together so they can do what is
right.
 Respect: There is respect among team members to be capable
technically as well as to work with the right intent.
 Focus: Members of the Team concentrate exclusively on the goals
Page 2/34
(Autonomous)
MODEL ANSWER
of their team and the Sprint Backlog; no work should be done

outside their backlog.
c) List core principle of Software Engineering. 4M
Ans. Following are the core principles of software engineering
1. TheReasonIt AllExists
2. KeepIt Simple,Stupid! List of
3. Maintain theVision correct
4. WhatYou Produce, Others WillConsume. principle
5. BeOpento theFuture explanat
6. PlanAhead forReuse ion2M
7. Think!
1. The Reason It All Exists

A software system exists for one reason: To provide value to its
users. All decisions should be made with this in mind. Before
specifying a system requirement, before noting a piece of system
functionality, before determining the hardware platforms or
development processes, ask yourself questions such as: "Does this
add real VALUE to the system?" If the answer is "no", don't do it.
All other principles support this one. 2M
2. Keep It Simple, Stupid! forAny 1
There are many factors to consider in any design effort. All or 2
design should be as simple as possible, but no simpler. This expected
facilitates having a more easily understood, and easily maintained to
system. explain
3. Maintain the Vision in short
A clear vision is essential to the success of a software project.
Without one, a project almost unfailingly ends up being "of two [or
more] minds" about itself.
Compromising the architectural vision of a software system
weakens and will eventually break even the most well designed
systems. Having an empowered Architect who can hold the vision
and enforce compliance helps ensure a very successful software
project.
4. What You Produce, Others Will Consume
Seldom is an industrial-strength software system constructed and
used in a vacuum. In some way or other, someone else will use,
maintain, document, or otherwise depend on being able to
Page 3/34
(Autonomous)
MODEL ANSWER
understand your system. So, always specify, design, and implement

knowing someone else will have to understand what you are doing.
The audience for any product of software development is
potentially large. Making their job easier adds value to the system.
5. Be Open to the Future
A system with a long lifetime has more value. In today's computing
environments, where specifications change on a moment's notice
and hardware platforms are obsolete when just a few months old,
software lifetimes are typically measured in months instead of
years. However, true "industrial-strength" software systems must
endure far longer. To do this successfully, these systems must be
ready to adapt to these and other changes. Systems that do this
successfully are those that have been designed this way from
the start. Never design yourself into a corner. Always ask "what
if ", and prepare for all possible answers by creating systems that
solve the general problem, not just the specific one. This could very
possibly lead to the reuse of an entire system.
6. Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is
arguably the hardest goal to accomplish in developing a software
system. The reuse of code and designs has been proclaimed as a
major benefit of using object-oriented technologies. However, the
return on this investment is not automatic. How can you reuse
something that you don't know exists? Planning ahead for reuse
reduces the cost and increases the value of both the reusable
components and the systems into which they are incorporated.
7. Think!
This last Principle is probably the most overlooked. Placing clear,
complete thought before action almost always produces better
results. When you think about something, you are more likely to do
it right. You also gain knowledge about how to do it right again. If
you do think about something and still do it wrong, it becomes
valuable experience. A side effect of thinking is learning to
recognize when you don t know something, at which point you can
research the answer. When clear thought has gone into a system,
value comes out. Applying the first six Principles requires intense
thought, for which the potential rewards are enormous.
Page 4/34
(Autonomous)
MODEL ANSWER
d) Write importance of analysis modelling. 4M

(Note: Four relevant importanceshallbeconsider)
Ans. Importance of analysis modeling:
1.Designing gets easier to the designer
2.Better understanding of system can be accomplished
3.System feasibility can be determined
4.Defines data objects For
5.Describes data attributes each
6.Establishes data relationships importa
7.Identifies functions that transform data objects nce 1M
8.Indicates different states of the system
9.Specifies events that cause the system to change state
10.Refines each model to represent lower levels of abstraction
11.Refines data objects
12. Relates a functional hierarchy represent behavior at different
levels of detail
e) List various testing characteristics. 4M
Ans. Objective of testing is to find errors and good test must have high
probability of finding an error.
 Testability: How software can be tested? It should not require
more time to test. To reduce testing cost and time
 Operability: It should be easily operable by end user to get desired List of
output. System should be designed and implemented keeping testing
quality in mind. System should be more user friendly. characte
 Observability: What you can see that you can test. Inputs are ristics
provided as a part of test during testing execution. If system states 2M and
and variables are visible incorrect output can be easily identified. any four
Hence internal errors can be detected and reported. to six
 Controllability: Better we control software, the most testing can be point
automated and optimized. with
 Decomposability: The program should be decomposable into small explanat
modules as a result a small testing module can be implemented to ion 2M
check validity. The software system is built from no. of
independent modules that can be tested independently.
 Simplicity: Testing can be done quickly if there is only less to test.
The software program should exhibit functionally, structurally,
code based simple.
 Stability: Uncontrolled and frequent changes cause much more
disturbance to the test activity. Changes should be as few as
Page 5/34
(Autonomous)
MODEL ANSWER
possible. The software should be able to recover well from changes

or failures.
 Understandability: If one can understand the software more then
we can test software smartly. The internal, external interfaces and
dependencies between system components should be clearly
understood. Any change made to design and implement should be
informed to tester.
f) What is change control? 4M
Ans. Change Control:
Change control is vital. But the forces that make it necessary also
make it annoying. We worry about change because a tiny perturbation
in the code can create a big failure in the product. But it can also fix a
big failure or enable wonderful new capabilities. We worry about
change because a single rogue developer could sink the project; yet
brilliant ideas originate in the minds of those rogues, and a
burdensome change control process could effectively discourage
them from doing creative work. Explana
For a large software project, uncontrolled change rapidly leads to tion
chaos. For such projects, change control combines human procedures relevant
and automated tools to provide a mechanism for the control of to
change. A change request is submitted and evaluated to assess change
technical merit, potential side effects, overall impact on other control
configuration objects and system functions, and the projected cost of 2M
the change. The results of the evaluation are presented as a change
report, which is used by a change control authority (CCA)—a person
or group that makes a final decision on the status and priority of the
change. An engineering change order (ECO) is generated for each
approved change. The ECO describes the change to be made, the
constraints that must be respected, and the criteria for review and
audit.
The object(s) to be changed can be placed in a directory that is
controlled solely by the software engineer making the change. A
version control system updates the original file once the change has
been made. As an alternative the object(s) to be changed can be
“checked out” of the project database (repository), the change is
made, and appropriate SQA activities are applied. The object(s) is
(are) then “checked in” to the database and appropriate version
control mechanisms are used to create the next version of the
Page 6/34
(Autonomous)
MODEL ANSWER
software.
These version control mechanisms, integrated within the change
control process, implement two important elements of change
management—access control and synchronization control. Access
control governs which software engineers have the authority to access
and modify a particular configuration object. Synchronization control
helps to ensure that parallel changes, performed by two different
people, don’t overwrite one another.
The Change Control Process
Diagram
2M
Page 7/34
(Autonomous)
MODEL ANSWER
g) List various activities of SQA. 4M

Ans. Software quality assurance is composed of a variety of tasks
associated with two different constituencies—the software engineers
who do technical work and an SQA group that has responsibility for
quality assurance planning, oversight, record keeping, analysis, and
reporting. Descript
Software engineers address quality (and perform quality assurance ion of
and quality control activities) by applying solid technical methods SQA -
and measures, conducting formal technical reviews, and performing 1M
well-planned software testing.
SQA Activities: (Any 4-6 activities accepted)

These activities are performed (or facilitated) by an independent SQA
group that:
1. Evaluations to be performed
2. Prepares an SQA plan for a project. Activitie
3. Participates in the development of the project’s software process s of
description. SQA-
4. Reviews software engineering activities to verify compliance 3M
with the defined software process.
5. Audits designated software work products to verify compliance
with those defined as part of the software process.
6. Ensures that deviations in software work and work products are
documented and handled according to a documented procedure.
7. Records any noncompliance and reports to senior management.
8. Audits and reviews to be performed
9. Standards those are applicable to the project
10. Procedures for error reporting and tracking
11. documents to be produced by the SQA group
12. Amount of feedback provided to the software project team
2. Attempt any FOUR of the following: 16
a) What is quality control? 4M
Ans. Quality Control is known as QC and focuses on identifying defect.
QC ensures that the approaches, techniques, methods and processes
are designed in the project are following correctly. QC activities
monitor and verify that the project deliverables meet the defined Concept
quality standards. 2M
Quality Control is a reactive process and is detection in nature. It
recognizes the defects. Quality Control has to complete after Quality
Page 8/34
(Autonomous)
MODEL ANSWER
Assurance.
The basic definition of quality for a software product is the product's
ability to fulfill the user's reasonable wishes and expectations, it must
provide functions of a type and at a time when the user needs them,
and the product must work. A closer inspection of what perceived
quality consists of reveals that there are many dimensions to defining
a quality product.
Some of these dimensions are:
 The level of satisfaction that the user perceives from the product.
 Achieving a perceived high quality with this demands that the
product also meets the customer's implied needs of the product.
 The value of the product. This value is perceived for all
stakeholders relative to their competitive environment.
 Key attributes, such as reliability, usability, efficiency,
portability, maintainability, Defectiveness, i.e. the degree to
which the product works incorrectly
Software Quality Control (SQC) is a set of activities for ensuring

quality in software products.
It includes the following activities: 2M for
 Reviews importa
o Requirement Review nce of
o Design Review Quality
o Code Review control
o Deployment Plan Review
o Test Plan Review
o Test Cases Review
 Testing
o Unit Testing
o Integration Testing
o System Testing
o Acceptance Testing
Software Quality Control is limited to the Review/Testing phases of
the Software Development Life Cycle and the goal is to ensure that
the products meet specifications/requirements.
The process of Software Quality Control (SQC) is governed
by Software Quality Assurance (SQA). While SQA is oriented
towards prevention, SQC is oriented towards detection.
Page 9/34
(Autonomous)
MODEL ANSWER
b) Explain following terms w.r.t. risk management: 4M

(i) Risk identification
(ii) Risk analysis
Ans. (i) Risk identification:
During the first step in the software risk management process, risks
are identified and added to the list of known risks. The output of this
step is a list of project-specific risks that have the potential of
compromising the project's success. There are many techniques for 2M for
identifying risks, including interviewing, reporting, decomposition, Risk
assumption analysis, critical path analysis, and utilization of risk identific
taxonomies. Interviewing/Brainstorming: ation
One technique for identifying risks is interviewing or brainstorming
with project personnel, customers, and vendors.
Open-ended questions such as the following can help identify
potential areas of risk.
What new or improved technologies does this project implement?
What interfaces issues still need to be defined?
What requirements exist that we aren’t sure how to implement?
What concerns do we have about our ability to meet the required
quality and performance levels?
Voluntary Reporting:
Decomposition: As the product is being decomposed during the
requirements and design phases, another opportunity exists for risk
identifications. Every TBD ("To Be Done/Determined") is a potential
risk. “The most important thing about planning is writing down what
you don’t know, because what you don’t know is what you must find
out.
Decomposition in the form of work breakdown structures during
project planning can also help identify areas of uncertainty that may
need to be recorded as risks. Assumption Analysis: Process and
product assumptions must be analyzed. Risk Taxonomies: Risk
taxonomies are lists of problems that have occurred on other projects
and can be used as checklists to help ensure all potential risks have
been considered.
(ii) Risk analysis

During the risk analysis step, each risk is assessed to determine:
Likelihood: the probability that the risk will result in a loss 2M for
Impact: the size or cost of that loss if the risk turns into a problem Risk
Page 10/34
(Autonomous)
MODEL ANSWER
Timeframe: when the risk needs to be addressed (i.e., risk associated Analysis
with activities in the near future would have a higher priority similar
risks in later activities), the interrelationships between risks are
assessed to determine if compounding risk conditions magnify losses.
Comparing the Risk Exposure measurement for various risks can help
identify those risks with the greatest probable negative impact to the
project or product and thus help establish which risks are candidates
for further action. The list of risks is then prioritized based on the
results of our risk analysis. Since resource limitations rarely allow the
consideration of all risks, the prioritized list of risks is used to
identify risks requiring additional planning and action. Other risks are
documented and tracked for possible future consideration. Risk
analysis is based on changing conditions, additional information, the
identification of new risks, or the closure of existing risks, the list of
risks requiring additional overheads.
c) Describe debugging process. 4M
Ans.
The Debugging Process Definitio

The execution of cases suspected causes, Identified causes, is n or
Debugging. concept
Debugging is not testing but always occurs as a consequence of 2M
testing. The debugging process begins with the execution of a test
case. Results are assessed and a lack of correspondence between
expected and actual performance is encountered. In many cases, the
non-corresponding data are a symptom of an underlying cause as yet 2M for
hidden. The debugging process attempts to match symptom with importa
cause, thereby leading to error correction. nce of
Page 11/34
(Autonomous)
MODEL ANSWER
The debugging process will always have one of two outcomes: Quality
(1) The cause will be found and corrected, or control
(2) The cause will not be found. In the latter case, the person
performing debugging may suspect a cause, design a test case to
help validate that suspicion, and work toward error correction in
an iterative fashion. Why is debugging so difﬁcult? Human
psychology has more to do with an answer than software
technology.
d) Compare cardinality and Modality. 4M
(AnyFour relevant Points shall be considered)
Ans. Cardinality Modality
Cardinality defines the Modalityindicates whether
rangeof object-to object ornot a relationship
Relationships between objects is mandatory
Expected Values are1:1, 1:N, Expected values are0 or1 only Any
N:M four
It does not, however, provide It provides indication points
an indication of whetheror ofparticipation in the 1M each
notaparticular data object must relationship byhavingvalues as
participate in the relationship. 1, if value is 0 no participation
in relationship will exist.
Itgives maximum numbers Itgives minimum numbers
occurrences inrelationship occurrences inrelationship
e) Explain essence of practice. 4M
Ans. Essence of practice:
Understand the problem (communication and analysis)
- Who has a stake in the solution to the problem? Explana
- What are the unknowns (data, function, behavior)? tion
- Can the problem be compartmentalized? essence
- Can the problem be represented graphically? of
Plan a solution (planning, modeling and software design) practice
- Have you seen similar problems like this before? 1M each
- Has a similar problem been solved and is the solution reusable?
- Can sub problems be defined and are solutions available for the
sub problems?
Carry out the plan (construction; code generation)
- Does the solution conform to the plan? Is the source code
traceable back to the design?
Page 12/34
(Autonomous)
MODEL ANSWER
- Is each component of the solution correct? Has the design and

code been reviewed?
Examine the results for accuracy (testing and quality assurance)
- Is it possible to test each component of the solution?
- Does the solution produce results that conform to the data,
function, and behavior that are required?
f) What do you mean by process framework? Explainwith suitable 4M
diagram.
Ans. A process framework establishes the foundation for a complete
software process by identifying a small number of framework
activities that are applicable to all software projects, regardless of
their size or complexity.
Each framework activity is populated by a set of software Descript
engineering actions. A collection of related tasks that produces a ion
major software engineering work product. Each action in process 2M
framework is populated with individual work tasks that accomplish
some part of the work implied by the action.
Five generic framework activities can be used during the
development of small programs, the creations of large web
applications and for the engineering of large complex computer-
based systems.
1. Communication:
Communication framework activity involves heavy communication
and collaboration with the customer, encompasses requirements
gathering and other related activities.
2. Planning:
Planning activity establishes a plan for software engineering
work that follows. Planning describes the technical tasks to be
conducted, the resources that will be required, the risks that are
likely the work products to be produced.
3. Modeling:
Modeling activity encompasses the creation of models that allow
the developer and the customer to better understand software
requirements specifications and the design that will achieve those
requirements.
4. Construction:
Page 13/34
(Autonomous)
MODEL ANSWER
Construction activity combines code generation and the testing.
5. Deployment:
The software is delivered to the customers who evaluates the
delivered product and provides feedback based on the evaluation.
Diagram
2M
Fig. softwareprocess framework

A software process can be characterized as shown in the diagram
1) A common process framework is established by defining a small

number of framework activities that are applicable to all software
projects, regardless of their size or complexity.
2) A number of task sets—each a collection of software engineering
work tasks, project milestones, work products, and quality
assurance points—enable the framework activities to be adapted to
the characteristics of the software project and the requirements of
the project team.
3) Umbrella activities—such as software quality assurance, software
configuration management, and measurement—overlay the process
model.
4) Umbrella activities are independent of any one framework activity
Page 14/34
(Autonomous)
MODEL ANSWER
and occur throughout the process.

5) Software Engineering Umbrella Activities ( Software project
tracking and control, Formal technical reviews, Software quality
assurance, Software configuration management, Document
preparation and production, Reusability management,
Measurement, Risk management).
a) Explain software engineering as a layered approach. 4M
Ans. Software engineering is a layered technology. The layers of software
engineering as shown in the above diagram are:-
Diagram
2M
1. A Quality Focus:
Anyengineering approach (including software engineering) must
rest on an organizational commitment to quality. Total quality
management, six sigma Explana
and similar philosophies foster a continuous process tion 2M
improvement culture, and it is this culture that ultimately leads
to the development of increasingly more effective approaches
to software engineering. The bedrock that supports software
engineering is a quality focus.
2. Process Layer:
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 computer software. Process defines a framework that
must be established for effective delivery of software engineering
technology. The software process forms the basis for
management control of software projects and establishes the
context in which technical methods are applied, works products
(models, documents, data, reports, forms etc.) are produced,
milestones are established, quantity is ensured and change is properly
Page 15/34
(Autonomous)
MODEL ANSWER
managed.
3. Methods:
Software Engineering methods provide the technical ―how to‘s‖ for
building software. Methods encompass a broad array of tasks that
include communication, requirements analysis, design modeling,
program construction, testing and support.
4. Tools:
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.
b) Explain following requirement engineering tasks: 4M
(i) Negotiation
(ii) Specification.
Ans. (i) 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 2M for
system for lesser cost. But based on the other aspect and feasibility of negotiati
a system the customer and developer can negotiate on the few key on
aspect of the system and then they can proceed towards the
implementation of a system
(ii) Specification:
A specification can be a re-written document, a set of graphical
models,a formal mathematical model,and a collection of usage 2M for
scenario, a prototype, or any combinations of these. The specification specifica
is the final work product produced by the requirement engineers. It tion
servesas 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.
c) What is DFD? Explain its symbol? 4M
Ans. 1) Data Flow Diagram (DFD) is also called as Bubble chart‘. This is a
graphical technique that represents information flow, and transformer
those are applied when data moves from input to output. 2M for
2) DFD represents system requirements those becomes program in explaini
design. ng DFD
3) DFD may be further partitioned into different levels to show
Page 16/34
(Autonomous)
MODEL ANSWER
detailed information flow e.g. level 0, level 1, level 2 etc.

4) DFD focuses on the fact ̳what data flow‘ rather how data is
processed
5) DFD is used to represent information flow, and the transformers
those are applied when data moves from input to output.
6) To show the data flow with more details the DFD is further
extended to level 1, level 2, level 3 etc. as per the requirement.
7) The typical value for the DFD is seven. Any system can be well
represented with details up to seventh levels.
The symbols that are used are
Any 4
symbols
each of
½M
diagram
and its
use in
DFD
d) How can project scheduling affect Integration testing? 4M

Ans, The project schedule provides a road map for a software project
manager. If it has been properly developed, the project schedule
defines the tasks and milestones that must be tracked and controlled
as the project proceeds. Explaini
ng
When faced with severe deadline pressure, experienced project schedule
managers sometimes use a project scheduling and control technique 1M
called time-boxing. The time-boxing strategy recognizes that the
complete product may not be deliverable by the predefined deadline.
Page 17/34
(Autonomous)
MODEL ANSWER
Therefore, an incremental software paradigm is chosen and a

schedule is derived for each incremental delivery.
The tasks associated with each increment are then time-boxed. This
means that the schedule for each task is adjusted by working
backward from the delivery date for the increment. A “box” is put Listing
around each task. When a task hits the boundary of its time box (plus or
or minus 10 percent), work stops and the next task begins. The initial explain
reaction to the time-boxing approach is often negative: “If the work how it
isn’tfinished, how can we proceed?” The answer lies in the way work affect
is accomplished. integrati
By the time the time-box boundary is encountered, it is likely that 90 on
percent of the task has been completed.11 The remaining 10 percent, testing
although important, can 3M
(1) be delayed until the next increment or (2) be completed later if
required. Rather than becoming “stuck” on a task, the project
proceeds toward the delivery date.
e) What is the concept of task network? 4M
Ans.
Diagram
2M
Individual tasks and subtasks have interdependencies based on their

sequence. In addition, when more than one person is involved in a Explain
software engineering project, it is likely that development activities concept
and tasks will be performed in parallel. When this occurs, concurrent of task
tasks must be coordinated so that they will be complete when later network
tasks require their work product(s). 2M
Page 18/34
(Autonomous)
MODEL ANSWER
A task network, also called an activity network, is a graphic

representation of the task flow for a project. It is sometimes used as
the mechanism through which task sequence and dependencies are
input to an automated project scheduling tool. In its simplest form
(used when creating a macroscopic schedule), the task network
depicts major software engineering tasks.
The concurrent nature of software engineering activities leads to a

number of important scheduling requirements. Because parallel tasks
occur asynchronously, the planner must determine intertask
dependencies to ensure continuous progress toward completion. In
addition, the project manager should be aware of those tasks that lie
on the critical path. That is, tasks that must be completed on schedule
if the project as a whole is to be completed on schedule.
f) Explain SCM in short. 4M
Ans. Software Configuration Management (SCM) is a set of activities that
have been developed to manage change throughout the life cycle of SCM
computer software. SCM can be viewed as a software quality 1M
assurance activity that is applied throughout the software process. In
the sections that follow, we examine major SCM tasks and important If the
concepts that help us to manage change. diagram
is drawn
SCM is an important element of software quality assurance. Its 2M
primary responsibility is the control of change. However, SCM is also along
responsible for the identification of individual SCIs and various with the
versions of the software,the auditing of the software configuration to explanat
ensure that it has been properly developed, and the reporting of all ion 1M
changes applied to the configuration.
or
Any discussion of SCM introduces a set of complex questions:
• How does an organization identify and manage the many existing
versions of a program (and its documentation) in a manner that will SCM
enable change to be accommodated efficiently? 1M
• How does an organization control changes before and after software Reasons
is released to a customer? why
• Who has responsibility for approving and ranking changes? changes
• How can we ensure that changes have been made properly? are
•What mechanism is used to appraise others of changes that are required
made? 3M
Page 19/34
(Autonomous)
MODEL ANSWER
These questions lead us to the definition of five SCM tasks:

identification, version control,change control, configuration auditing,
and reporting.
a) Give possible reasons of why software is delivered late. 4M
Ans. Although there are many reasons why software is delivered late, most
can be traced to one or more of the following root causes: ½ M for
• An unrealistic deadline established by someone outside the software each
development group and forced on managers and practitioners within reason
the group. total 8
• Changing customer requirements that are not reflected in schedule point
changes. must be
• An honest underestimate of the amount of effort and/or the number there
ofresources that will be required to do the job.
• Predictable and/or unpredictable risks that were not considered
when the project commenced.
• Technical difficulties that could not have been foreseen in advance.
• Human difficulties that could not have been foreseen in advance.
• Miscommunication among project staff that results in delays.
• A failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the problem.
Aggressive (read "unrealistic") deadlines are a fact of life in the

software business.
Sometimes such deadlines are demanded for reasons that are

legitimate, from the point of view of the person who sets the deadline.
But common sense says that legitimacy must also be perceived by the
people doing the work.
b) Explain test case design in detail. 4M
Ans. The design of tests for software and other engineered products can be
as challenging as the initial design of the product itself. Yet,software
engineers often treat testing as an afterthought, developing test cases
that may "feel right" but have little assurance of being complete.
Recalling the objectives of testing, we must design tests that have the
highest likelihood of finding the most errors with a minimum amount Explana
of time and effort. tion4M
A rich variety of test case design methods have evolved for software.
Page 20/34
(Autonomous)
MODEL ANSWER
These methods provide the developer with a systematic approach to

testing. More important, methods provide a mechanism that can help
to ensure the completeness of tests and provide the highest likelihood
for uncovering errors in software.
Any engineered product (and most other things) can be tested in one
of two ways:
(1) Knowing the specified function that a product has been designed to
perform, tests can be conducted that demonstrate each function is fully
operational while at the same time searching for errors in each
function;
(2) Knowing the internal workings of a product, tests can be
conducted to ensure that "all gears mesh," that is, internal operations
are performed according to specifications and all internal components
have been adequately exercised. The first test approach is called black-
box testing and the second, white-box testing.
c) Explain scenario based modeling in detail. 4M
(Note: Any other diagram such as use case or swin lane diagram can
also be given as example)
Ans. Analysis modeling with UML begins with the creation of scenarios. In
scenario Based Modeling the system is represented in user point of Listing
view. Scenario based elements are various
1. Use case diagram scenario
2. Activity diagram based
3. Swim lanes diagram model
1M
Step 1:First of all, identify the tasks in the project.
Step 2:You can add more information to the task boxes, such as who is
doing the task and the timeframes. You can add this information inside
the box or can add it somewhere near the box.
Step 3: Now, arrange the boxes in the sequence that they are
performed during the project execution. The early tasks will be at the
left hand side and the tasks performed at the later part of the project
execution will be at the right hand side. The tasks that can be
performed in parallel should be kept parallel to each other
(vertically).You may have to adjust the sequence a number of times
until you get it right. This is why software is an easy tool for creating
activity diagrams.
Page 21/34
(Autonomous)
MODEL ANSWER
Step 4:Now, use arrows to join task boxes. These arrows will show the
sequence of the tasks. Sometimes, a 'start' and an 'end' box can be
added to clearly present the start and the end of the project.
Example of activity diagram:Activity diagramfor Access camera

surveillancedisplay camera views function
The activity diagram is shown for the Function named Access Camera
Surveillance-Display Camera Views. The flowof the system is shown
in the diagram
3M for
drawing
the
diagram
and
explaini
ng
Page 22/34
(Autonomous)
MODEL ANSWER
d) What is meant by software deployment? 4M

Ans. Software Deployment:
The deployment phase includes 3 actions namely 1. Delivery 2.
Support 3. Feedback
1. The delivery cycle provides the customer and the end user with an
operational software increment that provides usable functions and Any
features. four
2. The support cycle provides documentation, human assistance for principle
all functions and features introduced during all deployment cycles 1M each
to date.
3. Each feedback cycle provides the software team with useful
inputs. The feedback can help in modifications to the functions,
features and even the approach for the next increments.
The delivery of the software increment is an important milestone of
any software project. A number of key principles should be followed
as the team prepares to deliver an increment.
1. Customer expectations for the software must be managed
Before the software delivery the project team should ensure that all
the requirements of the users are satisfied.
2. A complete delivery package should be assembled and tested
The system containing all executable software, support data files,
tools and support documents should be provided with beta testing at
the actual user side.
3. A support regime must be established before the software is
delivered
This includes assigning the responsibility to the team members to
provide support to the users in case of problem.
4. Appropriate instructional materials must be provided to end
users
At the end of construction various documents such as technical
manual, operations manual, user training manual, user reference
manual should be kept ready. These documents will help in providing
proper understanding and assistance to the user.
5. Buggy software should be fixed first, delivered later.
Sometimes under time pressure, the software delivers low-quality
increments with a warning to the customer that bugs will be fixed in
the next release. Customers will forget you delivered a high-quality
Page 23/34
(Autonomous)
MODEL ANSWER
product a few days late, but they will never forget the problems that a
low quality product caused them. The software reminds them every
day.
e) What is SRS? 4M
Ans. A software requirements specification (SRS) is a complete
description of the behavior of the system to be developed. It includes
a set of use cases describe all of the interactions that the users will
have with the software. In addition to use cases, the SRS contains
functional requirements and non functional requirements. Functional
requirements define the internal workings of the software: that is, the SRS 4M
calculations, technical details, data manipulation and processing, and
other specific functionality that shows how the use cases are to be
satisfied. Non-functional requirements impose constraints on the
design or implementation (such as performance requirements, quality
standards, or design constraints).
The purpose of SRS document is providing a detailed overview of
software product, its parameters and goals. SRS document describes
the project's target audience and its user interface, hardware and
software requirements. It defines how client, team and audience see
the product and its functionality.
f) What is agile process? 4M
Ans. Agile programming is an approach to project management,
typically used in software development. It helps teams react to Explaini
the instability of building software through incremental, iterative ng agile
work cycles, known as sprints. process
2M
Features of the Agile Software Development Approach:
The name ―agile software process, first originated in Japan. The
Japanese faced competitive pressures, and many of their
companies, like their American counterparts, promoted cycle-time
reduction as the most important characteristic of software Features
process improvement efforts of agile
2M
Modularity
Modularity is a key element of any good process. Modularity
allows a process to be broken into components called activities.
A software development process prescribes a set of activities
capable of transforming the vision of the software system into reality.
Page 24/34
(Autonomous)
MODEL ANSWER
Iterative
Agile software processes acknowledge that we get things wrong
before we get them right. Therefore, theyfocus on short cycles.
Within each cycle, a certain set of activities is completed.
Time-Bound
Iterations become the perfect unit for planning the software
development project. We can set time limits (between one and six
weeks is normal) on each iteration and schedule them
accordingly.
Parsimony
Agile Process is more than a traditional software development
process with some time constraints. Attempting to create
impossible deadlines under a process not suited for rapid
delivery puts the onus on the software developers. This leads to
burnout and poor quality Instead, agile software processes focus
on parsimony. That is, they require a minimal number of activities
necessary to mitigate risks and achieve their goals.
Adaptive
During an iteration, new risks may be exposed which require
some activities that were not planned. The agile process adapts the
process to attack these new found risks. If the goal cannot be
achieved using the activities planned during the iteration, new
activities can be added to allow the goal to be reached. Similarly,
activities may be discarded if the risks turn out to be ungrounded.
Incremental
An agile process does not try to build the entire system at once.
Instead, it partitions the nontrivial system into increments which may
be developed in parallel, at different times, and at different rates.
Convergent
Convergence states that we are actively attacking all of the
risks worth attacking. As a result, the system becomes closer to the
reality that we seek with each iteration.
People-Oriented
Agile processes favor people over process and technology.
They evolve through adaptation in an organic manner. Developers
Page 25/34
(Autonomous)
MODEL ANSWER
that are empowered raise their productivity, quality, and performance.
Collaborative
Agile processes foster communication among team members.
Communication is a vital part of any software development
project. When a project is developed in pieces, understanding
how the pieces fit together is vital to creating the finished product.
5. Attempt any TWO of the following: 16
a) Explain RAD model with its advantages and disadvantages. 8M
Ans. The RAD Model:
Diagram
2M
Rapid Application Development (RAD) is a modern software process

model that emphasizes a short development cycle. The RAD Model
is a “high-speed” adaptation of the waterfall model, in which rapid
development is achieved by using a component based construction
approach. If requirements are well understood and project scope is
considered, the RAD process enables a development team to create a
“Fully Functional System” within a very short period of time (e.g. 60
to 90 days).
One of the distinct features of RAD model is the possibility of cross
life cycle activities which will be assigned to teams, teams #1 to team
Page 26/34
(Autonomous)
MODEL ANSWER
#n leading to each module getting developed almost simultaneously.

This approach is very useful if the business application requirements
are modularized as function to be completed by individual teams and
finally to integrate into a complete system. As such compared to
waterfall model the team will be of larger size to function with proper
coordination. Descript
ion 2M
RAD model distributes the analysis and construction phases into a
series of short iterative development cycles. The activities of each
phase per team are Business modeling, Data modeling and process
modeling.
This model is useful for projects with possibility of modularization.
RAD may fail if modularization is difficult. This model should be
used if domain experts are available with relevant business
knowledge.
Advantages:
1. Changing requirements can be accommodated and progress can
be measured.
2. Powerful RAD tools can reduce development time.
3. Productivity with small team in short development time and quick Advanta
reviews, risk control increases reusability of components, better ges 2M
quality.
4. Due to risks in new approach only modularized systems are
recommended through RAD.
5. Suitable for scalable component based systems.
Disadvantages:
1. Success of RAD model depends on strong technical team
expertise and skills.
2. Highly skilled developers needed with modeling skills.
3. User involvement throughout life cycle. If developers &customers Disadva
are not committed to the rapid fire activities necessary to ntage
complete the System in a much-abbreviated time frame, RAD 2M
projects will fail.
4. May not be appropriate for very large scale systems where the
technical risks are high.
b) Describe in detail eight principles of good planning. 8M
Ans. Principle 1. Understand the scope of the project. It’s impossible to
use a road map if you don’t know where you’re going. Scope
Page 27/34
(Autonomous)
MODEL ANSWER
provides the software team with a destination.

Principle 2. Involve stakeholders in the planning activity.
Stakeholders define priorities and establish project constraints. To
accommodate these realities, software engineers must often negotiate
order of delivery, time lines, and other project-related issues. Any 8
Principle 3. Recognize that planning is iterative. A project plan is principle
never engraved in stone. As work begins, it is very likely that things s with
will change. As a consequence, the plan must be adjusted to descripti
accommodate these changes. In addition, iterative, incremental on 1M
process models dictate re-planning after the delivery of each software each
increment based on feedback received from users.
Principle 4. Estimate based on what you know. The intent of
estimation is to provide an indication of effort, cost, and task
duration, based on the team’s current understanding of the work to be
done. If information is vague or unreliable, estimates will be equally
unreliable.
Principle 5. Consider risk as you define the plan. If you have
identified risks that have high impact and high probability,
contingency planning is necessary. In addition, the project plan
(including the schedule) should be adjusted to accommodate the
likelihood that one or more of these risks will occur.
Principle 6. Be realistic. People don’t work 100 percent of every
day. Noise always enters into any human communication. Omissions
and ambiguity are facts of life. Change will occur. Even the best
software engineers make mistakes. These and other realities should
be considered as a project plan is established.
Principle 7. Adjust granularity as you define the plan. Granularity
refers to the level of detail that is introduced as a project plan is
developed. A “high-granularity” plan provides significant work task
detail that is planned over relatively short time increments (so that
tracking and control occur frequently). A “low-granularity” plan
provides broader work tasks that are planned over longer time
periods. In general granularity moves from high to low as the project
time line moves away from the current date. Over the next few weeks
or months, the project can be planned in significant detail. Activities
that won’t occur for many months do not require high granularity (too
much can change).
Principle 8. Define how you intend to ensure quality. The plan
should identify how the software team intends to ensure quality. If
Page 28/34
(Autonomous)
MODEL ANSWER
technical reviews are to be conducted, they should be scheduled. If

pair programming is to be used during construction, it should be
explicitly defined within the plan.
Principle 9. Describe how you intend to accommodate change.
Even the best planning can be obviated by uncontrolled change. You
should identify how changes are to be accommodated as software
engineering work proceeds. For example, can the customer request a
change at any time? If a change is requested, is the team obliged to
implement it immediately? How is the impact and cost of the change
assessed?
Principle 10. Track the plan frequently and make adjustments as
required. Software projects fall behind schedule one day at a time.
Therefore, it makes sense to track progress on a daily basis, looking
for problem areas and situations in which scheduled work does not
conform to actual work conducted. When slippage is encountered, the
plan is adjusted accordingly.
c) What is philosophy of six sigma? Explain Six sigma strategies. 8M
Ans. Six Sigma is the most widely used strategy for statistical quality
assurance in industry today. Originally popularized by Motorola in
the 1980s, the Six Sigma strategy “is a rigorous and disciplined Remark
methodology that uses data and statistical analysis to measure and Descript
improve a company’s operational performance by identifying and ion 2M
eliminating defects’ in manufacturing and service-related processes”.
The term Six Sigma is derived from six standard deviations instances
(defects) per million occurrences—implying an extremely high
quality standard. The Six Sigma methodology defines three core
steps:
• Define customer requirements and deliverables and project goals
via well-defined methods of customer communication.
• Measure the existing process and its output to determine current DMADV
quality performance (collect defect metrics). 3M
• Analyze defect metrics and determine the vital few causes.
If an existing software process is in place, but improvement is

required, Six Sigma suggests two additional steps:
• Improve the process by eliminating the root causes of defects.
• Control the process to ensure that future work does not reintroduce
the causes of defects.
These core and additional steps are sometimes referred to as the
Page 29/34
(Autonomous)
MODEL ANSWER
DMAIC (define,measure, analyze, improve, and control) method.

If an organization is developing a software process (rather than
improving an existing process), the core steps are augmented as
follows:
• Design the process to
a. a) Avoid the root causes of defects and DMAIC
b. b) To meet customer requirements. 3M
• Verify that the process model will, in fact, avoid defects and meet
customerrequirements.
This variation is sometimes called the DMADV (define, measure,
analyze, design, and verify) method.
a) Write meaning of PERT and CPM. 4M
Ans. PERT:
PERT stands for Program Evaluation Review Technique. PERT is a
project management technique, used to manage uncertain activities of
a project. It is a technique of planning and control of time. It focuses
of event. It is a probabilistic model. It is appropriate for high
precision time estimate. It manages Unpredictable Activities.PERT
chart represent another view of project. It does represent inter task PERT
relationships more effectively.Tasks and milestones are included in 2M
the chart symbols such as circles; squares are used to depict tasks and
milestone. Microsoft uses rectangles to represent task. Each task
rectangle is divided into sections with task name at the top and task-
id/duration in the middle.
CPM:
CPM stands for critical path method. A project of any kind involves a
number of activities. Some of them are interdependent while others
are independent. It is important that project management should
effectively plan, schedule, co-ordinate and optimize the activities of
the various participants in the project. There are certain activities CPM
which are to be completed within the stipulated time. If those critical 2M
activities are not completed within the prescribed time line, the
completion of the whole project is hampered.
If the project is quite large effective control over all the activities is
difficult. To control such projects, Network techniques have been
developed.
Page 30/34
(Autonomous)
MODEL ANSWER
b) Explain the steps of bottom up integration. 4M

Ans. Bottom-Up integration:
This begins with the construction a test of small modules. The
components are integrated from the bottom-up, the functionally
provided by components subordinate to a given level is always Each
available and the need for stubs is eliminated. A bottom-up step 1M
integration strategy may be implemented with the following steps: with
1. Low-level components are combined into clusters that perform a diagram
specific software sub-function.
2. A driver is written to coordinate test case input and output.
3. The cluster is tested
4. Drivers are removed and clusters are combined moving upward in
the program structure.
c) List the objective of black box testing. 4M

Ans.
1. Black-box tests are used to demonstrate that software functions
are operational
2. Input is properly accepted and output is correctly produced, 1M for
3. The integrity of external information (e.g., a database) is each
maintained. objective
4. A black-box test examines some fundamental aspect of a system
with little regard for the internal logical structure of the software.
Page 31/34
(Autonomous)
MODEL ANSWER
d) For library management system draw level 0 and level 1 DFD. 4M

(Note: Any other diagram also shall be considered
Ans.
Level 0
2M
DFD Level 0 for Library Management System
Level 1
2M
DFD Level 1 for Library Management System
Page 32/34
(Autonomous)
MODEL ANSWER
e) What are the characteristics of good design. 4M

Ans. Design Process:
Software design is an iterative process through which requirements
are translated into a “blueprint” for constructing the software. The
design is representation at a high level of abstraction – data, 1M for
functional, and behavioral requirements. As design iterations occur, Design
subsequent refinement leads to design representations at much lower Process
levels of abstraction.
There are three characteristics that serve as a guide for the evaluation
of a good design:
1. The design must implement all the explicit requirements
contained in the requirements model, and it must accommodate 3Mfor
all the implicit requirements desired by stakeholders. characte
ristics
2. The design must be a readable, understandable guide for those
who generate code and for those who test and subsequently
support the software.
3. The design should provide a complete picture of the software,
addressing the data, functional and behavioral domains for
implementation.
f) State advantages of PSP and TSP. 4M
Ans. PSP Advantages: -
1. PSP represents a disciplined, metrics-based approach to software
engineering. Any 2
2. PSP resulting improvement in software engineering productivity PSP
and software quality are significant. Advanta
3. It helps the software engineers in developing high quality ges 2M
software products.
4. It guides the engineer for personal improvement.
5. It gives the confidence to do the job the way you know you
should.
6. The PSP gives the command over your work.
TSP Advantages: - Any 2
1. Defines roles and responsibilities for each team member. Advanta
ges TSP
2. Track quantitative project data.
2M
3. Identifies a team process that is appropriate for the project and a
Page 33/34
(Autonomous)
MODEL ANSWER
strategy for implementing the process;

4. Defines local standards that are applicable to the team’s software
engineering work;
5. Continually assesses risk and reacts to it;
6. Tracks, manages, and reports project status.
Page 34/34

2017 Summer Model Answer Paper

Uploaded by

Copyright:

Available Formats

2017 Summer Model Answer Paper

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

2017 Summer Model Answer Paper

Uploaded by

Copyright:

Available Formats

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION

Important Instructions to examiners:

Q. Sub Answer Marking

Embedded software: Intelligent products have become

of their team and the Sprint Backlog; no work should be done

1. The Reason It All Exists

understand your system. So, always specify, design, and implement

d) Write importance of analysis modelling. 4M

possible. The software should be able to recover well from changes

g) List various activities of SQA. 4M

SQA Activities: (Any 4-6 activities accepted)

Software Quality Control (SQC) is a set of activities for ensuring

b) Explain following terms w.r.t. risk management: 4M

(ii) Risk analysis

The Debugging Process Definitio

- Is each component of the solution correct? Has the design and

Construction activity combines code generation and the testing.

Fig. softwareprocess framework

1) A common process framework is established by defining a small

and occur throughout the process.

detailed information flow e.g. level 0, level 1, level 2 etc.

d) How can project scheduling affect Integration testing? 4M

Therefore, an incremental software paradigm is chosen and a

Individual tasks and subtasks have interdependencies based on their

A task network, also called an activity network, is a graphic

The concurrent nature of software engineering activities leads to a

These questions lead us to the definition of five SCM tasks:

Aggressive (read "unrealistic") deadlines are a fact of life in the

Sometimes such deadlines are demanded for reasons that are

These methods provide the developer with a systematic approach to

Example of activity diagram:Activity diagramfor Access camera

d) What is meant by software deployment? 4M

that are empowered raise their productivity, quality, and performance.

Rapid Application Development (RAD) is a modern software process

#n leading to each module getting developed almost simultaneously.

provides the software team with a destination.

technical reviews are to be conducted, they should be scheduled. If

If an existing software process is in place, but improvement is

DMAIC (define,measure, analyze, improve, and control) method.

b) Explain the steps of bottom up integration. 4M

c) List the objective of black box testing. 4M

d) For library management system draw level 0 and level 1 DFD. 4M

DFD Level 0 for Library Management System

DFD Level 1 for Library Management System

e) What are the characteristics of good design. 4M

strategy for implementing the process;

You might also like