CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

UNIT I SOFTWARE PROCESS AND AGILE DEVELOPMENT

Introduction to Software Engineering, Software Process, Perspective and Specialized Process

Models –Introduction to Agility-Agile Process-Extreme programming-XP Process-Case Study.

PART A
1. What is software engineering? (Nov /Dec 2013) (Or) Write the IEEE definition of
software engineering. ( Nov /Dec 2017) Define: Software Engineering. (April/May 2019)
The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of engineering to software.

2. What is Software? (Apr/May 2018)

Software is nothing but a collection of computer programs that are related documents that
are indented to provide desired features, functionalities and better Performance.

3. What are the characteristics of the software? (Apr/May 2018, Nov2018)

 Software is engineered, not manufactured.
 Software does not wear out.
 Most software is custom built rather than being assembled from components.

4. What are the various categories of software? (Apr/May 2021)

 System software
 Application software
 Engineering/Scientific software
 Embedded software
 Web Applications
 Artificial Intelligence software

5. What are the challenges in software?

 Copying with legacy systems
 Heterogeneity challenge
 Delivery times challenge

6. What is a software process? (Nov/Dec 2019)

Software process is defined as the structured set of activities that are required to develop
the software system.
7. What are the fundamental activities of a software process?
 Specification
 Design and implementation
 Validation
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Evolution
8. What are the umbrella activities of a software process? (Nov/Dec 2018)
 Software project tracking and control.
 Risk management.
 Software Quality Assurance.
 Formal Technical Reviews.
 Software Configuration Management.
 Work product preparation and production.
 Reusability management.
 Measurement.

9. What are the merits of incremental model?

 The incremental model can be adopted when there are less number of people involved
in the project.
 Technical risks can be managed with each increment.
 For a very small time span, at least core product can be delivered to the customer.

10. List the task regions in the Spiral model.

 Customer communication – In this region it is suggested to establish customer
communication.
 Planning – All planning activities are carried out in order to define resources timeline
and other project related activities.
 Risk analysis – The tasks required to calculate technical and management risks.
 Engineering – In this the task region, tasks required to build one or more representations
of applications are carried out.
 Construct and release – All the necessary tasks required to construct, test, install the
applications are conducted.
 Customer evaluation – Customer’s feedback is obtained and based on the customer
evaluation required tasks are performed and implemented at installation stage.

11. What are the drawbacks of spiral model?

 It is based on customer communication. If the communication is not proper, then the
software product that gets developed will not be the up to the mark.
 It demands considerable risk assessment. If the risk assessment is done properly then only
the successful product can be obtained.

12. List the process maturity levels in SEIs CMM.

 Level 1: Initial – Few processes are defined and individual efforts are taken.
 Level 2: Repeatable – To track cost schedule and functionality basic project
management processes are established.
 Level 3: Defined – The process is standardized, documented and followed.
 Level 4: Managed – Both the software process and product are quantitatively understood
and controlled using detailed measures.
 Level 5: Optimizing – Establish mechanisms to plan and implement change.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

13. What is the use of CMM?

Capability Maturity Model is used in assessing how well an organization’s processes allow
to complete and manage new software projects.

14. Name the Evolutionary Process Models.

 Incremental model
 Spiral model
 WIN-WIN spiral model
 Concurrent Development

15. Define software prototyping.

Software prototyping is defined as a rapid software development for validating the
requirements.
The two approaches in software prototyping are,
 Evolutionary prototyping – In this approach of system development, the initial prototype
is prepared and it is then refined through number of stages to final stage.
 Throw-away prototyping – Using this approach a rough practical implementation of the
system is produced. The requirement problems can be identified from this implementation.

16. What are the benefits of prototyping?

 Prototype serves as a basis for deriving system specification.
 Design quality can be improved.
 System can be maintained easily.
 Development efforts may get reduced.
 System usability can be improved.

17. What are the advantages of evolutionary prototyping?

 Fast delivery of the working system.
 User is involved while developing the system.
 More useful system can be delivered.
 Specification, design and implementation work in co-coordinated manner.

18. What are the various Rapid prototyping techniques?

 Dynamic high level language development.
 Database programming.
 Component and application assembly.

19. Write down the generic framework that is applicable to any software project. (Or) List out
the five activities of a generic process framework for software engineering. (Nov/Dec 2021)
 Communication
 Planning
 Modeling
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Construction
 Development

20. List the goals of software engineering. (Apr/May 2021)

The primary goal of software engineering is to improve the quality of software products
and to increase the productivity and job satisfaction of software engineers.

21. What are the two types of software products?

(1) Application software is the general designation of computer programs for performing
user tasks. Application software may be general purpose (word processing, web browsers
...) or have a specific purpose (accounting, truck scheduling...). Application software
contrast with
(2) System software is a generic term referring to the computer programs used to start and
run computer systems and networks.

22. Is it always possible to realize the win-win spiral model for Software? Justify.
No, In reality customer and developers undergo through the process of negotiation.
Successful negotiation occurs when both the sides WIN.
 Customer’s WIN means- Obtaining the system that satisfies most of the needs.
 Developer’s WIN means- Getting the work done with realistic and achievable
budgets and deadlines.

In WIN-WIN spiral model negotiation activities are carried out at the beginning of each pass
of the spiral.

23. What is the potential advantage of adhering to life cycle models of software?
The primary goal of life cycle model is to develop software in a systematic and
disciplined manner.

24. Software doesn't wear out. Justify. (Nov/Dec 2013)

Software is not susceptible to the environmental maladies that cause hardware to wear out.
In theory, therefore, 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.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

25. Define Software measure.

A Software measure is a mapping from a set of objects in the software engineering world
into a set of mathematical constructs such as numbers or vector of numbers.

26. What is meant by software measurement?

A software measurement is a technique or method that applies software measures to a class
of software engineering objects to achieve a predefined goal.

27. List out the characteristics of software measurement.

The characteristics of software measurement are :
 Object of measurement ranging from products to processes
 Purpose of measurement such as characterization, assessment, evaluation,
prediction.
 Source of measurement such as software designers, software testers, and software
managers.
 Measured property such as software, reliability, maintainability, size, portability.
 Context of measurement.

28. What is PSP?

The personal software process emphasizes personal measurement of both the work product that
is produced and the resultant quality of the work product.
29. What are the Advantages of spiral model?
 It is realistic and typifies most software development products/projects. Most
software is evolutionary in nature and this model captures that nature.
 It combines the best features of prototyping as a means of eliciting feedback. The
phases resemble the Waterfall Model.
 It strikes a good balance mechanism for early problem identification and correction
while not missing out proactive problem prevention

30. What are the Advantages of waterfall model?

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Simplicity
 Easier to line up the resources with the appropriate skill sets

31. What are the Disadvantages of waterfall model?

 Highly impractical for most projects as very few projects can be divided into such
water-tight phases.
 This model could propagate defects to at least one phase following the point of
injection of the defect.
 This model is based on reactive error correction rather than proactive error prevention.

32. What is a life cycle model for a project?

 A life cycle model of a project describes the steps followed by the project team to
produce a tangible software product that fully meets the requirements of the component
or the part that the project set forth to build.

33. Define software project management.

 Software Project Management has key ideas about the planning, monitoring, and
control of software projects
34. Define project.
Project is a specific, finite task to be accomplished. Any activity that results in a
deliverable or a product. (or)
(1) A plan or proposal; a scheme
(2) An undertaking requiring concerted effort: a community cleanup project; a
government-funded irrigation project.
(3) An extensive task undertaken by a student or group of students to apply, illustrates, or
supplements classroom lessons.
(4) A housing project.
35. Define product.
Product:- "End Result."
Software products are outcomes of a software project. All the outputs that are produced
while the activities are being executed are the products (One of which is the final S/W)
1. Company designs product
2. Company with own views (based on market) develops product
3. End users are more than one
4. Never ending process 5.Customization is possible.

Eg: MicroSoft and their products like MS_Office, MS Visual Studio

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

36. What led to the transition from product oriented development to process oriented
development? May/June 2016
 During the last decade process oriented software quality management was considered the
successful paradigm of developing quality software.
 But the constant pace of change in the IT world brought up new challenges demanding
for a different model of software development.
 Product orientation is described as an alternative to process orientation, which is
specifically adapted to some of those new challenges.
 Both development models are adapted to different environments or development tasks.
 And they are based on different concepts of product quality and quality management.

37. Mention the characteristics of software contrasting it with characteristics of hardware.

(May/June 2016)
 Software is a general term used to describe a collection of computer programs, procedures,
and documentation that perform some task on a computer system.
 Practical computer systems divide software systems into three major classes: system
software, programming software, and application software, although the distinction is
arbitrary and often blurred.
 Software is an ordered sequence of instructions for changing the state of the computer
hardware in a particular sequence.
 Software is typically programmed with a user-friendly interface that allows humans to
interact more efficiently with a computer system.
 Hardware is best described as a device, such as a hard drive, that is physically connected
to the computer or something that can be physically touched.
 A CD-ROM, computer display monitor, printer, and video card are all examples of
computer hardware.
 Without any hardware, a computer would not function, and software would have nothing
to run on.
 Hardware and software interact with one another: software tells hardware which tasks it
needs to perform.

38. If you have to develop a word processing software product, what process models will
you chooses? (Nov/Dec 2016, Apr/May 2018)
 RAD (Rapid Application Development) model is used to develop a word processing
software product because it is needed to modify the previous version of word-processing
software.
 As Rapid Application Development is linear sequential software development process
model that emphasizes an extremely short development cycle.

39. Depict the relationship between Work product, task, activity and System. (Nov/Dec
2016, Apr/May 2017)
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 An activity strives to achieve a broad objective (e.g., communication with stakeholders)

and is applied regardless of the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be applied.
 A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.
 Work Product: Deliverables or outcome that must be produced to complete a project and
achieve its objectives.
 System: A set of principles or procedures according to which something is done; an
organized scheme or method.

40. Write the Process framework and Umbrella activities. (April/May 2015)
A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to all software
projects, regardless of their size or complexity. The process framework are:
 Software project tracking and control
 Risk management
 Software quality assurance
 A technical review—assesses software
 Measurement
 Software configuration management
 Reusability management
 Work product preparation and production
In addition, the process framework encompasses a set of umbrella activities that are
applicable across the entire software process. The umbrella activities are:
 Communication
 Planning
 Modeling
 Construction
 Deployment

41. What are the pros and cons of Iterative software development models? (Nov/Dec 2015)
Pros of Iterative Software development model:
 Potential defects are spotted and dealt with early
 Functional prototypes are developed early in the project life cycle
 Less time is spent on documenting and more on designing
 Progress is easily measured
 Changes to project scope are less costly and easier to implement
Cons of Iterative Software development model:
 More resources may be required
 Each successive phase is rigid with no overlaps
 The need for more intensive project management may be required
 It may be difficult to pin down an end date for the project conclusion
 Highly skilled talent is required for risk analysis
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

42. List two deficiencies in waterfall model. Which process model do you suggest to
overcome each deficiency?
 Real projects rarely follow a sequential flow. To overcome this, spiral model can be used.
 The customer has to state all requirements explicitly. To overcome this prototyping
model can be used.
 Working version of the program appears late in the project. To overcome this deficiency
RAD model can be used.

43. What is Agile software development?

Agile Software Development is a lightweight software engineering framework that

promotes iterative development throughout the life-cycle of the project, close collaboration
between the development team and business side, constant communication, and tightly-knit teams.
It promotes adaptive planning, evolutionary development and delivery, a time- boxed
iterative approach, and encourages rapid and flexible response to change and also known as agile
development.

44. Define Agility.

Agile --readiness for motion, nimbleness, activity, dexterity in motion.
Agility
Agility is dynamic, content specific, aggressively change embracing and growth
oriented.”

45. Define an Agile team.

 An agile team is a nimble team able to appropriately respond to changes.
 Changes in the software being built, changes to the team members, changes because
of new technology, changes of all kinds that may have an impact on the product
they build or the project that creates the product.
 An agile team recognizes that software is developed by individuals working in
teams and that the skills of these people, their ability to collaborate is at the core
for the success of the project.

46. State the Agile Manifesto.

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

47. State the agile principles.

 The highest priority of this process is to satisfy the customer.

 Acceptance of changing requirement even late in development.
 Frequently deliver working software in small time span.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Throughout the project business people and developers work together on daily basis. 
 Projects are created around motivated people if they are given the proper environment
and support.
 Face to face interaction is the most efficient method of moving information in the
development team. 
 Primary measure of progress is working software.
 Agile process helps in sustainable development.
 Continuous attention to technical excellence and good design increases agility. 
 From self organizing teams the best architecture, design and requirements are emerged. 
 Simplicity is necessary in development.

48. State the characteristics of Agile Software Development.

-- Light Weighted methodology
-- Small to medium sized teams
-- Vague and/or changing requirements
-- Vague and/or changing techniques
-- Simple design
-- Minimal system into production

49. State the advantages of the Agile Model.

 It is a very realistic approach to software development
 Promotes teamwork and cross training
 Functionality can be developed rapidly and demonstrated
 Resource requirements are minimum
 Suitable for fixed or changing requirements
 Delivers early partial working solutions
 Good model for environments that change steadily
 Minimal rules, documentation easily employed
 Enables concurrent development and delivery within an overall planned context
 Little or no planning required
 Easy to manage
 Gives flexibility to developers

50. What are all the disadvantages of the Agile Model?

 Not suitable for handling complex dependencies. 
 More risk of sustainability, maintainability and extensibility. 
 An overall plan, an agile leader and agile PM practice is a must without which it will not
work.
 Strict delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines. 
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Depends heavily on customer interaction, so if customer is not clear, team can be driven
in the wrong direction.

 There is a very high individual dependency, since there is minimum documentation

generated.
 Transfer of technology to new team members may be quite challenging due to lack of
documentation. 

51. What are the existing Agile Methods?

 Extreme Programming (“XP”) 
 Agile Unified Process
 Scrum

52. What are the processes of XP?

 Planning
 Design
 Coding and
 Testing

53. What do you mean by CRC?

CRC (class-responsibility collaborator) cards identify and organize the object-oriented classes
that are relevant to the current software increment.

54. Discuss about pair programming.

A key concept during the coding activity is pair programming. XP recommends that two
people work together at one computer workstation to create code for a story. This provides
a mechanism for real time problem solving and real-time quality assurance.

55. Draw the layered architecture of software engineering. (Nov/Dec 2018)

Software engineering is a layered technology. Any engineering approach (including software
engineering) must rest on an organizational commitment to quality.

 The bedrock that supports software engineering is a quality focus.

 The foundation for software engineering is the process layer.
 Software Process defines a framework that must be established for effective delivery of
software engineering technology.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Software engineering methods provide the technical how-to’s for building software.
56. State the difference between agile and waterfall (Traditional SDLC) methodology.

Agile Methodology Waterfall Methodology

Divides process into sprints Divides process into phases
Incremental approach Sequential approach
Flexible Well-structured and rigid
It is like a collection of several different The entire process is a part of one single
projects project
Allows making changes later on as well Almost impossible to make changes in the
later stages
Iterative approach as planning, designing, Planning, designing, prototyping,
prototyping, development, and testing is development, and testing is done just once.
done more than once.
Testing is carried out during the Testing is carried out after the build phase
development process

57. Comparison of Agile process with other SDLC models.

Features Agile Process Spiral Model RAD Model

Definition Agile process is the Spiral model is the RAD model is “high
ability to both create and Software speed adaptation of linear
respond to change development model sequential model, in
requirements of which focuses on which component based
software. managing risks. construction is used.

Adaptability yes yes no

Testing Phase Unit, Integration , Unit, Integration Unit
System testing and
System testing
Quality Factors yes yes no

Risk Analysis no yes no

Off-the- Tools no no yes

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Failure normally Code Code Architecture and design

due to

Knowledge Product and domain Product and domain Domain

Required
Entry & exit no no yes
Criteria
Mock up yes yes no

Extendability yes yes no

Project yes no yes

management
involvement
Higher yes yes no
Reliability
Time Boxing yes no yes

58. What are the advantages/merits and disadvantages/demerits of using formal methods
for developing a software? (Nov/Dec 2018)
Advantages/Merits:
1. Discovers ambiguity, incompleteness, and inconsistency in the software.
2. Offers defect-free software.
3. Incrementally grows in effective solution after each iteration.
4. This model does not involve high complexity rate.
5. Formal specification language semantics verify self-consistency.
Disadvantages/Demerits:
1. Time consuming and expensive.
2. Difficult to use this model as a communication mechanism for non technical personnel.
3. Extensive training is required since only few developers have the essential knowledge to
implement this model.

59. Define an evolutionary prototype. (Nov/Dec 2019)

 Evolutionary prototyping – In this approach of system development, the initial
prototype is prepared and it is then refined through number of stages to final stage.

60. List any two agile process models. (April/May 2019)

 Crystal
 Atern
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Feature-driven development
 Scrum
 Extreme programming (XP)
 Lean development
 Unified process

61. Draw the flow diagram of Iterative process flow and parallel flow. (Nov/Dec 2021)

PART B

1. What is Software Engineering? Briefly explain Software Process Framework. (Or)

List out the various umbrella activities which support software development process.
Discuss about their necessity in maintaining the quality in both software process and
product that is being developed for railway reservation system. (Nov/Dec 2017)

Introduction to Software Engineering

Software
Software is (1) instructions (computer programs) that when executed provide desired
function and performance, (2) data structures that enable the programs to adequately
manipulate information, and (3) documents that describe the operation and use of the programs.
Software Characteristics
 Software is developed or engineered; it is not manufactured in the classical sense.
 Software doesn't "wear out."
 Although the industry is moving toward component-based assembly, most software
continues to be custom built.
Software Applications
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 System software.
 Business software.
 Real-time software.
 Engineering and scientific software.
 Embedded software.
 Personal computer software.
 Web-based software.
 Artificial intelligence software.

Legacy Software
Legacy software systems were developed decades ago and have been continually modified
to meet changes in business requirements and computing platforms. The increase of such systems
is causing headaches for large organizations who find them costly to maintain and risky to evolve.
Software Engineering
The IEEE has developed a more comprehensive definition when it states: Software
Engineering:
(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to
software.
Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines.
Software engineering is a layered technology. Referring to Figure 1.1, any engineering approach
(including software engineering) must rest on an organizational commitment to quality.

Figure 1.1 – Software Engineering layers

 The bedrock that supports software engineering is a quality focus.

 The foundation for software engineering is the process layer. The software engineering
process is the glue that holds the technology layers together and enables rational and timely
development of computer software.
 Software Process defines a framework that must be established for effective delivery of
software engineering technology.
o The software process forms the basis for
 management control of software projects and establishes the
context in which technical methods are applied,
 work products (models, documents, data, reports, forms, etc.) are
produced,
 milestones are established, quality is ensured, and
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Change is properly managed.

 Software engineering methods provide the technical how-to’s for building software.
o Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
support.
o Software engineering methods rely on a set of basic principles that govern
each area of the technology and include modeling activities and other
descriptive techniques.
 Software engineering tools provide automated or semi-automated support for the process
and the methods. When tools are integrated so that information created by one tool can be
used by another, a system for the support of software development, called computer-aided
software engineering, is established.
Software Process
 A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created.
 An activity strives to achieve a broad objective (e.g., communication with stakeholders)
and is applied regardless of the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be applied.
 An action (e.g., architectural design) encompasses a set of tasks that produce a major work
product (e.g., an architectural design model).
 A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.
 A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.
 In addition, the process framework (Refer figure 1.2) encompasses a set of umbrella
activities that are applicable across the entire software process.

Software Process Framework

 A generic process framework for software engineering encompasses five activities:
 Communication. Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other stakeholders). The intent is
to understand stakeholders’ objectives for the project and to gather requirements that
help define software features and functions.
 Planning. A software project plan—defines the software engineering work by describing
the technical tasks to be conducted, the risks that are likely, the resources that will be
required, the work products to be produced, and a work schedule.
 Modeling. A software engineer creates models to better understand software requirements
and the design that will achieve those requirements.
 Construction. This activity combines code generation (either manual or automated) and
the testing that is required uncovering errors in the code.
 Deployment. The software (as a complete entity or as a partially completed increment) is
delivered to the customer who evaluates the delivered product and provides feedback based
on the evaluation.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Figure 1.2 – Software process framework

 Software engineering process framework activities are complemented by a number of

umbrella activities.

 In general, umbrella activities are applied throughout a software project and help a software
team manage and control progress, quality, change, and risk. Typical umbrella activities
include:

 Software project tracking and control—allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.

 Risk management—assesses risks that may affect the outcome of the project or the quality
of the product.

 Software quality assurance—defines and conducts the activities required to ensure

software quality.

 A technical review—assesses software engineering work products in an effort to uncover

and remove errors before they are propagated to the next activity.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs; can be used in conjunction
with all other framework and umbrella activities.

 Software configuration management—manages the effects of change throughout the

