(s14)
(s14)
(s14)
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Page 1 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Page 2 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Page 3 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
These elements include the organizational structure, procedures, processes, and resources
needed to implement quality planning, quality control, quality assurance, and quality
improvement.
However, ISO 9000 does not describe how an organization should implement these quality
system elements. Consequently, the challenge lies in designing and implementing a quality
assurance system that meets the standard and fits the company’s products, services, and
culture.
The ISO 9001 Standard ISO 9001 is the quality assurance standard that applies to software
engineering.
The standard contains 20 requirements that must be present for an effective quality assurance
system.
Because the ISO 9001 standard is applicable to all engineering disciplines, a special set of
ISO guidelines (ISO 9000-3) have been developed to help interpret the standard for use in the
software process.
The requirements delineated by ISO 9001 address topics such as management responsibility,
quality system, contract review, design control, document and data control, product
identification and traceability, process control, inspection and testing, corrective and
preventive action, control of quality records, internal quality audits, training, servicing, and
statistical techniques.
In order for a software organization to become registered to ISO 9001, it must establish
policies and procedures to address each of the requirements just noted (and others) and then
be able to demonstrate that these policies and procedures are being followed.
Page 4 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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 ―straw man 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.
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.
Page 5 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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.
Page 6 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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.
a) Describe a simple DFD for cash withdrawal by an account holder from saving Bank.
OR
Page 7 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Page 8 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
– Incorrect output is easily identified.
– 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.
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 specific and detailed.
– Technical documentation is accurate
Controllability
Page 9 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
– ―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 specified, automated, and reproduced.
c) State decomposition technique and list its types. Explain one type in detail.
(Definition – 1 Mark, Type -1 mark, Description -2 Marks)
Ans: Three different points of view for the decomposition approach Software Sizing, Decomposition of
the problem, and Decomposition of the process.
1. Software Sizing
– Size refers to a quantifiable outcome of the software project.
– If a direct approach is taken, size can be measured in LOC.
– 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:
Page 10 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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.
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 complexity 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.
Page 11 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
d) Describe the failure curve for software and list any four software characteristics
(Failure curve – 1 Mark, Description -1 Mark, list- 2 Marks)
Ans:
The failure rate curve for software should take the form of the ―idealized curve‖ shown in Figure
Undiscovered defects will cause high failure rates early in the life of a program. However, these
are corrected (ideally, without introducing other errors) and the curve flattens as shown. The
idealized curve is a gross oversimplification of actual failure models for software. However, the
implication is clear—software doesn't wear out. But it does deteriorate! This seeming
contradiction can best be explained by considering the ―actual curve‖ shown in Figure.
During its life, software will undergo change (maintenance). As changes are made, it is likely
that some new defects will be introduced, causing the failure rate curve to spike as shown in
Figure. Before the curve can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to
rise—the software is deteriorating due to change.
Following are the characteristics of Software
1. Software is developed or engineered; it is not manufactured in the classical sense.
2. Software doesn't "wear out‖.
3. Although the industry is moving toward component-based assembly, most software continues
to be custom built.
Page 12 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Page 13 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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 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.
Page 14 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Initially, system engineering defines the role of software and leads to software requirements
analysis, where the information domain, function, behavior, performance, constraints, and
validation criteria for software are established. Moving inward along the spiral, we come to
design and finally to coding. To develop computer software, we spiral inward along streamlines
that decrease the level of abstraction on each turn.
A strategy for software testing may also be viewed in the context of the spiral (Figure). Unit
testing begins at the vortex of the spiral and concentrates on each unit (i.e., component) of the
software as implemented in source code. Testing progresses by moving outward along the spiral
to integration testing, where the focus is on design and the construction of the software
architecture. Taking another turn outward on the spiral, we encounter validation testing, where
requirements established as part of software requirements analysis are validated against the
software that has been constructed. Finally, we arrive at system testing, where the software and
other system elements are tested as a whole. To test computer software, we spiral out along
streamlines that broaden the scope of testing with each turn.
Considering the process from a procedural point of view, testing within the context of software
engineering is actually a series of four steps that are implemented sequentially. The steps are
shown in Figure. Initially, tests focus on each component individually, ensuring that it functions
properly as a unit. Hence, the name unit testing. Unit testing makes heavy use of white-box
testing techniques, exercising specific paths in a module's control structure to ensure complete
coverage and maximum error detection. Next, components must be assembled or integrated to
form the complete software package. Integration testing addresses the issues associated with the
Page 15 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
dual problems of verification and program construction. Black-box test case design techniques are
the most prevalent during integration, although a limited amount of white-box testing may be
used to ensure coverage of major control paths. After the software has been integrated
(constructed), a set of high-order tests are conducted. Validation criteria (established during
requirements analysis) must be tested. Validation testing provides final assurance that software
meets all functional, behavioral, and performance requirements. Black-box testing techniques are
used exclusively during validation.
The last high-order testing step falls outside the boundary of software engineering and into the
broader context of computer system engineering. Software, once validated, must be combined
with other system elements (e.g., hardware, people, databases). System testing verifies that all
elements mesh properly and that overall system function/performance is achieved.
Page 16 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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.
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.
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.
The daily frequency of testing the entire product may surprise some readers. However,
frequent tests give both managers and practitioners a realistic assessment of integration testing
progress. McConnell describes the smoke test in the following manner:
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:
Integration risk is minimized. Because smoke tests are conducted daily, incompatibilities and
other show-stopper errors are uncovered early, thereby reducing the likelihood of serious
schedule impact when errors are uncovered. The quality of the end-product is improved.
Because the approach is construction (integration) oriented, smoke testing is likely to uncover
both functional errors and architectural and component-level design defects. If these defects
are corrected early, better product quality will result.
Error diagnosis and correction are simplified. Like all integration testing approaches, errors
uncovered during smoke testing are likely to be associated with ―new software increments‖—
that is, the software that has just been added to the build(s) is a probable cause of a newly
discovered error.
Progress is easier to assess. With each passing day, more of the software has been integrated
and more has been demonstrated to work. This improves team morale and gives managers a
good indication that progress is being made.
Page 17 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
c) Describe relationship between effort and delivery time using a graph in project scheduling.
(Relationship between effort and delivery- 2 Marks; Any relevant example- 2 Marks)
Ans: The relationship between effort and delivery time using graph in project scheduling gives
amount of efforts to be put-in to complete the task so that the deadline can be met.
Usually the project manager draws a graph where each node defines distinct activity and then
these activities given some duration depending on the deadline of a project. The project manager
keeps on verifying the progress of the project.
Consider following example:
As shown in above diagram there are various nodes / tasks assigned to various teams; each of the
node has its own duration and the dependency amongst two task /nodes. Whenever any task lags
behind the prescribed schedule then extra efforts can be given to ensure that the work can be
completed in given period of time.
Page 18 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
2. Changing customer requirements that are not reflected in schedule changes.
3. An honest underestimate of the amount of effort and/or the number of resources that will
be required to do the job.
4. Predictable and/or unpredictable risks that were not considered when the project
commenced.
5. Technical difficulties that could not have been foreseen in advance.
6. Human difficulties that could not have been foreseen in advance.
7. Miscommunication among project staff that results in delays.
8. A failure by project management to recognize that the project is falling behind schedule
and a lack of action to correct the problem.
Page 19 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Review software engineering activities to verify compliance with the defined software
process. The SQA group identifies, documents, and tracks deviations from the process and
verifies that corrections have been made.
Audits designated software work products to verify compliance with those defined as part of
the software process. The SQA group reviews selected work products; identifies, documents,
and tracks deviations; verifies that corrections have been made; and periodically reports the
results of its work to the project manager.
Ensure that deviations in software work and work products are documented and handled
according to a documented procedure. Deviations may be encountered in the project plan,
process description, applicable standards, or technical work products.
Records any noncompliance and reports to senior management. Noncompliance items are
tracked until they are resolved.
Page 20 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
o Empirical estimation models can be used to complement decomposition techniques and offer
a potentially valuable estimation approach in their own right. A model is based on experience
(historical data) and takes the form.
Ans: An automated debugging is a process of debugging the system / module automatically. In such
debugging methods the software tester writes a debugging scripts/code and this code can be use
repetitively to test similar module.
The script can be executed number of times to get the better accuracy and precision. The best part
of automated debugging is that it is done by computer itself with the logic being provided by the
tester. It is time saving and ensures that more number of modules can be tested in given time.
Ans: The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model, each
phase must be completed fully before the next phase can begin. At the end of each phase, a
review takes place to determine if the project is on the right path and whether or not to continue or
discard the project. In waterfall model phases do not overlap.
Page 21 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Page 22 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Advantages of waterfall model:
Simple and easy to understand and use.
Easy to manage due to the rigidity of the model – each phase has specific deliverables and a
review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Disadvantages of waterfall model:
Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing.
d) Differentiate any four points differentiate between Black box and White box testing.
(Each difference-1 Mark for)
Ans:
Criteria Black Box Testing White Box Testing
Definition Black Box Testing is a software White Box Testing is a software
testing method in which the testing method in which the
internal structure/design/ internal structure/ design/
implementation of the item implementation of the item
being tested is NOT known to being tested is known to the
the tester tester.
Levels Applicable To Mainly applicable to higher Mainly applicable to lower
levels of testing: levels of testing:
Acceptance Testing Unit Testing
System Testing Integration Testing
Responsibility Generally independent Generally Software Developers
Software Testers
Programming Not Required Required
Knowledge
Implementation Not Required Required
Knowledge
Page 23 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Basis for Test Cases Requirement Specifications Detail Design
Ans: The personal software Process (PSP) emphasizes personal measurements of both the work
product that is produced and the resultant quality of the work. In order to change ineffective
personal process, an individual must go through phases, each requiring training and careful
Page 24 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
instrumentation. In addition PSP makes the practitioner responsible for project planning and
empowers to control the quality of software product.
PSP model defines following five frame work activities:
Planning- isolates requirements, develops size and resource estimates. Tests are identified and
project schedule is created.
High level design: External specification for each component to be constructed is developed and
a component design is created.
High level design review: formal verification methods are applied to uncover errors in the
design.
Development: component level design is refined and reviewed. Code is generated, reviewed,
compiled and tested.
Post-mortem: Using measures and matrix collected, the effectiveness of the process is
determined. They provide guidance for improvement.
Page 25 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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 diagram for Access camera surveillance—display camera views function
The activity diagram is shown for the Function named Access Camera Surveillance- Display
Camera Views. The flow of the system is shown in the diagram.
Page 26 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
Page 27 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
1. Prototype Model:
a. Customers may press for immediate delivery of working but inefficient products
b. The developer often makes implementation compromises in order to get a prototype working
quickly.
c. Most helpful when developer is not sure of the efficiency of an algorithm and the adaptability
of an operating system.
d. Customer is unaware of detailed input, processing or output requirement.
e. Developer and customer determine objectives and draft requirements
f. Prototype quickly produced and evaluated by customer
g. Prototype then refined, and re-evaluated
h. Process iterated, before final product development
i. Advantages: Customer participation and better requirements
Page 28 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
2. Spiral model
Page 29 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
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 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 30 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
B F G
Page 31 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
4. Custom or 'Bespoke' software, is software which has been made for a specific job that software
off the shelf could not do.
5. Such software is usually made for a specific company to meet their requirements. It is not
usually made to be sold on the mass market.
Page 32 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
1. Define the risk referent levels for the project.
2. Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels.
3. Predict the set of referent points that define a region of termination, bounded by a curve or
areas of uncertainty.
4. Try to predict how compound combinations of risks will affect a referent level.
Page 33 of 34
MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2005 Certified)
SUMMER – 14 EXAMINATION
Subject Code: 12175 Model Answer Subject Name: Software Engineering
____________________________________________________________________________________________________
e) Justify why testing is also termed as a quality control measure.
(Each Point-1 Mark (Any Four))
(Any relevant description shall be considered)
Ans:
o Quality Control describes the directed use of testing to measure the achievement of a
specified standard. Quality control is a use of testing. Quality control is a superset of testing,
although it often used synonymously with testing. Roughly, you test to see if something is
broken, and with quality control you set limits that say, in effect, if this particular stuff is
broken then whatever you’re testing fails.
o For quality control to be effective, you must test the same things the same way every time you
test. When you change your tests, your results become inconsistent. You need a test plan.
o A test plan is simply a high-level summary of the areas (functionality, elements, regions, etc.)
You will test, how frequently you will test them, and where in the development or publication
process you will test them. A test plan also needs an estimate of the duration of testing, and
statement of any required resources.
o The major phases of a web site need test plans, because the focus and emphasis of testing will
change over time. Testing a new site in development is very different from testing a site that
has been up and running for some time. Furthermore, any changes to the website code,
incremental of major, require regression test plans.
Page 34 of 34