software process.

 Reusability management—defines criteria for work product reuse (including software

components) and establishes mechanisms to achieve reusable components.

 Work product preparation and production—encompasses the activities required to

create work products such as models, documents, logs, forms, and lists.

Process Assessment and Improvement

A number of different approaches to software process assessment and improvement have been
proposed over the past few decades:

Standard CMMI Assessment Method for Process Improvement (SCAMPI)

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
SPICE (ISO/IEC15504
ISO 9001:2000 for Software

Example:
Discuss about their necessity in maintaining the quality in both software process and
product that is being developed for railway reservation system.
A separate organization was considered better suited to take up all computer activities on IR
(Indian railways) mainly for the following reasons:
 To avoid duplication of efforts by individual Railways.

 To ensure standardization of computer hardware and software on the Railways.

 To undertake design and development of major applications on Railways requiring higher

levels of expertise, faster decision making and system wide applicability.

 To insulate the organization from day to day working of the Railways so that its objectives
are not lost sight of.

 Need for a combined effort of Railways and Computer Specialists, considered best suited
for the development of the computer applications on Railways.

 Need for development of expertise in highly specialized fields like Operation Research,
Simulation, Expert System, CAD/CAM, Process Control etc.

 Need for greater flexibility to keep pace with the fast changing technology.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

2. Explain the Iterative waterfall and Incremental model of Software life cycle models
and discuss various activities in each phase.(Nov/Dec ’12) (Or) Describe the type of
situations where iterative enhancement model might lead to difficulties (Or)
Elucidate the key features of the software process models with suitable examples.
What is the role of user participation in the selection of a life cycle model? (or) List
out the various perspective process model available in software development, with
appropriate diagram, discuss any two prescriptive process model in detail (Nov/Dec
2021)

Perspective and Specialized Process Models

 All software process models can accommodate the generic framework activities, but each
applies a different emphasis to these activities and defines a process flow that invokes each
framework activity in a different manner.

The Waterfall Model

 The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification of
requirements and progresses through planning, modeling, construction, and deployment,
culminating in ongoing support of the completed software (Refer Figure 1.3).

Figure 1.3 – Waterfall model

 A variation in the representation of the waterfall model is called the V-model. Represented
in Figure 1.4, the V-model depicts the relationship of quality assurance actions to the
actions associated with communication, modeling, and early construction activities.
 As software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem and
its solution.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Once code has been generated, the team moves up the right side of the V, essentially
performing a series of tests (quality assurance actions) that validate each of the models
created as the team moved down the left side.

 The problems that are encountered when the waterfall model is applied are:

 Real projects rarely follow the sequential flow that the model proposes.

 The linear model can accommodate iteration, it does so indirectly. As a result, changes
can cause confusion as the project team proceeds.

 It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty accommodating the natural uncertainty that exists at
the beginning of many projects.

 The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the
working program is reviewed, can be disastrous.

 Today, software work is fast-paced and subject to a never-ending stream of changes (to
features, functions, and information content). The waterfall model is often inappropriate
for such work. However, it can serve as a useful process model in situations where
requirements are fixed and work is to proceed to completion in a linear manner.

Advantages:
 Simple and easy to 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:
 Adjusting scope during the life cycle can kill a project
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Poor model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Poor model where requirements are at a moderate to high risk of changing.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Figure 1.4 – V Model

Incremental Process Models

 The incremental model combines elements of linear and parallel process flows. Referring
to Figure 1.5, the incremental model applies linear sequences in a staggered fashion as
calendar time progresses.
 Each linear sequence produces deliverable “increments” of the software in a manner that is
similar to the increments produced by an evolutionary process flow.
 When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features (some known, others unknown)
remain undelivered. The core product is used by the customer (or undergoes detailed
evaluation).
 As a result of use and/or evaluation, a plan is developed for the next increment.
 The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality.
 This process is repeated following the delivery of each increment, until the complete product
is produced.
 The incremental process model focuses on the delivery of an operational product with each
increment. Early increments are stripped-down versions of the final product, but they do
provide capability that serves the user and also provide a platform for evaluation by the user.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Figure 1.5 – Incremental Process model

 Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project.
 Early increments can be implemented with fewer people. If the core product is well
received, then additional staff (if required) can be added to implement the next increment.
In addition, increments can be planned to manage technical risks.
Advantages
 Generates working software quickly and early during the software life cycle.
 More flexible – less costly to change scope and requirements.
 Easier to test and debug during a smaller iteration.
 Easier to manage risk because risky pieces are identified and handled during its iteration.
 Each iteration is an easily managed milestone.
Disadvantages
 Each phase of an iteration is rigid and do not overlap each other.
 Problems may arise pertaining to system architecture because not all requirements are
gathered up front for the entire software life cycle.

3. Write short notes on Evolutionary Software process models. (Or) Discuss the
prototyping model. What is the effect of designing a prototype on the overall cost of
the software project? (May/June 2016)

Evolutionary Process Models

Evolutionary models are iterative. They are characterized in a manner that enables you to develop
increasingly more complete versions of the software. The common evolutionary process models
are
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Prototyping model
 Spiral model

Prototyping model
 The prototyping paradigm (Figure 1.6) begins with communication.
 Meeting with other stakeholders to define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
 Prototyping iteration is planned quickly, and modeling (in the form of a “quick design”)
occurs.
 A quick design focuses on a representation of those aspects of the software that will be
visible to end users (e.g., human interface layout or output display formats).
 The quick design leads to the construction of a prototype. The prototype is deployed and
evaluated by stakeholders, who provide feedback that is used to further refine
requirements.
 Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while
at the same time enabling you to better understand what needs to be done.
 Ideally, the prototype serves as a mechanism for identifying software requirements. If a
working prototype is to be built, you can make use of existing program fragments or apply
tools (e.g., report generators and window managers) that enable working programs to be
generated quickly.
 The prototype can serve as “the first system”.

 Some prototypes are built as “throwaways,” others are evolutionary in the sense that the
prototype slowly evolves into the actual system.

 Prototyping can be problematic for the following reasons:

 Stakeholders see what appears to be a working version of the software,

o unaware that the prototype is held together haphazardly,

o Unaware that in the rush to get it working you haven’t considered overall
software quality or long-term maintainability.

 As a software engineer, you often make implementation compromises in order to get a

prototype working quickly. An inappropriate operating system or programming language
may be used simply because it is available and known; an inefficient algorithm may be
implemented simply to demonstrate capability.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Figure 1.6 – Prototyping paradigm

 Prototyping can be an effective paradigm for software engineering. All stakeholders should
agree that the prototype is built to serve as a mechanism for defining requirements. It is
then discarded (at least in part), and the actual software is engineered with an eye toward
quality.

Spiral model [Apr/May2018, 2019]

 Originally proposed by Barry Boehm, the spiral model is an evolutionary software

process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.

 It provides the potential for rapid development of increasingly more complete versions of
the software. Using the spiral model, software is developed in a series of evolutionary
releases.

Spiral model = prototype model + waterfall model

 During early iterations, the release might be a model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Figure 1.7 – Spiral model

 A spiral model (Refer figure 1.7) is divided into a set of framework activities defined by
the software engineering team.
 As this evolutionary process begins, the software team performs activities that are
implied by a circuit around the spiral in a clockwise direction, beginning at the center.
 Risk is considered as each revolution is made.
 Anchor point milestones—a combination of work products and conditions that are attained
along the path of the spiral—are noted for each evolutionary pass.
 The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the software.

 The first circuit around the spiral might represent a “concept development project” that
starts at the core of the spiral and continues for multiple iterations until concept
development is complete.

 If the concept is to be developed into an actual product, the process proceeds outward on
the spiral and a “new product development project” commences. The new product will
evolve through a number of iterations around the spiral.
 Later, a circuit around the spiral might be used to represent a “product enhancement
project.” In essence, the spiral, when characterized in this way, remains operative until the
software is retired.

 The spiral model is a realistic approach to the development of large-scale systems and
software.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 The spiral model uses prototyping as a risk reduction mechanism but, more important,
enables you to apply the prototyping approach at any stage in the evolution of the product.

 It maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that more realistically reflects the real world.

 The spiral model demands a direct consideration of technical risks at all stages of the
project and, if properly applied, should reduce risks before they become problematic.

Advantages:
 High amount of risk analysis
 Good for large and mission-critical projects.
 Software is produced early in the software life cycle.

Disadvantages:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.

4. Explain the different states involved in Concurrent Engineering.

Concurrent Models
 The concurrent development model, sometimes called concurrent engineering, allows a
software team to represent iterative and concurrent elements of any of the process models.

 For example, the modeling activity defined for the spiral model is accomplished by
invoking one or more of the following software engineering actions: prototyping, analysis,
and design.

 Figure 1.8 provides a schematic representation of one software engineering activity within
the modeling activity using a concurrent modeling approach.

 The activity—modeling—may be in any one of the states noted at any given time.

 Similarly, other activities, actions, or tasks (e.g., communication or construction) can

be represented in an analogous manner. All software engineering activities exist
concurrently but reside in different states.

 For example, early in a project the communication activity (not shown in the figure) has
completed its first iteration and exists in the awaiting changes state.

 The modeling activity which existed in the inactive state while initial communication was
completed, now makes a transition into the under development state.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 If, however, the customer indicates that changes in requirements must be made, the
modeling activity moves from the under development state into the awaiting changes
state.

Figure 1.8 – Concurrent process model

 Concurrent modeling defines a series of events that will trigger transitions from state to
state for each of the software engineering activities, actions, or tasks.

 For example, during early stages of design, an inconsistency in the requirements model is
uncovered. This generates the event analysis model correction, which will trigger the
requirements analysis action from the done state into the awaiting changes state.

 Concurrent modeling is applicable to all types of software development and provides an

accurate picture of the current state of a project.

 Rather than confining software engineering activities, actions, and tasks to a sequence of
events, it defines a process network.

5. List the basics of Software Project Management.

The People
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

The “people factor” is so important that the Software Engineering Institute has developed
a People Capability Maturity Model (People-CMM).
The people capability maturity model defines the following key practice areas for software
people: staffing, communication and coordination, work environment, performance management,
training, compensation, competency analysis and development, career development, workgroup
development, team/culture development, and others.

The Product
Before a project can be planned, product objectives and scope should be established,
alternative solutions should be considered, and technical and management constraints should be
identified.
Without this information, it is impossible to define reasonable (and accurate) estimates of
the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable
project schedule that provides a meaningful indication of progress.
Once the product objectives and scope are understood, alternative solutions are considered.
Although very little detail is discussed, the alternatives enable managers and practitioners
to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary
restrictions, personnel availability, technical interfaces, and myriad other factors.

The Process
A software process provides the framework from which a comprehensive plan for software
development can be established. A small number of framework activities are applicable to all
software projects, regardless of their size or complexity.
A number of different task sets—tasks, 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.
Finally, umbrella activities—such as software quality assurance, software configuration
management, and measurement—overlay the process model. Umbrella activities are independent
of any one framework activity and occur throughout the process.
The Project
We conduct planned and controlled software projects for one primary reason—it is the only
known way to manage complexity. And yet, software teams still struggle. In a study of 250 large
software projects between 1998 and 2004, Capers Jones [Jon04] found that “about 25 were deemed
successful in that they achieved their schedule, cost, and quality objectives.
About 50 had delays or overruns below 35 percent, while about 175 experienced major
delays and overruns, or were terminated without completion.” Although the success rate for
present-day software projects may have improved somewhat, our project failure rate remains much
higher than it should be.
To avoid project failure, a software project manager and the software engineers who build
the product must avoid a set of common warning signs, understand the critical success factors that
lead to good project management, and develop a commonsense approach for planning, monitoring,
and controlling the project.

People
The Stakeholders
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

The software process (and every software project) is populated by stakeholders who
can be categorized into one of five constituencies:
 Senior managers who define the business issues that often have a significant influence
on the project.
 Project (technical) managers who must plan, motivate, organize, and control the
practitioners who do software work.
 Practitioners who deliver the technical skills that are necessary to engineer a product or
application.
 Customers who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.
 End users who interact with the software once it is released for production use.
 Team Leaders
In an excellent book of technical leadership, Jerry Weinberg [Wei86] suggests an MOI
model of leadership:
 Motivation. The ability to encourage (by “push or pull”) technical people to produce to
their best ability.
 Organization. The ability to mold existing processes (or invent new ones) that will enable
the initial concept to be translated into a final product.
 Ideas or innovation. The ability to encourage people to create and feel creative even when
they must work within bounds established for a particular software product or application.

The Software Team

The “best” team structure depends on the management style of your organization, the
number of people who will populate the team and their skill levels, and the overall problem
difficulty. Mantei [Man81] describes seven project factors that should be considered when
planning the structure of software engineering teams:
 Difficulty of the problem to be solved
 “Size” of the resultant program(s) in lines of code or function points
 Time that the team will stay together (team lifetime)
 Degree to which the problem can be modularized
 Required quality and reliability of the system to be built
 Rigidity of the delivery date
 Degree of sociability (communication) required for the project

Agile Teams
The small, highly motivated project team, also called an agile team, adopts many of the
characteristics of successful software project teams discussed in the preceding section and avoids
many of the toxins that create problems. However, the agile philosophy stresses individual (team
member) competency coupled with group collaboration as critical success factors for the team.

The W5HH Principle

Boehm suggests an approach that addresses project objectives, milestones and schedules,
responsibilities, management and technical approaches, and required resources.
He calls it the W5HH Principle, after a series of questions that lead to a definition of key
project characteristics and the resultant project plan:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Why is the system being developed? All stakeholders should assess the validity of business
reasons for the software work. Does the business purpose justify the expenditure of people,
time, and money?

 What will be done? The task set required for the project is defined.

 When will it be done? The team establishes a project schedule by identifying when project
tasks are to be conducted and when milestones are to be reached.

 Who is responsible for a function? The role and responsibility of each member of the
software team is defined.

 Where are they located organizationally? Not all roles and responsibilities reside within
software practitioners. The customer, users, and other stakeholders also have
responsibilities.

 How will the job be done technically and managerially? Once product scope is
established, a management and technical strategy for the project must be defined.

 How much of each resource is needed? The answer to this question is derived by
developing estimates based on answers to earlier questions.

6. Neatly explain the following process models and write their advantages and
disadvantages. (Apr/ May 2015)
(i) Spiral model
(ii) Rapid Application Development model.

(i) Spiral model

 Refer Q.No.3

(ii) Rapid Application Development model. (Refer Figure 1.9)

RAD model is Rapid Application Development model.

It is a type of incremental model. In RAD model the components or functions are

developed in parallel as if they were mini projects.

The developments are time boxed, delivered and then assembled into a working
prototype.

This can quickly give the customer something to see and use and to provide feedback
regarding the delivery and their requirements.

The phases in the rapid application development (RAD) model are:

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that
are needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and
created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the
actual system.
Testing and turnover: Test new components and all the interfaces.

Diagram of RAD-Model:

Figure 1.9 – RAD Model

Advantages of the RAD model:

 Reduced development time.

 Increases reusability of components
 Quick initial reviews occur
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Encourages customer feedback

 Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

 Depends on strong team and individual performances for identifying business

requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.

When to use RAD model:

 RAD should be used when there is a need to create a system that can be modularized in
2-3 months of time.
 It should be used if there’s high availability of designers for modeling and the budget
is high enough to afford their cost along with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3 months).

7. Explain the CMMI model to assess the organization level. (Nov/Dec 2018)

What is CMMI?
 CMMI is a Process Model Framework for process-improvement developed by Software
Engineering Institute (SEI).
 CMMI, standing for Capability Maturity Model Integration, is a structured and systematic
collection of best practices for process-improvement.
 The CMMI process model framework is currently available in three constellations. They
are CMMI for Development, CMMI for Services, and CMMI for Acquisition.
 These three constellations cover entire spectrum of industries including Software
Engineering, Manufacturing, Financial, Aerospace, Computer hardware, Defence, and
Telecommunications, etc.

What is CMMI Assessment?

 CMMI Assessment is an activity to evaluate compliance and measure the effectiveness of

Specific Practices (SPs) of Process Areas (PAs) as specified in CMMI Process Model
Framework.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 The CMMI Assessment Results are delivered in form of Maturity Level Rating when
CMMI Framework is implemented as per Staged Representation.

 The Assessment is conducted by an CMMI Institute Certified Assessor. The CMMI

Institute Certified Assessor is known as Lead Appraiser or High Maturity Lead
Appraiser depending on the maturity level to be assessed i.e. Low Maturity (2 and 3) or
High Maturity (i.e. 4 and 5).

 CMMI Assessments are also known as CMMI Appraisals. The CMMI Institute has
published following guidelines for conducting appraisals:

 Appraisal Requirements for CMMI (ARC) Document: ARC document provide

information on the Appraisal Requirements. ARC Document can be found here.

 Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Method

Definition Document: SCAMPI MDD Document provides information on the CMMI
Assessment Methodology. SCAMPI Document can be found here.

SCAMPI Assessments

 CMMI Institute has devised the three classes for Assessment i.e. A, B and C depending
on the formalism required in the Assessment.

 Among these, SCAMPI A Assessment is the most formal and rigorous and results in a
Maturity Level Rating for the assessment conducted for an organization.

 SCAMPI B Assessment is the less formal, less rigorous method and does not result in a
Maturity Level Rating for the assessment.

 SCAMPI C Assessment is the least formal method compared to SCAMPI A and B

assessments and also does not provide a Maturity Level Rating for assessment.

8. What are the pros and cons of using mathematical approach for software
development?

The Pros:
1. Abstractness. If done well, one can verify a variety of problems into formal methods.
2. Robustness. It can mathematically prove certain properties of a model. This is significantly
better than standard unit-testing and other methods to understand executions of a model.

The cons:
1. Practical applicability.
It is really tough to apply (traditional) formal methods in real-world giant applications.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

The major difficulty is the state explosion problem, which means that the verification
problem typically gets exponentially intractable in size of the model.
2. Characterizing the model.
Formal Methods has been applied in various fields, including software engineering,
computation biology, security, mechanical designing and a lot others.
However, given a problem from an arbitrary field, it is a tough challenge to find a
modeling technique and a property specification to express the problem.

9. Assume that you are the technical manager of a software development

organization. A client approached you for a software solution. The problems stated
by the client have uncertainties which lead to loss if it not planned and solved. Which
software development model you will suggest for this project — justify. Explain that
model with its pros and cons and neat sketch. (Nov/Dec 2015, Nov/Dec 2018)

 Agile Project Management is built around a flexible approach. Team member’s work in
short bursts on small-scale but functioning releases of a product.
 They then test each release against customers' needs, instead of aiming for a single final
result that is only released at the end of the project.
 The end product of an agile project may be very different from the one that was envisaged
at the outset.
 However, because of the checking process, team members can be sure that the product is
one that customers want.
 This makes Agile Project Management particularly appropriate for new or fast-moving
businesses, for those in a fast-changing environment, or for highly complex situations,
where managers are "feeling their way forward" to find the optimum business model.
 It's also helpful with urgent projects that can't wait for a full, traditional project to be set
up.
 The framework involves three key roles:

1. The product owner is an expert on the product being developed. He or she represents key
stakeholders, customers, and end users, and is responsible for prioritizing the project and getting
funding.
The product owner describes how people will use the final product, communicates
customer needs, and helps the team develop the right product. His or her expertise also helps
combat scope creep.

2. The scrum master is responsible for managing the process. This person solves problems, so
that the product owner can drive development, and maximize return on investment. The scrum
master ensures that each sprint is self-contained, and that it doesn't take on additional objectives.
The scrum master oversees communication, so that stakeholders and team members can
easily understand what progress has been made.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

3. The team is the group of professionals responsible for turning requirements into functionality.
The team will work on each project via "sprints" – short phases of work which deliver
completed, tested, documented, and functioning products at their conclusion.

Pros of Agile:
 You, and your customer, are able to see work as it’s being done so you can comment and
make decisions. More engagement on your part has a number of advantages to the overall
application – there is less chance that developers will need to redo polished work, and the
resulting application will be better tailored to your needs.

 You can usually get to market faster, because you are creating smaller, functional
elements that are designed, tested, and refined as you go.
 Agile has a more predictable timeframe. By working in discrete and relatively short
“sprints,” you’re never more than a few weeks away from your next usable release. And
by tracking your performance metrics for past sprints, you can better predict where the
coming sprints will get you.
 Lastly, Agile is, well, agile. The requirements can change as you think about the project.
If you gain more or better information about what your users want, you can more easily
incorporate these new insights into the project.

Cons of Agile:
 Increased customer participation is a double-edged sword. A customer – or a customer
avatar, such as an internal Product Manager – must commit to deep involvement with the
Agile process for this method to show its value. If you cannot devote someone to this
project full time, chances are you won’t get the best results possible.
 Agile also requires high commitment from members of the development team, because it
relies on short, intense sprints. It’s not so easy to multi-task this way, so they will likely
not be able to devote time to other projects during Agile development.
 Agile prioritizes speed and customer requirements over high technical precision. It may
not be the best choice when creating software that must be highly integrated with other
systems.

10. What is a process model? Describe the process model that you would choose to
manufacture a car. Explain giving suitable reasons. (Apr/May 2017)
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

A software process model is a standardized format for

• planning
• organizing, and
• running a development project
Hundreds of different models exist and are used, but many are minor variations on a small
number of basic models.
Planning with Models SE projects usually live with a fixed financial budget. Additionally,
time-to-market places a strong time constraint. There will be other project constraints such as staff.

Figure 1.10 – Process Model

The process model used to manufacture a car is Incremental model

 The incremental build model is a method of software development where the product
is designed, implemented and tested incrementally (a little more is added each time) until
the product is finished. It involves both development and maintenance.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 The product is defined as finished when it satisfies all of its requirements. This model
combines the elements of the waterfall model with the iterative philosophy of
prototyping.

 The incremental model applies the waterfall model incrementally.

 The series of releases is referred to as “increments”, with each increment providing more
functionality to the customers.

 After the first increment, a core product is delivered, which can already be used by the
customer.

 Based on customer feedback, a plan is developed for the next increments, and
modifications are made accordingly.

 This process continues, with increments being delivered until the complete product is
delivered. The incremental philosophy is also used in the agile process model.

 The Incremental model can be applied to DevOps.

 In DevOps it centers around the idea of minimizing risk and cost of a DevOps adoption
whilst building the necessary in-house skillset and momentum.

Characteristics of Incremental Model

1. System is broken down into many mini development projects.

2. Partial systems are built to produce the final system.
3. First tackled highest priority requirements.
4. The requirement of a portion is frozen once the incremented portion is developed.

Advantages

1. After each iteration, regression testing should be conducted.

2. It is generally easier to test and debug than other methods of software development because
relatively smaller changes are made during each iteration. This allows for more targeted
and rigorous testing of each element within the overall product.
3. Customer can respond to features and review the product for any needed or useful changes.
4. Initial product delivery is faster and costs less.

Disadvantages
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

1. Resulting cost may exceed the cost of the organization.

2. As additional functionality is added to the product, problems may arise related to system
architecture which were not evident in earlier prototypes

11. i) What is the impact of reusability in software development process? (Nov/Dec

2017)
ii) Explain the component based software development model with a neat sketch.

The impact of reusability in software development process:

 In simple words software reuse can be defined as the process of creating software
systems from existing software assets rather than building them from scratch.

 Software assets, or components, include all software products, from requirements and
proposals, to specifications and designs, to user manuals and test suites.

 In general anything that is produced from a software development effort can potentially
be reused.

ii) Explain the component based software development model with a neat sketch.

Component-Based software engineering

 CBSE is a process for developing computer systems using reusable software components.

 It is concerned with assembling of pre-existing software components into larger pieces

of software

Component
 A software component is an independently deployable implementation of some
functionality, to be reused as it is in a broad spectrum of applications.

 For a software component what it provides and requires should be clearly stated so that it
can be used without any ambiguity.

Categories of Components
 Commercial of-the-shelf components- readily available in the market.

 Qualified components—assessed by software engineers to ensure that not only

functionality, but also performance, reliability, usability, and other quality factors conform
to the requirements of the system/product to be built.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Adapted components—adapted to modify (wrapping) unwanted or undesired

characteristics.

 Assembled components—integrated into an architectural style and interconnected with an

appropriate component infrastructure that allows the components to be coordinated and
managed effectively.

 Updated components—replacing existing software as new versions of components become

available.

The CBSE Process (Refer figure 1.11)

• The CBSE process includes to identify candidate components, to qualify each component’s
interface, to adapt components to remove architectural mismatches, to assembly
components into a selected architectural style, and to update components as requirements
for the system change.

• The process model for component-based software engineering emphasizes parallel tracks
in which domain engineering occurs concurrently with component-based development.

Component Based Development

⚫ This process basically consists of three main stages namely
 qualification,
 adaptation and
 composition

Component Qualification
⚫ Component qualification ensures that a candidate component
⚫ will perform the function required,
⚫ will properly fit into the architectural style specified for the system, and
⚫ will exhibit the quality characteristics (e.g., performance, reliability, usability)
required for the application.
Component Adaption
⚫ Most of the times even after the component has been qualified for use in the architecture
it exhibits some conflicts.

⚫ To soothe these conflicts certain techniques such as component wrapping is used.

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Figure 1.11 – CBSE Process

Wrapping
 White-Box wrapping – this wrapping involves code level modifications in the
components to avoid conflicts.

 This is not widely used because the COTS products are not provided with the source
code.

12. i) Write a note on the unique characters of a software. (Nov/Dec 2017) ii) What is
the significance of the spiral model when compared with other models.
 Software is engineered, not manufactured.
 Software does not wear out.
 Most software is custom built rather than being assembled from components.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

ii) What is the significance of the spiral model when compared with other models.

 It is realistic and typifies most software development products/projects. Most software is

evolutionary in nature and this model captures that nature.
 It combines the best features of prototyping as a means of eliciting feedback. The phases
resemble the Waterfall Model.
 It strikes a good balance mechanism for early problem identification and correction while
not missing out proactive problem prevention.
 WWith increased globalisation; technology is witnessing growing application and
acceptance across service delivery platforms.
 SService organizations are using technology for improving their service quality and
customer service culture by developing profitable, long-term relationships with customers
.
 DDelivery of superior service quality is an important determinant of success in the service
industry.
 AIn exploratory research was conducted to study customer experience of the online
reservation system of the Indian railways. The purpose was to understand the customer’s
perception regarding technology deployment in improving services.
 DDimensions of the service quality model were used for understanding perceptions
regarding the online railway reservation system.
 TThe study indicates that though the service is gaining acceptability in the country, there
still exists considerable scope for improvement in customer experience with regard to the
various service quality dimensions for the online reservation system.
 BBased on the findings of the study, recommendations for improvement in various aspects
of the service are stated.

13. Explain in detail about Agile software development. (or) What is agility?
Elaborate the agile principles. (Nov/Dec 2019) (or) Define Agility. List any Five
principles of agility. (April/May 2019)
Agile software development

 Agile Software Development is a lightweight software engineering framework that

promotes iterative development throughout the life-cycle of the project, close
collaboration between the development team and business side, constant communication,
and tightly-knit teams.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 It promotes adaptive planning, evolutionary development and delivery, a time-

boxed iterative approach, and encourages rapid and flexible response to change.
 Also known as agile development.

Agile --readiness for motion, nimbleness, activity, dexterity in motion.

Agility
Agility is dynamic, content specific, aggressively change embracing, and growth
oriented.”

Agile team.

 An agile team is a nimble team able to appropriately respond to changes.

 Changes in the software being built, changes to the team members, changes because of new
technology, changes of all kinds that may have an impact on the product they build or the
project that creates the product.
 An agile team recognizes that software is developed by individuals working in teams and
that the skills of these people, their ability to collaborate is at the core for the success of
the project.
The Agile Manifesto.

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

The agile principles:

 The highest priority of this process is to satisfy the customer.

 Acceptance of changing requirement even late in development.
 Frequently deliver a working software in small time span.
 Throughout the project business people and developers work together on daily basis.
 Projects are created around motivated people if they are given the proper environment
and support.
 Face to face interaction is the most efficient method of moving information in the
development team.
 Primary measure of progress is a working software.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Agile process helps in sustainable development.

 Continuous attention to technical excellence and good design increases agility.
 From self organizing teams the best architecture, design and requirements are emerged.
 Simplicity is necessary in development.

Characteristics of Agile Software Development.

-- Light Weighted methodology
-- Small to medium sized teams
-- vague and/or changing requirements
-- vague and/or changing techniques
-- Simple design
-- Minimal system into production
Advantages of the Agile Model:
 Is a very realistic approach to software development.
 Promotes teamwork and cross training.
 Functionality can be developed rapidly and demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
 Delivers early partial working solutions.
 Good model for environments that change steadily.
 Minimal rules, documentation easily employed.
 Enables concurrent development and delivery within an overall planned context.
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers.
Disadvantages of the Agile Model
 Not suitable for handling complex dependencies.
 More risk of sustainability, maintainability and extensibility.
 An overall plan, an agile leader and agile PM practice is a must without which it will not
work.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 Strict delivery management dictates the scope, functionality to be delivered, and

adjustments to meet the deadlines.
 Depends heavily on customer interaction, so if customer is not clear, team can be driven
in the wrong direction.
 There is a very high individual dependency, since there is minimum documentation
generated.
 Transfer of technology to new team members may be quite challenging due to lack of
documentation.
Existing Agile Methods:
 Extreme Programming (“XP”)
 Agile Unified Process
 Scrum

14. Explain in detail about agile Extreme programming (XP) and its process. (or)
Explain the phases in Extreme Programming process. (April/May 2019)

EXTREME PROGRAMMING (XP)

 Extreme Programming (XP), the most widely used approach to agile software
development.
 A variant of XP, called Industrial XP (IXP) has been proposed.

 IXP refines XP and targets the agile process specifically for use within large
organizations.

XP Values

 Beck defines a set of five values that establish a foundation for all work performed as part
of XP
 Communication
 Simplicity
 Feedback
 Courage and
 Respect.

 Each of these values is used as a driver for specific XP activities, actions, and tasks.

Communication:
In order to achieve effective communication between software engineers and other
stakeholders (e.g., to establish required features and functions for the software), XP emphasizes
close, yet informal (verbal) collaboration between customers and developers, the establishment
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

of effective metaphors for communicating important concepts, continuous feedback, and the
avoidance of large documentation as a communication medium.

Simplicity:
 To achieve simplicity, XP restricts developers to design only for immediate needs, rather
than consider future needs.

 The intent is to create a simple design that can be easily implemented in code. If the
design must be improved, it can be refactored at a later time.

Feedback:
Feedback is derived from three sources:
 the implemented software itself,
 the customer, and
 Other software team members.

 By designing and implementing an effective testing strategy the software (via test results)
provides the agile team with feedback.
 XP makes use of the unit test as its primary testing tactic.
 As an increment is delivered to a customer, the user stories or use cases that are
implemented by the increment are used as a basis for acceptance tests.

 The degree to which the software implements the output, function, and behavior of the
use case is a form of feedback.

Courage (Discipline)

 Finally, as new requirements are derived as part of iterative planning, the team provides
the customer with rapid feedback regarding cost and schedule impact.

 Strict adherence to certain XP practices demands courage(discipline).

 For example, there is often significant pressure to design for future requirements.

Respect

By following each of these values, the agile team inculcates respect among it members, between
other stakeholders and team members, and indirectly, for the software itself.

The XP Process (Refer figure 1.12)

Extreme Programming uses an object-oriented approach as its preferred development paradigm

and encompasses a set of rules and practices that occur within the context of four framework
activities: planning, design, coding, and testing.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Figure 1.12 – XP Process

Planning:

 The planning activity (also called the planning game) begins with listening—a
requirements gathering activity that enables the technical members of the XP team.

 Listening leads to the creation of a set of “stories” (also called user stories) that describe
required output, features, and functionality for software to be built.

 Each story is written by the customer and is placed on an index card.

 The customer assigns a value (i.e., a priority) to the story based on the overall business
value of the feature or function.

 Members of the XP team then assess each story and assign a cost—measured in
development weeks—to it.

 Customers and developers decide the basic commitment (agreement on stories to be

included, delivery date, and other project matters) is made for a release, the XP team orders
the stories that will be developed in one of three ways:

(1) all stories will be implemented immediately (within a few weeks),

(2) the stories with highest value will be moved up in the schedule and implemented
first, or
(3) the riskiest stories will be moved up in the schedule and implemented first.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

After the first project release (also called a software increment) has been delivered, the XP team
computes project velocity. Stated simply, project velocity is the number of customer stories
implemented during the first release.

 Project velocity can then be used to

(1) help estimate delivery dates and schedule for subsequent releases and
(2) determine whether an over commitment has been made for all stories across the entire
development project.

Design:
 XP design rigorously follows the KIS (keep it simple) principle.

 A simple design is always preferred over a more complex representation.

 XP encourages the use of CRC cards as an effective mechanism for thinking about the
software in an object-oriented context. CRC (class-responsibility collaborator) cards
identify and organize the object-oriented classes that are relevant to the current software
increment.

 If a difficult design problem is encountered, XP recommends A spike solution, the design

prototype is implemented and evaluated.
 XP encourages refactoring—a construction technique that is also a method for design
optimization.
 Refactoring is the process of changing a software system in such a way that it does not
alter the external behavior of the code yet improves the internal structure.

Coding:
 After stories are developed and preliminary design work is done, the team does not move
to code, but rather develops a series of unit tests that will exercise each of the stories that
is to be included in the current release (software increment).
 Once the unit test has been created, the developer is better able to focus on what must be
implemented to pass the test.
 Once the code is complete, it can be unit-tested immediately, thereby providing
instantaneous feedback to the developers.
 A key concept during the coding activity is pair programming.
 XP recommends that two people work together at one computer workstation to create code
for a story.
 This provides a mechanism for realtime problem solving and real-time quality assurance.

Testing:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

 The creation of unit tests before coding commences is a key element of the XP approach.
The unit tests that are created should be implemented using a framework that enables them
to be automated. This encourages a regression testing strategy whenever code is modified.

 As the individual unit tests are organized into a “universal testing suite”, integration and
validation testing of the system can occur on a daily basis.

 XP acceptance tests, also called customer tests, are specified by the customer and focus on
overall system features and functionality that are visible and reviewable by the customer.

 Acceptance tests are derived from user stories that have been implemented as part of a
software release.

Industrial XP
 “IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric,
test-driven spirit.
 IXP differs most from the original XP in its greater inclusion of management, its
expanded role for customers, and its upgraded technical practices.”
 IXP incorporates six new practices that are designed to help ensure that an XP project
works successfully for significant projects within a large organization.

Readiness assessment. Prior to the initiation of an IXP project, the organization should conduct
a readiness assessment. The assessment ascertains whether
(1) an appropriate development environment exists to support IXP,
(2) the team will be populated by the proper set of stakeholders,
(3) the organization has a distinct quality program and supports continuous improvement,
(4) the organizational culture will support the new values of an agile team, and
(5) the broader project community will be populated appropriately.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Project community. When XP is to be applied for a significant project in a large organization, the
concept of the “team” should morph into that of a community. A community may have a
technologist and customers who are central to the success of a project as well as many other
stakeholders

Project chartering. The IXP team assesses the project itself to determine whether an appropriate
business justification for the project exists and whether the project will further the overall goals
and objectives of the organization. Chartering also examines the context of the project to determine
how it complements, extends, or replaces existing systems or processes.

Test-driven management. Test-driven management establishes a series of measurable

“destinations” and then defines mechanisms for determining whether or not these destinations have
been reached.

Retrospectives. An IXP team conducts a specialized technical review called a retrospective, the
review examines “issues, events, and lessons-learned” across a software increment and/or the
entire software release. The intent is to improve the IXP process.

Continuous learning. Because learning is a vital part of continuous process improvement,

members of the XP team are encouraged (and possibly, incented) to learn new methods and
techniques that can lead to a higher quality product.

The XP Debate
Among the issues that continue to trouble some critics of XP are:
• Requirements volatility
• Conflicting customer needs.
• Requirements are expressed informally.
• Lack of formal design.
15. Compare the waterfall, Prototyping and spiral model. List the features of each
model, advantages and disadvantage and a type of application where the model will
be acceptable. (April/May 2019) (April/May 2021)
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Table 1.1 – Comparison between Waterfall, Spiral and Prototype

16. Explain the 12 practices of extreme programming. Explain how agility is

achieved in extreme programming. (or) Define Agile Programming. Explain the 12
practices of extreme programming. (April/May 2021) (Nov/Dec 2021)

12 Core Practices of Extreme Programming

1. Planning Game:
 In XP the main planning process is called Planning Game.
 There are 2 levels of plans in XP;
 level 1  release planning and
 level 2  iteration planning.
 In both levels, there are 3 steps: exploration, commitment, and steering.

 Release planning: The team and stakeholders/customers collaboratively decide what are
the requirements and features that can be delivered into production and when. This is
done based on priorities, capacity, estimations and risks factor of the team to deliver.

 Iteration planning: The team will pick up the most valuable items from the list and break
them down into tasks then estimates and a committment to delivering at the end of the
iteration.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

2. Small releases

Small releases also help to breakdown complex modules in a small chunk of code. This
helps the developer team as well as the on-site customer to demonstrate the product and focus
only on the least amount of work that has the highest priority.

3. Simple Design:

XP uses the simplest possible design that gets the job done. The requirements will change
tomorrow, so only do what's needed to meet today's requirements.

4. Metaphor :

Extreme Programming teams develop a common vision of how the program works, which
we call the "metaphor". At its best, the metaphor is a simple evocative description of how the
program works.

XP teams use a common system of names to be sure that everyone understands how the
system works and where to look to find the functionality you're looking for, or to find the right
place to put the functionality you're about to add.

5. Continuous Testing:

XP teams focus on validation of the software at all times. Programmers develop software
by writing tests first, and then code that fulfills the requirements reflected in the tests.

Customers provide acceptance tests that enable them to be certain that the features they
need are provided.

6. Refactoring:

XP Team Refactor out any duplicate code generated in a coding session. Refactoring is
simplified due to extensive use of automated test cases.

7. Pair Programming:

All production code is written by two programmers sitting at one machine. This practice
ensures that all code is reviewed as it is written and results in better Design, testing and better
code.

8. Collective Code Ownership:

No single person "owns" a module. Any developer is expected to be able to work on any
part of the code base at any time.

9. Continuous Integration:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

All changes are integrated into the code base at least daily. The unit tests have to run 100%
both before and after integration.

10. 40-Hour Work Week:

Programmers go home on time. In crunch mode, up to one week of overtime is allowed.

But multiple consecutive weeks of overtime are treated as a sign that something is very wrong
with the process and/or schedule.

11. On-site Customer:

Development team has continuous access to the customer who will actually be using the
system.

For initiatives with lots of customers, a customer representative (i.e Product Manager) will
be designated for Development team access.

12. Coding Standards:

Everyone codes to the same standards. The specifics of the standard are not important:
what is important is that all the he code looks familiar, in support of collective ownership.

Case Study:
Question #1
You have been appointed a project manager within an information systems organization.
Your job is to build an application that is quite similar to others your team has built, although
this one is larger and more complex. Requirements have been thoroughly documented by
the customer. What software process model(s) would you choose and why? Explain in detail.
Answer:
As the information system already exists in which some development is to be made and released.
Now Developer just need to make some addition in the previous application because Customer
requirements are documented, which mean requirements are well understood and have no need to
modified requirement.
Process Selected:.
Prototype model will be used in development of this application. In prototype model application
or project is made in series of increment throughout project. In prototype model we first make a
prototype and give to the customer and make changes in it accordingly as required by the
customer. Further increment made after previous ones. Large systems are particularly suitable for
prototype model.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Prototype model is a strategy that allows system to be developed in pieces. Prototype

model allows the additions in process as per requirements, process change can be implemented.
To make this application we have to use the already existing application and make increments in
it and made new more complex and large application Requirements are fulfilled already for this
application.
Question# 2
University of Gujarat is currently running through different departments like
Administration, Accounts, Examination, Admission, Library, Computer Labs, Faculty
Management, and Student Management etc. Every department has its own specific processes
and each department is using computer-based system to some extent but not complete
computer based solutions. There is also inter-departmental communication for the smooth
running of all functions in respective departments. It is decided by the higher management
that all the departments should be integrated under one system and that system should
accommodate all the processes existing in all departments. It is also decided that if this system
is implemented successfully then it will also be used in other departments of University of
Gujarat independently after configuring it according to their needs. Higher Management
wants to see this system within this year. Risks, which can arise, should be accommodated
implicitly keeping the time factor in mind. As the system will be used in public sector, so
verification and validation factors must be administered accordingly. What software process
model(s) would you choose and why? Explain in detail

System need modification and integration .System is large and use in public sector .University of
Gujarat all department use this system according to their needs, which mean departments have
some same function and some different function. Risks analysis is also important factor which
should be resolve in given time frame. As system use in public sector, so verification and validation
factors must be administered accordingly.
Selected Process Model:
Selected process model is “Component Model” use to develop this system.
In the majority of software projects, there is some software reuse. This often happens informally
when people working on the project know of designs or code that are similar to what is required.
They look for these, modify them as needed, and incorporate them into their system. A general
process model for reuse-based development. Although the initial requirements specification stage
and the validation stage are comparable with other software processes, the intermediate stages in
a reuse oriented process are different. These stages are:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

1. Component analysis given the requirements specification, a search is made for components to
implement that specification. Usually, there is no exact match and the components that may be
used only provide some of the functionality required.
2. Requirements modification during this stage, the requirements are analyzed using information
about the components that have been discovered. They are then modified to reflect the available
components. Where modifications are impossible, the component analysis activity may be re-
entered to search for alternative solutions.
3. System design with reuse during this phase, the framework of the system is designed or an
existing framework is reused. The designers take into account the components that are reused and
organize the framework to cater for this. Some new software may have to be designed if reusable
components are not available.
4. Development and integration Software that cannot be externally procured is developed, and the
components and COTS systems are integrated to create the new system. System integration, in this
model, may be part of the development process rather than a separate activity.
Component software engineering has the obvious advantage of reducing the amount of software
to be developed and so reducing cost and risks. It usually also leads to faster delivery of the
software.System boundaries should be defined and clearly specified in a component-based
approach requirement analysis also implies that it is necessary to analyze whether requirements
can be fulfilled with available components. System is use in public sector. All departments have
some same function and some different function .We use component base approach to reuse the
same component in this way we reduce our code and save time. This becomes important as we
complete project in this year. The risk is analysis in every component by doing this risk is reducing
and project become more accurate and efficient. This project approach is as useful when we need
to modifier the some component we do not need to modify all project we just modify that
component. Another reason for using this approach is to save time and complete this project in
given time frame, risk is also reduce by this approach. Validation and verification also made on
each component.
Question #3
You have been appointed a project manager for a major software products company. Your
job is to manage the development of the next generation version of its widely used word-
processing software. Because competition is intense, tight deadlines have been established
and announced. What software process model(s) would you choose and why?
Assumptions
We have to use that process model which meets the requirements to make the version in the given
time limit because the deadline has been defined already.
Selected Process Model
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

We will use the RAD (Rapid Application Development) model because tight deadline has been
announced for project completion. We need to modify the previous version of word-processing
software. As Rapid Application Development is a linear sequential software development process
model that emphasizes an extremely short development cycle.
A component-based construction approach is used. There can be several teams working on
different components during this time limit announced.

Question# 4
You have been asked to develop a small application that analyzes each course offered by a
university and reports the average grade obtained in the course (for a given term). What
software model(s) would you choose and why?
As the requirements are simply known and understood that we have to just develop a small
application that analyzes each course offered by a university and reports the average grade obtained
in the course
Selected Process Model:
The sequential/Waterfall Model is better for this application. Because water fall model is used
when the requirements are well understood for the start and no changes are needed in that so as
the requirements of the application is well understood for the start so waterfall model is suitable
for this.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Anna University Questions

Apr/May 2015
PART-A
1. Write the Process framework and Umbrella activities. (April/May 2015) Q.NO. 61
2. State the advantages and disadvantages in LOC based Cost Estimation. (April/May 2015)
Q.NO. 62
PART-B
1.(a) Write short notes on COCOMO model. Discuss about the COCOMO models(Basic,
Intermediate and Detailed) for cost estimation. (16) Q.NO. 7
(b) Neatly explain the following process models and write their advantages and disadvantages.
Apr/ May 2015 Q.NO. 13

(i) Spiral model (8)

(ii) Rapid Application Development model.(8)
Nov/dec 2015
PART-A
1. What are the pros and cons of Iterative software development models? Q.NO. 63
2. What are the issues in measuring the software size using LOC as metric? Q.NO. 64

PART-B
1.a)Assume that you are the technical manager of a software development organization. A client
approached you for a software solution. The problems stated by the client have uncertainties which
lead to loss if it not planned and solved. Which software development model you will suggest for
this project — justify. Explain that model with its pros and cons and neat sketch. (16) Q.NO. 16

b) (i) Explain the various levels of capability maturity model intergation. (10) Q.NO. 14
(ii) What are the pros and cons of using mathematical approach for software development?. (6)
Q.NO. 15
May/June 2016
PART-A

1. What led to the transition from product oriented development to process oriented
development? (Q.No. 57)
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

2. Mention the characteristics of software contrasting it with characteristics of hardware.

PART-B
1. (i) Discuss the prototyping model. What is the effect of designing a prototype on the overall
cost of the software project?(8) (Q.No. 3)
(ii) Describe the type of situations where iterative enhancement model might lead to
difficulties.(8) (Q.No. 2)
2. Elucidate the key features of the software process models with suitable examples.(8)
(ii) What is the role of user participation in the selection of a life cycle model?(8) (Q.No. 2)

Nov/Dec 2016

PART-A
1. If you have to develop a word processing software product, what process model will you
choose? (Q.No. 59)
2. Depict the relationship between Work product, task, activity and System. (Q.No. 60)
PART-B
1. (a) Which process model is best suited for risk management? Discuss in detail with an
example. Give the advantages and disadvantages of the model. (16) (Q.No. 10)
2. (i) List the principles of agile software development.(8) (Q.No. 11)
Apr/May 2017
PART-A
1. Depict the relationship between work product, task, activity and system. (Q.No. 60)
2. List two deficiencies in waterfall model. Which process model do you suggest to overcome
each deficiency? (Q.No. 65)

PART-B
1. (a) What is a process model? Describe the process model that you would choose to
manufacture a car. Explain giving suitable reasons. (13) (Q.No. 17)
(b) (i)How function point analysis methodology is applied in estimation of software size?
Explain. Why FPA methodology is better than LOC methodology? (8) (Q.No. 6)

(ii) An application has the following: 10 Low External Inputs, 12 High External
Outputs, 20 Low Internal Logical Files, 15 High External Int erface Files, 12 Average
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

Ext ernal Inquir ies, and a value adjustment factor of 1.10. What is the unadjusted
and adjusted function point count? (5) (Q.No. 18)

Nov/Dec 2017
PART-A
1. Write the IEEE definit ion of software engineer ing. (Q.No. 1)
2. Why LOC is not a better metric to estimate a software ? (Q.No. 66)
PART-B
1. a) i) What is the impact of reusability in software development process ?(4) (Q.No. 19)
ii) Explain the component based software development model with a neat sketch.(9)
(Q.No.19)
2. i) Write a note on the unique characters of a software.(3) (Q.No. 20)
(ii) What is the significance of the spiral model when compared with other models. (3)
(iii)Explain the CMMI model to assess the organization level. (7)(Q.No. 14)
PART-C
1. List out the various umbrella activities which support software development process.
Discuss about their necessity in maintaining the quality in both software process and
product that is being developed for railway reservation system.(15) Nov/Dec 2017 (Q.No.
1)

Apr/May 2018

PART A

1. What is software? List its characteristics. (Q.No.2) (Q.No.3)

2. If you have to develop a word processing software product, what process model will you
choose? Justify your answer. (Q.No.59)

PART B

1. Which software process model is good for risk management? Explain the model. Describe
how the model is used to layout the objectives, risks and plans for quality improvement. (Q.No.3)
Nov/Dec 2018
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

PART A

1. List the characteristics of software. (Q.No.3)

2. Name the umbrella activities in software process. (Q.No.8)

PART B

1. (a) Assume that you are the technical manager of a software development organization. A client
approached you for a software solution. The problems stated by the client have uncertainties which
lead to loss if it is not planned and solved. What software development model you will suggest
for this project? Justify. Explain that model with a neat sketch along with its pros and cons.
(Q.No.16)

(b) (i) Draw the layered architecture of software engineering (3) (Part –A Q.No.79

(ii) What are the merits and demerits of using formal methods for developing software? (3)
(Part-A Q.No.80)

(iii) Explain the CMMI model to assess the organization level. (7) (Q.No.14)

April/May 2019
PART A
1. Define: Software Engineering.
2. List any two agile process models.
PART B
11) a) Compare the waterfall, Prototyping and spiral model. List the features of each model,
advantages and disadvantage and a type of application where the model will be acceptable.
b) i) Define Agility. List any Five principles of agility.
ii) Explain the phases in Extreme Programming process.
NOV/DEC 2019
PART A
What is a software process?
Define an evolutionary prototype.
PART B
11 a) Outline the spiral life cycle model with a diagram.
b) What is agility? Elaborate the agile principles.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 1

April/May 2021

PART A

1 List out the goals of software engineering. (Q.No.20)

2. What are the various categories of software? (Q.No.4)

PART B

11. a) Compare and contrast waterfall model, spiral model and iterative model. (Q.No.23)

b) Define Agile Programming. Explain the 12 practices of extreme programming. (Q.No.24)

NOV/DEC 2021

PART A

1. List out the five activities of a generic process framework for software engineering. (Q.No.19)

2. Draw the flow diagram of Iterative process flow and parallel flow. (Q.No.61)
PART B
11 a) List out the various prescriptive process model available in software development, with
appropriate diagram, discuss any two prescriptive process model in detail. (Q.No.2)

b) Explain the 12 practices of extreme programming. Explain how agility is achieved in extreme
programming. (Q.No.24)
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

UNIT II REQUIREMENTS ANALYSIS AND SPECIFICATION

Requirement analysis and specification – Requirements gathering and analysis – Software Requirement
Specification – Formal system specification – Finite State Machines – Petri nets – Object modeling using
UML – Use case Model – Class diagrams – Interaction diagrams – Activity diagrams – State chart
diagrams – Functional modeling – Data Flow Diagram- CASE TOOLS.

PART A
1. What are functional requirements?
Functional requirements are statements of the services that must provide descriptions of how
computations must be carried out. Domain requirements are functional requirements that are derived
from characteristics of the application domain.
2. What are non-functional requirements?
Non-functional requirements are product requirements that constrain the system being developed,
process requirements which apply to the development process and external requirements. They
often relate to the emergent properties of the system and so apply to the system as a whole.
3. Classify the different types of non-functional requirements.
The different types of non-functional requirements can be classified as:
 Product requirements
 Organizational requirements
 External requirements
4. List the metrics for specifying non – functional requirements.
The possible metrics that specify the non-functional requirements are:
 Speed
 Size
 Ease of Use
 Reliability
 Robustness
 Portability
5. Draw the DFD notations for the following.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

i. External entity -

ii. Data items - MEC

6. What is the need for user requirements? Mention the problems that arise when requirements
are written in natural language.
User requirements are useful for people involved in using and procuring the system. The
problems that arise when requirements are written in natural language are:
 Back of clarity
 Requirement§ confusion
 Requirements amalgamation
7. What does requirement process involve?
 requirements elicitation
 requirements analysis and negotiation
 requirements specification
 system modeling
 requirements validation
 requirements management
8. What guidelines do you think will minimize misunderstandings when writing user
requirements?
To minimize misunderstandings when writing user requirements, the following guidelines can
be used:
 Invent a standard format and ensure that all requirement definitions adhere to that format.
 Use language consistency.
 Use text highlighting
 Avoid, as far as- possible, the use of computer Jargon.
9. Write short notes on system requirements.
System requirements are intended to communicate, in a precise way, the functions which the
system must provide. To reduce ambiguity, they may be written in a structured language of some
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

kind. This can be a structured form of a natural language, a language based on a high-level
programming language or a special language for-requirements specification.
10. List the notations used for requirements specification.
The notations used for requirements specification are:
 Structured natural language.
 Design description languages.
 Graphical notations.
 Mathematical specifications.
11. What information must be included while specifying functional requirements?
The information to be included while specifying functional requirements are given below:
 A description of the function or entity being specified.
 A description of its inputs and where these come from.
 A description of its outputs and where these to.
 An indication of why other entities are used.
 If a functional approach is used, a pre-condition setting out what must be true before the
function is called and a post-condition specifying what is true after the function is called.
 A description of the side-effects of the operation. (if any).
12. What is a software requirements document (SRD)?
A software requirements document (also called as software requirements specification or SRS) is
the official statement of what is required of the system Developers. It should include both the user
requirements for a system and a detailed specification of the system requirements.
13. What is meant by Requirements Engineering?
Requirements Engineering is a process that involves all the activities required to create and
maintain a system requirements document.
The process activities include
 a feasibility study,
 elicitation and analysis of requirements,
 The specification of requirements and their documentation and
 The validation of these requirements.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

14. Why is it so difficult to gain a clear understanding of what the customer wants?
It is difficult to gain a clear understanding of what the customer wants, due to the following
reasons:
 Problems of scope: The boundary of the system is well-defined.
 Problems of understanding: Customers/users have a poor understanding of the capabilities
and limitations of their computing environment.
 Problems of volatility: The requirements change over time.
15. What is the use of requirements validation?
Requirements validation examines the specification to ensure that all system 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.
16. List the type of checks that needs to be carried out on the requirements in the requirements
document during the validation process.
The checks that should be carried out during the validation process-are:
 Validity checks
 Consistency checks
 Completeness checks
 Realism checks
 Verifiability
17. List four requirements validation techniques.
The four requirements validation techniques are:
 Requirement reviews
 Prototyping
 Test-case generation
 Automated consistency analysis
18. Why do new requirements emerge?
New requirements emerge for the following reasons:
 Large systems usually have a diverse user community. Different users have different
requirements and priorities. These may be conflicting or contradictory.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 System customers impose requirements because of organizational and budgetary constraints.

These may conflict with end-user requirements.
 The business and technical environment of the system changes and these must be reflected in the
system, itself.
19. What is meant by requirements management?
Requirements management is the process of understanding and controlling changes to system
requirements. The process of requirements management is carried out in conjunction with other
requirements engineering processes.
20. Classify requirements from an evolution perspective.
From an evolution perspective, requirements fall into two classes:
 Enduring requirements: These are relatively stable requirements that derive from the core
activity of the organization and relate to the domain of the system.
 Volatile requirements: These are requirements that are likely to change during the system
development or after the system has been put into operation.
21. Classify Volatile requirements.
Volatile requirements fall into four categories:
 Mutable requirements
 Emergent requirements
 Consequential requirements
 Compatibility requirements
22. Write short notes on planning.
Planning is an essential stage in requirements management process that establishes the level of
requirements management detail that is required. The following must be decided during the requirements
management stage:
 Requirements identification
 Change management process
 Traceability policies
 CASE tool support
23. Explain change management process.
Change management process:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

The process starts with an identified requirements problem, sometimes with a specific change
proposal. The effect of the proposed change is assessed using traceability information and general
knowledge of system requirements. Once analysis is completed, a decision is made whether or not to
proceed with the requirements-change. The requirements document and, where necessary, the system
design and implementation are modified.
24. What is a prototype? List any four benefits of using prototyping in software process.
A prototype is an initial version of a software system, which is used to demonstrate concepts,
tryout design options and generally, to find out more about the problem and its possible solutions.
The benefits of using prototyping in the software process are:
 Improved system usability.
 A closer match of the system to the User needs.
 Improved maintainability.
 Reduced development effort.
 Prototype serves as a basis for deriving system specification.
 Design quality can be improved.
 System can be maintained easily.
 Development efforts may get reduced.
25. What are the prototyping approaches in software process?
Evolutionary prototyping
 The objective is, to deliver a working system to end users.
 They should have a robust structure so that they are maintainable for many years
 They should be reliable and efficient and they should conform to relevant organizational
standards.
 In this approach of system development, the initial prototype is prepared and it is then refined
through number of stages to final stage.
Throw-away prototyping
 The objective is to validate or derive the system requirements.
 They have a short lifetime.
 Poor performance and reliability may be acceptable.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Using this approach a rough practical implementation of the system is produced. The requirement
problems can be identified from this implementation. It is then discarded. System is then
developed using some different engineering paradigm

26. What is requirement engineering?

Requirement engineering is the process of establishing the services that the customer requires
from the system and the constraints under which it operates and is developed.

27. What are the characteristics of SRS?

 Correct – The SRS should be made up to date when appropriate requirements are identified.
 Unambiguous – When the requirements are correctly understood then only it is possible to
write unambiguous software.
 Complete – To make SRS complete, it should be specified what a software designer wants to
create software.
 Consistent – It should be consistent with reference to the functionalities identified.
 Specific – The requirements should be mentioned specifically.
 Traceable – What is the need for mentioned requirement? This should be correctly identified
28. What is ERD?
Entity Relationship Diagram is the graphical representation of the object relationship pair. It is
mainly used in database applications.

29. What is DFD?

Data Flow Diagram depicts the information flow and the transforms that are applied on the data
as it moves from input to output.

30. What does Level0 DFD represent?

Level0 DFD is called as ‘fundamental system model’ or ‘context model’. In the context model
the entire software system is represented by a single bubble with input and output indicated by incoming
and outgoing arrows.

31. What are the elements of Analysis model?

 Data Dictionary
 Entity Relationship Diagram
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Data Flow Diagram

 State Transition Diagram
 Control Specification
 Process specification

37. Write a note on Feasibility studies. What is the need for feasibility analysis?
 The requirements engineering process should start with a feasibility study. The input to the feasibility
study is a set of preliminary business requirements, an outline description of the system and how the
system is intended to support business processes.
 The results of the feasibility study should be a report that recommends whether or not it is worth
carrying on with the requirements engineering and system development process.
 A feasibility study is a short, focused study that aims to answer a number of questions:

1. Does the system contribute to the overall objectives of the organisation?

2. Can the system be implemented using current technology and within given cost and schedule
constraints?
3. Can the system be integrated with other systems which are already in place?

An alternative perspective of requirement engineering process

38. Define Data Abstraction.

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Abstraction is the process by which data and programs are defined with a representation similar
in form to its meaning (semantics), while hiding away the implementation details. Abstraction tries
to reduce and factor out details so that the programmer can focus on a few concepts at a time.
39. What are the types of prototypes?

Types of prototyping

1. Throwaway prototyping
2. Evolutionary prototyping
3. Incremental prototyping
4. Extreme prototyping
40. What are the linkages between data flow and E-R diagram?

 An ER diagram is the Entity Relationship Diagram, showing the relationship between different
entities in a process.
 A Data Flow diagram is a symbolic structure showing how the flow of data is used in different
process stages.
41. Classify the following as functional/ non-functional requirements for a banking system.
(a) Verifying bank balance
(b) Withdrawing money from bank
(c) Completion of transactions in less than one second
(d) Extending the system by providing more tellers for customers.

42. Draw a use case diagram for an online shopping which should provide provisions for
registering, authenticating the customers and also for online payment through any payment
gateway like paypal.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

43. Write a brief notes on Petri Nets.

A Petri net is a particular kind of bipartite directed graphs populated by three types of objects.
 These objects are places, transitions, and directed arcs.
 Directed arcs connect places to transitions or transitions to places.
 In its simplest form, a Petri net can be represented by a transition together with an input
place and an output place.
 This elementary net may be used to represent various aspects of the modeled systems.
44. State two advantages of using Petri Nets.

Advantages:
 Mechanism for name management.
 Serves as a store of organizational information.
 Software might be integrated with other tools
 Design the software and test cases.
45. Requirements engineering builds a bridge to design and construction, but where does the
bridge originate? Nov/Dev 2021
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Begins at the feet of the project stakeholders, where business need is defined, user scenarios are
described, functions and features are delineated and project constraints are identified.

46. Define Design Class Diagrams.

A static view of the class definitions is usefully shown with a design class diagram. This
illustrates the attributes and methods of the classes.
47. What is UML?
The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
48. Define the inception step.
Inception is the initial short step to establish a common vision and basic scope for the project.
It will include analysis of perhaps 10% of the use cases, analysis of the critical non- functional
requirement, creation of a business case, and preparation of the development environment so that
programming can start in the elaboration phase. Inception in one sentence: Envision the product
scope, vision, and business case.
49. What Artifacts May Start in Inception?
Some sample artifacts are Vision and Business Case, Use-Case Model, Supplementary
Specification, Glossary, Risk List & Risk Management Plan, Prototypes and proof-of-concepts etc.

50. Define Requirements and mention its types.

Requirements are capabilities and conditions to which the system and more broadly, the
project must conform.

 Functional
 Reliability
 Performance
 Supportability
51. What are Actors?
An actor is something with behavior, such as a person (identified by role), computer system,
or organization; for example, a cashier.
52. What is a scenario?
A scenario is a specific sequence of actions and interactions between actors and the system;
it is also called a use case instance. It is one particular story of using a system, or one path through
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

the use case; for example, the scenario of successfully purchasing items with cash, or the scenario
of failing to purchase items because of a credit payment denial.
53. Define Use case.
A use case is a collection of related success and failure scenarios that describe an actor using
a system to support a goal. Use cases are text documents, not diagrams, and use-case modeling is
primarily an act of writing text, not drawing diagrams.
54. What Tests Can Help Find Useful Use Cases?
The Boss Test
The EBP Test
The Size Test
55. What are Use Case Diagrams?
A use case diagram is an excellent picture of the system context; it makes a good context
diagram that is, showing the boundary of a system, what lies outside of it, and how it gets used. It
serves as a communication tool that summarizes the behavior of a system and its actors.
56. What are Activity Diagrams?
A diagram which is useful to visualize workflows and business processes. These can be a
useful alternative or adjunct to writing the use case text, especially for business use cases that describe
complex workflows involving many parties and concurrent actions.
57. What are the three ways to apply UML?

1) UML as sketch Informal and incomplete diagrams created to explore difficult parts of the
problem or solution space, exploiting the power of visual languages.

2) UML as blueprint relatively detailed design diagrams used either for

i) Reverse engineering to visualize and better understanding existing code in UML

diagrams,

ii) Code generation (forward engineering).

3) UML as programming language - Complete executable specification of a software system in

UML. Executable code will be automatically generated, but is not normally seen or modified by
developers; one works only in the UML "programming language”.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

58. What are the three perspectives to apply UML?

Three Perspectives to Apply UML

1. Conceptual perspective the diagrams are interpreted as describing things in a

situation of the real world or domain of interest.

2. Specification perspective the diagrams describe software abstractions or components

with specifications and interfaces, but no commitment to a particular implementation (for
example, not specifically a class in C# or Java).

3. Implementation perspective the diagrams describe software implementations in a

particular technology (such as Java).

59. Define Conceptual Class.

Conceptual class is a real-world concept or thing. A conceptual or essential perspective is

the UP-Domain Model contains conceptual classes.
60. Define Software Class and Implementation class.

Software class a class representing a specification or implementation perspective of a

software component, regardless of the process or method.
Implementation class a class implemented in a specific OO language such as Java.
61. What is the Unified Process (UP)?

 A software development process describes an approach to building, deploying, and

possibly maintaining software.
 The Unified Process has emerged as a popular iterative software development process
for building object-oriented systems.
 In particular, the Rational Unified Process or RUP, a detailed refinement of the Unified
Process, has been widely adopted.
62. What is the importance of the Unified Process (UP)?

1) The UP is an iterative process. Iterative development influences how to introduce OOA/D,

and to understand how it is best practiced.
2) UP practices provide an example structure for how to do and thus how to explain OOA/D.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

3) The UP is flexible, and can be applied in a lightweight and agile approach that includes
practices from other agile methods (such as XP or Scrum).

63. What are the benefits of iterative development?

Benefits include:

 less project failure, better productivity, and lower defect rates; shown by research into
iterative and evolutionary methods
 early rather than late mitigation of high risks (technical, requirements, objectives,
usability, and so forth) early visible progress
 early feedback, user engagement, and adaptation, leading to a refined system that
more closely meets the real needs of the stakeholders
 managed complexity; the team is not overwhelmed by "analysis paralysis" or very
long and complex steps
 the learning within an iteration can be methodically used to improve the development
process itself, iteration by iteration
64. What are the other Critical UP practices?

The idea for UP practice is short time boxed iterative, evolutionary, and adaptive
development. Some additional best practices and key ideas in UP are

a) Tackle high-risk and high-value issue in early iterations

b) Continual evaluation, feedback and requirements from users
c) Build cohesive, core architecture in early iterations
d) Continuously verify quality; test early, often and realistically
e) Practice Change Request and Configuration Management
65. What are the different Unified process Phases? (NOV/DEC 2021)

An UP Project organizes work and iterations across four major phases:

1) Inception – approximate Vision, Business case, Scope, vague estimates

2) Elaboration – Refined Vision, iterative implementation of the core architecture,
resolution of high risks, identification of most requirements and scope, more realistic
estimates
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

3) Construction – Iterative implementation of the remaining lower risk and easier

elements, and preparation for deployment
4) Transition – beta tests, deployment
66. What are the UP disciplines?

In the UP, an artifact is the general term for any work product: Code, Web Graphics, Schema,
Test documents, diagrams, model and so on.

Some of the artifacts in the following Disciplines are:

a) Business Modeling – The Domain Model artifact, to visualize noteworthy

concepts in the application domain
b) Requirements – The Use Case Model and Supplementary specification artifacts
to capture functional and non-functional requirements
c) Design – The Design Model artifact, to design the software artifacts
d) Implementation – Programming and building the system, not deploying it
67. What is Use-case Modeling?

Use-Case Model is the set of all written use cases; it is a model of the system's
functionality and environment. Use cases are text documents, not diagrams, and use-case
modeling is primarily an act of writing text, not drawing diagrams. The Use-Case Model may
optionally include a UML use case diagram to show the names of use cases and actors, and their
relationships. This gives a nice context diagram of a system and its environment. It also provides
a quick way to list the use cases by name.

68. What are preconditions?

Preconditions state what must always be true before a scenario is begun in the use case.
Preconditions are not tested within the use case; rather, they are conditions that are assumed to be
true. Typically, a precondition implies a scenario of another use case, such as logging in, that has
successfully completed.

Example:

Preconditions: Cashier is identified and authenticated.

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

69. What are the types and categories of requirements?

In the UP, requirements are categorized according to the FURPS+ model [Grady92], a
useful mnemonic with the following meaning:

 Functional - features, capabilities, security.

 Usability - human factors, help, documentation.
 Reliability - frequency of failure, recoverability, predictability.
 Performance - response times, throughput, accuracy, availability, resource usage.
 Supportability - adaptability, maintainability, internationalization, configurability.
70. What are the three kinds of Actors?

Actors are roles played not only by people, but by organizations, software, and machines.

There are three kinds of external actors in relation to the SuD:

1) Primary actor has user goals fulfilled through using services of the SuD. For example,
the cashier.
Why identify? To find user goals, which drive the use cases.

2) Supporting actor provides a service (for example, information) to the SuD. The
automated payment authorization service is an example. Often a computer system, but
could be an organization or person.
Why identify? To clarify external interfaces and protocols.

3) Offstage actor has an interest in the behavior of the use case, but is not primary or
supporting; for example, a government tax agency.
Why identify? To ensure that all necessary interests are identified and satisfied.

71. What are Success guarantees (or postconditions)?

Success guarantees (or postconditions) state what must be true on successful completion
of the use case either the main success scenario or some alternate path. The guarantee should
meet the needs of all stakeholders.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Example: Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated.

Accounting and Inventory are updated. Commissions recorded. Receipt is generated.

72. Define use case Include relationships.

Use cases can be related to each other. It is common to have some partial behavior that
is common across several use cases. For example, the description of paying by credit occurs in
several use cases, including Process Sale, Process Rental, Contribute to Lay-away Plan, and so
forth. Rather than duplicate this text, it is desirable to separate it into its own subfunction use case,
and indicate its inclusion. This is simply refactoring and linking text to avoid duplication.

73. Define use case Extend relationships.

Extend Relationship

 Extend puts additional behavior in a use case that does not know about it.
 It is shown as a dotted line with an arrow point and labeled <<extend>>
 In this case, a customer can request a catalog when placing an order
74. List the relationships used in use cases.
(Or) List any two common ways to relate use cases and give suitable examples.

 include Relationship
 extend Relationship
 generalize Relationship
75. List out the steps for finding use cases.
 Choose the system boundary.
 Identify the primary actors those that have goals fulfilled through using services of
the system.
 Identify the goals for each primary actor.
 Define use cases that satisfy user goals; name them according to their goal.
76. What is the need for modeling?

 Modeling is a common approach to modeling applications, systems, and business domains by

using the object-oriented paradigm throughout the entire development life cycles.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Modeling is a main technique heavily used by both OOA and OOD activities in modern software
engineering.

 Modeling typically divides into two aspects of work: the modeling of dynamic behaviors like
business processes and use cases, and the modeling of static structures like classes and components.

77. Define CASE TOOLS.

 Computer Aided Software Engineering (CASE) tools are set of software application programs,
which are used to automate SDLC activities.

 CASE tools are used by software project managers, analysts and engineers to develop software
system.

 Use of CASE tools accelerates the development of project to produce desired result and helps to
uncover flaws before moving ahead with next stage in software development.

78. List out the CASE tools.

 There are number of CASE tools available to simplify various stages of Software Development
Life Cycle such as,
o Analysis tools
o Design tools
o Project management tools
o Database Management tools
o Documentation tools.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

PART - B
1. Explain in detail about different types of software requirements.

Software Requirements: Software requirement system states ―what the system should do and define
constraints on its operation and implementation. Two Types of requirements are:
1. User requirements
2. System requirements
User Requirements:
 User requirements are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must operate.

System Requirements:

 System requirements are more detailed descriptions of the software system’s functions, services,
and operational constraints. The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented.
Example:
 Figure 2.1 illustrates different types of requirements specification.
 Example from a mental health care patient management system (MHC-PMS) shows how a user
requirement may be expanded into several system requirements.

Types of Software system requirements:

 Software system requirements are often classified as functional requirements or non functional
requirements
1. Functional requirements: These are statements of services the system should
provide, how the system should react to particular inputs, and how the system should
behave in particular situations.
2. Non-functional requirements: These are constraints on the services or functions
offered by the system. They include timing constraints, constraints on the development
process, and constraints imposed by standards. Non-functional requirements often apply
to the system as a whole, rather than individual system features or services.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Fig. 2.1 - Types of readers for the user and system requirements.

 Functional Requirements:
 The functional requirements for a system describe “what the system should do?”
 For example, here are examples of functional requirements for the MHC-PMS system, used to
maintain information about patients receiving treatment for mental health problems:
1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are expected to
attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her eight-digit
employee number.

 These functional user requirements define specific facilities to be provided by the system.
 Imprecision in the requirements specification is the cause of many software engineering
problems.
 It is natural for a system developer to interpret an ambiguous requirement in a way that
simplifies its implementation. Often, however, this is not what the customer wants.
 New requirements have to be established and changes made to the system. Of course, this
delays system delivery and increases costs.
 In principle, the functional requirements specification of a system should be both complete and
consistent.
 Completeness means that all services required by the user should be defined.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Consistency means that requirements should not have contradictory definitions.

 In practice, for large, complex systems, it is practically impossible to achieve requirements
consistency and completeness.
 One reason for this is that it is easy to make mistakes and omissions when writing specifications
for complex systems.
 Another reason is that there are many stakeholders in a large system.
 A stakeholder is a person or role that is affected by the system in some way.
 Stakeholders have different— and often inconsistent—needs. These inconsistencies may not be
obvious when the requirements are first specified, so inconsistent requirements are included in
the specification.
 The problems may only emerge after deeper analysis or after the system has been delivered to the
customer.
Non-Functional Requirements: (Refer Figure 2.2)
 Non-functional requirements are requirements that are not directly concerned with the specific
services delivered by the system to its users.
 They may relate to emergent system properties such as reliability, response time, and store
occupancy.
 Non-functional requirements, such as performance, security, or availability, usually specify or
constrain characteristics of the system as a whole.
 Non-functional requirements are often more critical than individual functional requirements.
 System users can usually find ways to work around a system function that doesn’t really meet
their needs.
 However, failing to meet a non-functional requirement can mean that the whole system is
unusable.
 For example, if an aircraft system does not meet its reliability requirements, it will not be
certified as safe for operation;
 If an embedded control system fails to meet its performance requirements, the control functions
will not operate correctly.
1. Product requirements:
 These requirements specify or constrain the behavior of the software.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Examples include performance requirements on how fast the system must execute and how
much memory it requires, reliability requirements that set out the acceptable failure rate,
security requirements, and usability requirements.
2. Organizational requirements:
 These requirements are broad system requirements derived from policies and procedures in
the customer’s and developer’s organization.
 Examples include operational process requirements that define how the system will be used,
development process requirements that specify the programming language, the development
environment or process standards to be used, and environmental requirements that specify the
operating environment of the system.
3. External requirements:
 This broad heading covers all requirements that are derived from factors external to the system
and its development process.
 These may include regulatory requirements that set out what must be done for the system to be
approved for use by a regulator, such as a central bank;
 Legislative requirements that must be followed to ensure that the system operates within the
law;
 Ethical requirements that ensure that the system will be acceptable to its users and the general
public.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.2 - classification of non-functional requirements

Table 2.1 - Metrics to specify non-functional system properties.

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

2. Explain in detail about Requirements Analysis and Specification. (or) Elaborate in detail about each
phases/steps in Requirements gathering and analysis.

 All plan-driven life cycle models prescribe that before starting to develop software, the exact
requirements of the customer must be understood and documented.
 Starting development work without properly understanding and documenting the requirements
increases the number of iterative changes in the later life cycle phases, and thereby alarmingly pushes
up the development costs.
 A good requirements document not only helps to form a clear understanding of various features
required from the software, but also serves as the basis for various activities carried out during later
life cycle phases.
Overview of requirements analysis and specification:
 The requirements analysis and specification phase starts after the feasibility study stage is complete
and the project has been found to be financially viable and technically feasible.
 The requirements analysis and specification phase ends when the requirements specification document
has been developed and reviewed.
 The requirements specification document is usually called the software requirements specification
(SRS) document.
 The goal of the requirements analysis and specification phase is to clearly understand the customer
requirements and to systematically organize the requirements into a document called the Software
Requirements Specification (SRS) document.
Who performs requirements analysis?
 Requirements analysis and specification activity is usually carried out by a few experienced members
of the development team.
 It normally requires them to spend some time at the customer site.
 The engineers who gather and analyze customer requirements and then write the requirements
specification document are known as system analysts. Requirements analysis and specification phase
mainly involves carrying out the following two important activities:
o Requirements gathering and analysis.
o Requirements specification.
Requirements gathering and analysis:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 The complete set of requirements is almost never available in the form of a single document from
the customer.

 Complete requirements are rarely obtainable from any single customer representative.

 We can conceptually divide the requirements gathering and analysis activity into two separate tasks:
Requirements gathering and Requirements Analysis

Requirements gathering:

 Requirements gathering are also popularly known as requirements elicitation.

 The primary objective of the requirements gathering task is to collect the requirements from the
stakeholders.

 A stakeholder is a source of the requirements and is usually a person, or a group of persons who
either directly or indirectly are concerned with the software.

 It is very difficult to gather all the necessary information from a large number of stakeholders and
from information scattered across several pieces of documents.

 Gathering requirements turns out to be especially challenging if there is no working model of the
software being developed.

 Important ways in which an experienced analyst gathers requirements:

Studying existing documentation:

 The analyst usually studies all the available documents regarding the system to be developed before
visiting the customer site.

 Customers usually provide a statement of purpose (SoP) document to the developers.

Interview:

 Typically, there are many different categories of users of a software.

 Each category of users typically requires a different set of features from the software.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Therefore, it is important for the analyst to first identify the different categories of users and then
determine the requirements of each.

Task analysis:

 The users usually have a black-box view of software and consider the software as something that
provides a set of services (functionalities).

 A service supported by software is also called a task.

 The analyst tries to identify and understand the different tasks to be performed by the software.

 For each identified task, the analyst tries to formulate the different steps necessary to realize the
required functionality in consultation with the users.

Scenario analysis:

 A task can have many scenarios of operation.

 The different scenarios of a task may take place when the task is invoked under different situations.

 For different types of scenarios of a task, the behavior of the software can be different.

Form analysis:

 Form analysis is an important and effective requirements gathering activity that is undertaken by the
analyst, when the project involves automating an existing manual system.

 In form analysis the existing forms and the formats of the notifications produced are analyzed to
determine the data input to the system and the data that are output from the system.

Requirements analysis:

 After requirements gathering is complete, the analyst analyses the gathered requirements to form a
clear understanding of the exact customer requirements and to weed out any problems in the gathered
requirements.

 During requirements analysis, the analyst needs to identify and resolve three main types of problems
in the requirements:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Anomaly:

 An anomaly is an ambiguity in a requirement. When a requirement is anomalous, several

interpretations of that requirement are possible.

Example: While gathering the requirements for a process control application, the following requirement was
expressed by a certain stakeholder: “When the temperature becomes high, the heater should be switchedoff”.
Please note that words such as “high”, “low”, “good”, “bad” etc. are indications of ambiguous requirements
as these lack quantification and can be subjectively interpreted.

Incompleteness:

 An incomplete set of requirements is one in which some requirements have been overlooked. The
lack of these features would be felt by the customer much later, possibly while using the software.

Example: In chemical plant automation software, suppose one of the requirements is that if the
internal temperature of the reactor exceeds 200℃ then an alarm bell must be sounded. However,
on an examination of all requirements, it was found that there is no provision for resetting the
alarm bell after the temperature has been brought down in any of the requirements. This is clearly
an incomplete requirement.

3. Write detailed notes on Software Requirements Document or Software Requirements

Specification (SRS). What is SRS? Explain in detail the various components of SRS. Nov/Dec 2018.
 The software requirements document (sometimes called the software requirements specification
or SRS) is an official statement of what the system developers should implement.
 It should include both the user requirements for a system and a detailed specification of the
system requirements.
 Sometimes, the user and system requirements are integrated into a single description.
 In other cases, the user requirements are defined in an introduction to the system requirements
specification.
 If there are a large number of requirements, the detailed system requirements may be presented
in a separate document.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Requirements documents are essential when an outside contractor is developing the software
system.
 However, agile development methods argue that requirements change so rapidly that a
requirements document is out of date as soon as it is written, so the effort is largely wasted.
 Rather than a formal document, approaches such as Extreme Programming collect user
requirements incrementally and write these on cards as user stories.
 The user then prioritizes requirements for implementation in the next increment of the system.
 The requirements document has a diverse set of users, ranging from the senior management of
the organization that is paying for the system to the engineers responsible for developing the
software.

Figure 2.3 - Users of requirements document

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Table 2.2 - The Structure of a Requirements Document

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

4. Explain the Concepts of Requirement engineering process. (Or)

Write short notes on Feasibility study of Requirements Engineering Process.
 The requirements engineering process (Figure 2.4) aims to produce an agreed requirements
document that specifies a system satisfying stakeholder requirement. Requirements are usually
presented at two levels of detail.
 End-users and customers need a high-level statement of the requirements; system developers need
a more detailed system specification.
There are four main activities in the requirements engineering process:
1. Feasibility study :
 The study considers whether the proposed system will be cost-effective from a
business point of view and if it can be developed within existing budgetary
constraints.
 A feasibility study should be relatively cheap and quick.
2. Requirements elicitation and analysis:
 This is the process of deriving the system requirements through observation of
existing systems, discussions with potential users and procurers, task analysis, and
so on.
3. Requirements specification :
 Requirements specification is the activity of translating the information gathered
during the analysis activity into a document that defines a set of requirements.
 Two types of requirements may be included in this document. User requirements
are abstract statements of the system requirements for the customer and end-user
of the system.
4. Requirements validation
 This activity checks the requirements for realism, consistency, and
completeness.
 These focus on assessing if the system is useful to the business (feasibility
study),
 Discovering requirements (elicitation and analysis),
 Converting these requirements into some standard form (specification),
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Checking that the requirements actually define the system that the customer
wants (validation).
 In practice, requirements engineering is an iterative process in which the activities are
interleaved.
 Figure 2.4 shows the activities are organized as an iterative process around a spiral, with the
output being a system requirements document.
 The amount of time and effort devoted to each activity in each iteration depends on the stage
of the overall process and the type of system being developed.
 Early in the process, most effort will be spent on understanding high-level business and
non-functional requirements, and the user requirements for the system.
 Later in the process, in the outer rings of the spiral, more effort will be devoted to eliciting
and understanding the detailed system requirements.
 This spiral model accommodates approaches to development where the requirements are
developed to different levels of detail.
 The number of iterations around the spiral can vary so the spiral can be exited after some or
all of the user requirements have been elicited.
 Agile development can be used instead of prototyping so that the requirements and the
system implementation are developed together.

Figure 2.4 – A spiral view of the requirements engineering process

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 The aims of a feasibility study are to find out whether the system is worth implementing and if
it can be implemented, given the existing budget and schedule.
 The input to the feasibility study is a set of preliminary business requirements, an outline
description of the system and how the system is intended to support business processes.
 The results of the feasibility study should be a report that recommends whether or not it is worth
carrying on with the requirements engineering and system development process.
 If a system does not support the business objectives, it has no real value to the business.
 Carrying out a feasibility study involves information assessment, information collection and
report writing.

 Feasibility study should be completed in two or three weeks.

 The feasibility study report is generated when the information is available.

5. Write notes on Requirements Elicitation and Analysis of Requirement Engineering Process. (or)
What is requirements elicitation? Briefly describe the various activities performed in requirement
elicitation phase with an example of watch system that facilitates to set time and alarm. Nov/Dec
2018
 After an initial feasibility study, the next stage of the requirements engineering process is
requirements elicitation and analysis.
 In this activity, software engineers work with customers and system end-users to find out about
the application domain, what services the system should provide, the required performance of
the system, hardware constraints, and so on.

Figure 2.5 – The requirements elicitation and analysis process

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Requirements elicitation and analysis may involve a variety of different kinds of people
in an organization.
 A system stakeholder is anyone who should have some direct or indirect influence on
the system requirements.
 Stakeholders include end users who will interact with the system and anyone else in an
organization who will be affected by it.
 Other system stakeholders might be engineers who are developing or maintaining other
related systems, business managers, domain experts, and trade union representatives.
 A process model of the elicitation and analysis process is shown in Figure 2.5.
The process activities are:
1. Requirements discovery
This is the process of interacting with stakeholders of the system to discover their
requirements. Domain requirements from stakeholders and documentation are also
discovered during this activity. There are several complementary techniques that can be
used for requirements discovery.
2. Requirements classification and organization
This activity takes the unstructured collection of requirements, groups related
requirements, and organizes them into coherent clusters. The most common way of
grouping requirements is to use a model of the system architecture to identify sub- systems
and to associate requirements with each sub-system.
3. Requirements prioritization and negotiation
Inevitably, when multiple stakeholders are involved, requirements will conflict. This
activity is concerned with prioritizing requirements and finding and resolving
requirements conflicts through negotiation. Usually, stakeholders have to meet toresolve
differences and agree on compromise requirements.
4. Requirements specification
The requirements are documented and input into the next round of the spiral. Formal
or informal requirements documents may be produced.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

The process cycle starts with requirements discovery and ends with the requirements
documentation. The analyst’s understanding of the requirements improves with each
round of the cycle. The cycle ends when the requirements document is complete.
Eliciting and understanding requirements from system stakeholders is a difficult process
for several reasons:

 Stakeholders often don’t know what they want from a computer system except in the most
general terms; they may find it difficult to articulate what they want the system to do; they
may make unrealistic demands because they don’t know what is and isn’t feasible.

 Stakeholders in a system naturally express requirements in their own terms and with
implicit knowledge of their own work. Requirements engineers, without experience in the
customer’s domain, may not understand these requirements.
 Different stakeholders have different requirements and they may express these in different
ways. Requirements engineers have to discover all potential sources of requirements and
discover commonalities and conflict.

 Political factors may influence the requirements of a system. Managers may demand
specific system requirements because these will allow them to increase their influence in
the organization.

 The economic and business environment in which the analysis takes place is dynamic. It
inevitably changes during the analysis process. The importance of particular
requirements may change. New requirements may emerge from new stakeholders who
were not originally consulted.
Requirements Discovery
Requirements discovery (sometime called requirements elicitation) is the process of gathering
information about the required system and existing systems, and distilling the user and system
requirements from this information. Sources of information during the requirements discovery phase
include documentation, system stakeholders, and specifications of similar systems.
For example, system stakeholders for the mental healthcare patient information system include:
 Patients whose information is recorded in the system.
 Doctors who are responsible for assessing and treating patients.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Nurses who coordinate the consultations with doctors and administer some treatments.
 Medical receptionists who manage patients’ appointments.
 IT staff who are responsible for installing and maintaining the system.
 A medical ethics manager who must ensure that the system meets current ethical guidelines
for patient care.
 Healthcare managers who obtain management information from the system.
 Medical records staff who are responsible for ensuring that system information can be
maintained and preserved, and that record keeping procedures have been properly implemented.
Interviewing
Formal or informal interviews with system stakeholders are part of most requirements
engineering processes. In these interviews, the requirements engineering team puts questions to
stakeholders about the system that they currently use and the system to be developed. Requirements
are derived from the answers to these questions.
Interviews may be of two types:
1. Closed interviews, where the stakeholder answers a pre-defined set of questions.
2. Open interviews, in which there is no pre-defined agenda. The requirements engineering
team explores a range of issues with system stakeholders and hence develops a better
understanding of their needs.
Effective interviewers have two characteristics:
1. They are open-minded, avoid pre-conceived ideas about the requirements, and are willing to listen
to stakeholders. If the stakeholder comes up with surprising requirements, then they are willing to change
their mind about the system.
2. They prompt the interviewee to get discussions going using a springboard question, a requirements
proposal, or by working together on a prototype system. Saying to people ‘tell me what you want’ is
unlikely to result in useful information. They find it much easier to talk in a defined context rather than
in general terms.
Scenarios
 People usually find it easier to relate to real-life examples rather than abstract descriptions.
They can understand and criticize a scenario of how they might interact with a software
system.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Requirements engineers can use the information gained from this discussion to
formulate the actual system requirements.
 Scenarios can be particularly useful for adding detail to an outline requirements
description. They are descriptions of example interaction sessions.
 Each scenario usually covers one or a small number of possible interactions.
 Different forms of scenarios are developed and they provide different types of
information at different levels of detail about the system.

EXAMPLE: WATCH SYSTEM:

Types of Requirements:
Functional requirements: Interactions between the system and its environment independent from
implementation.
 The watch system must display the time based on its location.
Nonfunctional requirements: User visible aspects of the system not directly related to functional
behavior.
 The response time must be less than 1 second
 The accuracy must be within a second
 The watch must be available 24 hours a day except from 2:00am2:01am and 3:00am-3:01am
Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system
will operate.
Fig 2.6 shows use cases for MHC-PMS
A scenario starts with an outline of the interaction. During the elicitation process, details are added
to this to create a complete description of that interaction. At its most general, a scenario may include:
1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario finishes.
Use cases
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Use cases are a requirements discovery technique that were first introduced in the
Objectory method.
 They have now become a fundamental feature of the unified modeling language.

Figure 2.6 – Use cases for MHC - PMS

Ethnography
 Ethnography is an observational technique that can be used to understand operational
processes and help derive support requirements for these processes.
 An analyst immerses himself or herself in the working environment where the system
will be used.
 The day-to-day work is observed and notes made of the actual tasks in which
participants are involved.
The value of ethnography is that it helps discover implicit system requirements that reflect
the actual ways that people work, rather than the formal processes defined by the organization.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.7 – Ethnography & Prototyping for requirements analysis

Ethnography is particularly effective for discovering two types of requirements:

1. Requirements that are derived from the way in which people actually work, rather than the
way in which process definitions say they ought to work. For example, air traffic controllers may
switch off a conflict alert system that detects aircraft with intersecting flight paths, even though
normal control procedures specify that it should be used.
2. Requirements that are derived from cooperation and awareness of other people’s activities.
For example, air traffic controllers may use an awareness of other controllers’ work to predict the
number of aircrafts that will be entering their control sector. They then modify their control
strategies depending on that predicted workload. Therefore, an automated ATC system should
allow controllers in a sector to have some visibility of the work in adjacent sectors.

6. Write a brief notes on Requirements Validation of Requirement Engineering Process.

Requirements validation is the process of checking that requirements actually define the system
that the customer really wants.
 It overlaps with analysis as it is concerned with finding problems with the requirements.
 Requirements validation is important because errors in a requirements document can
lead to extensive rework costs when these problems are discovered during development
or after the system is in service.
During the requirements validation process, different types of checks should be carried out on the
requirements in the requirements document.
1. Validity checks
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

o A user may think that a system is needed to perform certain functions. However, further
thought and analysis may identify additional or different functions that are required.
o Systems have diverse stakeholders with different needs and any set of requirements is
inevitably a compromise across the stakeholder community.
2. Consistency checks
 Requirements in the document should not conflict. That is, there should not be
contradictory constraints or different descriptions of the same system function.
3. Completeness checks
 The requirements document should include requirements that define all functions and
the constraints intended by the system user.
4. Realism checks
 Using knowledge of existing technology, the requirements should be checked to
ensure that they can actually be implemented. These checks should also take account
of the budget and schedule for the system development.
5. Verifiability
 To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable.

This means that you should be able to write a set of tests that can demonstrate that the delivered system
meets each specified requirement.
There are a number of requirements validation techniques that can be used individually or in
conjunction with one another:
1. Requirements reviews
The requirements are analyzed systematically by a team of reviewers who check for errors
and inconsistencies.
2. Prototyping
In this approach to validation, an executable model of the system in question is demonstrated
to end-users and customers. They can experiment with this model to see if it meets their real
needs.
3. Test-case generation
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Requirements should be testable. If the tests for the requirements are devised as part of the
validation process, this often reveals requirements problems. If a test is difficult or
impossible to design, this usually means that the requirements will be difficult to implement
and should be reconsidered.

7. Write a short note on Requirements Management of Requirement Engineering Process. (or)

Describe the requirements change management process in detail.
The requirements for large software systems are always changing.
 One reason for this is that these systems are usually developed to address ‘wicked’ problems—
problems that cannot be completely defined.
 Because the problem cannot be fully defined, the software requirements are bound to be
incomplete.
 During the software process, the stakeholders’ understanding of the problem is constantly
changing
There are several reasons why change is inevitable:
1. The business and technical environment of the system always changes after installation. New
hardware may be introduced, it may be necessary to interface the system with other systems,
business priorities may change (with consequent changes in the system support required), and
new legislation and regulations may be introduced that the system must necessarily abide by.
2. The people who pay for a system and the users of that system are rarely the same people.
3. Large systems usually have a diverse user community, with many users having different
requirements and priorities that may be conflicting or contradictory.

 Requirements management is the process of understanding and controlling

changes to system requirements.
Requirements management planning
Planning is an essential first stage in the requirements management process.
The planning stage establishes the level of requirements management detail that is required.
During the requirements management stage, you have to decide on:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.8 - Requirements change Management

1. Requirements identification Each requirement must be uniquely identified so that it can be

cross-referenced with other requirements and used in traceability assessments.
2. A change management process This is the set of activities that assess the impact and cost of
changes.
3. Traceability policies These policies define the relationships between each requirement and
between the requirements and the system design that should be recorded. The traceability policy
should also define how these records should be maintained.
4. Tool support Requirements management involves the processing of large amounts of
information about the requirements. Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems.

Requirements management needs automated support and the software tools for this should be
chosen during the planning phase. You need tool support for:
1. Requirements storage The requirements should be maintained in a secure, managed data store
that is accessible to everyone involved in the requirements engineering process.
2. Change management The process of change management is simplified if active tool support
is available.
3. Traceability management Tool support for traceability allows related requirements to be
discovered. Some tools are available which use natural language processing techniques to help
discover possible relationships between requirements.
Requirements change management (Refer figure 2.8)
There are three principal stages to a change management process:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

1. Problem analysis and change specification The process starts with an identified
requirements problem or, sometimes, with a specific change proposal. During this stage, the
problem or the change proposal is analyzed to check that it is valid
2. Change analysis and costing The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements. The cost of making the change
is estimated both in terms of modifications to the requirements document and, if appropriate, to
the system design and implementation.
3. Change implementation The requirements document, the system design and implementation,
are modified. Organize the requirements document so that one can make changes to it without
extensive rewriting or reorganization.

8. Discuss in detail about various (Classical analysis) structured system Analysis. (Or) What is the
purpose of data flow diagrams? What are the notations used for the same? Explain by constructing
a Context flow diagram level-0 DFD and level-1 DFD for a library management system.

 One view of requirements modeling, called structured analysis, considers data and the processes
that transform the data as separate entities.
 Data objects are modeled in a way that defines their attributes and relationships.
 A second approach to analysis modeled, called object-oriented analysis, focuses on the definition
of classes and the manner in which they collaborate with one another to effect customer
requirements.

Flow-Oriented Modeling:
 Although data flow-oriented modeling is perceived as an outdated technique by some software
engineers, it continues to be one of the most widely used requirements analysis notations in use
today
 Although the data flow diagram (DFD) and related diagrams and information are not a formal
part of UML, they can be used to complement UML diagrams
 The DFD takes an input-process-output view of a system.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Data objects flow into the software, are transformed by processing elements, and resultant data
objects flow out of the software.
 Data objects are represented by labeled arrows, and transformations are represented by circles
(also called bubbles).
 The DFD is presented in a hierarchical fashion.
 The first data flow model (sometimes called a level 0 DFD or context diagram) represents the
system as a whole.
 Subsequent data flow diagrams refine the context diagram, providing increasing detail with
each subsequent level.

Figure 2.9 – Context level DFD for the safe home security function

Creating a Data Flow Model

The data flow diagram enables you to develop models of the information domain and
functional domain.
A few simple guidelines can aid immeasurably during the derivation of a data flow diagram:
(1) The level 0 data flow diagram should depict the software/system as a single bubble;
(2) Primary input and output should be carefully noted;
(3) Refinement should begin by isolating candidate processes, data objects, and data stores to be
represented at the next level;
(4) All arrows and bubbles should be labeled with meaningful names;
(5) Information flow continuity must be maintained from level to level and
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

(6) one bubble at a time should be refined.

Consider the Safe Home security function:

Level 0 DFD:
 A level 0 DFD for the security function is shown in Figure 2.9.
 The primary external entities (boxes) produce information for use by the system and consume
information generated by the system.
 The labeled arrows represent data objects or data object hierarchies.
 The level 0 DFD must now be expanded into a level 1 data flow model.
 Apply a “grammatical parse” to the use case narrative that describes the context-level bubble.
 Isolate all nouns (and noun phrases) and verbs (and verb phrases) in a SafeHome processing
narrative derived during the first requirements gathering meeting.
 Referring to the grammatical parse, verbs are SafeHome processes and can be represented as
bubbles in a subsequent DFD.
 Nouns are either external entities (boxes), data or control objects (arrows), or data stores (double
lines).
 By performing a grammatical parse on the processing narrative for a bubble at any DFD level,
one can generate much useful information about how to proceed with the refinement to the next
level.
Level 1 DFD:
 Using this information, a level 1 DFD is shown in Figure 2.10.
 The context level process shown in Figure 2.10 has been expanded into six processes derived
from an examination of the grammatical parse.
 Similarly, the information flow between processes at level 1 has been derived from the parse.
 In addition, information flow continuity is maintained between levels 0 and 1.
 The processes represented at DFD level 1 can be further refined into lower levels.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.10 – Level 1 DFD for Safe Home security function

Level 2 DFD:

 For example, the process monitor sensors can be refined into a level 2 DFD as shown in Figure
2.11.
 Note once again that information flow continuity has been maintained between levels.
 The refinement of DFDs continues until each bubble performs a simple function.
 That is, until the process represented by the bubble performs a function that would be easily
implemented as a program component.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.11 – Level 2 DFD that refines the monitor sensors process

Creating a Control Flow Model:

 For some types of applications, the data model and the data flow diagram are all that is
necessary to obtain meaningful insight into software requirements.
 Applications with heavy concern for time and performance require the use of control flow
modeling in addition to data flow modeling.
 Event or control item is implemented as a Boolean value (e.g., true or false, on or off, 1 or 0) or
a discrete list of conditions (e.g., empty, jammed, full).

To select potential candidate events, the following guidelines are suggested:

• List all sensors that are “read” by the software.
• List all interrupt conditions.
• List all “switches” that are actuated by an operator.
• List all data conditions.
• Recalling the noun/verb parse that was applied to the processing narrative, review all “control
items” as possible control specification inputs/outputs.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

• Describe the behavior of a system by identifying its states, identify how each state is reached,
and define the transitions between states.
• Focus on possible omissions—a very common error in specifying control.
The Control Specification (CSPEC):
 A control specification (CSPEC) represents the behavior of the system (at the level from which
it has been referenced) in two different ways.
 The CSPEC contains a state diagram that is a sequential specification of behavior. It can also
contain a program activation table—a combinatorial specification of behavior.
The Process Specification (PSPEC):
 The process specification (PSPEC) is used to describe all flow model processes that appear at
the final level of refinement.
Creating a Behavioral Model:
The behavioral model indicates how software will respond to external events or stimuli. To
create the model, you should perform the following steps:
1. Evaluate all use cases to fully understand the sequence of interaction within the system.
2. Identify events that drive the interaction sequence and understand how these events relate to
specific objects.
3. Create a sequence for each use case.
4. Build a state diagram for the system.
5. Review the behavioral model to verify accuracy and consistency.
State Representations:
 In the context of behavioral modeling, two different characterizations of states must be
considered:
(1) The state of each class as the system performs its function
(2) The state of the system as observed from the outside as the system performs its function.
 The state of a class takes on both passive and active characteristics .
 A passive state is simply the current status of all of an object’s attributes.
State diagrams for analysis classes.
 One component of a behavioral model is a UML state diagram that represents active states for
each class and the events (triggers) that cause changes between these active states.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Figure 2.12 illustrates a state diagram for the Control Panel object in the SafeHome security
function.
 Each arrow shown in Figure 2.12 represents a transition from one active state of an object to
another.
 The labels shown for each arrow represent the event that triggers the transition.

Figure 2.12 – State diagram for the control panel class

Sequence diagrams. (Refer figure 2.13)
 The second type of behavioral representation, called a sequence diagram in UML, indicates
how events cause transitions from object to object.

Figure 2.13 – Sequence diagram (partial) for the Safe Home security function
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

9. Write a brief notes on Petri Nets and discuss its properties. Draw a Petri Net that depicts the
operation of an “Automated Teller Machine“. State the functional requirements you are
considering. Nov/Dec 2019
 A Petri net is a particular kind of bipartite directed graphs populated by three types of
objects.
 These objects are places, transitions, and directed arcs.
 Directed arcs connect places to transitions or transitions to places.
 In its simplest form, a Petri net can be represented by a transition together with an input
place and an output place.
 This elementary net may be used to represent various aspects of the modeled systems.

A Petri net is formally defined as a 5-tuple N = (P, T, I, O, M0), where

(1) P = {p1, p2, …, pm} is a finite set of places;
(2) T = {t1, t2, …, tn} is a finite set of transitions, P 𝖴 T ≠ ∅, and P ∩ T = ∅;
(3) I: P × T → N is an input function that defines directed arcs from places to
transitions, where N is a set of nonnegative integers;
(4) O: T × P → N is an output function that defines directed arcs from transitions to
places; and
(5) M0: P → N is the initial marking.

 A marking in a Petri net is an assignment of tokens to the places of a Petri net.

 Tokens reside in the places of a Petri net.
 The number and position of tokens may change during the execution of a Petri net.
 The tokens are used to define the execution of a Petri net.
 Most theoretical work on Petri nets is based on the formal definition of Petri net
structures.
 However, a graphical representation of a Petri net structure is much more useful for
illustrating the concepts of Petri net theory.
 A Petri net graph is a Petri net structure as a bipartite directed multigraph.
 Corresponding to the definition of Petri nets, a Petri net graph has two types of nodes.
 A circle represents a place;
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 A bar or a box represents a transition.

 Directed arcs (arrows) connect places and transitions, with some arcs directed from
places to transitions and other arcs directed from transitions to places.

Example: A simple Petri net.

In this Petri net, we have
P = {p1, p2, p3, p4};

T = {t1, t2, t3};

I(t1, p1) = 2, I(t1, pi) = 0 for i = 2, 3, 4;

I(t2, p2) = 1, I(t2, pi) = 0 for i = 1, 3, 4;

I(t3, p3) = 1, I(t3, pi) = 0 for i = 1, 2, 4;

O(t1, p2) = 2, O(t1, p3) = 1, O(t1, pi) = 0 for i = 1, 4;

O(t2, p4) = 1, O(t2, pi) = 0 for i = 1, 2, 3;

O(t3, p4) = 1, O(t3, pi) = 0 for i = 1, 2, 3;

T
M0 = (2 0 0 0) .

Petri Net Properties

 Reachability
An important issue in designing event-driven systems is whether a system can reach a specific
state, or exhibit a particular functional behavior. In general, the question is whether the system modeled
with a Petri net exhibits all desirable properties as specified in the requirement specification.
 Safeness
In a Petri net, places are often used to represent information storage areas in communication
and computer systems, product and tool storage areas in manufacturing systems, etc. It is important to
be able to determine whether proposed control strategies prevent from the overflows of these storage
areas. The Petri net property which helps to identify the existence of overflows in the modeled system is
the concept of boundedness.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Liveness
The concept of liveness is closely related to the deadlock situation, which has been situated
extensively in the context of computer operating systems.
A Petri net modeling a deadlock-free system must be live. This implies that for any reachable
marking M, it is ultimately possible to fire any transition in the net by progressing through some firing
sequence. This requirement, however, might be too strict to represent some real systems or scenarios that
exhibit deadlock-free behavior
 High-Level Petri Nets
In a standard Petri net, tokens are indistinguishable. Because of this, Petri nets have the distinct
disadvantage of producing very large and unstructured specifications for the systems being modeled. To
tackle this issue, high-level Petri nets were developed to allow compact system representation.
 Colored Petri nets
Introduced by Kurt Jensen in (Jensen 1981), a Colored Petri Net (CPN) has its each token attached
with a color, indicating the identity of the token. Moreover, each place and each transition has attached a
set of colors.

Example: A manufacturing system.

Consider a simple manufacturing system comprising two machines M1 and M2, which process
three different types of raw parts. Each type of parts goes through one stage of operation, which can be
performed on either M1 or M2. After the completion of processing of a part, the part is unloaded from
the system and a fresh part of the same type is loaded into the system. Figure 5 shows the (uncolored)
Petri net model of the system. The places and transitions in the model are as follows:
p1 (p2): Machine M1 (M2) available

p3 (p4, p5): A raw part of type 1 (type 2, type 3) available

p6 (p7, p8): M1 processing a raw part of type 1 (type 2, type 3)

p9 (p10, p11): M2 processing a raw part of type 1 (type 2, type 3)

t1 (t2, t3): M1 begins processing a raw part of type 1 (type 2, type 3)

t4 (t5, t6): M2 begins processing a raw part of type 1 (type 2, type 3)

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

t7 (t8, t9): M1 ends processing a raw part of type 1 (type 2, type 3)

t10 (t11, t12): M2 ends processing a raw part of type 1 (type 2, type 3)

Figure 2.14 – Petrinet model of a simple manufacturing system

Now there are 11 places and 12 transitions in Fig.2.14. In this CPN model, p1 means machines

are available, p2 means parts available, p3 means processing in progress, t1 means processing starts, and

t12 means processing ends. There are three color sets: SM, SP and SM × SP, where SM = {M1, M2}, SP

= {J1, J2, J3}. The color of each node is as follows:

C(p1) = {M1, M2},

C(p2) = {J1, J2, J3},

C(p3) = SM × SP,

C(t1) = C(t2) = SM × SP.

 CPN models can be analyzed through reachability analysis.

 As for ordinary Petri nets, the basic idea behind reachability analysis is to construct a
reachability graph.
 Obviously, such a graph may become very large, even for small CPN’s.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 However, it can be constructed and analyzed totally automatically, and there exist
techniques which makes it possible to work with condensed occurrence graphs without
losing analytic power.
 Petri nets have been proven to be a powerful modeling tool for various types of dynamic
event-driven systems.

10. Explain in detail about UML (Unified Modeling Language).

 The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
 The word visual in the definition is a key point the UML is the standard diagramming
notation for drawing or presenting pictures related to software primarily OO software.
 Unified Modeling Language (UML)
o Unified Modeling Language (UML) is the set of notations, models and
diagrams used when developing object-oriented (OO) systems.
o The UML was formed from the coming together of three leading software
methodologists; Booch, Jacobson and Rumbaugh.
o UML is not limited simply modeling software.
o It can also be used to build models for system engineering, business processes,
and organization structures.
o UML can be used to represent behaviors, classes, and aggregation.

Three Ways to Apply UML

In three ways people apply UML are introduced:
 UML as sketch Informal and incomplete diagrams (often hand sketched on whiteboards)
created to explore difficult parts of the problem or solution space, exploiting the power of
visual languages. 
 UML as blueprint relatively detailed design diagrams used either for
1) Reverse engineering to visualize and better understanding existing code in
UML diagrams
2) Code generation (forward engineering).
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 UML as programming language Complete executable specification of a software system

in UML. Executable code will be automatically generated, but is not normally seen or
modified by developers; one works only in the UML "programming language."

Three Perspectives to Apply UML

a. Conceptual perspective the diagrams are interpreted as describing things in a situation of
the real world or domain of interest.
b. Specification perspective the diagrams describe software abstractions or components
with specifications and interfaces, but no commitment to a particular implementation.
c. Implementation perspective the diagrams describe software implementations in a
particular technology.
11. Explain with an example, how Use-Case modeling is used to describe functional requirements.
Identify the actors, scenario and use cases for the example. Or Elaborate use case modeling process
with suitable examples. [Apr/May-2020]
 Use cases are text stories, widely used to discover and record requirements.
 Use cases are not diagrams, they are text. Focusing on secondary-value UML use case
diagrams rather than the important use case text is a common mistake for use case
beginners.
 Use cases are requirements, primarily functional or behavioral requirements that indicate
what the system will do.

Use Cases and the Use-Case Model

 The UP defines the Use-Case Model within the Requirements discipline. Primarily, this
is the set of all written use cases; it is a model of the system's functionality and
environment.
 Use cases are text documents, not diagrams, and use-case modeling is primarily an act of
writing text, not drawing diagrams.
 The Use-Case Model is not the only requirement artifact in the UP. There are also the
Supplementary Specification, Glossary, Vision, and Business Rules. These are all useful
for requirements analysis, but secondary at this point.
 The Use-Case Model may optionally include a UML use case diagram to show the names
of use cases and actors, and their relationships. This gives a nice context diagram
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

of a system and its environment. It also provides a quick way to list the use cases by
name.

Actors, Scenarios, and Use Cases

 An actor is something with behavior, such as a person (identified by role), computer
system, or organization; for example, a cashier.
 A scenario is a specific sequence of actions and interactions between actors and the
system; it is also called a use case instance. It is one particular story of using a system, or
one path through the use case; for example, the scenario of successfully purchasing items
with cash, or the scenario of failing to purchase items because of a credit payment denial.
 A use case is a collection of related success and failure scenarios that describe an actor
using a system to support a goal. For example, here is a casual format use case with
alternate scenarios:

Three Kinds of Actors

Actors are roles played not only by people, but by organizations, software, and machines.
There are three kinds of external actors in relation to the SuD:
 Primary actor has user goals fulfilled through using services of the SuD. For example, the
cashier.
 Supporting actor provides a service (for example, information) to the SuD. The automated
payment authorization service is an example. Often a computer system, but could be an
organization or person.
 Offstage actor has an interest in the behavior of the use case, but is not primary or
supporting; for example, a government tax agency. 

Three Common Use Case Formats

Use cases can be written in different formats and levels of formality:
 Brief: Terse one-paragraph summary, usually of the main success scenario. The prior
Process Sale example was brief. 
 Casual: Informal paragraph format. Multiple paragraphs that cover various scenarios.
The prior Handle Returns example was casual. 
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Fully dressed: All steps and variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.
Fully dressed
Fully dressed use cases show more detail and are structured
Fully dressed template:
1. Scope- The scope bounds the system (or systems) under design. Typically, a use case describes
use of one software (or hardware plus software) system; in this case it is known as a system use
case.
2. Level- Use cases are classified as at the user-goal level or the subfunction level, among others.
3. Primary Actor- The principal actor that calls upon system services to fulfill a goal.
4. Stakeholders and Interests- This list is more important and practical than may appear at first
glance. It suggests and bounds what the system must do.
5. Preconditions and Success Guarantees (Postconditions)
 Preconditions state what must always be true before a scenario is begun in the use case.
 Success guarantees (or postconditions) state what must be true on successful completion of
the use case either the main success scenario or some alternate path. The guarantee should
meet the needs of all stakeholders.
6. Main Success Scenario and Steps (or Basic Flow)- This has also been called the "happy path"
scenario, or the more prosaic "Basic Flow" or "Typical Flow."
7. Extensions (or Alternate Flows)- Extensions are important and normally comprise the
majority of the text. They indicate all the other scenarios or branches, both success and
failure.
8. Special Requirements- If a non-functional requirement, quality attribute, or constraintrelates
specifically to a use case, record it with the use case.
9. Technology and Data Variations List-Often there are technical variations in how something
must be done, but not what, and it is noteworthy to record this in the use case.
Guideline for Use cases
 Write in an Essential UI-Free Style
 Write Terse Use Cases
 Write Black-Box Use Cases
 Take an Actor and Actor-Goal Perspective
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

How to Find Use Cases

Use cases are defined to satisfy the goals of the primary actors. Hence, the basic
procedure is:
1. Choose the system boundary. Is it just a software application, the hardware and application
as a unit, that plus a person using it, or an entire organization?

2. Identify the primary actors those that have goals fulfilled through using services of the system.
3. Identify the goals for each primary actor.
4. Define use cases that satisfy user goals; name them according to their goal. Usually, user- goal
level use cases will be one-to-one with user goals, but there is at least one exception, as will
be examined.
Example:
Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the
POS system to record each purchased item. The system presents a running total and line-item details.
The customer enters payment information, which the system validates and records. The system
updates inventory. The customer receives a receipt from the system and then leaves with the
items.

Scope: NextGen POS application

Level: user goal
Primary Actor: Cashier
Stakeholders and Interests:
- Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are deducted
from his/her salary.
- Salesperson: Wants sales commissions updated.
- Customer: Wants purchase and fast service with minimal effort
- Company: Wants to accurately record transactions and satisfy customer interests.
- Manager: Wants to be able to quickly perform override operations, and easily debug Cashier
problems.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated. Accounting and
Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

are recorded.

Main Success Scenario (or Basic Flow):

1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total.
Price calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:
*b. At any time, System fails:

Special Requirements:
- Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
- Credit authorization response within 30 seconds 90% of the time.
Technology and Data Variations List:
*a. Manager override entered by swiping an override card through a card reader, or entering an
authorization code via the keyboard.
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
- What are the tax law variations?
- Explore the remote service recovery issue.

12. What is meant by UML diagrams? List various UML diagrams and explain the purpose of
each diagram. [April/May 2014] (Nov-Dec-2021)
UML Diagrams:
“The UML diagrams (Refer figure 2.15) are a standard diagramming notation for specifying,
visualizing, constructing and documenting the artifacts of software systems”
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

1. Use-case diagram
2. Class diagram
3. Behavior diagram
3.1 Interaction diagram
3.1.1. Sequence diagram
3.1.2. Collaboration diagram
3.2 State chart diagram
3.3 Activity diagram
4. Implementation diagram
4.1 Component diagram
4.2 Deployment diagram

Figure 2.15: UML Diagrams

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

1. USE CASE DIAGRAM:

Definition:
The functionality of a system can be described in a number of different use-cases, each of which
represents a specific flow of events in a system. It is a graph of actors, a set of use-cases enclosed in a
boundary, communication, associations between the actors and the use-cases, and generalization among
the use-cases”
Actors, Scenarios and Use Cases
Actors:
 The actors are the entities that use the system or product within the context of behavior of the system.
 Actors represent the role of the people as system gets operated.
Scenarios
Scenarios are nothing but the text stories
Use Cases:
Use cases are the textual representation of particular scenario
Use Case Model:
Use case model is the graphical representation of the scenario.
Types of Actors
Three kinds of Actors:
1. Primary Actor
The primary actors are the actors that interact with the system in order to achiever the user goals.
2. Supporting Actor
The Supporting actors are used in conjunction with the primary actors in order to support for the main
services.
3. Offstage Actor
These actors help in behavior of the system.
Following figure 2.16 shows the use case diagram for ATM System
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.16: Use case Diagram

2. UML CLASS DIAGRAM:
The UML class diagram is also known as object modeling. It is a static analysis diagram. These
diagrams shown in figure 2.17. These diagrams show the static structure of the model. A class diagram
is a connection of static model elements, such as classes and their relationships, connected as a graph to
each other and to their contents.

Figure 2.17: Class Diagram

3. UML BEHAVIOR DIAGRAM

Behavior diagrams emphasize what must happen in the system being modeled.
Since behavior diagrams illustrate the behavior of a system, they are used extensively to describe the
functionality of software systems.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

For example, the activity diagram describes the business and operational step-by-step activities of the
components in a system.
3.1 Interaction diagram
It is the combination of sequence and collaboration diagram. It is used to depict the flow of
events in the system over a timeline. The interaction diagram is a dynamic model which shows how the
system behaves during dynamic execution is shown in figure 2.18.

Figure 2.18 - Interaction Diagram

 State chart diagram
It consists of state, events and activities. State diagrams are a familiar technique to describe the
behavior of a system. They describe all of the possible states that a particular object can get into and how
the object's state changes as a result of events that reach the object. In most OO techniques, state diagrams
are shown in figure 2.19, drawn for a single class to show the lifetime behavior of a single object.

Figure 2.19 - State Chart Diagram

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Activity diagram
It shows organization and their dependence among the set of components. These diagrams are
shown in figure 2.20, particularly useful in connection with workflow and in describing behavior that
has a lot of parallel processing. An activity is a state of doing something: either a real-world process,
or the execution of a software routine.

Figure 2.20 - Activity Diagram

IMPLEMENTATION DIAGRAM
It shows the implementation phase of the systems development, such as the source code structure and
the run-time implementation structure. These are relatively simple high-level diagrams compared to
the others seen so far. They are of two sub-diagrams, the component diagram and the deployment
diagram.
Component diagram:
These are organizational parts of a UML model. These are boxes to which a model can be
decomposed. They show in figure 2.21 is the structure of the code itself. They model the physical
components such as source code, user interface in a design. It is similar to the concept of packages.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.21 - Component Diagram

Deployment diagram:
The deployment diagram shown in figure 2.22 is the structure of the runtime system. It shows the
configuration of runtime processing elements and the software components that live in them. They
are usually used in conjunction with deployment diagrams to show how physical modules of code
are distributed on the system.
There are two types of Nodes:
1. Device Node
2. Execution Environment Node
Device nodes are physical computing resources with processing memory and services to execute
software, such as typical computers or mobile phones.
An execution environment node (EEN) is a software computing resource that runs within an outer
node and which itself provides a service to host and execute other executable software elements.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.22 - Deployment Diagram

13. Consider a distributed information system for accident management. It includes many
actors such as FieldOfficer, who represent the police, fire officers who respond to accidents,
and Dispatcher, the police officer responsible for answering 911 calls and dispatching
resources to an accident. FRIEND supports both actors by keeping track of incidents,
resources, and task plans. The FieldOfficer and the Dispatcher interact through different
interface – FieldOfficer interacts FRIEND through a mobile personal assistant, and
Dispatcher access FRIEND through a workstation. Identify suitable process model for the
above project and justify your answer. (Refer figure 2.23) (NOV/DEC 2021)
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.23 - Use case Diagram

14. Explain in Detail about UML Class Diagrams. (Or) Describe the UML notation for the
Class Diagram with an example. Explain the concept of association and Inheritance. (NOV /
DEC 2011) (MAY/JUNE 2012) (NOV / DEC 2012) (MAY/JUNE 2013)
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Design Class Diagram

In a conceptual perspective the class diagram can be used to visualize a domain model is
shown in figure 2.24.
A common modeling term for this purpose is design class diagram (DCD).
In the UP, the set of all DCDs form part of the Design Model. Other parts of the Design
Model include UML interaction and package diagrams.

Figure 2.24 - UML class diagrams in two perspectives

Definition: Classifier
A UML classifier is "a model element that describes behavioral and structure features".
Classifiers can also be specialized. They are a generalization of many of the elements of the UML,
including classes, interfaces, use cases, and actors. In class diagrams, the two most common
classifiers are regular classes and interfaces.

Attribute Text and Association Lines

Attributes of a classifier (also called structural properties in the UML) shown in figure 2.25
are several ways:
 Attribute text notation, such as currentSale : Sale.
 association line notation
 both together
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.25: Attribute text versus association line notation for a UML attribute.
The full format of the attribute text notation is shown in figure 2.25:
Visibility name: type multiplicity = default {property-string}
Visibility marks include + (public), - (private), and so forth.
Guideline: Attributes are usually assumed private if no visibility is given.
Notice that this attribute-as-association line has the following style:
 a navigability arrow pointing from the source (Register) to target (Sale) object,
indicating a Register object has an attribute of one Sale
 a multiplicity at the target end, but not the source end
o use the multiplicity notation
 a rolename (currentSale) only at the target end to show the attribute name
 no association name

Figure 2.26: Idioms in association notation usage in different perspectives.

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

When to Use Attribute Text versus Association Lines for Attributes?

 Use the attribute text notation for data type objects and the association line notation for
others. Both are semantically equal, but showing an association line to another class box
in the diagram gives visual emphasis it catches the eye, emphasizing the connection
between the class of objects on the diagram (figure 2.27).
 A data type refers to objects for which unique identity is not important.
 Common data types are primitive-oriented types such as:
 Boolean, Date (or DateTime), Number, Character, String (Text), Time,
Address, Color, Geometrics (Point, Rectangle), Phone Number, Social
Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes,
enumerated types

Figure 2.27 - Applying the guidelines to show attributes in two notations

The UML Notation for an Association End

 The end of an association can have a navigability arrow. It can also include an optional
role name to indicate the attribute name. And of course, the association end may also show
a multiplicity value, such as '*' or '0..1'.
 A property string such as {ordered} or {ordered, List} is possible. {ordered} is a UML-
defined keyword that implies the elements of the collection are ordered. Another related
keyword is {unique}, implying a set of unique elements.
 The keyword {List} illustrates that the UML also supports user-defined keywords. I define
{List} to mean the collection attribute lineItems will be implemented with an object
implementing the List interface.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

How to Show Collection Attributes with Attribute Text and Association Lines?
Suppose that a Sale software object holds a List (an interface for a kind of collection) of
many SalesLineItem objects. For example, in Java:
public class Sale
{
private List<SalesLineItem> lineItems = new ArrayList<SalesLineItem>();
// …}

Figure 2.28: Two ways to show a collection attribute in the UML

 Figure 2.28 shows two ways to illustrate a collection attribute in class diagrams.
 Notice also the optional use of property strings such as {ordered}.

Note Symbols: Notes, Comments, Constraints, and Method Bodies

Note symbols can be used on any UML diagram, but are especially common on class
diagrams.
A UML note symbol is displayed as a dog-eared rectangle with a dashed line to the
annotated element. A note symbol may represent several things, such as:
 A UML note or comment, which by definition have no semantic impact
 AUML constraint, in which case it must be encased in braces '{…}'
 A method body the implementation of a UML operation

Operations and Methods

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Operations
 One of the compartments of the UML class box shows the signatures of operations. At
the time of this writing, the full, official format of the operation syntax is:
visibility name (parameter-list) {property-string}
visibility name (parameter-list) : return-type {property-string}
 Assume the version that includes a return type.
 Operations are usually assumed public if no visibility is shown.
 The property string contains arbitrary additional information, such as exceptions that
may be raised, if the operation is abstract, and so forth.
 For example, both expressions are possible:
+ getPlayer( name : String ) : Player {exception IOException}
public Player getPlayer( String name ) throws IOException

How to Show Methods in Class Diagrams?

A UML method is the implementation of an operation; if constraints are defined, the
method must satisfy them. A method may be illustrated (in figure 2.29) several ways, including:
 In interaction diagrams, by the details and sequence of messages
 In class diagrams, with a UML note symbol stereotyped with «method»

Figure 2.29: How to show a method body in a class diagram

Operation Issues in DCDs

1. The create Operation
 The create message in an interaction diagram is normally interpreted as the invocation
of the new operator and a constructor call in languages such as Java and C#.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 In a DCD this create message will usually be mapped to a constructor definition, using
the rules of the language such as the constructor name equal to the class name (Java,
C#, C++,…).
2. Operations to Access Attributes
 Accessing operations retrieve or set attributes, such as getPrice and setPrice.
 These operations are often excluded (or filtered) from the class diagram because of
the high noise-to-value ratio they generate; for n attributes, there may be 2n
uninteresting getter and setter operations.
 Most UML tools support filtering their display, and it's especially common to ignore
them while wall sketching.

Keywords
 A UML keyword is a textual adornment to categorize a model element.
 For example, the keyword to categorize that a classifier box is an interface is (shocking
surprise!) «interface». The «actor» keyword was used to replace the human stick-figure
actor icon with a class box to model computer-system or robotic actors.
 Most keywords are shown in guillemet (« ») but some are shown in curly braces, such as
{abstract}, which is a constraint containing the abstract keyword.
 In general, when a UML element says it can have a "property string" such as a UML
operation and UML association end have some of the property string terms will be
keywords used in the curly brace format.

A few samples predefined UML keywords include:

There are many keywords.

Keyword Meaning Example Usage

«actor» classifier is an actor in class diagram, above classifier name

«interface» classifier is an interface in class diagram, above classifier name

{abstract} abstract element; can't be in class diagrams, after classifier name or

instantiated operation name
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Keyword Meaning Example Usage

{ordered} a set of objects have some imposed in class diagrams, at an association end
order

Stereotypes, Profiles, and Tags

 A stereotype represents a refinement of an existing modeling concept and is defined within
a UML profile in formally, a collection of related stereotypes, tags, and constraints to
specialize the use of the UML for a specific domain or platform, such as a UML profile
for project management or for data modeling.
 The keywords, stereotypes are shown with guillemets symbols, such as «authorship». But,
they are not keywords, which can be confusing.
 The UML predefines many stereotypes, such as «destroy» (used on sequence diagrams),
and also allows user-defined ones. Thus, stereotypes provide an extension mechanism in
the UML.
 For example, Figure 2.30 shows a stereotype declaration, and its use. The stereotype
declares a set of tags, using the attribute syntax.
 When an element is marked with a stereotype, all the tags apply to the element, and can
be assigned values.

Figure 2.30: Stereotype declaration and use.

UML Properties and Property Strings

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 In the UML, a property is "a named value denoting a characteristic of an element. A

property has semantic impact".
 Some properties are predefined in the UML, such as visibility a property of an operation.
Others can be user-defined.
 Properties of elements may be presented in many ways, but a textual approach is to use
the UML property string {name1=value1, name2=value2} format, such as {abstract,
visibility=public}.
 Some properties are shown without a value, such as {abstract}; this usually implies a
boolean property, shorthand for {abstract=true}. Note that {abstract} is both an example
of a constraint and a property string.

Generalization, Abstract Classes, Abstract Operations

Generalization:
 Generalization in the UML is shown with a solid line and fat triangular arrow from the
subclass to superclass. In the UML, to quote:
 A taxonomic relationship between a more general classifier and a more specific classifier.
Each instance of the specific classifier is also an indirect instance of the general classifier.
Thus, the specific classifier indirectly has features of the more general classifier.
Abstract classes and operations
 Abstract classes and operations can be shown either with an {abstract} tag (useful when
sketching UML) or by italicizing the name (easy to support in a UML tool).
 The opposite case, final classes and operations that can't be overridden in subclasses, are
shown with the {leaf} tag.

Dependency
 Dependency lines may be used on any diagram, but are especially common on class and
package diagrams. 
 The UML includes a general dependency relationship that indicates that a client element
(of any kind, including classes, packages, use cases, and so on) has knowledge of another
supplier element and that a change in the supplier could affect the client.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Dependency is illustrated with a dashed arrow line from the client to supplier.
 Dependency can be viewed as another version of coupling, a traditional term in software
development when an element is coupled to or depends on another.
 There are many kinds of dependency; here are some common types in terms of objects
and class diagrams:
 having an attribute of the supplier type
 sending a message to a supplier; the visibility to the supplier could be:
o an attribute, a parameter variable, a local variable, a global variable,
or class visibility (invoking static or class methods)
 receiving a parameter of the supplier type
 the supplier is a superclass or interface
 For example figure 2.31, the following Java code shows an updatePriceFor method in
the Sale class:
public class Sale
{
public void updatePriceFor( ProductDescription description )
{ Money basePrice = description.getPrice(); //… } // … }

Figure 2.31: Showing dependency

Another example: The following Java code shows a doX method in the Foo class:
public class Foo
{
public void doX()
{ System.runFinalization(); //… } // … }
The doX method invokes a static method on the System class. Therefore, the Foo object
(see figure 2.32) has a static-method dependency on the System class.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.32: Showing dependency

Dependency Labels
To show the figure 2.35 the type of dependency or to help a tool with code generation,
the dependency line can be labeled with keywords or stereotype

Figure 2.33: Dependency levels

Interfaces
The UML provides several ways to show interface implementation, providing an
interface to clients, and interface dependency. In the UML, interface implementation is formally
called interface realization is shown in figure 2.36.

Figure 2.34: Different notations to show interfaces in UML

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

The UML includes class diagrams to illustrate in figure 2.35, classes, interfaces, and their
associations. They are used for static object modeling.

Figure 2.35 - Common Class Diagram Notation

15. Explain in detail about Interaction diagrams with an example.

Interaction Diagrams

 Interaction diagrams describe patterns of communication among a set of interacting

objects. An object interacts with another object by sending messages.
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 The reception of a message by an object triggers the execution of a method, which in turn may
send messages to other objects.

 Arguments may be passed along with a message and are bound to the parameters of the
executing method in the receiving object.

 In UML, interaction diagrams can take one of two forms: sequence diagrams or
communication diagrams.

 Sequence diagrams represent the objects participating in the interaction horizontally and time
vertically.

 For example, consider a watch with two buttons (hereafter called 2Bwatch). Setting the time
on 2Bwatch requires the actor 2BWatchOwner to first press both buttons simultaneously, after
which 2Bwatch enters the set time mode.

 In the set time mode, 2Bwatch blinks the number being changed (e.g., the hours, minutes,
seconds, day, month, or year). Initially, when the 2BWatchOwner enters the set time mode,
the hours blink.

 If the actor presses the first button, the next number blinks (e.g, if the hours are blinking and
the actor presses the first button, the hours stop blinking and the minutes start blinking). If the
actor presses the second button, the blinking number is incremented by one unit.

 If the blinking number reaches the end of its range, it is reset to the beginning of its range (e.g.,
assume the minutes are blinking and its current value is 59, its new value is set to 0 if the actor
presses the second button). The actor exits the set time mode by pressing both buttons
simultaneously.

 Figure 2-36 depicts a sequence diagram for an actor setting his 2Bwatch one minute ahead.
Each column represents an object that participates in the interaction. Messages are shown by
solid arrows.

 Labels on solid arrows represent message names and may contain arguments. Activations (i.e.,
executing methods) are depicted by vertical rectangles. The actor who initiates the
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

interaction is shown in the left-most column. The messages coming from the actor represent
the interactions described in the use case diagrams.

 If other actors communicate with the system during the use case, these actors are represented
on the right-hand side and can receive messages.

 Although for simplicity, interactions among objects and actors are uniformly represented as
messages, the modeler should keep in mind that interactions between actors and the system are
of a different nature than interactions among objects.

 Sequence diagrams can be used to describe either an abstract sequence (i.e., all possible
interactions) or concrete sequences (i.e., one possible interaction, as in Figure 2-38). When
describing all possible interactions, sequence diagrams provide notations for iterations and
conditionals.

 Iteration is denoted by a combined fragment labeled with the loop operator (see Figure 2- 38).
An alternative is denoted by a combined fragment containing a partition for each alternative.

 The alternatives are selected by guards on the first message of the partition ([i>0] and [else] in
Figure 2-36). If i is positive, the top alternative of the alt combined fragment is executed and the
op1() message is sent. Otherwise, the bottom alternative is executed and the op2() message is sent.

Figure 2.36 - Example of a sequence diagram: setting the time on 2Bwatch.

 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Figure 2.37 - Examples of conditions and iterators in sequence diagrams

Communication diagrams depict the same information as sequence diagrams. Communication diagrams
represent the sequence of messages by numbering the interactions. On one hand, this removes the need
for geometrical constraints on the objects and results in a more compact diagram. On the other hand, the
sequence of messages becomes more difficult to follow. Figure 2-38 depicts the communication diagram
that is equivalent to the sequence diagram of Figure 2-36

Figure 2-38 Example of a communication diagram: setting the time on 2Bwatch. This diagram
represents the same use case as the sequence diagram of Figure 2-36.

Applying interaction diagrams Interaction diagrams describe interactions among several objects. One of
the main reasons for constructing an interaction diagram is to uncover the responsibilities of the classes
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

in the class diagrams and to discover even new classes. In other words, the interaction diagram helps the
developer in deciding which objects require particular operations.

Typically, there is an interaction diagram for every use case with focus on the event flow. The developer
identifies the objects that participate in the use case, and assigns pieces of the use case behavior to the
objects in the form of operations.

The class diagram and the associated interaction diagrams are usually constructed in tandem after the
initial class diagram has been defined. This process often also leads to refinements in the use case (e.g.,
correcting ambiguous descriptions, adding missing behavior) and consequently, the discovery of more
objects and more services.

16. Discuss about CASE Tools.

 Computer Aided Software Engineering (CASE) tools are set of software application programs,
which are used to automate SDLC activities. CASE tools are used by software project managers,
analysts and engineers to develop software system.
 There are number of CASE tools available to simplify various stages of Software Development
Life Cycle such as Analysis tools, Design tools, Project management tools, Database
Management tools, Documentation tools are to name a few.
 Use of CASE tools accelerates the development of project to produce desired result and helps to
uncover flaws before moving ahead with next stage in software development.

TAXONOMY OF CASE TOOLS

 CASE tools can be classified by function, by their role as instruments for managers or technical
people, by their use in the various steps of the software engineering process, by the environment
architecture (hardware and software) that supports them, or even by their origin or cost .The
taxonomy presented here uses function as a primary criterion.
Business process engineering tools:
The primary objective for tools in this category is to represent business data objects, their
relationships, and how these data objects flow between different business areas within a company.
Process modeling and management tools:
Process management tools provide links to other tools that provide support to defined process
activities.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Project planning tools:

Project scheduling tools enable the manager to define all project tasks (the work breakdown
structure), create a task network (usually using graphical input), represent task interdependencies, and
model the amount of parallelism possible for the project.
Risk analysis tools:
Risk analysis tools enable a project manager to build a risk table by providing detailed guidance
in the identification and analysis of risks.
Project management tools:
The project schedule and project plan must be tracked and monitored on a continuing basis.
Tools in the category are often extensions to project planning tools.
Requirements tracing tools:
The objective of requirements tracing tools is to provide a systematic approach to the isolation
of requirements, beginning with the customer request for proposal or specification.
Metrics and management tools:
Management-oriented tools capture project specific metrics (e.g., LOC/person-month, defects per
function point) that provide an overall indication of productivity or quality. Technically oriented tools
determine technical metrics that provide greater insight into the quality of design or code.
Documentation tools:
Document production and desktop publishing tools support nearly every aspect of software
engineering and represent a substantial "leverage" opportunity for all software developers. The
documentation tools provide an important opportunity to improve productivity.
System software tools:
CASE is a workstation technology. Therefore, the CASE environment must accommodate high-
quality network system software, object management services, distributed component support, electronic
mail, bulletin boards, and other communication capabilities.
Quality assurance tools:
The majority of CASE tools that claim to focus on quality assurance are actually metrics tools
that audit source code to determine compliance with language standards.
Database management tools:
Database management software serves as a foundation for the establishment of a CASE database
(repository) that we have called the project database.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Software configuration management tools:

Tools can assist in all five major SCM tasks—identification, version control, change control,
auditing, and status accounting.
Analysis and design tools:
Analysis and design tools enable a software engineer to create models of the system to be built.
The models contain a representation of data, function, and behavior (at the analysis level) and
characterizations of data, architectural, component-level, and interface design.
PRO/SIM tools:
PRO/SIM (prototyping and simulation) tools provide the software engineer with the ability to
predict the behavior of a real-time system prior to the time that it is built.
Interface design and development tools.
Interface design and development tools are actually a tool kit of software components (classes)
such as menus, buttons, window structures, icons, scrolling mechanisms, device drivers, and so forth.
Prototyping tools:
 A variety of different prototyping tools can be used. Screen painters enable a software engineer
to define screen layout rapidly for interactive applications. More sophisticated CASE prototyping
tools enable the creation of a data design, coupled with both screen and report layouts.
 Many analysis and design tools have extensions that provide a prototyping option. PRO/SIM tools
generate skeleton Ada and C source code for engineering (real-time) applications. Finally, a
variety of fourth generation tools have prototyping features.
Programming tools:

The programming tools category encompasses the compilers, editors, and debuggers that are
available to support most conventional programming languages.
Web development tools:
The activities associated with Web engineering are supported by a variety of tools for WebApp
development. These include tools that assist in the generation of text, graphics, forms, scripts, applets,
and other elements of a Web page.
Static analysis tools:
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Static testing tools assist the software engineer in deriving test cases. Three different types of
static testing tools are used in the industry: codebased testing tools, specialized testing languages,
and requirements-based testing tools.
 Code-based testing tools accept source code (or PDL) as input and perform a number of analyses
that result in the generation of test cases.
 Specialized testing languages (e.g., ATLAS) enable a software engineer to write detailed test
specifications that describe each test case and the logistics for its execution.
 Requirements-based testing tools isolate specific user requirements and suggest test cases (or
classes of tests) that will exercise the requirements.
Dynamic analysis tools:
 Dynamic testing tools interact with an executing program, checking path coverage, testing
assertions about the value of specific variables, and otherwise instrumenting the execution flow of
the program.
 Dynamic tools can be either intrusive or nonintrusive. An intrusive tool changes the software to be
tested by inserting probes (extra instructions) that perform the activities just mentioned.
Nonintrusive testing tools use a separate hardware processor that runs in parallel with the processor
containing the program that is being tested.
Test management tools:
 Test management tools are used to control and coordinate software testing for each of the major
testing steps. Tools in this category manage and coordinate regression testing, perform comparisons
that ascertain differences between actual and expected output, and conduct batch testing of programs
with interactive human/computer interfaces.
 In addition to the functions noted, many test management tools also serve as generic test drivers.
A test driver reads one or more test cases from a testing file, formats the test data to conform to the
needs of the software under test, and then invokes the software to be tested.
Client/server testing tools:
The c/s environment demands specialized testing tools that exercise the graphical user interface
and the network communications requirements for client and server.
Reengineering tools:
Tools for legacy software address a set of maintenance activities that currently absorb a
significant percentage of all software-related effort. The reengineering tools category can be subdivided
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

into the following functions Reverse engineering to specification tools take source code as input and
generate graphical structured analysis and design models, where-used lists, and other design information.
• Code restructuring and analysis tools analyze program syntax, generate a control flow graph, and
automatically generate a structured program.
• On-line system reengineering tools are used to modify on-line database systems.
The benefits of integrated CASE
The benefits of integrated CASE (I-CASE) include
(1) Smooth transfer of information (models, programs, documents, data) from one tool to another and
one software engineering step to the next
(2) A reduction in the effort required to perform umbrella activities such as software configuration
management, quality assurance, and document production
(3) An increase in project control that is achieved through better planning, monitoring, and
communication and
(4) Improved coordination among staff members who are working on a large software project.

17. Explain about UML State Machine Diagrams and Modeling. Or Differentiate state
independent and state dependent objects. How to model them using State Machine Diagrams?
Differentiate events, states and transitions with suitable examples.
 A UML state machine is a notation for describing the sequence of states an object goes through
in response to external events.

 UML state machines are extensions of the finite state machine model. On one hand, state
machines provide notation for nesting states and state machines (i.e., a state can be described by
a state machine).

 On the other hand, state machines provide notation for binding transitions with message sends
and conditions on objects. UML state machines are largely based on Harel’s state charts and have
been adapted for use with object models.

 UML state machines can be used to represent any Mealy or Moore state machine.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 A state is a condition satisfied by the attributes of an object. For example, an Incident object in
FRIEND can exist in four states: Active, Inactive, Closed, and Archived (see Figure 2-39).

 An active Incident denotes a situation that requires a response (e.g., an ongoing fire, a traffic
accident). An inactive Incident denotes a situation that was handled, but for which reports are yet
to be written (e.g., the fire has been put out, but damage estimates have not yet been completed).
A closed Incident denotes a situation that has been handled and documented.

An archived Incident is a closed Incident whose documentation has been moved to off-site storage. In
this example, we can represent these four states with a single attribute in the Incident class—a status
attribute that can take any of four values: Active, Inactive, Closed, and Archived. In general, a state can
be computed from the values of several attributes.

A transition represents a change of state triggered by events, conditions, or time. For example, Figure 2-
39 depicts three transitions: from the Active state into the Inactive state, from the Inactive state to the
Closed state, and from the Closed state to the Archived state.

A state is depicted by a rounded rectangle. A transition is depicted by an open arrow connecting two
states. States are labeled with their name. A small solid black circle indicates the initial state. A circle
surrounding a small solid black circle indicates a final state.

Figure 2.39 - A UML state machine diagram for the Incident class.

 Figure 2.40 displays another example, a state machine for the 2Bwatch. At the highest level of
abstraction, 2Bwatch has two states, MeasureTime and SetTime. 2Bwatch changes states when
the user presses and releases both buttons simultaneously. During the transition from the SetTime
state to the MeasureTime state, 2Bwatch beeps.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 This is indicated by the action /beep on the transition. When 2Bwatch is first powered on, it is in
the SetTime state. This is modeled by making SetTime the initial state. When the battery of the
watch runs out, the 2Bwatch is permanently out of order.
 This is indicated with a final state. In this example, transitions can be triggered by an event
(e.g.,pressBothButtons) or by the passage of time (e.g., after 2 min.).

Figure 2.40 – Refined state machine diagram for 2B watch

 Figure 2.40 depicts a refined state machine diagram for the 2Bwatch depicted in Figure 2.39 using
actions to denote the behavior within the states.
 Actions are fundamental units of processing that can take a set of inputs, produce a set of outputs,
and can change the state of the system. Actions normally take a short amount of time to execute
and are not interruptable.
For example, an action can be realized by an operation call. Actions can occur in three places in a state
machine:
• When a transition is taken (e.g., beep when the transition between SetTime and MeasureTime is fired
on the pressBothButtons event)
• When a state is entered (e.g., blink hours in the SetTime state in Figure 2.40)
• When a state is exited (e.g., stop blinking in the SetTime state in Figure 2.40).
 During a transition, the exit actions of the source state are executed first, then the actions
associated with the transition are executed, then the entry actions of the destination state are
executed.
 The exit and entry actions are always executed when a state is exited or entered, respectively.
They do not depend on the specific transition that was used to exit or enter the state. An internal
transition is a transition that does not leave the state.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 Internal transitions are triggered by events and can have actions associated with them. However,
the firing of an internal transition does not result in the execution of any exit or entry actions. For
example, in Figure 2.40, the SetTime state has two internal transitions, one associated with
pressing the left button and one associated with pressing the right button.
 An activity is a coordinated set of actions. A state can be associated an activity that is executed
as long as an object resides in this state. While an action is short and non-interruptable, an activity
can take a substantial amount of time and is interrupted when a transition exiting the state is fired.
 Activities are associated with state using the do label and are placed inside the state where they
executed. For example, in Figure 2.40, count ticks is an activity associated with the MeasureTime
state Nested state machines reduce complexity.
 They can be used instead of internal transitions. In Figure 2.41, the current number is modeled
as a nested state, whereas actions corresponding to modifying the current number are modeled
using internal transitions. Note that each state could be modeled as a nested state machine. For
example, the BlinkHours state machine would have 24 substates that correspond to the hours in
the day; transitions between these states would correspond to pressing the second button.

Figure 2.41 – Refined State machine diagram

Applying state machine diagrams

 State machine diagrams are used to represent nontrivial behavior of a subsystem or an object.
Unlike interaction diagrams that focus on the events impacting the behavior of a set of objects,
state machine diagrams make explicit which attribute or set of attributes have an impact on the
behavior of a single object.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 State machines are used to identify object attributes and to refine the behavior description of an
object, and interaction diagrams are used to identify participating objects and the services they
provide.
 State machine diagrams can also be used during system and object design to describe solution
domain objects with interesting behavior.

18. Explain about UML Activity Diagrams.

 UML activity diagrams represent the sequencing and coordination of lower level behaviors. An
activity diagram denotes how a behavior is realized in terms of one or several sequences of
activities and the object flows needed for coordinating the activities.
 Activity diagrams are hierarchical: an activity is made out of either an action or a graph of sub
activities and their associated object flow. Figure 2.42 is an activity diagram corresponding to the
state diagram in Figure 2-38. Rounded rectangles represent actions and activities. Edges between
activities represent control flow. An activity can be executed only after all predecessor activities
completed.

Figure 2.42 – Activity diagram

 Control nodes coordinate control flows in an activity diagram, providing mechanisms for
representing decisions, concurrency, and synchronization. The main control nodes we use are
decisions, fork nodes, and join nodes.
 Decisions are branches in the control flow. They denote alternatives based on a condition of the
state of an object or a set of objects. Decisions are depicted by a diamond with one or more
incoming open arrows and two or more outgoing arrows.
 The outgoing edges are labeled with the conditions that select a branch in the control flow. The
set of all outgoing edges from a decision represents the set of all possible outcomes.
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

 In Figure 2.43, a decision after the OpenIncident action selects between three branches: If the
incident is of high priority and if it is a fire, the FireChief is notified. If the incident is of high
priority and is not a fire, the PoliceChief is notified.
 Finally, if neither condition is satisfied, that is, if the Incident is of low priority, no superior is
notified and the resource allocation proceeds.
Fork nodes and join nodes represent concurrency. Fork nodes denote the splitting of the flow of control
into multiple threads, while join nodes denotes the synchronization of multiple threads and their merging
of the flow of control into a single thread.
For example, in Figure 2.44, the actions AllocateResources, Coordinate–Resources, and
DocumentIncident may all occur in parallel. However, they can only be initiated after the OpenIncident
action, and the ArchiveIncident action may only be initiated after all other activities have been completed.
Activities may be grouped into swimlanes (also called activity partitions) to denote the object or
subsystem that implements the actions. Swimlanes are represented as rectangles enclosing a group of
actions. Transitions may cross swimlanes. In Figure 2.45, the Dispatcher swimlane groups all the actions
that are performed by the Dispatcher object. The FieldOfficer swimlane denotes that the FieldOfficer
object is responsible for the DocumentIncident action.

Figure 2.43 Figure 2.44

Figure 2.45
 CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 2

Applying activity diagrams

 Activity diagrams provide a task-centric view of the behavior of a set of objects. They can be
used: for example, to describe sequencing constraints among use cases, sequential activities
among a group of objects, or the tasks of a project.

19. For the Hospital management system draw the following UML diagram.

(i) Conceptual Class diagram (Overall system)

(ii) Activity diagram (Billing see figure 2.46).

Figure 2.46-Activity diagram